* Re: [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock
From: Nicolas Kalkhof @ 2011-11-07 13:52 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, intel-gfx
Hi Daniel,
thanks for the git branch. Strange thing is with the patched kernel the cpu load goes up after working with my desktop with no obvious reason. top shows a high user and system load but no process using up all the cpu cores. The cpufreq-daemon clocks the cpu cores down to the minimal frequency (800mhz) when idle while top still shows full cpu load but no process using up the cpu. The cpu load drops to normal after I kill X and immediately goes up again if I restart X.
I'm kinda lost here :( Any Ideas?
Regards
Nic
-----Ursprüngliche Nachricht-----
Von: "Daniel Vetter" <daniel@ffwll.ch>
Gesendet: Nov 6, 2011 6:46:54 PM
An: "Nicolas Kalkhof" <nkalkhof@web.de>
Betreff: Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock
>On Sun, Nov 06, 2011 at 06:42:00PM +0100, Nicolas Kalkhof wrote:
>> is there a specific git branch availble where I can test your patch? I'm
>> also experiencing random forcewake hangs and would like to see if your
>> patch helps.
>
>Please grab the my-next branch from my personal repo:
>
>http://cgit.freedesktop.org/~danvet/drm/log/?h=my-next
>
>Yours, Daniel
>--
>Daniel Vetter
>Mail: daniel@ffwll.ch
>Mobile: +41 (0)79 365 57 48
___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Broken BAD_RECOMMENDATIONS support
From: Otavio Salvador @ 2011-11-07 13:45 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Hello,
It seems BAD_RECOMMENDATIONS support, in ipk, is broken.
I checked and the rootfs_ipk is writting the contents into the opkg's
status file however it seems opkg when starts to install the packages
it overwrites or ignores it. People at IRC confirmated that this also
happens to them and thus this is indeed broken.
Do someone know how I can debug opkg to see what's going on?
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: [Qemu-devel] GSoC mentor summit QEMU users session
From: Fabien Chouteau @ 2011-11-07 13:51 UTC (permalink / raw)
To: Stefan Hajnoczi, Alexander Graf, qemu-devel@nongnu.org Developers,
Lluís Vilanova
In-Reply-To: <874nygf8x3.fsf@ginnungagap.bsc.es>
On 07/11/2011 12:50, Lluís Vilanova wrote:
> Fabien Chouteau writes:
>
>> On 04/11/2011 19:45, Lluís Vilanova wrote:
>>> I've only had a brief look into the changes, but I think the mechanism I
>>> implemented has a cleaner fit into QEMU, thanks to previous feedback from this
>>> list.
>
>> I don't know about your implementation, can you give more information?
>> What type of analysis is supported (object, statement, decision, MC/DC)?
>> Which language? And maybe you can post a link to your repository.
>
> I'll be posting the patches once QEMU opens up for new commits other than
> release stabilization. If this is too far away in time, please tell me.
>
>
>>> It explicitly separates the tracing mechanism (in QEMU itself) from the specific
>>> trace analysis (which resides in a separate library specified by the user at
>>> compile time, where most of couverture would go).
>
>> As I understand everything is compiled within Qemu, right?
>
>> GNATcoverage seems even more separate. We use Qemu to generate an
>> execution trace file and the coverage analysis tool is a totally
>> separate program. You can add support for another language or implement
>> your own coverage tool without recompiling (redistribute) Qemu.
>
> The process is basically:
>
> * Add trace events that can work during TCG code generation (e.g., start TB,
> start instruction fetch, memory access, etc.)
>
> * Let the user select which trace events to instrument, including both "regular"
> trace events and TCG trace events (thus you instrument at both execution and
> translation time).
>
> * The user provides her own implementation of the instrumented trace events.
>
> As you can see, this system only gives you the hooks were code can be
> inserted. Whether your hooks implement everything inside QEMU or just write a
> trace file, that is up to you.
>
Interesting, what kind of analysis do you plan to perform with this?
> [...]
>>>
>>> On the other hand, I have a complementary set of events, so we can definitely
>>> join the efforts on that side (e.g., I haven't yet went into the trouble of
>>> adding the begin/end TB or branch events).
>
>> I don't know what do you mean by events, but we sure can join efforts on
>> coverage with Qemu.
>
> Well, my target is not code coverage, but generating events that can be used for
> architecture simulation. In any case, there will surely be trace events that
> we're both interested in (e.g., TB start and branch).
>
OK I thought you were talking about coverage. I'm not sure if and how we
can implement coverage using your events but for the moment both
features can cohabit.
--
Fabien Chouteau
^ permalink raw reply
* Re: [PATCH] distclean: Remove generated .dtb files
From: Rob Herring @ 2011-11-07 13:51 UTC (permalink / raw)
To: Dirk Behme
Cc: Dirk Behme, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Jason Liu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
grant.likely-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1320473955-4500-1-git-send-email-dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
On 11/05/2011 01:19 AM, Dirk Behme wrote:
> The patch 'arm/dt: Add dtb make rule' adds support to
> create a .dtb file. But this is never removed afterwards.
> Remove the generated .dtb file if 'distclean' is called.
>
> Signed-off-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
> CC: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> CC: Shawn Guo <shawn.guo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> CC: Jason Liu <jason.hui-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> CC: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> ---
Acked-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> arch/arm/boot/Makefile | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> index 1cd9b0a..08f0d35 100644
> --- a/arch/arm/boot/Makefile
> +++ b/arch/arm/boot/Makefile
> @@ -71,6 +71,8 @@ $(obj)/%.dtb: $(src)/dts/%.dts
>
> $(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
>
> +clean-files := *.dtb
> +
> quiet_cmd_uimage = UIMAGE $@
> cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
> -C none -a $(LOADADDR) -e $(STARTADDR) \
^ permalink raw reply
* [PATCH] distclean: Remove generated .dtb files
From: Rob Herring @ 2011-11-07 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320473955-4500-1-git-send-email-dirk.behme@de.bosch.com>
On 11/05/2011 01:19 AM, Dirk Behme wrote:
> The patch 'arm/dt: Add dtb make rule' adds support to
> create a .dtb file. But this is never removed afterwards.
> Remove the generated .dtb file if 'distclean' is called.
>
> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
> CC: Rob Herring <rob.herring@calxeda.com>
> CC: Shawn Guo <shawn.guo@freescale.com>
> CC: Jason Liu <jason.hui@linaro.org>
> CC: Grant Likely <grant.likely@secretlab.ca>
> ---
Acked-by: Rob Herring <rob.herring@calxeda.com>
> arch/arm/boot/Makefile | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> index 1cd9b0a..08f0d35 100644
> --- a/arch/arm/boot/Makefile
> +++ b/arch/arm/boot/Makefile
> @@ -71,6 +71,8 @@ $(obj)/%.dtb: $(src)/dts/%.dts
>
> $(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
>
> +clean-files := *.dtb
> +
> quiet_cmd_uimage = UIMAGE $@
> cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
> -C none -a $(LOADADDR) -e $(STARTADDR) \
^ permalink raw reply
* Re: [PATCH] agp: Enable all supported rates for graphic cards
From: Konrad Rzeszutek Wilk @ 2011-11-07 13:50 UTC (permalink / raw)
To: Tormod Volden; +Cc: dri-devel
In-Reply-To: <1320591801-31496-1-git-send-email-lists.tormod@gmail.com>
On Sun, Nov 06, 2011 at 04:03:21PM +0100, Tormod Volden wrote:
> From: Tormod Volden <debian.tormod@gmail.com>
>
> Some cards report that they support only 4x, in which case they
> should support 2x and 1x as well, according to the AGP spec.
Have you tested it on other hardware besides your KN133?
>
> Otherwise a requested 1x or 2x rate will result in 0 being set:
>
> agpgart-via 0000:00:00.0: putting AGP V2 device into 0x mode
>
> For instance ProSavage KN133 [5333:8d02] only reports 4x.
>
> Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
> ---
> drivers/char/agp/generic.c | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
> index b072648..c5d04e5 100644
> --- a/drivers/char/agp/generic.c
> +++ b/drivers/char/agp/generic.c
> @@ -526,6 +526,24 @@ static void agp_v2_parse_one(u32 *requested_mode, u32 *bridge_agpstat, u32 *vga_
> break;
> }
>
> + /* Some graphic cards report they only support 4x, however the AGP 2.0 spec
> + * (section 4.1.1) says components must support the lower speeds as well.
> + */
> + switch (*vga_agpstat & 7) {
> + case 4:
> + *vga_agpstat |= (AGPSTAT2_2X | AGPSTAT2_1X);
> + printk(KERN_INFO PFX "Graphics card claims to only support x4 rate. "
> + "Fixing up support for x2 & x1\n");
> + break;
> + case 2:
> + *vga_agpstat |= AGPSTAT2_1X;
> + printk(KERN_INFO PFX "Graphics card claims to only support x2 rate. "
> + "Fixing up support for x1\n");
> + break;
> + default:
> + break;
> + }
> +
> /* Check the speed bits make sense. Only one should be set. */
> tmp = *requested_mode & 7;
> switch (tmp) {
> --
> 1.7.5.4
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: Special drives for Linux Raid?
From: Miles Fidelman @ 2011-11-07 13:49 UTC (permalink / raw)
Cc: linux-raid
In-Reply-To: <4EB7DD23.9090907@agenda.si>
Danilo Godec wrote:
> Some manufacturers make 'special' versions of drives for RAID (WD RE4,
> Seagate SE, ...). Apparently the main difference is in error handling,
> where normal 'desktop' drives try hard to recover an error (up to
> several minutes) while RAID drives give up quickly (few seconds) so
> that the RAID controller can take over.
>
not so much "special" as "different"
the term to look for is "enterprise"
you've identified the key distinction:
- desktop drives assume that they have the only copy of your data, the
on-board processor tries very hard to read and re-read until it returns
your data ---- the result is that everything slows down
- if you have a raid array, you want a failing disk to give up and
return, very quickly, so that the data can be read from a different drive
I learned this the hard way, when I had a server that just slowed way
down to the point that it took 10 seconds or more to echo a keystroke.
It took me a long time to figure out what was going on - and some rather
painful false starts (trashed the o/s).
One important thing I discovered: the md RAID driver does NOT consider
a long time delay as a signal to fail a drive out of an array. It's a
really good idea to run mdstat and keep an eye on your drives. If Raw
Reed Error goes above 0, start paying attention.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra
^ permalink raw reply
* Re: [PATCH v8 REPOST 17/24] gpio/omap: fix debounce clock handling
From: DebBarma, Tarun Kanti @ 2011-11-07 13:49 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, tony, linux-arm-kernel
In-Reply-To: <87hb2jdeof.fsf@ti.com>
On Fri, Nov 4, 2011 at 10:10 PM, Kevin Hilman <khilman@ti.com> wrote:
> Tarun Kanti DebBarma <tarun.kanti@ti.com> writes:
>
>> Currently debounce clock state is not tracked in the system.
>
> ??
>
> bank->dbck_enable_mask ?
As I understand, this only tells which all GPIOs have debounce timeout enabled.
But, during system operation as debounce clocks are enabled and disabled I need
additional flag to keep track of current state (enabled/disabled).
This is what I meant.
>
>> The bank->dbck
>> is enabled/disabled in suspend/idle paths irrespective of whether debounce
>> interval has been set or not.
>
> No. It's conditional based on bank->dbck_enable_mask, which is based on
> whether or not debounce has been enabled.
You are right. I need to rephrase my description.
>
>> Ideally, it should be handled only for those
>> gpio banks where the debounce is enabled.
>
> AFAICT, it is. Please explain more what is actually happening in the
> patch, and why.
Yes, as I explained above, it is more about the tracking the debounce clock
enabled/disabled state for those GPIOs whose debounce timeouts are enabled.
I will modify the patch description.
>
>> In _set_gpio_debounce, enable debounce clock before accessing
>> registers.
>
> This is a separate issue/bug and wants its own patch with descriptive
> changelog.
OK.
>
>> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
>> ---
>> During further internal testing it was found that image was crashing within
>> _set_gpio_debounce(). It is observed that we are trying to access registers
>> without enabling debounce clock. This patch incorporates the change whereby
>> the debounce clock is enabled before accessing registers and disabled at the
>> end of the function.
>>
>> drivers/gpio/gpio-omap.c | 60 ++++++++++++++++++++++++++++++++-------------
>> 1 files changed, 42 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index fa6c9c5..85e9c2a 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -65,6 +65,7 @@ struct gpio_bank {
>> struct clk *dbck;
>> u32 mod_usage;
>> u32 dbck_enable_mask;
>> + bool dbck_enabled;
>> struct device *dev;
>> bool is_mpuio;
>> bool dbck_flag;
>> @@ -156,6 +157,22 @@ static inline void _gpio_rmw(void __iomem *base, u32 reg, u32 mask, bool set)
>> __raw_writel(l, base + reg);
>> }
>>
>> +static inline void _gpio_dbck_enable(struct gpio_bank *bank)
>> +{
>> + if (bank->dbck_enable_mask && !bank->dbck_enabled) {
>> + clk_enable(bank->dbck);
>> + bank->dbck_enabled = true;
>> + }
>> +}
>> +
>> +static inline void _gpio_dbck_disable(struct gpio_bank *bank)
>> +{
>> + if (bank->dbck_enable_mask && bank->dbck_enabled) {
>> + clk_disable(bank->dbck);
>> + bank->dbck_enabled = false;
>> + }
>> +}
>> +
>> /**
>> * _set_gpio_debounce - low level gpio debounce time
>> * @bank: the gpio bank we're acting upon
>> @@ -184,22 +201,22 @@ static void _set_gpio_debounce(struct gpio_bank *bank, unsigned gpio,
>>
>> l = GPIO_BIT(bank, gpio);
>>
>> + clk_enable(bank->dbck);
>> reg = bank->base + bank->regs->debounce;
>> __raw_writel(debounce, reg);
>>
>> reg = bank->base + bank->regs->debounce_en;
>> val = __raw_readl(reg);
>>
>> - if (debounce) {
>> + if (debounce)
>> val |= l;
>> - clk_enable(bank->dbck);
>> - } else {
>> + else
>> val &= ~l;
>> - clk_disable(bank->dbck);
>> - }
>> +
>> bank->dbck_enable_mask = val;
>>
>> __raw_writel(val, reg);
>> + clk_disable(bank->dbck);
>> }
>>
>> static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
>> @@ -485,8 +502,10 @@ static int omap_gpio_request(struct gpio_chip *chip, unsigned offset)
>> * If this is the first gpio_request for the bank,
>> * enable the bank module.
>> */
>> - if (!bank->mod_usage)
>> + if (!bank->mod_usage) {
>> + _gpio_dbck_enable(bank);
>> pm_runtime_get_sync(bank->dev);
>> + }
>>
>> spin_lock_irqsave(&bank->lock, flags);
>> /* Set trigger to none. You need to enable the desired trigger with
>> @@ -549,8 +568,10 @@ static void omap_gpio_free(struct gpio_chip *chip, unsigned offset)
>> * If this is the last gpio to be freed in the bank,
>> * disable the bank module.
>> */
>> - if (!bank->mod_usage)
>> + if (!bank->mod_usage) {
>> pm_runtime_put_sync(bank->dev);
>> + _gpio_dbck_disable(bank);
>
> Why not add this to the ->runtime_suspend() callback?
Yes, I can move there and test.
>
>> + }
>> }
>>
>> /*
>> @@ -829,8 +850,10 @@ static int gpio_debounce(struct gpio_chip *chip, unsigned offset,
>>
>> if (!bank->dbck) {
>> bank->dbck = clk_get(bank->dev, "dbclk");
>> - if (IS_ERR(bank->dbck))
>> + if (IS_ERR(bank->dbck)) {
>> dev_err(bank->dev, "Could not get gpio dbck\n");
>> + return -EINVAL;
>> + }
>> }
>>
>> spin_lock_irqsave(&bank->lock, flags);
>> @@ -1086,6 +1109,8 @@ static int omap_gpio_suspend(struct device *dev)
>> bank->saved_wakeup = __raw_readl(wake_status);
>> _gpio_rmw(base, bank->regs->wkup_en, bank->suspend_wakeup, 1);
>> spin_unlock_irqrestore(&bank->lock, flags);
>> +
>> + _gpio_dbck_disable(bank);
>
> If this call was in the ->runtime_suspend() callback, you wouldn't need
> it here.
Yes.
>
>> }
>>
>> return 0;
>> @@ -1102,6 +1127,8 @@ static int omap_gpio_resume(struct device *dev)
>> if (!bank->regs->wkup_en)
>> return 0;
>>
>> + _gpio_dbck_enable(bank);
>
> Similarily, this call should be in the ->runtime_resume() callback and
> it wouldn't be needed here.
Right.
>
> Using the runtime PM callbacks, all the _gpio_dbck_* calls below would
> not be needed.
Yes.
--
Tarun
>
>> spin_lock_irqsave(&bank->lock, flags);
>> _gpio_rmw(base, bank->regs->wkup_en, bank->saved_wakeup, 1);
>> spin_unlock_irqrestore(&bank->lock, flags);
>> @@ -1120,16 +1147,14 @@ void omap2_gpio_prepare_for_idle(int off_mode)
>>
>> list_for_each_entry(bank, &omap_gpio_list, node) {
>> u32 l1 = 0, l2 = 0;
>> - int j;
>>
>> if (!bank->loses_context)
>> continue;
>>
>> - for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
>> - clk_disable(bank->dbck);
>> -
>> - if (!off_mode)
>> + if (!off_mode) {
>> + _gpio_dbck_disable(bank);
>> continue;
>> + }
>>
>> /* If going to OFF, remove triggering for all
>> * non-wakeup GPIOs. Otherwise spurious IRQs will be
>> @@ -1151,15 +1176,16 @@ void omap2_gpio_prepare_for_idle(int off_mode)
>> __raw_writel(l2, bank->base + bank->regs->risingdetect);
>>
>> save_gpio_context:
>> -
>> if (bank->get_context_loss_count)
>> bank->context_loss_count =
>> bank->get_context_loss_count(bank->dev);
>>
>> omap_gpio_save_context(bank);
>>
>> - if (!pm_runtime_suspended(bank->dev))
>> + if (!pm_runtime_suspended(bank->dev)) {
>> pm_runtime_put_sync(bank->dev);
>> + _gpio_dbck_disable(bank);
>> + }
>> }
>> }
>>
>> @@ -1170,13 +1196,11 @@ void omap2_gpio_resume_after_idle(void)
>> list_for_each_entry(bank, &omap_gpio_list, node) {
>> u32 context_lost_cnt_after;
>> u32 l = 0, gen, gen0, gen1;
>> - int j;
>>
>> if (!bank->loses_context)
>> continue;
>>
>> - for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
>> - clk_enable(bank->dbck);
>> + _gpio_dbck_enable(bank);
>> if (pm_runtime_suspended(bank->dev))
>> pm_runtime_get_sync(bank->dev);
>
> Kevin
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
* [PATCH v8 REPOST 17/24] gpio/omap: fix debounce clock handling
From: DebBarma, Tarun Kanti @ 2011-11-07 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87hb2jdeof.fsf@ti.com>
On Fri, Nov 4, 2011 at 10:10 PM, Kevin Hilman <khilman@ti.com> wrote:
> Tarun Kanti DebBarma <tarun.kanti@ti.com> writes:
>
>> Currently debounce clock state is not tracked in the system.
>
> ??
>
> bank->dbck_enable_mask ?
As I understand, this only tells which all GPIOs have debounce timeout enabled.
But, during system operation as debounce clocks are enabled and disabled I need
additional flag to keep track of current state (enabled/disabled).
This is what I meant.
>
>> The bank->dbck
>> is enabled/disabled in suspend/idle paths irrespective of whether debounce
>> interval has been set or not.
>
> No. ?It's conditional based on bank->dbck_enable_mask, which is based on
> whether or not debounce has been enabled.
You are right. I need to rephrase my description.
>
>> Ideally, it should be handled only for those
>> gpio banks where the debounce is enabled.
>
> AFAICT, it is. ?Please explain more what is actually happening in the
> patch, and why.
Yes, as I explained above, it is more about the tracking the debounce clock
enabled/disabled state for those GPIOs whose debounce timeouts are enabled.
I will modify the patch description.
>
>> In _set_gpio_debounce, enable debounce clock before accessing
>> registers.
>
> This is a separate issue/bug and wants its own patch with descriptive
> changelog.
OK.
>
>> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
>> ---
>> During further internal testing it was found that image was crashing within
>> _set_gpio_debounce(). It is observed that we are trying to access registers
>> without enabling debounce clock. This patch incorporates the change whereby
>> the debounce clock is enabled before accessing registers and disabled at the
>> end of the function.
>>
>> ?drivers/gpio/gpio-omap.c | ? 60 ++++++++++++++++++++++++++++++++-------------
>> ?1 files changed, 42 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index fa6c9c5..85e9c2a 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -65,6 +65,7 @@ struct gpio_bank {
>> ? ? ? struct clk *dbck;
>> ? ? ? u32 mod_usage;
>> ? ? ? u32 dbck_enable_mask;
>> + ? ? bool dbck_enabled;
>> ? ? ? struct device *dev;
>> ? ? ? bool is_mpuio;
>> ? ? ? bool dbck_flag;
>> @@ -156,6 +157,22 @@ static inline void _gpio_rmw(void __iomem *base, u32 reg, u32 mask, bool set)
>> ? ? ? __raw_writel(l, base + reg);
>> ?}
>>
>> +static inline void _gpio_dbck_enable(struct gpio_bank *bank)
>> +{
>> + ? ? if (bank->dbck_enable_mask && !bank->dbck_enabled) {
>> + ? ? ? ? ? ? clk_enable(bank->dbck);
>> + ? ? ? ? ? ? bank->dbck_enabled = true;
>> + ? ? }
>> +}
>> +
>> +static inline void _gpio_dbck_disable(struct gpio_bank *bank)
>> +{
>> + ? ? if (bank->dbck_enable_mask && bank->dbck_enabled) {
>> + ? ? ? ? ? ? clk_disable(bank->dbck);
>> + ? ? ? ? ? ? bank->dbck_enabled = false;
>> + ? ? }
>> +}
>> +
>> ?/**
>> ? * _set_gpio_debounce - low level gpio debounce time
>> ? * @bank: the gpio bank we're acting upon
>> @@ -184,22 +201,22 @@ static void _set_gpio_debounce(struct gpio_bank *bank, unsigned gpio,
>>
>> ? ? ? l = GPIO_BIT(bank, gpio);
>>
>> + ? ? clk_enable(bank->dbck);
>> ? ? ? reg = bank->base + bank->regs->debounce;
>> ? ? ? __raw_writel(debounce, reg);
>>
>> ? ? ? reg = bank->base + bank->regs->debounce_en;
>> ? ? ? val = __raw_readl(reg);
>>
>> - ? ? if (debounce) {
>> + ? ? if (debounce)
>> ? ? ? ? ? ? ? val |= l;
>> - ? ? ? ? ? ? clk_enable(bank->dbck);
>> - ? ? } else {
>> + ? ? else
>> ? ? ? ? ? ? ? val &= ~l;
>> - ? ? ? ? ? ? clk_disable(bank->dbck);
>> - ? ? }
>> +
>> ? ? ? bank->dbck_enable_mask = val;
>>
>> ? ? ? __raw_writel(val, reg);
>> + ? ? clk_disable(bank->dbck);
>> ?}
>>
>> ?static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
>> @@ -485,8 +502,10 @@ static int omap_gpio_request(struct gpio_chip *chip, unsigned offset)
>> ? ? ? ?* If this is the first gpio_request for the bank,
>> ? ? ? ?* enable the bank module.
>> ? ? ? ?*/
>> - ? ? if (!bank->mod_usage)
>> + ? ? if (!bank->mod_usage) {
>> + ? ? ? ? ? ? _gpio_dbck_enable(bank);
>> ? ? ? ? ? ? ? pm_runtime_get_sync(bank->dev);
>> + ? ? }
>>
>> ? ? ? spin_lock_irqsave(&bank->lock, flags);
>> ? ? ? /* Set trigger to none. You need to enable the desired trigger with
>> @@ -549,8 +568,10 @@ static void omap_gpio_free(struct gpio_chip *chip, unsigned offset)
>> ? ? ? ?* If this is the last gpio to be freed in the bank,
>> ? ? ? ?* disable the bank module.
>> ? ? ? ?*/
>> - ? ? if (!bank->mod_usage)
>> + ? ? if (!bank->mod_usage) {
>> ? ? ? ? ? ? ? pm_runtime_put_sync(bank->dev);
>> + ? ? ? ? ? ? _gpio_dbck_disable(bank);
>
> Why not add this to the ->runtime_suspend() callback?
Yes, I can move there and test.
>
>> + ? ? }
>> ?}
>>
>> ?/*
>> @@ -829,8 +850,10 @@ static int gpio_debounce(struct gpio_chip *chip, unsigned offset,
>>
>> ? ? ? if (!bank->dbck) {
>> ? ? ? ? ? ? ? bank->dbck = clk_get(bank->dev, "dbclk");
>> - ? ? ? ? ? ? if (IS_ERR(bank->dbck))
>> + ? ? ? ? ? ? if (IS_ERR(bank->dbck)) {
>> ? ? ? ? ? ? ? ? ? ? ? dev_err(bank->dev, "Could not get gpio dbck\n");
>> + ? ? ? ? ? ? ? ? ? ? return -EINVAL;
>> + ? ? ? ? ? ? }
>> ? ? ? }
>>
>> ? ? ? spin_lock_irqsave(&bank->lock, flags);
>> @@ -1086,6 +1109,8 @@ static int omap_gpio_suspend(struct device *dev)
>> ? ? ? ? ? ? ? bank->saved_wakeup = __raw_readl(wake_status);
>> ? ? ? ? ? ? ? _gpio_rmw(base, bank->regs->wkup_en, bank->suspend_wakeup, 1);
>> ? ? ? ? ? ? ? spin_unlock_irqrestore(&bank->lock, flags);
>> +
>> + ? ? ? ? ? ? _gpio_dbck_disable(bank);
>
> If this call was in the ->runtime_suspend() callback, you wouldn't need
> it here.
Yes.
>
>> ? ? ? }
>>
>> ? ? ? return 0;
>> @@ -1102,6 +1127,8 @@ static int omap_gpio_resume(struct device *dev)
>> ? ? ? ? ? ? ? if (!bank->regs->wkup_en)
>> ? ? ? ? ? ? ? ? ? ? ? return 0;
>>
>> + ? ? ? ? ? ? _gpio_dbck_enable(bank);
>
> Similarily, this call should be in the ->runtime_resume() callback and
> it wouldn't be needed here.
Right.
>
> Using the runtime PM callbacks, all the _gpio_dbck_* calls below would
> not be needed.
Yes.
--
Tarun
>
>> ? ? ? ? ? ? ? spin_lock_irqsave(&bank->lock, flags);
>> ? ? ? ? ? ? ? _gpio_rmw(base, bank->regs->wkup_en, bank->saved_wakeup, 1);
>> ? ? ? ? ? ? ? spin_unlock_irqrestore(&bank->lock, flags);
>> @@ -1120,16 +1147,14 @@ void omap2_gpio_prepare_for_idle(int off_mode)
>>
>> ? ? ? list_for_each_entry(bank, &omap_gpio_list, node) {
>> ? ? ? ? ? ? ? u32 l1 = 0, l2 = 0;
>> - ? ? ? ? ? ? int j;
>>
>> ? ? ? ? ? ? ? if (!bank->loses_context)
>> ? ? ? ? ? ? ? ? ? ? ? continue;
>>
>> - ? ? ? ? ? ? for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
>> - ? ? ? ? ? ? ? ? ? ? clk_disable(bank->dbck);
>> -
>> - ? ? ? ? ? ? if (!off_mode)
>> + ? ? ? ? ? ? if (!off_mode) {
>> + ? ? ? ? ? ? ? ? ? ? _gpio_dbck_disable(bank);
>> ? ? ? ? ? ? ? ? ? ? ? continue;
>> + ? ? ? ? ? ? }
>>
>> ? ? ? ? ? ? ? /* If going to OFF, remove triggering for all
>> ? ? ? ? ? ? ? ?* non-wakeup GPIOs. ?Otherwise spurious IRQs will be
>> @@ -1151,15 +1176,16 @@ void omap2_gpio_prepare_for_idle(int off_mode)
>> ? ? ? ? ? ? ? __raw_writel(l2, bank->base + bank->regs->risingdetect);
>>
>> ?save_gpio_context:
>> -
>> ? ? ? ? ? ? ? if (bank->get_context_loss_count)
>> ? ? ? ? ? ? ? ? ? ? ? bank->context_loss_count =
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bank->get_context_loss_count(bank->dev);
>>
>> ? ? ? ? ? ? ? omap_gpio_save_context(bank);
>>
>> - ? ? ? ? ? ? if (!pm_runtime_suspended(bank->dev))
>> + ? ? ? ? ? ? if (!pm_runtime_suspended(bank->dev)) {
>> ? ? ? ? ? ? ? ? ? ? ? pm_runtime_put_sync(bank->dev);
>> + ? ? ? ? ? ? ? ? ? ? _gpio_dbck_disable(bank);
>> + ? ? ? ? ? ? }
>> ? ? ? }
>> ?}
>>
>> @@ -1170,13 +1196,11 @@ void omap2_gpio_resume_after_idle(void)
>> ? ? ? list_for_each_entry(bank, &omap_gpio_list, node) {
>> ? ? ? ? ? ? ? u32 context_lost_cnt_after;
>> ? ? ? ? ? ? ? u32 l = 0, gen, gen0, gen1;
>> - ? ? ? ? ? ? int j;
>>
>> ? ? ? ? ? ? ? if (!bank->loses_context)
>> ? ? ? ? ? ? ? ? ? ? ? continue;
>>
>> - ? ? ? ? ? ? for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
>> - ? ? ? ? ? ? ? ? ? ? clk_enable(bank->dbck);
>> + ? ? ? ? ? ? _gpio_dbck_enable(bank);
>> ? ? ? ? ? ? ? if (pm_runtime_suspended(bank->dev))
>> ? ? ? ? ? ? ? ? ? ? ? pm_runtime_get_sync(bank->dev);
>
> Kevin
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 6/8] block: add eject request callback
From: Kevin Wolf @ 2011-11-07 13:49 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Markus Armbruster, qemu-devel
In-Reply-To: <4EB7DEDE.4090809@redhat.com>
Am 07.11.2011 14:36, schrieb Paolo Bonzini:
> On 11/07/2011 02:21 PM, Markus Armbruster wrote:
>> The commit message should explain why we need this callback. The cover
>> letter says "support for eject requests is required by udev 173."
>> Please elaborate on that.
>
> Well, first and foremost eject requests are in the spec. :) The fact
> that recent guests need it is more a justification for pulling this in 1.0.
>
>> You implement it for IDE in PATCH 7/8 and SCSI in PATCH 8/8. You don't
>> implement it for floppy, despite the comment. That's okay; floppy has
>> no use for it. It's the comment that needs fixing. Devices that
>> implement is_medium_locked() must implement this one as well.
>
> Right.
>
>> 1. eject without -f behaves like the physical tray button. It has
>> immediate effect, unless the tray is locked closed. Then, the drive
>> just notifies the OS of the button push, so the OS can react to it. The
>> latter isn't implemented in QEMU.
>>
>> 2. eject with -f behaves like whatever physical way there is to pry the
>> tray open, locked or not. CD-ROM drives commonly have a little button
>> hidden in some hope you can reach with a bent paperclip.
>>
>> Could you explain your mental model?
>
> 1. eject without -f is as you mentioned.
>
> 2. eject with -f should really never be needed, but it does whatever is
> needed to be able to follow up with a "change" command. It turns out it
> is really "unlock" and "ask the guest to eject" combined, but that's the
> implementation, not the model.
Does this give different results than just asking the guest to eject
without forcefully unlocking? I would expect that a guest that responds
to the eject request would also unlock the drive. In which case I think
eject without -f should be enough?
> The difference from the paperclip model is that it gives a chance for
> the OS to clean up and eject safely. It wouldn't be hard to convince me
> otherwise though, especially if it can help getting the patch in 1.0.
> The "eject -f"+"change" can be replaced by "eject", possibly followed by
> "eject -f" after a timeout, and then followed again by "change".
Kevin
^ permalink raw reply
* Re: [PATCH] media: vb2: reset queued list on REQBUFS(0) call
From: Mauro Carvalho Chehab @ 2011-11-07 13:46 UTC (permalink / raw)
To: Pawel Osciak
Cc: Marek Szyprowski, Angela Wan, linux-media, leiwen, ytang5, qingx,
jwan, Kyungmin Park
In-Reply-To: <CAMm-=zBt9HufMLpvcDBfD3qS1vL+zwm77APcfVcPQst1zqEyPw@mail.gmail.com>
Em 25-10-2011 06:11, Pawel Osciak escreveu:
> On Tue, Oct 25, 2011 at 00:59, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> Queued list was not reset on REQBUFS(0) call. This caused enqueuing
>> a freed buffer to the driver.
>>
>> Reported-by: Angela Wan <angela.j.wan@gmail.com>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>> drivers/media/video/videobuf2-core.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf2-core.c
>> b/drivers/media/video/videobuf2-core.c
>> index 3015e60..5722b81 100644
>> --- a/drivers/media/video/videobuf2-core.c
>> +++ b/drivers/media/video/videobuf2-core.c
>> @@ -254,6 +254,7 @@ static void __vb2_queue_free(struct vb2_queue *q)
>>
>> q->num_buffers = 0;
>> q->memory = 0;
>> + INIT_LIST_HEAD(&q->queued_list);
>> }
>>
>> /**
>> --
>> 1.7.1
>>
>>
>>
>
> Acked-by: Pawel Osciak <pawel@osciak.com>
>
This patch doesn't apply anymore. Is it still needed? If so, please rebase.
Thanks!
Mauro
^ permalink raw reply
* Re: [dm-devel] Error when compiling drivers/md/dm-bufio.c
From: Alasdair G Kergon @ 2011-11-07 13:46 UTC (permalink / raw)
To: Witold Baryluk
Cc: Neil Brown, linux-raid, dm-devel, Mikulas Patocka, Linus Torvalds
In-Reply-To: <20111107082231.GB18221@smp.if.uj.edu.pl>
On Mon, Nov 07, 2011 at 09:22:31AM +0100, Witold Baryluk wrote:
> I just got error on todays Linus' tree
> CC [M] drivers/md/dm-bufio.o
> drivers/md/dm-bufio.c:988:1: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL_GPL’ [-Wimplicit-int]
Probably related to this merge:
commit 32aaeffbd4a7457bf2f7448b33b5946ff2a960eb
Merge branch 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/ker
Previously module.h was included via another header file.
Now, bufio.c needs an explicit
#include <linux/module.h>
Alasdair
--
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
* [PATCH] [TRIVIAL] 8250_hp300: Fix warning typo 'CONFIG_8250'
From: Paul Bolle @ 2011-11-07 13:44 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-kernel, Geert Uytterhoeven, linux-m68k
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
0) This patch is untested: I have neither the hardware nor the toolchain
needed. It should be correct (though it makes an already too long line
even longer). Nevertheless I think a proper solution is a patch that
drops this warning entirely. I've CC'd the m68k people for further
feedback.
1) If SERIAL_8250_HP300 is set but neither HPDCA nor HPAPCI are set we
end up with an elaborate nop, don't we? Initialization should always
fail in that case. So effectively SERIAL_8250_HP300 depends on HPDCA
and/or HPAPCI. Was there perhaps some problem in translating that
dependency into a Kconfig dependency?
2) Related question: is it useful to have both HPDCA and HPAPCI set?
drivers/tty/serial/8250_hp300.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/8250_hp300.c b/drivers/tty/serial/8250_hp300.c
index c13438c..dc41fbb 100644
--- a/drivers/tty/serial/8250_hp300.c
+++ b/drivers/tty/serial/8250_hp300.c
@@ -21,7 +21,7 @@
#include "8250.h"
#if !defined(CONFIG_HPDCA) && !defined(CONFIG_HPAPCI)
-#warning CONFIG_8250 defined but neither CONFIG_HPDCA nor CONFIG_HPAPCI defined, are you sure?
+#warning CONFIG_SERIAL_8250 defined but neither CONFIG_HPDCA nor CONFIG_HPAPCI defined, are you sure?
#endif
#ifdef CONFIG_HPAPCI
--
1.7.4.4
^ permalink raw reply related
* [Bug 42654] [3.1 regression] hwmon sysfs entry is missing
From: bugzilla-daemon @ 2011-11-07 13:44 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-42654-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42654
--- Comment #1 from Alex Deucher <agd5f@yahoo.com> 2011-11-07 05:44:44 PST ---
The aux i2c errors are unrelated and can be ignored. What was the last kernel
that has working hwmon support? Can you bisect?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: PROBLEM: Race condition in tty buffer's function flush_to_ldisc().
From: Ilya Zykov @ 2011-11-07 13:44 UTC (permalink / raw)
To: Alan Cox; +Cc: Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20111107130643.07e84fca@bob.linux.org.uk>
Alan Cox wrote:
>
>> Why we need: "if (!test_and_set_bit(TTY_FLUSHING, &tty->flags)) {"
>> if flush_to_ldisc is single threaded?
>> we can: set_bit(TTY_FLUSHING, &tty->flags)
>> without if() at all.
>
> It is single threaded with respect to itself (you can't have two
> flush_to_ldisc on the same tty at once) but you can have a parallel
> call to tty_buffer_flush. The tty_buffer_flush path needs to pick the
> right approach reliably.
>
Of course I know about tty_buffer_flush(), it only read TTY_FLUSHING,
it can't change TTY_FLUSHING, if flush_to_ldisc() single threaded,
we can change TTY_FLUSHING only in one place in one time(in flush_to_ldisc()),
therefor we can use only "set_bit(TTY_FLUSHING, &tty->flags)" without test.
^ permalink raw reply
* [PATCH] [TRIVIAL] 8250_hp300: Fix warning typo 'CONFIG_8250'
From: Paul Bolle @ 2011-11-07 13:44 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-kernel, Geert Uytterhoeven, linux-m68k
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
0) This patch is untested: I have neither the hardware nor the toolchain
needed. It should be correct (though it makes an already too long line
even longer). Nevertheless I think a proper solution is a patch that
drops this warning entirely. I've CC'd the m68k people for further
feedback.
1) If SERIAL_8250_HP300 is set but neither HPDCA nor HPAPCI are set we
end up with an elaborate nop, don't we? Initialization should always
fail in that case. So effectively SERIAL_8250_HP300 depends on HPDCA
and/or HPAPCI. Was there perhaps some problem in translating that
dependency into a Kconfig dependency?
2) Related question: is it useful to have both HPDCA and HPAPCI set?
drivers/tty/serial/8250_hp300.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/8250_hp300.c b/drivers/tty/serial/8250_hp300.c
index c13438c..dc41fbb 100644
--- a/drivers/tty/serial/8250_hp300.c
+++ b/drivers/tty/serial/8250_hp300.c
@@ -21,7 +21,7 @@
#include "8250.h"
#if !defined(CONFIG_HPDCA) && !defined(CONFIG_HPAPCI)
-#warning CONFIG_8250 defined but neither CONFIG_HPDCA nor CONFIG_HPAPCI defined, are you sure?
+#warning CONFIG_SERIAL_8250 defined but neither CONFIG_HPDCA nor CONFIG_HPAPCI defined, are you sure?
#endif
#ifdef CONFIG_HPAPCI
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] usbnet: fix oops in usbnet_start_xmit
From: Michael Riesch @ 2011-11-07 13:29 UTC (permalink / raw)
To: Konstantin Khlebnikov; +Cc: Oliver Neukum, netdev, David S. Miller, devel
In-Reply-To: <20111106183337.5379.4356.stgit@zurg>
On Sun, 2011-11-06 at 22:33 +0300, Konstantin Khlebnikov wrote:
> This patch fixes the bug added in commit v3.1-rc7-1055-gf9b491e
> SKB can be NULL at this point, at least for cdc-ncm.
OK, I didn't think of that, but...
> Let's call skb_tx_timestamp() after driver specific tx-fixup hacks.
... the reason I put the skb_tx_timestamp() call before the tx_fixup is
that these hacks often perform skb_push/skb_pull or any other kind of
framing. This may result (at least in the case of the asix drivers) in
perfectly correct PTP packets being not recognized as such by the packet
filter.
Can we do a check like this:
if(skb) skb_tx_timestamp()
tx_fixup()
?
Regards, Michael
^ permalink raw reply
* Re: BUG. Git config pager when --edit
From: Frans Klaver @ 2011-11-07 13:43 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <20111107172652.0faade61@ashu.dyn.rarus.ru>
Hi,
On Mon, Nov 7, 2011 at 2:26 PM, Alexey Shumkin <Alex.Crezoff@gmail.com> wrote:
> As far as my config is large enough to be paged I set pager.config=less
> setting. But since that moment when I run
> $ git config --edit
> I get
> Vim: Warning: Output is not to a terminal
> And some messed config output
>
> The same happens if to run
> $ vim .git/config | less
So git is trying to tell vim to pipe its output to less. vim can't do
that because it needs a terminal, as it's the only way vim is usable.
Should pager.config then only be used with --list?
^ permalink raw reply
* Re: Linux Route Cache performance tests
From: Ben Hutchings @ 2011-11-07 13:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Paweł Staszewski, Linux Network Development list
In-Reply-To: <1320608290.6506.33.camel@edumazet-laptop>
On Sun, 2011-11-06 at 20:38 +0100, Eric Dumazet wrote:
> Le dimanche 06 novembre 2011 à 20:20 +0100, Paweł Staszewski a écrit :
[...]
> > So the point of this test was figure out how much of route cache entries
> > Linux can handle without dropping performance.
>
> No need to even do a bench, its pretty easy to understand how a hash
> table is handled.
>
> Allowing long chains is not good.
>
> With your 512k slots hash table, you cannot expect handling 1.4M routes
> with optimal performance. End of story.
>
> Since route hash table is allocated at boot time, only way to change its
> size is using "rhash_entries=2097152" boot parameter.
>
> If it still doesnt fly, try with "rhash_entries=4194304"
A routing cache this big is not going to fit in the processor caches,
anyway; in fact even the hash table may not. So a routing cache hit is
likely to involve processor cache misses. After David's work to make
cacheless operation faster, I suspect that such a 'hit' can be a net
loss. But it *is* necessary to run a benchmark to answer this (and the
answer will obviously vary between systems).
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue())
From: Mike Snitzer @ 2011-11-07 13:42 UTC (permalink / raw)
To: Jun'ichi Nomura
Cc: Heiko Carstens, James Bottomley, Steffen Maier,
linux-scsi@vger.kernel.org, Jens Axboe, Hannes Reinecke,
Linux Kernel, Alan Stern, Thadeu Lima de Souza Cascardo,
Taraka R. Bodireddy, Seshagiri N. Ippili,
Manvanthara B. Puttashankar, Jeff Moyer, Shaohua Li, gmuelas
In-Reply-To: <4EB7C18D.4070607@ce.jp.nec.com>
On Mon, Nov 07 2011 at 6:31am -0500,
Jun'ichi Nomura <j-nomura@ce.jp.nec.com> wrote:
> On 11/04/11 22:30, Mike Snitzer wrote:
> > On Fri, Nov 04 2011 at 5:19am -0400,
> > Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> >
> >> On Thu, Nov 03, 2011 at 02:25:48PM -0400, Mike Snitzer wrote:
> >>> On Mon, Oct 31 2011 at 9:00am -0400,
> >>> Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> >>>
> >>>> On Mon, Oct 31, 2011 at 08:46:06PM +0900, Jun'ichi Nomura wrote:
> >>>>> Hm, dm_softirq_done is generic completion code of original
> >>>>> request in dm-multipath.
> >>>>> So oops here might be another manifestation of use-after-free.
> >>>>>
> >>>>> Do you always hit the oops at the same address?
> >>>>
> >>>> I think we saw this bug the first time. But before that the scsi
> >>>> logging level was higher. Gonzalo is trying to recreate it with
> >>>> the same (old) scsi logging level.
> >>>> Afterwards we will try with barrier=0.
> >>>>
> >>>> Both on v3.0.7 btw.
> >>>>
> >>>>> Could you find corresponding source code line for
> >>>>> the crashed address, dm_softirq_done+0x72/0x140,
> >>>>> and which pointer was invalid?
> >>>>
> >>>> It crashes in the inlined function dm_done() when trying to
> >>>> dereference tio (aka clone->end_io_data):
> >>>>
> >>>> static void dm_done(struct request *clone, int error, bool mapped)
> >>>> {
> >>>> int r = error;
> >>>> struct dm_rq_target_io *tio = clone->end_io_data;
> >>>> dm_request_endio_fn rq_end_io = tio->ti->type->rq_end_io;
> >>>
> >>> Hi,
> >>>
> >>> Which underlying storage driver is being used by this multipath device?
> >>
> >> It's the s390 only zfcp device driver.
> >>
> >> FWIW, yet another use-after-free crash, this time however in multipath_end_io:
> >>
> >> [96875.870593] Unable to handle kernel pointer dereference at virtual kernel address 6b6b6b6b6b6b6000
> >> [96875.870602] Oops: 0038 [#1]
> >> [96875.870674] PREEMPT SMP DEBUG_PAGEALLOC
> >> [96875.870683] Modules linked in: dm_round_robin sunrpc ipv6 qeth_l2 binfmt_misc dm_multipath scsi_dh dm_mod qeth ccwgroup [la\
> >> st unloaded: scsi_wait_scan]
> >> [96875.870722] CPU: 2 Tainted: G W 3.0.7-50.x.20111024-s390xdefault #1
> >> [96875.870728] Process udevd (pid: 36697, task: 0000000072c8a3a8, ksp: 0000000057c43868)
> >> [96875.870732] Krnl PSW : 0704200180000000 000003e001347138 (multipath_end_io+0x50/0x140 [dm_multipath])
> >> [96875.870746] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
> >> [96875.870751] Krnl GPRS: 0000000000000000 000003e000000000 6b6b6b6b6b6b6b6b 00000000717ab940
> >> [96875.870755] 0000000000000000 00000000717abab0 0000000000000002 0700000000000008
> >> [96875.870759] 0000000000000002 0000000000000000 0000000058dd37a8 000000006f845478
> >> [96875.870764] 000003e0012e1000 000000005613d1f0 000000007a737bf0 000000007a737ba0
> >> [96875.870768] Krnl Code: 000003e00134712a: b90200dd ltgr %r13,%r13
> >> [96875.870793] 000003e00134712e: a7840017 brc 8,3e00134715c
> >> [96875.870800] 000003e001347132: e320d0100004 lg %r2,16(%r13)
> >> [96875.870809] >000003e001347138: e31020180004 lg %r1,24(%r2)
> >> [96875.870818] 000003e00134713e: e31010580004 lg %r1,88(%r1)
> >> [96875.870827] 000003e001347144: b9020011 ltgr %r1,%r1
> >> [96875.870835] 000003e001347148: a784000a brc 8,3e00134715c
> >> [96875.870841] 000003e00134714c: 41202018 la %r2,24(%r2)
> >> [96875.870889] Call Trace:
> >> [96875.870892] ([<0700000000000008>] 0x700000000000008)
> >> [96875.870897] [<000003e0012e3662>] dm_softirq_done+0x9a/0x140 [dm_mod]
> >> [96875.870915] [<000000000040d29c>] blk_done_softirq+0xd4/0xf0
> >> [96875.870925] [<00000000001587c2>] __do_softirq+0xda/0x398
> >> [96875.870932] [<000000000010f47e>] do_softirq+0xe2/0xe8
> >> [96875.870940] [<0000000000158e2c>] irq_exit+0xc8/0xcc
> >> [96875.870945] [<00000000004ceb48>] do_IRQ+0x910/0x1bfc
> >> [96875.870953] [<000000000061a164>] io_return+0x0/0x16
> >> [96875.870961] [<000000000019c84e>] lock_acquire+0xd2/0x204
> >> [96875.870969] ([<000000000019c836>] lock_acquire+0xba/0x204)
> >> [96875.870974] [<0000000000615f8e>] mutex_lock_killable_nested+0x92/0x520
> >> [96875.870983] [<0000000000292796>] vfs_readdir+0x8a/0xe4
> >> [96875.870992] [<00000000002928e0>] SyS_getdents+0x60/0xe8
> >> [96875.870999] [<0000000000619af2>] sysc_noemu+0x16/0x1c
> >> [96875.871024] [<000003fffd1ec83e>] 0x3fffd1ec83e
> >> [96875.871028] INFO: lockdep is turned off.
> >> [96875.871031] Last Breaking-Event-Address:
> >> [96875.871037] [<000003e0012e3660>] dm_softirq_done+0x98/0x140 [dm_mod]
> >>
> >> static int multipath_end_io(struct dm_target *ti, struct request *clone,
> >> int error, union map_info *map_context)
> >> {
> >> struct multipath *m = ti->private;
> >> struct dm_mpath_io *mpio = map_context->ptr;
> >> struct pgpath *pgpath = mpio->pgpath;
> >> struct path_selector *ps;
> >> int r;
> >>
> >> r = do_end_io(m, clone, error, mpio);
> >> if (pgpath) {
> >> ps = &pgpath->pg->ps; <--- crashes here
> >> if (ps->type->end_io)
> >> ps->type->end_io(ps, &pgpath->path, mpio->nr_bytes);
> >> }
> >> mempool_free(mpio, m->mpio_pool);
> >>
> >> return r;
> >> }
> >>
> >> It crashes when trying to derefence pgpath, which was freed. Since we have
> >> SLUB debugging turned on the freed object tells us that it was allocated
> >> via a call to multipath_ctr() and freed via a call to free_priority_group().
> >>
> >> FWIW, this reproduction was done with barriers off.
> >>
> >> Btw, since I cc'ed you rather late I'm not sure if you are aware of the
> >> test scenario: it's I/O stress with multipathing were paths come and go
> >> all the time. It usually takes quite a few hours before the crashes are
> >> observed.
> >
> > OK, thanks for the backstory.
> >
> > That is the same type of testing we've been doing with some partners
> > for RHEL6.2 with the qla2xxx driver. They have seen the same crash that
> > you originally reported here: https://lkml.org/lkml/2011/10/31/64
> >
> > The really interesting observation that was made is that the qla2xxx
> > driver was made lockless in RHEL6.2. We've found that reverting the
> > qla2xxx lockless changes eliminates the problems seen with it and I/O
> > stress testing with multipath path failures.
>
> It's interesting.
> Have you analyzed how the lockless change caused the dm crash?
Not yet. It will take me some time (as I'm not overly familiar with the
SCSI lockless changes). Any assistance would be appreciated.
^ permalink raw reply
* Re: [PATCH] distclean: Remove generated .dtb files
From: Grant Likely @ 2011-11-07 13:42 UTC (permalink / raw)
To: Dirk Behme
Cc: Dirk Behme, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Jason Liu,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <4EB779CF.4040007-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1516 bytes --]
On Nov 6, 2011 11:25 PM, "Dirk Behme" <dirk.behme-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>
> On 06.11.2011 19:42, Grant Likely wrote:
>>
>> On Sun, Nov 6, 2011 at 11:38 AM, Grant Likely<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
wrote:
>>>
>>> On Sat, Nov 05, 2011 at 07:19:15AM +0100, Dirk Behme wrote:
>>>>
>>>> The patch 'arm/dt: Add dtb make rule' adds support to
>>>> create a .dtb file. But this is never removed afterwards.
>>>> Remove the generated .dtb file if 'distclean' is called.
>>>>
>>>> Signed-off-by: Dirk Behme<dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
>>>> CC: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>>> CC: Shawn Guo<shawn.guo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>>>> CC: Jason Liu<jason.hui-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>> CC: Grant Likely<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
>>>
>>>
>>> Acked-by: Grant Likely<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
>>
>>
>> ... although why are only the .dtb files needed in the clean list?
>> How are the other built files cleaned? 'make clean' does remove the
>> other images, but I don't know what the mechanism is.
>
>
> A lot of stuff is removed by the top level Makefile [1]. But as the patch
"arm/dt: Add dtb make rule" adds the .dtb generation to
arch/arm/boot/Makefile, we thought it would be a good place to add the
removal of that file there, too.
>
> Hmm, not sure if this answers your question, though ;)
Okay. Good enough for me.
g.
[-- Attachment #1.2: Type: text/html, Size: 2487 bytes --]
[-- Attachment #2: Type: text/plain, Size: 192 bytes --]
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* [xen-unstable test] 9721: regressions - trouble: blocked/broken/fail/pass
From: xen.org @ 2011-11-07 13:41 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 9721 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9721/
Regressions :-(
Tests which did not succeed and are blocking:
test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken
test-i386-i386-xl 18 leak-check/check fail REGR. vs. 9661
test-amd64-i386-xl 18 leak-check/check fail REGR. vs. 9661
test-amd64-i386-xl-credit2 18 leak-check/check fail REGR. vs. 9661
test-amd64-i386-xl-multivcpu 18 leak-check/check fail REGR. vs. 9661
build-amd64-pvops 2 host-install(2) broken
test-amd64-i386-xl-win-vcpus1 3 host-install(3) broken
test-i386-i386-xl-win 3 host-install(3) broken
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a
test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a
test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass
test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a
test-amd64-amd64-win 1 xen-build-check(1) blocked n/a
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a
version targeted for testing:
xen c0702424afc5
baseline version:
xen 54a5e994a241
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Anthony PERARD <anthony.perard@citrix.com>
Christoph Egger <Christoph.Egger@amd.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson.citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
juergen.gross@ts.fujitsu.com
Keir Fraser <keir@xen.org>
Tim Deegan <tim@xen.org>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops broken
build-i386-pvops pass
test-amd64-amd64-xl blocked
test-amd64-i386-xl fail
test-i386-i386-xl fail
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 fail
test-amd64-amd64-xl-pcipt-intel blocked
test-amd64-i386-rhel6hvm-intel broken
test-amd64-i386-xl-multivcpu fail
test-amd64-amd64-pair blocked
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-amd64-pv blocked
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf blocked
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 broken
test-amd64-amd64-win blocked
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win blocked
test-i386-i386-xl-win broken
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
changeset: 24085:c0702424afc5
tag: tip
user: Jan Beulich <jbeulich@suse.com>
date: Mon Nov 07 10:29:14 2011 +0100
cpufreq: allocate CPU masks dynamically
struct cpufreq_policy, including a cpumask_t member, gets copied in
cpufreq_limit_change(), cpufreq_add_cpu(), set_cpufreq_gov(), and
set_cpufreq_para(). Make the member a cpumask_var_t, thus reducing the
amount of data needing copying (particularly with large NR_CPUS).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 24084:721a87728b6b
user: Jan Beulich <jbeulich@suse.com>
date: Mon Nov 07 10:26:23 2011 +0100
powernow: don't read never initialized structure member
c/s 20361:51b031b0737e removed the writing of struct
processor_performance's shared_cpu_map member, but the powernow driver
still has code to read it (though presumably that code path can't be
taken on actual hardware supported by the powernow driver). Remove the
use of the field along with the field itself.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 24083:604a90b803d3
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 15:34:50 2011 +0000
libxl: Remove a passthrough device through QMP.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
---
tools/libxl/libxl_pci.c | 72 +++++++++++++++++++++++++++++++---------------
1 files changed, 48 insertions(+), 24 deletions(-)
changeset: 24082:e22e108e1c57
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 15:34:50 2011 +0000
libxl: libxl_qmp: Introduce libxl__qmp_pci_del
To remove a pci passthough device from QEMU (upstream).
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
---
tools/libxl/libxl_internal.h | 2 ++
tools/libxl/libxl_qmp.c | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 0 deletions(-)
changeset: 24081:659c800d7edf
user: Jan Beulich <jbeulich@suse.com>
date: Fri Nov 04 15:55:50 2011 +0100
x86/IRQ: fix create_irq() after c/s 24068:6928172f7ded
init_one_irq_desc() must be called with interrupts enabled (as it may
call functions from the xmalloc() group). Rather than mis-using
vector_lock to also protect the finding of an unused IRQ, make this
lockless through using cmpxchg(), and obtain the lock only around the
actual assignment of the vector.
Also fold find_unassigned_irq() into its only caller.
It is, btw, questionable whether create_irq() calling
__assign_irq_vector() (rather than assign_irq_vector()) is actually
correct - desc->affinity appears to not get initialized properly in
this case.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 24080:974b00c7c2d0
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 14:24:07 2011 +0000
libxl: Use QMP to insert a passthrough device when using upstream QEMU
Also move the xenstore specific code to a new function and add a
message if sscanf fails.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
changeset: 24079:a67944b1adfb
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 14:24:07 2011 +0000
libxl: libxl_qmp: Introduce libxl__qmp_pci_add.
This function insert a PCI passthrough device in qemu.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
changeset: 24078:c5fe74068253
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 12:38:25 2011 +0000
libxl: libxl_json: Handle number above LONG_MAX.
The integers are now "long long" in the json_object.
If a number (decimal or integer) is too big (or too low), it is stored as it in
a string. So for that, we introduce a new type JSON_NUMBER.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
changeset: 24077:8d06378f1487
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 12:38:25 2011 +0000
libxl: libxl_qmp: Introduce qmp_request_context.
This structure helps to track the return code of a callback. It's only used
between qmp_synchronous_send and qmp_send.
Now, qmp_synchronous_send will return the rc of the callback if there is no
error.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
changeset: 24076:0406f6783c65
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 12:38:24 2011 +0000
libxl: libxl_qmp: Always insert a command id in the callback_list.
Because the function qmp_synchronous_send rely on the presence of the id
in the callback_list.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 24075:918a2091c181
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 12:38:24 2011 +0000
libxl: libxl_qmp: Introduce list of arguments to qmp_send
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 24074:9641b7594ed6
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 12:38:23 2011 +0000
libxl: libxl_qmp: Introduce an opaque argument to the callbacks.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 24073:7b22d2f98302
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 12:38:23 2011 +0000
libxl: libxl: Introduce dm-version xenstore key.
The all key is /libxl/$domid/dm-version.
The /libxl/$domid dir is created with the domain and should be only accessible
by the toolstack domain. The function libxl__xs_libxl_path() give this path.
This come with libxl__device_model_version_running() helper function.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
changeset: 24072:cf8924724b61
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 12:38:22 2011 +0000
libxl: libxl_qmp: Better error message after a parse error.
By setting the next string to parse after having printed any error messages.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
changeset: 24071:bdbd100b28ae
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 12:38:22 2011 +0000
libxl: libxl_json: Check the parser status before to call parse_complete
Also, use goto to handle an error.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
changeset: 24070:e0b6b0e68e90
user: Anthony PERARD <anthony.perard@citrix.com>
date: Fri Nov 04 12:38:22 2011 +0000
libxl: libxl_qmp: Fix return check of fcntl
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
changeset: 24069:801ca6c0fbfa
user: Jan Beulich <jbeulich@suse.com>
date: Thu Nov 03 17:28:41 2011 +0100
x86/IRQ: consolidate IRQ disabling when acquiring vector lock
__assign_irq_vector() doesn't need to disable interrupts (its callers
are required to when acquiring the lock), and set_desc_affinity() can
use the normal spin lock primitives.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
changeset: 24068:6928172f7ded
user: Jan Beulich <jbeulich@suse.com>
date: Thu Nov 03 17:27:38 2011 +0100
IRQ: allocate CPU masks dynamically
This includes delaying the initialization of dynamically created IRQs
until their actual first use and some further elimination of uses of
struct irq_cfg.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
changeset: 24067:17ee4c213438
user: Tim Deegan <tim@xen.org>
date: Thu Nov 03 12:19:23 2011 +0000
xen: provide pse36 cpuid bit
Provide pse36 cpuid bit if guest runs in 32bit PAE
or in long mode. Hyper-V refuses to start as
the "cpu does not provide required hw features"
if it does not find the pse36 cpuid bits.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
changeset: 24066:54a5e994a241
user: Juergen Gross <juergen.gross@ts.fujitsu.com>
date: Wed Nov 02 17:09:09 2011 +0000
docs: Correct man page of xl regarding cpu-pools
Signed-off-by: juergen.gross@ts.fujitsu.com
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Tue Nov 1 18:42:55 2011 +0000
qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
I have just proposed a patch to add this to xen-unstable.hg as
docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
look for docs, plus we are transitioning to upstream qemu.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
^ permalink raw reply
* [U-Boot] Code relocation in U-boot.
From: Sandeep Sharma @ 2011-11-07 13:41 UTC (permalink / raw)
To: u-boot
Hi,
I am analyzing U-Boot code for "relocate_code" function. In this function
after copying the text section and before clearing the bss section we are
doing "fix .rel.dyn relocations". I want to know that what actually we are
doing in this section of code. What does this section actually contains and
what kind of fix we are doing in this. What are relative and absolute fix
that we are doing in this section.
Any kind of help will we highly appreciated.
--
Thanks and Regards,
Sandeep Kumar,
^ permalink raw reply
* RE: [PATCH] BUILD FIX:hwspinlock: do not return any value from void funtion
From: Hiremath, Vaibhav @ 2011-11-07 13:40 UTC (permalink / raw)
To: Igor Grinberg
Cc: linux-omap@vger.kernel.org, tony@atomide.com, ohad@wizery.com
In-Reply-To: <4EB7D80D.2080108@compulab.co.il>
> -----Original Message-----
> From: Igor Grinberg [mailto:grinberg@compulab.co.il]
> Sent: Monday, November 07, 2011 6:37 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; tony@atomide.com; ohad@wizery.com
> Subject: Re: [PATCH] BUILD FIX:hwspinlock: do not return any value from
> void funtion
>
> Hi Vaibhav,
>
> On 11/07/11 14:58, Vaibhav Hiremath wrote:
> > Fixes below compilation error -
> >
> > CC arch/arm/mach-omap2/hwspinlock.o
> > cc1: warnings being treated as errors
> > In file included from arch/arm/mach-omap2/hwspinlock.c:22:0:
> > include/linux/hwspinlock.h: In function '__hwspin_unlock':
> > include/linux/hwspinlock.h:121:2: error: 'return' with a value, in
> function
> > returning void
> > make[1]: *** [arch/arm/mach-omap2/hwspinlock.o] Error 1
> > make: *** [arch/arm/mach-omap2] Error 2
> >
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > ---
> > include/linux/hwspinlock.h | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
> > index 08a2fee..192710a 100644
> > --- a/include/linux/hwspinlock.h
> > +++ b/include/linux/hwspinlock.h
> > @@ -118,7 +118,7 @@ int __hwspin_trylock(struct hwspinlock *hwlock, int
> mode, unsigned long *flags)
> > static inline
> > void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long
> *flags)
> > {
> > - return 0;
> > + return;
>
> Isn't it better to just remove this line?
>
[Hiremath, Vaibhav] Yeup, we can do that... Submitting it again.
Thanks,
Vaibhav
> > }
> >
> > static inline int hwspin_lock_get_id(struct hwspinlock *hwlock)
>
>
> --
> Regards,
> Igor.
^ permalink raw reply
* [Buildroot] Talk at Embedded Linux Conference Europe
From: Jonathan Dumaresq @ 2011-11-07 13:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111107142639.1fa5d4b5@skate>
Hi thomas,
I leave in montreal, Quebec and we have a french student that does his
stages here. You are not alone with this french accent when you speak in
english... Lol !
This videos hare very interesting !!!
Continue your grate works !
Jonathan
buildroot-bounces at busybox.net wrote:
> Le Wed, 2 Nov 2011 10:15:35 +0100,
> Thomas Petazzoni <thomas.petazzoni@free-electrons.com> a ?crit :
>
>> As planned, I gave the talk ? Using Buildroot for real projects ? on
>> Wednesday last week at the Embedded Linux Conference Europe. The room
>> was crowded with 50+ people, a pretty good audience compared to many
>> other technical talks I've seen during the conference.
>
> For those interested in hearing my terrible french accent, the video
> is now available at :
>
> HD format, 408 MB
>
http://free-electrons.com/pub/video/2011/elce/elce-2011-petazzoni-buildroot-
for-real-project.webm
>
> 800x450 format, 156 MB
>
http://free-electrons.com/pub/video/2011/elce/elce-2011-petazzoni-buildroot-
for-real-project-450p.webm
>
> All other videos from ELCE are also available at
> http://free-electrons.com/blog/elce-2011-videos/.
>
> Regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux development,
> consulting, training and support. http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.