* bad tree block start
From: Helmut Hullen @ 2011-10-22 7:05 UTC (permalink / raw)
To: linux-btrfs
Hallo,
my system now shows in "dmesg"
btrfs bad tree block start 0 5064615628800
btrfs bad tree block start 0 5064615632896
btrfs bad tree block start 0 5064615665664
btrfs bad tree block start 0 5064615624704
btrfs bad tree block start 0 5064615628800
btrfs bad tree block start 0 5064615632896
btrfs bad tree block start 0 5064615665664
btrfs bad tree block start 0 5064615624704
Can I repair it? If yes: how?
Kernel 2.6.39.4
btrfs from the "Hugo Mills" tree.
Cluster of 3 Disks, data raid0, metadata raid 1.
Disks: 3* 2TByte, filled with more than 4 TByte.
Viele Gruesse!
Helmut
^ permalink raw reply
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code
From: Albert ARIBAUD @ 2011-10-22 7:05 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110220320.28232.marek.vasut@gmail.com>
Le 22/10/2011 03:20, Marek Vasut a ?crit :
> On Saturday, October 22, 2011 02:41:54 AM Albert ARIBAUD wrote:
>> Le 22/10/2011 02:19, Marek Vasut a ?crit :
>>> On Saturday, October 22, 2011 02:04:52 AM Tom Rini wrote:
>>>> On Fri, Oct 21, 2011 at 4:45 PM, Marek Vasut<marek.vasut@gmail.com> wrote:
>>>>> On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
>>>>>> Le 22/10/2011 00:46, Marek Vasut a ?crit :
>>>>>>> On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
>>>>>>>> Le 22/10/2011 00:00, Marek Vasut a ?crit :
>>>>>>>>> On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
>>>>>>>>>> Hi Marek,
>>>>>>>>>>
>>>>>>>>>> Le 21/10/2011 22:44, Marek Vasut a ?crit :
>>>>>>>>>>> On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
>>>>>>>>>>>> This allows the SPL to avoid compiling in the CPU support code.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Marek Vasut<marek.vasut@gmail.com>
>>>>>>>>>>>> Cc: Stefano Babic<sbabic@denx.de>
>>>>>>>>>>>> Cc: Wolfgang Denk<wd@denx.de>
>>>>>>>>>>>> Cc: Detlev Zundel<dzu@denx.de>
>>>>>>>>>>>> Cc: Scott Wood<scottwood@freescale.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> arch/arm/cpu/arm926ejs/Makefile | 7 +++++++
>>>>>>>>>>>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/arch/arm/cpu/arm926ejs/Makefile
>>>>>>>>>>>> b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644
>>>>>>>>>>>> --- a/arch/arm/cpu/arm926ejs/Makefile
>>>>>>>>>>>> +++ b/arch/arm/cpu/arm926ejs/Makefile
>>>>>>>>>>>> @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
>>>>>>>>>>>>
>>>>>>>>>>>> START = start.o
>>>>>>>>>>>> COBJS = cpu.o
>>>>>>>>>>>>
>>>>>>>>>>>> +ifdef CONFIG_SPL_BUILD
>>>>>>>>>>>> +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE
>>>>>>>>>>>> +START :=
>>>>>>>>>>>> +COBJS :=
>>>>>>>>>>>> +endif
>>>>>>>>>>>> +endif
>>>>>>>>>>>> +
>>>>>>>>>>>>
>>>>>>>>>>>> SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
>>>>>>>>>>>> OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
>>>>>>>>>>>> START := $(addprefix $(obj),$(START))
>>>>>>>>>>>
>>>>>>>>>>> Hi Albert,
>>>>>>>>>>>
>>>>>>>>>>> can we get this applied please?
>>>>>>>>>>
>>>>>>>>>> I still don't understand what this is supposed to do -- why not
>>>>>>>>>> linking this code is required.
>>>>>>>>>>
>>>>>>>>>> Amicalement,
>>>>>>>>>
>>>>>>>>> Hi Albert,
>>>>>>>>>
>>>>>>>>> I use very different start.S in SPL. And I don't need cpu.o at all.
>>>>>>>>
>>>>>>>> That I understand; but is there a /problem/ in linking cpu.o in?
>>>>>>>
>>>>>>> I suppose it'll be optimized out at link time ?
>>>>>>
>>>>>> That indirectly answers my question: what you want to achieve is
>>>>>> removing dead code.
>>>>>
>>>>> The code IS USED in U-Boot, but IS NOT USED in SPL !
>>>>
>>>> Right, but linked and unused code in SPL is (or should be!) thrown
>>>> away, is what's
>>>> trying to be driven home right now. If the file is going to go away,
>>>> and it's compiled
>>>> thrown away at final link of SPL, lets just ignore that it exists for
>>>> a little longer, and
>>>> then it won't.
>>>
>>> My distrust towards compiler abilities to optimize such stuff out tells
>>> me it's better to avoid it even to be compiled in at all.
>>
>> Optimizing unused functions is a rather simple and reliable ability in
>> tolchains. The issue is not really whether the toolchain is able to do
>> the removal (it is); rather, the issue is whether the linker command
>> line will cause the removal (it will IMO as long as -gc-sections is
>> specified).
>>
>> Amicalement,
>
> So what you suggest is to leave cpu.o compiling and drop only start.S ?
Yes -- once you're sure that -gc-sections is there.
> Cheers
Amicalement,
--
Albert.
^ permalink raw reply
* Re: [PATCH 0/7] writeback: avoid touching dirtied_when on blocked inodes
From: Wu Fengguang @ 2011-10-22 7:07 UTC (permalink / raw)
To: Jan Kara
Cc: linux-fsdevel@vger.kernel.org, Dave Chinner, Christoph Hellwig,
Andrew Morton, LKML, Tang, Feng
In-Reply-To: <20111022065926.GA31074@localhost>
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
On Sat, Oct 22, 2011 at 02:59:26PM +0800, Wu Fengguang wrote:
> > In general it looks better we first root case the "decreasing wrote
> > pages by writeback_single_inode() over time" problem before looking
> > into further steps..
>
> The problem shows up in many of the regression cases. For example,
> the thresh=1G/ext4-100dd case with patches 1-4 applied will not only
> see nr_writeback occasionally dropped low (bdi_dirty_state-8:0.png),
> but also see repeated pattern of nr_wrote by writeback_single_inode()
> slowly decreasing to 0 during some period of dozens of seconds
> (writeback_single_inode.png).
Another example is the thresh=1G/xfs-100dd case with patches 1-4 and
Jan's requeue_io_wait-on-I_SYNC patch. The writeback_single_inode.png
graph shows steadily decreasing wrote pages in some period of 400
seconds. It's accompanied by decrease of nr_writeback, IO size and
impacts write bandwidth a lot.
Thanks,
Fengguang
[-- Attachment #2: bdi_dirty_state-8:0.png --]
[-- Type: image/png, Size: 54418 bytes --]
[-- Attachment #3: writeback_single_inode.png --]
[-- Type: image/png, Size: 46406 bytes --]
[-- Attachment #4: iostat-misc.png --]
[-- Type: image/png, Size: 43585 bytes --]
[-- Attachment #5: iostat-bw.png --]
[-- Type: image/png, Size: 65248 bytes --]
^ permalink raw reply
* Re: [PATCH 12/X] uprobes: x86: introduce abort_xol()
From: Ananth N Mavinakayanahalli @ 2011-10-22 7:09 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Srikar Dronamraju, Peter Zijlstra, Ingo Molnar, Steven Rostedt,
Linux-mm, Arnaldo Carvalho de Melo, Linus Torvalds,
Jonathan Corbet, Masami Hiramatsu, Hugh Dickins,
Christoph Hellwig, Thomas Gleixner, Andi Kleen, Andrew Morton,
Jim Keniston, Roland McGrath, LKML
In-Reply-To: <20111021164221.GA30770@redhat.com>
On Fri, Oct 21, 2011 at 06:42:21PM +0200, Oleg Nesterov wrote:
> On 10/21, Ananth N Mavinakayanahalli wrote:
...
> > For instance, on x86, it points to the next
> > instruction,
>
> No?
At exception entry, we'd not have done the following fixup...
> /**
> * get_uprobe_bkpt_addr - compute address of bkpt given post-bkpt regs
> * @regs: Reflects the saved state of the task after it has hit a breakpoint
> * instruction.
> * Return the address of the breakpoint instruction.
> */
> unsigned long __weak get_uprobe_bkpt_addr(struct pt_regs *regs)
> {
> return instruction_pointer(regs) - UPROBES_BKPT_INSN_SIZE;
> }
>
> Yes, initially regs->ip points to the next insn after int3, but
> utask->vaddr == get_uprobe_bkpt_addr() == addr of int3.
>
> Right?
Yes, we fix it up so we point to the right (breakpoint) address.
> > while on powerpc, the nip points to the breakpoint vaddr
> > at the time of exception.
>
> I think get_uprobe_bkpt_addr() should be consistent on every arch.
> That is why (I think) it is __weak.
Yes, that is the intention.
> Anyway, abort_xol() has to be arch-specific.
Agree.
Ananth
--
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 internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 12/X] uprobes: x86: introduce abort_xol()
From: Ananth N Mavinakayanahalli @ 2011-10-22 7:09 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Srikar Dronamraju, Peter Zijlstra, Ingo Molnar, Steven Rostedt,
Linux-mm, Arnaldo Carvalho de Melo, Linus Torvalds,
Jonathan Corbet, Masami Hiramatsu, Hugh Dickins,
Christoph Hellwig, Thomas Gleixner, Andi Kleen, Andrew Morton,
Jim Keniston, Roland McGrath, LKML
In-Reply-To: <20111021164221.GA30770@redhat.com>
On Fri, Oct 21, 2011 at 06:42:21PM +0200, Oleg Nesterov wrote:
> On 10/21, Ananth N Mavinakayanahalli wrote:
...
> > For instance, on x86, it points to the next
> > instruction,
>
> No?
At exception entry, we'd not have done the following fixup...
> /**
> * get_uprobe_bkpt_addr - compute address of bkpt given post-bkpt regs
> * @regs: Reflects the saved state of the task after it has hit a breakpoint
> * instruction.
> * Return the address of the breakpoint instruction.
> */
> unsigned long __weak get_uprobe_bkpt_addr(struct pt_regs *regs)
> {
> return instruction_pointer(regs) - UPROBES_BKPT_INSN_SIZE;
> }
>
> Yes, initially regs->ip points to the next insn after int3, but
> utask->vaddr == get_uprobe_bkpt_addr() == addr of int3.
>
> Right?
Yes, we fix it up so we point to the right (breakpoint) address.
> > while on powerpc, the nip points to the breakpoint vaddr
> > at the time of exception.
>
> I think get_uprobe_bkpt_addr() should be consistent on every arch.
> That is why (I think) it is __weak.
Yes, that is the intention.
> Anyway, abort_xol() has to be arch-specific.
Agree.
Ananth
^ permalink raw reply
* Re: AHCI not working with VT-d enabled
From: Robert Hancock @ 2011-10-22 7:11 UTC (permalink / raw)
To: Tobias Geiger; +Cc: linux-ide, linux-kernel
In-Reply-To: <201110191404.27193.tobias.geiger@vido.info>
On 10/19/2011 06:04 AM, Tobias Geiger wrote:
> Hi,
>
> short description of my problem is:
> with vt-d enabled in bios the sata 6g ports are not recognized;
> when vt-d is disabled the sata6g ports work...
>
> Sata ports are on
> 04:00.0 SATA controller: Marvell Technology Group Ltd. Device 9120 (rev 12)
>
> kernel is 3.1.0-rc8+
> Dmesg with vt-d enabled is here: http://pastebin.com/YLJU8yMJ
>
> Thanks for your input on this!
> Greetings
> Tobias
I think we've had another report about this. This is the error that's
being hit:
[ 1.056549] DRHD: handling fault status reg 2
[ 1.056612] DMAR:[DMA Write] Request device [04:00.1] fault addr fffe0000
[ 1.056614] DMAR:[fault reason 02] Present bit in context entry is clear
Essentially it seems that this Marvell controller can produce PCIe
transactions from the wrong device function (in this case presumably
from the PATA part of the controller on function 1 instead of the AHCI
part on function 0), and the IOMMU is blocking the access since the PATA
function hasn't had any DMA mapping set up.
Not sure what we can do about this.. maybe some kind of PCI quirk for
this device?
^ permalink raw reply
* Re: [DRM] Lower the severity of the radeon lockup messages.
From: Robert Hancock @ 2011-10-22 7:17 UTC (permalink / raw)
To: Dave Jones, airlied, Linux Kernel
In-Reply-To: <20111021165101.GA27960@redhat.com>
On 10/21/2011 10:51 AM, Dave Jones wrote:
> abrt files a lot of bug reports when users get GPU lockups, but there's not really
> enough context to do anything useful with them. Given the lack of GPU context being
> dumped, this patch removes the stack trace, so that abrt ignores the messages.
>
> Signed-off-by: Dave Jones<davej@redhat.com>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c
> index 7fd4e3e..a488b50 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -263,7 +263,7 @@ retry:
> */
> if (seq == rdev->fence_drv.last_seq&& radeon_gpu_is_lockup(rdev)) {
> /* good news we believe it's a lockup */
> - WARN(1, "GPU lockup (waiting for 0x%08X last fence id 0x%08X)\n",
> + printk(KERN_WARNING "GPU lockup (waiting for 0x%08X last fence id 0x%08X)\n",
> fence->seq, seq);
> /* FIXME: what should we do ? marking everyone
> * as signaled for now
At the risk of sounding obvious, wouldn't it be better to enhance the
driver to dump out more useful debugging info in this case rather than
just suppressing the ABRT report?
^ permalink raw reply
* [U-Boot] A bit about board.c, board.c
From: Albert ARIBAUD @ 2011-10-22 7:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ0M=+s5V0xuDp-87ePkvQa+-CSk-Y8GPbqYgX=SKJEo4A@mail.gmail.com>
Le 22/10/2011 07:11, Simon Glass a ?crit :
> Hi,
>
> Each architecture has its own board.c but they are mostly quite similar.
>
> New features such as fdt, boot timing, trace, profiling, etc. must be
> done separately for each arch, even if there are no
> architecture-specific bits.
>
> What would you say to adding something like lib/board.c which is a
> simplified cleaned-up copy of one of the existing board.c files, and a
> CONFIG_ARCH_GENERIC_BOARD option to select that in preference to the
> architecture-specific one. Then perhaps people could try it out and we
> could slowly move to it over time...
I'd say anything that factorizes ARM code is a good thing. :)
However I'm not in favor of a CONFIG option that would force the board
code to provide some functions just in odrer to override one, not if
weak definitions can do a finer job. I am looking into that already for
cache management function specialization, and it seems like there is the
same kind of possibility here, with lib functions defined weak and the
board code overriding the ones it deems necessary to.
I will look into it a bit more this morning.
Amicalement,
--
Albert.
^ permalink raw reply
* [RESEND][PATCH v4 2/3] at91: add parameters for at91_add_device_isi function
From: Josh Wu @ 2011-10-22 7:17 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Josh Wu <josh.wu@atmel.com>
---
fix codeing style
using bool instead of int for boolean type
arch/arm/mach-at91/at91sam9263_devices.c | 13 ++++++++++---
arch/arm/mach-at91/include/mach/board.h | 4 +++-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
index a050f41..29d5c01 100644
--- a/arch/arm/mach-at91/at91sam9263_devices.c
+++ b/arch/arm/mach-at91/at91sam9263_devices.c
@@ -885,7 +885,8 @@ static struct platform_device at91sam9263_isi_device = {
.num_resources = ARRAY_SIZE(isi_resources),
};
-void __init at91_add_device_isi(void)
+void __init at91_add_device_isi(struct isi_platform_data *data,
+ bool use_pck_as_mck)
{
at91_set_A_periph(AT91_PIN_PE0, 0); /* ISI_D0 */
at91_set_A_periph(AT91_PIN_PE1, 0); /* ISI_D1 */
@@ -898,14 +899,20 @@ void __init at91_add_device_isi(void)
at91_set_A_periph(AT91_PIN_PE8, 0); /* ISI_PCK */
at91_set_A_periph(AT91_PIN_PE9, 0); /* ISI_HSYNC */
at91_set_A_periph(AT91_PIN_PE10, 0); /* ISI_VSYNC */
- at91_set_B_periph(AT91_PIN_PE11, 0); /* ISI_MCK (PCK3) */
at91_set_B_periph(AT91_PIN_PE12, 0); /* ISI_PD8 */
at91_set_B_periph(AT91_PIN_PE13, 0); /* ISI_PD9 */
at91_set_B_periph(AT91_PIN_PE14, 0); /* ISI_PD10 */
at91_set_B_periph(AT91_PIN_PE15, 0); /* ISI_PD11 */
+
+ if (use_pck_as_mck) {
+ at91_set_B_periph(AT91_PIN_PE11, 0); /* ISI_MCK (PCK3) */
+
+ /* TODO: register the PCK for ISI_MCK and set its parent */
+ }
}
#else
-void __init at91_add_device_isi(void) {}
+void __init at91_add_device_isi(struct isi_platform_data *data,
+ bool use_pck_as_mck) {}
#endif
diff --git a/arch/arm/mach-at91/include/mach/board.h b/arch/arm/mach-at91/include/mach/board.h
index ed544a0..731c449 100644
--- a/arch/arm/mach-at91/include/mach/board.h
+++ b/arch/arm/mach-at91/include/mach/board.h
@@ -183,7 +183,9 @@ extern void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data);
extern void __init at91_add_device_ac97(struct ac97c_platform_data *data);
/* ISI */
-extern void __init at91_add_device_isi(void);
+struct isi_platform_data;
+extern void __init at91_add_device_isi(struct isi_platform_data *data,
+ bool use_pck_as_mck);
/* Touchscreen Controller */
struct at91_tsadcc_data {
--
1.6.3.3
^ permalink raw reply related
* [RESEND][PATCH v4 3/3] at91: add Atmel ISI and ov2640 support on sam9m10/sam9g45 board
From: Josh Wu @ 2011-10-22 7:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319267860-32367-1-git-send-email-josh.wu@atmel.com>
This patch adds:
- ov2640 sensor in sam9m10/sam9g45 board
- support to use PCK as ISI_MCK. PCK's parent is managed in SoC level, e.g. at91sam9g45_devices.c
Signed-off-by: Josh Wu <josh.wu@atmel.com>
---
fix the coding style
using simpler code
arch/arm/mach-at91/at91sam9g45_devices.c | 94 +++++++++++++++++++++++++++++-
arch/arm/mach-at91/board-sam9m10g45ek.c | 80 +++++++++++++++++++++++++-
2 files changed, 171 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index 600bffb..1474149 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -16,9 +16,10 @@
#include <linux/platform_device.h>
#include <linux/i2c-gpio.h>
#include <linux/atmel-mci.h>
-
+#include <linux/clk.h>
#include <linux/fb.h>
#include <video/atmel_lcdc.h>
+#include <media/atmel-isi.h>
#include <mach/board.h>
#include <mach/gpio.h>
@@ -29,6 +30,7 @@
#include <mach/atmel-mci.h>
#include "generic.h"
+#include "clock.h"
/* --------------------------------------------------------------------
@@ -863,6 +865,96 @@ void __init at91_add_device_ac97(struct ac97c_platform_data *data)
void __init at91_add_device_ac97(struct ac97c_platform_data *data) {}
#endif
+/* --------------------------------------------------------------------
+ * Image Sensor Interface
+ * -------------------------------------------------------------------- */
+#if defined(CONFIG_VIDEO_ATMEL_ISI) || defined(CONFIG_VIDEO_ATMEL_ISI_MODULE)
+static u64 isi_dmamask = DMA_BIT_MASK(32);
+static struct isi_platform_data isi_data;
+
+struct resource isi_resources[] = {
+ [0] = {
+ .start = AT91SAM9G45_BASE_ISI,
+ .end = AT91SAM9G45_BASE_ISI + SZ_16K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = AT91SAM9G45_ID_ISI,
+ .end = AT91SAM9G45_ID_ISI,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device at91sam9g45_isi_device = {
+ .name = "atmel_isi",
+ .id = 0,
+ .dev = {
+ .dma_mask = &isi_dmamask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = &isi_data,
+ },
+ .resource = isi_resources,
+ .num_resources = ARRAY_SIZE(isi_resources),
+};
+
+static struct clk_lookup isi_mck_lookups[] = {
+ CLKDEV_CON_DEV_ID("isi_mck", "atmel_isi.0", NULL),
+};
+
+void __init at91_add_device_isi(struct isi_platform_data *data,
+ bool use_pck_as_mck)
+{
+ struct clk *pck;
+ struct clk *parent;
+
+ if (!data)
+ return;
+ isi_data = *data;
+
+ at91_set_A_periph(AT91_PIN_PB20, 0); /* ISI_D0 */
+ at91_set_A_periph(AT91_PIN_PB21, 0); /* ISI_D1 */
+ at91_set_A_periph(AT91_PIN_PB22, 0); /* ISI_D2 */
+ at91_set_A_periph(AT91_PIN_PB23, 0); /* ISI_D3 */
+ at91_set_A_periph(AT91_PIN_PB24, 0); /* ISI_D4 */
+ at91_set_A_periph(AT91_PIN_PB25, 0); /* ISI_D5 */
+ at91_set_A_periph(AT91_PIN_PB26, 0); /* ISI_D6 */
+ at91_set_A_periph(AT91_PIN_PB27, 0); /* ISI_D7 */
+ at91_set_A_periph(AT91_PIN_PB28, 0); /* ISI_PCK */
+ at91_set_A_periph(AT91_PIN_PB30, 0); /* ISI_HSYNC */
+ at91_set_A_periph(AT91_PIN_PB29, 0); /* ISI_VSYNC */
+ at91_set_B_periph(AT91_PIN_PB8, 0); /* ISI_PD8 */
+ at91_set_B_periph(AT91_PIN_PB9, 0); /* ISI_PD9 */
+ at91_set_B_periph(AT91_PIN_PB10, 0); /* ISI_PD10 */
+ at91_set_B_periph(AT91_PIN_PB11, 0); /* ISI_PD11 */
+
+ platform_device_register(&at91sam9g45_isi_device);
+
+ if (use_pck_as_mck) {
+ at91_set_B_periph(AT91_PIN_PB31, 0); /* ISI_MCK (PCK1) */
+
+ pck = clk_get(NULL, "pck1");
+ parent = clk_get(NULL, "plla");
+
+ BUG_ON(IS_ERR(pck) || IS_ERR(parent));
+
+ if (clk_set_parent(pck, parent)) {
+ pr_err("Failed to set PCK's parent\n");
+ } else {
+ /* Register PCK as ISI_MCK */
+ isi_mck_lookups[0].clk = pck;
+ clkdev_add_table(isi_mck_lookups,
+ ARRAY_SIZE(isi_mck_lookups));
+ }
+
+ clk_put(pck);
+ clk_put(parent);
+ }
+}
+#else
+void __init at91_add_device_isi(struct isi_platform_data *data,
+ bool use_pck_as_mck) {}
+#endif
+
/* --------------------------------------------------------------------
* LCD Controller
diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c b/arch/arm/mach-at91/board-sam9m10g45ek.c
index ad234cc..9082f42 100644
--- a/arch/arm/mach-at91/board-sam9m10g45ek.c
+++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
@@ -23,11 +23,13 @@
#include <linux/gpio_keys.h>
#include <linux/input.h>
#include <linux/leds.h>
-#include <linux/clk.h>
#include <linux/atmel-mci.h>
+#include <linux/delay.h>
#include <mach/hardware.h>
#include <video/atmel_lcdc.h>
+#include <media/soc_camera.h>
+#include <media/atmel-isi.h>
#include <asm/setup.h>
#include <asm/mach-types.h>
@@ -187,6 +189,71 @@ static void __init ek_add_device_nand(void)
/*
+ * ISI
+ */
+static struct isi_platform_data __initdata isi_data = {
+ .frate = ISI_CFG1_FRATE_CAPTURE_ALL,
+ /* to use codec and preview path simultaneously */
+ .full_mode = 1,
+ .data_width_flags = ISI_DATAWIDTH_8 | ISI_DATAWIDTH_10,
+ /* ISI_MCK is provided by programmable clock or external clock */
+ .mck_hz = 25000000,
+};
+
+
+/*
+ * soc-camera OV2640
+ */
+#if defined(CONFIG_SOC_CAMERA_OV2640) || \
+ defined(CONFIG_SOC_CAMERA_OV2640_MODULE)
+static unsigned long isi_camera_query_bus_param(struct soc_camera_link *link)
+{
+ /* ISI board for ek using default 8-bits connection */
+ return SOCAM_DATAWIDTH_8;
+}
+
+static int i2c_camera_power(struct device *dev, int on)
+{
+ /* enable or disable the camera */
+ pr_debug("%s: %s the camera\n", __func__, on ? "ENABLE" : "DISABLE");
+ at91_set_gpio_output(AT91_PIN_PD13, !on);
+
+ if (!on)
+ goto out;
+
+ /* If enabled, give a reset impulse */
+ at91_set_gpio_output(AT91_PIN_PD12, 0);
+ msleep(20);
+ at91_set_gpio_output(AT91_PIN_PD12, 1);
+ msleep(100);
+
+out:
+ return 0;
+}
+
+static struct i2c_board_info i2c_camera = {
+ I2C_BOARD_INFO("ov2640", 0x30),
+};
+
+static struct soc_camera_link iclink_ov2640 = {
+ .bus_id = 0,
+ .board_info = &i2c_camera,
+ .i2c_adapter_id = 0,
+ .power = i2c_camera_power,
+ .query_bus_param = isi_camera_query_bus_param,
+};
+
+static struct platform_device isi_ov2640 = {
+ .name = "soc-camera-pdrv",
+ .id = 0,
+ .dev = {
+ .platform_data = &iclink_ov2640,
+ },
+};
+#endif
+
+
+/*
* LCD Controller
*/
#if defined(CONFIG_FB_ATMEL) || defined(CONFIG_FB_ATMEL_MODULE)
@@ -378,7 +445,12 @@ static struct gpio_led ek_pwm_led[] = {
#endif
};
-
+static struct platform_device *devices[] __initdata = {
+#if defined(CONFIG_SOC_CAMERA_OV2640) || \
+ defined(CONFIG_SOC_CAMERA_OV2640_MODULE)
+ &isi_ov2640,
+#endif
+};
static void __init ek_board_init(void)
{
@@ -400,6 +472,8 @@ static void __init ek_board_init(void)
ek_add_device_nand();
/* I2C */
at91_add_device_i2c(0, NULL, 0);
+ /* ISI, using programmable clock as ISI_MCK */
+ at91_add_device_isi(&isi_data, true);
/* LCD Controller */
at91_add_device_lcdc(&ek_lcdc_data);
/* Touch Screen */
@@ -411,6 +485,8 @@ static void __init ek_board_init(void)
/* LEDs */
at91_gpio_leds(ek_leds, ARRAY_SIZE(ek_leds));
at91_pwm_leds(ek_pwm_led, ARRAY_SIZE(ek_pwm_led));
+ /* Other platform devices */
+ platform_add_devices(devices, ARRAY_SIZE(devices));
}
MACHINE_START(AT91SAM9M10G45EK, "Atmel AT91SAM9M10G45-EK")
--
1.6.3.3
^ permalink raw reply related
* [RESEND][PATCH v4 2/3] at91: add parameters for at91_add_device_isi function
From: Josh Wu @ 2011-10-22 7:17 UTC (permalink / raw)
To: g.liakhovetski, linux-media, plagnioj
Cc: linux-kernel, linux-arm-kernel, nicolas.ferre, s.nawrocki,
Josh Wu
Signed-off-by: Josh Wu <josh.wu@atmel.com>
---
fix codeing style
using bool instead of int for boolean type
arch/arm/mach-at91/at91sam9263_devices.c | 13 ++++++++++---
arch/arm/mach-at91/include/mach/board.h | 4 +++-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
index a050f41..29d5c01 100644
--- a/arch/arm/mach-at91/at91sam9263_devices.c
+++ b/arch/arm/mach-at91/at91sam9263_devices.c
@@ -885,7 +885,8 @@ static struct platform_device at91sam9263_isi_device = {
.num_resources = ARRAY_SIZE(isi_resources),
};
-void __init at91_add_device_isi(void)
+void __init at91_add_device_isi(struct isi_platform_data *data,
+ bool use_pck_as_mck)
{
at91_set_A_periph(AT91_PIN_PE0, 0); /* ISI_D0 */
at91_set_A_periph(AT91_PIN_PE1, 0); /* ISI_D1 */
@@ -898,14 +899,20 @@ void __init at91_add_device_isi(void)
at91_set_A_periph(AT91_PIN_PE8, 0); /* ISI_PCK */
at91_set_A_periph(AT91_PIN_PE9, 0); /* ISI_HSYNC */
at91_set_A_periph(AT91_PIN_PE10, 0); /* ISI_VSYNC */
- at91_set_B_periph(AT91_PIN_PE11, 0); /* ISI_MCK (PCK3) */
at91_set_B_periph(AT91_PIN_PE12, 0); /* ISI_PD8 */
at91_set_B_periph(AT91_PIN_PE13, 0); /* ISI_PD9 */
at91_set_B_periph(AT91_PIN_PE14, 0); /* ISI_PD10 */
at91_set_B_periph(AT91_PIN_PE15, 0); /* ISI_PD11 */
+
+ if (use_pck_as_mck) {
+ at91_set_B_periph(AT91_PIN_PE11, 0); /* ISI_MCK (PCK3) */
+
+ /* TODO: register the PCK for ISI_MCK and set its parent */
+ }
}
#else
-void __init at91_add_device_isi(void) {}
+void __init at91_add_device_isi(struct isi_platform_data *data,
+ bool use_pck_as_mck) {}
#endif
diff --git a/arch/arm/mach-at91/include/mach/board.h b/arch/arm/mach-at91/include/mach/board.h
index ed544a0..731c449 100644
--- a/arch/arm/mach-at91/include/mach/board.h
+++ b/arch/arm/mach-at91/include/mach/board.h
@@ -183,7 +183,9 @@ extern void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data);
extern void __init at91_add_device_ac97(struct ac97c_platform_data *data);
/* ISI */
-extern void __init at91_add_device_isi(void);
+struct isi_platform_data;
+extern void __init at91_add_device_isi(struct isi_platform_data *data,
+ bool use_pck_as_mck);
/* Touchscreen Controller */
struct at91_tsadcc_data {
--
1.6.3.3
^ permalink raw reply related
* [RESEND][PATCH v4 3/3] at91: add Atmel ISI and ov2640 support on sam9m10/sam9g45 board
From: Josh Wu @ 2011-10-22 7:17 UTC (permalink / raw)
To: g.liakhovetski, linux-media, plagnioj
Cc: linux-kernel, linux-arm-kernel, nicolas.ferre, s.nawrocki,
Josh Wu
In-Reply-To: <1319267860-32367-1-git-send-email-josh.wu@atmel.com>
This patch adds:
- ov2640 sensor in sam9m10/sam9g45 board
- support to use PCK as ISI_MCK. PCK's parent is managed in SoC level, e.g. at91sam9g45_devices.c
Signed-off-by: Josh Wu <josh.wu@atmel.com>
---
fix the coding style
using simpler code
arch/arm/mach-at91/at91sam9g45_devices.c | 94 +++++++++++++++++++++++++++++-
arch/arm/mach-at91/board-sam9m10g45ek.c | 80 +++++++++++++++++++++++++-
2 files changed, 171 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index 600bffb..1474149 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -16,9 +16,10 @@
#include <linux/platform_device.h>
#include <linux/i2c-gpio.h>
#include <linux/atmel-mci.h>
-
+#include <linux/clk.h>
#include <linux/fb.h>
#include <video/atmel_lcdc.h>
+#include <media/atmel-isi.h>
#include <mach/board.h>
#include <mach/gpio.h>
@@ -29,6 +30,7 @@
#include <mach/atmel-mci.h>
#include "generic.h"
+#include "clock.h"
/* --------------------------------------------------------------------
@@ -863,6 +865,96 @@ void __init at91_add_device_ac97(struct ac97c_platform_data *data)
void __init at91_add_device_ac97(struct ac97c_platform_data *data) {}
#endif
+/* --------------------------------------------------------------------
+ * Image Sensor Interface
+ * -------------------------------------------------------------------- */
+#if defined(CONFIG_VIDEO_ATMEL_ISI) || defined(CONFIG_VIDEO_ATMEL_ISI_MODULE)
+static u64 isi_dmamask = DMA_BIT_MASK(32);
+static struct isi_platform_data isi_data;
+
+struct resource isi_resources[] = {
+ [0] = {
+ .start = AT91SAM9G45_BASE_ISI,
+ .end = AT91SAM9G45_BASE_ISI + SZ_16K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = AT91SAM9G45_ID_ISI,
+ .end = AT91SAM9G45_ID_ISI,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device at91sam9g45_isi_device = {
+ .name = "atmel_isi",
+ .id = 0,
+ .dev = {
+ .dma_mask = &isi_dmamask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = &isi_data,
+ },
+ .resource = isi_resources,
+ .num_resources = ARRAY_SIZE(isi_resources),
+};
+
+static struct clk_lookup isi_mck_lookups[] = {
+ CLKDEV_CON_DEV_ID("isi_mck", "atmel_isi.0", NULL),
+};
+
+void __init at91_add_device_isi(struct isi_platform_data *data,
+ bool use_pck_as_mck)
+{
+ struct clk *pck;
+ struct clk *parent;
+
+ if (!data)
+ return;
+ isi_data = *data;
+
+ at91_set_A_periph(AT91_PIN_PB20, 0); /* ISI_D0 */
+ at91_set_A_periph(AT91_PIN_PB21, 0); /* ISI_D1 */
+ at91_set_A_periph(AT91_PIN_PB22, 0); /* ISI_D2 */
+ at91_set_A_periph(AT91_PIN_PB23, 0); /* ISI_D3 */
+ at91_set_A_periph(AT91_PIN_PB24, 0); /* ISI_D4 */
+ at91_set_A_periph(AT91_PIN_PB25, 0); /* ISI_D5 */
+ at91_set_A_periph(AT91_PIN_PB26, 0); /* ISI_D6 */
+ at91_set_A_periph(AT91_PIN_PB27, 0); /* ISI_D7 */
+ at91_set_A_periph(AT91_PIN_PB28, 0); /* ISI_PCK */
+ at91_set_A_periph(AT91_PIN_PB30, 0); /* ISI_HSYNC */
+ at91_set_A_periph(AT91_PIN_PB29, 0); /* ISI_VSYNC */
+ at91_set_B_periph(AT91_PIN_PB8, 0); /* ISI_PD8 */
+ at91_set_B_periph(AT91_PIN_PB9, 0); /* ISI_PD9 */
+ at91_set_B_periph(AT91_PIN_PB10, 0); /* ISI_PD10 */
+ at91_set_B_periph(AT91_PIN_PB11, 0); /* ISI_PD11 */
+
+ platform_device_register(&at91sam9g45_isi_device);
+
+ if (use_pck_as_mck) {
+ at91_set_B_periph(AT91_PIN_PB31, 0); /* ISI_MCK (PCK1) */
+
+ pck = clk_get(NULL, "pck1");
+ parent = clk_get(NULL, "plla");
+
+ BUG_ON(IS_ERR(pck) || IS_ERR(parent));
+
+ if (clk_set_parent(pck, parent)) {
+ pr_err("Failed to set PCK's parent\n");
+ } else {
+ /* Register PCK as ISI_MCK */
+ isi_mck_lookups[0].clk = pck;
+ clkdev_add_table(isi_mck_lookups,
+ ARRAY_SIZE(isi_mck_lookups));
+ }
+
+ clk_put(pck);
+ clk_put(parent);
+ }
+}
+#else
+void __init at91_add_device_isi(struct isi_platform_data *data,
+ bool use_pck_as_mck) {}
+#endif
+
/* --------------------------------------------------------------------
* LCD Controller
diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c b/arch/arm/mach-at91/board-sam9m10g45ek.c
index ad234cc..9082f42 100644
--- a/arch/arm/mach-at91/board-sam9m10g45ek.c
+++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
@@ -23,11 +23,13 @@
#include <linux/gpio_keys.h>
#include <linux/input.h>
#include <linux/leds.h>
-#include <linux/clk.h>
#include <linux/atmel-mci.h>
+#include <linux/delay.h>
#include <mach/hardware.h>
#include <video/atmel_lcdc.h>
+#include <media/soc_camera.h>
+#include <media/atmel-isi.h>
#include <asm/setup.h>
#include <asm/mach-types.h>
@@ -187,6 +189,71 @@ static void __init ek_add_device_nand(void)
/*
+ * ISI
+ */
+static struct isi_platform_data __initdata isi_data = {
+ .frate = ISI_CFG1_FRATE_CAPTURE_ALL,
+ /* to use codec and preview path simultaneously */
+ .full_mode = 1,
+ .data_width_flags = ISI_DATAWIDTH_8 | ISI_DATAWIDTH_10,
+ /* ISI_MCK is provided by programmable clock or external clock */
+ .mck_hz = 25000000,
+};
+
+
+/*
+ * soc-camera OV2640
+ */
+#if defined(CONFIG_SOC_CAMERA_OV2640) || \
+ defined(CONFIG_SOC_CAMERA_OV2640_MODULE)
+static unsigned long isi_camera_query_bus_param(struct soc_camera_link *link)
+{
+ /* ISI board for ek using default 8-bits connection */
+ return SOCAM_DATAWIDTH_8;
+}
+
+static int i2c_camera_power(struct device *dev, int on)
+{
+ /* enable or disable the camera */
+ pr_debug("%s: %s the camera\n", __func__, on ? "ENABLE" : "DISABLE");
+ at91_set_gpio_output(AT91_PIN_PD13, !on);
+
+ if (!on)
+ goto out;
+
+ /* If enabled, give a reset impulse */
+ at91_set_gpio_output(AT91_PIN_PD12, 0);
+ msleep(20);
+ at91_set_gpio_output(AT91_PIN_PD12, 1);
+ msleep(100);
+
+out:
+ return 0;
+}
+
+static struct i2c_board_info i2c_camera = {
+ I2C_BOARD_INFO("ov2640", 0x30),
+};
+
+static struct soc_camera_link iclink_ov2640 = {
+ .bus_id = 0,
+ .board_info = &i2c_camera,
+ .i2c_adapter_id = 0,
+ .power = i2c_camera_power,
+ .query_bus_param = isi_camera_query_bus_param,
+};
+
+static struct platform_device isi_ov2640 = {
+ .name = "soc-camera-pdrv",
+ .id = 0,
+ .dev = {
+ .platform_data = &iclink_ov2640,
+ },
+};
+#endif
+
+
+/*
* LCD Controller
*/
#if defined(CONFIG_FB_ATMEL) || defined(CONFIG_FB_ATMEL_MODULE)
@@ -378,7 +445,12 @@ static struct gpio_led ek_pwm_led[] = {
#endif
};
-
+static struct platform_device *devices[] __initdata = {
+#if defined(CONFIG_SOC_CAMERA_OV2640) || \
+ defined(CONFIG_SOC_CAMERA_OV2640_MODULE)
+ &isi_ov2640,
+#endif
+};
static void __init ek_board_init(void)
{
@@ -400,6 +472,8 @@ static void __init ek_board_init(void)
ek_add_device_nand();
/* I2C */
at91_add_device_i2c(0, NULL, 0);
+ /* ISI, using programmable clock as ISI_MCK */
+ at91_add_device_isi(&isi_data, true);
/* LCD Controller */
at91_add_device_lcdc(&ek_lcdc_data);
/* Touch Screen */
@@ -411,6 +485,8 @@ static void __init ek_board_init(void)
/* LEDs */
at91_gpio_leds(ek_leds, ARRAY_SIZE(ek_leds));
at91_pwm_leds(ek_pwm_led, ARRAY_SIZE(ek_pwm_led));
+ /* Other platform devices */
+ platform_add_devices(devices, ARRAY_SIZE(devices));
}
MACHINE_START(AT91SAM9M10G45EK, "Atmel AT91SAM9M10G45-EK")
--
1.6.3.3
^ permalink raw reply related
* Re: [DRM] Lower the severity of the radeon lockup messages.
From: David Airlie @ 2011-10-22 7:19 UTC (permalink / raw)
To: Robert Hancock; +Cc: Dave Jones, airlied, Linux Kernel
In-Reply-To: <4EA26DF9.8040903@gmail.com>
>
> At the risk of sounding obvious, wouldn't it be better to enhance the driver
> to dump out more useful debugging info in this case rather than just
> suppressing the ABRT report?
In theory yes, in practice that is non-trivial. The amount of data you
need to keep track off is in the MBs, it can range from any previous GPU
command stream sent to the GPU, to the contents of any of the vertex
buffers etc.
the problem with GPU lockups is you don't notice them until after you've
queued up a tonne more stuff since they are such deep pipelines.
Dave.
^ permalink raw reply
* Re: [PATCH 13/X] uprobes: introduce UTASK_SSTEP_TRAPPED logic
From: Ananth N Mavinakayanahalli @ 2011-10-22 7:20 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Srikar Dronamraju, Peter Zijlstra, Ingo Molnar, Steven Rostedt,
Linux-mm, Arnaldo Carvalho de Melo, Linus Torvalds,
Jonathan Corbet, Masami Hiramatsu, Hugh Dickins,
Christoph Hellwig, Thomas Gleixner, Andi Kleen, Andrew Morton,
Jim Keniston, Roland McGrath, LKML
In-Reply-To: <20111019215344.GG16395@redhat.com>
On Wed, Oct 19, 2011 at 11:53:44PM +0200, Oleg Nesterov wrote:
> Finally, add UTASK_SSTEP_TRAPPED state/code to handle the case when
> xol insn itself triggers the signal.
>
> In this case we should restart the original insn even if the task is
> already SIGKILL'ed (say, the coredump should report the correct ip).
> This is even more important if the task has a handler for SIGSEGV/etc,
> The _same_ instruction should be repeated again after return from the
> signal handler, and SSTEP can never finish in this case.
Oleg,
Not sure I understand this completely...
When you say 'correct ip' you mean the original vaddr where we now have
a uprobe breakpoint and not the xol copy, right?
Coredump needs to report the correct ip, but should it also not report
correctly the instruction that caused the signal? Ergo, shouldn't we
put the original instruction back at the uprobed vaddr?
Ananth
--
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 internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 13/X] uprobes: introduce UTASK_SSTEP_TRAPPED logic
From: Ananth N Mavinakayanahalli @ 2011-10-22 7:20 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Srikar Dronamraju, Peter Zijlstra, Ingo Molnar, Steven Rostedt,
Linux-mm, Arnaldo Carvalho de Melo, Linus Torvalds,
Jonathan Corbet, Masami Hiramatsu, Hugh Dickins,
Christoph Hellwig, Thomas Gleixner, Andi Kleen, Andrew Morton,
Jim Keniston, Roland McGrath, LKML
In-Reply-To: <20111019215344.GG16395@redhat.com>
On Wed, Oct 19, 2011 at 11:53:44PM +0200, Oleg Nesterov wrote:
> Finally, add UTASK_SSTEP_TRAPPED state/code to handle the case when
> xol insn itself triggers the signal.
>
> In this case we should restart the original insn even if the task is
> already SIGKILL'ed (say, the coredump should report the correct ip).
> This is even more important if the task has a handler for SIGSEGV/etc,
> The _same_ instruction should be repeated again after return from the
> signal handler, and SSTEP can never finish in this case.
Oleg,
Not sure I understand this completely...
When you say 'correct ip' you mean the original vaddr where we now have
a uprobe breakpoint and not the xol copy, right?
Coredump needs to report the correct ip, but should it also not report
correctly the instruction that caused the signal? Ergo, shouldn't we
put the original instruction back at the uprobed vaddr?
Ananth
^ permalink raw reply
* Re: ath9k: irq storm after suspend/resume
From: Clemens Buchacher @ 2011-10-22 7:22 UTC (permalink / raw)
To: Adrian Chadd; +Cc: Mohammed Shafi, linux-wireless, ath9k-devel
In-Reply-To: <CAJ-Vmonu-75rtOyyqP7aWNA5NvQ7XW+0YB-G7N5gF3tS5E0EaA@mail.gmail.com>
Hi,
On Sat, Oct 22, 2011 at 08:47:33AM +0800, Adrian Chadd wrote:
>
> At this point I'd really suggest whacking other devices into the slot
> to see if they generate the same kind of behaviour.
Looks like you had it right from the start. After unloading the jme
module [*1*] I cannot reproduce the IRQ storm any more. From
looking at dmesg it should have been obvious, since it also gets
IRQ 17 assigned. I don't know how I missed that, I was sure I had
checked.
Sorry guys, for most likely wasting your time. And thanks for your
patience.
Best,
Clemens
[*1*]
$ lspci
06:00.5 Ethernet controller: JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller (rev 03))
$ dmesg|grep -i jme
[ 6.160187] jme: JMicron JMC2XX ethernet driver version 1.0.8
[ 6.160278] jme 0000:06:00.5: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 6.160305] jme 0000:06:00.5: setting latency timer to 64
[ 6.161154] jme 0000:06:00.5: eth0: JMC250 Gigabit Ethernet chiprev:23 pcirev:3 macaddr:bc:ae:c5:2f:91:47
[ 18.354697] jme 0000:06:00.5: PCI INT A disabled
^ permalink raw reply
* Re: [PATCH 1/4] Add parsing of L2CAP Create/Move Channel signals
From: Marcel Holtmann @ 2011-10-22 7:21 UTC (permalink / raw)
To: Peter Krystad; +Cc: linux-bluetooth, andrei.emeltchenko
In-Reply-To: <1319239802-22457-2-git-send-email-pkrystad@codeaurora.org>
Hi Peter,
> Add parsing of L2CAP Create/Move Channel signalling.
> Example output:
>
> 2011-10-18 16:09:47.810208 > ACL data: handle 39 flags 0x02 dlen 13
> L2CAP(s): Create req: psm 4097 scid 0x4201 id 17
> 2011-10-18 16:09:47.810269 < ACL data: handle 39 flags 0x00 dlen 16
> L2CAP(s): Create rsp: dcid 0x0040 scid 0x4201 result 1 status 0
> 2011-10-18 16:09:47.898308 < ACL data: handle 39 flags 0x00 dlen 16
> L2CAP(s): Create rsp: dcid 0x0040 scid 0x4201 result 0 status 0
>
> ....
>
> 2011-10-18 14:25:24.646869 > ACL data: handle 39 flags 0x02 dlen 11
> L2CAP(s): Move req: icid 0x4000 id 17
> 2011-10-18 14:25:24.646987 < ACL data: handle 39 flags 0x00 dlen 12
> L2CAP(s): Move rsp: icid 0x4000 result 1
> 2011-10-18 14:25:24.846873 < ACL data: handle 39 flags 0x00 dlen 12
> L2CAP(s): Move rsp: icid 0x4000 result 0
> 2011-10-18 14:25:25.041844 > ACL data: handle 39 flags 0x02 dlen 12
> L2CAP(s): Move cfm: icid 0x4000 result 0
> 2011-10-18 14:25:25.041945 < ACL data: handle 39 flags 0x00 dlen 10
> L2CAP(s): Move cfm rsp: icid 0x4000
> ---
> lib/l2cap.h | 50 +++++++++++++++++++++++++++++
> parser/l2cap.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 147 insertions(+), 0 deletions(-)
same requirement as with Andrei's patches before. First get them
accepted into bluez.git and then we port them over here.
Regards
Marcel
^ permalink raw reply
* [ath9k-devel] ath9k: irq storm after suspend/resume
From: Clemens Buchacher @ 2011-10-22 7:22 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <CAJ-Vmonu-75rtOyyqP7aWNA5NvQ7XW+0YB-G7N5gF3tS5E0EaA@mail.gmail.com>
Hi,
On Sat, Oct 22, 2011 at 08:47:33AM +0800, Adrian Chadd wrote:
>
> At this point I'd really suggest whacking other devices into the slot
> to see if they generate the same kind of behaviour.
Looks like you had it right from the start. After unloading the jme
module [*1*] I cannot reproduce the IRQ storm any more. From
looking at dmesg it should have been obvious, since it also gets
IRQ 17 assigned. I don't know how I missed that, I was sure I had
checked.
Sorry guys, for most likely wasting your time. And thanks for your
patience.
Best,
Clemens
[*1*]
$ lspci
06:00.5 Ethernet controller: JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller (rev 03))
$ dmesg|grep -i jme
[ 6.160187] jme: JMicron JMC2XX ethernet driver version 1.0.8
[ 6.160278] jme 0000:06:00.5: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 6.160305] jme 0000:06:00.5: setting latency timer to 64
[ 6.161154] jme 0000:06:00.5: eth0: JMC250 Gigabit Ethernet chiprev:23 pcirev:3 macaddr:bc:ae:c5:2f:91:47
[ 18.354697] jme 0000:06:00.5: PCI INT A disabled
^ permalink raw reply
* [PATCH] tg3: fix tigon3_dma_hwbug_workaround()
From: Eric Dumazet @ 2011-10-22 7:25 UTC (permalink / raw)
To: Ari Savolainen
Cc: RongQing Li, David Miller, richardcochran, netdev, linux-kernel
In-Reply-To: <1319265470.6180.13.camel@edumazet-laptop>
Ari got kernel panics using tg3 NIC, and bisected to 2669069aacc9 "tg3:
enable transmit time stamping."
This is because tigon3_dma_hwbug_workaround() might alloc a new skb and
free the original. We panic when skb_tx_timestamp() is called on freed
skb.
Reported-by: Ari Savolainen <ari.m.savolainen@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/tg3.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 4a1374d..6149dc5 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6029,12 +6029,12 @@ static void tg3_tx_skb_unmap(struct tg3_napi *tnapi, u32 entry, int last)
/* Workaround 4GB and 40-bit hardware DMA bugs. */
static int tigon3_dma_hwbug_workaround(struct tg3_napi *tnapi,
- struct sk_buff *skb,
+ struct sk_buff **pskb,
u32 *entry, u32 *budget,
u32 base_flags, u32 mss, u32 vlan)
{
struct tg3 *tp = tnapi->tp;
- struct sk_buff *new_skb;
+ struct sk_buff *new_skb, *skb = *pskb;
dma_addr_t new_addr = 0;
int ret = 0;
@@ -6076,7 +6076,7 @@ static int tigon3_dma_hwbug_workaround(struct tg3_napi *tnapi,
}
dev_kfree_skb(skb);
-
+ *pskb = new_skb;
return ret;
}
@@ -6305,7 +6305,7 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
*/
entry = tnapi->tx_prod;
budget = tg3_tx_avail(tnapi);
- if (tigon3_dma_hwbug_workaround(tnapi, skb, &entry, &budget,
+ if (tigon3_dma_hwbug_workaround(tnapi, &skb, &entry, &budget,
base_flags, mss, vlan))
goto out_unlock;
}
^ permalink raw reply related
* Re: [PATCH] ibmvscsis: Initial IBM vSCSI Target merge for v3.2-rc1
From: Nicholas A. Bellinger @ 2011-10-22 7:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: target-devel, linux-scsi, FUJITA Tomonori, Brian King,
James Bottomley
In-Reply-To: <20111018090849.GA22131@lst.de>
On Tue, 2011-10-18 at 11:08 +0200, Christoph Hellwig wrote:
> This needs a patch like the one below folded in. In addition to not
> unessecarily offload new command mapping to the fabric thread this
> also fixes the currenly incorrect (outdated) handling of the return
> values from transport_generic_allocate_tasks. I don't even have
> a ppc compiler at hand right now, so handle it with care.
>
> ---
> From: Christoph Hellwig <hch@lst.de>
> Subject: ibmvscsis: do not offload new command processing to the fabric thread
>
> tcm_queuecommand is always called from process context, so prepare the command
> in-process instead of offloading it.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Hi Christoph,
Fixed some minor compile breakage with this patch. Aside from that, I
think it looks like a reasonably safe conversion to perform the
necessary setup in tcm_queuecommand() process context instead of the
extra context switch into transport_generic_handle_cdb_map().
I've not heard Tomo-san or BR-King feedback on this for a v3.2 merge
yet, but will respin with this change included for them to review again
for next week.
Thanks,
--nab
^ permalink raw reply
* [ath9k-devel] ath9k: irq storm after suspend/resume
From: Adrian Chadd @ 2011-10-22 7:29 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <20111022072215.GA2524@ecki>
On 22 October 2011 15:22, Clemens Buchacher <drizzd@aon.at> wrote:
> Looks like you had it right from the start. After unloading the jme
> module [*1*] I cannot reproduce the IRQ storm any more. From
> looking at dmesg it should have been obvious, since it also gets
> IRQ 17 assigned. I don't know how I missed that, I was sure I had
> checked.
>
> Sorry guys, for most likely wasting your time. And thanks for your
> patience.
Ah, eek! Well, you're welcome! And I hope you/others have a better
understanding of how the interrupt setup on these NICs work.
(I certainly have a better understanding now of the host interface and
what we can poke when it's awake and asleep.)
Good luck!
Adrian
^ permalink raw reply
* Re: ath9k: irq storm after suspend/resume
From: Adrian Chadd @ 2011-10-22 7:29 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Mohammed Shafi, linux-wireless, ath9k-devel
In-Reply-To: <20111022072215.GA2524@ecki>
On 22 October 2011 15:22, Clemens Buchacher <drizzd@aon.at> wrote:
> Looks like you had it right from the start. After unloading the jme
> module [*1*] I cannot reproduce the IRQ storm any more. From
> looking at dmesg it should have been obvious, since it also gets
> IRQ 17 assigned. I don't know how I missed that, I was sure I had
> checked.
>
> Sorry guys, for most likely wasting your time. And thanks for your
> patience.
Ah, eek! Well, you're welcome! And I hope you/others have a better
understanding of how the interrupt setup on these NICs work.
(I certainly have a better understanding now of the host interface and
what we can poke when it's awake and asleep.)
Good luck!
Adrian
^ permalink raw reply
* Re: Page Faults
From: Rakib Mullick @ 2011-10-22 7:30 UTC (permalink / raw)
To: Artur Baruchi; +Cc: linux-kernel
In-Reply-To: <CAAiDW_RfbuWt6C3ixe1gM5FLTJZ7ekpGsaSMgVnt+bSy1mBUBg@mail.gmail.com>
On Sat, Oct 22, 2011 at 8:12 AM, Artur Baruchi <mail.baruchi@gmail.com> wrote:
> Hi Guys.
>
> I would like to create a module (probably unsig kprobe or jproble) to
> separate some kinds of page faults. For example, suppose that during
> 10min my system experienced a total of 100 page faults. This module
> should show me that, 10 page faults happened in cache, 30 page faults
> happened in kernel pages, and so on...
> My question is... which function should I probe to accomplish this?
>
Maybe you're looking for arch/x86/mm/fault.c:do_page_fault(). But,
do_page_fault is tagged with __kprobes, so maybe you can't use this
function with kprobe. You need to find some other solutions. perf
tools has an option for page fault counting, see whether it satisfies
your need. Use 'perf list' to see all the events.
Thanks,
Rakib
^ permalink raw reply
* Re: [PATCH] tg3: fix tigon3_dma_hwbug_workaround()
From: David Miller @ 2011-10-22 7:30 UTC (permalink / raw)
To: eric.dumazet
Cc: ari.m.savolainen, roy.qing.li, richardcochran, netdev,
linux-kernel
In-Reply-To: <1319268338.6180.20.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 22 Oct 2011 09:25:38 +0200
> Ari got kernel panics using tg3 NIC, and bisected to 2669069aacc9 "tg3:
> enable transmit time stamping."
>
> This is because tigon3_dma_hwbug_workaround() might alloc a new skb and
> free the original. We panic when skb_tx_timestamp() is called on freed
> skb.
>
> Reported-by: Ari Savolainen <ari.m.savolainen@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* [PATCH] Makefile: Remove duplicate description of "make RECORDMCOUNT_WARN=1"
From: Jongman Heo @ 2011-10-22 7:32 UTC (permalink / raw)
To: linux-kernel
Remove duplicate "make RECORDMCOUNT_WARN=1" description from "make help" output
Signed-off-by: Jongman Heo <jongman.heo@gmail.com>
---
Makefile | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 2652089..86437a3 100644
--- a/Makefile
+++ b/Makefile
@@ -1290,7 +1290,6 @@ help:
@echo ' make O=dir [targets] Locate all output files in "dir",
including .config'
@echo ' make C=1 [targets] Check all c source with $$CHECK
(sparse by default)'
@echo ' make C=2 [targets] Force check of all c source with $$CHECK'
- @echo ' make RECORDMCOUNT_WARN=1 [targets] Warn about ignored
mcount sections'
@echo ' make W=n [targets] Enable extra gcc checks, n=1,2,3 where'
@echo ' 1: warnings which may be relevant and do not occur too often'
@echo ' 2: warnings which occur quite often but may still be relevant'
--
1.7.6.4
^ 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.