* Re: kernel BUG at include/linux/kvm_host.h:603!
From: Jörg Sommer @ 2011-10-31 10:28 UTC (permalink / raw)
To: Alexander Graf; +Cc: Avi Kivity, Marcelo Tosatti, kvm list, kvm-ppc
In-Reply-To: <A3DF1AA5-63A6-45BE-9708-8BE07E24EDA5@suse.de>
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
Hi Alexander,
Alexander Graf hat am Mon 10. Oct, 10:09 (+0200) geschrieben:
> On 07.10.2011, at 23:10, Jörg Sommer wrote:
>
> > Hi,
> >
> > I've got this backtrace:
> >
> > [130902.709711] ------------[ cut here ]------------
> > [130902.709747] kernel BUG at include/linux/kvm_host.h:603!
>
> Ouch. This means that preemption is broken in KVM for PPC. To quickly
> get things working on your side, please recompile your kernel with
> CONFIG_PREEMPT_NONE. I'll take a look at fixing it for real ASAP.
Did you look for it? I still get this message for 3.1.0-02829.
Bye, Jörg.
--
Es gibt nichts schöneres als dem Schweigen eines Dummkopfes zuzuhören.
(Helmut Quatlinger)
[-- Attachment #2: Digital signature http://en.wikipedia.org/wiki/OpenPGP --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [alternative-merged] oom-do-not-live-lock-on-frozen-tasks.patch removed from -mm tree
From: akpm @ 2011-10-31 10:30 UTC (permalink / raw)
To: mhocko, kamezawa.hiroyu, khlebnikov, rientjes, rjw, mm-commits
The patch titled
Subject: oom: do not live lock on frozen tasks
has been removed from the -mm tree. Its filename was
oom-do-not-live-lock-on-frozen-tasks.patch
This patch was dropped because an alternative patch was merged
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Michal Hocko <mhocko@suse.cz>
Subject: oom: do not live lock on frozen tasks
Konstantin Khlebnikov has reported (https://lkml.org/lkml/2011/8/23/45)
that OOM can end up in a live lock if select_bad_process picks up a frozen
task.
Unfortunately we cannot mark such processes as unkillable to ignore them
because we could panic the system even though there is a chance that
somebody could thaw the process so we can make a forward process (e.g. a
process from another cpuset or with a different nodemask).
Let's thaw an OOM selected frozen process right after we've sent fatal
signal from oom_kill_task.
Thawing is safe if the frozen task doesn't access any suspended device
(e.g. by ioctl) on the way out to the userspace where we handle the
signal and die. Note, we are not interested in the kernel threads because
they are not oom killable.
Accessing suspended devices by a userspace processes shouldn't be an issue
because devices are suspended only after userspace is already frozen and
oom is disabled at that time.
Other than that userspace accesses the fridge only from the signal
handling routines so we are able to handle SIGKILL without any negative
side effects or we always check for pending signals after we return from
try_to_freeze (e.g. in lguest).
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Reported-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/oom_kill.c | 5 +++++
1 file changed, 5 insertions(+)
diff -puN mm/oom_kill.c~oom-do-not-live-lock-on-frozen-tasks mm/oom_kill.c
--- a/mm/oom_kill.c~oom-do-not-live-lock-on-frozen-tasks
+++ a/mm/oom_kill.c
@@ -462,10 +462,15 @@ static int oom_kill_task(struct task_str
task_pid_nr(q), q->comm);
task_unlock(q);
force_sig(SIGKILL, q);
+
+ if (frozen(q))
+ thaw_process(q);
}
set_tsk_thread_flag(p, TIF_MEMDIE);
force_sig(SIGKILL, p);
+ if (frozen(p))
+ thaw_process(p);
return 0;
}
_
Patches currently in -mm which might be from mhocko@suse.cz are
origin.patch
linux-next.patch
mm-compaction-trivial-clean-up-in-acct_isolated.patch
mm-change-isolate-mode-from-define-to-bitwise-type.patch
mm-compaction-make-isolate_lru_page-filter-aware.patch
mm-compaction-make-isolate_lru_page-filter-aware-fix.patch
mm-zone_reclaim-make-isolate_lru_page-filter-aware.patch
mm-zone_reclaim-make-isolate_lru_page-filter-aware-fix.patch
mm-migration-clean-up-unmap_and_move.patch
mm-page-writebackc-make-determine_dirtyable_memory-static-again.patch
oom-avoid-killing-kthreads-if-they-assume-the-oom-killed-threads-mm.patch
mm-vmscan-drop-nr_force_scan-from-get_scan_count.patch
mm-mmapc-eliminate-the-ret-variable-from-mm_take_all_locks.patch
cgroup-kmemleak-annotate-alloc_page-for-cgroup-allocations.patch
memcg-rename-mem-variable-to-memcg.patch
memcg-fix-oom-schedule_timeout.patch
memcg-do-not-expose-uninitialized-mem_cgroup_per_node-to-world.patch
memcg-close-race-between-charge-and-putback.patch
oom-thaw-threads-if-oom-killed-thread-is-frozen-before-deferring.patch
^ permalink raw reply
* Re: bigalloc and max file size
From: Tao Ma @ 2011-10-31 10:27 UTC (permalink / raw)
To: Theodore Tso
Cc: Andreas Dilger, linux-ext4 development, Alex Zhuravlev,
hao.bigrat@gmail.com
In-Reply-To: <A0C1821A-B597-4617-BD14-B638143DC3C2@mit.edu>
On 10/31/2011 06:15 PM, Theodore Tso wrote:
>
> On Oct 27, 2011, at 11:31 PM, Tao Ma wrote:
>
>> Forget to say, if we increase the extent length to be cluster, there are
>> also a good side effect. ;) Current bigalloc has a severe performance
>> regression in the following test case:
>> mount -t ext4 /dev/sdb1 /mnt/ext4
>> cp linux-3.0.tar.gz /mnt/ext4
>> cd /mnt/ext4
>> tar zxvf linux-3.0.tar.gz
>> umount /mnt/ext4
>
> I've been traveling, so I haven't had a chance to test this, but it makes no sense that changing the encoding fro the extent length would change the performance of the forced writeback caused by amount. There may be a performance bug that we should fix, or may have been fixed by accident with the extent encoding change.
>
> Have you investigated why this got better when you changed the meaning of the extent length field? It makes no sense that such a format change would have such an impact….
OK, so let me explain why the big cluster length works.
In the new bigalloc case if chunk size=64k, and with the linux-3.0
source, every file will be allocated a chunk, but they aren't contiguous
if we only write the 1st 4k bytes. In this case, writeback and the block
layer below can't merge all the requests sent by ext4. And in our test
case, the total io will be around 20000. While with the cluster size, we
have to zero the whole cluster. From the upper point of view. we have to
write more bytes. But from the block layer, the write is contiguous and
it can merge them to be a big one. In our test, it will only do around
2000 ios. So it helps the test case.
Thanks
Tao
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" 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: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API
From: Avi Kivity @ 2011-10-31 10:27 UTC (permalink / raw)
To: Anthony Liguori, qemu-devel, Blue Swirl
In-Reply-To: <20111031003658.GC9698@truffala.fritz.box>
On 10/31/2011 02:36 AM, David Gibson wrote:
> >
> > There is no direct use of signed arithmetic in the API (just in the
> > implementation). Aliases can cause a region to move in either the
> > positive or negative direction, and this requires either signed
> > arithmetic or special casing the two directions.
>
> You keep saying we need signed arithmetic for this, but it's not
> really true. *If* you see aliases as shifting the entire aliases
> address space w.r.t., then just allowing a window to show through, you
> get negative offsets, yes, but that's by no means the only way t think
> about it.
Obviously it's not the only way. We could insert checks for the
direction, and for overflow/underflow. But I am looking for the most
reliable way to prevent similar issues from popping up. There have been
at least three bugs in this area.
If we can use a heavy hammer here, it is worthwhile IMO. Sorry for
being a little trollish, but I much prefer replacing function calls with
infix operators, than getting a CVE for some overflow.
> It's basically one spot - the alias handling in render_memory_region()
> - that generates a negative start intermediate. I'm convinced it's
> pretty straightforward to remove this - making a patch for it just
> hasn't bubbled to the top of my priority queue, though.
We keep adding, subtracting, and comparing stuff everywhere. I am
fairly certain that you are right and there are no other trouble spot,
but I am not absolutely sure, and I would like to be.
> > Signed arithmetic is not the only motivation - overflow is another.
> > Nothing prevents a user from placing a 64-bit 4k BAR at address
> > ffff_ffff_ffff_f000; we could move to base/limit representation, but
> > that will likely cause its own bugs. Finally, we should be able to
> > represent both a 0-sized region and a 2^64 sized region.
>
> Note that an (inclusive) start/end representation also cannot
> represent a 0 sized region.
Right. In theory we shouldn't generate zero sized regions, but can we
trust call device code not to do that?
Also, start/end or off-by-one size are easy to get wrong since C
programmers assume half-inclusive regions.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: kernel panic on device removal when using a workqueue and delayed_work
From: Frank Schäfer @ 2011-10-31 10:26 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20111031031136.GA18057@zhy>
Am 31.10.2011 04:11, schrieb Yong Zhang:
> On Sun, Oct 30, 2011 at 08:19:10PM +0100, Frank Sch�fer wrote:
>> Hi,
>>
>> with the following simple kernel module, I have a good chance to get
>> a kernel panic when I unplug the device:
>>
>>
>> #include<linux/workqueue.h>
>> #include<linux/usb.h>
>> #include<linux/module.h>
>>
>> MODULE_AUTHOR("Nobody");
>> MODULE_DESCRIPTION("example driver for causing kernel panic");
>> MODULE_LICENSE("GPL");
>>
>> static struct delayed_work poll_work;
>>
>> static void poll(struct work_struct *work)
>> {
>> schedule_delayed_work(&poll_work,
>> msecs_to_jiffies(100));
>> }
>>
>> static int test_probe(struct usb_interface *intf,
>> const struct usb_device_id *id)
>> {
>> INIT_DELAYED_WORK(&poll_work, poll);
>> schedule_delayed_work(&poll_work,
>> msecs_to_jiffies(100));
>> return 0;
>> }
>>
>> static void test_disconnect(struct usb_interface *intf)
>> {
>> cancel_delayed_work_sync(&poll_work);
>> }
...
>> static const struct usb_device_id device_table[] = {
>> {USB_DEVICE(0x1234, 0x5678)},
>> {}
>> };
>>
>> MODULE_DEVICE_TABLE(usb, device_table);
>>
>> static struct usb_driver test_driver = {
>> .name = "test",
>> .id_table = device_table,
>> .probe = test_probe,
>> .disconnect = test_disconnect,
>> };
>>
>> static int __init test_mod_init(void)
>> {
>> return usb_register(&test_driver);
>> }
>>
>> static void __exit test_mod_exit(void)
>> {
>> usb_deregister(&test_driver);
>> }
>>
>> module_init(test_mod_init);
>> module_exit(test_mod_exit);
>>
>>
>>
>>
>> A picture of the backtrace (the machine immediately turns off
>> without saving a backtrace) can be found at
>>
>> http://imageshack.us/photo/my-images/823/img075gv.jpg
>>
>> Kernel version is 3.1.0.
>>
>>
>> This is the first time I'm using a workqueue, so there is a good
>> chance that I missed something...
> You should cancel the work you have armed before exit.
> See cancel_delayed_work().
That's what I'm doing (see above).
Did you read the code ? ;-)
Regards,
Frank Schaefer
>> Or is this a kernel bug ?
> I don't think so.
>
> Thanks,
> Yong
^ permalink raw reply
* Re: [PATCH v2 1/3] nl80211: Add probe response offload attribute
From: Luciano Coelho @ 2011-10-31 10:04 UTC (permalink / raw)
To: Guy Eilam; +Cc: johannes, linux-wireless
In-Reply-To: <1319313081-28722-1-git-send-email-guy@wizery.com>
On Sat, 2011-10-22 at 21:51 +0200, Guy Eilam wrote:
> Notify the userspace of the probe response offloading
> support by the driver.
>
> Signed-off-by: Guy Eilam <guy@wizery.com>
> ---
> v2:
> use struct wiphy instead of a function pointer
> this change made the previous second PATCH:
> "Get the probe response offloading support from the driver" irrelevant
> changed WPS to WSC
>
> include/linux/nl80211.h | 24 ++++++++++++++++++++++++
> include/net/cfg80211.h | 5 +++++
> net/wireless/nl80211.c | 5 +++++
> 3 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
> index 9d797f2..c1f0a3d 100644
> --- a/include/linux/nl80211.h
> +++ b/include/linux/nl80211.h
> @@ -1109,6 +1109,11 @@ enum nl80211_commands {
> * %NL80211_CMD_TDLS_MGMT. Otherwise %NL80211_CMD_TDLS_OPER should be
> * used for asking the driver to perform a TDLS operation.
> *
> + * @NL80211_ATTR_PROBE_RESP_OFFLOAD_SUPPORT: Indicates the support
> + * of probe response offloading by the driver/firmware.
> + * In addition this attribute holds a bitmap of the supported protocols
> + * for offloading using &enum nl80211_probe_resp_offload_support_attr.
> + *
> * @NL80211_ATTR_MAX: highest attribute number currently defined
> * @__NL80211_ATTR_AFTER_LAST: internal use
> */
> @@ -1337,6 +1342,8 @@ enum nl80211_attrs {
> NL80211_ATTR_TDLS_SUPPORT,
> NL80211_ATTR_TDLS_EXTERNAL_SETUP,
>
> + NL80211_ATTR_PROBE_RESP_OFFLOAD_SUPPORT,
> +
I'm not sure I understand why we need this. Why aren't the flags
themselves enough?
Johannes wrote, on a separate thread:
> Oh, and probably a regular WIPHY flag that indicates whether the
> attribute should be added at all so that it can also be 0 but present
> (presence with 0 value indicates something other than not present).
What would be the meaning when the WIPHY flag is set but the attributes
are all 0? Wouldn't it mean that we don't support probe_resp offload at
all? Or would it mean that we support probe_resp offloading in normal
cases (ie. not WCS nor P2P)? If the latter is the case, why not add a
bit in the attributes to indicate that "normal" probe_resp offloading is
supported? I think this would be cleaner because there wouldn't be any
implicit semantics.
--
Cheers,
Luca.
^ permalink raw reply
* Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]
From: Christian Brunner @ 2011-10-31 10:25 UTC (permalink / raw)
To: Josef Bacik, Sage Weil, linux-btrfs
In-Reply-To: <CAO47_-8YGAxoYOBRKxLP2HULqEtV5bMugzzybq3srCVFZczgGA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3269 bytes --]
2011/10/31 Christian Brunner <chb@muc.de>:
> 2011/10/31 Christian Brunner <chb@muc.de>:
>>
>> The patch didn't hurt, but I've to tell you that I'm still seeing the
>> same old problems. Load is going up again:
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 5502 root 20 0 0 0 0 S 52.5 0.0 106:29.97 btrfs-endio-wri
>> 1976 root 20 0 601m 211m 1464 S 28.3 0.9 115:10.62 ceph-osd
>>
>> And I have hit our warning again:
>>
>> [223560.970713] ------------[ cut here ]------------
>> [223560.976043] WARNING: at fs/btrfs/inode.c:2118
>> btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]()
>> [223560.985411] Hardware name: ProLiant DL180 G6
>> [223560.990491] Modules linked in: btrfs zlib_deflate libcrc32c sunrpc
>> bonding ipv6 sg serio_raw pcspkr ghes hed iTCO_wdt iTCO_vendor_support
>> i7core_edac edac_core ixgbe dca mdio iomemory_vsl(P) hpsa squashfs
>> [last unloaded: scsi_wait_scan]
>> [223561.014748] Pid: 2079, comm: ceph-osd Tainted: P
>> 3.0.6-1.fits.9.el6.x86_64 #1
>> [223561.023874] Call Trace:
>> [223561.026738] [<ffffffff8106344f>] warn_slowpath_common+0x7f/0xc0
>> [223561.033564] [<ffffffff810634aa>] warn_slowpath_null+0x1a/0x20
>> [223561.040272] [<ffffffffa0282120>] btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]
>> [223561.048278] [<ffffffffa027ce55>] commit_fs_roots+0xc5/0x1b0 [btrfs]
>> [223561.055534] [<ffffffff8154c231>] ? mutex_lock+0x31/0x60
>> [223561.061666] [<ffffffffa027ddbe>]
>> btrfs_commit_transaction+0x3ce/0x820 [btrfs]
>> [223561.069876] [<ffffffffa027d1b8>] ? wait_current_trans+0x28/0x110 [btrfs]
>> [223561.077582] [<ffffffffa027e325>] ? join_transaction+0x25/0x250 [btrfs]
>> [223561.085065] [<ffffffff81086410>] ? wake_up_bit+0x40/0x40
>> [223561.091251] [<ffffffffa025a329>] btrfs_sync_fs+0x59/0xd0 [btrfs]
>> [223561.098187] [<ffffffffa02abc65>] btrfs_ioctl+0x495/0xd50 [btrfs]
>> [223561.105120] [<ffffffff8125ed20>] ? inode_has_perm+0x30/0x40
>> [223561.111575] [<ffffffff81261a2c>] ? file_has_perm+0xdc/0xf0
>> [223561.117924] [<ffffffff8117086a>] do_vfs_ioctl+0x9a/0x5a0
>> [223561.124072] [<ffffffff81170e11>] sys_ioctl+0xa1/0xb0
>> [223561.129842] [<ffffffff81555702>] system_call_fastpath+0x16/0x1b
>> [223561.136699] ---[ end trace 176e8be8996f25f6 ]---
>
> [ Not sending this to the lists, as the attachment is large ].
>
> I've spent a little time to do some tracing with ftrace. Its output
> seems to be right (at least as far as I can tell). I hope that its
> output can give you an insight on whats going on.
>
> The interesting PIDs in the trace are:
>
> 5502 root 20 0 0 0 0 S 33.6 0.0 118:28.37 btrfs-endio-wri
> 5518 root 20 0 0 0 0 S 29.3 0.0 41:23.58 btrfs-endio-wri
> 8059 root 20 0 400m 48m 2756 S 8.0 0.2 8:31.56 ceph-osd
> 7993 root 20 0 401m 41m 2808 S 13.6 0.2 7:58.38 ceph-osd
>
[ adding linux-btrfs again ]
I've been digging into this a bit further:
Attached is another ftrace report that I've filtered for "btrfs_*"
calls and limited to CPU0 (this is where PID 5502 was running).
>From what I can see there is a lot of time consumed in
btrfs_reserve_extent(). I this normal?
Thanks,
Christian
[-- Attachment #2: ftrace_btrfs_cpu0.bz2 --]
[-- Type: application/x-bzip2, Size: 19541 bytes --]
^ permalink raw reply
* [PATCH] wl12xx: add vifs_state debugfs key
From: Eliad Peller @ 2011-10-31 10:24 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
Add debugfs key to dump information regarding the
active vifs (similar to the driver_state debugfs key)
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/wl12xx/debugfs.c | 110 +++++++++++++++++++++++++++++++++
1 files changed, 110 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/debugfs.c b/drivers/net/wireless/wl12xx/debugfs.c
index a9e0b73..2e14b43 100644
--- a/drivers/net/wireless/wl12xx/debugfs.c
+++ b/drivers/net/wireless/wl12xx/debugfs.c
@@ -385,6 +385,115 @@ static const struct file_operations driver_state_ops = {
.llseek = default_llseek,
};
+static ssize_t vifs_state_read(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct wl1271 *wl = file->private_data;
+ struct wl12xx_vif *wlvif;
+ int ret, res = 0;
+ const int buf_size = 4096;
+ char *buf;
+ char tmp_buf[64];
+
+ buf = kzalloc(buf_size, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ mutex_lock(&wl->mutex);
+
+#define VIF_STATE_PRINT(x, fmt) \
+ (res += scnprintf(buf + res, buf_size - res, \
+ #x " = " fmt "\n", wlvif->x))
+
+#define VIF_STATE_PRINT_LONG(x) VIF_STATE_PRINT(x, "%ld")
+#define VIF_STATE_PRINT_INT(x) VIF_STATE_PRINT(x, "%d")
+#define VIF_STATE_PRINT_STR(x) VIF_STATE_PRINT(x, "%s")
+#define VIF_STATE_PRINT_LHEX(x) VIF_STATE_PRINT(x, "0x%lx")
+#define VIF_STATE_PRINT_LLHEX(x) VIF_STATE_PRINT(x, "0x%llx")
+#define VIF_STATE_PRINT_HEX(x) VIF_STATE_PRINT(x, "0x%x")
+
+#define VIF_STATE_PRINT_NSTR(x, len) \
+ do { \
+ memset(tmp_buf, 0, sizeof(tmp_buf)); \
+ memcpy(tmp_buf, wlvif->x, \
+ min_t(u8, len, sizeof(tmp_buf) - 1)); \
+ res += scnprintf(buf + res, buf_size - res, \
+ #x " = %s\n", tmp_buf); \
+ } while (0)
+
+ wl12xx_for_each_wlvif(wl, wlvif) {
+ VIF_STATE_PRINT_INT(role_id);
+ VIF_STATE_PRINT_INT(bss_type);
+ VIF_STATE_PRINT_LHEX(flags);
+ VIF_STATE_PRINT_INT(p2p);
+ VIF_STATE_PRINT_INT(dev_role_id);
+ VIF_STATE_PRINT_INT(dev_hlid);
+
+ if (wlvif->bss_type == BSS_TYPE_STA_BSS ||
+ wlvif->bss_type == BSS_TYPE_IBSS) {
+ VIF_STATE_PRINT_INT(sta.hlid);
+ VIF_STATE_PRINT_INT(sta.ba_rx_bitmap);
+ VIF_STATE_PRINT_INT(sta.basic_rate_idx);
+ VIF_STATE_PRINT_INT(sta.ap_rate_idx);
+ VIF_STATE_PRINT_INT(sta.p2p_rate_idx);
+ } else {
+ VIF_STATE_PRINT_INT(ap.global_hlid);
+ VIF_STATE_PRINT_INT(ap.bcast_hlid);
+ VIF_STATE_PRINT_LHEX(ap.sta_hlid_map[0]);
+ VIF_STATE_PRINT_INT(ap.mgmt_rate_idx);
+ VIF_STATE_PRINT_INT(ap.bcast_rate_idx);
+ VIF_STATE_PRINT_INT(ap.ucast_rate_idx[0]);
+ VIF_STATE_PRINT_INT(ap.ucast_rate_idx[1]);
+ VIF_STATE_PRINT_INT(ap.ucast_rate_idx[2]);
+ VIF_STATE_PRINT_INT(ap.ucast_rate_idx[3]);
+ }
+ VIF_STATE_PRINT_INT(last_tx_hlid);
+ VIF_STATE_PRINT_LHEX(links_map[0]);
+ VIF_STATE_PRINT_NSTR(ssid, wlvif->ssid_len);
+ VIF_STATE_PRINT_INT(band);
+ VIF_STATE_PRINT_INT(channel);
+ VIF_STATE_PRINT_HEX(bitrate_masks[0]);
+ VIF_STATE_PRINT_HEX(bitrate_masks[1]);
+ VIF_STATE_PRINT_HEX(basic_rate_set);
+ VIF_STATE_PRINT_HEX(basic_rate);
+ VIF_STATE_PRINT_HEX(rate_set);
+ VIF_STATE_PRINT_INT(beacon_int);
+ VIF_STATE_PRINT_INT(default_key);
+ VIF_STATE_PRINT_INT(aid);
+ VIF_STATE_PRINT_INT(session_counter);
+ VIF_STATE_PRINT_INT(ps_poll_failures);
+ VIF_STATE_PRINT_INT(psm_entry_retry);
+ VIF_STATE_PRINT_INT(power_level);
+ VIF_STATE_PRINT_INT(rssi_thold);
+ VIF_STATE_PRINT_INT(last_rssi_event);
+ VIF_STATE_PRINT_INT(ba_support);
+ VIF_STATE_PRINT_INT(ba_allowed);
+ VIF_STATE_PRINT_LLHEX(tx_security_seq);
+ VIF_STATE_PRINT_INT(tx_security_last_seq_lsb);
+ }
+
+#undef VIF_STATE_PRINT_INT
+#undef VIF_STATE_PRINT_LONG
+#undef VIF_STATE_PRINT_HEX
+#undef VIF_STATE_PRINT_LHEX
+#undef VIF_STATE_PRINT_LLHEX
+#undef VIF_STATE_PRINT_STR
+#undef VIF_STATE_PRINT_NSTR
+#undef VIF_STATE_PRINT
+
+ mutex_unlock(&wl->mutex);
+
+ ret = simple_read_from_buffer(user_buf, count, ppos, buf, res);
+ kfree(buf);
+ return ret;
+}
+
+static const struct file_operations vifs_state_ops = {
+ .read = vifs_state_read,
+ .open = wl1271_open_file_generic,
+ .llseek = default_llseek,
+};
+
static ssize_t dtim_interval_read(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -765,6 +874,7 @@ static int wl1271_debugfs_add_files(struct wl1271 *wl,
DEBUGFS_ADD(gpio_power, rootdir);
DEBUGFS_ADD(start_recovery, rootdir);
DEBUGFS_ADD(driver_state, rootdir);
+ DEBUGFS_ADD(vifs_state, rootdir);
DEBUGFS_ADD(dtim_interval, rootdir);
DEBUGFS_ADD(beacon_interval, rootdir);
DEBUGFS_ADD(beacon_filtering, rootdir);
--
1.7.6.401.g6a319
^ permalink raw reply related
* Re: [RESEND PATCH 1/14] staging/media/as102: initial import from Abilis
From: Sylwester Nawrocki @ 2011-10-31 10:24 UTC (permalink / raw)
To: Piotr Chmura
Cc: Mauro Carvalho Chehab, Devin Heitmueller, Stefan Richter, Greg KH,
Patrick Dickey, LMML, devel
In-Reply-To: <4EADBBB7.7070802@poczta.onet.pl>
On 10/30/2011 10:03 PM, Piotr Chmura wrote:
> W dniu 18.10.2011 21:46, Piotr Chmura pisze:
>> Patch taken from http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/
>>
>> Changes made by me:
>> 1. Driver moved from media/dvb to staging/media
>> 2. Removed Makefile/Kconfig - it doesn't compile in current tree
> (...)
>> +
>> +/*
>> + * Note:
>> + * - in AS102 SNR=MER
>> + * - the SNR will be returned in linear terms, i.e. not in dB
>> + * - the accuracy equals ±2dB for a SNR range from 4dB to 30dB
>> + * - the accuracy is>2dB for SNR values outside this range
>> + */
>
> I found another issue here.
> In this comment "±" is from upper ASCII (0xF1). Should I change it into sth.
> like "+/-" in this patch (1/14) or leave it and just resend without "Â"
> (wasn't there in original patch, don't know where it came from) ?
I collected all your patches (1..14/14, as we agreed in private), did a bit of
cleanup myself, re-edited the changelogs and I'm going to post the series which
is hopefully ready for initial pull into staging/media. I've also removed that
odd  character right from the first patch.
>
> Peter
>
> P.S. Thanks to Sylwester Nawrocki for pointing me out, that there is something
> wrong with patch 6/14, which was caused by this comment in 1/14.
---
Regards,
Sylwester
^ permalink raw reply
* [Qemu-devel] [PATCH 2/2] softfloat: Avoid uint16 type conflict on Darwin
From: Andreas Färber @ 2011-10-31 10:23 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Maydell, Andreas Färber, Juan Pineda
In-Reply-To: <1320056616-295-1-git-send-email-andreas.faerber@web.de>
In file included from ./bswap.h:7,
from ./qemu-common.h:106,
from ./qemu-aio.h:17,
from ./Block.h:4,
from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/FSEvents.h:28,
from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:218,
from /System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20,
from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21,
from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:17,
from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:81,
from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
from ui/cocoa.m:25:
/Users/andreas/QEMU/qemu/fpu/softfloat.h:60: error: conflicting types for ‘uint16’
/System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:73: error: previous declaration of ‘uint16’ was here
make: *** [ui/cocoa.o] Error 1
Apple's FSEvents.h has #include <Block.h>, which wants
/usr/include/Block.h but due to case-insensitive file system and
include path jungle gets QEMU's ./block.h, which in turn includes
softfloat.h indirectly.
Therefore work around the conflict in softfloat.h itself
by renaming specifically uint16 on Darwin to qemu_uint16.
This fixes the build until we have a more general solution.
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Cc: Juan Pineda <juan@logician.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
---
fpu/softfloat.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fpu/softfloat.h b/fpu/softfloat.h
index 07c2929..5320945 100644
--- a/fpu/softfloat.h
+++ b/fpu/softfloat.h
@@ -54,6 +54,9 @@ these four paragraphs for those parts of this code that are retained.
| to the same as `int'.
*----------------------------------------------------------------------------*/
typedef uint8_t flag;
+#ifdef __APPLE__
+#define uint16 qemu_uint16
+#endif
typedef uint8_t uint8;
typedef int8_t int8;
#ifndef _AIX
--
1.7.0.3
^ permalink raw reply related
* [Qemu-devel] [PATCH 1/2] MAINTAINERS: Add Cocoa maintainer
From: Andreas Färber @ 2011-10-31 10:23 UTC (permalink / raw)
To: qemu-devel; +Cc: Andreas Färber, Anthony Liguori
In-Reply-To: <1320056616-295-1-git-send-email-andreas.faerber@web.de>
Degrade cocoa.m from Maintained to Odd Fixes.
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Cc: Anthony Liguori <aliguori@us.ibm.com>
---
MAINTAINERS | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2b4c5d7..c08951c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -446,6 +446,11 @@ M: Anthony Liguori <aliguori@us.ibm.com>
S: Maintained
F: ui/
+Cocoa graphics
+M: Andreas Färber <andreas.faerber@web.de>
+S: Odd Fixes
+F: ui/cocoa.m
+
Main loop
M: Anthony Liguori <aliguori@us.ibm.com>
S: Supported
--
1.7.0.3
^ permalink raw reply related
* [Qemu-devel] [PATCH 0/2] Cocoa patches for 1.0
From: Andreas Färber @ 2011-10-31 10:23 UTC (permalink / raw)
To: qemu-devel; +Cc: Andreas Färber, Juan Pineda
[Seems they didn't make it to the list yesterday]
Hello,
Here's two Cocoa patches I'd like to see pulled into 1.0.
First, documenting the de facto maintainer.
Second, fixing the build.
Since qemu-system-* crashes after selecting an image file,
I can only say that Juan's sheet patch compiles and would like
to postpone it until it actually makes a difference. Unless Juan
or someone has a use case that works on master.
Regards,
Andreas
Cc: Juan Pineda <juan@logician.com>
Andreas Färber (2):
MAINTAINERS: Add Cocoa maintainer
softfloat: Avoid uint16 type conflict on Darwin
MAINTAINERS | 5 +++++
fpu/softfloat.h | 3 +++
2 files changed, 8 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: bigalloc and max file size
From: Theodore Tso @ 2011-10-31 10:22 UTC (permalink / raw)
To: i
Cc: Theodore Tso, Andreas Dilger, linux-ext4 development,
Alex Zhuravlev, Tao Ma, hao.bigrat@gmail.com
In-Reply-To: <4EAE6BD4.9080705@coly.li>
On Oct 31, 2011, at 5:35 AM, Coly Li wrote:
>
> Back to our topic, Ext4 doesn't have too much on-disk incompatible flag-bits now. If we get current bigalloc code merged now, we have to use another incompatible bit when we merge cluster/chunk based extent patch set.
What is the appeal to you have the cluster/chunk based extent patch set? I'm not sure I understand why it's so interesting to you in the first place. Ext4's RAID support isn't particularly good, and its sweet spot really is for single disk file systems. And for cluster file systems, such as when you might build Hadoop on top of ext4, there's no real advantage of using RAID arrays as opposed to having single file systems on each disk. In fact, due to the specd of being able to check multiple disk spindles in parallel, it's advantageous to build cluster file systems on single disk file systems.
I'm just curious what your use case is, because that tends to drive decision decisions in subtle ways.
Regards,
-- Ted
^ permalink raw reply
* Re: [PATCH 1/3] dmaengine: Allow controller drivers to set channel ids
From: Viresh Kumar @ 2011-10-31 10:22 UTC (permalink / raw)
To: Dan
Cc: Vinod Koul, linux-kernel@vger.kernel.org, Armando VISCONTI,
Shiraz HASHIM, Vipin KUMAR, Rajeev KUMAR, Deepak SIKRI,
Vipul Kumar SAMAR, Amit VIRDI, Pratyush ANAND, Bhupesh SHARMA,
viresh.linux@gmail.com, Bhavna YADAV
In-Reply-To: <1318571018.1546.383.camel@vkoul-udesk3>
On 10/14/2011 11:13 AM, Vinod Koul wrote:
>> > Hi Vinod/Dan,
>> >
>> > Any update/feedback on this?
> Since this touches non slave stuff as well, I need Dan to ack it first
Hi Dan,
Can you please provide some comments on this.
--
viresh
^ permalink raw reply
* Re: [PATCH 0/1] virtio: console: fix for early console
From: Amit Shah @ 2011-10-31 10:21 UTC (permalink / raw)
To: Rusty Russell; +Cc: Christian Borntraeger, kvm list, Virtualization List
In-Reply-To: <cover.1316715093.git.amit.shah@redhat.com>
On (Thu) 22 Sep 2011 [23:44:22], Amit Shah wrote:
> Hi Rusty,
>
> This is a fix from Christian for early console handling with multiport
> support. Please apply.
>
> Christian, I've made some changes to the patch as noted in the commit
> message. Nothing major, but an ACK would be nice.
>
> Thanks.
Hey Rusty can you push this fix for 3.2?
Thanks
Amit
^ permalink raw reply
* Re: [PATCH 0/1] virtio: console: fix for early console
From: Amit Shah @ 2011-10-31 10:21 UTC (permalink / raw)
To: Rusty Russell; +Cc: Christian Borntraeger, kvm list, Virtualization List
In-Reply-To: <cover.1316715093.git.amit.shah@redhat.com>
On (Thu) 22 Sep 2011 [23:44:22], Amit Shah wrote:
> Hi Rusty,
>
> This is a fix from Christian for early console handling with multiport
> support. Please apply.
>
> Christian, I've made some changes to the patch as noted in the commit
> message. Nothing major, but an ACK would be nice.
>
> Thanks.
Hey Rusty can you push this fix for 3.2?
Thanks
Amit
^ permalink raw reply
* Re: Multi-partition block layer behaviour
From: Tiju Jacob @ 2011-10-31 10:21 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <CANejiEVxdX7KC6MFqBZ2azPtETmwJXML6v1L5-kq+UrRTmf+Tg@mail.gmail.com>
>> ok, thanks. So this means the elevator is switching in the test. How
>> about below patch:
>>
>> diff --git a/block/elevator.c b/block/elevator.c
>> index a3b64bc..e14824a 100644
>> --- a/block/elevator.c
>> +++ b/block/elevator.c
>> @@ -683,8 +683,13 @@ void __elv_add_request(struct request_queue *q, struct request *rq, int where)
>> * - Usually, back inserted requests won't be merged
>> * with anything. There's no point in delaying queue
>> * processing.
>> + * If elevator is switching, doesn't need run the queue.
>> + * elevator switching will run it anyway. And this could
>> + * cause warning since the code might run in atomic
>> + * environment(blk_flush_plug_list() callbed in schedule())
>> */
>> - __blk_run_queue(q);
>> + if (!test_bit(QUEUE_FLAG_ELVSWITCH, &q->queue_flags))
>> + __blk_run_queue(q);
>> break;
>>
>> case ELEVATOR_INSERT_SORT_MERGE:
>>
>>
> oh, wait. We should have no this issue with latest kernel, because
> blk_schedule_flush_plug is moved out of schedule atomic environment. please
> try a latest kernel, for example, 3.1.
>
Even after applying the above patch, I am getting the same error. We
have to use the linux 3.0.* kernel series. So is there a fix for the
3.0 series?
We'll defenetly check with the 3.1 kernel and let know.
Thanks,
--TJ
^ permalink raw reply
* Re: [PATCH 0/8] virtio: console: Fixes, cleanups, stats for bytes transferred
From: Amit Shah @ 2011-10-31 10:19 UTC (permalink / raw)
To: Rusty Russell; +Cc: Juan Quintela, Virtualization List
In-Reply-To: <cover.1315985553.git.amit.shah@redhat.com>
On (Wed) 14 Sep 2011 [13:06:38], Amit Shah wrote:
> Hello,
>
> These patches are mostly cleanups (patches 1, 4, 5, 6, 7). Patches 2
> and 3 fix cases which will be exposed when S4 support is enabled.
>
> Patch 8 adds stats for bytes received, sent and discarded for each
> port. These are added for debugging data loss issues (rather,
> pointing out they don't exist). Closing a port while data transfer is
> ongoing resulted in discarding of any pending data in the vq, which is
> the expected case. Adding these stats just helps showing there's no
> data loss, but things are working as they were designed.
>
> Please apply.
Hey Rusty,
Can you push this series to Linus for 3.2? Thanks!
Amit
^ permalink raw reply
* Re: HT (Hyper Threading) aware process scheduling doesn't work as it should
From: Con Kolivas @ 2011-10-31 10:06 UTC (permalink / raw)
To: Artem S. Tashkinov; +Cc: linux-kernel
In-Reply-To: <269467866.49093.1320004632156.JavaMail.mail@webmail17>
On Sun, 30 Oct 2011 07:57:12 PM Artem S. Tashkinov wrote:
> I've found out that even on Linux 3.0.8 the process scheduler doesn't
> correctly distributes the load amongst virtual CPUs. E.g. on a 4-core
> system (8 total virtual CPUs) the process scheduler often run some
> instances of four different tasks on the same physical CPU.
> Any thoughts? comments? I think this is quite a serious problem.
Intense cache locality logic, power saving concepts, cpu frequency governor
behaviour and separate runqueues per CPU within the current CPU process
scheduler in the current mainline linux kernel will ocasionally do this. Some
workloads will be better, while others will be worse. Feel free to try my BFS
cpu scheduler if you wish a CPU process scheduler that spreads work more
evenly across CPUs.
Alas the last version I synced up with will not apply cleanly past about 3.0.6
I believe:
http://ck.kolivas.org/patches/bfs/3.0.0/3.0-sched-bfs-413.patch
Regards,
Con Kolivas
--
-ck
^ permalink raw reply
* RE: [PATCH] scheduler rate controller
From: Dario Faggioli @ 2011-10-31 10:16 UTC (permalink / raw)
To: Lv, Hui
Cc: Tian, Kevin, xen-devel@lists.xensource.com, Keir (Xen.org),
George Dunlap, Dong, Eddie, George Dunlap, Duan, Jiangang
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F34B3905D03@shsmsx502.ccr.corp.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 2193 bytes --]
On Sat, 2011-10-29 at 10:05 +0800, Lv, Hui wrote:
> As you said, if applying the seveal_ms_delay, it will happen whenever system is normal or not (excessive frequency). It may possible have the consequence that 1)under normal condition, it will produce worse Qos than that without applying such delay, 2) under excessive frequency condition, the mitigation effect of 1ms-delay may be too weak. In addition, your idea is to delay scheduling instead of reducing, which means the total number of scheduling would probably not change.
>
I think it would. I mean, all the interrupts that arrive (and that are
causing TASKLET_SCHEDULE->schedule() right now) and see current vcpu not
having run for 1ms would collapse in just one call to schedule() at the
end of the 1ms delay from the time instant when the very first one
(interrupt) happened... Isn't it?
If yes, that would definitely reduce the number of calls to schedule().
> I think one possible solution, is to make the value of 1ms-delay adaptive according to the system status (low load or high load). If so, SRC patch just covered the excessive condition currently :). That's why I mentioned to treat normal and excessive conditions separately and don't influence the normal case as much as possible. Because we never know the consequence without amount of testing work. :)
>
Well, again, from my perspective, these numbers (1ms, 10ms) really looks
like ages, considering for example audio processing workloads with
software like JACK needs periodicity of 1.3 or 2.6 ms, and thus having
1ms or (for worse) 10ms eaten by the scheduler would definitely step on
their toes. I understand we're not talking very much about audio
processing VMs here but hey, if it has to be general purpose... :-P
> Some of my stupid thinking :)
>
Same for mine. :-)
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: Which filesystem for target?
From: Paul Eggleton @ 2011-10-31 10:16 UTC (permalink / raw)
To: Chris Tapp; +Cc: yocto
In-Reply-To: <6722EDB4-6AD2-4E51-A826-B00D3AABC6A0@keylevel.com>
On Friday 28 October 2011 23:11:22 Chris Tapp wrote:
> Which is the 'best' filesystem to use for an embedded device that's
> using a CF card?
>
> It needs to survive loss-of-power, have a RO root filesystem, allow
> user configuration data to persist and (ideally) only use 'Busybox'
> commands.
>
> This seems to imply the use of a partition for booting (mount RO) and
> a second partition or a loop-device on the boot partition for
> persistent storage.
>
> I would normally go for ext3, but Busybox doesn't support it (afaik).
> The Busybox tune2fs also only supports -L, so I can't stop 'disk needs
> checking after <n> mounts' messages.
>
> Is btrfs a suitable alternative?
Arnd Bergmann gave a talk at ELCE on flash drive performance (something he has
done quite a lot of research on); I did not attend but Darren and I spoke to
him later on, and if I recall correctly in his tests btrfs performed the best.
Hopefully the talk video will be available soon thanks to the folks at Free
Electrons; in the mean time there's an earlier article by Arnd on this topic
here:
http://lwn.net/Articles/428584/
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: bigalloc and max file size
From: Theodore Tso @ 2011-10-31 10:15 UTC (permalink / raw)
To: Tao Ma
Cc: Theodore Tso, Andreas Dilger, linux-ext4 development,
Alex Zhuravlev, hao.bigrat@gmail.com
In-Reply-To: <4EAA2217.5020002@tao.ma>
On Oct 27, 2011, at 11:31 PM, Tao Ma wrote:
> Forget to say, if we increase the extent length to be cluster, there are
> also a good side effect. ;) Current bigalloc has a severe performance
> regression in the following test case:
> mount -t ext4 /dev/sdb1 /mnt/ext4
> cp linux-3.0.tar.gz /mnt/ext4
> cd /mnt/ext4
> tar zxvf linux-3.0.tar.gz
> umount /mnt/ext4
I've been traveling, so I haven't had a chance to test this, but it makes no sense that changing the encoding fro the extent length would change the performance of the forced writeback caused by amount. There may be a performance bug that we should fix, or may have been fixed by accident with the extent encoding change.
Have you investigated why this got better when you changed the meaning of the extent length field? It makes no sense that such a format change would have such an impact….
-- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" 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
* Serious question: How long does it take to get 64bit into ARM?
From: Russell King - ARM Linux @ 2011-10-31 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111030001654.GX4267@michelle1>
On Sun, Oct 30, 2011 at 02:16:54AM +0200, Michelle Konzack wrote:
> Hello Arm Developers,
>
> Applied Micro Circuits (AMCC) has now presented its new 64bit ARM ?C:
>
> <http://www.pcmag.com/article2/0,2817,2395449,00.asp>
>
> and I like to know, how long it take, to get 64bit support into the
> Kernel.
It won't happen until there's some concrete technical documentation or
example implementation publically released, so at the moment it really
depends on the marketing schedule.
^ permalink raw reply
* [Cluster-devel] GFS2: Fix up REQ flags
From: Steven Whitehouse @ 2011-10-31 10:13 UTC (permalink / raw)
To: cluster-devel.redhat.com
Christoph has split up REQ_PRIO from REQ_META. That means that
we can drop REQ_PRIO from places where is it not needed. I'm
not at all sure that the combination WRITE_FLUSH_FUA | REQ_PRIO
makes any kind of sense, anyway.
In addition, I've added REQ_META to one place in the code where
it was missing. REQ_PRIO has been left for read/writes triggered
by glock acquisition and writeback only. We can adjust it again
if required, but these are the most important points from a
performance perspective.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>
diff --git a/fs/gfs2/log.c b/fs/gfs2/log.c
index 5986464..2731e65 100644
--- a/fs/gfs2/log.c
+++ b/fs/gfs2/log.c
@@ -626,7 +626,7 @@ static void log_write_header(struct gfs2_sbd *sdp, u32 flags, int pull)
if (test_bit(SDF_NOBARRIERS, &sdp->sd_flags))
submit_bh(WRITE_SYNC | REQ_META | REQ_PRIO, bh);
else
- submit_bh(WRITE_FLUSH_FUA | REQ_META | REQ_PRIO, bh);
+ submit_bh(WRITE_FLUSH_FUA | REQ_META, bh);
wait_on_buffer(bh);
if (!buffer_uptodate(bh))
diff --git a/fs/gfs2/meta_io.c b/fs/gfs2/meta_io.c
index be29858..181586e 100644
--- a/fs/gfs2/meta_io.c
+++ b/fs/gfs2/meta_io.c
@@ -435,7 +435,7 @@ struct buffer_head *gfs2_meta_ra(struct gfs2_glock *gl, u64 dblock, u32 extlen)
if (buffer_uptodate(first_bh))
goto out;
if (!buffer_locked(first_bh))
- ll_rw_block(READ_SYNC | REQ_META | REQ_PRIO, 1, &first_bh);
+ ll_rw_block(READ_SYNC | REQ_META, 1, &first_bh);
dblock++;
extlen--;
@@ -444,7 +444,7 @@ struct buffer_head *gfs2_meta_ra(struct gfs2_glock *gl, u64 dblock, u32 extlen)
bh = gfs2_getbuf(gl, dblock, CREATE);
if (!buffer_uptodate(bh) && !buffer_locked(bh))
- ll_rw_block(READA, 1, &bh);
+ ll_rw_block(READA | REQ_META, 1, &bh);
brelse(bh);
dblock++;
extlen--;
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index 7e823bb..4998194 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -223,7 +223,7 @@ static int gfs2_read_super(struct gfs2_sbd *sdp, sector_t sector, int silent)
bio->bi_end_io = end_bio_io_page;
bio->bi_private = page;
- submit_bio(READ_SYNC | REQ_META | REQ_PRIO, bio);
+ submit_bio(READ_SYNC | REQ_META, bio);
wait_on_page_locked(page);
bio_put(bio);
if (!PageUptodate(page)) {
diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
index 7e528dc..d1962b2 100644
--- a/fs/gfs2/quota.c
+++ b/fs/gfs2/quota.c
@@ -712,7 +712,7 @@ get_a_page:
set_buffer_uptodate(bh);
if (!buffer_uptodate(bh)) {
- ll_rw_block(READ | REQ_META | REQ_PRIO, 1, &bh);
+ ll_rw_block(READ | REQ_META, 1, &bh);
wait_on_buffer(bh);
if (!buffer_uptodate(bh))
goto unlock_out;
^ permalink raw reply related
* Re: [PATCH] [TRIVIAL] ARM: imx: Fix typo 'MACH_MX31_3DS_MXC_NAND_USE_BBT'
From: Jiri Kosina @ 2011-10-31 10:12 UTC (permalink / raw)
To: Paul Bolle
Cc: linux-kernel, Russell King, linux-arm-kernel, Fabio Estevam,
Uwe Kleine-König
In-Reply-To: <1318421062.2336.4.camel@x61.thuisdomein>
On Wed, 12 Oct 2011, Paul Bolle wrote:
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> This is trivial because this is what apparently was intended. On the
> other hand this should open code paths that were hidden until now. So
> perhaps this needs the maintainer's approval. (I cannot meaningfully
> test this.)
I'd like to have this tested by some relevant people before taking it
myself (added some CCs).
>
> arch/arm/mach-imx/mach-mx31_3ds.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c b/arch/arm/mach-imx/mach-mx31_3ds.c
> index c20be75..5750ca5 100644
> --- a/arch/arm/mach-imx/mach-mx31_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx31_3ds.c
> @@ -542,7 +542,7 @@ static const struct mxc_nand_platform_data
> mx31_3ds_nand_board_info __initconst = {
> .width = 1,
> .hw_ecc = 1,
> -#ifdef MACH_MX31_3DS_MXC_NAND_USE_BBT
> +#ifdef CONFIG_MACH_MX31_3DS_MXC_NAND_USE_BBT
> .flash_bbt = 1,
> #endif
> };
> --
> 1.7.4.4
>
>
>
--
Jiri Kosina
SUSE Labs
^ 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.