* [PATCH 3/3] drm/i915: extract constant offset setting
From: Ben Widawsky @ 2011-10-23 2:41 UTC (permalink / raw)
To: intel-gfx; +Cc: Ben Widawsky
In-Reply-To: <1319337685-26195-1-git-send-email-ben@bwidawsk.net>
Simple refactor.
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 82 ++++++++++++++++------------
1 files changed, 46 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1589a19..a5c856b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -954,6 +954,50 @@ i915_gem_execbuffer_retire_commands(struct drm_device *dev,
}
static int
+i915_gem_set_constant_offset(struct intel_ring_buffer *ring, int mode)
+{
+ struct drm_device *dev = ring->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ uint32_t mask = I915_EXEC_CONSTANTS_MASK;
+ int ret;
+
+ switch (mode) {
+ case I915_EXEC_CONSTANTS_REL_GENERAL:
+ case I915_EXEC_CONSTANTS_ABSOLUTE:
+ case I915_EXEC_CONSTANTS_REL_SURFACE:
+ if (ring == &dev_priv->ring[RCS] &&
+ mode != dev_priv->relative_constants_mode) {
+ if (INTEL_INFO(dev)->gen < 4)
+ return -EINVAL;
+
+ if (INTEL_INFO(dev)->gen > 5 &&
+ mode == I915_EXEC_CONSTANTS_REL_SURFACE)
+ return -EINVAL;
+
+ /* The HW changed the meaning on this bit on gen6 */
+ if (INTEL_INFO(dev)->gen >= 6)
+ mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
+
+ ret = intel_ring_begin(ring, 4);
+ if (ret)
+ return ret;
+
+ intel_ring_emit(ring, MI_NOOP);
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, INSTPM);
+ intel_ring_emit(ring, mask << 16 | mode);
+ intel_ring_advance(ring);
+
+ dev_priv->relative_constants_mode = mode;
+ }
+ return 0;
+ default:
+ DRM_ERROR("execbuf with unknown constants: %d\n", mode);
+ return -EINVAL;
+ }
+}
+
+static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
struct drm_i915_gem_execbuffer2 *args,
@@ -967,7 +1011,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct intel_ring_buffer *ring;
u32 exec_start, exec_len;
u32 seqno;
- u32 mask;
int ret, mode, i;
if (!i915_gem_check_execbuffer(args)) {
@@ -1128,42 +1171,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
}
mode = args->flags & I915_EXEC_CONSTANTS_MASK;
- mask = I915_EXEC_CONSTANTS_MASK;
- switch (mode) {
- case I915_EXEC_CONSTANTS_REL_GENERAL:
- case I915_EXEC_CONSTANTS_ABSOLUTE:
- case I915_EXEC_CONSTANTS_REL_SURFACE:
- if (ring == &dev_priv->ring[RCS] &&
- mode != dev_priv->relative_constants_mode) {
- if (INTEL_INFO(dev)->gen < 4)
- return -EINVAL;
-
- if (INTEL_INFO(dev)->gen > 5 &&
- mode == I915_EXEC_CONSTANTS_REL_SURFACE)
- return -EINVAL;
-
- /* The HW changed the meaning on this bit on gen6 */
- if (INTEL_INFO(dev)->gen >= 6)
- mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
-
- ret = intel_ring_begin(ring, 4);
- if (ret)
- goto err;
-
- intel_ring_emit(ring, MI_NOOP);
- intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
- intel_ring_emit(ring, INSTPM);
- intel_ring_emit(ring, mask << 16 | mode);
- intel_ring_advance(ring);
-
- dev_priv->relative_constants_mode = mode;
- }
- break;
- default:
- DRM_ERROR("execbuf with unknown constants: %d\n", mode);
- ret = -EINVAL;
+ ret = i915_gem_set_constant_offset(ring, mode);
+ if (ret)
goto err;
- }
trace_i915_gem_ring_dispatch(ring, seqno);
--
1.7.7
^ permalink raw reply related
* [PATCH 2/3] drm/i915: Force sync command ordering (Gen6+)
From: Ben Widawsky @ 2011-10-23 2:41 UTC (permalink / raw)
To: intel-gfx; +Cc: Ben Widawsky
In-Reply-To: <1319337685-26195-1-git-send-email-ben@bwidawsk.net>
The docs say this is required for Gen7, and since the bit was added for
Gen6, we are also setting it there pit pf paranoia. Particularly as
Chris points out, if PIPE_CONTROL counts as a 3d state packet.
This was found through doc inspection by Ken and applies to Gen6+;
Cc: Keith Packard <keithp@keithp.com>
Reported-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 +++++++--
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1d66c24..1589a19 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -967,6 +967,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct intel_ring_buffer *ring;
u32 exec_start, exec_len;
u32 seqno;
+ u32 mask;
int ret, mode, i;
if (!i915_gem_check_execbuffer(args)) {
@@ -1127,6 +1128,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
}
mode = args->flags & I915_EXEC_CONSTANTS_MASK;
+ mask = I915_EXEC_CONSTANTS_MASK;
switch (mode) {
case I915_EXEC_CONSTANTS_REL_GENERAL:
case I915_EXEC_CONSTANTS_ABSOLUTE:
@@ -1140,6 +1142,10 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
mode == I915_EXEC_CONSTANTS_REL_SURFACE)
return -EINVAL;
+ /* The HW changed the meaning on this bit on gen6 */
+ if (INTEL_INFO(dev)->gen >= 6)
+ mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
+
ret = intel_ring_begin(ring, 4);
if (ret)
goto err;
@@ -1147,8 +1153,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
intel_ring_emit(ring, MI_NOOP);
intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
intel_ring_emit(ring, INSTPM);
- intel_ring_emit(ring,
- I915_EXEC_CONSTANTS_MASK << 16 | mode);
+ intel_ring_emit(ring, mask << 16 | mode);
intel_ring_advance(ring);
dev_priv->relative_constants_mode = mode;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 138eae1..51569f2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -436,6 +436,7 @@
#define INSTPM_AGPBUSY_DIS (1<<11) /* gen3: when disabled, pending interrupts
will not assert AGPBUSY# and will only
be delivered when out of C3. */
+#define INSTPM_FORCE_ORDERING (1<<7) /* GEN6+ */
#define ACTHD 0x020c8
#define FW_BLC 0x020d8
#define FW_BLC2 0x020dc
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 0e99589..a3c0b13 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -297,6 +297,9 @@ static int init_render_ring(struct intel_ring_buffer *ring)
}
if (INTEL_INFO(dev)->gen >= 6) {
+ I915_WRITE(INSTPM,
+ INSTPM_FORCE_ORDERING << 16 |
+ INSTPM_FORCE_ORDERING);
} else if (IS_GEN5(dev)) {
ret = init_pipe_control(ring);
if (ret)
--
1.7.7
^ permalink raw reply related
* [PATCH 1/3] drm/i915: relative_constants_mode race fix
From: Ben Widawsky @ 2011-10-23 2:41 UTC (permalink / raw)
To: intel-gfx; +Cc: Ben Widawsky
After my refactoring, Chris noticed that we had a bug.
dev_priv keeps track of the current addressing mode that gets set at
execbuffer time. Unfortunately the existing code was doing this before
acquiring struct_mutex which leaves a race with another thread also
doing an execbuffer. If that wasn't bad enough, relocate_slow drops
struct_mutex which opens a much more likely error where another thread
comes in and modifies the state while relocate_slow is being slow.
The solution here is to just defer setting this state until we
absolutely need it, and we know we'll have struct_mutex for the
remainder of our code path.
Cc: Keith Packard <keithp@keithp.com>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 67 ++++++++++++++--------------
1 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3693e83..1d66c24 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1003,39 +1003,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
return -EINVAL;
}
- mode = args->flags & I915_EXEC_CONSTANTS_MASK;
- switch (mode) {
- case I915_EXEC_CONSTANTS_REL_GENERAL:
- case I915_EXEC_CONSTANTS_ABSOLUTE:
- case I915_EXEC_CONSTANTS_REL_SURFACE:
- if (ring == &dev_priv->ring[RCS] &&
- mode != dev_priv->relative_constants_mode) {
- if (INTEL_INFO(dev)->gen < 4)
- return -EINVAL;
-
- if (INTEL_INFO(dev)->gen > 5 &&
- mode == I915_EXEC_CONSTANTS_REL_SURFACE)
- return -EINVAL;
-
- ret = intel_ring_begin(ring, 4);
- if (ret)
- return ret;
-
- intel_ring_emit(ring, MI_NOOP);
- intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
- intel_ring_emit(ring, INSTPM);
- intel_ring_emit(ring,
- I915_EXEC_CONSTANTS_MASK << 16 | mode);
- intel_ring_advance(ring);
-
- dev_priv->relative_constants_mode = mode;
- }
- break;
- default:
- DRM_ERROR("execbuf with unknown constants: %d\n", mode);
- return -EINVAL;
- }
-
if (args->buffer_count < 1) {
DRM_ERROR("execbuf with %d buffers\n", args->buffer_count);
return -EINVAL;
@@ -1159,6 +1126,40 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
}
}
+ mode = args->flags & I915_EXEC_CONSTANTS_MASK;
+ switch (mode) {
+ case I915_EXEC_CONSTANTS_REL_GENERAL:
+ case I915_EXEC_CONSTANTS_ABSOLUTE:
+ case I915_EXEC_CONSTANTS_REL_SURFACE:
+ if (ring == &dev_priv->ring[RCS] &&
+ mode != dev_priv->relative_constants_mode) {
+ if (INTEL_INFO(dev)->gen < 4)
+ return -EINVAL;
+
+ if (INTEL_INFO(dev)->gen > 5 &&
+ mode == I915_EXEC_CONSTANTS_REL_SURFACE)
+ return -EINVAL;
+
+ ret = intel_ring_begin(ring, 4);
+ if (ret)
+ goto err;
+
+ intel_ring_emit(ring, MI_NOOP);
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, INSTPM);
+ intel_ring_emit(ring,
+ I915_EXEC_CONSTANTS_MASK << 16 | mode);
+ intel_ring_advance(ring);
+
+ dev_priv->relative_constants_mode = mode;
+ }
+ break;
+ default:
+ DRM_ERROR("execbuf with unknown constants: %d\n", mode);
+ ret = -EINVAL;
+ goto err;
+ }
+
trace_i915_gem_ring_dispatch(ring, seqno);
exec_start = batch_obj->gtt_offset + args->batch_start_offset;
--
1.7.7
^ permalink raw reply related
* [U-Boot] Congratulations
From: BBC NATIONAL PROMO @ 2011-10-23 2:08 UTC (permalink / raw)
To: u-boot
--
BBC E-MAIL PROMOTION WINNERS NOTICE,
WINNING NOTIFICATION !!!
BBC NATIONAL LOTTERY PROMO
UK HEAD OFFICE.
SUITES 23-30,LION TOWERS
CENTRAL LONDON
ENGLAND,
Your Email Address was selected thereby Winning for you,?1.000,000
(one million
pounds) in the British Broadcasting corporation (BBC) Online Promo
Held on this
month of October 2011,and you are to acknowledge the receipt of this mail with
the details below to.
1.Full name:
2.Tel:
3.Country :
Sincerely,
Mr. Scott Carson
^ permalink raw reply
* Re: [PATCH 15/49] powerpc: irq: Remove IRQF_DISABLED
From: Geoff Levand @ 2011-10-23 1:57 UTC (permalink / raw)
To: Yong Zhang
Cc: linux-kernel, tglx, Benjamin Herrenschmidt, Paul Mackerras,
Arnd Bergmann, linuxppc-dev, cbe-oss-dev
In-Reply-To: <1319277421-9203-16-git-send-email-yong.zhang0@gmail.com>
On Sat, 2011-10-22 at 17:56 +0800, Yong Zhang wrote:
> Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
> We run all interrupt handlers with interrupts disabled
> and we even check and yell when an interrupt handler
> returns with interrupts enabled (see commit [b738a50a:
> genirq: Warn when handler enables interrupts]).
>
> So now this flag is a NOOP and can be removed.
>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/powerpc/include/asm/floppy.h | 4 ++--
> arch/powerpc/include/asm/xics.h | 4 ++--
> arch/powerpc/kernel/smp.c | 2 +-
> arch/powerpc/platforms/cell/beat.c | 2 +-
> arch/powerpc/platforms/cell/celleb_scc_pciex.c | 2 +-
> arch/powerpc/platforms/cell/iommu.c | 3 +--
> arch/powerpc/platforms/cell/pmu.c | 2 +-
> arch/powerpc/platforms/cell/spu_base.c | 9 +++------
> arch/powerpc/platforms/powermac/pic.c | 1 -
> arch/powerpc/platforms/powermac/smp.c | 4 ++--
> arch/powerpc/platforms/ps3/device-init.c | 2 +-
> arch/powerpc/sysdev/mpic.c | 2 --
> arch/powerpc/sysdev/ppc4xx_soc.c | 2 +-
> arch/powerpc/sysdev/xics/xics-common.c | 5 ++---
> 14 files changed, 18 insertions(+), 26 deletions(-)
Looks OK for PS3.
Acked-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: [PATCH 15/49] powerpc: irq: Remove IRQF_DISABLED
From: Geoff Levand @ 2011-10-23 1:57 UTC (permalink / raw)
To: Yong Zhang
Cc: cbe-oss-dev, Arnd Bergmann, linux-kernel, Paul Mackerras, tglx,
linuxppc-dev
In-Reply-To: <1319277421-9203-16-git-send-email-yong.zhang0@gmail.com>
On Sat, 2011-10-22 at 17:56 +0800, Yong Zhang wrote:
> Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
> We run all interrupt handlers with interrupts disabled
> and we even check and yell when an interrupt handler
> returns with interrupts enabled (see commit [b738a50a:
> genirq: Warn when handler enables interrupts]).
>
> So now this flag is a NOOP and can be removed.
>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/powerpc/include/asm/floppy.h | 4 ++--
> arch/powerpc/include/asm/xics.h | 4 ++--
> arch/powerpc/kernel/smp.c | 2 +-
> arch/powerpc/platforms/cell/beat.c | 2 +-
> arch/powerpc/platforms/cell/celleb_scc_pciex.c | 2 +-
> arch/powerpc/platforms/cell/iommu.c | 3 +--
> arch/powerpc/platforms/cell/pmu.c | 2 +-
> arch/powerpc/platforms/cell/spu_base.c | 9 +++------
> arch/powerpc/platforms/powermac/pic.c | 1 -
> arch/powerpc/platforms/powermac/smp.c | 4 ++--
> arch/powerpc/platforms/ps3/device-init.c | 2 +-
> arch/powerpc/sysdev/mpic.c | 2 --
> arch/powerpc/sysdev/ppc4xx_soc.c | 2 +-
> arch/powerpc/sysdev/xics/xics-common.c | 5 ++---
> 14 files changed, 18 insertions(+), 26 deletions(-)
Looks OK for PS3.
Acked-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* [PATCH v2] udf : skip mirror metadata FE since metadata FE is ok.
From: Namjae Jeon @ 2011-10-23 10:28 UTC (permalink / raw)
To: jack; +Cc: linux-kernel, Namjae Jeon
By Jan Kara's suggestion, This patch skip mirror metadata FE since metadata FE is ok. And try to read it only the first time udf_get_pblock_meta25() fails to map the block from metadata FE.
Signed-off-by: Namjae Jeon <linkinjeon@gmail.com>
igned-off-by: Ashish Sangwan <ashishsangwan2@gmail.com>
---
fs/udf/partition.c | 8 +++++-
fs/udf/super.c | 66 +++++++++++++++++++++++++--------------------------
fs/udf/udf_sb.h | 1 +
fs/udf/udfdecl.h | 2 +
4 files changed, 42 insertions(+), 35 deletions(-)
diff --git a/fs/udf/partition.c b/fs/udf/partition.c
index f3e472c..05e71b7 100644
--- a/fs/udf/partition.c
+++ b/fs/udf/partition.c
@@ -321,8 +321,14 @@ uint32_t udf_get_pblock_meta25(struct super_block *sb, uint32_t block,
/* We shouldn't mount such media... */
BUG_ON(!inode);
retblk = udf_try_read_meta(inode, block, partition, offset);
- if (retblk == 0xFFFFFFFF) {
+ if (retblk == 0xFFFFFFFF && mdata->s_metadata_fe) {
udf_warn(sb, "error reading from METADATA, trying to read from MIRROR\n");
+ if (!mdata->s_mirror_load_flag) {
+ mdata->s_mirror_fe = udf_find_metadata_inode_efe(sb,
+ mdata->s_mirror_file_loc, map->s_partition_num);
+ mdata->s_mirror_load_flag = 1;
+ }
+
inode = mdata->s_mirror_fe;
if (!inode)
return 0xFFFFFFFF;
diff --git a/fs/udf/super.c b/fs/udf/super.c
index e58123a..2a26f8d1 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -826,59 +826,57 @@ out1:
return ret;
}
+struct inode *udf_find_metadata_inode_efe(struct super_block *sb,
+ u32 meta_file_loc, u32 partition_num)
+{
+ struct kernel_lb_addr addr;
+ struct inode *metadata_fe;
+
+ addr.logicalBlockNum = meta_file_loc;
+ addr.partitionReferenceNum = partition_num;
+
+ metadata_fe = udf_iget(sb, &addr);
+
+ if (metadata_fe == NULL)
+ udf_warn(sb, "metadata inode efe not found\n");
+ else if (UDF_I(metadata_fe)->i_alloc_type != ICBTAG_FLAG_AD_SHORT) {
+ udf_warn(sb, "metadata inode efe does not have short allocation descriptors!\n");
+ iput(metadata_fe);
+ metadata_fe = NULL;
+ }
+
+ return metadata_fe;
+}
+
static int udf_load_metadata_files(struct super_block *sb, int partition)
{
struct udf_sb_info *sbi = UDF_SB(sb);
struct udf_part_map *map;
struct udf_meta_data *mdata;
struct kernel_lb_addr addr;
- int fe_error = 0;
map = &sbi->s_partmaps[partition];
mdata = &map->s_type_specific.s_metadata;
/* metadata address */
- addr.logicalBlockNum = mdata->s_meta_file_loc;
- addr.partitionReferenceNum = map->s_partition_num;
-
udf_debug("Metadata file location: block = %d part = %d\n",
addr.logicalBlockNum, addr.partitionReferenceNum);
- mdata->s_metadata_fe = udf_iget(sb, &addr);
+ mdata->s_metadata_fe = udf_find_metadata_inode_efe(sb,
+ mdata->s_meta_file_loc, map->s_partition_num);
if (mdata->s_metadata_fe == NULL) {
- udf_warn(sb, "metadata inode efe not found, will try mirror inode\n");
- fe_error = 1;
- } else if (UDF_I(mdata->s_metadata_fe)->i_alloc_type !=
- ICBTAG_FLAG_AD_SHORT) {
- udf_warn(sb, "metadata inode efe does not have short allocation descriptors!\n");
- fe_error = 1;
- iput(mdata->s_metadata_fe);
- mdata->s_metadata_fe = NULL;
- }
-
- /* mirror file entry */
- addr.logicalBlockNum = mdata->s_mirror_file_loc;
- addr.partitionReferenceNum = map->s_partition_num;
-
- udf_debug("Mirror metadata file location: block = %d part = %d\n",
- addr.logicalBlockNum, addr.partitionReferenceNum);
+ /* mirror file entry */
+ udf_debug("Mirror metadata file location: block = %d part = %d\n",
+ addr.logicalBlockNum, addr.partitionReferenceNum);
- mdata->s_mirror_fe = udf_iget(sb, &addr);
+ mdata->s_mirror_fe = udf_find_metadata_inode_efe(sb,
+ mdata->s_mirror_file_loc, map->s_partition_num);
- if (mdata->s_mirror_fe == NULL) {
- if (fe_error) {
- udf_err(sb, "mirror inode efe not found and metadata inode is missing too, exiting...\n");
- goto error_exit;
- } else
- udf_warn(sb, "mirror inode efe not found, but metadata inode is OK\n");
- } else if (UDF_I(mdata->s_mirror_fe)->i_alloc_type !=
- ICBTAG_FLAG_AD_SHORT) {
- udf_warn(sb, "mirror inode efe does not have short allocation descriptors!\n");
- iput(mdata->s_mirror_fe);
- mdata->s_mirror_fe = NULL;
- if (fe_error)
+ if (mdata->s_mirror_fe == NULL) {
+ udf_err(sb, "Both metadata and mirror metadata inode efe can not found\n");
goto error_exit;
+ }
}
/*
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index 4858c19..05025c9 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -61,6 +61,7 @@ struct udf_meta_data {
__u32 s_alloc_unit_size;
__u16 s_align_unit_size;
__u8 s_dup_md_flag;
+ __u8 s_mirror_load_flag;
struct inode *s_metadata_fe;
struct inode *s_mirror_fe;
struct inode *s_bitmap_fe;
diff --git a/fs/udf/udfdecl.h b/fs/udf/udfdecl.h
index 5d8ee8c..4dda1e7 100644
--- a/fs/udf/udfdecl.h
+++ b/fs/udf/udfdecl.h
@@ -135,6 +135,8 @@ static inline void udf_updated_lvid(struct super_block *sb)
UDF_SB(sb)->s_lvid_dirty = 1;
}
extern u64 lvid_get_unique_id(struct super_block *sb);
+struct inode *udf_find_metadata_inode_efe(struct super_block *sb,
+ u32 meta_file_loc, u32 partition_num);
/* namei.c */
extern int udf_write_fi(struct inode *inode, struct fileIdentDesc *,
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 00/22] Refactor to accept NUL in commit messages
From: Nguyen Thai Ngoc Duy @ 2011-10-23 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff, Ævar Arnfjörð
In-Reply-To: <7vobx863v3.fsf@alter.siamese.dyndns.org>
2011/10/23 Junio C Hamano <gitster@pobox.com>:
> I do not think we want to go this route.
>
> There are two possible approaches to attack this.
>
> - If we want to show everything after a potential and rare NUL in the log
> message most of the time, then "struct commit" should just store
> <ptr,len> pair. This grows "struct commit" with one extra ulong.
>
> - If we want to give us a way to notice and show these "funnily, this
> commit log message has a NUL in it" case as an exception in only
> selected codepaths, then "struct commit" should just gain "flags"
> 4-byte int field between "indegree" and "date", and
> parse_commit_buffer() should set one bit in the flags when the log
> message has NUL in it. And teach only these selected codepaths to find
> the length from the object name with sha1_object_info() as needed. This
> grows "struct commit" with one 4-byte int, with runtime overhead only
> where it matters.
>
> The approach taken by the patch wastes two malloc() blocks with their own
> allocation overhead, and unused "alloc" field in the strbuf that does not
> have to be there.
We could allocate just one block with length as the first field:
struct commit_buffer {
unsigned long len;
char buf[FLEX_ARRAY];
};
The downside is commit_buffer field type in struct commit changes,
which impacts many codepaths. If we agree to allow NUL in commit
objects, then all codepaths should be aware of that fact, otherwise
funny things may happen because string processing in this function
stops early due to NUL, but others run fine..
Jeff's low-level normalization approach sounds much simpler, but
probably trickier because we need to identify where to normalize and
denormalize. At least with type change, the compiler spots all the
places for me.
I would not worry about runtime processing overhead. The string end
check is basically converted from "if (*msg)" to "if (msg < msg_end)".
There will one more pointer (msg_end) in stack for each call. Unless
we do deep recursion, we should be fine. Memory overhead is still
something to profile.
--
Duy
^ permalink raw reply
* Kernel Panic every 2 weeks on ISP server (NULL pointer dereference)
From: Luciano Ruete @ 2011-10-23 1:18 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: Text/Plain, Size: 1072 bytes --]
Hi,
I'm the sysadmin at a 3500 customers ISP, wich runs an iptables+tc solution
for load balancing and QoS.
Every 2 or 3 weeks the server panics with a "NULL pointer dereference" and
with IP at "dev_queue_xmit"
It is curious that if i disable MSI on the network card driver this panics
seems to disapear, does this ring a bell?
The server is an IBM, previously with Broadcom NetXtreme II BCM5709 nics and
now with Intel 82576. I change the nics thinking that maybe the bug was in
Broadcom Driver but it seems to affect MSI in general.
The tc+iptables rules are auto-generated with sequreisp[1] an ISP solution
that i wrote and is open sourced under AGPLv3.
Tell me if you need any further information, and plz CC because I'm not
suscribed.
root@server:~# uname -a
Linux server 2.6.35-30-server #60~lucid1-Ubuntu SMP Tue Sep 20 22:28:40 UTC
2011 x86_64 GNU/Linux
[1]https://github.com/sequre/sequreisp
--
Luciano Ruete
Sequre - Sys Admin
Mitre 617, piso 7, of. 1
+54 261 4254894
Mendoza - Argentina
http://www.sequre.com.ar/
http://www.sequreisp.com/
[-- Attachment #2: kern.log.txt --]
[-- Type: text/plain, Size: 12769 bytes --]
BUG: unable to handle kernel NULL pointer dereference at (null)
[694244.692704] IP: [<ffffffff814b48ea>] dev_queue_xmit+0xaa/0x5b0
[694244.763424] PGD 16f369067 PUD 16f368067 PMD 0
[694244.817577] Oops: 0000 [#1] SMP
[694244.857160] last sysfs file: /sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map
[694244.951740] CPU 3
[694244.974623] Modules linked in: xt_mac ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt nf_conntrack_netlink nfnetlink xt_owner ipt_REJECT ipt_REDIRECT ipt_MASQUERADE xt_helper xt_length xt_TCPMSS xt_mark xt_connmark xt_state xt_tcpudp xt_multiport iptable_mangle iptable_nat iptable_filter ip_tables x_tables sch_sfq act_mirred cls_u32 sch_prio cls_fw sch_htb ifb dummy 8021q garp stp nf_nat_irc nf_conntrack_irc nf_nat_sip nf_conntrack_sip nf_nat_pptp nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_proto_gre nf_nat_amanda ts_kmp nf_conntrack_amanda nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack cdc_ether i7core_edac usbnet serio_raw edac_core tpm_tis tpm ioatdma tpm_bios lp shpchp parport mii raid10 raid456 async_pq async_xor xor async_memcpy async_r
aid6_recov megaraid_sas raid6_pq async_tx raid1 raid0 multipath igb dca usbhid hid linear
[694245.905128]
[694245.923881] Pid: 30, comm: events/3 Not tainted 2.6.35-30-server #60~lucid1-Ubuntu 69Y5698 /System x3650 M3 -[7945AC1]-
[694246.057920] RIP: 0010:[<ffffffff814b48ea>] [<ffffffff814b48ea>] dev_queue_xmit+0xaa/0x5b0
[694246.157723] RSP: 0018:ffff880001e63960 EFLAGS: 00010202
[694246.222176] RAX: 0000000000002000 RBX: ffff880145b6f400 RCX: 000000009fe9dec3
[694246.308451] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff88017bd47130
[694246.394725] RBP: ffff880001e639a0 R08: ffff880145b6f400 R09: ffff88017bd47130
[694246.480998] R10: 0000000000000000 R11: 0000000000000003 R12: 0000000000000000
[694246.567265] R13: ffff880118128000 R14: ffff88015c39d300 R15: ffff880001e63b00
[694246.653534] FS: 0000000000000000(0000) GS:ffff880001e60000(0000) knlGS:0000000000000000
[694246.751226] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[694246.820861] CR2: 0000000000000000 CR3: 0000000250400000 CR4: 00000000000006e0
[694246.907128] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[694246.993394] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[694247.079668] Process events/3 (pid: 30, threadinfo ffff880276efe000, task ffff880276ed44d0)
[694247.179433] Stack:
[694247.204410] 0000000000000000 ffff880118128000 ffff880001e639e0 ffff880145b6f400
[694247.291793] <0> 0000000000000000 ffff88015ce2f780 ffff880145b6f400 ffff880001e63b00
[694247.384466] <0> ffff880001e639e0 ffffffff814e9347 ffff880001e63a20 ffff880145b6f400
[694247.479257] Call Trace:
[694247.509424] <IRQ>
[694247.535481] [<ffffffff814e9347>] ip_finish_output+0x237/0x310
[694247.606165] [<ffffffff814e9738>] ip_output+0xb8/0xc0
[694247.667503] [<ffffffff814e75d3>] ? __ip_local_out+0xa3/0xb0
[694247.736114] [<ffffffff814e84c9>] ip_local_out+0x29/0x30
[694247.800566] [<ffffffff814e8ce1>] ip_queue_xmit+0x191/0x3f0
[694247.868129] [<ffffffff814fe484>] tcp_transmit_skb+0x3f4/0x700
[694247.938811] [<ffffffff815002fd>] tcp_send_ack+0xdd/0x130
[694248.004302] [<ffffffff814fc823>] tcp_rcv_synsent_state_process+0x5a3/0x5b0
[694248.088493] [<ffffffff815046bf>] ? tcp_v4_inbound_md5_hash+0x7f/0x210
[694248.167486] [<ffffffff814fcf8d>] tcp_rcv_state_process+0x7d/0x4e0
[694248.242332] [<ffffffff815048f3>] tcp_v4_do_rcv+0xa3/0x1c0
[694248.308864] [<ffffffff81505ab9>] tcp_v4_rcv+0x5a9/0x830
[694248.373314] [<ffffffff814e36a0>] ? ip_local_deliver_finish+0x0/0x290
[694248.451265] [<ffffffff814db384>] ? nf_hook_slow+0x74/0x100
[694248.518830] [<ffffffff814e36a0>] ? ip_local_deliver_finish+0x0/0x290
[694248.596781] [<ffffffff814e377d>] ip_local_deliver_finish+0xdd/0x290
[694248.673696] [<ffffffff814e39b0>] ip_local_deliver+0x80/0x90
[694248.742300] [<ffffffff814e2f29>] ip_rcv_finish+0x119/0x410
[694248.809870] [<ffffffff814e35cd>] ip_rcv+0x23d/0x310
[694248.870167] [<ffffffff814af233>] __netif_receive_skb+0x383/0x5c0
[694248.943960] [<ffffffff814af57b>] process_backlog+0x10b/0x210
[694249.013603] [<ffffffff814b04af>] net_rx_action+0x10f/0x2a0
[694249.081175] [<ffffffff8106862d>] __do_softirq+0xbd/0x200
[694249.146672] [<ffffffff810ca950>] ? handle_IRQ_event+0x50/0x160
[694249.218394] [<ffffffff81068695>] ? __do_softirq+0x125/0x200
[694249.287006] [<ffffffff8100afdc>] call_softirq+0x1c/0x30
[694249.351458] [<ffffffff8100cab5>] do_softirq+0x65/0xa0
[694249.413833] [<ffffffff810684e5>] irq_exit+0x85/0x90
[694249.474131] [<ffffffff815aac85>] do_IRQ+0x75/0xf0
[694249.532352] [<ffffffff815a3853>] ret_from_intr+0x0/0x11
[694249.596797] <EOI>
[694249.622854] [<ffffffff815a3319>] ? _raw_spin_unlock_irqrestore+0x19/0x30
[694249.704961] [<ffffffffa0107826>] ppp_asynctty_receive+0x86/0x100 [ppp_async]
[694249.791233] [<ffffffff81360816>] flush_to_ldisc+0x1a6/0x1e0
[694249.859834] [<ffffffff81360670>] ? flush_to_ldisc+0x0/0x1e0
[694249.928442] [<ffffffff8107b2a5>] run_workqueue+0xc5/0x1a0
[694249.994969] [<ffffffff8107b423>] worker_thread+0xa3/0x110
[694250.061499] [<ffffffff810800d0>] ? autoremove_wake_function+0x0/0x40
[694250.139451] [<ffffffff8107b380>] ? worker_thread+0x0/0x110
[694250.207014] [<ffffffff8107fb56>] kthread+0x96/0xa0
[694250.266274] [<ffffffff8100aee4>] kernel_thread_helper+0x4/0x10
[694250.338002] [<ffffffff8107fac0>] ? kthread+0x0/0xa0
[694250.398296] [<ffffffff8100aee0>] ? kernel_thread_helper+0x0/0x10
[694250.472081] Code: f6 49 c1 e6 07 66 89 93 ac 00 00 00 4d 03 b5 40 03 00 00 0f b7 83 a6 00 00 00 4d 8b 66 08 80 e4 cf 80 cc 20 66 89 83 a6 00 00 00 <49> 83 3c 24 00 0f 84 3b 02 00 00 49 8d 84 24 9c 00 00 00 48 89
[694250.700622] RIP [<ffffffff814b48ea>] dev_queue_xmit+0xaa/0x5b0
[694250.772367] RSP <ffff880001e63960>
[694250.814999] CR2: 0000000000000000
[694250.855923] ---[ end trace 0c85e47af955446e ]---
[694250.912113] Kernel panic - not syncing: Fatal exception in interrupt
[694250.989074] Pid: 30, comm: events/3 Tainted: G D 2.6.35-30-server #60~lucid1-Ubuntu
[694251.090974] Call Trace:
[694251.121208] <IRQ> [<ffffffff815a0597>] panic+0x90/0x113
[694251.154109] ------------[ cut here ]------------
[694251.154118] WARNING: at /build/buildd/linux-lts-backport-maverick-2.6.35/net/sched/sch_generic.c:258 dev_watchdog+0x25f/0x270()
[694251.154121] Hardware name: System x3650 M3 -[7945AC1]-
[694251.154123] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out
[694251.154124] Modules linked in: xt_mac ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt nf_conntrack_netlink nfnetlink xt_owner ipt_REJECT ipt_REDIRECT ipt_MASQUERADE xt_helper xt_length xt_TCPMSS xt_mark xt_connmark xt_state xt_tcpudp xt_multiport iptable_mangle iptable_nat iptable_filter ip_tables x_tables sch_sfq act_mirred cls_u32 sch_prio cls_fw sch_htb ifb dummy 8021q garp stp nf_nat_irc nf_conntrack_irc nf_nat_sip nf_conntrack_sip nf_nat_pptp nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_proto_gre nf_nat_amanda ts_kmp nf_conntrack_amanda nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack cdc_ether i7core_edac usbnet serio_raw edac_core tpm_tis tpm ioatdma tpm_bios lp shpchp parport mii raid10 raid456 async_pq async_xor xor async_memcpy async_r
aid6_recov megaraid_sas raid6_pq async_tx raid1 raid0 multipath igb dca usbhid hid linear
[694251.154174] Pid: 0, comm: swapper Tainted: G D 2.6.35-30-server #60~lucid1-Ubuntu
[694251.154176] Call Trace:
[694251.154178] <IRQ> [<ffffffff8106159f>] warn_slowpath_common+0x7f/0xc0
[694251.154187] [<ffffffff81061696>] warn_slowpath_fmt+0x46/0x50
[694251.154190] [<ffffffff814cd81f>] dev_watchdog+0x25f/0x270
[694251.154200] [<ffffffffa01adc49>] ? destroy_conntrack+0xa9/0xe0 [nf_conntrack]
[694251.154204] [<ffffffff814db1a7>] ? nf_conntrack_destroy+0x17/0x30
[694251.154211] [<ffffffffa01ad264>] ? death_by_timeout+0xd4/0x140 [nf_conntrack]
[694251.154214] [<ffffffff814cd5c0>] ? dev_watchdog+0x0/0x270
[694251.154217] [<ffffffff814cd5c0>] ? dev_watchdog+0x0/0x270
[694251.154221] [<ffffffff81070172>] call_timer_fn+0x42/0x120
[694251.154226] [<ffffffff8105553b>] ? scheduler_tick+0x1db/0x300
[694251.154229] [<ffffffff814cd5c0>] ? dev_watchdog+0x0/0x270
[694251.154232] [<ffffffff81071734>] run_timer_softirq+0x154/0x270
[694251.154236] [<ffffffff8108a683>] ? ktime_get+0x63/0xe0
[694251.154239] [<ffffffff8106862d>] __do_softirq+0xbd/0x200
[694251.154243] [<ffffffff8108fa1a>] ? tick_program_event+0x2a/0x30
[694251.154247] [<ffffffff8100afdc>] call_softirq+0x1c/0x30
[694251.154250] [<ffffffff8100cab5>] do_softirq+0x65/0xa0
[694251.154253] [<ffffffff810684e5>] irq_exit+0x85/0x90
[694251.154258] [<ffffffff815aad70>] smp_apic_timer_interrupt+0x70/0x9b
[694251.154261] [<ffffffff8100aa93>] apic_timer_interrupt+0x13/0x20
[694251.154263] <EOI> [<ffffffff8130ad54>] ? intel_idle+0xe4/0x180
[694251.154271] [<ffffffff8130ad37>] ? intel_idle+0xc7/0x180
[694251.154277] [<ffffffff81488062>] cpuidle_idle_call+0x92/0x140
[694251.154281] [<ffffffff81008d93>] cpu_idle+0xb3/0x110
[694251.154285] [<ffffffff8159b226>] start_secondary+0x100/0x102
[694251.154288] ---[ end trace 0c85e47af955446f ]---
[694251.154389] igb 0000:17:00.0: eth0: Reset adapter
[694251.273081] igb 0000:18:00.0: eth2: Reset adapter
[694254.499174] [<ffffffff815a485a>] oops_end+0xea/0xf0
[694254.559522] [<ffffffff8103e45c>] no_context+0xfc/0x190
[694254.622984] [<ffffffffa0070155>] ? nfnetlink_has_listeners+0x15/0x20 [nfnetlink]
[694254.713470] [<ffffffff8103e615>] __bad_area_nosemaphore+0x125/0x1e0
[694254.790433] [<ffffffff8103e6e3>] bad_area_nosemaphore+0x13/0x20
[694254.863244] [<ffffffff815a711f>] do_page_fault+0x28f/0x350
[694254.930864] [<ffffffff815a3b35>] page_fault+0x25/0x30
[694254.993287] [<ffffffff814b48ea>] ? dev_queue_xmit+0xaa/0x5b0
[694255.062987] [<ffffffff814e9347>] ip_finish_output+0x237/0x310
[694255.133728] [<ffffffff814e9738>] ip_output+0xb8/0xc0
[694255.195123] [<ffffffff814e75d3>] ? __ip_local_out+0xa3/0xb0
[694255.263784] [<ffffffff814e84c9>] ip_local_out+0x29/0x30
[694255.328283] [<ffffffff814e8ce1>] ip_queue_xmit+0x191/0x3f0
[694255.395910] [<ffffffff814fe484>] tcp_transmit_skb+0x3f4/0x700
[694255.466647] [<ffffffff815002fd>] tcp_send_ack+0xdd/0x130
[694255.532185] [<ffffffff814fc823>] tcp_rcv_synsent_state_process+0x5a3/0x5b0
[694255.616423] [<ffffffff815046bf>] ? tcp_v4_inbound_md5_hash+0x7f/0x210
[694255.695489] [<ffffffff814fcf8d>] tcp_rcv_state_process+0x7d/0x4e0
[694255.770377] [<ffffffff815048f3>] tcp_v4_do_rcv+0xa3/0x1c0
[694255.838650] [<ffffffff81505ab9>] tcp_v4_rcv+0x5a9/0x830
[694255.903158] [<ffffffff814e36a0>] ? ip_local_deliver_finish+0x0/0x290
[694255.981164] [<ffffffff814db384>] ? nf_hook_slow+0x74/0x100
[694256.048778] [<ffffffff814e36a0>] ? ip_local_deliver_finish+0x0/0x290
[694256.126783] [<ffffffff814e377d>] ip_local_deliver_finish+0xdd/0x290
[694256.203750] [<ffffffff814e39b0>] ip_local_deliver+0x80/0x90
[694256.272413] [<ffffffff814e2f29>] ip_rcv_finish+0x119/0x410
[694256.340028] [<ffffffff814e35cd>] ip_rcv+0x23d/0x310
[694256.400385] [<ffffffff814af233>] __netif_receive_skb+0x383/0x5c0
[694256.474233] [<ffffffff814af57b>] process_backlog+0x10b/0x210
[694256.543933] [<ffffffff814b04af>] net_rx_action+0x10f/0x2a0
[694256.611549] [<ffffffff8106862d>] __do_softirq+0xbd/0x200
[694256.677096] [<ffffffff810ca950>] ? handle_IRQ_event+0x50/0x160
[694256.748871] [<ffffffff81068695>] ? __do_softirq+0x125/0x200
[694256.817527] [<ffffffff8100afdc>] call_softirq+0x1c/0x30
[694256.882030] [<ffffffff8100cab5>] do_softirq+0x65/0xa0
[694256.944458] [<ffffffff810684e5>] irq_exit+0x85/0x90
[694257.004807] [<ffffffff815aac85>] do_IRQ+0x75/0xf0
[694257.063079] [<ffffffff815a3853>] ret_from_intr+0x0/0x11
[694257.127578] <EOI> [<ffffffff815a3319>] ? _raw_spin_unlock_irqrestore+0x19/0x30
[694257.217120] [<ffffffffa0107826>] ppp_asynctty_receive+0x86/0x100 [ppp_async]
[694257.303447] [<ffffffff81360816>] flush_to_ldisc+0x1a6/0x1e0
[694257.372104] [<ffffffff81360670>] ? flush_to_ldisc+0x0/0x1e0
[694257.440768] [<ffffffff8107b2a5>] run_workqueue+0xc5/0x1a0
[694257.507355] [<ffffffff8107b423>] worker_thread+0xa3/0x110
[694257.573940] [<ffffffff810800d0>] ? autoremove_wake_function+0x0/0x40
[694257.651961] [<ffffffff8107b380>] ? worker_thread+0x0/0x110
[694257.719582] [<ffffffff8107fb56>] kthread+0x96/0xa0
[694257.778897] [<ffffffff8100aee4>] kernel_thread_helper+0x4/0x10
[694257.850666] [<ffffffff8107fac0>] ? kthread+0x0/0xa0
[694257.911018] [<ffffffff8100aee0>] ? kernel_thread_helper+0x0/0x10
[694257.984951] Rebooting in 1 seconds..[ 0.000000] Initializing cgroup subsys cpuset
^ permalink raw reply
* Re: [PATCH] udf : skip mirror metadata FE since metadata FE is ok.
From: NamJae Jeon @ 2011-10-23 1:24 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-kernel, Ashish Sangwan
In-Reply-To: <20111020234703.GI20542@quack.suse.cz>
2011/10/21 Jan Kara <jack@suse.cz>:
> On Thu 20-10-11 00:03:18, Namjae Jeon wrote:
>> By Jan Kara's suggestion, This patch skip mirror metadata FE since
>> metadata FE is ok. And try to read it only the first time
>> udf_get_pblock_meta25() fails to map the block from metadata FE.
>>
>> Signed-off-by: Namjae Jeon <linkinjeon@gmail.com>
>> Signed-off-by: Ashish Sangwan <ashishsangwan2@gmail.com>
>> ---
>> fs/udf/partition.c | 20 ++++++++++++++++++++
>> fs/udf/super.c | 33 ++++++++++++++++-----------------
>> 2 files changed, 36 insertions(+), 17 deletions(-)
>>
>> diff --git a/fs/udf/partition.c b/fs/udf/partition.c
>> index f3e472c..8bfc25b 100644
>> --- a/fs/udf/partition.c
>> +++ b/fs/udf/partition.c
>> @@ -311,6 +311,7 @@ uint32_t udf_get_pblock_meta25(struct super_block *sb, uint32_t block,
>> struct udf_meta_data *mdata;
>> uint32_t retblk;
>> struct inode *inode;
>> + struct kernel_lb_addr addr;
>>
>> udf_debug("READING from METADATA\n");
>>
>> @@ -323,6 +324,25 @@ uint32_t udf_get_pblock_meta25(struct super_block *sb, uint32_t block,
>> retblk = udf_try_read_meta(inode, block, partition, offset);
>> if (retblk == 0xFFFFFFFF) {
>> udf_warn(sb, "error reading from METADATA, trying to read from MIRROR\n");
>> + if (mdata->s_mirror_fe == NULL) {
> This won't be good because if s_mirror_fe cannot be loaded as well, you'd
> just try loading it on every block mapping which failed from the primary
> metadata map. So you should have a flag somewhere whether in mdata, whether
> you tried loading mirror_fe or not and use that.
>
>> + /* mirror file entry */
>> + addr.logicalBlockNum = mdata->s_mirror_file_loc;
>> + addr.partitionReferenceNum = map->s_partition_num;
>> + udf_debug("Mirror metadata file location: block = %d part = %d\n",
>> + addr.logicalBlockNum,
>> + addr.partitionReferenceNum);
>> + mdata->s_mirror_fe = udf_iget(sb, &addr);
>> +
>> + if (mdata->s_mirror_fe == NULL)
>> + udf_err(sb, "mirror inode efe not found");
>> + else if (UDF_I(mdata->s_mirror_fe)->i_alloc_type !=
>> + ICBTAG_FLAG_AD_SHORT) {
>> + udf_warn(sb, "mirror inode efe does not have short allocation descriptors!\n");
>> + iput(mdata->s_mirror_fe);
>> + mdata->s_mirror_fe = NULL;
>> + }
> Also please create a helper function for loading metadata/mirror metadat
> FE so that we don't have loading duplicated in three places... Thanks.
Hi Jan.
Thanks for your review.
I will do it.
>
> Honza
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
>
^ permalink raw reply
* Re: [PATCH] udf : skip mirror metadata FE since metadata FE is ok.
From: NamJae Jeon @ 2011-10-23 1:24 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-kernel, Ashish Sangwan
In-Reply-To: <20111020234703.GI20542@quack.suse.cz>
2011/10/21 Jan Kara <jack@suse.cz>:
> On Thu 20-10-11 00:03:18, Namjae Jeon wrote:
>> By Jan Kara's suggestion, This patch skip mirror metadata FE since
>> metadata FE is ok. And try to read it only the first time
>> udf_get_pblock_meta25() fails to map the block from metadata FE.
>>
>> Signed-off-by: Namjae Jeon <linkinjeon@gmail.com>
>> Signed-off-by: Ashish Sangwan <ashishsangwan2@gmail.com>
>> ---
>> fs/udf/partition.c | 20 ++++++++++++++++++++
>> fs/udf/super.c | 33 ++++++++++++++++-----------------
>> 2 files changed, 36 insertions(+), 17 deletions(-)
>>
>> diff --git a/fs/udf/partition.c b/fs/udf/partition.c
>> index f3e472c..8bfc25b 100644
>> --- a/fs/udf/partition.c
>> +++ b/fs/udf/partition.c
>> @@ -311,6 +311,7 @@ uint32_t udf_get_pblock_meta25(struct super_block *sb, uint32_t block,
>> struct udf_meta_data *mdata;
>> uint32_t retblk;
>> struct inode *inode;
>> + struct kernel_lb_addr addr;
>>
>> udf_debug("READING from METADATA\n");
>>
>> @@ -323,6 +324,25 @@ uint32_t udf_get_pblock_meta25(struct super_block *sb, uint32_t block,
>> retblk = udf_try_read_meta(inode, block, partition, offset);
>> if (retblk == 0xFFFFFFFF) {
>> udf_warn(sb, "error reading from METADATA, trying to read from MIRROR\n");
>> + if (mdata->s_mirror_fe == NULL) {
> This won't be good because if s_mirror_fe cannot be loaded as well, you'd
> just try loading it on every block mapping which failed from the primary
> metadata map. So you should have a flag somewhere whether in mdata, whether
> you tried loading mirror_fe or not and use that.
>
>> + /* mirror file entry */
>> + addr.logicalBlockNum = mdata->s_mirror_file_loc;
>> + addr.partitionReferenceNum = map->s_partition_num;
>> + udf_debug("Mirror metadata file location: block = %d part = %d\n",
>> + addr.logicalBlockNum,
>> + addr.partitionReferenceNum);
>> + mdata->s_mirror_fe = udf_iget(sb, &addr);
>> +
>> + if (mdata->s_mirror_fe == NULL)
>> + udf_err(sb, "mirror inode efe not found");
>> + else if (UDF_I(mdata->s_mirror_fe)->i_alloc_type !=
>> + ICBTAG_FLAG_AD_SHORT) {
>> + udf_warn(sb, "mirror inode efe does not have short allocation descriptors!\n");
>> + iput(mdata->s_mirror_fe);
>> + mdata->s_mirror_fe = NULL;
>> + }
> Also please create a helper function for loading metadata/mirror metadat
> FE so that we don't have loading duplicated in three places... Thanks.
Hi Jan.
Thanks for your review.
I will do it.
>
> Honza
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
>
^ permalink raw reply
* [Bug 42090] New: [r300/compiler] [bisected] sauerbraten texture corruption
From: bugzilla-daemon @ 2011-10-23 0:51 UTC (permalink / raw)
To: dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=42090
Bug #: 42090
Summary: [r300/compiler] [bisected] sauerbraten texture
corruption
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: fabio.ped@libero.it
CC: tstellar@gmail.com
Fabio Pedretti <fabio.ped@libero.it> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tstellar@gmail.com
Monsters in sauerbraten have missing textures. I bisected and got:
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
163629fd05166b78d70c2c26f4a922b296e8999d
0dc97e7fd49a5b8db25b95a1020fc598dba5cf65
We cannot bisect more!
the first introduce an all screen corruption, the second change it to missing
textures in monsters.
My chip:
r300: DRM version: 2.9.0, Name: ATI RV530, ID: 0x71c5, GB: 1, Z: 2
r300: GART size: 509 MB, VRAM size: 256 MB
r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: YES
--- Comment #1 from Tom Stellard <tstellar@gmail.com> 2011-10-22 17:51:52 PDT ---
Created attachment 52640
--> https://bugs.freedesktop.org/attachment.cgi?id=52640
Possible fix
Does this patch fix the problem?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH] mmc: boot partition ro lock support
From: Sebastian Rasmussen @ 2011-10-23 0:51 UTC (permalink / raw)
To: Chris Ball
Cc: Linus Walleij, Andrei Warkentin, Ulf Hansson, Per Forlin,
Lee Jones, Johan Rudholm, John Beckett, linux-mmc
In-Reply-To: <m2vcrh55lm.fsf@bob.laptop.org>
Hi!
> What we're worried about is someone issuing the perm read-only command,
> and not realizing that it really means that they can never ever write
> any more changes to their eMMC -- it's a one-time fuse
I can see why you are worried that people may brick their devices.
How about only adding the read-only-until-power-cycled command?
> I'd rather leave it to specialized manufacturing equipment.
Sure, but then again permanent read-only commands seem to be
able to be sent by writing a userspace tool that issues a ioctl(fd, 0xb3, ...)
using the generic command interface by John Calixto mentioned by
Andrei. I assume that what reassures you in this case is
that CAP_SYS_RAWIO is required and perhaps also obscurity?
/ Sebastian
^ permalink raw reply
* Re: Linux 3.1-rc10
From: Linus Torvalds @ 2011-10-23 0:47 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Linux Kernel Mailing List
In-Reply-To: <9983.1319261492@turing-police.cc.vt.edu>
On Sat, Oct 22, 2011 at 8:31 AM, <Valdis.Kletnieks@vt.edu> wrote:
>
> Actually, the question was "Are there enough Linus cycles to do KS
> and all the merges in 2 weeks?". ;)
I think there will be.
The kernel summit is only two days, and then I have another day of
LinuxCon Europe, and basically a day of travel. So it's four days out
of the 2 weeks, and I can actually do the time-consuming part of the
merges while traveling (ie *looking* at them if I need to: the
technical merge action itself is usually never the problem).
Additionally, the first few days (which is KS/etc), I'll probably be
merging mainly from people who have already got k.org accounts because
they got into the trust network early, so it's going to be slightly
limited by the fact that it will invariably take some time to get the
gpg signing and k.org account setup a day or two.
So I'm not horribly worried.
What worries me more than the kernel summit is just that the 3.1
release cycle has dragged out longer than usual, so I'm a bit afraid
that the 3.2 merge window will just be more chaotic than usual just
because there might be more stuff there to be merged. But that's
independent of any KS issues, and I also suspect that the added time
for development has been largely nullified by the productivity lost
due to the k.org mess.
linux-next is pretty large, but I don't track historical sizes all
that well, so I can't say if it's noticeably larger than it usually
is. Stephen may know, but he's on vacation right now.
So we'll see.
Linus
^ permalink raw reply
* (no subject)
From: Correa Angelique @ 2011-10-23 0:40 UTC (permalink / raw)
Dear beneficiary,
This is to re-notify you of the $300,000.00 USD that was deposited
here in the western union office in your name is available for pickup.
Contact us via email for your M.T.C.N Numbers.
Contact Person:Mr. Allen Williams
Email:mrallenwilliams@live.com
Tel. +447024037299
^ permalink raw reply
* Re: SCSI HA problems
From: Stan Hoeppner @ 2011-10-23 0:26 UTC (permalink / raw)
To: Emmanuel Florac; +Cc: Michael Robbert, linux-scsi@vger.kernel.org
In-Reply-To: <20111022105046.5ab4e3e9@galadriel.home>
On 10/22/2011 3:50 AM, Emmanuel Florac wrote:
> Le Fri, 21 Oct 2011 18:08:37 -0600 vous écriviez:
>> So, my question is this, is this setup technically possible or are
>> the 2 HBAs going to conflict with each other when talking over the
>> same SAS bus to the SATA drives?
>
> Your explanation lacks important information, like the hardware in use
> (controllers, jbods, drives, cabling, etc), kernel version, RAID ( is it
> linux software RAID you're using?) etc. However:
>
> First, you shouldn't be using desktop drives because it's extremely
> dangerous (search the web and you'll find countless horror stories of
> catastrophic failures, particularly with WD desktop drives).
Agreed. Particularly the "Green" drives from any manufacturer. Keep in
mind that when a "home brew" system of this nature takes a catastrophic
nose dive, you may spend a couple of days or more trying to hunt down
the problem and fix it. And therein lies the rub: cheap SATA drives
will drop en masse from arrays, inexplicably, and will test good in
isolation on the bench. Now what? The problem isn't the drives but the
entire low cost architecture. The only fix it to replace _everything_
if you want it to be reliable. Or, fix it by avoiding such a thing in
the first place. Use "enterprise" quality SAS or SATA drives from day
one, and use a good quality SAS controller, such as LSI.
> Second, normally for SAS HA configuration, you must use SAS drives; the
> main difference being that SAS drives have dual attachment, and can
> manage commands coming from dual sources (controllers). SATA drives
> lack the second path and can't be reliably driven from 2 different
> controllers at once, unless you added a SAS to SATA adapter to them.
>
> Third, your SAS controller must be able to work in multi-host
> configuration. Most PCIe SAS controllers (3Ware, Adaptec, Areca,
> HighPoint) can't do that at all. AFAIK only some LSI controllers are
> multi-host aware, and this is a software option you must buy in
> addition to the controller.
You'll also want, if not outright need, an SAS switch, such as the LSI
SAS6160. Runs about $2000 USD from resellers. You'll also want a
quality JBOD chassis w/expander at about $2k each.
> Fourth, for a dual attachment you need to use both SAS data path to
> both hosts, which would quickly make clear you can't use SATA drives
> (because they'll simply won't show up at all on the second path).
Which is why hardware RAID enclosures and cluster filesystems and/or NFS
servers are much more popular than this type of shared SAS cluster.
> Fifth, if you're actually using linux md raid driver, I don't think
> it to be in any manner multi-host capable. So that would be a
> definitive dead end.
Yep.
> My advice : the only reliable way to achieve HA using SATA drives and
> common SAS controllers is to use DRDB or some similar replication
> mechanism. Yes, that means you'll need a second JBOD and twice the
> number of drives. But it will _just_ _work_, both with hardware or
> software RAID.
I see it as the only way to get away with using cheap SATA drives (which
I still wouldn't recommend). If this is a lab exercise that's one
thing. If this will be a production system, stay away from consumer
class drives.
> If necessary, you may need a pair of 10 Ge or IB cards for data
> synchronisation between hosts to perform well enough. Modern hardware
> can easily replicate over DRBD at several hundred MB per second.
The replication link bandwidth depends entirely on the target
application and expected filesystem bandwidth required, which the OP
didn't state IIRC. That omission leads me to believe this is a research
project/exercise, with no actual goal to realize.
> Don't forget : "cheap, good, fast: choose two." In the case of large,
> important, valuable data, "good" isn't really an option you may go
> without anyway.
Good advice.
--
Stan
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Sebastian Rasmussen @ 2011-10-23 0:31 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, linux-arm-kernel, Lee Jones, Russell King - ARM Linux
In-Reply-To: <CAKnu2MrOriMzJH9NcwUivWa0cinASa6wrRf4a69si4WUs-aTrQ@mail.gmail.com>
Hi!
> Err, no. You're not allowed to power down the card between commands
> unless the card has been removed or been has finished with.
>
> If you power down the card (which you _are_ doing by writing zero to
> the MMCIPOWER register), then you have to do a full setup of the card
> when you resume.
MCIPower is according to ARM PL180 TRM signalling to an external power
supply to turn on/off (MCIPWR), whether to use open-drain (MCIROD),
what voltage to use (MCIVDD) and whether the card is clocked (MCICLK).
According ST-Ericsson's public PL180 derivative spec[1] it seems to work
roughly in same way (but renaming the register SDI_PWR and the signals
SDIPWR & SDICLK). However, there is no SDIVDD as the derivative can not
signal desired voltage level externally (there are no bits in SDI_PWR for this).
This makes it plausible that SDIPWR may not be routed externally either.
Can you verify this as there are no signal routing diagrams in the spec..?
This leads me to believe that writing 0 to SDI_PWR/MMC in actual practice
doesn't really do much but disabling the clock to the card (and for
ST-Ericsson's PL180, disable direction signalling to the external level
shifter). Clearing bit 8 of MCIClock/SDI_CLKCR also disables the clock.
I guess the patch would appeal more to Russell if mmci_runtime_suspend()
only cleared MCIMask0/SDI_MASK0 and MCIClock/SDI_CLKCR and left
MCIPower/SDI_PWR unchanged. It may be the case that the signal direction
bits need to be cleared for the ST-Ericsson PL180, but I haven't yet verified
this on my Snowball dev board yet.
/ Sebastian
[1] http://www.stericsson.com/developers/DM00030004_AP9500_reference_manual_rev1.pdf
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Sebastian Rasmussen @ 2011-10-23 0:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKnu2MrOriMzJH9NcwUivWa0cinASa6wrRf4a69si4WUs-aTrQ@mail.gmail.com>
Hi!
> Err, no. You're not allowed to power down the card between commands
> unless the card has been removed or been has finished with.
>
> If you power down the card (which you _are_ doing by writing zero to
> the MMCIPOWER register), then you have to do a full setup of the card
> when you resume.
MCIPower is according to ARM PL180 TRM signalling to an external power
supply to turn on/off (MCIPWR), whether to use open-drain (MCIROD),
what voltage to use (MCIVDD) and whether the card is clocked (MCICLK).
According ST-Ericsson's public PL180 derivative spec[1] it seems to work
roughly in same way (but renaming the register SDI_PWR and the signals
SDIPWR & SDICLK). However, there is no SDIVDD as the derivative can not
signal desired voltage level externally (there are no bits in SDI_PWR for this).
This makes it plausible that SDIPWR may not be routed externally either.
Can you verify this as there are no signal routing diagrams in the spec..?
This leads me to believe that writing 0 to SDI_PWR/MMC in actual practice
doesn't really do much but disabling the clock to the card (and for
ST-Ericsson's PL180, disable direction signalling to the external level
shifter). Clearing bit 8 of MCIClock/SDI_CLKCR also disables the clock.
I guess the patch would appeal more to Russell if mmci_runtime_suspend()
only cleared MCIMask0/SDI_MASK0 and MCIClock/SDI_CLKCR and left
MCIPower/SDI_PWR unchanged. It may be the case that the signal direction
bits need to be cleared for the ST-Ericsson PL180, but I haven't yet verified
this on my Snowball dev board yet.
/ Sebastian
[1] http://www.stericsson.com/developers/DM00030004_AP9500_reference_manual_rev1.pdf
^ permalink raw reply
* Re: Profiling sleep times?
From: Arun Sharma @ 2011-10-23 0:27 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Peter Zijlstra, Ingo Molnar, avagin, linux-perf-users, acme,
Stephane Eranian
In-Reply-To: <20111022104947.GB2811@somewhere.feld.cvut.cz>
On 10/22/11 3:49 AM, Frederic Weisbecker wrote:
> That's not only a problem of semantics although that alone is a problem,
> people will seldom read the documentation for corner cases, we should
> really stay consistant here: if remote callchains are really needed, we
> want a specific interface for that, not abusing the existing one that would
> only confuse people.
A separate interface sounds good.
>
> Now I still think doing remote callchains is asking for troubles: we need to
> ensure the target is really sleeping and is not going to be scheduled
> concurrently otherwise you might get weird or stale results. So the user needs
> to know which tracepoints are safe to perform this.
I expect this interface to be used in a small number of well known
places in the kernel.
[...]
>
> I think we should use something like a perf report plugin: perhaps something
> that can create a virtual event on top of real ones: compute the sched:sched_switch
> events, find the time tasks are sleeping and create virtual sleep events on top
> of that with a period weighted with the sleep time.
> Just a thought.
Right - whether we're doing wall-clock profiling or sleep profiling,
it'll involve looking at multiple real events.
I still see one problem with doing: perf record -ag -e <bunch of events>
and trying to sort through what happened. Unprivileged users who don't
have permissions to system wide profiling, but have privileges to
profile their own processes get locked out of this feature.
-Arun
^ permalink raw reply
* Re: [PATCH] x86: Fix compilation bug in kprobes' twobyte_is_boostable
From: Linus Torvalds @ 2011-10-23 0:25 UTC (permalink / raw)
To: Josh Stone
Cc: linux-kernel, Masami Hiramatsu, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, Srikar Dronamraju, Jakub Jelinek
In-Reply-To: <1319229182-32226-1-git-send-email-jistone@redhat.com>
On Fri, Oct 21, 2011 at 11:33 PM, Josh Stone <jistone@redhat.com> wrote:
> When compiling an i386_defconfig kernel with gcc-4.6.1-9.fc15.i686, I
> noticed a warning about the asm operand for test_bit in kprobes'
> can_boost. I discovered that this caused only the first long of
> twobyte_is_boostable[] to be output.
>
> Jakub filed and fixed gcc PR50571 to correct the warning and this output
> issue. But to solve it for less current gcc, we can make kprobes'
> twobyte_is_boostable[] volatile, and it won't be optimized out.
Hmm. I'd *much* rather do this in arch/x86/include/asm/bitops.h
instead, methinks.
Also, rather than your
> See also my more general fix, https://lkml.org/lkml/2011/10/6/412
wouldn't the simple fix be just to add the volatile there to the cast
we already do, ie something like the appended (cut-and-paste, so it's
whitespace-damaged, but you get the idea).
Now, I'm the first to say that I hate volatile, and I'm not entirely
happy about the cast there, but (a) we're casting a volatile pointer
to begin with, and (b) it's essentially the same thing that we do for
the inline asms that modify the bit (see the "ADDR" macro, which also
handles some gcc versioning issues).
And I don't mind volatile in code nearly as much as I mind volatile on
the data structures (it's one of my "C typing was misdesigned" pet
peeves: I think "volatile" is about the access, not about the data)
Does this fix the gcc problem too?
Historical notes:
- We *used* to have a volatile there (and a whole base address and
"tell gcc which word changed" mess) up until commit eb2b4e682a6 ("x86:
revert commit 709f744 ("x86: bitops asm constraint fixes")"). We
reverted the base address mess, but we probably should have kept the
"volatile".
- Long long ago, we had that "big array" approach for ADDR too. So
we've wavered between the volatile and using a block memory op. But
we've used the "volatile" for a long time now for the bit change ones,
so I don't think we should mix concepts like your patch.
Comments? Does the simple 'volatile' approach also fix the problem?
Linus
---
arch/x86/include/asm/bitops.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 1775d6e5920e..87f000d9377e 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -319,7 +319,7 @@ static inline int variable_test_bit(int nr, volatile const u
asm volatile("bt %2,%1\n\t"
"sbb %0,%0"
: "=r" (oldbit)
- : "m" (*(unsigned long *)addr), "Ir" (nr));
+ : "m" (*(volatile unsigned long *)addr), "Ir" (nr));
return oldbit;
}
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 4/7] target-arm: Add ARM UDIV/SDIV support
From: Andreas Färber @ 2011-10-23 0:20 UTC (permalink / raw)
To: Peter Maydell; +Cc: Anthony Liguori, qemu-devel
In-Reply-To: <1319116568-2663-5-git-send-email-peter.maydell@linaro.org>
Am 20.10.2011 15:16, schrieb Peter Maydell:
> Add support for UDIV and SDIV in ARM mode. This is a new optional
> feature for A profile cores (Thumb mode has had UDIV and SDIV for
> M profile cores for some time).
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Lightly ...
Tested-by: Andreas Färber <andreas.faerber@web.de>
Andreas
> ---
> target-arm/cpu.h | 1 +
> target-arm/helper.c | 5 ++++-
> target-arm/translate.c | 19 +++++++++++++++++++
> 3 files changed, 24 insertions(+), 1 deletions(-)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 00e012e..af3904d 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -375,6 +375,7 @@ enum arm_features {
> ARM_FEATURE_V5,
> ARM_FEATURE_STRONGARM,
> ARM_FEATURE_VAPA, /* cp15 VA to PA lookups */
> + ARM_FEATURE_ARM_DIV, /* divide supported in ARM encoding */
> };
>
> static inline int arm_feature(CPUARMState *env, int feature)
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index faf0283..3a51fd7 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -207,7 +207,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
> set_feature(env, ARM_FEATURE_VFP_FP16);
> set_feature(env, ARM_FEATURE_NEON);
> set_feature(env, ARM_FEATURE_THUMB2EE);
> - set_feature(env, ARM_FEATURE_THUMB_DIV);
> + set_feature(env, ARM_FEATURE_ARM_DIV);
> set_feature(env, ARM_FEATURE_V7MP);
> break;
> case ARM_CPUID_TI915T:
> @@ -261,6 +261,9 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
> if (arm_feature(env, ARM_FEATURE_V7)) {
> set_feature(env, ARM_FEATURE_VAPA);
> }
> + if (arm_feature(env, ARM_FEATURE_ARM_DIV)) {
> + set_feature(env, ARM_FEATURE_THUMB_DIV);
> + }
> }
>
> void cpu_reset(CPUARMState *env)
> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index deb0bcf..812a9e7 100644
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -7639,6 +7639,25 @@ static void disas_arm_insn(CPUState * env, DisasContext *s)
> store_reg(s, rn, tmp);
> }
> break;
> + case 1:
> + case 3:
> + /* SDIV, UDIV */
> + if (!arm_feature(env, ARM_FEATURE_ARM_DIV)) {
> + goto illegal_op;
> + }
> + if (((insn >> 5) & 7) || (rd != 15)) {
> + goto illegal_op;
> + }
> + tmp = load_reg(s, rm);
> + tmp2 = load_reg(s, rs);
> + if (insn & (1 << 21)) {
> + gen_helper_udiv(tmp, tmp, tmp2);
> + } else {
> + gen_helper_sdiv(tmp, tmp, tmp2);
> + }
> + tcg_temp_free_i32(tmp2);
> + store_reg(s, rn, tmp);
> + break;
> default:
> goto illegal_op;
> }
^ permalink raw reply
* [Bug 42117] R200 driver performance, UMS, all mesa versions from 7.6
From: bugzilla-daemon @ 2011-10-23 0:10 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-42117-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42117
majkell10@interia.pl changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|high |medium
Summary|r200 driver performance, |R200 driver performance,
|ums, all mesa versions from |UMS, all mesa versions from
|7.6 |7.6
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [Bug 42117] r200 driver performance, ums, all mesa versions from 7.6
From: bugzilla-daemon @ 2011-10-23 0:05 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-42117-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42117
majkell10@interia.pl changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|medium |high
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 3/7] target-arm: Rename ARM_FEATURE_DIV to _THUMB_DIV
From: Andreas Färber @ 2011-10-23 0:04 UTC (permalink / raw)
To: Peter Maydell; +Cc: Anthony Liguori, qemu-devel
In-Reply-To: <1319116568-2663-4-git-send-email-peter.maydell@linaro.org>
Am 20.10.2011 15:16, schrieb Peter Maydell:
> Rename the ARM_FEATURE_DIV feature bit to _THUMB_DIV, to
> make room for a new feature switch enabling DIV in the ARM
> encoding. (Cores may implement either (a) no divide insns
> (b) divide insns in Thumb encodings only (c) divide insns
> in both ARM and Thumb encodings.)
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Andreas Färber <andreas.faerber@web.de>
Andreas
> ---
> target-arm/cpu.h | 2 +-
> target-arm/helper.c | 4 ++--
> target-arm/translate.c | 3 ++-
> 3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 6ab780d..00e012e 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -366,7 +366,7 @@ enum arm_features {
> ARM_FEATURE_VFP3,
> ARM_FEATURE_VFP_FP16,
> ARM_FEATURE_NEON,
> - ARM_FEATURE_DIV,
> + ARM_FEATURE_THUMB_DIV, /* divide supported in Thumb encoding */
> ARM_FEATURE_M, /* Microcontroller profile. */
> ARM_FEATURE_OMAPCP, /* OMAP specific CP15 ops handling. */
> ARM_FEATURE_THUMB2EE,
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 17ef98b..faf0283 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -193,7 +193,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
> set_feature(env, ARM_FEATURE_THUMB2);
> set_feature(env, ARM_FEATURE_V7);
> set_feature(env, ARM_FEATURE_M);
> - set_feature(env, ARM_FEATURE_DIV);
> + set_feature(env, ARM_FEATURE_THUMB_DIV);
> break;
> case ARM_CPUID_ANY: /* For userspace emulation. */
> set_feature(env, ARM_FEATURE_V4T);
> @@ -207,7 +207,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
> set_feature(env, ARM_FEATURE_VFP_FP16);
> set_feature(env, ARM_FEATURE_NEON);
> set_feature(env, ARM_FEATURE_THUMB2EE);
> - set_feature(env, ARM_FEATURE_DIV);
> + set_feature(env, ARM_FEATURE_THUMB_DIV);
> set_feature(env, ARM_FEATURE_V7MP);
> break;
> case ARM_CPUID_TI915T:
> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index e99fc18..deb0bcf 100644
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -8513,8 +8513,9 @@ static int disas_thumb2_insn(CPUState *env, DisasContext *s, uint16_t insn_hw1)
> tmp2 = load_reg(s, rm);
> if ((op & 0x50) == 0x10) {
> /* sdiv, udiv */
> - if (!arm_feature(env, ARM_FEATURE_DIV))
> + if (!arm_feature(env, ARM_FEATURE_THUMB_DIV)) {
> goto illegal_op;
> + }
> if (op & 0x20)
> gen_helper_udiv(tmp, tmp, tmp2);
> else
^ permalink raw reply
* [Bug 42117] r200 driver performance, ums, all mesa versions from 7.6
From: bugzilla-daemon @ 2011-10-23 0:02 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-42117-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #1 from majkell10@interia.pl 2011-10-22 17:02:42 PDT ---
With KMS enabled, problem does not exists.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ 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.