Re: [PATCH RFC nohz_full v2 2/7] nohz_full: Add rcu_dyntick data for scalable detection of all-idle state
On Tue, Jul 02, 2013 at 07:10:52AM +0200, Mike Galbraith wrote: > On Mon, 2013-07-01 at 12:16 -0700, Paul E. McKenney wrote: > > On Mon, Jul 01, 2013 at 11:34:13AM -0700, Josh Triplett wrote: > > > > > > This also naturally raises the question "How can we let userspace get > > > > > accurate time without forcing a timer tick?". > > > > > > > > We don't. ;-) > > > > > > We don't currently, hence my question about how we can. :) > > > > Per-CPU atomic clocks? > > Great idea, who needs timekeeping code. > > http://www.euronews.com/2013/04/02/swiss-sets-sights-on-miniscule-atomic-clock/ "in theory you’ll only need to set it once every 3,000 years, providing of course your battery lasts that long" ;-) ;-) ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC ticketlock] v3 Auto-queued ticketlock
On Mon, Jul 01, 2013 at 02:49:34PM +0530, Raghavendra KT wrote: > On Sun, Jun 23, 2013 at 11:23 PM, Raghavendra KT > wrote: > > > > > > On Wed, Jun 12, 2013 at 9:10 PM, Paul E. McKenney > > wrote: > >> > >> Breaking up locks is better than implementing high-contention locks, but > >> if we must have high-contention locks, why not make them automatically > >> switch between light-weight ticket locks at low contention and queued > >> locks at high contention? After all, this would remove the need for > >> the developer to predict which locks will be highly contended. > >> > >> This commit allows ticket locks to automatically switch between pure > >> ticketlock and queued-lock operation as needed. If too many CPUs are > >> spinning on a given ticket lock, a queue structure will be allocated > >> and the lock will switch to queued-lock operation. When the lock becomes > >> free, it will switch back into ticketlock operation. The low-order bit > >> of the head counter is used to indicate that the lock is in queued mode, > >> which forces an unconditional mismatch between the head and tail counters. > >> This approach means that the common-case code path under conditions of > >> low contention is very nearly that of a plain ticket lock. > >> > >> A fixed number of queueing structures is statically allocated in an > >> array. The ticket-lock address is used to hash into an initial element, > >> but if that element is already in use, it moves to the next element. If > >> the entire array is already in use, continue to spin in ticket mode. > >> > >> Signed-off-by: Paul E. McKenney > >> [ paulmck: Eliminate duplicate code and update comments (Steven Rostedt). > >> ] > >> [ paulmck: Address Eric Dumazet review feedback. ] > >> [ paulmck: Use Lai Jiangshan idea to eliminate smp_mb(). ] > >> [ paulmck: Expand ->head_tkt from s32 to s64 (Waiman Long). ] > >> [ paulmck: Move cpu_relax() to main spin loop (Steven Rostedt). ] > >> [ paulmck: Reduce queue-switch contention (Waiman Long). ] > >> [ paulmck: __TKT_SPIN_INC for __ticket_spin_trylock() (Steffen Persvold). > >> ] > >> [ paulmck: Type safety fixes (Steven Rostedt). ] > >> [ paulmck: Pre-check cmpxchg() value (Waiman Long). ] > >> [ paulmck: smp_mb() downgrade to smp_wmb() (Lai Jiangshan). ] > >> > > [...] > > > > I did test this on 32 core machine with 32 vcpu guests. > > > > This version gave me around 20% improvement fro sysbench and 36% improvement > > for ebizzy, for 1x commit though other overcommited results showed > > degradation. I have not tested Lai Jiangshan's patches on top of this yet. > > Will report any findings. > > Sorry for late report. Not a problem, thank you for running these numbers! > With Lai's patch I see few percentage of improvement in ebizzy 1x and > reduction in degradation in dbench 1x. OK, good! But my guess is that even pushing the lock-acquisition slowpath out of line, we still would not reach parity for the less-good results. Still seems like I should add Lai Jiangshan's patches and post them somewhere in case they are helpful in some other context. Thanx, Paul > But over-commit degradation seem to still persist. seeing this, I > feel it is more of qmode overhead itself for large guests, > > +---+---+---+---++---+ > ebizzy (rec/sec higher is better) > +---+---+---+---+---++---+ > base stdev patched stdev %improvement > +---+---+---+---++---+ > 1x 5574.9000 237.4997 7851.9000 148.673740.84378 > 2x 2741.5000 561.3090 1620.9000 410.8299 -40.87543 > 3x 2146.2500 216.7718 1751.833396.5023 -18.37702 > +---+---+---+---++---+ > +---+---+---+---++---+ > dbench (throughput higher is better) > +---+---+---+---++---+ > base stdev patched stdev %improvement > +---+---+---+---++---+ > 1x 14111.5600 754.4525 13826.5700 1458.0744-2.01955 > 2x 2481.627071.2665 1549.3740 245.3777 -37.56620 > 3x 1510.248331.8634 1116.015826.4882 -26.10382 > +---+---+---+---++---+ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: smart wake-affine
On Tue, 2013-07-02 at 12:43 +0800, Michael Wang wrote: > Since RFC: > Tested again with the latest tip 3.10.0-rc7. > > wake-affine stuff is always trying to pull wakee close to waker, by theory, > this will bring benefit if waker's cpu cached hot data for wakee, or the > extreme ping-pong case. > > And testing show it could benefit hackbench 15% at most. How much does this still help with Alex's patches integrated? aside: were I a maintainer, I'd be a little concerned that what this helps with collides somewhat with the ongoing numa work. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: smart wake-affine
On 07/02/2013 01:38 PM, Mike Galbraith wrote:
> On Tue, 2013-07-02 at 12:43 +0800, Michael Wang wrote:
>
>> +static int nasty_pull(struct task_struct *p)
>> +{
>> +int factor = cpumask_weight(cpu_online_mask);
>> +
>> +/*
>> + * Yeah, it's the switching-frequency, could means many wakee or
>> + * rapidly switch, use factor here will just help to automatically
>> + * adjust the loose-degree, so more cpu will lead to more pull.
>> + */
>> +if (p->nr_wakee_switch > factor) {
>> +/*
>> + * wakee is somewhat hot, it needs certain amount of cpu
>> + * resource, so if waker is far more hot, prefer to leave
>> + * it alone.
>> + */
>> +if (current->nr_wakee_switch > (factor * p->nr_wakee_switch))
>> +return 1;
>> +}
>> +
>> +return 0;
>> +}
>
> Ew. I haven't gotten around to test-driving this patchlet, and I see
> you haven't gotten around to finding a better name either. Any other
> name will likely have a better chance of flying.
Trust me, I've tried to get a good name...and some cells in my brain do
sacrificed for it, bravely ;-)
>
> tasks_related()
> ...
> well, nearly any..
> tasks_think_wake_affine_sucks_rocks()
> ..that won't fly either :)
Hmm...better than those in my mind (like dragon_wake_affine(), well...at
least dragon could fly).
Anyway, if the idea itself become acceptable, then any name is ok for
me, let's figure out a good one at that time :)
Regards,
Michael Wang
>
> -Mike
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] mm: madvise: MADV_POPULATE for quick pre-faulting
On Mon, Jul 01, 2013 at 09:43:29PM -0700, Dave Hansen wrote: > On 07/01/2013 07:37 PM, Zheng Liu wrote: > > FWIW, it would be great if we can let MAP_POPULATE flag support shared > > mappings because in our product system there has a lot of applications > > that uses mmap(2) and then pre-faults this mapping. Currently these > > applications need to pre-fault the mapping manually. > > Are you sure it doesn't? From a cursory look at the code, it looked to > me like it would populate anonymous and file-backed, but I didn't > double-check experimentally. Thanks for pointing it out. I write a program to test this issue, and it seems to me that it can populate a shared mapping. But in manpage it describes as below: MAP_POPULATE (since Linux 2.5.46) Populate (prefault) page tables for a mapping. For a file mapping, this causes read-ahead on the file. Later accesses to the mapping will not be blocked by page faults. MAP_POPULATE is only supported for private mappings since Linux 2.6.23. This page is part of release 3.24 of the Linux man-pages project. I am not sure whether it has been updated or not. Regards, - Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: manual merge of the arm-soc tree with the l2-mtd tree
>
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> Documentation/devicetree/bindings/mtd/gpmc-nand.txt between commits
> 6c88058ef927 ("ARM: OMAP2+: cleaned-up DT support of various ECC
> schemes") and 212012138deb ("mtd: nand: omap2: updated support for
> BCH4
> ECC scheme") from the l2-mtd tree and commit 496c8a0bbb72 ("ARM:
> OMAP2+:
> Allow NAND transfer mode to be specified in DT") from the arm-soc tree.
>
> I fixed it up (maybe - see below) and can carry the fix as necessary (no
> action is required).
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
Yes following merge is correct. Apologies, as there were multiple OMAP2 NAND
and GPMC updates and clean-up going into different trees, so these conflict
came. Going forward you shouldn't find such issues, as code is more stable now.
Thanks for help.
with regards, pekon
> diff --cc Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> index b3f23df,df338cb..000
> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@@ -17,59 -17,27 +17,66 @@@ Required properties
>
> Optional properties:
>
> - - nand-bus-width: Set this numeric value to 16 if the hardware
> -is wired that way. If not specified, a bus
> -width of 8 is assumed.
> + - nand-bus-width: Determines data-width of the connected
> device
> +x16 = "16"
> +x8 = "8" (default)
>
> - - ti,nand-ecc-opt: A string setting the ECC layout to use. One of:
>
> -"sw"Software method (default)
> -"hw"Hardware method
> -"hw-romcode"gpmc hamming mode method & romcode
> layout
> -"bch4" 4-bit BCH ecc code
> -"bch8" 8-bit BCH ecc code
> + - ti,nand-ecc-opt: Determines the ECC scheme used by driver.
> +It can be any of the following strings:
> +
> +"hamming_code_sw" 1-bit Hamming ECC
> +- ECC calculation in software
> +- Error detection in software
> +- ECC layout compatible with S/W
> scheme
> +
> +"hamming_code_hw" 1-bit Hamming ECC
> +- ECC calculation in hardware
> +- Error detection in software
> +- ECC layout compatible with S/W
> scheme
> +
> +"hamming_code_hw_romcode" 1-bit Hamming ECC
> +- ECC calculation in hardware
> +- Error detection in software
> +- ECC layout compatible with ROM
> code
> +
> +"bch4_code_hw_detection_sw" 4-bit BCH ECC
> +- ECC calculation in hardware
> +- Error detection in software
> +- ECC layout compatible with S/W
> scheme
> +* depends on
> CONFIG_MTD_NAND_ECC_BCH
> +
> +"bch4_code_hw" 4-bit BCH ECC
> +- ECC calculation in hardware
> +- Error detection in hardware
> +- ECC layout compatible with ROM
> code
> +* depends on
> CONFIG_MTD_NAND_OMAP_BCH
> +* requires to be specified
> +
> +"bch8_code_hw_detection_sw" 8-bit BCH ECC
> +- ECC calculation in hardware
> +- Error detection in software
> +- ECC layout compatible with S/W
> scheme
> +* depends on
> CONFIG_MTD_NAND_ECC_BCH
> +
> +"bch8_code_hw" 8-bit BCH ECC
> +- ECC calculation in hardware
> +- Error detection in hardware
> +- ECC layout compatible with ROM
> code
> +* depends on
> CONFIG_MTD_NAND_OMAP_BCH
> +* requires to be specified
>
> + - ti,nand-xfer-type: A string setting the data transfer
> type. One
> of:
> +
> + "prefetch-polled" Prefetch polled mode (default)
> + "polled"Polled mode, without prefetch
> + "prefetch-dma" Prefetch enabled sDMA
> mode
> + "prefetch-irq" Prefetch enabled irq mode
> +
> - - elm_id: Specifies elm device node. This is required to support BCH
> -
[PATCH 1/3] mds: update atime if client can read.
Now, update atime only for CEPH_CAP_FILE_EXCL.Change this if
CEPH_CAP_FILE_RD.
Signed-off-by: Jianpeng Ma
---
src/mds/Locker.cc | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/mds/Locker.cc b/src/mds/Locker.cc
index 30e014a..58f953f 100644
--- a/src/mds/Locker.cc
+++ b/src/mds/Locker.cc
@@ -2676,8 +2676,9 @@ void Locker::_do_snap_update(CInode *in, snapid_t snap,
int dirty, snapid_t foll
void Locker::_update_cap_fields(CInode *in, int dirty, MClientCaps *m, inode_t
*pi)
{
// file
+ utime_t atime = m->get_atime();
+
if (dirty & (CEPH_CAP_FILE_EXCL|CEPH_CAP_FILE_WR)) {
-utime_t atime = m->get_atime();
utime_t mtime = m->get_mtime();
utime_t ctime = m->get_ctime();
uint64_t size = m->get_size();
@@ -2700,11 +2701,7 @@ void Locker::_update_cap_fields(CInode *in, int dirty,
MClientCaps *m, inode_t *
pi->size = size;
pi->rstat.rbytes = size;
}
-if ((dirty & CEPH_CAP_FILE_EXCL) && atime != pi->atime) {
- dout(7) << " atime " << pi->atime << " -> " << atime
- << " for " << *in << dendl;
- pi->atime = atime;
-}
+
if ((dirty & CEPH_CAP_FILE_EXCL) &&
ceph_seq_cmp(pi->time_warp_seq, m->get_time_warp_seq()) < 0) {
dout(7) << " time_warp_seq " << pi->time_warp_seq << " -> " <<
m->get_time_warp_seq()
@@ -2712,6 +2709,12 @@ void Locker::_update_cap_fields(CInode *in, int dirty,
MClientCaps *m, inode_t *
pi->time_warp_seq = m->get_time_warp_seq();
}
}
+
+ if ((dirty & CEPH_CAP_FILE_RD) && atime > pi->atime) {
+ dout(7) << " atime " << pi->atime << " -> " << atime
+ << " for " << *in << dendl;
+ pi->atime = atime;
+ }
// auth
if (dirty & CEPH_CAP_AUTH_EXCL) {
if (m->head.uid != pi->uid) {
--
1.8.3.rc1.44.gb387c77
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
[PATCH 2/3] ceph: update atime after read-operation.
Now ceph don't support updating atime after read-operation if the open
mode is CEPH_CAP_FILE_RD.There are two reasons:
1:in client of fs,it don't set dirty cap of CEPH_CAP_FILE_RD.
2:in mds,it only update the atime if the condition
"dirty & (CEPH_CAP_FILE_EXCL|CEPH_CAP_FILE_WR) is true.
But if we can read, we can update atime. This patch only modify client to
support.
Signed-off-by: Jianpeng Ma
---
fs/ceph/file.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index 87df15a..9daea70 100644
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -672,6 +672,15 @@ again:
out:
dout("aio_read %p %llx.%llx dropping cap refs on %s = %d\n",
inode, ceph_vinop(inode), ceph_cap_string(got), (int)ret);
+
+ if (ret >= 0) {
+ int dirty;
+ spin_lock(>i_ceph_lock);
+ dirty = __ceph_mark_dirty_caps(ci, CEPH_CAP_FILE_RD);
+ spin_unlock(>i_ceph_lock);
+ if (dirty)
+ __mark_inode_dirty(inode, dirty);
+ }
ceph_put_cap_refs(ci, got);
if (checkeof && ret >= 0) {
--
1.8.1.2
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
linux-next: manual merge of the renesas tree with the arm tree
Hi Simon,
Today's linux-next merge of the renesas tree got a conflict in
arch/arm/mach-shmobile/Kconfig between commit fb521a0da155 ("arm: fix up
ARM_ARCH_TIMER selects") from the arm tree and commits 462972da5f18
("ARM: shmobile: Make r8a7790 Arch timer optional") and 39d97587d6cb
("ARM: shmobile: Make r8a73a4 Arch timer optional") from the renesas tree.
I fixed it up (the latter patches removed the "select"s that the former
modified) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp5IRLXnFdml.pgp
Description: PGP signature
[PATCH 3/3] ceph: For ceph_sync_read, update the atime of file.
For buffer read, the func generic_file_aio_read will update atime of
file.But the ceph_sync_read don't do it.So add this.
Signed-off-by: Jianpeng Ma
---
fs/ceph/file.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index 656e169..87df15a 100644
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -442,6 +442,9 @@ done:
ceph_put_page_vector(pages, num_pages, true);
else
ceph_release_page_vector(pages, num_pages);
+
+ file_accessed(file);
+
dout("sync_read result %d\n", ret);
return ret;
}
--
1.8.1.2
[PATCH 0/3] implement of updating atime for client has CEPH_CAP_FILE_RD
Now update atime of file, only for client had CEPH_CAP_FLE_EXCL.But for atime, if one can read he can update this attribte. For this feature,it need both client and mds modify. PATCH1,it modify the mds to support. PATCH2,it modify the client to suport. PATCH3, it support this feature for sync_read mode. Jianpeng Ma (3): mds: update atime if client can read ceph: update atime after read-operation. ceph: For ceph_sync_read, update the atime of file. fs/ceph/file.c | 12 1 file changed, 12 insertions(+) -- 1.8.1.2
RE: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
On Tue, Jul 02, 2013 at 11:10:14, Nori, Sekhar wrote: > > On 6/28/2013 3:05 PM, Hebbar Gururaja wrote: > > Since now rtc-omap driver itself calls deice_init_wakeup(dev, true), > > duplicate call from the rtc device registration can be removed. > > > > This is basically a partial revert of the prev commit > > > > commit 75c99bb0006ee065b4e2995078d779418b0fab54 > > Author: Sekhar Nori > > > > davinci: da8xx/omap-l1: mark RTC as a wakeup source > > > > Signed-off-by: Hebbar Gururaja > > Cc: Sekhar Nori > > Cc: Kevin Hilman > > Cc: Russell King > > Subject line should be prefixed with ARM: keeping with arch/arm > convention. Otherwise looks good. Will fix it in v2. > > Acked-by: Sekhar Nori Thanks for the review. > > Thanks, > Sekhar > Regards, Gururaja
Re: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote: > Since now rtc-omap driver itself calls deice_init_wakeup(dev, true), > duplicate call from the rtc device registration can be removed. > > This is basically a partial revert of the prev commit > > commit 75c99bb0006ee065b4e2995078d779418b0fab54 > Author: Sekhar Nori > > davinci: da8xx/omap-l1: mark RTC as a wakeup source > > Signed-off-by: Hebbar Gururaja > Cc: Sekhar Nori > Cc: Kevin Hilman > Cc: Russell King Subject line should be prefixed with ARM: keeping with arch/arm convention. Otherwise looks good. Acked-by: Sekhar Nori Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: smart wake-affine
On Tue, 2013-07-02 at 12:43 +0800, Michael Wang wrote:
> +static int nasty_pull(struct task_struct *p)
> +{
> + int factor = cpumask_weight(cpu_online_mask);
> +
> + /*
> + * Yeah, it's the switching-frequency, could means many wakee or
> + * rapidly switch, use factor here will just help to automatically
> + * adjust the loose-degree, so more cpu will lead to more pull.
> + */
> + if (p->nr_wakee_switch > factor) {
> + /*
> + * wakee is somewhat hot, it needs certain amount of cpu
> + * resource, so if waker is far more hot, prefer to leave
> + * it alone.
> + */
> + if (current->nr_wakee_switch > (factor * p->nr_wakee_switch))
> + return 1;
> + }
> +
> + return 0;
> +}
Ew. I haven't gotten around to test-driving this patchlet, and I see
you haven't gotten around to finding a better name either. Any other
name will likely have a better chance of flying.
tasks_related()
...
well, nearly any..
tasks_think_wake_affine_sucks_rocks()
..that won't fly either :)
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2 1/1] mwifiex: add tx info to skb when forming mgmt frame
Hi Harvey,
> From: Huawei Yang
>
> In function 'mwifiex_write_data_complete' it need tx info to find the
> mwifiex_private to updates statistics and wake up tx queues.
> Or we may trigger tx queues timeout when transmitting lots of mgmt frames.
>
> Signed-off-by: Huawei Yang
> ---
> drivers/net/wireless/mwifiex/cfg80211.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
> b/drivers/net/wireless/mwifiex/cfg80211.c
> index e42b266..b4e2538 100644
> --- a/drivers/net/wireless/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/mwifiex/cfg80211.c
> @@ -186,6 +186,7 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy,
> struct wireless_dev *wdev,
> struct sk_buff *skb;
> u16 pkt_len;
> const struct ieee80211_mgmt *mgmt;
> + struct mwifiex_txinfo *tx_info;
> struct mwifiex_private *priv = mwifiex_netdev_get_priv(wdev-
> >netdev);
>
> if (!buf || !len) {
> @@ -212,6 +213,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy,
> struct wireless_dev *wdev,
> wiphy_err(wiphy, "allocate skb failed for management
> frame\n");
> return -ENOMEM;
> }
> +
Here checkpatch.pl script reports whitespace damaged error.
I can fix it in my local tree and resend v3 to John after the 3.11 merge window.
Thanks,
Bing
> + tx_info = MWIFIEX_SKB_TXCB(skb);
> + tx_info->bss_num = priv->bss_num;
> + tx_info->bss_type = priv->bss_type;
>
> mwifiex_form_mgmt_frame(skb, buf, len);
> mwifiex_queue_tx_pkt(priv, skb);
> --
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [v2][PATCH 4/7] book3e/kexec/kdump: introduce a kexec kernel flag
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Tiejun
> Chen
> Sent: Thursday, June 20, 2013 1:23 PM
> To: b...@kernel.crashing.org
> Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Subject: [v2][PATCH 4/7] book3e/kexec/kdump: introduce a kexec kernel flag
>
> We need to introduce a flag to indicate we're already running
> a kexec kernel then we can go proper path. For example, We
> shouldn't access spin_table from the bootloader to up any secondary
> cpu for kexec kernel, and kexec kernel already know how to jump to
> generic_secondary_smp_init.
>
> Signed-off-by: Tiejun Chen
> ---
> arch/powerpc/include/asm/smp.h|3 +++
> arch/powerpc/kernel/head_64.S | 12
> arch/powerpc/kernel/misc_64.S |6 ++
> arch/powerpc/platforms/85xx/smp.c | 14 ++
> 4 files changed, 35 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index ffbaabe..fbc3d9b 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -200,6 +200,9 @@ extern void generic_secondary_thread_init(void);
> extern unsigned long __secondary_hold_spinloop;
> extern unsigned long __secondary_hold_acknowledge;
> extern char __secondary_hold;
> +#if defined(CONFIG_KEXEC) || defined(CONFIG_CRASH_DUMP)
> +extern unsigned long __run_at_kexec;
> +#endif
>
> extern void __early_start(void);
> #endif /* __ASSEMBLY__ */
> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index 3e19ba2..ffa4b18 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -89,6 +89,12 @@ __secondary_hold_spinloop:
> __secondary_hold_acknowledge:
> .llong 0x0
>
> +#if defined(CONFIG_KEXEC) || defined(CONFIG_CRASH_DUMP)
> + .globl __run_at_kexec
> +__run_at_kexec:
> + .llong 0x0 /* Flag for the secondary kernel from kexec. */
> +#endif
> +
> #ifdef CONFIG_RELOCATABLE
> /* This flag is set to 1 by a loader if the kernel should run
>* at the loaded address instead of the linked address. This
> @@ -417,6 +423,12 @@ _STATIC(__after_prom_start)
> #if defined(CONFIG_PPC_BOOK3E)
> tovirt(r26,r26) /* on booke, we already run at
> PAGE_OFFSET */
> #endif
> +#if defined(CONFIG_KEXEC) || defined(CONFIG_CRASH_DUMP)
> + /* If relocated we need to restore this flag on that relocated address.
> */
> + ld r7,__run_at_kexec-_stext(r26)
> + std r7,__run_at_kexec-_stext(r26)
> +#endif
> +
> lwz r7,__run_at_load-_stext(r26)
> #if defined(CONFIG_PPC_BOOK3E)
> tophys(r26,r26) /* Restore for the remains. */
> diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
> index 20cbb98..c89aead 100644
> --- a/arch/powerpc/kernel/misc_64.S
> +++ b/arch/powerpc/kernel/misc_64.S
> @@ -619,6 +619,12 @@ _GLOBAL(kexec_sequence)
> bl .copy_and_flush /* (dest, src, copy limit, start offset) */
> 1: /* assume normal blr return */
>
> + /* notify we're going into kexec kernel for SMP. */
> + LOAD_REG_ADDR(r3,__run_at_kexec)
> + li r4,1
> + std r4,0(r3)
> + sync
> +
> /* release other cpus to the new kernel secondary start at 0x60 */
> mflrr5
> li r6,1
> diff --git a/arch/powerpc/platforms/85xx/smp.c
> b/arch/powerpc/platforms/85xx/smp.c
> index 6a17599..b308373 100644
> --- a/arch/powerpc/platforms/85xx/smp.c
> +++ b/arch/powerpc/platforms/85xx/smp.c
> @@ -150,6 +150,9 @@ static int __cpuinit smp_85xx_kick_cpu(int nr)
> int hw_cpu = get_hard_smp_processor_id(nr);
> int ioremappable;
> int ret = 0;
> +#if defined(CONFIG_KEXEC) || defined(CONFIG_CRASH_DUMP)
> + unsigned long *ptr;
> +#endif
What about if we can remove the ifdef around *ptr ...
>
> WARN_ON(nr < 0 || nr >= NR_CPUS);
> WARN_ON(hw_cpu < 0 || hw_cpu >= NR_CPUS);
> @@ -238,11 +241,22 @@ out:
> #else
> smp_generic_kick_cpu(nr);
>
> +#if defined(CONFIG_KEXEC) || defined(CONFIG_CRASH_DUMP)
> + ptr = (unsigned long *)((unsigned long)&__run_at_kexec);
... #endif here ...
> + /* We shouldn't access spin_table from the bootloader to up any
> + * secondary cpu for kexec kernel, and kexec kernel already
> + * know how to jump to generic_secondary_smp_init.
> + */
> + if (!*ptr) {
> +#endif
... remove #endif ...
> flush_spin_table(spin_table);
> out_be32(_table->pir, hw_cpu);
> out_be64((u64 *)(_table->addr_h),
> __pa((u64)*((unsigned long long *)generic_secondary_smp_init)));
> flush_spin_table(spin_table);
> +#if defined(CONFIG_KEXEC) || defined(CONFIG_CRASH_DUMP)
> + }
> +#endif
--- remove above 3 lines
-Bharat
> #endif
>
> local_irq_restore(flags);
> --
> 1.7.9.5
>
> ___
> Linuxppc-dev mailing
[PATCH] Add hsize argument in write_buf call of pstore_ftrace_call
Incorporate the addition of hsize argument in write_buf callback of pstore. Signed-off-by: Aruna Balakrishnaiah --- fs/pstore/ftrace.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/pstore/ftrace.c b/fs/pstore/ftrace.c index 43b1280..76a4eeb 100644 --- a/fs/pstore/ftrace.c +++ b/fs/pstore/ftrace.c @@ -44,7 +44,7 @@ static void notrace pstore_ftrace_call(unsigned long ip, rec.parent_ip = parent_ip; pstore_ftrace_encode_cpu(, raw_smp_processor_id()); psinfo->write_buf(PSTORE_TYPE_FTRACE, 0, NULL, 0, (void *), - sizeof(rec), psinfo); + 0, sizeof(rec), psinfo); local_irq_restore(flags); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with the l2-mtd tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/mtd/nand/Kconfig between commit 212012138deb ("mtd: nand: omap2:
updated support for BCH4 ECC scheme") from the l2-mtd tree and commit
930d800bded7 ("mtd: omap2: allow bulding as a module") from the arm-soc
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/mtd/nand/Kconfig
index a6e247c,50543f1..000
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@@ -95,13 -95,35 +95,13 @@@ config MTD_NAND_OMAP
config MTD_NAND_OMAP_BCH
depends on MTD_NAND && MTD_NAND_OMAP2 && ARCH_OMAP3
- bool "Support hardware based BCH error correction"
- tristate "Enable support for hardware BCH error correction"
++ tristate "Support hardware based BCH error correction"
default n
select BCH
- select BCH_CONST_PARAMS
help
- Support for hardware BCH error correction.
-
-choice
- prompt "BCH error correction capability"
- depends on MTD_NAND_OMAP_BCH
-
-config MTD_NAND_OMAP_BCH8
- bool "8 bits / 512 bytes (recommended)"
- help
- Support correcting up to 8 bitflips per 512-byte block.
- This will use 13 bytes of spare area per 512 bytes of page data.
- This is the recommended mode, as 4-bit mode does not work
- on some OMAP3 revisions, due to a hardware bug.
-
-config MTD_NAND_OMAP_BCH4
- bool "4 bits / 512 bytes"
- help
- Support correcting up to 4 bitflips per 512-byte block.
- This will use 7 bytes of spare area per 512 bytes of page data.
- Note that this mode does not work on some OMAP3 revisions, due to a
- hardware bug. Please check your OMAP datasheet before selecting this
- mode.
-
-endchoice
+Some devices have built-in ELM hardware engine, which can be used to
+locate and correct errors when using BCH ECC scheme. This enables the
+driver support for same.
if MTD_NAND_OMAP_BCH
config BCH_CONST_M
pgpsAM2A22JRP.pgp
Description: PGP signature
Re: [PATCH v3 10/45] smp: Use get/put_online_cpus_atomic() to prevent CPU offline
Hi, Srivatsa
On 06/28/2013 03:54 AM, Srivatsa S. Bhat wrote:
[snip]
> @@ -625,8 +632,9 @@ EXPORT_SYMBOL(on_each_cpu_mask);
> * The function might sleep if the GFP flags indicates a non
> * atomic allocation is allowed.
> *
> - * Preemption is disabled to protect against CPUs going offline but not
> online.
> - * CPUs going online during the call will not be seen or sent an IPI.
> + * We use get/put_online_cpus_atomic() to protect against CPUs going
> + * offline but not online. CPUs going online during the call will
> + * not be seen or sent an IPI.
I was a little confused about this comment, if the offline-cpu still
have chances to become online, then there is chances that we will pick
it from for_each_online_cpu(), isn't it? Did I miss some point?
Regards,
Michael Wang
> *
> * You must not call this function with disabled interrupts or
> * from a hardware interrupt handler or from a bottom half handler.
> @@ -641,26 +649,26 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void
> *info),
> might_sleep_if(gfp_flags & __GFP_WAIT);
>
> if (likely(zalloc_cpumask_var(, (gfp_flags|__GFP_NOWARN {
> - preempt_disable();
> + get_online_cpus_atomic();
> for_each_online_cpu(cpu)
> if (cond_func(cpu, info))
> cpumask_set_cpu(cpu, cpus);
> on_each_cpu_mask(cpus, func, info, wait);
> - preempt_enable();
> + put_online_cpus_atomic();
> free_cpumask_var(cpus);
> } else {
> /*
>* No free cpumask, bother. No matter, we'll
>* just have to IPI them one by one.
>*/
> - preempt_disable();
> + get_online_cpus_atomic();
> for_each_online_cpu(cpu)
> if (cond_func(cpu, info)) {
> ret = smp_call_function_single(cpu, func,
> info, wait);
> WARN_ON_ONCE(!ret);
> }
> - preempt_enable();
> + put_online_cpus_atomic();
> }
> }
> EXPORT_SYMBOL(on_each_cpu_cond);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Mon, Jul 1, 2013 at 11:03 AM, Sedat Dilek wrote: > On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter wrote: >> On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek wrote: >>> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell >>> wrote: >>>> Hi all, >>>> >>>> Changes since 20130628: >>>> >>>> The regulator tree gained a build failure so I used the version from >>>> next-20130628. >>>> >>>> The trivial tree gained a conflict against the fbdev tree. >>>> >>>> The arm-soc tree gained a conflict against the net-next tree. >>>> >>>> The akpm tree lost a few patches that turned up elsewhere and I removed 2 >>>> that were causing run time problems. >>>> >>> >>> [ CC drm and drm-intel folks ] >>> >>> [ Did not check any relevant MLs ] >>> >>> Please, see attached dmesg output. >> >> Clock mismatch, one for Jesse to figure out. Note that this patch is >> for 3.12, I simply haven't yet gotten around to properly split my >> patch queue so a few spilled into -next. I'll do that now. > > I like lightspeed-fast replies :-). > > Guess "drm/i915: get mode clock when reading the pipe config v9" [1] > is the cause. > Problem solved by applying these patches to next-20130701 from intel-gfx patchwork-service [0]: [1/2] drm/i915: fixup messages in pipe_config_compare [2/2] drm/i915: get clock config when checking CRTC state too AFAICS 2/2 was folded into updated "drm/i915: get mode clock when reading the pipe config v9" [3]. It would be kind to be CCed on the patches and get also some credits. Also a CC to the report in linux-next should IMHO be done. - Sedat - [0] https://patchwork.kernel.org/project/intel-gfx/list/ [1] https://patchwork.kernel.org/patch/2809031/ [2] https://patchwork.kernel.org/patch/2809021/ [3] http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-nightly=f1f644dc66cbaf5a4c7dcde683361536b41885b9 > - Sedat - > > [1] > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued=d325d8b4f351f9d45e7c8baabf581fd21f343133 > >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with the l2-mtd tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
Documentation/devicetree/bindings/mtd/gpmc-nand.txt between commits
6c88058ef927 ("ARM: OMAP2+: cleaned-up DT support of various ECC
schemes") and 212012138deb ("mtd: nand: omap2: updated support for BCH4
ECC scheme") from the l2-mtd tree and commit 496c8a0bbb72 ("ARM: OMAP2+:
Allow NAND transfer mode to be specified in DT") from the arm-soc tree.
I fixed it up (maybe - see below) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index b3f23df,df338cb..000
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@@ -17,59 -17,27 +17,66 @@@ Required properties
Optional properties:
- - nand-bus-width:Set this numeric value to 16 if the hardware
- is wired that way. If not specified, a bus
- width of 8 is assumed.
+ - nand-bus-width:Determines data-width of the connected device
+ x16 = "16"
+ x8 = "8" (default)
- - ti,nand-ecc-opt: A string setting the ECC layout to use. One of:
- "sw"Software method (default)
- "hw"Hardware method
- "hw-romcode"gpmc hamming mode method & romcode layout
- "bch4" 4-bit BCH ecc code
- "bch8" 8-bit BCH ecc code
+ - ti,nand-ecc-opt: Determines the ECC scheme used by driver.
+ It can be any of the following strings:
+
+ "hamming_code_sw" 1-bit Hamming ECC
+ - ECC calculation in software
+ - Error detection in software
+ - ECC layout compatible with S/W scheme
+
+ "hamming_code_hw" 1-bit Hamming ECC
+ - ECC calculation in hardware
+ - Error detection in software
+ - ECC layout compatible with S/W scheme
+
+ "hamming_code_hw_romcode" 1-bit Hamming ECC
+ - ECC calculation in hardware
+ - Error detection in software
+ - ECC layout compatible with ROM code
+
+ "bch4_code_hw_detection_sw" 4-bit BCH ECC
+ - ECC calculation in hardware
+ - Error detection in software
+ - ECC layout compatible with S/W scheme
+ * depends on CONFIG_MTD_NAND_ECC_BCH
+
+ "bch4_code_hw" 4-bit BCH ECC
+ - ECC calculation in hardware
+ - Error detection in hardware
+ - ECC layout compatible with ROM code
+ * depends on CONFIG_MTD_NAND_OMAP_BCH
+ * requires to be specified
+
+ "bch8_code_hw_detection_sw" 8-bit BCH ECC
+ - ECC calculation in hardware
+ - Error detection in software
+ - ECC layout compatible with S/W scheme
+ * depends on CONFIG_MTD_NAND_ECC_BCH
+
+ "bch8_code_hw" 8-bit BCH ECC
+ - ECC calculation in hardware
+ - Error detection in hardware
+ - ECC layout compatible with ROM code
+ * depends on CONFIG_MTD_NAND_OMAP_BCH
+ * requires to be specified
+ - ti,nand-xfer-type: A string setting the data transfer type. One of:
+
+ "prefetch-polled" Prefetch polled mode (default)
+ "polled"Polled mode, without prefetch
+ "prefetch-dma" Prefetch enabled sDMA mode
+ "prefetch-irq" Prefetch enabled irq mode
+
- - elm_id:Specifies elm device node. This is required to support BCH
- error correction using ELM module.
+
+ - elm_id:Specifies elm device node. This is required to
+ support some BCH ECC schemes mentioned above.
+
For inline partiton table parsing (optional):
pgpGr02zUsHk6.pgp
Description: PGP signature
Re: [PATCH 0/6] Basic scheduler support for automatic NUMA balancing
* Mel Gorman [2013-07-01 09:43:21]: > > Thanks. Each of the the two runs had 5 iterations and there is a > difference in the reported average. Do you know what the standard > deviation is of the results? Yes, the results were from 2 different runs. I hadnt calculated the std deviation for those runs. > > I'm less concerned about the numa01 results as it is an adverse > workload on machins with more than two sockets but the numa02 results > are certainly of concern. My own testing for numa02 showed little or no > change. Would you mind testing with "Increase NUMA PTE scanning when a > new preferred node is selected" reverted please? > Here are the results with the last patch reverted as requested by you. KernelVersion: 3.9.0-mainline_v39+ your patches - last patch Testcase: Min Max Avg StdDev %Change numa01: 1704.50 1841.82 1757.55 49.272.42% numa01_THREAD_ALLOC: 433.25 517.07 464.17 28.15 -32.99% numa02:55.6461.7557.702.19 -43.52% numa02_SMT:44.7853.4548.722.91 -18.53% Detailed run output here numa01 1704.50 248.67 71999.86 207091 1093 numa01_THREAD_ALLOC 461.62 416.89 23064.79 90283 961 numa02 61.75 93.86 2444.21 10652 6 numa02_SMT 46.79 23.13 977.94 1925 8 numa01 1769.09 262.00 74607.77 226677 1313 numa01_THREAD_ALLOC 433.25 365.12 21994.25 88597 773 numa02 55.64 89.52 2250.01 8848 210 numa02_SMT 49.39 19.81 938.86 1376 33 numa01 1841.82 407.73 78683.69 227428 1834 numa01_THREAD_ALLOC 517.07 465.71 26152.60 111689 978 numa02 55.95 103.26 2223.36 8471 158 numa02_SMT 53.45 19.73 962.08 1349 26 numa01 1760.41 474.74 76094.03 231278 2802 numa01_THREAD_ALLOC 456.80 395.35 23170.23 88049 835 numa02 57.18 87.31 2390.11 10804 3 numa02_SMT 44.78 26.48 944.28 1314 7 numa01 1711.91 421.49 77728.30 224185 2103 numa01_THREAD_ALLOC 452.09 430.88 22271.38 83418 2035 numa02 57.97 126.86 2354.34 8991 135 numa02_SMT 49.19 34.99 914.35 1308 22 > -- > Mel Gorman > SUSE Labs > -- Thanks and Regards Srikar Dronamraju -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] arch/arc updates for 3.11
Hi Linus, First batch of ARC changes for 3.11. Please pull. There's a second bunch to follow next week - which depends on commits on other trees (irq/net). I'd have preferred the accompanying ARC change via respective trees, but it didn't workout somehow. Thx, -Vineet ---> The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/arc-v3.11-rc1-part1 for you to fetch changes up to baadb8fd0c62540f2ffb2d0f12b8a47c7975562b: ARC: warn on improper stack unwind FDE entries (2013-06-27 14:37:59 +0530) ARC changes for 3.11 Highlights of changes: -Continuation of ARC MM changes from 3.10 including zero page optimization; Setting pagecache pages dirty by default; Non executable stack by default; Reducing dcache flushes for aliasing VIPT config -Long overdue rework of pt_regs machinery - removing the unused word gutters and adding ECR register to baseline (helps cleanup lot of low level code) -Support for ARC gcc 4.8 -Few other preventive fixes, cosmetics, usage of Kconfig helper.. The diffstat is larger than normal primarily because of arcregs.h header split as well as beautification of macros in entry.h Alexey Brodkin (1): ARC: make dcache VIPT aliasing support dependant on dcache Mischa Jonker (1): ARC: [plat-arcfpga] Fix build breakage when !CONFIG_ARC_SERIAL Paul Gortmaker (1): arc: delete __cpuinit usage from all arc files Vineet Gupta (29): ARC: Use kconfig helper IS_ENABLED() to get rid of defines.h ARC: More code beautification with IS_ENABLED() ARC: Disintegrate arcregs.h ARC: Reduce Code for ECR printing ARC: cache detection code bitrot ARC: No-op full icache flush if !CONFIG_ARC_HAS_ICACHE ARC: [mm] Zero page optimization ARC: [mm] optimise VIPT dcache aliasing 1/x ARC: [mm] optimise VIPT dcache aliasing 2/x ARC: [mm] Assume pagecache page dirty by default ARC: [mm] Make stack/heap Non-executable by default ARC: [mm] Remove @write argument to do_page_fault() ARC: pt_regs update #0: remove kernel stack canary ARC: pt_regs update #1: Align pt_regs end with end of kernel stack page ARC: pt_regs update #2: Remove unused gutter at start of pt_regs ARC: pt_regs update #3: Remove unused gutter at start of callee_regs ARC: Increase readability of entry handlers ARC: Entry Handler tweaks: Avoid hardcoded LIMMS for ECR values ARC: Entry Handler tweaks: Simplify branch for in-kernel preemption ARC: K/U SP saved from one location in stack switching macro ARC: pt_regs update #4: r25 saved/restored unconditionally ARC: stop using pt_regs->orig_r8 ARC: pt_regs update #5: Use real ECR for pt_regs->event vs. synth values ARC: Remove explicit passing around of ECR ARC: Setup Vector Table Base in early boot ARC: Adjustments for gcc 4.8 ARC: [tlb-miss] Extraneous PTE bit testing/setting ARC: [tlb-miss] Fix bug with CONFIG_ARC_DBG_TLB_MISS_COUNT ARC: warn on improper stack unwind FDE entries arch/arc/Kconfig| 8 +- arch/arc/Makefile | 28 +- arch/arc/configs/fpga_defconfig | 2 +- arch/arc/configs/nsimosci_defconfig | 2 +- arch/arc/configs/tb10x_defconfig| 2 +- arch/arc/include/asm/arcregs.h | 127 + arch/arc/include/asm/bug.h | 5 +- arch/arc/include/asm/cache.h| 26 +- arch/arc/include/asm/cacheflush.h | 13 +- arch/arc/include/asm/defines.h | 56 arch/arc/include/asm/entry.h| 521 +++- arch/arc/include/asm/irq.h | 2 +- arch/arc/include/asm/irqflags.h | 20 ++ arch/arc/include/asm/kgdb.h | 4 +- arch/arc/include/asm/kprobes.h | 6 +- arch/arc/include/asm/mmu.h | 44 +++ arch/arc/include/asm/page.h | 7 +- arch/arc/include/asm/pgtable.h | 6 + arch/arc/include/asm/processor.h| 17 +- arch/arc/include/asm/ptrace.h | 47 ++-- arch/arc/include/asm/syscall.h | 5 +- arch/arc/include/asm/tlb-mmu1.h | 4 +- arch/arc/include/asm/tlb.h | 26 -- arch/arc/include/asm/unaligned.h| 4 +- arch/arc/include/uapi/asm/ptrace.h | 15 +- arch/arc/kernel/asm-offsets.c | 7 +- arch/arc/kernel/ctx_sw.c| 14 +- arch/arc/kernel/entry.S | 103 +++ arch/arc/kernel/head.S | 2 + arch/arc/kernel/irq.c | 16 +- arch/arc/kernel/kgdb.c | 4 +- arch/arc/kernel/kprobes.c | 5 +- arch/arc/kernel/process.c | 9 +- arch/arc/kernel/ptrace.c| 14 +-
RE: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On Tue, Jul 02, 2013 at 05:45:01, Kevin Hilman wrote: > Hebbar Gururaja writes: > > > On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN) > > is available to enable Alarm Wakeup feature. This register needs to be > > properly handled for the rtcwake to work properly. > > > > Platforms using such IP should set "ti,am3352-rtc" in rtc device dt > > compatibility node. > > > > Signed-off-by: Hebbar Gururaja > > Cc: Grant Likely > > Cc: Rob Herring > > Cc: Rob Landley > > Cc: Sekhar Nori > > Cc: Kevin Hilman > > Cc: Alessandro Zummo > > Cc: rtc-li...@googlegroups.com > > Cc: devicetree-disc...@lists.ozlabs.org > > Cc: linux-...@vger.kernel.org > > Acked-by: Kevin Hilman > > ...with a minor nit below... > > > --- > > :100644 100644 b47aa41... 5a0f02d... M > > Documentation/devicetree/bindings/rtc/rtc-omap.txt > > :100644 100644 761919d... 666b0c2... M drivers/rtc/rtc-omap.c > > Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 ++- > > drivers/rtc/rtc-omap.c | 56 > > +--- > > 2 files changed, 54 insertions(+), 8 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt > > b/Documentation/devicetree/bindings/rtc/rtc-omap.txt > > index b47aa41..5a0f02d 100644 > > --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt > > +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt > > @@ -1,7 +1,11 @@ > > TI Real Time Clock > > > > Required properties: > > -- compatible: "ti,da830-rtc" > > +- compatible: > > + - "ti,da830-rtc" - for RTC IP used similar to that on DA8xx SoC family. > > + - "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC > > family. > > + This RTC IP has special WAKE-EN Register to enable > > + Wakeup generation for event Alarm. > > - reg: Address range of rtc register set > > - interrupts: rtc timer, alarm interrupts in order > > - interrupt-parent: phandle for the interrupt controller > > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c > > index 761919d..666b0c2 100644 > > --- a/drivers/rtc/rtc-omap.c > > +++ b/drivers/rtc/rtc-omap.c > > @@ -72,6 +72,8 @@ > > #define OMAP_RTC_KICK0_REG 0x6c > > #define OMAP_RTC_KICK1_REG 0x70 > > > > +#define OMAP_RTC_IRQWAKEEN 0x7C > > + > > nit: letters in hex numbers are usually lower-case. Thanks for the review. V2 will soon follow. > > > Kevin > Regards, Gururaja -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
On Tue, Jul 02, 2013 at 05:37:43, Kevin Hilman wrote:
> Hebbar Gururaja writes:
>
> > Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
> > duplicate call from the rtc device registration can be removed.
> >
> > This is basically a partial revert of the prev commit
> >
> > commit 75c99bb0006ee065b4e2995078d779418b0fab54
> > Author: Sekhar Nori
> >
> > davinci: da8xx/omap-l1: mark RTC as a wakeup source
> >
> > Signed-off-by: Hebbar Gururaja
> > Cc: Sekhar Nori
> > Cc: Kevin Hilman
> > Cc: Russell King
> >
> > ---
> > :100644 100644 bf57252... 85a900c... M
> > arch/arm/mach-davinci/devices-da8xx.c
> > arch/arm/mach-davinci/devices-da8xx.c |9 +
> > 1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/devices-da8xx.c
> > b/arch/arm/mach-davinci/devices-da8xx.c
> > index bf57252..85a900c 100644
> > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> > @@ -827,14 +827,7 @@ static struct platform_device da8xx_rtc_device = {
> >
> > int da8xx_register_rtc(void)
> > {
> > - int ret;
> > -
> > - ret = platform_device_register(_rtc_device);
> > - if (!ret)
> > - /* Atleast on DA850, RTC is a wakeup source */
> > - device_init_wakeup(_rtc_device.dev, true);
> > -
> > - return ret;
> > + return platform_device_register(_rtc_device);
>
> nit: extra space between 'return' and 'platform_'
Thanks for the review. V2 will soon follow.
>
> > }
> >
> > static void __iomem *da8xx_ddr2_ctlr_base;
>
> Otherwise,
>
> Acked-by: Kevin Hilman
>
>
Regards,
Gururaja
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [v2][PATCH 2/7] book3e/kexec/kdump: enable kexec for kernel
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Tiejun
> Chen
> Sent: Thursday, June 20, 2013 1:23 PM
> To: b...@kernel.crashing.org
> Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Subject: [v2][PATCH 2/7] book3e/kexec/kdump: enable kexec for kernel
>
> We need to active KEXEC for book3e and bypass or convert non-book3e stuff
> in kexec coverage.
>
> Signed-off-by: Tiejun Chen
> ---
> arch/powerpc/Kconfig |2 +-
> arch/powerpc/kernel/machine_kexec_64.c |6 ++
> arch/powerpc/kernel/misc_64.S |6 ++
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index c33e3ad..6ecf3c9 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -364,7 +364,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
>
> config KEXEC
> bool "kexec system call"
> - depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP))
> + depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP)) || PPC_BOOK3E
> help
> kexec is a system call that implements the ability to shutdown your
> current kernel, and to start another kernel. It is like a reboot
> diff --git a/arch/powerpc/kernel/machine_kexec_64.c
> b/arch/powerpc/kernel/machine_kexec_64.c
> index 611acdf..ef39271 100644
> --- a/arch/powerpc/kernel/machine_kexec_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_64.c
> @@ -33,6 +33,7 @@
> int default_machine_kexec_prepare(struct kimage *image)
> {
> int i;
> +#ifndef CONFIG_PPC_BOOK3E
> unsigned long begin, end; /* limits of segment */
> unsigned long low, high;/* limits of blocked memory range */
> struct device_node *node;
> @@ -41,6 +42,7 @@ int default_machine_kexec_prepare(struct kimage *image)
>
> if (!ppc_md.hpte_clear_all)
> return -ENOENT;
> +#endif
Do we really need this function for book3e? can we have a separate function
rather than multiple confusing ifdef?
-Bharat
>
> /*
>* Since we use the kernel fault handlers and paging code to
> @@ -51,6 +53,7 @@ int default_machine_kexec_prepare(struct kimage *image)
> if (image->segment[i].mem < __pa(_end))
> return -ETXTBSY;
>
> +#ifndef CONFIG_PPC_BOOK3E
> /*
>* For non-LPAR, we absolutely can not overwrite the mmu hash
>* table, since we are still using the bolted entries in it to
> @@ -92,6 +95,7 @@ int default_machine_kexec_prepare(struct kimage *image)
> return -ETXTBSY;
> }
> }
> +#endif
>
> return 0;
> }
> @@ -367,6 +371,7 @@ void default_machine_kexec(struct kimage *image)
> /* NOTREACHED */
> }
>
> +#ifndef CONFIG_PPC_BOOK3E
> /* Values we need to export to the second kernel via the device tree. */
> static unsigned long htab_base;
>
> @@ -411,3 +416,4 @@ static int __init export_htab_values(void)
> return 0;
> }
> late_initcall(export_htab_values);
> +#endif
> diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
> index 6820e45..f1a7ce7 100644
> --- a/arch/powerpc/kernel/misc_64.S
> +++ b/arch/powerpc/kernel/misc_64.S
> @@ -543,9 +543,13 @@ _GLOBAL(kexec_sequence)
> lhz r25,PACAHWCPUID(r13)/* get our phys cpu from paca */
>
> /* disable interrupts, we are overwriting kernel data next */
> +#ifndef CONFIG_PPC_BOOK3E
> mfmsr r3
> rlwinm r3,r3,0,17,15
> mtmsrd r3,1
> +#else
> + wrteei 0
> +#endif
>
> /* copy dest pages, flush whole dest image */
> mr r3,r29
> @@ -567,10 +571,12 @@ _GLOBAL(kexec_sequence)
> li r6,1
> stw r6,kexec_flag-1b(5)
>
> +#ifndef CONFIG_PPC_BOOK3E
> /* clear out hardware hash page table and tlb */
> ld r5,0(r27) /* deref function descriptor */
> mtctr r5
> bctrl /* ppc_md.hpte_clear_all(void); */
> +#endif
>
> /*
> * kexec image calling is:
> --
> 1.7.9.5
>
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [v2][PATCH 1/7] powerpc/book3e: support CONFIG_RELOCATABLE
> -Original Message- > From: Linuxppc-dev [mailto:linuxppc-dev- > bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Tiejun > Chen > Sent: Thursday, June 20, 2013 1:23 PM > To: b...@kernel.crashing.org > Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org > Subject: [v2][PATCH 1/7] powerpc/book3e: support CONFIG_RELOCATABLE > > book3e is different with book3s since 3s includes the exception > vectors code in head_64.S as it relies on absolute addressing > which is only possible within this compilation unit. So we have > to get that label address with got. > > And when boot a relocated kernel, we should reset ipvr properly again > after .relocate. > > Signed-off-by: Tiejun Chen > --- > arch/powerpc/include/asm/exception-64e.h |8 > arch/powerpc/kernel/exceptions-64e.S | 15 ++- > arch/powerpc/kernel/head_64.S| 22 ++ > arch/powerpc/lib/feature-fixups.c|7 +++ > 4 files changed, 51 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/include/asm/exception-64e.h > b/arch/powerpc/include/asm/exception-64e.h > index 51fa43e..89e940d 100644 > --- a/arch/powerpc/include/asm/exception-64e.h > +++ b/arch/powerpc/include/asm/exception-64e.h > @@ -214,10 +214,18 @@ exc_##label##_book3e: > #define TLB_MISS_STATS_SAVE_INFO_BOLTED > #endif > > +#ifndef CONFIG_RELOCATABLE > #define SET_IVOR(vector_number, vector_offset) \ > li r3,vector_offset@l; \ > ori r3,r3,interrupt_base_book3e@l; \ > mtspr SPRN_IVOR##vector_number,r3; > +#else > +#define SET_IVOR(vector_number, vector_offset) \ > + LOAD_REG_ADDR(r3,interrupt_base_book3e);\ > + rlwinm r3,r3,0,15,0; \ > + ori r3,r3,vector_offset@l; \ > + mtspr SPRN_IVOR##vector_number,r3; > +#endif > > #endif /* _ASM_POWERPC_EXCEPTION_64E_H */ > > diff --git a/arch/powerpc/kernel/exceptions-64e.S > b/arch/powerpc/kernel/exceptions-64e.S > index 645170a..4b23119 100644 > --- a/arch/powerpc/kernel/exceptions-64e.S > +++ b/arch/powerpc/kernel/exceptions-64e.S > @@ -1097,7 +1097,15 @@ skpinv:addir6,r6,1 > /* > Increment */ > * r4 = MAS0 w/TLBSEL & ESEL for the temp mapping > */ > /* Now we branch the new virtual address mapped by this entry */ > +#ifdef CONFIG_RELOCATABLE > + /* We have to find out address from lr. */ > + bl 1f /* Find our address */ > +1: mflrr6 > + addir6,r6,(2f - 1b) > + tovirt(r6,r6) > +#else > LOAD_REG_IMMEDIATE(r6,2f) > +#endif > lis r7,MSR_KERNEL@h > ori r7,r7,MSR_KERNEL@l > mtspr SPRN_SRR0,r6 > @@ -1348,9 +1356,14 @@ _GLOBAL(book3e_secondary_thread_init) > mflrr28 > b 3b > > -_STATIC(init_core_book3e) > +_GLOBAL(init_core_book3e) > /* Establish the interrupt vector base */ > +#ifdef CONFIG_RELOCATABLE > + tovirt(r2,r2) > + LOAD_REG_ADDR(r3, interrupt_base_book3e) > +#else > LOAD_REG_IMMEDIATE(r3, interrupt_base_book3e) > +#endif > mtspr SPRN_IVPR,r3 > sync > blr > diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S > index b61363d..0942f3a 100644 > --- a/arch/powerpc/kernel/head_64.S > +++ b/arch/powerpc/kernel/head_64.S > @@ -414,12 +414,22 @@ _STATIC(__after_prom_start) > /* process relocations for the final address of the kernel */ > lis r25,PAGE_OFFSET@highest /* compute virtual base of kernel */ > sldir25,r25,32 > +#if defined(CONFIG_PPC_BOOK3E) > + tovirt(r26,r26) /* on booke, we already run at > PAGE_OFFSET */ > +#endif > lwz r7,__run_at_load-_stext(r26) > +#if defined(CONFIG_PPC_BOOK3E) > + tophys(r26,r26) /* Restore for the remains. */ > +#endif > cmplwi cr0,r7,1/* flagged to stay where we are ? */ > bne 1f > add r25,r25,r26 > 1: mr r3,r25 > bl .relocate > +#if defined(CONFIG_PPC_BOOK3E) > + /* We should set ivpr again after .relocate. */ > + bl .init_core_book3e > +#endif > #endif > > /* > @@ -447,12 +457,24 @@ _STATIC(__after_prom_start) > * variable __run_at_load, if it is set the kernel is treated as relocatable > * kernel, otherwise it will be moved to PHYSICAL_START > */ > +#if defined(CONFIG_PPC_BOOK3E) > + tovirt(r26,r26) /* on booke, we already run at > PAGE_OFFSET */ > +#endif > lwz r7,__run_at_load-_stext(r26) > +#if defined(CONFIG_PPC_BOOK3E) > + tophys(r26,r26) /* Restore for the remains. */ > +#endif > cmplwi cr0,r7,1 > bne 3f > > +#ifdef CONFIG_PPC_BOOK3E > + LOAD_REG_ADDR(r5, interrupt_end_book3e) > + LOAD_REG_ADDR(r11, _stext) > + sub r5,r5,r11 > +#else > /* just copy interrupts */ > LOAD_REG_IMMEDIATE(r5, __end_interrupts - _stext) > +#endif >
Re: [PATCH RFC nohz_full v2 2/7] nohz_full: Add rcu_dyntick data for scalable detection of all-idle state
On Mon, 2013-07-01 at 12:16 -0700, Paul E. McKenney wrote: > On Mon, Jul 01, 2013 at 11:34:13AM -0700, Josh Triplett wrote: > > > > This also naturally raises the question "How can we let userspace get > > > > accurate time without forcing a timer tick?". > > > > > > We don't. ;-) > > > > We don't currently, hence my question about how we can. :) > > Per-CPU atomic clocks? Great idea, who needs timekeeping code. http://www.euronews.com/2013/04/02/swiss-sets-sights-on-miniscule-atomic-clock/ -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: udevd cannot modprobe snd-hda-intel with 3.9.8
* Marc Haber [130701 17:50]: > The issue does not appear when one uses a Debian kernel, or uses the > configuration that Debian uses for its kernels to build a vanilla > kernel.org kernel. This has, after a gazillion of reoboots and > experimenting with man different blacklist entries and kernel > configuration, led me to the fact that this bug does not show if the > kernel is compiled with CONFIG_SND_SUPPORT_OLD_API=y. > So it was my error to dump backwards compatibility and to remove the > old api support. I have now set CONFIG_SND_SUPPORT_OLD_API=y again and > everything is fine. Even with this option, I get the problem, so this is not enough... -- Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/11] tracing: trace event triggers
On 2013/7/1 20:32, Masami Hiramatsu wrote: > (2013/06/29 18:30), zhangwei(Jovi) wrote: >>> This patchset implements 'trace event triggers', which are similar to >>> the function triggers implemented for 'ftrace filter commands' (see >>> 'Filter commands' in Documentation/trace/ftrace.txt), but instead of >>> being invoked from function calls are invoked by trace events. >>> Basically the patchset allows 'commands' to be triggered whenever a >>> given trace event is hit. The set of commands implemented by this >>> patchset are: >>> >>> - enable/disable_event - enable or disable another event whenever >>>the trigger event is hit >>> >>> - stacktrace - dump a stacktrace to the trace buffer whenever the >>>trigger event is hit >>> >>> - snapshot - create a snapshot of the current trace buffer whenever >>>the trigger event is hit >>> >>> - traceon/traceoff - turn tracing on or off whenever the trigger >>>event is hit >>> >>> Triggers can also be conditionally invoked by associating a standard >>> trace event filter with them - if the given event passes the filter, >>> the trigger is invoked, otherwise it's not. (see 'Event filtering' in >>> Documentation/trace/events.txt for info on event filters). >>> >> >> I just aware that we are implementing more and more scripting functionality >> into >> tracing subsystem, like filter and trigger mode, of cause we don't call it >> as scripting, but basically the pattern is same, all is "do something when >> event hit". > > Agreed, that's a good direction to handle event by script in kernel :) > That may be simply done with an extension of "event trigger". Of course > your ktap work will be the next step for ftrace. But I think, the basic > implementation can be done by just passing recorded event entry to > each action. (other works are for debugfs management) > And that could be a generic trace-event interface for other users too. > Fully agree "passing recorded event entry to each action". Actually there already have this interface, it's perf. struct perf_event * perf_event_create_kernel_counter(struct perf_event_attr *attr, int cpu, struct task_struct *task, perf_overflow_handler_t callback, void *context); As we known, each event has a id, register this id in perf_event_attr, and give a callback function, then it will call the callback function when event hit. void overflow_callback(struct perf_event *event, struct perf_sample_data *data, struct pt_regs *regs) the recorded event entry is passed as data->raw->data; This perf interface is a generic action trigger interface now, it support tracepoint, k(ret)probe, u(ret)probe, PMU, hw_breakpoint(perhaps we could implement PMU and hw_breakpoint trigger in future) So why we need to reinvent another trigger interface as this patchset did? (this patchset changed lots of places, include macro in ftrace.h, and will change more if support kprobe/uprobe trigger in future.) jovi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v3.9] [v3.10] [Regression] serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller
On Mon, Jul 01, 2013 at 12:14:45PM -0400, Joseph Salisbury wrote: > Hi Wang, > > A bug was opened against the Ubuntu kernel[0]. After a kernel bisect, > it was found that reverting the following commit resolved this bug: > > commit 8d2f8cd424ca0b99001f3ff4f5db87c4e525f366 > Author: Wang YanQing > Date: Fri Mar 1 11:47:20 2013 +0800 > > serial: 8250_pci: add support for another kind of NetMos Technology > PCI 9835 Multi-I/O Controller > > > The regression was introduced as of v3.9-rc3 and still exists in the > current Mainline tree. It was also propagated to the stable trees. > > The patch causes the device to use the serial module instead of > parport_serial. Maybe the the quirk in ~drivers/pci/quirks.c > quirk_netmos() needs to be modified? > > I see that you are the author of this patch, so I wanted to run this by > you. I was thinking of requesting a revert, but I wanted to get your > feedback first. > > > Thanks, > > Joe Hi all, I am sorry for it and later reply. But I am sure I have included the parport_serial in the kernel for my consumers at the time they report their PCI 9835 Multi-I/O Controller didn't work which cause this "culprit" patch. I don't have the card in hand right now, so I can't dig into it. After stare into parport_serial.c, yes, it seems like it will handle this pci serial card. Maybe I forget or miss something, I hope. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is it desirable to improve the build system?
On Mon, Jul 01, 2013 at 05:12:01PM -0700, Mark Galeck wrote: > Dear Linux-Kernel Community, > > I am a consultant specializing in builds, and I recently worked for a > large client company, a world-wide leader in its field, where I > overhauled their build system: sped it up by more of an order of > magnitude, and improved maintainability, for example making > comment-to-code ratio approach 1:1. > > A part of their build is a modified Linux kernel. I rebuilt it > countless times in various configurations, but made only a few further > changes, because those improvements would have a small effect on the > whole system, and because they want to stay close to your current > release for ease of porting. > > From that limited experience, it nevertheless seemed to me, that the > Linux kernel build, while correct, is somewhat slow, and the sources > could be more readable. How is it "slow"? And it has to be correct, fast and non-correct doesn't work well, does it :) What "sources" are you referring to as being not readable? > Does the Linux-Kernel Community perceive that is the case? > > If so, do you think it is possible to improve? > > If so, would such an attempt be welcome, including and especially by, > the current maintainer(s) of the build? Of course it would have to be > completely backwards-compatible, including to the text output > interface and requirements for modules makefiles. Patches are always gladly accepted, if they work well, please feel free to submit them. > I do apologize if my impressions are simply the result of > unfamilliarity and naivete, and that I don't understand the deep > reasons why "it has to be this way", and that I am unaware that such > attempts were already made by some very skilled people. What do you not understand that you think could be changed? Have you looked at the history of the build code to help understand why things were changed to be they way they are? git should help you out here. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched: smart wake-affine
Since RFC:
Tested again with the latest tip 3.10.0-rc7.
wake-affine stuff is always trying to pull wakee close to waker, by theory,
this will bring benefit if waker's cpu cached hot data for wakee, or the
extreme ping-pong case.
And testing show it could benefit hackbench 15% at most.
However, the whole stuff is somewhat blindly and time-consuming, some
workload therefore suffer.
And testing show it could damage pgbench 50% at most.
Thus, wake-affine stuff should be more smart, and realise when to stop
it's thankless effort.
This patch introduced 'nr_wakee_switch', which will be increased each
time the task switch it's wakee.
So a high 'nr_wakee_switch' means the task has more than one wakee, and
bigger the number, higher the wakeup frequency.
Now when making the decision on whether to pull or not, pay attention on
the wakee with a high 'nr_wakee_switch', pull such task may benefit wakee,
but also imply that waker will face cruel competition later, it could be
very cruel or very fast depends on the story behind 'nr_wakee_switch',
whatever, waker therefore suffer.
Furthermore, if waker also has a high 'nr_wakee_switch', imply that multiple
tasks rely on it, then waker's higher latency will damage all of them, pull
wakee seems to be a bad deal.
Thus, when 'waker->nr_wakee_switch / wakee->nr_wakee_switch' become higher
and higher, the deal seems to be worse and worse.
The patch therefore help wake-affine stuff to stop it's work when:
wakee->nr_wakee_switch > factor &&
waker->nr_wakee_switch > (factor * wakee->nr_wakee_switch)
The factor here is the online cpu number, and more cpu will lead to more pull
since the trial become more severe.
After applied the patch, pgbench show 40% improvement at most.
Test:
Test with 12 cpu X86 server and tip 3.10.0-rc7.
basesmart
| db_size | clients | tps | | tps |
+-+-+---+ +---+
| 22 MB | 1 | 10598 | | 10693 |
| 22 MB | 2 | 21257 | | 21409 |
| 22 MB | 4 | 41386 | | 41517 |
| 22 MB | 8 | 51253 | | 58173 |
| 22 MB | 12 | 48570 | | 53817 |
| 22 MB | 16 | 46748 | | 55992 | +19.77%
| 22 MB | 24 | 44346 | | 56087 | +26.48%
| 22 MB | 32 | 43460 | | 54781 | +26.05%
| 7484 MB | 1 | 8951 | | 9336 |
| 7484 MB | 2 | 19233 | | 19348 |
| 7484 MB | 4 | 37239 | | 37316 |
| 7484 MB | 8 | 46087 | | 49329 |
| 7484 MB | 12 | 42054 | | 49231 |
| 7484 MB | 16 | 40765 | | 51082 | +25.31%
| 7484 MB | 24 | 37651 | | 52740 | +40.08%
| 7484 MB | 32 | 37056 | | 50866 | +37.27%
| 15 GB | 1 | 8845 | | 9124 |
| 15 GB | 2 | 19094 | | 19187 |
| 15 GB | 4 | 36979 | | 37178 |
| 15 GB | 8 | 46087 | | 50075 |
| 15 GB | 12 | 41901 | | 48098 |
| 15 GB | 16 | 40147 | | 51463 | +28.19%
| 15 GB | 24 | 37250 | | 51750 | +38.93%
| 15 GB | 32 | 36470 | | 50807 | +39.31%
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Mike Galbraith
Signed-off-by: Michael Wang
---
include/linux/sched.h |3 +++
kernel/sched/fair.c | 45 +
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 178a8d9..1c996c7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1041,6 +1041,9 @@ struct task_struct {
#ifdef CONFIG_SMP
struct llist_node wake_entry;
int on_cpu;
+ struct task_struct *last_wakee;
+ unsigned long nr_wakee_switch;
+ unsigned long last_switch_decay;
#endif
int on_rq;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c61a614..591c113 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3109,6 +3109,45 @@ static inline unsigned long effective_load(struct
task_group *tg, int cpu,
#endif
+static void record_wakee(struct task_struct *p)
+{
+ /*
+* Rough decay, don't worry about the boundary, really active
+* task won't care the loose.
+*/
+ if (jiffies > current->last_switch_decay + HZ) {
+ current->nr_wakee_switch = 0;
+ current->last_switch_decay = jiffies;
+ }
+
+ if (current->last_wakee != p) {
+ current->last_wakee = p;
+ current->nr_wakee_switch++;
+ }
+}
+
+static int nasty_pull(struct task_struct *p)
+{
+ int factor = cpumask_weight(cpu_online_mask);
+
+ /*
+* Yeah, it's the switching-frequency, could means many wakee or
+* rapidly switch, use factor here will just help to automatically
+* adjust the loose-degree, so more cpu will lead to more pull.
+
Re: [RFC][PATCH] mm: madvise: MADV_POPULATE for quick pre-faulting
On 07/01/2013 07:37 PM, Zheng Liu wrote: > FWIW, it would be great if we can let MAP_POPULATE flag support shared > mappings because in our product system there has a lot of applications > that uses mmap(2) and then pre-faults this mapping. Currently these > applications need to pre-fault the mapping manually. Are you sure it doesn't? From a cursory look at the code, it looked to me like it would populate anonymous and file-backed, but I didn't double-check experimentally. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vfs: remove the unnecessrary code of fs/inode.c
On Mon, Jul 01, 2013 at 08:19:03AM -0400, Dong Fang wrote: > These functions, such as find_inode_fast() and find_inode(), iget_lock() and > iget5_lock(), insert_inode_locked() and insert_inode_locked4(), almost have > the same code. NAK. These functions exist exactly because the variant with callbacks costs more. We walk the hash chain and for each inode on it your variant would result in * call * fetching ino from memory * comparison (and storing result in general-purpose register) * return * checking that register and branch on the result of that check What's more, the whole thing's not fun for branch predictor. It is a hot enough path to warrant a special-cased variant; if we can't get away with that, we use the variants with callbacks, but on filesystems where ->i_ino is sufficient as search key we really want to avoid the overhead. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] vmpressure: implement strict mode
On Mon, Jul 01, 2013 at 05:22:36PM +0900, Hyunhee Kim wrote:
> >> > > for each event in memory.pressure_level; do
> >> > > /* register eventfd to be notified on "event" */
> >> > > done
> >> >
> >> > This scheme registers "all" events.
> >>
> >> Yes, because I thought that's the user-case that matters for activity
> >> manager :)
> >
> > Some activity managers use only low levels (Android), some might use only
> > medium levels (simple load-balancing).
>
> When the platform like Android uses only "low" level, is it the
> process you intended when designing vmpressure?
>
> 1. activity manager receives "low" level events
> 2. it reads and checks the current memory (e.g. available memory) using vmstat
> 3. if the available memory is not under the threshold (defined e.g. by
> activity manager), activity manager does nothing
> 4. if the available memory is under the threshold, activity manager
> handles it by e.g. reclaiming or killing processes?
Yup, exactly.
> At first time when I saw this vmpressure, I thought that I should
> register all events ("low", "medium", and "critical
> ") and use different handler for each event. However, without the mode
> like strict mode, I should see too many events. So, now, I think that
> it is better to use only one level and run each handler after checking
> available memory as you mentioned.
Yup, this should work ideally.
> But,
>
> 1. Isn't it overhead to read event and check memory state every time
> we receive events?
Even if it is an overhead, is it measurable? Plus, vmstat/memcg stats are
the only source of information that Activity Manager can use to make a
decision, so there is no point in duplicating the information in the
notifications.
> - sometimes, even when there are lots of available memory, low
> level event could occur if most of them is reclaimable memory not free
> pages.
The point of low level is to signal [any] reclaiming activity. So, yes,
> - Don't most of platforms use available memory to judge their
> current memory state?
No, because you hardly want to monitor available memory only. You want to
take into account the level of the page caches, etc.
> Is there any reason vmpressure use reclaim rate?
Yes, you can refer to this email:
http://lkml.org/lkml/2012/10/4/145
And here is about the levels thing:
http://lkml.org/lkml/2012/10/22/177
> IMO, activity manager doesn't have to check available memory if it
> could receive signal based on the available memory.
But userspace can define its own policy of managing the tasks/resouces
based on different factors, other than just available memory. And that is
exactly why we don't filter the events in the kernel anymore. The only
filtering that we make is the levels, which, as it appears, can work for
many use-cases.
> 2. If we use only "medium" to avoid the overheads occurred when using
> "low" level, isn't it possible to miss sending events when there is a
> little available memory but reclaim ratio is high?
If your app don't "trust" reclaim ratio idicator, then the application can
use its own heuristics, using low level just to monitor reclaiming
activity. More than that, you can change vmpressure itself to use
different heuristics for low/med/crit levels: the point of introducing
levels was also to hide the implementation and memory management details,
so if you can come up with a better approach for vmpressure "internals"
you are more than welcome to do so. :)
> IMHO, we cannot consider and cover all the use cases, but considering
> some use cases and giving some guides and directions to use this
> vmpressure will be helpful to make many platform accept this for their
> low memory manager.
Can't argue with that. :) I guess I will need to better document current
behavior of the levels and when exactly the events trigger.
Thanks!
Anton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vfs: remove the unnecessrary code of fs/inode.c
On 07/01/2013 08:19 PM, Dong Fang wrote:
> These functions, such as find_inode_fast() and find_inode(), iget_lock() and
> iget5_lock(), insert_inode_locked() and insert_inode_locked4(), almost have
> the same code.
Maybe the title "[PATCH] vfs: remove the reduplicate code of fs/inode.c" is more
suitable.
>
> Signed-off-by: Dong Fang
Reviewed-by: Gu Zheng
Thanks,
Gu
> ---
> fs/inode.c | 134
>
> 1 files changed, 26 insertions(+), 108 deletions(-)
>
> diff --git a/fs/inode.c b/fs/inode.c
> index 00d5fc3..847eee9 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -790,6 +790,22 @@ void prune_icache_sb(struct super_block *sb, int
> nr_to_scan)
> }
>
> static void __wait_on_freeing_inode(struct inode *inode);
> +
> +
> +static int test_ino(struct inode *inode, void *data)
> +{
> + unsigned long ino = *(unsigned long *) data;
> + return inode->i_ino == ino;
Can be more concise:
return inode->i_ino == *(unsigned long *) data;
,so does the new insert_inode_locked():
> +}
> +
> +static int set_ino(struct inode *inode, void *data)
> +{
> + inode->i_ino = *(unsigned long *) data;
> + return 0;
> +}
> +
> +
> +
> /*
> * Called with the inode lock held.
> */
> @@ -829,28 +845,7 @@ repeat:
> static struct inode *find_inode_fast(struct super_block *sb,
> struct hlist_head *head, unsigned long ino)
> {
> - struct inode *inode = NULL;
> -
> -repeat:
> - hlist_for_each_entry(inode, head, i_hash) {
> - spin_lock(>i_lock);
> - if (inode->i_ino != ino) {
> - spin_unlock(>i_lock);
> - continue;
> - }
> - if (inode->i_sb != sb) {
> - spin_unlock(>i_lock);
> - continue;
> - }
> - if (inode->i_state & (I_FREEING|I_WILL_FREE)) {
> - __wait_on_freeing_inode(inode);
> - goto repeat;
> - }
> - __iget(inode);
> - spin_unlock(>i_lock);
> - return inode;
> - }
> - return NULL;
> + return find_inode(sb, head, test_ino, (void *));
> }
>
> /*
> @@ -1073,50 +1068,7 @@ EXPORT_SYMBOL(iget5_locked);
> */
> struct inode *iget_locked(struct super_block *sb, unsigned long ino)
> {
> - struct hlist_head *head = inode_hashtable + hash(sb, ino);
> - struct inode *inode;
> -
> - spin_lock(_hash_lock);
> - inode = find_inode_fast(sb, head, ino);
> - spin_unlock(_hash_lock);
> - if (inode) {
> - wait_on_inode(inode);
> - return inode;
> - }
> -
> - inode = alloc_inode(sb);
> - if (inode) {
> - struct inode *old;
> -
> - spin_lock(_hash_lock);
> - /* We released the lock, so.. */
> - old = find_inode_fast(sb, head, ino);
> - if (!old) {
> - inode->i_ino = ino;
> - spin_lock(>i_lock);
> - inode->i_state = I_NEW;
> - hlist_add_head(>i_hash, head);
> - spin_unlock(>i_lock);
> - inode_sb_list_add(inode);
> - spin_unlock(_hash_lock);
> -
> - /* Return the locked inode with I_NEW set, the
> - * caller is responsible for filling in the contents
> - */
> - return inode;
> - }
> -
> - /*
> - * Uhhuh, somebody else created the same inode under
> - * us. Use the old inode instead of the one we just
> - * allocated.
> - */
> - spin_unlock(_hash_lock);
> - destroy_inode(inode);
> - inode = old;
> - wait_on_inode(inode);
> - }
> - return inode;
> + return iget5_locked(sb, ino, test_ino, set_ino, (void *));
> }
> EXPORT_SYMBOL(iget_locked);
>
> @@ -1281,48 +1233,6 @@ struct inode *ilookup(struct super_block *sb, unsigned
> long ino)
> }
> EXPORT_SYMBOL(ilookup);
>
> -int insert_inode_locked(struct inode *inode)
> -{
> - struct super_block *sb = inode->i_sb;
> - ino_t ino = inode->i_ino;
> - struct hlist_head *head = inode_hashtable + hash(sb, ino);
> -
> - while (1) {
> - struct inode *old = NULL;
> - spin_lock(_hash_lock);
> - hlist_for_each_entry(old, head, i_hash) {
> - if (old->i_ino != ino)
> - continue;
> - if (old->i_sb != sb)
> - continue;
> - spin_lock(>i_lock);
> - if (old->i_state & (I_FREEING|I_WILL_FREE)) {
> - spin_unlock(>i_lock);
> - continue;
> - }
> - break;
> - }
> -
Re: [PATCH] sched: fix cpu utilization account error
On 2013/7/2 11:20, Michael Wang wrote:
> Hi, Xie
>
> On 07/01/2013 07:26 PM, Xie XiuQi wrote:
> [snip]
>> Here is the kthread main logic. Although it's not a good idea, but it does
>> exist:
>> while (!kthread_should_stop()) {
>> /* call schedule every 1 sec */
>> if (HZ <= jiffies - last) {
>> last = jiffies;
>> schedule();
>> }
>>
>> /* get data and sent it */
>> get_msg();
>> send_msg();
>
> What about use cond_resched() here? Isn't that more gentle?
>
That's a good idea for driver implementation.
Thank you Michael.
> Regards,
> Michael Wang
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix cpu utilization account error
On 2013/7/2 11:07, Mike Galbraith wrote:
> On Mon, 2013-07-01 at 19:26 +0800, Xie XiuQi wrote:
>
>> Here is the kthread main logic. Although it's not a good idea, but it does
>> exist:
>
> Why not fix this instead?
>
>> while (!kthread_should_stop()) {
>> /* call schedule every 1 sec */
>> if (HZ <= jiffies - last) {
>> last = jiffies;
>> schedule();
>> }
>
> Hanging out in the kernel for ages is not cool. That doesn't mean
> something else might not pop up that forces the issue, but to date it
> has not, and sacrificing precious fastpath cycles is not attractive.
>
That is to say, the driver's code needs improvement.
Thank you Mike.
> -Mike
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] proc: Add workaround for idle/iowait decreasing problem.
Hi Frederic,
I'm sorry it's taken me so long to respond; I got sidetracked for
a while. Comments follow below.
On 2013/04/28 09:49, Frederic Weisbecker wrote:
On Tue, Apr 23, 2013 at 09:45:23PM +0900, Tetsuo Handa wrote:
CONFIG_NO_HZ=y can cause idle/iowait values to decrease.
[...]
It's not clear in the changelog why you see non-monotonic idle/iowait values.
Looking at the previous patch from Fernando, it seems that's because we can
race with concurrent updates from the CPU target when it wakes up from idle?
(could be updated by drivers/cpufreq/cpufreq_governor.c as well).
If so the bug has another symptom: we may also report a wrong iowait/idle time
by accounting the last idle time twice.
In this case we should fix the bug from the source, for example we can force
the given ordering:
= Write side = = Read side =
// tick_nohz_start_idle()
write_seqcount_begin(ts->seq)
ts->idle_entrytime = now
ts->idle_active = 1
write_seqcount_end(ts->seq)
// tick_nohz_stop_idle()
write_seqcount_begin(ts->seq)
ts->iowait_sleeptime += now - ts->idle_entrytime
t->idle_active = 0
write_seqcount_end(ts->seq)
// get_cpu_iowait_time_us()
do {
seq = read_seqcount_begin(ts->seq)
if (t->idle_active) {
time = now - ts->idle_entrytime
time += ts->iowait_sleeptime
} else {
time = ts->iowait_sleeptime
}
} while (read_seqcount_retry(ts->seq,
seq));
Right? seqcount should be enough to make sure we are getting a consistent
result.
I doubt we need harder locking.
I tried that and it doesn't suffice. The problem that causes the most
serious skews is related to the CPU scheduler: the per-run queue
counter nr_iowait can be updated not only from the CPU it belongs
to but also from any other CPU if tasks are migrated out while
waiting on I/O.
The race looks like this:
CPU0CPU1
[ CPU1_rq->nr_iowait == 0 ]
Task foo: io_schedule()
schedule()
[ CPU1_rq->nr_iowait == 1) ]
Task foo migrated to CPU0
Goes to sleep
// get_cpu_iowait_time_us(1, NULL)
[ CPU1_ts->idle_active == 1, CPU1_rq->nr_iowait == 1 ]
[ CPU1_ts->iowait_sleeptime = 4, CPU1_ts->idle_entrytime = 3 ]
now = 5
delta = 5 - 3 = 2
iowait = 4 + 2 = 6
Task foo wakes up
[ CPU1_rq->nr_iowait == 0 ]
CPU1 comes out of sleep state
tick_nohz_stop_idle()
update_ts_time_stats()
[ CPU1_ts->idle_active == 1,
CPU1_rq->nr_iowait == 0 ]
[ CPU1_ts->iowait_sleeptime = 4,
CPU1_ts->idle_entrytime = 3 ]
now = 6
delta = 6 - 3 = 3
(CPU1_ts->iowait_sleeptime is not updated)
CPU1_ts->idle_entrytime = now = 6
CPU1_ts->idle_active = 0
// get_cpu_iowait_time_us(1, NULL)
[ CPU1_ts->idle_active == 0, CPU1_rq->nr_iowait == 0 ]
[ CPU1_ts->iowait_sleeptime = 4, CPU1_ts->idle_entrytime = 6 ]
iowait = CPU1_ts->iowait_sleeptime = 4
(iowait decreased from 6 to 4)
Another thing while at it. It seems that an update done from
drivers/cpufreq/cpufreq_governor.c
(calling get_cpu_iowait_time_us() -> update_ts_time_stats()) can randomly race
with a CPU
entering/exiting idle. I have no idea why drivers/cpufreq/cpufreq_governor.c
does the update
itself. It can just compute the delta like any reader. May be we could remove
that and only
ever call update_ts_time_stats() from the CPU that exit idle.
What do you think?
I am all for it. We just need to make sure that CPU governors
can cope with non-monotonic idle and iowait times. I'll take
a closer look at the code but I wouldn't mind if Arjan (CCed)
beat me at that.
Thanks,
Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sched: context tracking demolishes pipe-test
On Mon, 2013-07-01 at 11:20 +0200, Mike Galbraith wrote: > On Mon, 2013-07-01 at 11:12 +0200, Mike Galbraith wrote: > > On Mon, 2013-07-01 at 10:06 +0200, Peter Zijlstra wrote: > > > > > So aside from the context tracking stuff, there's still a regression > > > we might want to look at. That's still a ~10% drop against 2.6.32 for > > > TCP_RR and few percents for tbench. > > > > Yeah, known, and some of it's ours. > > (btw tbench has a ~5% phase-of-moon jitter, you can pretty much > disregard that one) Hm. Seems we don't own much of TCP_RR regression after all, somewhere along the line while my silly-tester hat was moldering, we got some cycles back.. in the light config case anyway. With wakeup granularity set to zero, per pipe-test, scheduler is within variance of .32, sometimes appearing a tad lighter, though usually a wee bit heavier. TCP_RR throughput delta does not correlate. echo 0 > sched_wakeup_granularity_ns pipe-test 2.6.32-regress689.8 Khz1.000 3.10.0-regress682.5 Khz .989 netperf TCP_RR 2.6.32-regress 117910.11 Trans/sec 1.000 3.10.0-regress96955.12 Trans/sec.822 It should be closer than this. 3.10.0-regress 2.6.32-regress 3.85% [kernel][k] tcp_ack 4.04% [kernel][k] tcp_sendmsg 3.34% [kernel][k] __schedule 3.63% [kernel][k] schedule 2.93% [kernel][k] tcp_sendmsg 2.86% [kernel][k] tcp_recvmsg 2.54% [kernel][k] tcp_rcv_established 2.83% [kernel][k] tcp_ack 2.26% [kernel][k] tcp_transmit_skb 2.19% [kernel][k] system_call 1.90% [kernel][k] __netif_receive_skb_core 2.16% [kernel][k] tcp_transmit_skb 1.87% [kernel][k] tcp_v4_rcv 2.07% libc-2.14.1.so [.] __libc_recv 1.84% [kernel][k] tcp_write_xmit 1.95% [kernel][k] _spin_lock_bh 1.70% [kernel][k] __switch_to 1.89% libc-2.14.1.so [.] __libc_send 1.57% [kernel][k] tcp_recvmsg 1.77% [kernel][k] tcp_rcv_established 1.54% [kernel][k] _raw_spin_lock_bh1.70% [kernel][k] netif_receive_skb 1.52% libc-2.14.1.so [.] __libc_recv 1.61% [kernel][k] tcp_v4_rcv 1.43% [kernel][k] ip_rcv 1.49% [kernel][k] native_sched_clock 1.35% [kernel][k] local_bh_enable 1.49% [kernel][k] tcp_write_xmit 1.33% [kernel][k] _raw_spin_lock_irqsave 1.46% [kernel][k] __switch_to 1.26% [kernel][k] ip_queue_xmit1.35% [kernel][k] dev_queue_xmit 1.16% [kernel][k] __inet_lookup_established1.29% [kernel][k] __alloc_skb 1.14% [kernel][k] mod_timer1.27% [kernel][k] skb_release_data 1.13% [kernel][k] process_backlog 1.26% netserver [.] recv_tcp_rr 1.13% [kernel][k] read_tsc 1.22% [kernel][k] local_bh_enable 1.13% libc-2.14.1.so [.] __libc_send 1.18% netperf [.] send_tcp_rr 1.12% [kernel][k] system_call 1.18% [kernel][k] sched_clock_local 1.07% [kernel][k] tcp_event_data_recv 1.11% [kernel][k] copy_user_generic_string 1.04% [kernel][k] ip_finish_output 1.07% [kernel][k] _spin_lock_irqsave -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/11] tracing: trace event triggers
On 2013/7/1 23:49, Tom Zanussi wrote: > Hi jovi, > > On Sat, 2013-06-29 at 17:30 +0800, zhangwei(Jovi) wrote: >> On 2013/6/29 13:08, Tom Zanussi wrote: >>> Hi, >>> >>> This is v2 of the trace event triggers patchset, addressing comments >>> from Masami Hiramatsu, zhangwei(Jovi), and Steve Rostedt (thanks for >>> reviewing v1). >>> >>> v2: >>> - removed all changes to __ftrace_event_enable_disable() (except >>>for patch 04/11 which clears the soft_disabled bit as discussed) >>>and created a separate trace_event_trigger_enable_disable() that >>>calls it after setting/clearing the TRIGGER_MODE_BIT. >>> - added a trigger_mode enum for future patches that break up the >>>trigger calls for filtering, but that's also now used as a command >>>id for registering/unregistering commands. >>> - removed the enter_file/exit_file members that were added to >>>syscall_metadata after realizing that they were unnecessary if >>>ftrace_syscall_enter/exit() were modified to receive a pointer >>>to the ftrace_file instead of the pointer to the trace_array in >>>the ftrace_file. >>> - broke up the trigger invocation into two parts so that triggers >>>like 'stacktrace' that themselves log into the trace buffer can >>>defer the actual trigger invocation until after the current >>>record is closed, which is needed for the filter check that >>>in turn determines whether the trigger gets invoked. >>> - other minor cleanup >>> >>> >>> This patchset implements 'trace event triggers', which are similar to >>> the function triggers implemented for 'ftrace filter commands' (see >>> 'Filter commands' in Documentation/trace/ftrace.txt), but instead of >>> being invoked from function calls are invoked by trace events. >>> Basically the patchset allows 'commands' to be triggered whenever a >>> given trace event is hit. The set of commands implemented by this >>> patchset are: >>> >>> - enable/disable_event - enable or disable another event whenever >>>the trigger event is hit >>> >>> - stacktrace - dump a stacktrace to the trace buffer whenever the >>>trigger event is hit >>> >>> - snapshot - create a snapshot of the current trace buffer whenever >>>the trigger event is hit >>> >>> - traceon/traceoff - turn tracing on or off whenever the trigger >>>event is hit >>> >>> Triggers can also be conditionally invoked by associating a standard >>> trace event filter with them - if the given event passes the filter, >>> the trigger is invoked, otherwise it's not. (see 'Event filtering' in >>> Documentation/trace/events.txt for info on event filters). >>> >> >> I just aware that we are implementing more and more scripting functionality >> into >> tracing subsystem, like filter and trigger mode, of cause we don't call it >> as scripting, but basically the pattern is same, all is "do something when >> event hit". >> > > Not really - this patchset is just reusing the existing filter code > that's been there for years, and yes, it does follow the pattern of > 'doing something when an event is hit', but the things it does are > really dirt simple - toggling of other events or the global tracing > on/off switch, snapshotting trace buffers, etc. All things that don't > require any kind of scripting - this is more on the level of wiring > things together on a breadboard. And it's all available by simply using > 'cat' and 'echo' - no separate command and scripts to keep track of. > >> FYI, a pretty simple scripting module of tracing is there: >> https://github.com/ktap/ktap.git >> > > It looks pretty nice, but I wonder if Linux is ready for a full-fledged > language interpreter in the kernel. It's been tried before - see > DProbes (in fact that effort is where kprobes came from - after it was > obvious DProbes wouldn't make it into the kernel, it was broken up into > multiple pieces - kprobes and uprobes eventually got in, but the RPN > interpreter, which also had an ANSI C compiler targeting the bytecode > (dpcc) never did...). Well, following that, DTrace came along and > showed how useful it could be, so maybe there wouldn't be as much > resistance these days... Actually ktap is very lightweight compare with Dtrace and other tools, it doesn't reinvent tracing interface, it make use on kprobe/uprobe/tracepoint/perf, it doesn't engage with debugging info, just a simple script interface for tracing, as demoed in example, the tracing interface is same as perf. > > Also, assuming an in-kernel language interpreter would fly, did you > consider starting with something already-baked rather than starting from > scratch? How about taking something like the parrot VM and carving out > a minimal core subset of that suitable for embedding in the kernel? It > probably wouldn't be easy, but you'd be building on a relatively mature > and tested VM that's been designed for targeting many languages > (including lua). > ktap is building on mature interpreter(lua) which
Re: [PATCH 0/6] Introducing Device Tree Overlays
On Mon, Jul 01, 2013 at 12:46:24PM +0300, Pantelis Antoniou wrote: > Hi Guenter, > > Yes there is an updated patchset against 3.10 as of this morning. > > I will post details how to get it later today. > Hi Pantelis, looking forward to it. I see you have a large number of new branches in your repository. It would help a lot to know which patches from which branch I need to get DT overlay support to work. For example, the mainline-pdev-fixes branch seems relevant, but that is not immediately obvious (and may be a wrong assumption). Are you trying to get the patches in the various branches into the upstream kernel ? Thanks a lot! Guenter > Regards > > -- Pantelis > > On Jun 29, 2013, at 5:38 AM, Guenter Roeck wrote: > > > On Fri, Jan 04, 2013 at 09:31:04PM +0200, Pantelis Antoniou wrote: > >> The following patchset introduces Device Tree overlays, a method > >> of dynamically altering the kernel's live Device Tree. > >> > >> This patchset is against mainline as of Friday Jan 4 2013. > >> (4956964 Merge tag 'driver-core-3.8-rc2' of \ > >>git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) > >> > >> Note that a separate patch for the DTC compiler has been posted and > >> is required to compile the DTS files according to the documentation. > >> The patch is "dtc: Dynamic symbols & fixup support" > >> > >> An implementation patchset for a beaglebone cape loader will follow, > >> but if you want to check out a working kernel for the beaglebone please > >> pull from: > >> > >> git://github.com/pantoniou/linux-bbxm.git branch not-capebus-v8 > >> > >> Pantelis Antoniou (6): > >> OF: Introduce device tree node flag helpers. > >> OF: export of_property_notify > >> OF: Export all DT proc update functions > >> OF: Introduce utility helper functions > >> OF: Introduce Device Tree resolve support. > >> OF: Introduce DT overlay support. > >> > > Hi Pantelis, > > > > do you have an update of this patchset ? I want to seriously start testing > > it. > > Digging through your tree on github is a bit cumbersome, and I am not sure > > if I got all patches. It would also be nice to get an update with all the > > comments addressed. > > > > Thanks, > > Guenter > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: Fix possible sleep in invalid context
On 7/2/2013 8:34 AM, Aaron Lu wrote: Fix this by releasing spin_lock_irq() before calling >pm_runtime_autosuspend() in blk_post_runtime_resume(). Hi Sujit, Thanks for testing out block layer runtime PM! As for the problem here, it is already fixed by: commit c60855cdb976c632b3bf8922eeab8a0e78edfc04 Author: Aaron Lu Date: Fri May 17 15:47:20 2013 +0800 blkpm: avoid sleep when holding queue lock Thanks Aaron. I see that is merged in 3.10-rc6. Please ignore this patch. -- Regards, Sujit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0
Thanks George, this looks fine. I will munge the description a bit when
I commit it, and mark it for stable as well.
Unfortunately, due to the timing of the merge window, this patch will
have to wait for 2-3 weeks until 3.11-rc1 is out.
Sarah Sharp
On Mon, Jul 01, 2013 at 10:59:12AM +0530, George Cherian wrote:
> Xhci controllers with hci_version > 0.96 gives spurious success
> events on short packet completion. During webcam capture the
> "ERROR Transfer event TRB DMA ptr not part of current TD" was observed.
> The same application works fine with synopsis controllers hci_version 0.96.
> The same Issue is seen with Intel Pantherpoint xhci controller. So enabling
> this quirk in xhci_gen_setup if controller verion is greater than 0.96.
> For xhci-pci move the quirk to much generic place xhci_gen_setup.
>
> Signed-off-by: George Cherian
> ---
> drivers/usb/host/xhci-pci.c | 1 -
> drivers/usb/host/xhci.c | 7 +++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index cc24e39..f00cb20 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -93,7 +93,6 @@ static void xhci_pci_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> }
> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
> pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
> - xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
> xhci->quirks |= XHCI_EP_LIMIT_QUIRK;
> xhci->limit_active_eps = 64;
> xhci->quirks |= XHCI_SW_BW_CHECKING;
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index d8f640b..0f7be59 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -4697,6 +4697,13 @@ int xhci_gen_setup(struct usb_hcd *hcd,
> xhci_get_quirks_t get_quirks)
>
> get_quirks(dev, xhci);
>
> + /* In xhci controllers which follow xhci 1.0 spec gives a spurious
> + * success event after a short transfer. This quirk will ignore such
> + * spurious event.
> + */
> + if (xhci->hci_version > 0x96)
> + xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
> +
> /* Make sure the HC is halted. */
> retval = xhci_halt(xhci);
> if (retval)
> --
> 1.8.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/13] sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards
Hi Richard,
Will move this patch before 5, 6, 7?
On 7/1/2013 16:39, Richard Genoud wrote:
From: Nicolas Ferre
Description of the Asoc machine driver for an at91sam9x5 based board
with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
master on the SSC/I2S interface. Its connections are a headphone jack
and an Line input jack.
[Richard: this is based on an old patch from Nicolas that I forward
ported and reworked to use only device tree]
Signed-off-by: Nicolas Ferre
Signed-off-by: Uwe Kleine-König
Signed-off-by: Richard Genoud
---
sound/soc/atmel/Kconfig | 12 ++
sound/soc/atmel/Makefile|2 +
sound/soc/atmel/sam9x5_wm8731.c | 232 +++
3 files changed, 246 insertions(+)
create mode 100644 sound/soc/atmel/sam9x5_wm8731.c
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 3fdd87f..f24d601 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -13,6 +13,7 @@ config SND_ATMEL_SOC_PDC
config SND_ATMEL_SOC_DMA
tristate
depends on SND_ATMEL_SOC
+ select SND_SOC_DMAENGINE_PCM
config SND_ATMEL_SOC_SSC
tristate
@@ -32,6 +33,17 @@ config SND_AT91_SOC_SAM9G20_WM8731
Say Y if you want to add support for SoC audio on WM8731-based
AT91sam9g20 evaluation board.
+config SND_AT91_SOC_SAM9X5_WM8731
+ tristate "SoC Audio support for WM8731-based at91sam9x5 board"
+ depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
+ select SND_ATMEL_SOC_SSC
+ select SND_ATMEL_SOC_DMA
+ select SND_ATMEL_SOC_PDC
Not need to select SND_ATMEL_SOC_PDC
+ select SND_SOC_WM8731
+ help
+ Say Y if you want to add support for audio SoC on an
+ at91sam9x5 based board that is using WM8731 codec.
+
config SND_AT91_SOC_AFEB9260
tristate "SoC Audio support for AFEB9260 board"
depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 &&
SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 41967cc..7784c09 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
# AT91 Machine Support
snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
+snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
+obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
new file mode 100644
index 000..83ca457
--- /dev/null
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -0,0 +1,232 @@
+/*
+ * sam9x5_wm8731 -- SoC audio for AT91SAM9X5-based boards
+ * that are using WM8731 as codec.
+ *
+ * Copyright (C) 2011 Atmel,
+ * Nicolas Ferre
+ *
+ * Based on sam9g20_wm8731.c by:
+ * Sedji Gaouaou
+ *
+ * GPL
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "../codecs/wm8731.h"
+#include "atmel-pcm.h"
+#include "atmel_ssc_dai.h"
+
+#define MCLK_RATE 12288000
+
+#define DRV_NAME "sam9x5-snd-wm8731"
+
+/*
+ * Audio paths on at91sam9x5ek board:
+ *
+ * |A| > | | ---R> Headphone Jack
+ * |T| <\| WM | ---L--/
+ * |9| ---> CLK <--> | 8751 | <--R- Line In Jack
+ * |1| < | | <--L--/
+ */
+static const struct snd_soc_dapm_widget at91sam9x5ek_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Headphone Jack", NULL),
+ SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+/*
+ * Logic for a wm8731 as connected on a at91sam9x5 based board.
+ */
+static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_codec *codec = rtd->codec;
+ struct snd_soc_dai *codec_dai = rtd->codec_dai;
+ struct snd_soc_dapm_context *dapm = >dapm;
+ struct device *dev = rtd->dev;
+ int ret;
+
+ dev_dbg(dev, "ASoC: at91sam9x5ek_wm8731_init() called\n");
+
+ /*
+* remove some not supported rates in relation with clock
+* provided to the wm8731 codec
+*/
+ switch (MCLK_RATE) {
+ case 12288000:
+ codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
+SNDRV_PCM_RATE_32000 |
+SNDRV_PCM_RATE_48000 |
+SNDRV_PCM_RATE_96000;
+ codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
+ SNDRV_PCM_RATE_32000 |
+ SNDRV_PCM_RATE_48000 |
+ SNDRV_PCM_RATE_96000;
+
Re: [PATCH] sched: fix cpu utilization account error
Hi, Xie
On 07/01/2013 07:26 PM, Xie XiuQi wrote:
[snip]
> Here is the kthread main logic. Although it's not a good idea, but it does
> exist:
> while (!kthread_should_stop()) {
> /* call schedule every 1 sec */
> if (HZ <= jiffies - last) {
> last = jiffies;
> schedule();
> }
>
> /* get data and sent it */
> get_msg();
> send_msg();
What about use cond_resched() here? Isn't that more gentle?
Regards,
Michael Wang
>
> if (kthread_should_stop())
> break;
> }
>
>> That said, accounting funnies induced by skipped update are possible,
>> which could trump the cycle savings I suppose, so maybe savings (sniff)
>> should just go away?
>
> Indeed, removing the skip_clock_update could resolve the issue, but I found
> there is no this issue in preempt mode. However, if remove skip_clock_update
> we'll get more precise time account.
>
> So, what's your opinion, Mike.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix cpu utilization account error
On Mon, 2013-07-01 at 19:26 +0800, Xie XiuQi wrote:
> Here is the kthread main logic. Although it's not a good idea, but it does
> exist:
Why not fix this instead?
> while (!kthread_should_stop()) {
> /* call schedule every 1 sec */
> if (HZ <= jiffies - last) {
> last = jiffies;
> schedule();
> }
Hanging out in the kernel for ages is not cool. That doesn't mean
something else might not pop up that forces the issue, but to date it
has not, and sacrificing precious fastpath cycles is not attractive.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 03/13] ARM: at91: DTS: sam9x5: add clock for SSC DT entry
Hi Richard,
On 7/1/2013 16:39, Richard Genoud wrote:
Signed-off-by: Richard Genoud
---
arch/arm/mach-at91/at91sam9x5.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
index 2abee66..191eb4b 100644
--- a/arch/arm/mach-at91/at91sam9x5.c
+++ b/arch/arm/mach-at91/at91sam9x5.c
@@ -233,6 +233,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("mci_clk", "f000c000.mmc", _clk),
CLKDEV_CON_DEV_ID("dma_clk", "ec00.dma-controller", _clk),
CLKDEV_CON_DEV_ID("dma_clk", "ee00.dma-controller", _clk),
+ CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", _clk),
Actually, we don't use this anymore. Am I right?
CLKDEV_CON_DEV_ID("pclk", "f001.ssc", _clk),
CLKDEV_CON_DEV_ID(NULL, "f801.i2c", _clk),
CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", _clk),
Best Regards,
Bo Shen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 02/13] misc: atmel_ssc: keep the count of pdev->id
Hi Richard,
On 7/1/2013 16:39, Richard Genoud wrote:
With device tree, pdev->id is always -1, so we introduce a local
counter.
Signed-off-by: Richard Genoud
---
drivers/misc/atmel-ssc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 3afbd82..d1ec5ab 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -173,6 +173,12 @@ out:
return err;
}
+/* counter of ssc devive instances.
+ * With device tree pdev->id is always -1, so we have to keep the
+ * count ourselves
+ */
+static int ssc_device_id;
Do we really need this? If Yes, would it better to get from device
through of_alias_get_id?
+
static int ssc_probe(struct platform_device *pdev)
{
struct resource *regs;
@@ -235,6 +241,7 @@ static int ssc_probe(struct platform_device *pdev)
}
spin_lock(_lock);
+ pdev->id = ssc_device_id++;
list_add_tail(>list, _list);
spin_unlock(_lock);
Best Regards,
Bo Shen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: Fix possible sleep in invalid context
On 07/01/2013 11:28 PM, Sujit Reddy Thumma wrote:
> When block runtime PM is enabled following warning is seen
> while resuming the device.
>
> BUG: sleeping function called from invalid context at
> .../drivers/base/power/runtime.c:923
> in_atomic(): 1, irqs_disabled(): 128, pid: 12, name: kworker/0:1
> [] (unwind_backtrace+0x0/0x120) from
> [] (__pm_runtime_suspend+0x34/0xa0) from
> [] (blk_post_runtime_resume+0x4c/0x5c) from
> [] (scsi_runtime_resume+0x90/0xb4) from
> [] (__rpm_callback+0x30/0x58) from
> [] (rpm_callback+0x18/0x28) from
> [] (rpm_resume+0x3dc/0x540) from
> [] (pm_runtime_work+0x8c/0x98) from
> [] (process_one_work+0x238/0x3e4) from
> [] (worker_thread+0x1ac/0x2ac) from
> [] (kthread+0x88/0x94) from
> [] (kernel_thread_exit+0x0/0x8)
>
> Fix this by releasing spin_lock_irq() before calling
> pm_runtime_autosuspend() in blk_post_runtime_resume().
Hi Sujit,
Thanks for testing out block layer runtime PM!
As for the problem here, it is already fixed by:
commit c60855cdb976c632b3bf8922eeab8a0e78edfc04
Author: Aaron Lu
Date: Fri May 17 15:47:20 2013 +0800
blkpm: avoid sleep when holding queue lock
-Aaron
>
> Signed-off-by: Sujit Reddy Thumma
> Cc: sta...@vger.kernel.org
> ---
> block/blk-core.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 33c33bc..2456116 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -3159,16 +3159,18 @@ EXPORT_SYMBOL(blk_pre_runtime_resume);
> */
> void blk_post_runtime_resume(struct request_queue *q, int err)
> {
> - spin_lock_irq(q->queue_lock);
> if (!err) {
> + spin_lock_irq(q->queue_lock);
> q->rpm_status = RPM_ACTIVE;
> __blk_run_queue(q);
> pm_runtime_mark_last_busy(q->dev);
> + spin_unlock_irq(q->queue_lock);
> pm_runtime_autosuspend(q->dev);
> } else {
> + spin_lock_irq(q->queue_lock);
> q->rpm_status = RPM_SUSPENDED;
> + spin_unlock_irq(q->queue_lock);
> }
> - spin_unlock_irq(q->queue_lock);
> }
> EXPORT_SYMBOL(blk_post_runtime_resume);
> #endif
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
Hi Richard, On 7/1/2013 16:39, Richard Genoud wrote: The ssc device has to fill the at_dma_slave structure with the device tree informations. Doing a of_dma_request_slave_channel()+dma_release_channel() for that seems wrong (or at least not very clean). Please hold on of this, as to the ASoC dmaengine will deal with this. So, we not need do it manually. Now, I am working on it. And will send out the patch soon after testing OK. Signed-off-by: Richard Genoud --- drivers/misc/atmel-ssc.c| 56 +++ include/linux/atmel-ssc.h |2 ++ include/linux/platform_data/dma-atmel.h |2 ++ 3 files changed, 60 insertions(+) Best Regards, Bo Shen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [draft] Tracing multibuffer support concurrency issues
On Mon, Jul 1, 2013 at 6:35 PM, Steven Rostedt wrote: > On Mon, 2013-07-01 at 15:33 -0700, Alexander Lam wrote: > >> To fix this we could go through the ftrace_trace_arrays list and use >> addresses to check if a particular pointer to a trace_array is still >> valid, but this is vulnerable to the ABA problem if a trace_array is >> freed and another is reallocated at the same address. This method is >> used by subsystem_open() in trace_events.c > > And what's so bad about that? If it is freed and a new one is allocated > at the same address, let it return crap. I'm much more interested in not > letting it crash then caring about inconsistent data from someone that's > doing crazy things to the system. I figured you might say something like that. I agree with you on this. >> >> An ugly way to get around the ABA issue is to use a monotonically >> increasing ID # for each trace_array instance. Those IDs could be used >> instead of pointers when creating debugfs files. > > Not worth it. > >> >> Is there a better way to fix this problem? >> >> Also unaddressed are all of the other files which use a trace_array, >> trace_cpu, or ftrace_event_file in their operation - these would need >> the same fix. > > Hmm, really? Just the initiator. That is, when an event is enabled or > anything gets opened, we block deletion from happening. That way we > don't need to care about the rest. Only open and enabling events. Yes, I did mean the initiator, but I meant the "search for this pointer in a list" would have to be applied for each of those struct types because they were being passed through inode->i_private. I see how this isn't a problem anymore after looking at your patch. It didn't occur to me that checking the tr field of those structs before using other pointers in the struct would also work. Thanks, Alex > > -- Steve > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V2 2/2] sched: update cfs_rq weight earlier in enqueue_entity
Paul,
On Mon, Jul 1, 2013 at 10:07 PM, Paul Turner wrote:
> Could you please restate the below?
>
> On Mon, Jul 1, 2013 at 5:33 AM, Lei Wen wrote:
>> Since we are going to calculate cfs_rq's average ratio by
>> runnable_load_avg/load.weight
>
> I don't understand what you mean by this.
Previously I take runnable_load_avg/load.weight calculation as the cfs_rq's
average ratio. But as Alex point out, the runnable_avg_sum/runnable_avg_period
may better sever this need.
>
>>, if not increase the load.weight prior to
>> enqueue_entity_load_avg, it may lead to one cfs_rq's avg ratio higher
>> than 100%.
>>
>
> Or this.
In my mind, runnable_load_avg in one cfs_rq should always be less than
load.weight.
Not sure whether this assumption stand here, but runnable_load_avg/load.weight
truly could shows out the cfs_rq execution trend in some aspect.
The previous problem that enqueue_entity_load_avg called before
account_entity_enqueue,
which make runnable_load_avg be updated first, then the load.weight.
So that with the trace info log inside of enqueue_entity_load_avg, we
may get the calculation
result for runnable_load_avg/load.weight > 1.
This result is not friendly for the final data being parsed out.
>
>> Adjust the sequence, so that all ratio is kept below 100%.
>>
>> Signed-off-by: Lei Wen
>> ---
>> kernel/sched/fair.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 07bd74c..d1eee84 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -1788,8 +1788,8 @@ enqueue_entity(struct cfs_rq *cfs_rq, struct
>> sched_entity *se, int flags)
>> * Update run-time statistics of the 'current'.
>> */
>> update_curr(cfs_rq);
>> - enqueue_entity_load_avg(cfs_rq, se, flags & ENQUEUE_WAKEUP);
>> account_entity_enqueue(cfs_rq, se);
>> + enqueue_entity_load_avg(cfs_rq, se, flags & ENQUEUE_WAKEUP);
>
> account_entity_enqueue is independent of enqueue_entity_load_avg;
> their order should not matter.
Yes, agree, the order should not be matter, but for make trace info
integrated, we may
need some order here.
>
> Further, should we restore the reverted amortization commit (improves
> context switch times)
Not understand here...
What the "should we restore the reverted amortization commit (improves
context switch times)" means here...?
enqueue_entity_load_avg needs to precede
> account_entity_enqueue as it may update se->load.weight.
account_entity_enqueue needs to precede enqueue_entity_load_avg?
Thanks,
Lei
>
>> update_cfs_shares(cfs_rq);
>>
>> if (flags & ENQUEUE_WAKEUP) {
>> --
>> 1.7.10.4
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
Hi Alexandre, On Mon, Jun 24, 2013 at 2:24 PM, Alexandre Belloni wrote: > From: Maxime Ripard > > The ADCs connected to this bus have been experiencing some timeout > issues when using the iMX28 i2c controller. Switching back to bitbanging > solves this. Are you able to use the mxs i2c controller instead of bitbang if you use this patch? http://www.spinics.net/lists/stable/msg13202.html Regards, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] tracing: Protect ftrace_trace_arrays list in trace_events.c
There are multiple places where the ftrace_trace_arrays list is accessed in
trace_events.c without the trace_types_lock held.
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c| 2 +-
kernel/trace/trace.h| 2 ++
kernel/trace/trace_events.c | 11 ++-
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 2f7307e..35e5e55 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -245,7 +245,7 @@ static struct tracer*trace_types
__read_mostly;
/*
* trace_types_lock is used to protect the trace_types list.
*/
-static DEFINE_MUTEX(trace_types_lock);
+DEFINE_MUTEX(trace_types_lock);
/*
* serialize the access of the ring buffer
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 3de07e0..334dc85 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -225,6 +225,8 @@ enum {
extern struct list_head ftrace_trace_arrays;
+extern struct mutex trace_types_lock;
+
/*
* The global tracer (top) should be the first trace array added,
* but we check the flag anyway.
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 6db3290..1b14751 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -987,6 +987,7 @@ static int subsystem_open(struct inode *inode, struct file
*filp)
int ret;
/* Make sure the system still exists */
+ mutex_lock(_types_lock);
mutex_lock(_mutex);
list_for_each_entry(tr, _trace_arrays, list) {
list_for_each_entry(dir, >systems, list) {
@@ -1002,6 +1003,7 @@ static int subsystem_open(struct inode *inode, struct
file *filp)
}
exit_loop:
mutex_unlock(_mutex);
+ mutex_unlock(_types_lock);
if (!system)
return -ENODEV;
@@ -1586,6 +1588,7 @@ static void __add_event_to_tracers(struct
ftrace_event_call *call,
int trace_add_event_call(struct ftrace_event_call *call)
{
int ret;
+ mutex_lock(_types_lock);
mutex_lock(_mutex);
ret = __register_event(call, NULL);
@@ -1593,11 +1596,13 @@ int trace_add_event_call(struct ftrace_event_call *call)
__add_event_to_tracers(call, NULL);
mutex_unlock(_mutex);
+ mutex_unlock(_types_lock);
return ret;
}
/*
- * Must be called under locking both of event_mutex and trace_event_sem.
+ * Must be called under locking of trace_types_lock, event_mutex and
+ * trace_event_sem.
*/
static void __trace_remove_event_call(struct ftrace_event_call *call)
{
@@ -1609,11 +1614,13 @@ static void __trace_remove_event_call(struct
ftrace_event_call *call)
/* Remove an event_call */
void trace_remove_event_call(struct ftrace_event_call *call)
{
+ mutex_lock(_types_lock);
mutex_lock(_mutex);
down_write(_event_sem);
__trace_remove_event_call(call);
up_write(_event_sem);
mutex_unlock(_mutex);
+ mutex_unlock(_types_lock);
}
#define for_each_event(event, start, end) \
@@ -1757,6 +1764,7 @@ static int trace_module_notify(struct notifier_block
*self,
{
struct module *mod = data;
+ mutex_lock(_types_lock);
mutex_lock(_mutex);
switch (val) {
case MODULE_STATE_COMING:
@@ -1767,6 +1775,7 @@ static int trace_module_notify(struct notifier_block
*self,
break;
}
mutex_unlock(_mutex);
+ mutex_unlock(_types_lock);
return 0;
}
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [draft] Tracing multibuffer support concurrency issues
On Mon, 2013-07-01 at 21:35 -0400, Steven Rostedt wrote:
> >
> > Is there a better way to fix this problem?
> >
> > Also unaddressed are all of the other files which use a trace_array,
> > trace_cpu, or ftrace_event_file in their operation - these would need
> > the same fix.
>
> Hmm, really? Just the initiator. That is, when an event is enabled or
> anything gets opened, we block deletion from happening. That way we
> don't need to care about the rest. Only open and enabling events.
I added two helper functions to handle this. trace_array_get() and
trace_array_put(). This patch prevents your example from crashing.
This probably needs to be added to opening of other files if not already
done.
-- Steve
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index e36da7f..89a3930 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -204,6 +204,37 @@ static struct trace_array global_trace;
LIST_HEAD(ftrace_trace_arrays);
+int trace_array_get(struct trace_array *this_tr)
+{
+ struct trace_array *tr;
+ int ret = -ENODEV;
+
+ mutex_lock(_types_lock);
+ list_for_each_entry(tr, _trace_arrays, list) {
+ if (tr == this_tr) {
+ tr->ref++;
+ ret = 0;
+ break;
+ }
+ }
+ mutex_unlock(_types_lock);
+
+ return ret;
+}
+
+static void __trace_array_put(struct trace_array *this_tr)
+{
+ WARN_ON(!this_tr->ref);
+ this_tr->ref--;
+}
+
+void trace_array_put(struct trace_array *this_tr)
+{
+ mutex_lock(_types_lock);
+ __trace_array_put(this_tr);
+ mutex_unlock(_types_lock);
+}
+
int filter_current_check_discard(struct ring_buffer *buffer,
struct ftrace_event_call *call, void *rec,
struct ring_buffer_event *event)
@@ -2831,10 +2862,9 @@ static const struct seq_operations tracer_seq_ops = {
};
static struct trace_iterator *
-__tracing_open(struct inode *inode, struct file *file, bool snapshot)
+__tracing_open(struct trace_array *tr, struct trace_cpu *tc,
+ struct inode *inode, struct file *file, bool snapshot)
{
- struct trace_cpu *tc = inode->i_private;
- struct trace_array *tr = tc->tr;
struct trace_iterator *iter;
int cpu;
@@ -2913,8 +2943,6 @@ __tracing_open(struct inode *inode, struct file *file,
bool snapshot)
tracing_iter_reset(iter, cpu);
}
- tr->ref++;
-
mutex_unlock(_types_lock);
return iter;
@@ -2944,17 +2972,20 @@ static int tracing_release(struct inode *inode, struct
file *file)
struct trace_array *tr;
int cpu;
- if (!(file->f_mode & FMODE_READ))
+ /* Writes do not use seq_file, need to grab tr from inode */
+ if (!(file->f_mode & FMODE_READ)) {
+ struct trace_cpu *tc = inode->i_private;
+
+ trace_array_put(tc->tr);
return 0;
+ }
iter = m->private;
tr = iter->tr;
+ trace_array_put(tr);
mutex_lock(_types_lock);
- WARN_ON(!tr->ref);
- tr->ref--;
-
for_each_tracing_cpu(cpu) {
if (iter->buffer_iter[cpu])
ring_buffer_read_finish(iter->buffer_iter[cpu]);
@@ -2973,20 +3004,23 @@ static int tracing_release(struct inode *inode, struct
file *file)
kfree(iter->trace);
kfree(iter->buffer_iter);
seq_release_private(inode, file);
+
return 0;
}
static int tracing_open(struct inode *inode, struct file *file)
{
+ struct trace_cpu *tc = inode->i_private;
+ struct trace_array *tr = tc->tr;
struct trace_iterator *iter;
int ret = 0;
+ if (trace_array_get(tr) < 0)
+ return -ENODEV;
+
/* If this file was open for write, then erase contents */
if ((file->f_mode & FMODE_WRITE) &&
(file->f_flags & O_TRUNC)) {
- struct trace_cpu *tc = inode->i_private;
- struct trace_array *tr = tc->tr;
-
if (tc->cpu == RING_BUFFER_ALL_CPUS)
tracing_reset_online_cpus(>trace_buffer);
else
@@ -2994,12 +3028,16 @@ static int tracing_open(struct inode *inode, struct
file *file)
}
if (file->f_mode & FMODE_READ) {
- iter = __tracing_open(inode, file, false);
+ iter = __tracing_open(tr, tc, inode, file, false);
if (IS_ERR(iter))
ret = PTR_ERR(iter);
else if (trace_flags & TRACE_ITER_LATENCY_FMT)
iter->iter_flags |= TRACE_FILE_LAT_FMT;
}
+
+ if (ret < 0)
+ trace_array_put(tr);
+
return ret;
}
@@ -4575,12 +4613,16 @@ struct ftrace_buffer_info {
static int tracing_snapshot_open(struct inode *inode, struct file *file)
{
struct trace_cpu *tc = inode->i_private;
+
Re: [GIT PULL for v3.11] media patches for v3.11
Hi Mauro, On Mon, 1 Jul 2013 07:58:56 -0300 Mauro Carvalho Chehab wrote: > > Please pull from: > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > v4l_for_linus > > For the media patches for Kernel v3.11. I am not sure why you added a back merge of v3.10 before sending this to Linus? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpG9twURwAYx.pgp Description: PGP signature
[PATCH] shdma: fixup sh_dmae_get_partial() calculation error
sh_desc->hw.tcr is controlling data size, and register TCR is controlling data transfer count which was xmit_shift'ed value of hw.tcr. Current sh_dmae_get_partial() is calculating in different unit. This patch fixes it. Cc: Guennadi Liakhovetski Signed-off-by: Kuninori Morimoto --- >> Guennadi Can you please review this patch ? drivers/dma/sh/shdma.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c index b70709b..d670b8b 100644 --- a/drivers/dma/sh/shdma.c +++ b/drivers/dma/sh/shdma.c @@ -388,8 +388,8 @@ static size_t sh_dmae_get_partial(struct shdma_chan *schan, shdma_chan); struct sh_dmae_desc *sh_desc = container_of(sdesc, struct sh_dmae_desc, shdma_desc); - return (sh_desc->hw.tcr - sh_dmae_readl(sh_chan, TCR)) << - sh_chan->xmit_shift; + return sh_desc->hw.tcr - + (sh_dmae_readl(sh_chan, TCR) << sh_chan->xmit_shift); } /* Called from error IRQ or NMI */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] tracing: Protect ftrace_trace_arrays list in trace_events.c
Oh, sorry, that is an incomplete patch; some bits are in a patch I
dropped. I'll send you a new one in about 20 minutes.
- Alex
On Mon, Jul 1, 2013 at 6:25 PM, Steven Rostedt wrote:
> On Mon, 2013-07-01 at 15:31 -0700, Alexander Z Lam wrote:
>> There are multiple places where the ftrace_trace_arrays list is accessed in
>> trace_events.c without the trace_types_lock held.
>
> Hmm, doesn't compile. Not a complete patch? trace_types_lock is local to
> trace.c, and needs to be in trace.h and non static.
>
> -- Steve
>
>>
>> Cc: David Sharp
>> Cc: Alexander Z Lam
>> Signed-off-by: Alexander Z Lam
>> ---
>> kernel/trace/trace_events.c | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
>> index 6db3290..26351cc 100644
>> --- a/kernel/trace/trace_events.c
>> +++ b/kernel/trace/trace_events.c
>> @@ -1586,6 +1586,7 @@ static void __add_event_to_tracers(struct
>> ftrace_event_call *call,
>> int trace_add_event_call(struct ftrace_event_call *call)
>> {
>> int ret;
>> + mutex_lock(_types_lock);
>> mutex_lock(_mutex);
>>
>> ret = __register_event(call, NULL);
>> @@ -1593,11 +1594,13 @@ int trace_add_event_call(struct ftrace_event_call
>> *call)
>> __add_event_to_tracers(call, NULL);
>>
>> mutex_unlock(_mutex);
>> + mutex_unlock(_types_lock);
>> return ret;
>> }
>>
>> /*
>> - * Must be called under locking both of event_mutex and trace_event_sem.
>> + * Must be called under locking of trace_types_lock, event_mutex and
>> + * trace_event_sem.
>> */
>> static void __trace_remove_event_call(struct ftrace_event_call *call)
>> {
>> @@ -1609,11 +1612,13 @@ static void __trace_remove_event_call(struct
>> ftrace_event_call *call)
>> /* Remove an event_call */
>> void trace_remove_event_call(struct ftrace_event_call *call)
>> {
>> + mutex_lock(_types_lock);
>> mutex_lock(_mutex);
>> down_write(_event_sem);
>> __trace_remove_event_call(call);
>> up_write(_event_sem);
>> mutex_unlock(_mutex);
>> + mutex_unlock(_types_lock);
>> }
>>
>> #define for_each_event(event, start, end)\
>> @@ -1757,6 +1762,7 @@ static int trace_module_notify(struct notifier_block
>> *self,
>> {
>> struct module *mod = data;
>>
>> + mutex_lock(_types_lock);
>> mutex_lock(_mutex);
>> switch (val) {
>> case MODULE_STATE_COMING:
>> @@ -1767,6 +1773,7 @@ static int trace_module_notify(struct notifier_block
>> *self,
>> break;
>> }
>> mutex_unlock(_mutex);
>> + mutex_unlock(_types_lock);
>>
>> return 0;
>> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
-linux-arm (wrong email address - sorry) On Mon, Jul 1, 2013 at 6:49 PM, Grant Grundler wrote: > On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote: >> This commit adds cache flush for removed small page and large page >> entries in exynos_iommu_unmap(). Missing cache flush of removed >> page table entries can cause missing page fault interrupt when a >> master IP accesses an unmapped area. > > KyongHo, > It appears this patch was never applied and got caught up in the > device tree binding discussion. AFAICT, this patch is still necessary. > Can you resubmit this patch separately. Or ok if I do? > > Original patch is here: > https://patchwork.kernel.org/patch/1910261/ > > thanks, > grant -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/1] mwifiex: add tx info to skb when forming mgmt frame
From: Huawei Yang
In function 'mwifiex_write_data_complete' it need tx info to find
the mwifiex_private to updates statistics and wake up tx queues.
Or we may trigger tx queues timeout when transmitting lots of mgmt
frames.
Signed-off-by: Huawei Yang
---
drivers/net/wireless/mwifiex/cfg80211.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
b/drivers/net/wireless/mwifiex/cfg80211.c
index e42b266..b4e2538 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -186,6 +186,7 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct
wireless_dev *wdev,
struct sk_buff *skb;
u16 pkt_len;
const struct ieee80211_mgmt *mgmt;
+ struct mwifiex_txinfo *tx_info;
struct mwifiex_private *priv = mwifiex_netdev_get_priv(wdev->netdev);
if (!buf || !len) {
@@ -212,6 +213,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct
wireless_dev *wdev,
wiphy_err(wiphy, "allocate skb failed for management frame\n");
return -ENOMEM;
}
+
+ tx_info = MWIFIEX_SKB_TXCB(skb);
+ tx_info->bss_num = priv->bss_num;
+ tx_info->bss_type = priv->bss_type;
mwifiex_form_mgmt_frame(skb, buf, len);
mwifiex_queue_tx_pkt(priv, skb);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] mm: madvise: MADV_POPULATE for quick pre-faulting
On Mon, Jul 01, 2013 at 09:16:46AM -0700, Dave Hansen wrote: > On 06/28/2013 07:20 PM, Zheng Liu wrote: > >> > IOW, a process needing to do a bunch of MAP_POPULATEs isn't > >> > parallelizable, but one using this mechanism would be. > > I look at the code, and it seems that we will handle MAP_POPULATE flag > > after we release mmap_sem locking in vm_mmap_pgoff(): > > > > down_write(>mmap_sem); > > ret = do_mmap_pgoff(file, addr, len, prot, flag, pgoff, > > ); > > up_write(>mmap_sem); > > if (populate) > > mm_populate(ret, populate); > > > > Am I missing something? > > I went and did my same test using mmap(MAP_POPULATE)/munmap() pair > versus using MADV_POPULATE in 160 threads in parallel. > > MADV_POPULATE was about 10x faster in the threaded configuration. > > With MADV_POPULATE, the biggest cost is shipping the mmap_sem cacheline > around so that we can write the reader count update in to it. With > mmap(), there is a lot of _contention_ on that lock which is much, much > more expensive than simply bouncing a cacheline around. Thanks for your explanation. FWIW, it would be great if we can let MAP_POPULATE flag support shared mappings because in our product system there has a lot of applications that uses mmap(2) and then pre-faults this mapping. Currently these applications need to pre-fault the mapping manually. Regards, - Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.
'asm-generic' need provide necessary configuration checking, if can't
pass checking, 'asm-generic' shouldn't implement it.
For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
let it pass configuration checking, and provide related dummy contents
for it.
Part of 'COMPLE_TEST' help contents in "init/Kconfig":
"...Despite they cannot be loaded there (or even when they load they cannot
be used due to missing HW support)..."
Signed-off-by: Chen Gang
---
include/asm-generic/io.h | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index d5afe96..301ce80 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -303,13 +303,18 @@ static inline void *phys_to_virt(unsigned long address)
/*
* Change "struct page" to physical address.
*
- * This implementation is for the no-MMU case only... if you have an MMU
- * you'll need to provide your own definitions.
+ * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
+ * if you have an MMU and IOMEM, you'll need to provide your own definitions.
*/
-#ifndef CONFIG_MMU
+#if !defined(CONFIG_MMU) || \
+ (!defined(CONFIG_HAS_IOMEM) && defined(CONFIG_COMPILE_TEST))
static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
{
+#if !defined(CONFIG_MMU)
return (void __iomem*) (unsigned long)offset;
+#else
+ return NULL;
+#endif
}
#define __ioremap(offset, size, flags) ioremap(offset, size)
@@ -325,7 +330,7 @@ static inline void __iomem *ioremap(phys_addr_t offset,
unsigned long size)
static inline void iounmap(void __iomem *addr)
{
}
-#endif /* CONFIG_MMU */
+#endif /* !CONFIG_MMU || (!CONFIG_HAS_IOMEM && CONFIG_COMPILE_TEST) */
#ifdef CONFIG_HAS_IOPORT
#ifndef CONFIG_GENERIC_IOMAP
@@ -341,6 +346,15 @@ static inline void ioport_unmap(void __iomem *p)
extern void __iomem *ioport_map(unsigned long port, unsigned int nr);
extern void ioport_unmap(void __iomem *p);
#endif /* CONFIG_GENERIC_IOMAP */
+#elif defined(CONFIG_COMPILE_TEST) /* CONFIG_HAS_IOPORT */
+static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
+{
+ return NULL;
+}
+
+static inline void ioport_unmap(void __iomem *p)
+{
+}
#endif /* CONFIG_HAS_IOPORT */
#ifndef xlate_dev_kmem_ptr
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: block layer softlockup
On Mon, Jul 01, 2013 at 01:57:34PM -0400, Dave Jones wrote:
> On Fri, Jun 28, 2013 at 01:54:37PM +1000, Dave Chinner wrote:
> > On Thu, Jun 27, 2013 at 04:54:53PM -1000, Linus Torvalds wrote:
> > > On Thu, Jun 27, 2013 at 3:18 PM, Dave Chinner
> wrote:
> > > >
> > > > Right, that will be what is happening - the entire system will go
> > > > unresponsive when a sync call happens, so it's entirely possible
> > > > to see the soft lockups on inode_sb_list_add()/inode_sb_list_del()
> > > > trying to get the lock because of the way ticket spinlocks work...
> > >
> > > So what made it all start happening now? I don't recall us having had
> > > these kinds of issues before..
> >
> > Not sure - it's a sudden surprise for me, too. Then again, I haven't
> > been looking at sync from a performance or lock contention point of
> > view any time recently. The algorithm that wait_sb_inodes() is
> > effectively unchanged since at least 2009, so it's probably a case
> > of it having been protected from contention by some external factor
> > we've fixed/removed recently. Perhaps the bdi-flusher thread
> > replacement in -rc1 has changed the timing sufficiently that it no
> > longer serialises concurrent sync calls as much
>
> This mornings new trace reminded me of this last sentence. Related ?
Was this running the last patch I posted, or a vanilla kernel?
> BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child1:7219]
> CPU: 0 PID: 7219 Comm: trinity-child1 Not tainted 3.10.0+ #38
.
> RIP: 0010:[] []
> _raw_spin_unlock_irqrestore+0x67/0x80
.
>
>
> [] blk_end_bidi_request+0x51/0x60
> [] blk_end_request+0x10/0x20
> [] scsi_io_completion+0xf3/0x6e0
> [] scsi_finish_command+0xb0/0x110
> [] scsi_softirq_done+0x12f/0x160
> [] blk_done_softirq+0x88/0xa0
> [] __do_softirq+0xff/0x440
> [] irq_exit+0xcd/0xe0
> [] smp_apic_timer_interrupt+0x6b/0x9b
> [] apic_timer_interrupt+0x6f/0x80
>
That's doing IO completion processing in softirq time, and the lock
it just dropped was the q->queue_lock. But that lock is held over
end IO processing, so it is possible that the way the page writeback
transition handling of my POC patch caused this.
FWIW, I've attached a simple patch you might like to try to see if
it *minimises* the inode_sb_list_lock contention problems. All it
does is try to prevent concurrent entry in wait_sb_inodes() for a
given superblock and hence only have one walker on the contending
filesystem at a time. Replace the previous one I sent with it. If
that doesn't work, I have another simple patch that makes the
inode_sb_list_lock per-sb to take this isolation even further
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
sync: serialise per-superblock sync operations
From: Dave Chinner
When competing sync(2) calls walk the same filesystem, they need to
walk the list of inodes on the superblock to find all the inodes
that we need to wait for IO completion on. However, when multiple
wait_sb_inodes() calls do this at the same time, they contend on the
the inode_sb_list_lock and the contention causes system wide
slowdowns. In effect, concurrent sync(2) calls the take longer and
burn more CPU than if they were serialised.
Stop the worst of the contention by adding a per-sb mutex to wrap
around sync_inodes_sb() so that we only execute one sync(2)
operation at a time per superblock and hence mostly avoid
contention.
Signed-off-by: Dave Chinner
---
fs/fs-writeback.c |9 -
fs/super.c |1 +
include/linux/fs.h |2 ++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 996f91a..4d7a90c 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -1353,7 +1353,12 @@ EXPORT_SYMBOL(try_to_writeback_inodes_sb);
* @sb: the superblock
*
* This function writes and waits on any dirty inode belonging to this
- * super_block.
+ * super_block. The @s_sync_lock is used to serialise concurrent sync
operations
+ * to avoid lock contention problems with concurrent wait_sb_inodes() calls.
+ * This also allows us to optimise wait_sb_inodes() to use private dirty lists
+ * as subsequent sync calls will block waiting for @s_sync_lock and hence
always
+ * wait for the inodes in the private sync lists to be completed before they do
+ * their own private wait.
*/
void sync_inodes_sb(struct super_block *sb)
{
@@ -1372,10 +1377,12 @@ void sync_inodes_sb(struct super_block *sb)
return;
WARN_ON(!rwsem_is_locked(>s_umount));
+ mutex_lock(>s_sync_lock);
bdi_queue_work(sb->s_bdi, );
wait_for_completion();
wait_sb_inodes(sb);
+ mutex_unlock(>s_sync_lock);
}
EXPORT_SYMBOL(sync_inodes_sb);
diff --git a/fs/super.c b/fs/super.c
index 7465d43..887bfbe 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -181,6 +181,7 @@ static struct super_block *alloc_super(struct
file_system_type *type, int flags)
Re: linux-next: build failure after merge of the powerpc tree
On Tue, 2013-07-02 at 10:54 +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> fs/pstore/ftrace.c: In function 'pstore_ftrace_call':
> fs/pstore/ftrace.c:47:6: warning: passing argument 7 of 'psinfo->write_buf'
> makes integer from pointer without a cast [enabled by default]
> sizeof(rec), psinfo);
> ^
> fs/pstore/ftrace.c:47:6: note: expected 'size_t' but argument is of type
> 'struct pstore_info *'
> fs/pstore/ftrace.c:47:6: error: too few arguments to function
> 'psinfo->write_buf'
>
> Caused by commit 6bbbca735936 ("pstore: Pass header size in the pstore
> write callback").
>
> I have used the version from next-20130701 for today.
Interestingly enough I didn't see that when testing a x86_64 build, I
might have failed to test with ftrace enabled.
Aruna, please send a fix ASAP.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] cciss: rework pci pm related code for simplification
Hi Jens,
Sorry to disturb you, do you have any comments for this patch?
Thanks!
Yijing.
On 2013/6/18 16:19, Yijing Wang wrote:
> Use pci core pm interface to simplify code.
>
> Signed-off-by: Yijing Wang
> Cc: Mike Miller
> Cc: iss_storage...@hp.com
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/block/cciss.c | 16 +++-
> 1 files changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
> index 62b6c2c..18da685 100644
> --- a/drivers/block/cciss.c
> +++ b/drivers/block/cciss.c
> @@ -4528,9 +4528,6 @@ static int cciss_message(struct pci_dev *pdev, unsigned
> char opcode,
> static int cciss_controller_hard_reset(struct pci_dev *pdev,
> void * __iomem vaddr, u32 use_doorbell)
> {
> - u16 pmcsr;
> - int pos;
> -
> if (use_doorbell) {
> /* For everything after the P600, the PCI power state method
>* of resetting the controller doesn't work, so we have this
> @@ -4548,8 +4545,7 @@ static int cciss_controller_hard_reset(struct pci_dev
> *pdev,
>* this causes a secondary PCI reset which will reset the
>* controller." */
>
> - pos = pci_find_capability(pdev, PCI_CAP_ID_PM);
> - if (pos == 0) {
> + if (!pdev->pm_cap) {
> dev_err(>dev,
> "cciss_controller_hard_reset: "
> "PCI PM not supported\n");
> @@ -4557,18 +4553,12 @@ static int cciss_controller_hard_reset(struct pci_dev
> *pdev,
> }
> dev_info(>dev, "using PCI PM to reset controller\n");
> /* enter the D3hot power management state */
> - pci_read_config_word(pdev, pos + PCI_PM_CTRL, );
> - pmcsr &= ~PCI_PM_CTRL_STATE_MASK;
> - pmcsr |= PCI_D3hot;
> - pci_write_config_word(pdev, pos + PCI_PM_CTRL, pmcsr);
> + pci_set_power_state(pdev, PCI_D3hot);
>
> msleep(500);
>
> /* enter the D0 power management state */
> - pmcsr &= ~PCI_PM_CTRL_STATE_MASK;
> - pmcsr |= PCI_D0;
> - pci_write_config_word(pdev, pos + PCI_PM_CTRL, pmcsr);
> -
> + pci_set_power_state(pdev, PCI_D0);
> /*
>* The P600 requires a small delay when changing states.
>* Otherwise we may think the board did not reset and we bail.
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote: > This commit adds cache flush for removed small page and large page > entries in exynos_iommu_unmap(). Missing cache flush of removed > page table entries can cause missing page fault interrupt when a > master IP accesses an unmapped area. KyongHo, It appears this patch was never applied and got caught up in the device tree binding discussion. AFAICT, this patch is still necessary. Can you resubmit this patch separately. Or ok if I do? Original patch is here: https://patchwork.kernel.org/patch/1910261/ thanks, grant -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix cpu utilization account error
On 2013/7/1 23:19, Greg KH wrote: > On Mon, Jul 01, 2013 at 02:45:04PM +0800, Xie XiuQi wrote: >> We setting clock_skip_update = 1 based on the assumption that the >> next call to update_rq_clock() will come nearly immediately >> after being set. However, it is not always true especially on >> non-preempt mode. In this case we may miss some clock update, which >> would cause an error curr->sum_exec_runtime account. >> ... > > > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read Documentation/stable_kernel_rules.txt > for how to do this properly. Thanks Greg, I've removed sta...@vger.kernel.org from recipient list now. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] vt6655/trivial: replace numeric with standard PM state macros
On 2013/7/2 9:23, Greg Kroah-Hartman wrote: > On Tue, Jul 02, 2013 at 09:14:06AM +0800, Yijing Wang wrote: >> ping...? > > You are asking yourself the status of a patch? Interesting... > >> On 2013/6/27 20:57, Yijing Wang wrote: > > You sent this after I closed my staging tree, so it will be applied > after 3.11-rc1 is out, don't worry, it's not lost. Hi Greg, I get it, thanks for your reply. Thanks! Yijing. > . > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [draft] Tracing multibuffer support concurrency issues
On Mon, 2013-07-01 at 15:33 -0700, Alexander Lam wrote: > To fix this we could go through the ftrace_trace_arrays list and use > addresses to check if a particular pointer to a trace_array is still > valid, but this is vulnerable to the ABA problem if a trace_array is > freed and another is reallocated at the same address. This method is > used by subsystem_open() in trace_events.c And what's so bad about that? If it is freed and a new one is allocated at the same address, let it return crap. I'm much more interested in not letting it crash then caring about inconsistent data from someone that's doing crazy things to the system. > > An ugly way to get around the ABA issue is to use a monotonically > increasing ID # for each trace_array instance. Those IDs could be used > instead of pointers when creating debugfs files. Not worth it. > > Is there a better way to fix this problem? > > Also unaddressed are all of the other files which use a trace_array, > trace_cpu, or ftrace_event_file in their operation - these would need > the same fix. Hmm, really? Just the initiator. That is, when an event is enabled or anything gets opened, we block deletion from happening. That way we don't need to care about the rest. Only open and enabling events. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/6] ARM, mm: change meaning of max_low_pfn to maximum pfn for nobootmem
On Mon, Jul 01, 2013 at 10:14:45AM -0400, Santosh Shilimkar wrote: > Joonsoo, > > On Monday 25 March 2013 12:11 AM, Joonsoo Kim wrote: > > nobootmem use max_low_pfn for computing boundary in free_all_bootmem() > > So we need proper value to max_low_pfn. > > > > But, there is some difficulty related to max_low_pfn. max_low_pfn is used > > for two meanings in various architectures. One is for number of pages > > in lowmem and the other is for maximum lowmem pfn. Now, in ARM, it is used > > as number of pages in lowmem. You can get more information in below link. > > http://lwn.net/Articles/543408/ > > http://lwn.net/Articles/543424/ > > > > As I investigated, architectures which use max_low_pfn as maximum pfn are > > more than others, so to change meaning of max_low_pfn to maximum pfn > > is preferable solution to me. This patch change max_low_pfn as maximum > > lowmem pfn in ARM. In addition, min_low_pfn, max_pfn is assigned according > > to this criteria. > > > > There is no real user for max_low_pfn except block/blk-setting.c and > > blk-setting.c assume that max_low_pfn is maximum lowmem pfn, > > so this patch may not harm anything. > > > > Signed-off-by: Joonsoo Kim > > > I have been also carrying similar patch as yours in an attempt > to make LPAE kernel work on ARM. Your patch carries better > description, so will your version and include in my series > which I plan to post on the list after some more testing. > Will copy you. The changes are very similar to your series. Okay! Thanks. > > Regards, > Santosh > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] tracing: Protect ftrace_trace_arrays list in trace_events.c
On Mon, 2013-07-01 at 15:31 -0700, Alexander Z Lam wrote:
> There are multiple places where the ftrace_trace_arrays list is accessed in
> trace_events.c without the trace_types_lock held.
Hmm, doesn't compile. Not a complete patch? trace_types_lock is local to
trace.c, and needs to be in trace.h and non static.
-- Steve
>
> Cc: David Sharp
> Cc: Alexander Z Lam
> Signed-off-by: Alexander Z Lam
> ---
> kernel/trace/trace_events.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 6db3290..26351cc 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -1586,6 +1586,7 @@ static void __add_event_to_tracers(struct
> ftrace_event_call *call,
> int trace_add_event_call(struct ftrace_event_call *call)
> {
> int ret;
> + mutex_lock(_types_lock);
> mutex_lock(_mutex);
>
> ret = __register_event(call, NULL);
> @@ -1593,11 +1594,13 @@ int trace_add_event_call(struct ftrace_event_call
> *call)
> __add_event_to_tracers(call, NULL);
>
> mutex_unlock(_mutex);
> + mutex_unlock(_types_lock);
> return ret;
> }
>
> /*
> - * Must be called under locking both of event_mutex and trace_event_sem.
> + * Must be called under locking of trace_types_lock, event_mutex and
> + * trace_event_sem.
> */
> static void __trace_remove_event_call(struct ftrace_event_call *call)
> {
> @@ -1609,11 +1612,13 @@ static void __trace_remove_event_call(struct
> ftrace_event_call *call)
> /* Remove an event_call */
> void trace_remove_event_call(struct ftrace_event_call *call)
> {
> + mutex_lock(_types_lock);
> mutex_lock(_mutex);
> down_write(_event_sem);
> __trace_remove_event_call(call);
> up_write(_event_sem);
> mutex_unlock(_mutex);
> + mutex_unlock(_types_lock);
> }
>
> #define for_each_event(event, start, end)\
> @@ -1757,6 +1762,7 @@ static int trace_module_notify(struct notifier_block
> *self,
> {
> struct module *mod = data;
>
> + mutex_lock(_types_lock);
> mutex_lock(_mutex);
> switch (val) {
> case MODULE_STATE_COMING:
> @@ -1767,6 +1773,7 @@ static int trace_module_notify(struct notifier_block
> *self,
> break;
> }
> mutex_unlock(_mutex);
> + mutex_unlock(_types_lock);
>
> return 0;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] vt6655/trivial: replace numeric with standard PM state macros
On Tue, Jul 02, 2013 at 09:14:06AM +0800, Yijing Wang wrote: > ping...? You are asking yourself the status of a patch? Interesting... > On 2013/6/27 20:57, Yijing Wang wrote: You sent this after I closed my staging tree, so it will be applied after 3.11-rc1 is out, don't worry, it's not lost. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] PCI: acpiphp: do not check for SLOT_ENABLED in enable_device()
On Monday, July 01, 2013 09:36:13 PM Mika Westerberg wrote: > On Mon, Jul 01, 2013 at 04:01:37PM +0200, Rafael J. Wysocki wrote: > > > Given the fact that SLOT_ENABLED is only checked in acpiphp_enable_slot() > > > (after this patch) and that /sys/bus/pci/slots/*/power uses SLOT_POWEREDON > > > anyway, should we remove the whole flag? > > > > Sure, if it is not necessary any more, we should remove it. > > Well, there is one thing that changes due that. Once the flag is gone > userspace can do 'echo 1 > /sys/bus/pci/slots/*/power' several times and > the slot is always re-enumerated. > > If that is not acceptable we should probably move the SLOT_ENABLED check > closer to acpiphp_core:enable_device() and drop it from here, so that we > always re-enumerate on Bus Check event but userspace can only do enable > once (we still re-enumerate on Bus Check). Yes, that sounds like the right thing to do. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ACPI / dock: Rework the handling of notifications
On Monday, July 01, 2013 02:21:45 PM Bjorn Helgaas wrote:
> On Fri, Jun 28, 2013 at 4:53 PM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > The ACPI dock driver uses register_acpi_bus_notifier() which
> > installs a notifier triggered globally for all system notifications.
> > That first of all is inefficient, because the dock driver is only
> > interested in notifications associated with the devices it handles,
> > but it has to handle all system notifies for all devices. Moreover,
> > it does that even if no docking stations are present in the system
> > (CONFIG_ACPI_DOCK set is sufficient for that to happen). Besides,
> > that is inconvenient, because it requires the driver to do extra work
> > for each notification to find the target dock station object.
> >
> > For these reasons, rework the dock driver to install a notify
> > handler individually for each dock station in the system using
> > acpi_install_notify_handler(). This allows the dock station
> > object to be passed directly to the notify handler and makes it
> > possible to simplify the dock driver quite a bit. It also
> > reduces the overhead related to the handling of all system
> > notifies when CONFIG_ACPI_DOCK is set.
>
> I fully support what you're doing, even though I haven't read it in
> enough detail to actually review it. I'm pretty sure that whatever
> you do, you won't make things worse :)
Well, fair enough. :-)
> It sounds like you are keeping the approach of "look for certain AML
> features to identify a dock, and install notify handlers when you find
> one." I think acpiphp uses a similar approach, and I'm not sure it's
> a good one. The spec is not explicit about how the AML should be
> organized, and AML writers are very creative. I think acpiphp suffers
> because it only works with certain arrangements of _ADR, _EJ0, _RMV,
> etc., and I think that has led to a brittle design and possibly more
> separation between dock and acpiphp than is necessary.
I generally agree that this is not a robust approach, but for now I'm avoiding
making changes that may just go too far.
> I think it would be better if we *always* had a more generic notify
> handler installed and figured out where to route the notification
> based on its type and what services are configured in. The ultimate
> handler might do different things based on what methods are present,
> of course.
>
> I don't know if this rambling makes sense for docks (or even for
> acpiphp), so if it doesn't, feel free to just ignore it :)
Well, ideally, it would be great if we could handle all of the bus check,
device check and eject notifications through something like
acpi_hotplug_notify_cb() and dispatch more specific handling from
there depending on what's represented by the target handle. That's why I
introduced hotplug profiles.
That said it's a long way to that point from where we are now. :-)
Thanks,
Rafael
> > Signed-off-by: Rafael J. Wysocki
> > ---
> > drivers/acpi/dock.c | 69
> > ++--
> > 1 file changed, 25 insertions(+), 44 deletions(-)
> >
> > Index: linux-pm/drivers/acpi/dock.c
> > ===
> > --- linux-pm.orig/drivers/acpi/dock.c
> > +++ linux-pm/drivers/acpi/dock.c
> > @@ -718,18 +718,17 @@ static int handle_eject_request(struct d
> >
> > /**
> > * dock_notify - act upon an acpi dock notification
> > - * @handle: the dock station handle
> > + * @ds: dock station
> > * @event: the acpi event
> > - * @data: our driver data struct
> > *
> > * If we are notified to dock, then check to see if the dock is
> > * present and then dock. Notify all drivers of the dock event,
> > * and then hotplug and devices that may need hotplugging.
> > */
> > -static void dock_notify(acpi_handle handle, u32 event, void *data)
> > +static void dock_notify(struct dock_station *ds, u32 event)
> > {
> > - struct dock_station *ds = data;
> > - struct acpi_device *tmp;
> > + acpi_handle handle = ds->handle;
> > + struct acpi_device *ad;
> > int surprise_removal = 0;
> >
> > /*
> > @@ -752,8 +751,7 @@ static void dock_notify(acpi_handle hand
> > switch (event) {
> > case ACPI_NOTIFY_BUS_CHECK:
> > case ACPI_NOTIFY_DEVICE_CHECK:
> > - if (!dock_in_progress(ds) && acpi_bus_get_device(ds->handle,
> > - )) {
> > + if (!dock_in_progress(ds) && acpi_bus_get_device(handle,
> > )) {
> > begin_dock(ds);
> > dock(ds);
> > if (!dock_present(ds)) {
> > @@ -790,9 +788,8 @@ static void dock_notify(acpi_handle hand
> > }
> >
> > struct dock_data {
> > - acpi_handle handle;
> > - unsigned long event;
> > struct dock_station *ds;
> > + u32 event;
> > };
> >
> > static void acpi_dock_deferred_cb(void *context)
> > @@ -800,52 +797,31 @@
Re: [PATCH 4/6] vt6655/trivial: replace numeric with standard PM state macros
ping...?
On 2013/6/27 20:57, Yijing Wang wrote:
> Use standard PM state macros PCI_Dx instead of numeric 0/1/2..
>
> Signed-off-by: Yijing Wang
> Cc: Forest Bond
> Cc: Greg Kroah-Hartman
> Cc: Jiri Kosina
> Cc: Devendra Naga
> Cc :Joe Perches
> Cc: Marcos Paulo de Souza
> Cc: Bill Pemberton
> Cc: de...@driverdev.osuosl.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/staging/vt6655/device_main.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/vt6655/device_main.c
> b/drivers/staging/vt6655/device_main.c
> index 08b250f..7f36a71 100644
> --- a/drivers/staging/vt6655/device_main.c
> +++ b/drivers/staging/vt6655/device_main.c
> @@ -3370,8 +3370,8 @@ viawget_resume(struct pci_dev *pcid)
> PSMgmtObject pMgmt = pDevice->pMgmt;
> int power_status; // to silence the compiler
>
> - power_status = pci_set_power_state(pcid, 0);
> - power_status = pci_enable_wake(pcid, 0, 0);
> + power_status = pci_set_power_state(pcid, PCI_D0);
> + power_status = pci_enable_wake(pcid, PCI_D0, 0);
> pci_restore_state(pcid);
> if (netif_running(pDevice->dev)) {
> spin_lock_irq(>lock);
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kvm_intel: Could not allocate 42 bytes percpu data
On 6/30/2013 11:22 PM, Rusty Russell wrote:
Chegu Vinod writes:
Hello,
Lots (~700+) of the following messages are showing up in the dmesg of a
3.10-rc1 based kernel (Host OS is running on a large socket count box
with HT-on).
[ 82.270682] PERCPU: allocation failed, size=42 align=16, alloc from
reserved chunk failed
[ 82.272633] kvm_intel: Could not allocate 42 bytes percpu data
Woah, weird
Oh. Shit. Um, this is embarrassing.
Thanks,
Rusty.
Thanks for your response!
===
module: do percpu allocation after uniqueness check. No, really!
v3.8-rc1-5-g1fb9341 was supposed to stop parallel kvm loads exhausting
percpu memory on large machines:
Now we have a new state MODULE_STATE_UNFORMED, we can insert the
module into the list (and thus guarantee its uniqueness) before we
allocate the per-cpu region.
In my defence, it didn't actually say the patch did this. Just that
we "can".
This patch actually *does* it.
Signed-off-by: Rusty Russell
Tested-by: Noone it seems.
Your following "updated" fix seems to be working fine on the larger
socket count machine with HT-on.
Thx
Vinod
diff --git a/kernel/module.c b/kernel/module.c
index cab4bce..fa53db8 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2927,7 +2927,6 @@ static struct module *layout_and_allocate(struct
load_info *info, int flags)
{
/* Module within temporary copy. */
struct module *mod;
- Elf_Shdr *pcpusec;
int err;
mod = setup_load_info(info, flags);
@@ -2942,17 +2941,10 @@ static struct module *layout_and_allocate(struct
load_info *info, int flags)
err = module_frob_arch_sections(info->hdr, info->sechdrs,
info->secstrings, mod);
if (err < 0)
- goto out;
+ return ERR_PTR(err);
- pcpusec = >sechdrs[info->index.pcpu];
- if (pcpusec->sh_size) {
- /* We have a special allocation for this section. */
- err = percpu_modalloc(mod,
- pcpusec->sh_size, pcpusec->sh_addralign);
- if (err)
- goto out;
- pcpusec->sh_flags &= ~(unsigned long)SHF_ALLOC;
- }
+ /* We will do a special allocation for per-cpu sections later. */
+ info->sechdrs[info->index.pcpu].sh_flags &= ~(unsigned long)SHF_ALLOC;
/* Determine total sizes, and put offsets in sh_entsize. For now
this is done generically; there doesn't appear to be any
@@ -2963,17 +2955,22 @@ static struct module *layout_and_allocate(struct
load_info *info, int flags)
/* Allocate and move to the final place */
err = move_module(mod, info);
if (err)
- goto free_percpu;
+ return ERR_PTR(err);
/* Module has been copied to its final place now: return it. */
mod = (void *)info->sechdrs[info->index.mod].sh_addr;
kmemleak_load_module(mod, info);
return mod;
+}
-free_percpu:
- percpu_modfree(mod);
-out:
- return ERR_PTR(err);
+static int alloc_module_percpu(struct module *mod, struct load_info *info)
+{
+ Elf_Shdr *pcpusec = >sechdrs[info->index.pcpu];
+ if (!pcpusec->sh_size)
+ return 0;
+
+ /* We have a special allocation for this section. */
+ return percpu_modalloc(mod, pcpusec->sh_size, pcpusec->sh_addralign);
}
/* mod is no longer valid after this! */
@@ -3237,6 +3234,11 @@ static int load_module(struct load_info *info, const
char __user *uargs,
}
#endif
+ /* To avoid stressing percpu allocator, do this once we're unique. */
+ err = alloc_module_percpu(mod, info);
+ if (err)
+ goto unlink_mod;
+
/* Now module is in final location, initialize linked lists, etc. */
err = module_unload_init(mod);
if (err)
.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the powerpc tree
Hi all,
After merging the powerpc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/pstore/ftrace.c: In function 'pstore_ftrace_call':
fs/pstore/ftrace.c:47:6: warning: passing argument 7 of 'psinfo->write_buf'
makes integer from pointer without a cast [enabled by default]
sizeof(rec), psinfo);
^
fs/pstore/ftrace.c:47:6: note: expected 'size_t' but argument is of type
'struct pstore_info *'
fs/pstore/ftrace.c:47:6: error: too few arguments to function
'psinfo->write_buf'
Caused by commit 6bbbca735936 ("pstore: Pass header size in the pstore
write callback").
I have used the version from next-20130701 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpNiotIEG7Qf.pgp
Description: PGP signature
[GIT PULL] f2fs updates for v3.11
Hi Linus,
Here is the pull request on f2fs updates for v3.11.
Most of patches in this patch-set have been proposed to fix the
roll-forward mechanism significantly.
One of major fixes is related to little and big endian conversion, and
its errorneous symptom on powerpc was initially reported by Oded Gabbay.
Another one is that it has been revealed the pgbench regression reported
by phoronix was caused by one of fsync bug fixes in 3.10-rc1. In order
to restore the performance, one enhancement patch was introduced in this
patch-set, which is f2fs: recover wrong pino after checkpoint during
fsync.
One of new features is *xattr security labels* which is essential to the
SEandroid system.
Please consider pulling the following tag.
Thank you,
The following changes since commit
e4aa937ec75df0eea0bee03bffa3303ad36c986b:
Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
tags/for-f2fs-3.11
for you to fetch changes up to a1dd3c13ce65b726fddfe72b9d2f1009db983ce6:
f2fs: fix to recover i_size from roll-forward (2013-07-02 08:48:16
+0900)
This patch-set includes the following major enhancement patches.
o remount_fs callback function
o restore parent inode number to enhance the fsync performance
o xattr security labels
o reduce the number of redundant lock/unlock data pages
o avoid frequent write_inode calls
The other minor bug fixes are as follows.
o endian conversion bugs
o various bugs in the roll-forward recovery routine
Dan Carpenter (1):
f2fs: dereferencing an ERR_PTR
Gu Zheng (3):
f2fs: set sb->s_fs_info before calling parse_options()
f2fs: code cleanup and simplify in func {find/add}_gc_inode
f2fs: remove the unused argument "sbi" of func
destroy_fsync_dnodes()
Haicheng Li (4):
f2fs: remove unecessary variable and code
f2fs: remove unnecessary parameter "offset" from __add_sum_entry()
f2fs: make locate_dirty_segment() as static
f2fs: optimize do_write_data_page()
Jaegeuk Kim (35):
f2fs: fix inconsistency of block count during recovery
f2fs: fix the inconsistent state of data pages
f2fs: remove redundant assignment
f2fs: fix por_doing variable coverage
f2fs: fix BUG_ON during f2fs_evict_inode(dir)
f2fs: remove unnecessary por_doing check
f2fs: skip get_node_page if locked node page is passed
f2fs: change get_new_data_page to pass a locked node page
f2fs: update inode page after creation
f2fs: add debug msgs in the recovery routine
f2fs: remove unnecessary kmap/kunmap operations
f2fs: fix to unlock page before exit
f2fs: don't do checkpoint if error is occurred
f2fs: avoid RECLAIM_FS-ON-W: deadlock
f2fs: add f2fs_readonly()
f2fs: fix wrong condition check
f2fs: reuse the locked dnode page and its inode
f2fs: fix to handle do_recover_data errors
f2fs: should not make_bad_inode on f2fs_link failure
f2fs: use ihold
f2fs: align data types between on-disk and in-memory block
addresses
f2fs: iput only if whole data blocks are flushed
f2fs: fix dentry recovery routine
f2fs: fix incorrect iputs during the dentry recovery
f2fs: cover cp_file information with ilock
f2fs: fix iget/iput of dir during recovery
f2fs: support xattr security labels
f2fs: fix i_blocks translation on various types of files
f2fs: sync dir->i_size with its block allocation
f2fs: avoid freqeunt write_inode calls
f2fs: recover wrong pino after checkpoint during fsync
f2fs: fix crc endian conversion
f2fs: fix an endian conversion bug detected by sparse
f2fs: remove reusing any prefree segments
f2fs: fix to recover i_size from roll-forward
Jason Hrycay (1):
f2fs: handle errors from get_node_page calls
Namjae Jeon (10):
f2fs: reorganize f2fs_vm_page_mkwrite
f2fs: push some variables to debug part
f2fs: remove unneeded initializations in f2fs_parent_dir
f2fs: optimize several routines in node.h
f2fs: return proper error from start_gc_thread
f2fs: reorganise the function get_victim_by_default
f2fs: use the F2FS specific flags in f2fs_ioctl()
f2fs: optimise the truncate_data_blocks_range() range
f2fs: add remount_fs callback support
f2fs: optimize the init_dirty_segmap function
Peter Zijlstra (1):
f2fs, lockdep: annotate mutex_lock_all()
majianpeng (1):
f2fs: use list_for_each_entry rather than list_for_each_entry_safe
Documentation/filesystems/f2fs.txt | 9 +-
fs/f2fs/Kconfig| 12 ++
fs/f2fs/acl.c | 2 +-
fs/f2fs/checkpoint.c | 99 +++
fs/f2fs/data.c | 68 +++---
[GIT PULL] f2fs updates for v3.11
Hi Linus,
Here is the pull request on f2fs updates for v3.11.
Most of patches in this patch-set have been proposed to fix the
roll-forward mechanism significantly.
One of major fixes is related to little and big endian conversion, and
its errorneous symptom on powerpc was initially reported by Oded Gabbay.
Another one is that it has been revealed the pgbench regression reported
by phoronix was caused by one of fsync bug fixes in 3.10-rc1. In order
to restore the performance, one enhancement patch was introduced in this
patch-set, which is f2fs: recover wrong pino after checkpoint during
fsync.
One of new features is *xattr security labels* which is essential to the
SEandroid system.
Please consider pulling the following tag.
Thank you,
The following changes since commit
e4aa937ec75df0eea0bee03bffa3303ad36c986b:
Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
tags/for-f2fs-3.11
for you to fetch changes up to a1dd3c13ce65b726fddfe72b9d2f1009db983ce6:
f2fs: fix to recover i_size from roll-forward (2013-07-02 08:48:16
+0900)
This patch-set includes the following major enhancement patches.
o remount_fs callback function
o restore parent inode number to enhance the fsync performance
o xattr security labels
o reduce the number of redundant lock/unlock data pages
o avoid frequent write_inode calls
The other minor bug fixes are as follows.
o endian conversion bugs
o various bugs in the roll-forward recovery routine
Dan Carpenter (1):
f2fs: dereferencing an ERR_PTR
Gu Zheng (3):
f2fs: set sb->s_fs_info before calling parse_options()
f2fs: code cleanup and simplify in func {find/add}_gc_inode
f2fs: remove the unused argument "sbi" of func
destroy_fsync_dnodes()
Haicheng Li (4):
f2fs: remove unecessary variable and code
f2fs: remove unnecessary parameter "offset" from __add_sum_entry()
f2fs: make locate_dirty_segment() as static
f2fs: optimize do_write_data_page()
Jaegeuk Kim (35):
f2fs: fix inconsistency of block count during recovery
f2fs: fix the inconsistent state of data pages
f2fs: remove redundant assignment
f2fs: fix por_doing variable coverage
f2fs: fix BUG_ON during f2fs_evict_inode(dir)
f2fs: remove unnecessary por_doing check
f2fs: skip get_node_page if locked node page is passed
f2fs: change get_new_data_page to pass a locked node page
f2fs: update inode page after creation
f2fs: add debug msgs in the recovery routine
f2fs: remove unnecessary kmap/kunmap operations
f2fs: fix to unlock page before exit
f2fs: don't do checkpoint if error is occurred
f2fs: avoid RECLAIM_FS-ON-W: deadlock
f2fs: add f2fs_readonly()
f2fs: fix wrong condition check
f2fs: reuse the locked dnode page and its inode
f2fs: fix to handle do_recover_data errors
f2fs: should not make_bad_inode on f2fs_link failure
f2fs: use ihold
f2fs: align data types between on-disk and in-memory block
addresses
f2fs: iput only if whole data blocks are flushed
f2fs: fix dentry recovery routine
f2fs: fix incorrect iputs during the dentry recovery
f2fs: cover cp_file information with ilock
f2fs: fix iget/iput of dir during recovery
f2fs: support xattr security labels
f2fs: fix i_blocks translation on various types of files
f2fs: sync dir->i_size with its block allocation
f2fs: avoid freqeunt write_inode calls
f2fs: recover wrong pino after checkpoint during fsync
f2fs: fix crc endian conversion
f2fs: fix an endian conversion bug detected by sparse
f2fs: remove reusing any prefree segments
f2fs: fix to recover i_size from roll-forward
Jason Hrycay (1):
f2fs: handle errors from get_node_page calls
Namjae Jeon (10):
f2fs: reorganize f2fs_vm_page_mkwrite
f2fs: push some variables to debug part
f2fs: remove unneeded initializations in f2fs_parent_dir
f2fs: optimize several routines in node.h
f2fs: return proper error from start_gc_thread
f2fs: reorganise the function get_victim_by_default
f2fs: use the F2FS specific flags in f2fs_ioctl()
f2fs: optimise the truncate_data_blocks_range() range
f2fs: add remount_fs callback support
f2fs: optimize the init_dirty_segmap function
Peter Zijlstra (1):
f2fs, lockdep: annotate mutex_lock_all()
majianpeng (1):
f2fs: use list_for_each_entry rather than list_for_each_entry_safe
Documentation/filesystems/f2fs.txt | 9 +-
fs/f2fs/Kconfig| 12 ++
fs/f2fs/acl.c | 2 +-
fs/f2fs/checkpoint.c | 99 +++
fs/f2fs/data.c | 68 +++---
Re: [PATCH] seq_file:update file->f_pos when lseek() to m->read_pos
On 07/01/2013 08:41 PM, fangdong wrote:
> On 06/29/2013 05:11 AM, Jiaxing Wang wrote:
>> After pread(), file->f_pos and m->read_pos get different,
>> and lseek() to m->read_pos did not update file->f_pos, then
>> a subsequent read may read from a wrong position, the following
>> program shows the problem:
>>
>> char str1[32] = { 0 };
>> char str2[32] = { 0 };
>> int poffset = 10;
>> int count = 20;
>>
>> /*open any seq file*/
>> int fd = open("/proc/modules", O_RDONLY);
>>
>> pread(fd, str1, count, poffset);
>> printf("pread:%s\n", str1);
>>
>> /*seek to where m->read_pos is*/
>> lseek(fd, poffset+count, SEEK_SET);
>>
>> /*supposed to read from poffset+count, but this read from position 0*/
>> read(fd, str2, count);
>> printf("read:%s\n", str2);
>>
>> Signed-off-by: Jiaxing Wang
>> ---
>> fs/seq_file.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/seq_file.c b/fs/seq_file.c
>> index 774c1eb..4b22b26 100644
>> --- a/fs/seq_file.c
>> +++ b/fs/seq_file.c
>> @@ -328,7 +328,8 @@ loff_t seq_lseek(struct file *file, loff_t offset, int
>> whence)
>> m->read_pos = offset;
>> retval = file->f_pos = offset;
>> }
>> -}
>> +} else
>> +file->f_pos = offset;
>> }
>> file->f_version = m->version;
>> mutex_unlock(>lock);
>>
> This does not appear to be a problem, in linux man page, the behaver seems
> clearly defined:
>
> DESCRIPTION
>pread() reads up to count bytes from file descriptor fd at offset
> off-set (from the start of the file) into the buffer starting at buf. The
> file offset is not changed.
>
>pwrite() writes up to count bytes from the buffer starting at buf to
> the file descriptor fd at offset offset. The file offset is not
> changed.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
There's no problem that pread() don't change file->f_pos, but I think lseek()
should have changed it.
Any comments from other people, and Alexander?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT] Security subsystem updates for 3.11
In this update, Smack learns to love IPv6 and to mount a filesystem with a transmutable hierarchy (i.e. security labels are inherited from parent directory upon creation rather than creating process). The rest of the changes are maintenance. Please pull. The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376: Linux 3.10 (2013-06-30 15:13:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus Al Viro (1): apparmor: no need to delay vfree() Casey Schaufler (3): Smack: Local IPv6 port based controls Smack: Improve access check performance Smack: Add smkfstransmute mount option J. Bruce Fields (1): security: clarify cap_inode_getsecctx description James Morris (2): Merge tag 'aa-3.10' of git://git.kernel.org/.../jj/linux-apparmor into ra-next Merge branch 'smack-for-3.11' of git://git.gitorious.org/smack-next/kernel into ra-next John Johansen (20): apparmor: fix auditing of domain transition failures due to incomplete policy apparmor: Remove -W1 warnings apparmor: refactor profile mode macros apparmor: fix error code to failure message mapping for name lookup apparmor: add utility function to get an arbitrary tasks profile. apparmor: add kvzalloc to handle zeroing for kvmalloc apparmor: use common fn to clear task_context for domain transitions apparmor: remove "permipc" command apparmor: relax the restrictions on setting rlimits apparmor: misc cleanup of match apparmor: move perm defines into policy_unpack apparmor: remove sid from profiles apparmor: move the free_profile fn ahead of aa_alloc_profile apparmor: reserve and mask off the top 8 bits of the base field apparmor: fix the audit type table apparmor: Fix smatch warning in aa_remove_profiles apparmor: fix sparse warnings apparmor: localize getting the security context to a few macros apparmor: fix setprocattr arg processing for onexec apparmor: fix fully qualified name parsing Kent Yoder (1): maintainers: Remove Kent from maintainers Lars-Peter Clausen (1): tpm: tpm_i2c_infinion: Don't modify i2c_client->driver Mimi Zohar (5): tpm: move TPM_DIGEST_SIZE defintion maintainers: add Dmitry Kasatkin evm: calculate HMAC after initializing posix acl on tmpfs integrity: move integrity_audit_msg() evm: audit integrity metadata failures Passion,Zhao (1): Smack: Fix the bug smackcipso can't set CIPSO correctly Peter Huewe (2): tpm: fix regression caused by section type conflict of tpm_dev_release() in ppc builds tpm/tpm_i2c_infineon: Remove unused header file Tetsuo Handa (1): Smack: Fix possible NULL pointer dereference at smk_netlbl_mls() Wei Yongjun (1): tpm_tis: missing platform_driver_unregister() on error in init_tis() Documentation/kernel-parameters.txt| 10 +- MAINTAINERS|7 +- drivers/char/tpm/tpm.c |2 +- drivers/char/tpm/tpm.h |2 +- drivers/char/tpm/tpm_i2c_infineon.c|4 - drivers/char/tpm/tpm_tis.c | 17 +- include/linux/security.h |3 +- include/linux/tpm.h|2 + mm/shmem.c | 16 +- security/apparmor/audit.c |2 +- security/apparmor/context.c| 44 +- security/apparmor/domain.c | 26 +- security/apparmor/include/apparmor.h | 12 +- security/apparmor/include/context.h| 61 ++- security/apparmor/include/file.h | 14 +- security/apparmor/include/match.h | 21 +- security/apparmor/include/policy.h | 16 +- security/apparmor/include/procattr.h |1 - security/apparmor/include/sid.h|4 +- security/apparmor/ipc.c| 13 +- security/apparmor/lib.c| 44 +- security/apparmor/lsm.c| 69 +- security/apparmor/match.c | 23 +- security/apparmor/path.c |2 +- security/apparmor/policy.c | 181 +++--- security/apparmor/policy_unpack.c |4 +- security/apparmor/procattr.c |6 - security/apparmor/resource.c | 15 +- security/integrity/Kconfig | 15 + security/integrity/Makefile|1 + security/integrity/evm/evm_main.c | 15 +- security/integrity/ima/Kconfig | 12 - security/integrity/ima/Makefile
Re: [PATCH 3/3] tracing: Protect ftrace_trace_arrays list in trace_events.c
On Mon, 2013-07-01 at 15:31 -0700, Alexander Z Lam wrote:
> There are multiple places where the ftrace_trace_arrays list is accessed in
> trace_events.c without the trace_types_lock held.
Thanks, this I'll also pull into 3.11 and mark stable.
-- Steve
>
> Cc: David Sharp
> Cc: Alexander Z Lam
> Signed-off-by: Alexander Z Lam
> ---
> kernel/trace/trace_events.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 6db3290..26351cc 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -1586,6 +1586,7 @@ static void __add_event_to_tracers(struct
> ftrace_event_call *call,
> int trace_add_event_call(struct ftrace_event_call *call)
> {
> int ret;
> + mutex_lock(_types_lock);
> mutex_lock(_mutex);
>
> ret = __register_event(call, NULL);
> @@ -1593,11 +1594,13 @@ int trace_add_event_call(struct ftrace_event_call
> *call)
> __add_event_to_tracers(call, NULL);
>
> mutex_unlock(_mutex);
> + mutex_unlock(_types_lock);
> return ret;
> }
>
> /*
> - * Must be called under locking both of event_mutex and trace_event_sem.
> + * Must be called under locking of trace_types_lock, event_mutex and
> + * trace_event_sem.
> */
> static void __trace_remove_event_call(struct ftrace_event_call *call)
> {
> @@ -1609,11 +1612,13 @@ static void __trace_remove_event_call(struct
> ftrace_event_call *call)
> /* Remove an event_call */
> void trace_remove_event_call(struct ftrace_event_call *call)
> {
> + mutex_lock(_types_lock);
> mutex_lock(_mutex);
> down_write(_event_sem);
> __trace_remove_event_call(call);
> up_write(_event_sem);
> mutex_unlock(_mutex);
> + mutex_unlock(_types_lock);
> }
>
> #define for_each_event(event, start, end)\
> @@ -1757,6 +1762,7 @@ static int trace_module_notify(struct notifier_block
> *self,
> {
> struct module *mod = data;
>
> + mutex_lock(_types_lock);
> mutex_lock(_mutex);
> switch (val) {
> case MODULE_STATE_COMING:
> @@ -1767,6 +1773,7 @@ static int trace_module_notify(struct notifier_block
> *self,
> break;
> }
> mutex_unlock(_mutex);
> + mutex_unlock(_types_lock);
>
> return 0;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] tracing: Make trace_marker use the correct per-instance buffer
On Mon, 2013-07-01 at 15:31 -0700, Alexander Z Lam wrote:
> The trace_marker file was present for each new instance created, but it
> added the trace mark to the global trace buffer instead of to
> the instance's buffer.
Thanks, I'll get this into this merge window. And maybe even mark it for
stable.
-- Steve
>
> Cc: David Sharp
> Cc: Vaibhav Nagarnaik
> Cc: Alexander Z Lam
> Signed-off-by: Alexander Z Lam
> ---
> kernel/trace/trace.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index e0b0d2a..2f7307e 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -4351,6 +4351,7 @@ tracing_mark_write(struct file *filp, const char __user
> *ubuf,
> size_t cnt, loff_t *fpos)
> {
> unsigned long addr = (unsigned long)ubuf;
> + struct trace_array *tr = filp->private_data;
> struct ring_buffer_event *event;
> struct ring_buffer *buffer;
> struct print_entry *entry;
> @@ -4410,7 +4411,7 @@ tracing_mark_write(struct file *filp, const char __user
> *ubuf,
>
> local_save_flags(irq_flags);
> size = sizeof(*entry) + cnt + 2; /* possible \n added */
> - buffer = global_trace.trace_buffer.buffer;
> + buffer = tr->trace_buffer.buffer;
> event = trace_buffer_lock_reserve(buffer, TRACE_PRINT, size,
> irq_flags, preempt_count());
> if (!event) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] rtc: omap: handle rtc wakeup support in driver
Hi Hebbar, Hebbar Gururaja writes: > rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms. > > However, rtc wake support on OMAP1 is broken. Hence the > device_init_wakeup() was removed from rtc-omap driver and moved to > platform board files that supported it (DA850/OMAP-L138). [1] > > However, recently [2] it was suggested that driver should always do a > device_init_wakeup(dev, true). Platforms that don't want/need > wakeup support can disable it from userspace via: > > echo disabled > /sys/devices/.../power/wakeup > > Also, with the new DT boot-up, board file doesn't exist and hence there > is no way to have device wakeup support rtc. > > The fix for above issues, is to hard code device_init_wakeup() inside > driver and let platforms that don't need this, handle it through the > sysfs power entry. This series looks good now, thanks for your persistence. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
is it desirable to improve the build system?
Dear Linux-Kernel Community, I am a consultant specializing in builds, and I recently worked for a large client company, a world-wide leader in its field, where I overhauled their build system: sped it up by more of an order of magnitude, and improved maintainability, for example making comment-to-code ratio approach 1:1. A part of their build is a modified Linux kernel. I rebuilt it countless times in various configurations, but made only a few further changes, because those improvements would have a small effect on the whole system, and because they want to stay close to your current release for ease of porting. >From that limited experience, it nevertheless seemed to me, that the Linux >kernel build, while correct, is somewhat slow, and the sources could be more >readable. Does the Linux-Kernel Community perceive that is the case? If so, do you think it is possible to improve? If so, would such an attempt be welcome, including and especially by, the current maintainer(s) of the build? Of course it would have to be completely backwards-compatible, including to the text output interface and requirements for modules makefiles. I do apologize if my impressions are simply the result of unfamilliarity and naivete, and that I don't understand the deep reasons why "it has to be this way", and that I am unaware that such attempts were already made by some very skilled people. Thank you, Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] pin control bulk changes for v3.11
Hi Linus, here is the big pin control pull request for the v3.11 cycle. A lot is going on as this is now getting ever more accepter with embedded system on chips. We have new archs using pin control and a batch of beautification. I've boiled this in -next, the 0day build system and manual test compilations. Patches touching other subsystems are ACKed. There may be other trees dependent on this baseline so I better get it out the door early in the merge window. Please pull it in! Yours, Linus Walleij The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10: Linux 3.10-rc5 (2013-06-08 17:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git tags/pinctrl-for-v3.11-1 for you to fetch changes up to 2207a4e1ca6a1bb126360b6d0c236af6664532f2: pinctrl: vt8500: wmt: remove redundant dev_err call in wmt_pinctrl_probe() (2013-06-27 11:51:51 +0200) Pin control changes for the v3.11 kernel cycle: - A large slew of improvements of the Genric pin configuration support, and deployment in four different platforms: Rockchip, Super-H PFC, ABx500 and TZ1090. Support BIAS_BUS_HOLD, get device tree parsing and debugfs support into shape. - We also have device tree support with generic naming conventions for the generic pin configuration. - Delete the unused and confusing direct pinconf API. Now state transitions is *the* way to control pins and multiplexing. - New drivers for Rockchip, TZ1090, and TZ1090 PDC. - Two pin control states related to power management are now handled in the device core: "sleep" and "idle", removing a lot of boilerplate code in drivers. We do not yet know if this is the final word for pin PM, but it already make things a lot easier to handle. - Handle sparse GPIO ranges passing a list of disparate pins, and utilize these in the new BayTrail (x86 Atom SoC) driver. - Make the sunxi (AllWinner) driver handle external interrupts. - Make it possible for pinctrl-single to handle the case where several pins are managed by a single register, and augment it to handle sleep modes. - Cleanups and improvements for the abx500 drivers. - Move Sirf pin control drivers to their own directory, support save/restore of context and add support for the SiRFatlas6 SoC. - PMU muxing for the Dove pinctrl driver. - Finalization and support for VF610 in the i.MX6 pinctrl driver. - Smoothen out various Exynos rough edges. - Generic cleanups of various kinds. Arnd Bergmann (1): pinctrl: export pinctrl_pm_select_*_state Axel Lin (1): pinctrl: rockchip: Add missing irq_gc_unlock() call before return error Barry Song (2): pinctrl:sirf:re-arch and add support for new SiRFatlas6 SoC pinctrl: sirf: save the status in suspend and restore after resuming Christian Ruppert (2): pinctrl: add pin list based GPIO ranges Fix comment on pinctrl_gpio_range.pin_base Doug Anderson (4): pinctrl: exynos: Add spinlocks to irq_mask and irq_unmask pinctrl: exynos: reorder xyz_irq_unmask() so future patch can ack MAINTAINERS: Add Samsung pinctrl entries pinctrl: exynos: ack level-triggered interrupts before unmasking Fabio Baltieri (1): spi: pl022: remove unused ret and pins_state variables Hebbar Gururaja (1): pinctrl: single: adopt pinctrl sleep mode management Heiko Stübner (11): pinctrl: add pinconf-generic define for a pin-default pull pinctrl: add function to parse generic pinconfig properties from a dt node pinctrl: add pinctrl driver for Rockchip SoCs pinctrl: clarify some dt pinconfig options pinctrl: handle zero found dt pinconfig properties better pinctrl: dynamically alloc temp array when parsing dt pinconf options pinctrl: rockchip: correctly handle arguments of pinconf options pinctrl: more clarifications for generic pull configs pinctrl: set unit for debounce time pinconfig to usec pinctrl: remove slew-rate parameter from tz1090 pinctrl: remove bindings for pinconf options needing more thought James Hogan (6): pinconf-generic: add drive strength to debugfs output pinconf-generic: add BIAS_BUS_HOLD pinconf Documentation/pinctrl.txt: fix typo "with with" pinctrl: fix pinconf_ops::pin_config_dbg_parse_modify kerneldoc pinctrl-tz1090: add TZ1090 pinctrl driver pinctrl-tz1090-pdc: add TZ1090 PDC pinctrl driver Jingchang Lu (2): pinctrl: imx: add VF610 support to imx pinctrl framework pinctrl: add VF610 pinctrl driver Jingoo Han (4): pinctrl: coh901: remove unnecessary platform_set_drvdata() pinctrl: mxs: remove unnecessary platform_set_drvdata() pinctrl: sirf: remove unnecessary platform_set_drvdata() pinctrl: u300: remove unnecessary
Re: [PATCH 1/3] tracing: Use a ring buffer size of 1 when creating a new trace buffer
On Mon, 2013-07-01 at 15:31 -0700, Alexander Z Lam wrote: > Use deferred ring buffer allocation in new trace buffer instances by > copying the behavior of the deferred allocation of global_trace's buffer. > Without this, each new trace buffer instance will attempt to allocate > num_cpus * TRACE_BUF_SIZE_DEFAULT bytes for the ring buffer, which might > fail on a system with many cores. If this fails, the new instance is not > created, precluding the user from setting a smaller buffer for which > allocation might succeed. > Actually no, I don't like this approach. The reason for the expanded buffer for ftrace is because we wanted distros to configure it enabled, thus we needed a way not to waste memory in the buffers for tracing which is used by 1% of distro uses, and the 99% of distro uses just have wasted memory. The reason I don't like this, is because it can fail to allocate when the user starts the trace, which may cause strange results. For the main buffer, we need to deal with this because of the distro issue. There's plenty of ways to allocate the buffer on boot up in case you don't want to worry about the buffer later. But for instances, I think the creation of the instance should be dependent on whether or not you have the space for the buffer, and not to find this out at time of starting the trace. Now, the solution you do want is a new file called, "instance_default_buffer_size_kb", that is used when creating a new buffer. That is, let users change what a new instance buffer size will be. By default, this should be what the buffer_size is. Perhaps have it change with the buffer_size as long as the instance_default_buffer_size_kb hasn't changed manually yet. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scripts/package/builddeb: build perftools package
This will build a linux-tools-$version package for each build that includes
perf.
Signed-off-by: Gary Lowell
---
scripts/package/builddeb | 95 +-
1 file changed, 94 insertions(+), 1 deletion(-)
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index acb8650..f57d33c 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -78,17 +78,20 @@ tmpdir="$objtree/debian/tmp"
fwdir="$objtree/debian/fwtmp"
kernel_headers_dir="$objtree/debian/hdrtmp"
libc_headers_dir="$objtree/debian/headertmp"
+tools_dir="$objtree/debian/toolstmp"
+tmp_build_dir="$objtree/debian/toolsbuild"
packagename=linux-image-$version
fwpackagename=linux-firmware-image
kernel_headers_packagename=linux-headers-$version
libc_headers_packagename=linux-libc-dev
+tools_packagename=linux-tools-$version
if [ "$ARCH" = "um" ] ; then
packagename=user-mode-linux-$version
fi
# Setup the directory structure
-rm -rf "$tmpdir" "$fwdir" "$kernel_headers_dir" "$libc_headers_dir"
+rm -rf "$tmpdir" "$fwdir" "$kernel_headers_dir" "$libc_headers_dir"
"$tools_dir" "$tmp_build_dir"
mkdir -m 755 -p "$tmpdir/DEBIAN"
mkdir -p "$tmpdir/lib" "$tmpdir/boot" "$tmpdir/usr/share/doc/$packagename"
mkdir -m 755 -p "$fwdir/DEBIAN"
@@ -98,6 +101,10 @@ mkdir -p
"$libc_headers_dir/usr/share/doc/$libc_headers_packagename"
mkdir -m 755 -p "$kernel_headers_dir/DEBIAN"
mkdir -p "$kernel_headers_dir/usr/share/doc/$kernel_headers_packagename"
mkdir -p "$kernel_headers_dir/lib/modules/$version/"
+mkdir -m 755 -p "$tools_dir/DEBIAN"
+mkdir -p "$tools_dir/usr/share/doc/$tools_packagename"
+mkdir -p "$tools_dir/usr/bin/"
+mkdir -p "$tmp_build_dir"
if [ "$ARCH" = "um" ] ; then
mkdir -p "$tmpdir/usr/lib/uml/modules/$version" "$tmpdir/usr/bin"
fi
@@ -120,6 +127,77 @@ else
fi
fi
+# Build the tools
+num_tools="0"
+tools_flavour_abi=${version#*-}
+tools_flavour=${tools_flavour_abi#*-}
+tools_version=${version%-$tools_flavour}
+debian_tools_version="${version%%-*}"
+debian_tools_version="${version%.*}"
+if grep -q '^CONFIG_PERF_EVENTS=y' .config ; then
+ # Build and install perf
+ (
+unset MAKEFLAGS
+unset MFLAGS
+unset MAKEOVERRIDES
+
+mkdir -p $objtree/tools/perf
+cd "$srctree/tools/perf"
+$MAKE DESTDIR="$tools_dir/usr/" LDFLAGS= O=$objtree/tools/perf/ install
+mv "$tools_dir/usr/bin/perf"
"$tools_dir/usr/bin/perf_$debian_tools_version"
+ln -s "/usr/bin/perf_$debian_tools_version"
"$tools_dir/usr/bin/perf_$tools_version"
+mv "$tools_dir/usr/libexec/perf-core"
"$tools_dir/usr/share/perf_$debian_tools_version-core"
+rmdir "$tools_dir/usr/libexec"
+
+# Documentation can't be built out-of-tree so copy source
+# over to objtree and build man pages there
+mkdir -p $tmp_build_dir/perf
+cp -a "$srctree/tools/perf/Documentation" "$tmp_build_dir/perf/"
+cp -a "$srctree/tools/perf/config" "$tmp_build_dir/perf/"
+cd "$tmp_build_dir/perf/Documentation"
+$MAKE man
+$MAKE DESTDIR="$tools_dir/usr/" install
+for manpage in `find $tools_dir/usr/share/man/ -type f`; do
+ mv $manpage ${manpage/perf/perf_$debian_tools_version}
+ gzip -9 ${manpage/perf/perf_$debian_tools_version}
+done
+ )
+ num_tools=$(($num_tools+1))
+fi
+
+if [[ "$ARCH" = "i386" || "$ARCH" = "x86_64" ]]; then
+ # Build turbostat
+ (
+cp -a $srctree/tools/power/x86/turbostat "$tmp_build_dir"
+ln -s $srctree/arch "$tmp_build_dir/../../../arch"
+cd "$tmp_build_dir/turbostat/"
+unset MAKEFLAGS
+unset MFLAGS
+unset MAKEOVERRIDES
+$MAKE LDFLAGS=
+cp turbostat "$tools_dir/usr/bin/turbostat_$debian_tools_version"
+ln -s "/usr/bin/turbostat_$debian_tools_version"
"$tools_dir/usr/bin/turbostat_$tools_version"
+mkdir -p "$tools_dir/usr/share/man/man8"
+cp turbostat.8
"$tools_dir/usr/share/man/man8/turbotstat_${debian_tools_version}.8"
+gzip -9
"$tools_dir/usr/share/man/man8/turbotstat_${debian_tools_version}.8"
+ )
+
+ # Build x86_energy_perf_policy
+ (
+cp -a $srctree/tools/power/x86/x86_energy_perf_policy "$tmp_build_dir"
+cd "$tmp_build_dir/x86_energy_perf_policy"
+unset MAKEFLAGS
+unset MFLAGS
+unset MAKEOVERRIDES
+$MAKE LDFLAGS=
+cp x86_energy_perf_policy
"$tools_dir/usr/bin/x86_energy_perf_policy_$debian_tools_version"
+ln -s "/usr/bin/x86_energy_perf_policy_$debian_tools_version"
"$tools_dir/usr/bin/x86_energy_perf_policy_$tools_version"
+cp x86_energy_perf_policy.8
"$tools_dir/usr/share/man/man8/x86_energy_perf_policy_${debian_tools_version}.8"
+gzip -9
"$tools_dir/usr/share/man/man8/x86_energy_perf_policy_${debian_tools_version}.8"
+ )
+ num_tools=$(($num_tools+2))
+fi
+
if grep -q
Re: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
Hebbar Gururaja writes: > On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN) > is available to enable Alarm Wakeup feature. This register needs to be > properly handled for the rtcwake to work properly. > > Platforms using such IP should set "ti,am3352-rtc" in rtc device dt > compatibility node. > > Signed-off-by: Hebbar Gururaja > Cc: Grant Likely > Cc: Rob Herring > Cc: Rob Landley > Cc: Sekhar Nori > Cc: Kevin Hilman > Cc: Alessandro Zummo > Cc: rtc-li...@googlegroups.com > Cc: devicetree-disc...@lists.ozlabs.org > Cc: linux-...@vger.kernel.org Acked-by: Kevin Hilman ...with a minor nit below... > --- > :100644 100644 b47aa41... 5a0f02d... M > Documentation/devicetree/bindings/rtc/rtc-omap.txt > :100644 100644 761919d... 666b0c2... Mdrivers/rtc/rtc-omap.c > Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 ++- > drivers/rtc/rtc-omap.c | 56 > +--- > 2 files changed, 54 insertions(+), 8 deletions(-) > > diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt > b/Documentation/devicetree/bindings/rtc/rtc-omap.txt > index b47aa41..5a0f02d 100644 > --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt > +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt > @@ -1,7 +1,11 @@ > TI Real Time Clock > > Required properties: > -- compatible: "ti,da830-rtc" > +- compatible: > + - "ti,da830-rtc" - for RTC IP used similar to that on DA8xx SoC family. > + - "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC > family. > + This RTC IP has special WAKE-EN Register to enable > + Wakeup generation for event Alarm. > - reg: Address range of rtc register set > - interrupts: rtc timer, alarm interrupts in order > - interrupt-parent: phandle for the interrupt controller > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c > index 761919d..666b0c2 100644 > --- a/drivers/rtc/rtc-omap.c > +++ b/drivers/rtc/rtc-omap.c > @@ -72,6 +72,8 @@ > #define OMAP_RTC_KICK0_REG 0x6c > #define OMAP_RTC_KICK1_REG 0x70 > > +#define OMAP_RTC_IRQWAKEEN 0x7C > + nit: letters in hex numbers are usually lower-case. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
Hebbar Gururaja writes:
> Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
> duplicate call from the rtc device registration can be removed.
>
> This is basically a partial revert of the prev commit
>
> commit 75c99bb0006ee065b4e2995078d779418b0fab54
> Author: Sekhar Nori
>
> davinci: da8xx/omap-l1: mark RTC as a wakeup source
>
> Signed-off-by: Hebbar Gururaja
> Cc: Sekhar Nori
> Cc: Kevin Hilman
> Cc: Russell King
>
> ---
> :100644 100644 bf57252... 85a900c... M
> arch/arm/mach-davinci/devices-da8xx.c
> arch/arm/mach-davinci/devices-da8xx.c |9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/devices-da8xx.c
> b/arch/arm/mach-davinci/devices-da8xx.c
> index bf57252..85a900c 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -827,14 +827,7 @@ static struct platform_device da8xx_rtc_device = {
>
> int da8xx_register_rtc(void)
> {
> - int ret;
> -
> - ret = platform_device_register(_rtc_device);
> - if (!ret)
> - /* Atleast on DA850, RTC is a wakeup source */
> - device_init_wakeup(_rtc_device.dev, true);
> -
> - return ret;
> + return platform_device_register(_rtc_device);
nit: extra space between 'return' and 'platform_'
> }
>
> static void __iomem *da8xx_ddr2_ctlr_base;
Otherwise,
Acked-by: Kevin Hilman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] rtc: omap: restore back (hard-code) wakeup support
Hebbar Gururaja writes:
> rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms.
>
> However, rtc wake support on OMAP1 is broken. Hence the
> device_init_wakeup() was removed from rtc-omap driver and moved to
> platform board files that supported it (DA850/OMAP-L138). [1]
>
> However, recently [2] it was suggested that driver should always do a
> device_init_wakeup(dev, true). Platforms that don't want/need
> wakeup support can disable it from userspace via:
>
> echo disabled > /sys/devices/.../power/wakeup
>
> Also, with the new DT boot-up, board file doesn't exist and hence there
> is no way to have device wakeup support rtc.
>
> The fix for above issues, is to hard code device_init_wakeup() inside
> driver and let platforms that don't need this, handle it through the
> sysfs power entry.
>
> [1]
> https://patchwork.kernel.org/patch/136731/
>
> [2]
> http://www.mail-archive.com/davinci-linux-open-source@linux.
> davincidsp.com/msg26077.html
>
> Signed-off-by: Hebbar Gururaja
> Cc: Alessandro Zummo
> Cc: rtc-li...@googlegroups.com
Acked-by: Kevin Hilman
> ---
> :100644 100644 b0ba3fc... 761919d... Mdrivers/rtc/rtc-omap.c
> drivers/rtc/rtc-omap.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index b0ba3fc..761919d 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -423,6 +423,8 @@ static int __init omap_rtc_probe(struct platform_device
> *pdev)
>*is write-only, and always reads as zero...)
>*/
>
> + device_init_wakeup(>dev, true);
> +
> if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
> pr_info("%s: split power mode\n", pdev->name);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] metag: kick: prevent nested kick handlers
Thomas Gleixner wrote: >On Mon, 1 Jul 2013, James Hogan wrote: >> On 1 July 2013 22:51, Thomas Gleixner wrote: >> > On Mon, 1 Jul 2013, James Hogan wrote: >> > >> >> The main kick trigger handler iterates a list of kick handlers and >calls >> >> each one. This is done with the kick_handlers_lock spin lock held, >but >> >> this causes a problem on SMP where IPIs are implemented with >kicks. A >> >> reschedule IPI calls scheduler_ipi() which uses irq_enter() and >> >> irq_exit(). This results in the scheduler being invoked with >> >> kick_handlers_lock held which can result in a nested kick trigger >> >> attempting to acquire the lock, resulting in deadlock. >> >> >> >> irq_enter() and irq_exit() can nest, so call them from the main >kick >> >> interrupt handler so that softirqs are only handled after >> >> kick_handlers_lock is released. >> > >> > This changelog is confusing. What I decode from the patch is, that >you >> > are adding a missing irq_enter/exit pair to the kick_handler, right >? >> >> Yes. Previously the outermost pair of irq_enter/exit was inside the >> spin lock critical section (inside scheduler_ipi). so soft-irqs >> (apparently including the scheduler) would run from irq_exit with the >> spinlock still held. Now it waits until the new outermost irq_exit(), >> after the spin lock is released. >> >> I should probably have increased the number of lines of diff context. >> http://lxr.linux.no/#linux+v3.10/arch/metag/kernel/kick.c#L66 > >No, you should have written the changelog less confusing. I can see >the context by just looking at the current and the patched code. Yes, i agree, sorry it wasn't clear. >The explanation you provided right now that the outermost pair of >irq_enter/exit was inside the spin locked section matches the patch >and makes sense. > >So the real issue is, that all of your various interrupts come from Only kicks, which are the hardware IPI mechanism (in practice only used for SMP IPIs and for communication with non-linux hw threads). Timer/peripheral interrupts come via different handlers. >the same place, i.e. kick_handler. The kick_handler locks a global >lock and calls the handlers which have registered. These handlers >(partially calling generic code) might invoke irq_enter/exit pairs, >which leads to the underlying problem. > >If irq_exit() results in a nest count of hard interrupts = 0, then it >invokes eventually pending soft interrupts. The softirq callbacks can >issue an IPI of some sorts and because this IPI will end up in the >kick handler, the systems livelocks on the already held global lock >which protects the kick_handler list. This can happen from any invoked >handler, because the kick_handler is missing an irq_enter/pair >preventing a kick_handler invocation recursion. Yes, that's my understanding of the problem. > >The obvious fix for now is to add an irq_enter/exit() pair around the >spin locked section in the kick handler, so irq_exit() invocations of >subhandlers wont lead to softirq execution. > >The more elegant fix would be to replace that global lock which is not >really scalable with an RCU protected list of subscribed handlers. Yes, I considered switching it to an RCU list (thanks for confirming that), but this patch looks sensible to me even with rcu, so I figured that can be a separate patch. >The most elegant fix would be to have separate entry points for >various exceptions, but that seems to be an architectural issue. thanks for taking the time to review and for the other acks. i'll rewrite the commit message of this patch and resend. cheers James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] clk: changes for 3.11
The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:
Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)
are available in the git repository at:
git://git.linaro.org/people/mturquette/linux.git tags/clk-for-linus-3.11
for you to fetch changes up to 45e3ec3784aec0d194740b75b547bfabca448ff3:
clk: tegra: fix ifdef for tegra_periph_reset_assert inline (2013-06-24
14:17:59 -0700)
The common clock framework changes for 3.11 include new clock drivers
across several different platforms and architectures, fixes to existing
drivers, a MAINTAINERS file fix and improvements to the basic clock
types that allow them to be of use to more platforms than before. Only a
few fixes to the core framework are included with most all of the
changes landing in the various clock drivers themselves.
Alexandre Courbot (1):
clk: tegra114: correctly output clk_32k
Arnd Bergmann (1):
clk: tegra: provide tegra_periph_reset_assert alternative
Axel Lin (2):
clk: wm831x: Fix update wrong register for enable/disable FLL
clk: wm831x: Fix wm831x_clkout_get_parent
Daniel Tang (1):
clk: Add TI-Nspire clock drivers
Fabio Baltieri (1):
clk: ux500: abx500-clk: rename ux500 audio codec aliases
Giacomo A. Catenazzi (1):
clk: sunxi: "cpu_data" is defined in header files of some architectures
Haojian Zhuang (3):
clk: mux: add CLK_MUX_HIWORD_MASK
clk: divider: add CLK_DIVIDER_HIWORD_MASK flag
clk: gate: add CLK_GATE_HIWORD_MASK
Heiko Stübner (1):
clk: add support for Rockchip gate clocks
Jean-Francois Moine (1):
clk: si5351: declare all device IDs for module loading
Jingoo Han (1):
clk: use platform_{get,set}_drvdata()
Maxime Ripard (1):
clk: sun5i: Add compatibles for Allwinner A13
Mikko Perttunen (1):
clk: tegra114: Fix msenc clock register
Paul Walmsley (3):
clk: tegra: T114: add FCPU clock shaper programming, needed by the DFLL
clk: tegra: T114: add DFLL source clocks
clk: tegra: T114: add DFLL DVCO reset control
Pawel Moll (2):
clk: vexpress: Use full node name to identify individual clocks
clk: vexpress: Make the clock drivers directly available for arm64
Peter De Schrijver (12):
clk: tegra: pllc and pllxc should use pdiv_map
clk: tegra: pllp_out2 divider is int only
clk: tegra: allow PLL m,n,p init from SoC files
clk: tegra: PLL m,n,p init for Tegra114
clk: tegra: fix pllre initilization
clk: tegra: fix sclk_parents
clk: tegra: Add fields for override bits
clk: tegra: override bits for Tegra114 PLLM
clk: tegra: override bits for Tegra30 PLLM
clk: tegra: Use override bits when needed
clk: use clk_get_rate() for debugfs
clk: honor CLK_GET_RATE_NOCACHE in clk_set_rate
Philippe Begnic (4):
clk: ux500: Pass clock base adresses in initcall for u8540 and u9540
mfd: db8500: Update register definition for u8540 clock
mfd: db8500: Update BML clock register for db8580
clk: ux500: Clocks definition for u8540
Prashant Gaikwad (2):
clk: tegra: fix clk_out parents list
clk: tegra: Use common of_clk_init function
Saravana Kannan (2):
clk: Fix race condition between clk_set_parent and clk_enable()
clk: Disable unused clocks after deferred probing is done
Sebastian Hesselbarth (3):
clk: si5351: Allow user to define disabled state for every clock output
clk: add non CONFIG_OF routines for clk-provider
clk: si5351: Allow to build without CONFIG_OF
Shawn Guo (1):
clk: divider: do not propagate rate change request when unnecessary
Soren Brinkmann (1):
clk: Always notify whole subtree when reparenting
Stephen Warren (2):
MAINTAINERS: make drivers/clk entry match subdirs
clk: tegra: fix ifdef for tegra_periph_reset_assert inline
Tang Yuantian (2):
clk: add PowerPC corenet clock driver support
clk: mpc85xx: Update the compatible string
Tony Prisk (2):
clk: vt8500: Add support for clocks on the WM8850 SoCs
clk: vt8500: Remove unnecessary divisor adjustment in vtwm_dclk_set_rate()
Tushar Behera (4):
clk: exynos5250: Update cpufreq related clocks for EXYNOS5250
clk: exynos5250: Add sclk_mpll to the parent list of mout_cpu clock
clk: samsung: Add MUX_FA macro to pass flag and alias
clk: exynos4: Fix clock aliases for cpufreq related clocks
.../devicetree/bindings/clock/nspire-clock.txt | 24 +
.../devicetree/bindings/clock/rockchip.txt | 74 +++
.../devicetree/bindings/clock/silabs,si5351.txt| 5 +
Documentation/devicetree/bindings/clock/sunxi.txt | 117 +
.../bindings/clock/sunxi/sun4i-a10-gates.txt | 93
.../bindings/clock/sunxi/sun5i-a13-gates.txt | 58 +++
Documentation/devicetree/bindings/clock/vt8500.txt | 2 +
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Fri, 28 Jun 2013 12:23:33 +0200, Johan Hovold writes: >> I did a quick check of adding the device id though sysfs, and although >> it partly works, it doesn't find the correct firmware (it ends up trying >> to load 5052 firmware for a 3410 device. Looking at the code it seems >> (struct ti_device) td_is_3410 isn't set properly.) > >Turns out that the drivers device-type detection has never worked with >the dynamic id interface (all devices were detected as 2-port devices). > >I'm responding to this mail with a fix. Care to give it a try? Yes, this works fine. /Anders -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] mce, acpi/apei: Soft-offline a page on firmware GHES notification
On Mon, Jul 01, 2013 at 09:08:59PM +0530, Naveen N. Rao wrote:
> If the firmware indicates in GHES error data entry that the error threshold
> has exceeded for a corrected error event, then we try to soft-offline the
> page. This could be called in interrupt context, so we queue this up similar
> to how we handle memory failure scenarios.
>
>
> Signed-off-by: Naveen N. Rao
> ---
> drivers/acpi/apei/ghes.c | 12 ++
> include/linux/mm.h |1 +
> mm/memory-failure.c | 53
> ++
> 3 files changed, 48 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index fcd7d91..5a630ed 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -429,6 +429,18 @@ static void ghes_do_proc(struct ghes *ghes,
> mem_err);
> #endif
> #ifdef CONFIG_ACPI_APEI_MEMORY_FAILURE
> + if (sec_sev == GHES_SEV_CORRECTED &&
> + (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED)
> &&
> + (mem_err->validation_bits &
> CPER_MEM_VALID_PHYSICAL_ADDRESS)) {
> + unsigned long pfn;
> + pfn = mem_err->physical_addr >> PAGE_SHIFT;
> + if (pfn_valid(pfn))
> + soft_memory_failure_queue(pfn, 0, 0);
> + else
> + pr_warning(FW_WARN GHES_PFX
> + "Invalid address in generic error data:
> %#lx\n",
> + mem_err->physical_addr);
> + }
Yuck, this looks like BIOS code.
Can we carve out this into a function and do
void function(.. )
{
#ifdef CONFIG_ACPI_APEI_MEMORY_FAILURE
#endif
}
so that we can nicely call it from ghes_do_proc()?
> if (sev == GHES_SEV_RECOVERABLE &&
> sec_sev == GHES_SEV_RECOVERABLE &&
> mem_err->validation_bits &
> CPER_MEM_VALID_PHYSICAL_ADDRESS) {
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index e0c8528..f9907d2 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1787,6 +1787,7 @@ enum mf_flags {
> };
> extern int memory_failure(unsigned long pfn, int trapno, int flags);
> extern void memory_failure_queue(unsigned long pfn, int trapno, int flags);
> +extern void soft_memory_failure_queue(unsigned long pfn, int trapno, int
> flags);
> extern int unpoison_memory(unsigned long pfn);
> extern int sysctl_memory_failure_early_kill;
> extern int sysctl_memory_failure_recovery;
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index ceb0c7f..50caefd 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1222,6 +1222,7 @@ struct memory_failure_entry {
> unsigned long pfn;
> int trapno;
> int flags;
> + bool soft_offline;
Why a new bool? This flags int looks nice above. :)
> };
>
> struct memory_failure_cpu {
> @@ -1233,6 +1234,28 @@ struct memory_failure_cpu {
>
> static DEFINE_PER_CPU(struct memory_failure_cpu, memory_failure_cpu);
>
> +void __memory_failure_queue(unsigned long pfn, int trapno, int flags, int
> soft_offline)
> +{
> + struct memory_failure_cpu *mf_cpu;
> + unsigned long proc_flags;
> + struct memory_failure_entry entry = {
> + .pfn = pfn,
> + .trapno = trapno,
> + .flags =flags,
> + .soft_offline = soft_offline
> + };
> +
> + mf_cpu = _cpu_var(memory_failure_cpu);
> + spin_lock_irqsave(_cpu->lock, proc_flags);
> + if (kfifo_put(_cpu->fifo, ))
> + schedule_work_on(smp_processor_id(), _cpu->work);
> + else
> + pr_err("Memory failure: buffer overflow when queuing memory
> failure at 0x%#lx\n",
> +pfn);
> + spin_unlock_irqrestore(_cpu->lock, proc_flags);
> + put_cpu_var(memory_failure_cpu);
> +}
> +
> /**
> * memory_failure_queue - Schedule handling memory failure of a page.
> * @pfn: Page Number of the corrupted page
> @@ -1250,28 +1273,19 @@ static DEFINE_PER_CPU(struct memory_failure_cpu,
> memory_failure_cpu);
> *
> * Can run in IRQ context.
> */
> +
> void memory_failure_queue(unsigned long pfn, int trapno, int flags)
> {
> - struct memory_failure_cpu *mf_cpu;
> - unsigned long proc_flags;
> - struct memory_failure_entry entry = {
> - .pfn = pfn,
> - .trapno = trapno,
> - .flags =flags,
> - };
> -
> - mf_cpu = _cpu_var(memory_failure_cpu);
> - spin_lock_irqsave(_cpu->lock, proc_flags);
> - if (kfifo_put(_cpu->fifo, ))
> - schedule_work_on(smp_processor_id(), _cpu->work);
> - else
> - pr_err("Memory failure: buffer overflow when queuing memory
Re: [PATCH] mfd: sec: Provide max_register to regmap
Hi Mark, On Mon, Jul 01, 2013 at 11:02:19PM +0100, Mark Brown wrote: > From: Mark Brown > > Enable debugfs register dumps and greater error checking within the > regmap API providing the maximum register to the regmap API. > > Signed-off-by: Mark Brown > --- > drivers/mfd/sec-core.c | 41 - > 1 file changed, 40 insertions(+), 1 deletion(-) Applied as well, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: wm8994: Remove duplicate check for active JACKDET
Hi Mark, On Mon, Jul 01, 2013 at 08:56:18PM +0100, Mark Brown wrote: > From: Mark Brown > > Probably the result of a mismerge or rebase failing to notice that the > hunk had already been applied. > > Signed-off-by: Mark Brown > --- > drivers/mfd/wm8994-core.c | 14 -- > 1 file changed, 14 deletions(-) Applied to mfd-next, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH v4] drivers/tpm: add xen tpmfront interface
"Peter Hüwe" wrote: >Am Montag, 1. Juli 2013, 23:34:28 schrieb Daniel De Graaf: >> This is a complete rewrite of the Xen TPM frontend driver, taking >> advantage of a simplified frontend/backend interface and adding >support >> for cancellation and timeouts. The backend for this driver is >provided >> by a vTPM stub domain using the interface in Xen 4.3. >> >> Signed-off-by: Daniel De Graaf >> Acked-by: Matthew Fioravante >> Reviewed-by: Konrad Rzeszutek Wilk >> Acked-by: Peter Huewe >> Reviewed-by: Peter Huewe >> --- > >Reviewed, the remaining topics were addressed in this v4. >Reviewed-by: Peter Huewe > > >From the TPM point of view I'd say it is fine. >Acked-by: Peter Huewe > >Thanks! > >@Konrad: Can you take it through your tree? > > >Thanks, >Peter Of course I will queue it up. I am not sure if it will be able to make it in 3.11 (merge window opened just now). -- Sent from my Android phone. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
