* [PATCH 1/2 v1] davinci: support disabling modem status interrupts on SOC UARTS
From: Kevin Hilman @ 2011-02-01 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D44803E.8000703@criticallink.com>
Michael Williamson <michael.williamson@criticallink.com> writes:
> Hi Kevin...
>
> On 01/05/2011 07:26 AM, Michael Williamson wrote:
>> On the da850/omap-l138/am18x family of SoCs, up to three on chip UARTS may be
>> configured. These peripherals support the standard Tx/Rx signals as well as
>> CTS/RTS hardware flow control signals. The pins on these SOC's associated with
>> these signals are multiplexed; e.g., the pin providing UART0_TXD capability
>> also provides SPI0 chip select line 5 output capability. The configuration of
>> the pin multiplexing occurs during platform initialization (or by earlier
>> bootloader operations).
>>
>> There is a problem with the multiplexing implementation on these SOCs. Only
>> the output and output enable portions of the I/O section of the pin are
>> multiplexed. All peripheral input functions remain connected to a given pin
>> regardless of configuration.
>>
>> In many configurations of these parts, providing a UART with Tx/Rx capability
>> is needed, but the HW flow control capability is not. Furthermore, the pins
>> associated with the CTS inputs on these UARTS are often configured to support
>> a different peripheral, and they may be active/toggling during runtime. This
>> can result in false modem status (CTS) interrupts being asserted to the 8250
>> driver controlling the associated Tx/Rx pins, and will impact system
>> performance.
>>
>> The 8250 serial driver platform data does not provide a direct mechanism to
>> tell the driver to disable modem status (i.e., CTS) interrupts for a given
>> port. As a work-around, intercept register writes to the IER and disable
>> modem status interrupts.
>>
>> This patch was tested using a MityDSP-L138 SOM having UART1 enabled with the
>> associated CTS pin connected to a clock (configured for the AHCLKX function).
>>
>> Background / problem reports related to this issue are captured in the links
>> below:
>> http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/36701.aspx
>> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg19524.html
>>
>> Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
>> Tested-by: Michael Williamson <michael.williamson@criticallink.com>
>> ---
>> This is against the linux-davinci tree.
>>
>> Changes from original proposed patch:
>> - instead of overriding set_termios, now override serial_out driver hook
>> and intercept writes to the MSR.
>>
>> An alternate patch was proposed that modified the serial core driver and added a UPF_NO_MSR
>> flag. There was resistance to this patch. The reasoning is that the core 8250 driver code
>> should not continue to get muddied by platform hacks.
>>
>
> I'd like to withdraw this patch. It works, but it's inefficient and ugly, and
> I also get the feeling it isn't going to make it in it's current form anyway.
>
> I have another patch that is limited to just the mityomapl138 platform that
> I would like to submit in place of this. No other board appears to have this
> problem, so it makes sense to constrain the fix to platform file that does.
>
OK
Kevin
^ permalink raw reply
* Re: [PATCH 1/2 v1] davinci: support disabling modem status interrupts on SOC UARTS
From: Kevin Hilman @ 2011-02-01 20:53 UTC (permalink / raw)
To: Michael Williamson
Cc: davinci-linux-open-source, gregkh, linux-serial, linux-arm-kernel
In-Reply-To: <4D44803E.8000703@criticallink.com>
Michael Williamson <michael.williamson@criticallink.com> writes:
> Hi Kevin...
>
> On 01/05/2011 07:26 AM, Michael Williamson wrote:
>> On the da850/omap-l138/am18x family of SoCs, up to three on chip UARTS may be
>> configured. These peripherals support the standard Tx/Rx signals as well as
>> CTS/RTS hardware flow control signals. The pins on these SOC's associated with
>> these signals are multiplexed; e.g., the pin providing UART0_TXD capability
>> also provides SPI0 chip select line 5 output capability. The configuration of
>> the pin multiplexing occurs during platform initialization (or by earlier
>> bootloader operations).
>>
>> There is a problem with the multiplexing implementation on these SOCs. Only
>> the output and output enable portions of the I/O section of the pin are
>> multiplexed. All peripheral input functions remain connected to a given pin
>> regardless of configuration.
>>
>> In many configurations of these parts, providing a UART with Tx/Rx capability
>> is needed, but the HW flow control capability is not. Furthermore, the pins
>> associated with the CTS inputs on these UARTS are often configured to support
>> a different peripheral, and they may be active/toggling during runtime. This
>> can result in false modem status (CTS) interrupts being asserted to the 8250
>> driver controlling the associated Tx/Rx pins, and will impact system
>> performance.
>>
>> The 8250 serial driver platform data does not provide a direct mechanism to
>> tell the driver to disable modem status (i.e., CTS) interrupts for a given
>> port. As a work-around, intercept register writes to the IER and disable
>> modem status interrupts.
>>
>> This patch was tested using a MityDSP-L138 SOM having UART1 enabled with the
>> associated CTS pin connected to a clock (configured for the AHCLKX function).
>>
>> Background / problem reports related to this issue are captured in the links
>> below:
>> http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/36701.aspx
>> http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg19524.html
>>
>> Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
>> Tested-by: Michael Williamson <michael.williamson@criticallink.com>
>> ---
>> This is against the linux-davinci tree.
>>
>> Changes from original proposed patch:
>> - instead of overriding set_termios, now override serial_out driver hook
>> and intercept writes to the MSR.
>>
>> An alternate patch was proposed that modified the serial core driver and added a UPF_NO_MSR
>> flag. There was resistance to this patch. The reasoning is that the core 8250 driver code
>> should not continue to get muddied by platform hacks.
>>
>
> I'd like to withdraw this patch. It works, but it's inefficient and ugly, and
> I also get the feeling it isn't going to make it in it's current form anyway.
>
> I have another patch that is limited to just the mityomapl138 platform that
> I would like to submit in place of this. No other board appears to have this
> problem, so it makes sense to constrain the fix to platform file that does.
>
OK
Kevin
^ permalink raw reply
* Re: [RFC][PATCH 0/6] more detailed per-process transparent hugepage statistics
From: Dave Hansen @ 2011-02-01 20:56 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: linux-kernel, linux-mm, Michael J Wolf, Andrew Morton
In-Reply-To: <20110201203936.GB16981@random.random>
On Tue, 2011-02-01 at 21:39 +0100, Andrea Arcangeli wrote:
> So now the speedup
> from hugepages needs to also offset the cost of the more frequent
> split/collapse events that didn't happen before.
My concern here is the downward slope. I interpret that as saying that
we'll eventually have _zero_ THPs. Plus, the benefits are decreasing
constantly, even though the scanning overhead is fixed (or increasing
even).
> So I guess considering the time is of the order of 2/3 hours and there
> are "only" 88G of memory, speeding up khugepaged is going to be
> beneficial considering how big boost hugepages gives to the guest with
> NPT/EPT and even bigger boost for regular shadow paging, but it also
> depends on guest. In short khugepaged by default is tuned in a way
> that can't run in the way of the CPU.
I guess we could also try and figure out whether the khugepaged CPU
overhead really comes from the scanning or the collapsing operations
themselves. Should be as easy as some oprofiling.
If it really is the scanning, I bet we could be a lot more efficient
with khugepaged as well. In the case of KVM guests, we're going to have
awfully fixed virtual addresses and processes where collapsing can take
place.
It might make sense to just have split_huge_page() stick the vaddr and
the mm in a queue. khugepaged could scan those addresses first instead
of just going after the system as a whole.
For cases where the page got split, but wasn't modified, should we have
a non-copying, non-allocating fastpath to re-merge it?
-- Dave
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC][PATCH 0/6] more detailed per-process transparent hugepage statistics
From: Dave Hansen @ 2011-02-01 20:56 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: linux-kernel, linux-mm, Michael J Wolf, Andrew Morton
In-Reply-To: <20110201203936.GB16981@random.random>
On Tue, 2011-02-01 at 21:39 +0100, Andrea Arcangeli wrote:
> So now the speedup
> from hugepages needs to also offset the cost of the more frequent
> split/collapse events that didn't happen before.
My concern here is the downward slope. I interpret that as saying that
we'll eventually have _zero_ THPs. Plus, the benefits are decreasing
constantly, even though the scanning overhead is fixed (or increasing
even).
> So I guess considering the time is of the order of 2/3 hours and there
> are "only" 88G of memory, speeding up khugepaged is going to be
> beneficial considering how big boost hugepages gives to the guest with
> NPT/EPT and even bigger boost for regular shadow paging, but it also
> depends on guest. In short khugepaged by default is tuned in a way
> that can't run in the way of the CPU.
I guess we could also try and figure out whether the khugepaged CPU
overhead really comes from the scanning or the collapsing operations
themselves. Should be as easy as some oprofiling.
If it really is the scanning, I bet we could be a lot more efficient
with khugepaged as well. In the case of KVM guests, we're going to have
awfully fixed virtual addresses and processes where collapsing can take
place.
It might make sense to just have split_huge_page() stick the vaddr and
the mm in a queue. khugepaged could scan those addresses first instead
of just going after the system as a whole.
For cases where the page got split, but wasn't modified, should we have
a non-copying, non-allocating fastpath to re-merge it?
-- Dave
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Saravana Kannan @ 2011-02-01 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201152820.GQ31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:28 AM, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 04:22:03PM +0100, Uwe Kleine-König wrote:
>> Full ack. (I wonder if you misunderstood me or wanted to put my
>> statement into more words. Jassi didn't like that a clk_enable without
>> a previous clk_prepare worked on some platforms and on others it
>> doesn't. With BUG_ON(clk->ops->prepare&& !clk->prepare_count) in
>> clk_enable we have exactly this situation.)
>
> Even with a NULL clk->ops->prepare function, we still want drivers to
> have called clk_prepare(). So we can do something like:
>
> if (WARN_ON(clk->prepare_count = 0))
> return -EINVAL;
>
> in clk_enable() should be sufficient and noisy enough not to be missed.
This code will only catch the error when it actually happens and will
even miss catching some of them (if timed right -- unprepare happens in
the other core after this check is executed).
I really wish there was something better we could do to help driver devs
catch errors of calling enable without calling prepare(). Some thing
like spin lock debug, or the might_sleeps() inside mutexes, etc.
Hmm... Jeremy, how about doing a similar check in the unprepare code?
You could WARN/BUG ON the prepare count going to zero when the enable
count is still non-zero?
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Saravana Kannan @ 2011-02-01 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201152820.GQ31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:28 AM, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 04:22:03PM +0100, Uwe Kleine-K?nig wrote:
>> Full ack. (I wonder if you misunderstood me or wanted to put my
>> statement into more words. Jassi didn't like that a clk_enable without
>> a previous clk_prepare worked on some platforms and on others it
>> doesn't. With BUG_ON(clk->ops->prepare&& !clk->prepare_count) in
>> clk_enable we have exactly this situation.)
>
> Even with a NULL clk->ops->prepare function, we still want drivers to
> have called clk_prepare(). So we can do something like:
>
> if (WARN_ON(clk->prepare_count == 0))
> return -EINVAL;
>
> in clk_enable() should be sufficient and noisy enough not to be missed.
This code will only catch the error when it actually happens and will
even miss catching some of them (if timed right -- unprepare happens in
the other core after this check is executed).
I really wish there was something better we could do to help driver devs
catch errors of calling enable without calling prepare(). Some thing
like spin lock debug, or the might_sleeps() inside mutexes, etc.
Hmm... Jeremy, how about doing a similar check in the unprepare code?
You could WARN/BUG ON the prepare count going to zero when the enable
count is still non-zero?
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Saravana Kannan @ 2011-02-01 20:57 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Uwe Kleine-König, Nicolas Pitre, Dima Zavin,
Lorenzo Pieralisi, linux-sh, Ben Herrenschmidt, Sascha Hauer,
Jassi Brar, linux-kernel, Paul Mundt, Ben Dooks, Vincent Guittot,
Jeremy Kerr, linux-arm-kernel
In-Reply-To: <20110201152820.GQ31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:28 AM, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 04:22:03PM +0100, Uwe Kleine-König wrote:
>> Full ack. (I wonder if you misunderstood me or wanted to put my
>> statement into more words. Jassi didn't like that a clk_enable without
>> a previous clk_prepare worked on some platforms and on others it
>> doesn't. With BUG_ON(clk->ops->prepare&& !clk->prepare_count) in
>> clk_enable we have exactly this situation.)
>
> Even with a NULL clk->ops->prepare function, we still want drivers to
> have called clk_prepare(). So we can do something like:
>
> if (WARN_ON(clk->prepare_count == 0))
> return -EINVAL;
>
> in clk_enable() should be sufficient and noisy enough not to be missed.
This code will only catch the error when it actually happens and will
even miss catching some of them (if timed right -- unprepare happens in
the other core after this check is executed).
I really wish there was something better we could do to help driver devs
catch errors of calling enable without calling prepare(). Some thing
like spin lock debug, or the might_sleeps() inside mutexes, etc.
Hmm... Jeremy, how about doing a similar check in the unprepare code?
You could WARN/BUG ON the prepare count going to zero when the enable
count is still non-zero?
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PULL] vhost-net: 2.6.38 - warning fix
From: David Miller @ 2011-02-01 20:58 UTC (permalink / raw)
To: mst; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20110201154440.GA22819@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 1 Feb 2011 17:44:40 +0200
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net
Pulled, thanks Michael.
^ permalink raw reply
* Re: [PATCH 01/18] wl1251: fix queue stopping/waking for TX path
From: Kalle Valo @ 2011-02-01 20:58 UTC (permalink / raw)
To: David Gnedt
Cc: John W. Linville, linux-wireless, Grazvydas Ignotas,
Denis 'GNUtoo' Carikli
In-Reply-To: <4D45B7B6.4090102@davizone.at>
David Gnedt <david.gnedt@davizone.at> writes:
> The queue stopping/waking functionality was broken in a way that could
> cause the TX to stall if the right circumstances are met.
>
> The problem was caused by tx_work, which is scheduled on each TX operation.
> If the firmware buffer is full, tx_work does nothing. In combinition with
> stopped queues or non-continues transfers, tx_work is never scheduled again.
> Moreover the low watermark introduced by
> 9df86e2e702c6d5547aced7f241addd2d698bb11 never takes effect because of some
> old code.
>
> Solve this by scheduling tx_work every time tx_queue is non-empty and
> firmware buffer is freed on tx_complete.
>
> This also solves a possible but unlikely case: If less frames than the high
> watermark are queued, but more than firmware buffer can hold. This results
> in queues staying awake but the only scheduled tx_work doesn't transfer all
> frames, so the remaining frames are stuck in the queue until more frames
> get queued and tx_work is scheduled again.
This looks good. Unfortunately I wasn't able to test it yet, but if it
solves your issue I think it's best to get it in now.
Thanks for fixing this.
> Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Acked-by: Kalle Valo <kvalo@adurom.com>
--
Kalle Valo
^ permalink raw reply
* Re: What's the typical RAID10 setup?
From: Roberto Spadim @ 2011-02-01 20:58 UTC (permalink / raw)
To: Keld Jørn Simonsen; +Cc: David Brown, linux-raid
In-Reply-To: <20110201203210.GB26468@www2.open-std.org>
> For sequential reading, this is not true. For random reading and
> writing I agree with you in theory, but benchmarks show that it is not
> so, at least for Linux RAID, viz the above URL.
i agree with you, since linux algorith for raid1 is closest head, not
round robin or time based
there´s some patch on internet (google it: round robin raid1 linux)
for roundrobin, but none for time based =(
it´s a point of optimization of today raid1 algorithm
round robin (may be at this mail list)
http://www.spinics.net/lists/raid/msg30003.html
2011/2/1 Keld Jørn Simonsen <keld@keldix.com>:
> On Tue, Feb 01, 2011 at 05:02:46PM +0100, Keld Jørn Simonsen wrote:
>> On Tue, Feb 01, 2011 at 11:01:33AM +0100, David Brown wrote:
>> > On 31/01/2011 23:52, Keld Jørn Simonsen wrote:
>> > >raid1+0 and Linux MD raid10 are similar, but significantly different
>> > >in a number of ways. Linux MD raid10 can run on only 2 drives.
>> > >Linux raid10,f2 has almost RAID0 striping performance in sequential read.
>> > >You can have an odd number of drives in raid10.
>> > >And you can have as many copies as you like in raid10,
>> > >
>> >
>> > You can make raid10,f2 functionality from raid1+0 by using partitions.
>> > For example, to get a raid10,f2 equivalent on two drives, partition them
>> > into equal halves. Then make md0 a raid1 mirror of sda1 and sdb2, and
>> > md1 a raid1 mirror of sdb1 and sda2. Finally, make md2 a raid0 stripe
>> > set of md0 and md1.
>>
>> I don't think you get the striping performance of raid10,f2 with this
>> layout. And that is one of the main advantages of raid10,f2 layout.
>> Have you tried it out?
>>
>> As far as I can see the layout of blocks are not alternating between the
>> disks. You have one raid1 of sda1 and sdb2, there a file is allocated on
>> blocks sequentially on sda1 and then mirrored on sdb2, where it is also
>> sequentially allocated. That gives no striping.
>
> Well, maybe the RAID0 layer provides the adequate striping.
> I am noy sure, but it looks like it could hold in theory.
> One could try it out.
>
> One advantage of this scheme could be improved probability
> When 2 drives fail, eg. in the case of a 4 drive array.
> The probability of survival of a running system could then
> be enhaced form 33 % to 66 %.
>
> One problem could be the choice of always the lowest block number, which
> is secured in raid10,f2, but not in a raid0 over raid1 (or raid10,n2) scenario.
>
> best regards
> keld
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] usb:smsc: preserve MAC address when resetting device
From: Sergiy Kibrik @ 2011-02-01 20:58 UTC (permalink / raw)
To: David Lamparter; +Cc: Steve Glendinning, netdev, linux-usb
In-Reply-To: <20110201112425.GA3407894@jupiter.n2.diac24.net>
[-- Attachment #1: Type: Text/Plain, Size: 448 bytes --]
On Tuesday 01 February 2011 13:24:25 David Lamparter wrote:
> You cannot do that. Imagine if I plug in two devices. Only the first one
> will get a MAC properly. Or imagine if i plug a device, unplug it and
> plug it back. It will have an uninitialized mac address.
>
> You need to move the init_mac_address call to happen on device plug-in.
>
>
> -David
Sorry, didn't take into account such case. Will resubmit
-regards,
Sergey
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Stephen Boyd @ 2011-02-01 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:24 AM, Russell King - ARM Linux wrote:
>
> I'd also be tempted at this stage to build-in a no-op dummy clock,
> that being the NULL clk:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> if (clk) {
> mutex_lock(&clk->mutex);
> if (clk->prepared = 0)
> ret = clk->ops->prepare(clk);
> if (ret = 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
> }
>
> return ret;
> }
I'm afraid this will hide enable/disable imbalances on some targets and
then expose them on others. Maybe its not a big problem though since
this also elegantly handles the root(s) of the tree.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Stephen Boyd @ 2011-02-01 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:24 AM, Russell King - ARM Linux wrote:
>
> I'd also be tempted at this stage to build-in a no-op dummy clock,
> that being the NULL clk:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> if (clk) {
> mutex_lock(&clk->mutex);
> if (clk->prepared == 0)
> ret = clk->ops->prepare(clk);
> if (ret == 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
> }
>
> return ret;
> }
I'm afraid this will hide enable/disable imbalances on some targets and
then expose them on others. Maybe its not a big problem though since
this also elegantly handles the root(s) of the tree.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Stephen Boyd @ 2011-02-01 20:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Uwe Kleine-König, Nicolas Pitre, Lorenzo Pieralisi,
Saravana Kannan, linux-sh, Ben Herrenschmidt, Sascha Hauer,
Paul Mundt, linux-kernel, Dima Zavin, Ben Dooks, Vincent Guittot,
Jeremy Kerr, linux-arm-kernel
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:24 AM, Russell King - ARM Linux wrote:
>
> I'd also be tempted at this stage to build-in a no-op dummy clock,
> that being the NULL clk:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> if (clk) {
> mutex_lock(&clk->mutex);
> if (clk->prepared == 0)
> ret = clk->ops->prepare(clk);
> if (ret == 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
> }
>
> return ret;
> }
I'm afraid this will hide enable/disable imbalances on some targets and
then expose them on others. Maybe its not a big problem though since
this also elegantly handles the root(s) of the tree.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH] perf: Cure task_oncpu_function_call() races
From: Peter Zijlstra @ 2011-02-01 21:00 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Frederic Weisbecker, Ingo Molnar, Alan Stern,
Arnaldo Carvalho de Melo, Paul Mackerras, Prasad, Roland McGrath,
linux-kernel
In-Reply-To: <1296583698.26581.279.camel@laptop>
On Tue, 2011-02-01 at 19:08 +0100, Peter Zijlstra wrote:
> perf_install_in_context() works on a ctx obtained by find_get_context(),
> that context is either new (uncloned) or existing in which case it
> called unclone_ctx(). So I was thinking there was no race with the ctx
> flipping in perf_event_context_sched_out(), _however_ since it only
> acquires ctx->mutex after calling unclone_ctx() there is a race window
> with perf_event_init_task().
>
> This race we should fix with perf_pin_task_context()
I came up with the below.. I'll give it some runtime tomorrow, my brain
just gave up for today..
---
Index: linux-2.6/kernel/perf_event.c
===================================================================
--- linux-2.6.orig/kernel/perf_event.c
+++ linux-2.6/kernel/perf_event.c
@@ -327,7 +327,6 @@ static void perf_unpin_context(struct pe
raw_spin_lock_irqsave(&ctx->lock, flags);
--ctx->pin_count;
raw_spin_unlock_irqrestore(&ctx->lock, flags);
- put_ctx(ctx);
}
/*
@@ -741,10 +740,10 @@ static void perf_remove_from_context(str
raw_spin_lock_irq(&ctx->lock);
/*
- * If we failed to find a running task, but find it running now that
- * we've acquired the ctx->lock, retry.
+ * If we failed to find a running task, but find the context active now
+ * that we've acquired the ctx->lock, retry.
*/
- if (task_curr(task)) {
+ if (ctx->is_active) {
raw_spin_unlock_irq(&ctx->lock);
goto retry;
}
@@ -1104,10 +1103,10 @@ perf_install_in_context(struct perf_even
raw_spin_lock_irq(&ctx->lock);
/*
- * If we failed to find a running task, but find it running now that
- * we've acquired the ctx->lock, retry.
+ * If we failed to find a running task, but find the context active now
+ * that we've acquired the ctx->lock, retry.
*/
- if (task_curr(task)) {
+ if (ctx->is_active) {
raw_spin_unlock_irq(&ctx->lock);
goto retry;
}
@@ -2278,6 +2277,9 @@ find_lively_task_by_vpid(pid_t vpid)
}
+/*
+ * Returns a matching context with refcount and pincount.
+ */
static struct perf_event_context *
find_get_context(struct pmu *pmu, struct task_struct *task, int cpu)
{
@@ -2302,6 +2304,7 @@ find_get_context(struct pmu *pmu, struct
cpuctx = per_cpu_ptr(pmu->pmu_cpu_context, cpu);
ctx = &cpuctx->ctx;
get_ctx(ctx);
+ ++ctx->pin_count;
return ctx;
}
@@ -2315,6 +2318,7 @@ find_get_context(struct pmu *pmu, struct
ctx = perf_lock_task_context(task, ctxn, &flags);
if (ctx) {
unclone_ctx(ctx);
+ ++ctx->pin_count;
raw_spin_unlock_irqrestore(&ctx->lock, flags);
}
@@ -6041,6 +6045,7 @@ SYSCALL_DEFINE5(perf_event_open,
perf_install_in_context(ctx, event, cpu);
++ctx->generation;
+ perf_unpin_context(ctx);
mutex_unlock(&ctx->mutex);
event->owner = current;
@@ -6066,6 +6071,7 @@ SYSCALL_DEFINE5(perf_event_open,
return event_fd;
err_context:
+ perf_unpin_context(ctx);
put_ctx(ctx);
err_alloc:
free_event(event);
@@ -6116,6 +6122,7 @@ perf_event_create_kernel_counter(struct
mutex_lock(&ctx->mutex);
perf_install_in_context(ctx, event, cpu);
++ctx->generation;
+ perf_unpin_context(ctx);
mutex_unlock(&ctx->mutex);
return event;
@@ -6591,6 +6598,7 @@ int perf_event_init_context(struct task_
mutex_unlock(&parent_ctx->mutex);
perf_unpin_context(parent_ctx);
+ put_ctx(parent_ctx);
return ret;
}
^ permalink raw reply
* [refpolicy] [PATCH/RFC 2/19]: patch set to update the git reference policy
From: Guido Trentalancia @ 2011-02-01 20:59 UTC (permalink / raw)
To: refpolicy
In-Reply-To: <4D48649C.70000@tresys.com>
Hello Christopher !
On Tue, 01/02/2011 at 14.53 -0500, Christopher J. PeBenito wrote:
> On 02/01/11 15:03, Guido Trentalancia wrote:
> > Hello Christopher !
> >
> > On Tue, 01/02/2011 at 09.05 -0500, Christopher J. PeBenito wrote:
> >> On 01/31/11 18:15, Guido Trentalancia wrote:
> >>> Hello again Christopher !
> >>>
> >>> On Mon, 31/01/2011 at 13.52 -0500, Christopher J. PeBenito wrote:
> >>>> On 1/24/2011 9:24 AM, Dominick Grift wrote:
> >>>>> On 01/24/2011 01:43 AM, Guido Trentalancia wrote:
> >>>>
> >>>> Please include descriptions on each of your patches. The subject is
> >>>> definitely insufficient. I guess this is all the dbus changes you
> >>>> suggest? More
> >>>
> >>> The DBus send_msg issue is the probably the main change introduced by
> >>> the set of patches that I am proposing.
> >>>
> >>> The issue is very wide and needs careful approval. It's not limited to
> >>> this [2/19] patch/thread at all. It is mainly a style issue, but it's an
> >>> important one.
> >>>
> >>> In my reply to [0/19] I have pointed out a few threads where such issue
> >>> has been discussed more extensively between me and Dominick, because we
> >>> kept having different point of views and none of us managed to
> >>> definitely persuade the other !
> >>>
> >>> In any case, [2/19] and [8/19] are perhaps the most relevant places
> >>> where you can provide a definite direction on this (in short, can we
> >>> really talk about an hypothetical DBus "chat" throughout all refpolicy
> >>> and model interfaces accordingly to such assumption when on the other
> >>> hand the elementary data-flow in DBus is constituted by a
> >>> uni-directional message called "signal" ?).
> >>
> >> There already is an established verb for unidirectional dbus messaging:
> >> send. See unconfined_dbus_send() for an example. If there is
> >> unidirectional messaging, the policy should reflect that.
> >
> > Yes, unconfined_dbus_send() can be used in the context of the unconfined
> > domain.
> >
> > But then there are many other circumstances where DBus messaging needs
> > to take place. My original dbus-messaging patch ([2/19]) contains
> > several examples of where this appears to be needed.
> >
> > I prefer to grant two distinct and separate uni-directional send_msg
> > permissions in the two relevant modules anyway (even in the case of
> > bi-directional messaging).
>
> I'm not sure if I understand. Are you saying that you want to break
> apart the chat interfaces into individual send interfaces?
>
> eg:
>
> networkmanager_dbus_chat(hald_t)
>
> turns into
>
> networkmanager_dbus_send(hald_t)
> hald_dbus_send(networkmanager_t)
>
> (of course these would be in the proper modules)
>
> > Therefore, I have always created new *_dbus_send() interfaces even where
> > *_dbus_chat() interfaces were present (and could in theory be used).
>
> I don't have a problem with this.
Yes, I was referring exactly to that. Excellent.
Thanks a lot for your advice.
Best regards,
Guido
^ permalink raw reply
* test message (add List-ID: header)
From: Benjamin LaHaise @ 2011-02-01 21:00 UTC (permalink / raw)
To: linux-mm
This is a test. Nothing to see. Please ignore the man behind the curtain.
-owner-linux-mm
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [Buildroot] [PATCH] Makefile.package.in: fix upper case $(PKG)_SITE_METHOD
From: Thomas Petazzoni @ 2011-02-01 21:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <AANLkTikUX0mZAwBhX=xVYYtmHR8gp1K3cBde=w7wpwhH@mail.gmail.com>
On Tue, 1 Feb 2011 21:51:38 +0100
Daniel Nystr?m <daniel.nystrom@timeterminal.se> wrote:
> Maybe, after all, this is a special case where both upper and lower
> case should work?
Hum, why would it be necessary to accept upper case spelling ?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: User space RAID-6 access
From: Piergiorgio Sartor @ 2011-02-01 21:00 UTC (permalink / raw)
To: NeilBrown; +Cc: Piergiorgio Sartor, linux-raid
In-Reply-To: <20110202071850.3b671c1e@notabene.brown>
> I didn't realise that you wanted to look at the members of the array while
> the array was active!! That is a bit harder. But not impossible.
Well, let's say that would be optimal, but even
off-line could be OK.
BTW, what does it mean "off-line"?
Does it mean that /dev/mdX exists, but it is not
used (un-mounted), or it is just read-only, or
it should *not* exists and only the componing
HDDs are available?
> If you write a couple of numbers to 'suspend_lo' and 'suspend_hi' in sysfs,
> then writes to blocks between those two array addresses will be blocked.
> So you could suspend a region, look at the blocks, then un-suspend.
Oh, thanks, I will consider the option.
bye,
--
piergiorgio
^ permalink raw reply
* Re: Kernel 2.6.32-5-amd64 fails to boot.
From: Rudy Zijlstra @ 2011-02-01 21:02 UTC (permalink / raw)
To: lrhorer; +Cc: 'Linux RAID'
In-Reply-To: <1D.26.13137.882784D4@cdptpa-omtalb.mail.rr.com>
On 02/01/2011 09:52 PM, Leslie Rhorer wrote:
>> On 02/01/2011 09:23 PM, Leslie Rhorer wrote:
>>
>>
>>> doesn't boot, either. It gives a bit more detail in the output, but
>>>
>> nothing
>>
>>> illuminating. The old kernel (2.6.32-3-amd64) boots just fine.
>>>
>>>
>> Can you enable serial console and catch the console output that way?
>>
> Well, not easily. I don't have a serial terminal. I suppose I
> could set something up. You're suggesting I poke around to see what md is
> reporting? Also, I'm not sure why - if the keyboard console is failing -
> the serial console would work better.
>
>
>
Serial console can be captured to a file and then the output analysed.
So you can read afterwards the messages that are flying past.
What i do in such case, is that i take serial connector from a laptop,
and run a terminal emulater like minicom. And capture it to a file so i
can analyse what has been happening.
^ permalink raw reply
* [Buildroot] [PATCH] Add package bonnie++
From: Thomas Petazzoni @ 2011-02-01 21:02 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1296580740-4790-1-git-send-email-mort@bork.org>
Hello,
On Tue, 1 Feb 2011 12:19:00 -0500
Martin Hicks <mort@bork.org> wrote:
> A good filesystem performance benchmark program
>
> Signed-off-by: Martin Hicks <mort@bork.org>
Thanks for this package. Some comments below.
> +config BR2_PACKAGE_BONNIE
> + bool "bonnie++"
> + help
> + Filesystem tester
Here the indent should be one tab + two spaces.
> +BONNIE_VERSION = 1.03e
> +BONNIE_SOURCE = bonnie++-$(BONNIE_VERSION).tgz
> +BONNIE_SITE = http://www.coker.com.au/bonnie++/
> +BONNIE_INSTALL_TARGET_OPT = INSTALL="install -m 0755" install-bin
This is not needed if you override the installation as done below by
BONNE_INSTALL_TARGET_CMDS.
> +define BONNIE_INSTALL_TARGET_CMDS
> + install -D -m 755 $(@D)/bonnie++ $(TARGET_DIR)/usr/sbin
should be
install -D -m 755 $(@D)/bonnie++ $(TARGET_DIR)/usr/sbin/bonnie++
> + install -D -m 755 $(@D)/zcav $(TARGET_DIR)/usr/sbin
should be
install -D -m 755 $(@D)/zcav $(TARGET_DIR)/usr/sbin/zcav
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH] cryptsetup: select e2fsprogs for libuuid dependency
From: Thomas Petazzoni @ 2011-02-01 21:03 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1296585857-5491-1-git-send-email-mort@bork.org>
Hello Martin,
This patch should be merged in your previous cryptsetup patch. Could
you resend a single patch with those two patches merged ?
Thanks,
Thomas
On Tue, 1 Feb 2011 13:44:17 -0500
Martin Hicks <mort@bork.org> wrote:
> Signed-off-by: Martin Hicks <mort@bork.org>
> ---
> package/cryptsetup/Config.in | 1 +
> package/cryptsetup/cryptsetup.mk | 1 -
> 2 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/package/cryptsetup/Config.in b/package/cryptsetup/Config.in
> index 23c4afa..8b543cd 100644
> --- a/package/cryptsetup/Config.in
> +++ b/package/cryptsetup/Config.in
> @@ -3,6 +3,7 @@ config BR2_PACKAGE_CRYPTSETUP
> select BR2_PACKAGE_LIBGCRYPT
> select BR2_PACKAGE_POPT
> select BR2_PACKAGE_LVM2
> + select BR2_PACKAGE_E2FSPROGS
> help
> This tool helps manipulate dm-crypt and luks partitions for on-disk
> encryption.
> diff --git a/package/cryptsetup/cryptsetup.mk b/package/cryptsetup/cryptsetup.mk
> index 5b0310f..33869c7 100644
> --- a/package/cryptsetup/cryptsetup.mk
> +++ b/package/cryptsetup/cryptsetup.mk
> @@ -6,7 +6,6 @@ CRYPTSETUP_SOURCE = cryptsetup-$(CRYPTSETUP_VERSION).tar.bz2
> CRYPTSETUP_SITE = http://cryptsetup.googlecode.com/files
> CRYPTSETUP_INSTALL_STAGING = NO
> CRYPTSETUP_INSTALL_TARGET = YES
> -#CRYPTSETUP_CONF_OPT = --BLAH
> CRYPTSETUP_DEPENDENCIES = lvm2 libgcrypt popt e2fsprogs
>
> $(eval $(call AUTOTARGETS,package,cryptsetup))
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH] Add cryptsetup package
From: Thomas Petazzoni @ 2011-02-01 21:04 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1296580718-4746-1-git-send-email-mort@bork.org>
Hello,
On Tue, 1 Feb 2011 12:18:38 -0500
Martin Hicks <mort@bork.org> wrote:
> +CRYPTSETUP_INSTALL_STAGING = NO
> +CRYPTSETUP_INSTALL_TARGET = YES
Those are not needed, this is the default.
> +#CRYPTSETUP_CONF_OPT = --BLAH
Not needed (but removed by your followup patch that should be merged
here).
> +CRYPTSETUP_DEPENDENCIES = lvm2 libgcrypt popt e2fsprogs
As done by your followup patch, if you have an e2fsprogs dependency
here, you should also have the dependency in the Config.in file.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] compat: backport alloc_ordered_workqueue
From: Hauke Mehrtens @ 2011-02-01 21:04 UTC (permalink / raw)
To: mcgrof; +Cc: linux-wireless, Hauke Mehrtens
This was moved from a patch in compat-wireless to this place.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
include/linux/compat-2.6.37.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/compat-2.6.37.h b/include/linux/compat-2.6.37.h
index 502d2b1..e993f75 100644
--- a/include/linux/compat-2.6.37.h
+++ b/include/linux/compat-2.6.37.h
@@ -106,6 +106,8 @@ extern void compat_led_classdev_unregister(struct led_classdev *led_cdev);
extern void compat_led_brightness_set(struct led_classdev *led_cdev,
enum led_brightness brightness);
+#define alloc_ordered_workqueue(name, flags) create_singlethread_workqueue(name)
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37)) */
#endif /* LINUX_26_37_COMPAT_H */
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] compat: add support for kernel 2.6.38
From: Hauke Mehrtens @ 2011-02-01 21:04 UTC (permalink / raw)
To: mcgrof; +Cc: linux-wireless, Hauke Mehrtens
In-Reply-To: <1296594253-21273-1-git-send-email-hauke@hauke-m.de>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
include/linux/compat-2.6.38.h | 17 -----------------
include/linux/compat-2.6.39.h | 27 +++++++++++++++++++++++++++
include/linux/compat-2.6.h | 1 +
3 files changed, 28 insertions(+), 17 deletions(-)
create mode 100644 include/linux/compat-2.6.39.h
diff --git a/include/linux/compat-2.6.38.h b/include/linux/compat-2.6.38.h
index 0521156..004fe27 100644
--- a/include/linux/compat-2.6.38.h
+++ b/include/linux/compat-2.6.38.h
@@ -8,23 +8,6 @@
#include <linux/kernel.h>
#include <linux/skbuff.h>
-/*
- * This is not part of The 2.6.37 kernel yet but we
- * we use it to optimize the backport code we
- * need to implement. Instead of using ifdefs
- * to check what version of the check we use
- * we just replace all checks on current code
- * with this. I'll submit this upstream too, that
- * way all we'd have to do is to implement this
- * for older kernels, then we would not have to
- * edit the upstrema code for backport efforts.
- */
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
-#define br_port_exists(dev) (dev->priv_flags & IFF_BRIDGE_PORT)
-#else
-#define br_port_exists(dev) (dev->br_port)
-#endif
-
/* rename member in struct mmc_host in include/linux/mmc/host.h */
#define max_segs max_hw_segs
diff --git a/include/linux/compat-2.6.39.h b/include/linux/compat-2.6.39.h
new file mode 100644
index 0000000..c0c98fd
--- /dev/null
+++ b/include/linux/compat-2.6.39.h
@@ -0,0 +1,27 @@
+#ifndef LINUX_26_39_COMPAT_H
+#define LINUX_26_39_COMPAT_H
+
+#include <linux/version.h>
+
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39))
+
+/*
+ * This is not part of The 2.6.37 kernel yet but we
+ * we use it to optimize the backport code we
+ * need to implement. Instead of using ifdefs
+ * to check what version of the check we use
+ * we just replace all checks on current code
+ * with this. I'll submit this upstream too, that
+ * way all we'd have to do is to implement this
+ * for older kernels, then we would not have to
+ * edit the upstrema code for backport efforts.
+ */
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
+#define br_port_exists(dev) (dev->priv_flags & IFF_BRIDGE_PORT)
+#else
+#define br_port_exists(dev) (dev->br_port)
+#endif
+
+#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)) */
+
+#endif /* LINUX_26_39_COMPAT_H */
diff --git a/include/linux/compat-2.6.h b/include/linux/compat-2.6.h
index 2706797..478f833 100644
--- a/include/linux/compat-2.6.h
+++ b/include/linux/compat-2.6.h
@@ -31,5 +31,6 @@
#include <linux/compat-2.6.36.h>
#include <linux/compat-2.6.37.h>
#include <linux/compat-2.6.38.h>
+#include <linux/compat-2.6.39.h>
#endif /* LINUX_26_COMPAT_H */
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.