All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai] RaspberryPi kernel 3.8 issue
@ 2014-02-23 21:27 Gregory Dymarek
  2014-02-23 21:37 ` Gilles Chanteperdrix
  2014-02-23 22:37 ` Adam Vaughan
  0 siblings, 2 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-23 21:27 UTC (permalink / raw)
  To: xenomai

Hi,


I compiled a fresh rpi-3.8 kernel using the following patches (from
xenomai-2.6.3):
- ipipe-core-3.8.13-raspberry-pre-2.patch
- ipipe-core-3.8.13-arm-3.patch
- ipipe-core-3.8.13-raspberry-post-2.patch

All compiled well, but when booting this kernel it reports an exception.
The entire boot log is here: http://pastebin.com/K7v44nPw

I am still not very faimiliar with the architecture so I am not really able
to sort it myself...
Any advise please?

[    1.915956] hub 1-0:1.0: 1 port detected
[    1.923672] ------------[ cut here ]------------
[    1.931807] WARNING: at kernel/irq/handle.c:146
handle_irq_event_percpu+0x190/0x1b4()
[    1.943148] irq 32 handler usb_hcd_irq+0x0/0x7c enabled interrupts
[    1.952840] Modules linked in:
[    1.959469] [<c00141ec>] (unwind_backtrace+0x0/0xec) from [<c00204fc>]
(warn_slowpath_common+0x4c/0x64)
[    1.972561] [<c00204fc>] (warn_slowpath_common+0x4c/0x64) from
[<c0020544>] (warn_slowpath_fmt+0x30/0x40)
[    1.985872] [<c0020544>] (warn_slowpath_fmt+0x30/0x40) from [<c0077838>]
(handle_irq_event_percpu+0x190/0x1b4)
[    1.999671] [<c0077838>] (handle_irq_event_percpu+0x190/0x1b4) from
[<c00778c0>] (handle_irq_event+0x64/0x94)
[    2.013394] [<c00778c0>] (handle_irq_event+0x64/0x94) from [<c007a6c4>]
(handle_level_irq+0x78/0x108)
[    2.026432] [<c007a6c4>] (handle_level_irq+0x78/0x108) from [<c0077010>]
(generic_handle_irq+0x1c/0x30)
[    2.039690] [<c0077010>] (generic_handle_irq+0x1c/0x30) from
[<c000eacc>] (handle_IRQ+0x30/0x84)
[    2.052361] [<c000eacc>] (handle_IRQ+0x30/0x84) from [<c008036c>]
(__ipipe_do_sync_stage+0x25c/0x278)
[    2.065548] [<c008036c>] (__ipipe_do_sync_stage+0x25c/0x278) from
[<c00083c4>] (__ipipe_grab_irq+0x2c/0x70)
[    2.079312] [<c00083c4>] (__ipipe_grab_irq+0x2c/0x70) from [<c0422d14>]
(__irq_svc+0x34/0xc0)
[    2.091773] Exception stack(0xcd82de00 to 0xcd82de48)
[    2.100766] de00: f2980008 00000000 00000000 00000000 00000000 00000000
cd99ec00 c05db7c4
[    2.112995] de20: cd9ed380 c05bbfc0 c0523a7c c05db8a4 00000030 cd82de48
c02f947c c02f8e44
[    2.125241] de40: 60000113 ffffffff
[    2.132818] [<c0422d14>] (__irq_svc+0x34/0xc0) from [<c02f8e44>]
(dwc_otg_driver_probe+0x114/0x7e0)
[    2.146103] [<c02f8e44>] (dwc_otg_driver_probe+0x114/0x7e0) from
[<c02aa504>] (really_probe+0x60/0x1e8)
[    2.159771] [<c02aa504>] (really_probe+0x60/0x1e8) from [<c02aa778>]
(__driver_attach+0x98/0x9c)
[    2.172812] [<c02aa778>] (__driver_attach+0x98/0x9c) from [<c02a8b70>]
(bus_for_each_dev+0x60/0x94)
[    2.186145] [<c02a8b70>] (bus_for_each_dev+0x60/0x94) from [<c02a9cb8>]
(bus_add_driver+0xac/0x244)
[    2.199589] [<c02a9cb8>] (bus_add_driver+0xac/0x244) from [<c02aae20>]
(driver_register+0x78/0x140)
[    2.213103] [<c02aae20>] (driver_register+0x78/0x140) from [<c05a0074>]
(dwc_otg_driver_init+0x20/0xe0)
[    2.226973] [<c05a0074>] (dwc_otg_driver_init+0x20/0xe0) from
[<c00086e0>] (do_one_initcall+0x114/0x180)
[    2.241020] [<c00086e0>] (do_one_initcall+0x114/0x180) from [<c058c86c>]
(kernel_init_freeable+0xf8/0x1b8)
[    2.255236] [<c058c86c>] (kernel_init_freeable+0xf8/0x1b8) from
[<c041c210>] (kernel_init+0x8/0x150)
[    2.268963] [<c041c210>] (kernel_init+0x8/0x150) from [<c000dc40>]
(ret_from_fork+0x18/0x38)
[    2.282034] ---[ end trace 6e968ac9df7b1cbe ]---
[    2.291589] dwc_otg: FIQ enabled

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-23 21:27 [Xenomai] RaspberryPi kernel 3.8 issue Gregory Dymarek
@ 2014-02-23 21:37 ` Gilles Chanteperdrix
  2014-02-23 22:18   ` Gregory Dymarek
  2014-02-23 22:37 ` Adam Vaughan
  1 sibling, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-23 21:37 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/23/2014 10:27 PM, Gregory Dymarek wrote:
> Hi,
> 
> 
> I compiled a fresh rpi-3.8 kernel using the following patches (from
> xenomai-2.6.3):
> - ipipe-core-3.8.13-raspberry-pre-2.patch
> - ipipe-core-3.8.13-arm-3.patch
> - ipipe-core-3.8.13-raspberry-post-2.patch
> 
> All compiled well, but when booting this kernel it reports an exception.
> The entire boot log is here: http://pastebin.com/K7v44nPw
> 
> I am still not very faimiliar with the architecture so I am not really able
> to sort it myself...
> Any advise please?



> 
> [    1.915956] hub 1-0:1.0: 1 port detected
> [    1.923672] ------------[ cut here ]------------
> [    1.931807] WARNING: at kernel/irq/handle.c:146
> handle_irq_event_percpu+0x190/0x1b4()

It is not an exception, it is a warning, what is there at
kernel/irq/handle.c:146 in the kernel you are using?


-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-23 21:37 ` Gilles Chanteperdrix
@ 2014-02-23 22:18   ` Gregory Dymarek
  2014-02-23 22:36     ` Gilles Chanteperdrix
  0 siblings, 1 reply; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-23 22:18 UTC (permalink / raw)
  To: xenomai

Thank you for such quick response!

Actually yes, this is a warning. Sorry.

That's the content:
irqreturn_t handle_irq_event_percpu(struct irq_desc *desc, struct irqaction
*action)
...
 if (WARN_ONCE(!irqs_disabled(),"irq %u handler %pF enabled interrupts\n",
irq, action->handler))
      local_irq_disable();


Should the IRQs be 'not disabled' at the first place?

When running unpatched kernel this is not the case.


On 23 February 2014 21:37, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/23/2014 10:27 PM, Gregory Dymarek wrote:
> > Hi,
> >
> >
> > I compiled a fresh rpi-3.8 kernel using the following patches (from
> > xenomai-2.6.3):
> > - ipipe-core-3.8.13-raspberry-pre-2.patch
> > - ipipe-core-3.8.13-arm-3.patch
> > - ipipe-core-3.8.13-raspberry-post-2.patch
> >
> > All compiled well, but when booting this kernel it reports an exception.
> > The entire boot log is here: http://pastebin.com/K7v44nPw
> >
> > I am still not very faimiliar with the architecture so I am not really
> able
> > to sort it myself...
> > Any advise please?
>
>
>
> >
> > [    1.915956] hub 1-0:1.0: 1 port detected
> > [    1.923672] ------------[ cut here ]------------
> > [    1.931807] WARNING: at kernel/irq/handle.c:146
> > handle_irq_event_percpu+0x190/0x1b4()
>
> It is not an exception, it is a warning, what is there at
> kernel/irq/handle.c:146 in the kernel you are using?
>
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-23 22:18   ` Gregory Dymarek
@ 2014-02-23 22:36     ` Gilles Chanteperdrix
  0 siblings, 0 replies; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-23 22:36 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/23/2014 11:18 PM, Gregory Dymarek wrote:
> Thank you for such quick response!
> 
> Actually yes, this is a warning. Sorry.
> 
> That's the content:
> irqreturn_t handle_irq_event_percpu(struct irq_desc *desc, struct irqaction
> *action)
> ...
>  if (WARN_ONCE(!irqs_disabled(),"irq %u handler %pF enabled interrupts\n",
> irq, action->handler))
>       local_irq_disable();
> 
> 
> Should the IRQs be 'not disabled' at the first place?

irqs_disabled() does not really test if irqs are disabled when running
over I-pipe, it tests if the linux domain is "stalled", i.e. if irqs are
disabled, but "virtually".

Anyway, I believe the problem is that handle_IRQ is called, normally a
call to ipipe_do_irq should be inserted, so, the normal interposition of
the I-pipe seems missing.

Could you try to disable stack unwinding to see if we have a different
trace?

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-23 21:27 [Xenomai] RaspberryPi kernel 3.8 issue Gregory Dymarek
  2014-02-23 21:37 ` Gilles Chanteperdrix
@ 2014-02-23 22:37 ` Adam Vaughan
  2014-02-23 23:08   ` Adam Vaughan
  1 sibling, 1 reply; 61+ messages in thread
From: Adam Vaughan @ 2014-02-23 22:37 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

I haven't tried using the official Xenomai Raspberry Pi 3.8.13 patch for a
few months now because I had some issue disabling the USB FIQ and I needed
to run alternate FIQ code.  I can't remember exactly what error I was
seeing, but my stopgap solution was to fall back to 3.5.7 (detailed below).
 I believe the USB FIQ disable issue I was seeing has been fixed in more
recent RPi kernels [1], but I haven't had a chance yet to try out that
patch with the Xenomai RPi 3.8.13 kernel.  It is curious that your 3.8.13
kernel log throws the exception at the same location just after the hub
detection as in [1] and involves the same USB code.  Perhaps they're
related?

If any kernel will work and you need to get up and going now, I had the
most success with the set of 3.5.7 patches at [2] (Google translate does a
good job translating the French, but it can also change acronyms in the
text such as RTDM to TDGR).  I did, however, have occasional 3.5.7 kernel
crashes at ext4 code with two different SD cards which haven't occurred
again since moving to the 3.10.11 Raspian distro (I'm working on frontend
code right now, and it's just easier doing it with vetted binaries).  These
infrequent crashes seemed to be associated with heavy file system accesses,
but it wasn't enough of issue that I needed to find a solution right then.

[1]  https://github.com/raspberrypi/linux/issues/355
[2]
http://www.blaess.fr/christophe/2013/02/15/raspberry-pi-interruptions-gpio-avec-rtdm/


On Sun, Feb 23, 2014 at 4:27 PM, Gregory Dymarek <gregd72002@gmail.com>wrote:

> Hi,
>
>
> I compiled a fresh rpi-3.8 kernel using the following patches (from
> xenomai-2.6.3):
> - ipipe-core-3.8.13-raspberry-pre-2.patch
> - ipipe-core-3.8.13-arm-3.patch
> - ipipe-core-3.8.13-raspberry-post-2.patch
>
> All compiled well, but when booting this kernel it reports an exception.
> The entire boot log is here: http://pastebin.com/K7v44nPw
>
> I am still not very faimiliar with the architecture so I am not really able
> to sort it myself...
> Any advise please?
>
> [    1.915956] hub 1-0:1.0: 1 port detected
> [    1.923672] ------------[ cut here ]------------
> [    1.931807] WARNING: at kernel/irq/handle.c:146
> handle_irq_event_percpu+0x190/0x1b4()
> [    1.943148] irq 32 handler usb_hcd_irq+0x0/0x7c enabled interrupts
> [    1.952840] Modules linked in:
> [    1.959469] [<c00141ec>] (unwind_backtrace+0x0/0xec) from [<c00204fc>]
> (warn_slowpath_common+0x4c/0x64)
> [    1.972561] [<c00204fc>] (warn_slowpath_common+0x4c/0x64) from
> [<c0020544>] (warn_slowpath_fmt+0x30/0x40)
> [    1.985872] [<c0020544>] (warn_slowpath_fmt+0x30/0x40) from [<c0077838>]
> (handle_irq_event_percpu+0x190/0x1b4)
> [    1.999671] [<c0077838>] (handle_irq_event_percpu+0x190/0x1b4) from
> [<c00778c0>] (handle_irq_event+0x64/0x94)
> [    2.013394] [<c00778c0>] (handle_irq_event+0x64/0x94) from [<c007a6c4>]
> (handle_level_irq+0x78/0x108)
> [    2.026432] [<c007a6c4>] (handle_level_irq+0x78/0x108) from [<c0077010>]
> (generic_handle_irq+0x1c/0x30)
> [    2.039690] [<c0077010>] (generic_handle_irq+0x1c/0x30) from
> [<c000eacc>] (handle_IRQ+0x30/0x84)
> [    2.052361] [<c000eacc>] (handle_IRQ+0x30/0x84) from [<c008036c>]
> (__ipipe_do_sync_stage+0x25c/0x278)
> [    2.065548] [<c008036c>] (__ipipe_do_sync_stage+0x25c/0x278) from
> [<c00083c4>] (__ipipe_grab_irq+0x2c/0x70)
> [    2.079312] [<c00083c4>] (__ipipe_grab_irq+0x2c/0x70) from [<c0422d14>]
> (__irq_svc+0x34/0xc0)
> [    2.091773] Exception stack(0xcd82de00 to 0xcd82de48)
> [    2.100766] de00: f2980008 00000000 00000000 00000000 00000000 00000000
> cd99ec00 c05db7c4
> [    2.112995] de20: cd9ed380 c05bbfc0 c0523a7c c05db8a4 00000030 cd82de48
> c02f947c c02f8e44
> [    2.125241] de40: 60000113 ffffffff
> [    2.132818] [<c0422d14>] (__irq_svc+0x34/0xc0) from [<c02f8e44>]
> (dwc_otg_driver_probe+0x114/0x7e0)
> [    2.146103] [<c02f8e44>] (dwc_otg_driver_probe+0x114/0x7e0) from
> [<c02aa504>] (really_probe+0x60/0x1e8)
> [    2.159771] [<c02aa504>] (really_probe+0x60/0x1e8) from [<c02aa778>]
> (__driver_attach+0x98/0x9c)
> [    2.172812] [<c02aa778>] (__driver_attach+0x98/0x9c) from [<c02a8b70>]
> (bus_for_each_dev+0x60/0x94)
> [    2.186145] [<c02a8b70>] (bus_for_each_dev+0x60/0x94) from [<c02a9cb8>]
> (bus_add_driver+0xac/0x244)
> [    2.199589] [<c02a9cb8>] (bus_add_driver+0xac/0x244) from [<c02aae20>]
> (driver_register+0x78/0x140)
> [    2.213103] [<c02aae20>] (driver_register+0x78/0x140) from [<c05a0074>]
> (dwc_otg_driver_init+0x20/0xe0)
> [    2.226973] [<c05a0074>] (dwc_otg_driver_init+0x20/0xe0) from
> [<c00086e0>] (do_one_initcall+0x114/0x180)
> [    2.241020] [<c00086e0>] (do_one_initcall+0x114/0x180) from [<c058c86c>]
> (kernel_init_freeable+0xf8/0x1b8)
> [    2.255236] [<c058c86c>] (kernel_init_freeable+0xf8/0x1b8) from
> [<c041c210>] (kernel_init+0x8/0x150)
> [    2.268963] [<c041c210>] (kernel_init+0x8/0x150) from [<c000dc40>]
> (ret_from_fork+0x18/0x38)
> [    2.282034] ---[ end trace 6e968ac9df7b1cbe ]---
> [    2.291589] dwc_otg: FIQ enabled
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-23 22:37 ` Adam Vaughan
@ 2014-02-23 23:08   ` Adam Vaughan
  2014-02-23 23:30     ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Adam Vaughan @ 2014-02-23 23:08 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

* I also missed that it was a warning.  Sorry about that.


On Sun, Feb 23, 2014 at 5:37 PM, Adam Vaughan <vaughana@umich.edu> wrote:

> I haven't tried using the official Xenomai Raspberry Pi 3.8.13 patch for a
> few months now because I had some issue disabling the USB FIQ and I needed
> to run alternate FIQ code.  I can't remember exactly what error I was
> seeing, but my stopgap solution was to fall back to 3.5.7 (detailed below).
>  I believe the USB FIQ disable issue I was seeing has been fixed in more
> recent RPi kernels [1], but I haven't had a chance yet to try out that
> patch with the Xenomai RPi 3.8.13 kernel.  It is curious that your 3.8.13
> kernel log throws the exception at the same location just after the hub
> detection as in [1] and involves the same USB code.  Perhaps they're
> related?
>
> If any kernel will work and you need to get up and going now, I had the
> most success with the set of 3.5.7 patches at [2] (Google translate does a
> good job translating the French, but it can also change acronyms in the
> text such as RTDM to TDGR).  I did, however, have occasional 3.5.7 kernel
> crashes at ext4 code with two different SD cards which haven't occurred
> again since moving to the 3.10.11 Raspian distro (I'm working on frontend
> code right now, and it's just easier doing it with vetted binaries).  These
> infrequent crashes seemed to be associated with heavy file system accesses,
> but it wasn't enough of issue that I needed to find a solution right then.
>
> [1]  https://github.com/raspberrypi/linux/issues/355
> [2]
> http://www.blaess.fr/christophe/2013/02/15/raspberry-pi-interruptions-gpio-avec-rtdm/
>
>
> On Sun, Feb 23, 2014 at 4:27 PM, Gregory Dymarek <gregd72002@gmail.com>wrote:
>
>> Hi,
>>
>>
>> I compiled a fresh rpi-3.8 kernel using the following patches (from
>> xenomai-2.6.3):
>> - ipipe-core-3.8.13-raspberry-pre-2.patch
>> - ipipe-core-3.8.13-arm-3.patch
>> - ipipe-core-3.8.13-raspberry-post-2.patch
>>
>> All compiled well, but when booting this kernel it reports an exception.
>> The entire boot log is here: http://pastebin.com/K7v44nPw
>>
>> I am still not very faimiliar with the architecture so I am not really
>> able
>> to sort it myself...
>> Any advise please?
>>
>> [    1.915956] hub 1-0:1.0: 1 port detected
>> [    1.923672] ------------[ cut here ]------------
>> [    1.931807] WARNING: at kernel/irq/handle.c:146
>> handle_irq_event_percpu+0x190/0x1b4()
>> [    1.943148] irq 32 handler usb_hcd_irq+0x0/0x7c enabled interrupts
>> [    1.952840] Modules linked in:
>> [    1.959469] [<c00141ec>] (unwind_backtrace+0x0/0xec) from [<c00204fc>]
>> (warn_slowpath_common+0x4c/0x64)
>> [    1.972561] [<c00204fc>] (warn_slowpath_common+0x4c/0x64) from
>> [<c0020544>] (warn_slowpath_fmt+0x30/0x40)
>> [    1.985872] [<c0020544>] (warn_slowpath_fmt+0x30/0x40) from
>> [<c0077838>]
>> (handle_irq_event_percpu+0x190/0x1b4)
>> [    1.999671] [<c0077838>] (handle_irq_event_percpu+0x190/0x1b4) from
>> [<c00778c0>] (handle_irq_event+0x64/0x94)
>> [    2.013394] [<c00778c0>] (handle_irq_event+0x64/0x94) from [<c007a6c4>]
>> (handle_level_irq+0x78/0x108)
>> [    2.026432] [<c007a6c4>] (handle_level_irq+0x78/0x108) from
>> [<c0077010>]
>> (generic_handle_irq+0x1c/0x30)
>> [    2.039690] [<c0077010>] (generic_handle_irq+0x1c/0x30) from
>> [<c000eacc>] (handle_IRQ+0x30/0x84)
>> [    2.052361] [<c000eacc>] (handle_IRQ+0x30/0x84) from [<c008036c>]
>> (__ipipe_do_sync_stage+0x25c/0x278)
>> [    2.065548] [<c008036c>] (__ipipe_do_sync_stage+0x25c/0x278) from
>> [<c00083c4>] (__ipipe_grab_irq+0x2c/0x70)
>> [    2.079312] [<c00083c4>] (__ipipe_grab_irq+0x2c/0x70) from [<c0422d14>]
>> (__irq_svc+0x34/0xc0)
>> [    2.091773] Exception stack(0xcd82de00 to 0xcd82de48)
>> [    2.100766] de00: f2980008 00000000 00000000 00000000 00000000 00000000
>> cd99ec00 c05db7c4
>> [    2.112995] de20: cd9ed380 c05bbfc0 c0523a7c c05db8a4 00000030 cd82de48
>> c02f947c c02f8e44
>> [    2.125241] de40: 60000113 ffffffff
>> [    2.132818] [<c0422d14>] (__irq_svc+0x34/0xc0) from [<c02f8e44>]
>> (dwc_otg_driver_probe+0x114/0x7e0)
>> [    2.146103] [<c02f8e44>] (dwc_otg_driver_probe+0x114/0x7e0) from
>> [<c02aa504>] (really_probe+0x60/0x1e8)
>> [    2.159771] [<c02aa504>] (really_probe+0x60/0x1e8) from [<c02aa778>]
>> (__driver_attach+0x98/0x9c)
>> [    2.172812] [<c02aa778>] (__driver_attach+0x98/0x9c) from [<c02a8b70>]
>> (bus_for_each_dev+0x60/0x94)
>> [    2.186145] [<c02a8b70>] (bus_for_each_dev+0x60/0x94) from [<c02a9cb8>]
>> (bus_add_driver+0xac/0x244)
>> [    2.199589] [<c02a9cb8>] (bus_add_driver+0xac/0x244) from [<c02aae20>]
>> (driver_register+0x78/0x140)
>> [    2.213103] [<c02aae20>] (driver_register+0x78/0x140) from [<c05a0074>]
>> (dwc_otg_driver_init+0x20/0xe0)
>> [    2.226973] [<c05a0074>] (dwc_otg_driver_init+0x20/0xe0) from
>> [<c00086e0>] (do_one_initcall+0x114/0x180)
>> [    2.241020] [<c00086e0>] (do_one_initcall+0x114/0x180) from
>> [<c058c86c>]
>> (kernel_init_freeable+0xf8/0x1b8)
>> [    2.255236] [<c058c86c>] (kernel_init_freeable+0xf8/0x1b8) from
>> [<c041c210>] (kernel_init+0x8/0x150)
>> [    2.268963] [<c041c210>] (kernel_init+0x8/0x150) from [<c000dc40>]
>> (ret_from_fork+0x18/0x38)
>> [    2.282034] ---[ end trace 6e968ac9df7b1cbe ]---
>> [    2.291589] dwc_otg: FIQ enabled
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> http://www.xenomai.org/mailman/listinfo/xenomai
>>
>
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-23 23:08   ` Adam Vaughan
@ 2014-02-23 23:30     ` Gregory Dymarek
  2014-02-23 23:32       ` Gregory Dymarek
                         ` (2 more replies)
  0 siblings, 3 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-23 23:30 UTC (permalink / raw)
  To: xenomai

Gilles,

I will give it a try with stack unwinding disabled and report back.

Why I picked up this warning was because I mostly get kernel panics when
unplugging usb devices:
http://pastebin.com/uAhDGuzm

I thought this is to do with the warning when booting the kernel.




On 23 February 2014 23:08, Adam Vaughan <vaughana@umich.edu> wrote:

> * I also missed that it was a warning.  Sorry about that.
>
>
> On Sun, Feb 23, 2014 at 5:37 PM, Adam Vaughan <vaughana@umich.edu> wrote:
>
>> I haven't tried using the official Xenomai Raspberry Pi 3.8.13 patch for
>> a few months now because I had some issue disabling the USB FIQ and I
>> needed to run alternate FIQ code.  I can't remember exactly what error I
>> was seeing, but my stopgap solution was to fall back to 3.5.7 (detailed
>> below).  I believe the USB FIQ disable issue I was seeing has been fixed in
>> more recent RPi kernels [1], but I haven't had a chance yet to try out that
>> patch with the Xenomai RPi 3.8.13 kernel.  It is curious that your 3.8.13
>> kernel log throws the exception at the same location just after the hub
>> detection as in [1] and involves the same USB code.  Perhaps they're
>> related?
>>
>> If any kernel will work and you need to get up and going now, I had the
>> most success with the set of 3.5.7 patches at [2] (Google translate does a
>> good job translating the French, but it can also change acronyms in the
>> text such as RTDM to TDGR).  I did, however, have occasional 3.5.7 kernel
>> crashes at ext4 code with two different SD cards which haven't occurred
>> again since moving to the 3.10.11 Raspian distro (I'm working on frontend
>> code right now, and it's just easier doing it with vetted binaries).  These
>> infrequent crashes seemed to be associated with heavy file system accesses,
>> but it wasn't enough of issue that I needed to find a solution right then.
>>
>> [1]  https://github.com/raspberrypi/linux/issues/355
>> [2]
>> http://www.blaess.fr/christophe/2013/02/15/raspberry-pi-interruptions-gpio-avec-rtdm/
>>
>>
>> On Sun, Feb 23, 2014 at 4:27 PM, Gregory Dymarek <gregd72002@gmail.com>wrote:
>>
>>> Hi,
>>>
>>>
>>> I compiled a fresh rpi-3.8 kernel using the following patches (from
>>> xenomai-2.6.3):
>>> - ipipe-core-3.8.13-raspberry-pre-2.patch
>>> - ipipe-core-3.8.13-arm-3.patch
>>> - ipipe-core-3.8.13-raspberry-post-2.patch
>>>
>>> All compiled well, but when booting this kernel it reports an exception.
>>> The entire boot log is here: http://pastebin.com/K7v44nPw
>>>
>>> I am still not very faimiliar with the architecture so I am not really
>>> able
>>> to sort it myself...
>>> Any advise please?
>>>
>>> [    1.915956] hub 1-0:1.0: 1 port detected
>>> [    1.923672] ------------[ cut here ]------------
>>> [    1.931807] WARNING: at kernel/irq/handle.c:146
>>> handle_irq_event_percpu+0x190/0x1b4()
>>> [    1.943148] irq 32 handler usb_hcd_irq+0x0/0x7c enabled interrupts
>>> [    1.952840] Modules linked in:
>>> [    1.959469] [<c00141ec>] (unwind_backtrace+0x0/0xec) from [<c00204fc>]
>>> (warn_slowpath_common+0x4c/0x64)
>>> [    1.972561] [<c00204fc>] (warn_slowpath_common+0x4c/0x64) from
>>> [<c0020544>] (warn_slowpath_fmt+0x30/0x40)
>>> [    1.985872] [<c0020544>] (warn_slowpath_fmt+0x30/0x40) from
>>> [<c0077838>]
>>> (handle_irq_event_percpu+0x190/0x1b4)
>>> [    1.999671] [<c0077838>] (handle_irq_event_percpu+0x190/0x1b4) from
>>> [<c00778c0>] (handle_irq_event+0x64/0x94)
>>> [    2.013394] [<c00778c0>] (handle_irq_event+0x64/0x94) from
>>> [<c007a6c4>]
>>> (handle_level_irq+0x78/0x108)
>>> [    2.026432] [<c007a6c4>] (handle_level_irq+0x78/0x108) from
>>> [<c0077010>]
>>> (generic_handle_irq+0x1c/0x30)
>>> [    2.039690] [<c0077010>] (generic_handle_irq+0x1c/0x30) from
>>> [<c000eacc>] (handle_IRQ+0x30/0x84)
>>> [    2.052361] [<c000eacc>] (handle_IRQ+0x30/0x84) from [<c008036c>]
>>> (__ipipe_do_sync_stage+0x25c/0x278)
>>> [    2.065548] [<c008036c>] (__ipipe_do_sync_stage+0x25c/0x278) from
>>> [<c00083c4>] (__ipipe_grab_irq+0x2c/0x70)
>>> [    2.079312] [<c00083c4>] (__ipipe_grab_irq+0x2c/0x70) from
>>> [<c0422d14>]
>>> (__irq_svc+0x34/0xc0)
>>> [    2.091773] Exception stack(0xcd82de00 to 0xcd82de48)
>>> [    2.100766] de00: f2980008 00000000 00000000 00000000 00000000
>>> 00000000
>>> cd99ec00 c05db7c4
>>> [    2.112995] de20: cd9ed380 c05bbfc0 c0523a7c c05db8a4 00000030
>>> cd82de48
>>> c02f947c c02f8e44
>>> [    2.125241] de40: 60000113 ffffffff
>>> [    2.132818] [<c0422d14>] (__irq_svc+0x34/0xc0) from [<c02f8e44>]
>>> (dwc_otg_driver_probe+0x114/0x7e0)
>>> [    2.146103] [<c02f8e44>] (dwc_otg_driver_probe+0x114/0x7e0) from
>>> [<c02aa504>] (really_probe+0x60/0x1e8)
>>> [    2.159771] [<c02aa504>] (really_probe+0x60/0x1e8) from [<c02aa778>]
>>> (__driver_attach+0x98/0x9c)
>>> [    2.172812] [<c02aa778>] (__driver_attach+0x98/0x9c) from [<c02a8b70>]
>>> (bus_for_each_dev+0x60/0x94)
>>> [    2.186145] [<c02a8b70>] (bus_for_each_dev+0x60/0x94) from
>>> [<c02a9cb8>]
>>> (bus_add_driver+0xac/0x244)
>>> [    2.199589] [<c02a9cb8>] (bus_add_driver+0xac/0x244) from [<c02aae20>]
>>> (driver_register+0x78/0x140)
>>> [    2.213103] [<c02aae20>] (driver_register+0x78/0x140) from
>>> [<c05a0074>]
>>> (dwc_otg_driver_init+0x20/0xe0)
>>> [    2.226973] [<c05a0074>] (dwc_otg_driver_init+0x20/0xe0) from
>>> [<c00086e0>] (do_one_initcall+0x114/0x180)
>>> [    2.241020] [<c00086e0>] (do_one_initcall+0x114/0x180) from
>>> [<c058c86c>]
>>> (kernel_init_freeable+0xf8/0x1b8)
>>> [    2.255236] [<c058c86c>] (kernel_init_freeable+0xf8/0x1b8) from
>>> [<c041c210>] (kernel_init+0x8/0x150)
>>> [    2.268963] [<c041c210>] (kernel_init+0x8/0x150) from [<c000dc40>]
>>> (ret_from_fork+0x18/0x38)
>>> [    2.282034] ---[ end trace 6e968ac9df7b1cbe ]---
>>> [    2.291589] dwc_otg: FIQ enabled
>>> _______________________________________________
>>> Xenomai mailing list
>>> Xenomai@xenomai.org
>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>
>>
>>
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-23 23:30     ` Gregory Dymarek
@ 2014-02-23 23:32       ` Gregory Dymarek
  2014-02-23 23:42       ` Gilles Chanteperdrix
  2014-02-24  0:22       ` Paul
  2 siblings, 0 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-23 23:32 UTC (permalink / raw)
  To: xenomai

PS. ignore the 'disable stack unwinding' at the beginning of the listing.
It's just copy&paste mistake.


On 23 February 2014 23:30, Gregory Dymarek <gregd72002@gmail.com> wrote:

> Gilles,
>
> I will give it a try with stack unwinding disabled and report back.
>
> Why I picked up this warning was because I mostly get kernel panics when
> unplugging usb devices:
> http://pastebin.com/uAhDGuzm
>
> I thought this is to do with the warning when booting the kernel.
>
>
>
>
> On 23 February 2014 23:08, Adam Vaughan <vaughana@umich.edu> wrote:
>
>> * I also missed that it was a warning.  Sorry about that.
>>
>>
>> On Sun, Feb 23, 2014 at 5:37 PM, Adam Vaughan <vaughana@umich.edu> wrote:
>>
>>> I haven't tried using the official Xenomai Raspberry Pi 3.8.13 patch for
>>> a few months now because I had some issue disabling the USB FIQ and I
>>> needed to run alternate FIQ code.  I can't remember exactly what error I
>>> was seeing, but my stopgap solution was to fall back to 3.5.7 (detailed
>>> below).  I believe the USB FIQ disable issue I was seeing has been fixed in
>>> more recent RPi kernels [1], but I haven't had a chance yet to try out that
>>> patch with the Xenomai RPi 3.8.13 kernel.  It is curious that your 3.8.13
>>> kernel log throws the exception at the same location just after the hub
>>> detection as in [1] and involves the same USB code.  Perhaps they're
>>> related?
>>>
>>> If any kernel will work and you need to get up and going now, I had the
>>> most success with the set of 3.5.7 patches at [2] (Google translate does a
>>> good job translating the French, but it can also change acronyms in the
>>> text such as RTDM to TDGR).  I did, however, have occasional 3.5.7 kernel
>>> crashes at ext4 code with two different SD cards which haven't occurred
>>> again since moving to the 3.10.11 Raspian distro (I'm working on frontend
>>> code right now, and it's just easier doing it with vetted binaries).  These
>>> infrequent crashes seemed to be associated with heavy file system accesses,
>>> but it wasn't enough of issue that I needed to find a solution right then.
>>>
>>> [1]  https://github.com/raspberrypi/linux/issues/355
>>> [2]
>>> http://www.blaess.fr/christophe/2013/02/15/raspberry-pi-interruptions-gpio-avec-rtdm/
>>>
>>>
>>> On Sun, Feb 23, 2014 at 4:27 PM, Gregory Dymarek <gregd72002@gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> I compiled a fresh rpi-3.8 kernel using the following patches (from
>>>> xenomai-2.6.3):
>>>> - ipipe-core-3.8.13-raspberry-pre-2.patch
>>>> - ipipe-core-3.8.13-arm-3.patch
>>>> - ipipe-core-3.8.13-raspberry-post-2.patch
>>>>
>>>> All compiled well, but when booting this kernel it reports an exception.
>>>> The entire boot log is here: http://pastebin.com/K7v44nPw
>>>>
>>>> I am still not very faimiliar with the architecture so I am not really
>>>> able
>>>> to sort it myself...
>>>> Any advise please?
>>>>
>>>> [    1.915956] hub 1-0:1.0: 1 port detected
>>>> [    1.923672] ------------[ cut here ]------------
>>>> [    1.931807] WARNING: at kernel/irq/handle.c:146
>>>> handle_irq_event_percpu+0x190/0x1b4()
>>>> [    1.943148] irq 32 handler usb_hcd_irq+0x0/0x7c enabled interrupts
>>>> [    1.952840] Modules linked in:
>>>> [    1.959469] [<c00141ec>] (unwind_backtrace+0x0/0xec) from
>>>> [<c00204fc>]
>>>> (warn_slowpath_common+0x4c/0x64)
>>>> [    1.972561] [<c00204fc>] (warn_slowpath_common+0x4c/0x64) from
>>>> [<c0020544>] (warn_slowpath_fmt+0x30/0x40)
>>>> [    1.985872] [<c0020544>] (warn_slowpath_fmt+0x30/0x40) from
>>>> [<c0077838>]
>>>> (handle_irq_event_percpu+0x190/0x1b4)
>>>> [    1.999671] [<c0077838>] (handle_irq_event_percpu+0x190/0x1b4) from
>>>> [<c00778c0>] (handle_irq_event+0x64/0x94)
>>>> [    2.013394] [<c00778c0>] (handle_irq_event+0x64/0x94) from
>>>> [<c007a6c4>]
>>>> (handle_level_irq+0x78/0x108)
>>>> [    2.026432] [<c007a6c4>] (handle_level_irq+0x78/0x108) from
>>>> [<c0077010>]
>>>> (generic_handle_irq+0x1c/0x30)
>>>> [    2.039690] [<c0077010>] (generic_handle_irq+0x1c/0x30) from
>>>> [<c000eacc>] (handle_IRQ+0x30/0x84)
>>>> [    2.052361] [<c000eacc>] (handle_IRQ+0x30/0x84) from [<c008036c>]
>>>> (__ipipe_do_sync_stage+0x25c/0x278)
>>>> [    2.065548] [<c008036c>] (__ipipe_do_sync_stage+0x25c/0x278) from
>>>> [<c00083c4>] (__ipipe_grab_irq+0x2c/0x70)
>>>> [    2.079312] [<c00083c4>] (__ipipe_grab_irq+0x2c/0x70) from
>>>> [<c0422d14>]
>>>> (__irq_svc+0x34/0xc0)
>>>> [    2.091773] Exception stack(0xcd82de00 to 0xcd82de48)
>>>> [    2.100766] de00: f2980008 00000000 00000000 00000000 00000000
>>>> 00000000
>>>> cd99ec00 c05db7c4
>>>> [    2.112995] de20: cd9ed380 c05bbfc0 c0523a7c c05db8a4 00000030
>>>> cd82de48
>>>> c02f947c c02f8e44
>>>> [    2.125241] de40: 60000113 ffffffff
>>>> [    2.132818] [<c0422d14>] (__irq_svc+0x34/0xc0) from [<c02f8e44>]
>>>> (dwc_otg_driver_probe+0x114/0x7e0)
>>>> [    2.146103] [<c02f8e44>] (dwc_otg_driver_probe+0x114/0x7e0) from
>>>> [<c02aa504>] (really_probe+0x60/0x1e8)
>>>> [    2.159771] [<c02aa504>] (really_probe+0x60/0x1e8) from [<c02aa778>]
>>>> (__driver_attach+0x98/0x9c)
>>>> [    2.172812] [<c02aa778>] (__driver_attach+0x98/0x9c) from
>>>> [<c02a8b70>]
>>>> (bus_for_each_dev+0x60/0x94)
>>>> [    2.186145] [<c02a8b70>] (bus_for_each_dev+0x60/0x94) from
>>>> [<c02a9cb8>]
>>>> (bus_add_driver+0xac/0x244)
>>>> [    2.199589] [<c02a9cb8>] (bus_add_driver+0xac/0x244) from
>>>> [<c02aae20>]
>>>> (driver_register+0x78/0x140)
>>>> [    2.213103] [<c02aae20>] (driver_register+0x78/0x140) from
>>>> [<c05a0074>]
>>>> (dwc_otg_driver_init+0x20/0xe0)
>>>> [    2.226973] [<c05a0074>] (dwc_otg_driver_init+0x20/0xe0) from
>>>> [<c00086e0>] (do_one_initcall+0x114/0x180)
>>>> [    2.241020] [<c00086e0>] (do_one_initcall+0x114/0x180) from
>>>> [<c058c86c>]
>>>> (kernel_init_freeable+0xf8/0x1b8)
>>>> [    2.255236] [<c058c86c>] (kernel_init_freeable+0xf8/0x1b8) from
>>>> [<c041c210>] (kernel_init+0x8/0x150)
>>>> [    2.268963] [<c041c210>] (kernel_init+0x8/0x150) from [<c000dc40>]
>>>> (ret_from_fork+0x18/0x38)
>>>> [    2.282034] ---[ end trace 6e968ac9df7b1cbe ]---
>>>> [    2.291589] dwc_otg: FIQ enabled
>>>> _______________________________________________
>>>> Xenomai mailing list
>>>> Xenomai@xenomai.org
>>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>>
>>>
>>>
>>
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-23 23:30     ` Gregory Dymarek
  2014-02-23 23:32       ` Gregory Dymarek
@ 2014-02-23 23:42       ` Gilles Chanteperdrix
  2014-02-24 21:19         ` Gregory Dymarek
  2014-02-24  0:22       ` Paul
  2 siblings, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-23 23:42 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/24/2014 12:30 AM, Gregory Dymarek wrote:
> Gilles,
> 
> I will give it a try with stack unwinding disabled and report back.
> 
> Why I picked up this warning was because I mostly get kernel panics when
> unplugging usb devices:
> http://pastebin.com/uAhDGuzm
> 
> I thought this is to do with the warning when booting the kernel.

It is very much likely from the stack trace that the problem is due to
the root domain not being stalled during the execution of the USB
handler: we see two USB interrupts piled up, which obviously could not
happen if interrupts were disabled.


-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-23 23:30     ` Gregory Dymarek
  2014-02-23 23:32       ` Gregory Dymarek
  2014-02-23 23:42       ` Gilles Chanteperdrix
@ 2014-02-24  0:22       ` Paul
  2014-02-24  0:47         ` Adam Vaughan
  2 siblings, 1 reply; 61+ messages in thread
From: Paul @ 2014-02-24  0:22 UTC (permalink / raw)
  To: xenomai

On Sunday 23 February 2014, Gregory Dymarek wrote:
> I will give it a try with stack unwinding disabled and report back.
>
> Why I picked up this warning was because I mostly get kernel panics
> when unplugging usb devices:
> http://pastebin.com/uAhDGuzm
>
> I thought this is to do with the warning when booting the kernel.

Can you please try booting the kernel with dwc_otg.fiq_fix_enable=1 and 
then compare it to booting with dwc_otg.fiq_fix_enable=0

This boot option, along with all others, is set in cmdline.txt


It has been a while since I looked at the RPi kernel, but will help 
where I can.


Regards, Paul.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-24  0:22       ` Paul
@ 2014-02-24  0:47         ` Adam Vaughan
  2014-02-24  0:53           ` Adam Vaughan
  0 siblings, 1 reply; 61+ messages in thread
From: Adam Vaughan @ 2014-02-24  0:47 UTC (permalink / raw)
  To: xenomai

It's a separate issue, but I just rebuilt a Xenomai RPi 3.8.13 kernel with
the patch at [1], and it now boots with the USB FIQ disabled.  It has been
a while, but I'm pretty sure it wasn't booting with FIQ disabled before, as
detailed in [1].  I am able to run my FIQ code after retargeting the module
for the more recent kernel (my stopgap solution was to use 3.5.7).

Gilles, can you include KrfVan's patch at [1] with any modifications you
make to the official Xenomai RPi patches to address the issue Gregory
pointed out?  Also, for what its worth, I also see the same issue Gregory
sees in the kernel logs:

...
[    1.167969] hub 1-0:1.0: 1 port detected
[    1.171818] ------------[ cut here ]------------
[    1.175376] WARNING: at kernel/irq/handle.c:146
handle_irq_event_percpu+0x198/0x1c0()
[    1.179042] irq 75 handler usb_hcd_irq+0x0/0x84 enabled interrupts
...

[1]  https://github.com/raspberrypi/linux/issues/355

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-24  0:47         ` Adam Vaughan
@ 2014-02-24  0:53           ` Adam Vaughan
  2014-02-24  1:20             ` Adam Vaughan
  0 siblings, 1 reply; 61+ messages in thread
From: Adam Vaughan @ 2014-02-24  0:53 UTC (permalink / raw)
  To: xenomai

Regarding Paul's question, it doesn't matter if the dwc_otg.fiq_fix_enable=1
or 0.  The same issue is still there.


On Sun, Feb 23, 2014 at 7:47 PM, Adam Vaughan <vaughana@umich.edu> wrote:

> It's a separate issue, but I just rebuilt a Xenomai RPi 3.8.13 kernel with
> the patch at [1], and it now boots with the USB FIQ disabled.  It has been
> a while, but I'm pretty sure it wasn't booting with FIQ disabled before, as
> detailed in [1].  I am able to run my FIQ code after retargeting the module
> for the more recent kernel (my stopgap solution was to use 3.5.7).
>
> Gilles, can you include KrfVan's patch at [1] with any modifications you
> make to the official Xenomai RPi patches to address the issue Gregory
> pointed out?  Also, for what its worth, I also see the same issue Gregory
> sees in the kernel logs:
>
> ...
> [    1.167969] hub 1-0:1.0: 1 port detected
> [    1.171818] ------------[ cut here ]------------
> [    1.175376] WARNING: at kernel/irq/handle.c:146
> handle_irq_event_percpu+0x198/0x1c0()
> [    1.179042] irq 75 handler usb_hcd_irq+0x0/0x84 enabled interrupts
> ...
>
> [1]  https://github.com/raspberrypi/linux/issues/355
>
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-24  0:53           ` Adam Vaughan
@ 2014-02-24  1:20             ` Adam Vaughan
  0 siblings, 0 replies; 61+ messages in thread
From: Adam Vaughan @ 2014-02-24  1:20 UTC (permalink / raw)
  To: xenomai

I just recompiled 3.8.13 without the patch at [1], and my memory was
apparently correct.  The system stalls as shown in [1] with
dwc_otg.fiq_fix_enable=0
without the patch.

[1]  https://github.com/raspberrypi/linux/issues/355


On Sun, Feb 23, 2014 at 7:53 PM, Adam Vaughan <vaughana@umich.edu> wrote:

> Regarding Paul's question, it doesn't matter if the dwc_otg.fiq_fix_enable=1
> or 0.  The same issue is still there.
>
>
> On Sun, Feb 23, 2014 at 7:47 PM, Adam Vaughan <vaughana@umich.edu> wrote:
>
>> It's a separate issue, but I just rebuilt a Xenomai RPi 3.8.13 kernel
>> with the patch at [1], and it now boots with the USB FIQ disabled.  It has
>> been a while, but I'm pretty sure it wasn't booting with FIQ disabled
>> before, as detailed in [1].  I am able to run my FIQ code after retargeting
>> the module for the more recent kernel (my stopgap solution was to use
>> 3.5.7).
>>
>> Gilles, can you include KrfVan's patch at [1] with any modifications you
>> make to the official Xenomai RPi patches to address the issue Gregory
>> pointed out?  Also, for what its worth, I also see the same issue Gregory
>> sees in the kernel logs:
>>
>> ...
>> [    1.167969] hub 1-0:1.0: 1 port detected
>> [    1.171818] ------------[ cut here ]------------
>> [    1.175376] WARNING: at kernel/irq/handle.c:146
>> handle_irq_event_percpu+0x198/0x1c0()
>> [    1.179042] irq 75 handler usb_hcd_irq+0x0/0x84 enabled interrupts
>> ...
>>
>> [1]  https://github.com/raspberrypi/linux/issues/355
>>
>>
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-23 23:42       ` Gilles Chanteperdrix
@ 2014-02-24 21:19         ` Gregory Dymarek
  2014-02-24 22:00           ` Gilles Chanteperdrix
  0 siblings, 1 reply; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-24 21:19 UTC (permalink / raw)
  To: xenomai

Hi Gilles,

I compiled the kernel width the stack unwind disabled and it throws the
same warning while booting: http://pastebin.com/mSTnPACr
[    1.948056] WARNING: at kernel/irq/handle.c:146
handle_irq_event_percpu+0x198/0x1c0(
[    1.959568] irq 32 handler usb_hcd_irq+0x0/0x84 enabled interrupts

Also, when unlpugging USB devices I get kernel panics:
http://pastebin.com/Nr87y8Ki

What else would you need to see to identify the actual failure?
How should be the root domain stalled, how to look for it?


Thanks,
Gregory


On 23 February 2014 23:42, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/24/2014 12:30 AM, Gregory Dymarek wrote:
> > Gilles,
> >
> > I will give it a try with stack unwinding disabled and report back.
> >
> > Why I picked up this warning was because I mostly get kernel panics when
> > unplugging usb devices:
> > http://pastebin.com/uAhDGuzm
> >
> > I thought this is to do with the warning when booting the kernel.
>
> It is very much likely from the stack trace that the problem is due to
> the root domain not being stalled during the execution of the USB
> handler: we see two USB interrupts piled up, which obviously could not
> happen if interrupts were disabled.
>
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-24 21:19         ` Gregory Dymarek
@ 2014-02-24 22:00           ` Gilles Chanteperdrix
  2014-02-25 20:04             ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-24 22:00 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/24/2014 10:19 PM, Gregory Dymarek wrote:
> Hi Gilles,
> 
> I compiled the kernel width the stack unwind disabled and it throws the
> same warning while booting: http://pastebin.com/mSTnPACr
> [    1.948056] WARNING: at kernel/irq/handle.c:146
> handle_irq_event_percpu+0x198/0x1c0(
> [    1.959568] irq 32 handler usb_hcd_irq+0x0/0x84 enabled interrupts
> 
> Also, when unlpugging USB devices I get kernel panics:
> http://pastebin.com/Nr87y8Ki

Yes, but we now have a clear trace, where we see that ipipe_do_irq is
indeed called.

> 
> What else would you need to see to identify the actual failure?
> How should be the root domain stalled, how to look for it?

The simplest solution is to enable the I-pipe tracer, and trigger a
trace freeze instead of the warning.

The I-pipe tracer should show us where the root domain is unstalled.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-24 22:00           ` Gilles Chanteperdrix
@ 2014-02-25 20:04             ` Gregory Dymarek
  2014-02-25 20:20               ` Gilles Chanteperdrix
  0 siblings, 1 reply; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-25 20:04 UTC (permalink / raw)
  To: xenomai

Thanks Gilles,

Do you mean to execute ipipe_trace_freeze instead of the warning and
kernel/irq/handle.c:146
?

I've recompiled the kernel with the following code in handle.c:146
 13 irqreturn_t

 12 handle_irq_event_percpu(struct irq_desc *desc, struct irqaction
*action)
 11 {

 10     irqreturn_t retval = IRQ_NONE;

  9     unsigned int flags = 0, irq = desc->irq_data.irq;

  8

  7     do {

  6         irqreturn_t res;

  5

  4         trace_irq_handler_entry(irq, action);

  3         res = action->handler(irq, action->dev_id);

  2         trace_irq_handler_exit(irq, action, res);

  1

145         if (!irqs_disabled()) ipipe_trace_freeze(1);

  1

  2         if (WARN_ONCE(!irqs_disabled(),"irq %u handler %pF enabled
interrupts\n",
  3                   irq, action->handler))

  4             local_irq_disable();


But this does not trigger trace freeze.
What is the 'unsigned int v' in the definition of ipipe_trace_freeze?


On 24 February 2014 22:00, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/24/2014 10:19 PM, Gregory Dymarek wrote:
> > Hi Gilles,
> >
> > I compiled the kernel width the stack unwind disabled and it throws the
> > same warning while booting: http://pastebin.com/mSTnPACr
> > [    1.948056] WARNING: at kernel/irq/handle.c:146
> > handle_irq_event_percpu+0x198/0x1c0(
> > [    1.959568] irq 32 handler usb_hcd_irq+0x0/0x84 enabled interrupts
> >
> > Also, when unlpugging USB devices I get kernel panics:
> > http://pastebin.com/Nr87y8Ki
>
> Yes, but we now have a clear trace, where we see that ipipe_do_irq is
> indeed called.
>
> >
> > What else would you need to see to identify the actual failure?
> > How should be the root domain stalled, how to look for it?
>
> The simplest solution is to enable the I-pipe tracer, and trigger a
> trace freeze instead of the warning.
>
> The I-pipe tracer should show us where the root domain is unstalled.
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 20:04             ` Gregory Dymarek
@ 2014-02-25 20:20               ` Gilles Chanteperdrix
  2014-02-25 20:23                 ` Gregory Dymarek
       [not found]                 ` <CAEbDrgkJCnbWu_J4svoXOU1x2rz=n95A5+3Ee=R_9CpMgx-JmA@mail.gmail.com>
  0 siblings, 2 replies; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-25 20:20 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/25/2014 09:04 PM, Gregory Dymarek wrote:
> Thanks Gilles,
> 
> Do you mean to execute ipipe_trace_freeze instead of the warning and
> kernel/irq/handle.c:146
> ?

Yes.

> 
> I've recompiled the kernel with the following code in handle.c:146
>  13 irqreturn_t
> 
>  12 handle_irq_event_percpu(struct irq_desc *desc, struct irqaction
> *action)
>  11 {
> 
>  10     irqreturn_t retval = IRQ_NONE;
> 
>   9     unsigned int flags = 0, irq = desc->irq_data.irq;
> 
>   8
> 
>   7     do {
> 
>   6         irqreturn_t res;
> 
>   5
> 
>   4         trace_irq_handler_entry(irq, action);
> 
>   3         res = action->handler(irq, action->dev_id);
> 
>   2         trace_irq_handler_exit(irq, action, res);
> 
>   1
> 
> 145         if (!irqs_disabled()) ipipe_trace_freeze(1);
> 
>   1
> 
>   2         if (WARN_ONCE(!irqs_disabled(),"irq %u handler %pF enabled
> interrupts\n",
>   3                   irq, action->handler))
> 
>   4             local_irq_disable();
> 
> 
> But this does not trigger trace freeze.

the tracer should be compiled-in and started, see:
http://www.xenomai.org/index.php/Xenomai:I-pipe_Tracer#API


> What is the 'unsigned int v' in the definition of ipipe_trace_freeze?

It is a value you will find back in the trace.


-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 20:20               ` Gilles Chanteperdrix
@ 2014-02-25 20:23                 ` Gregory Dymarek
       [not found]                 ` <CAEbDrgkJCnbWu_J4svoXOU1x2rz=n95A5+3Ee=R_9CpMgx-JmA@mail.gmail.com>
  1 sibling, 0 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-25 20:23 UTC (permalink / raw)
  To: xenomai

I should have added more context.

I'm sure I recompiled the kernel correctly with CONFIG_IPIPE_TRACE
Because, when I unplug my USB device i get the ipipe trace now instead of
default kernel panic.

   CONFIG_IPIPE_DEBUG=y

   CONFIG_IPIPE_DEBUG_CONTEXT=y

   CONFIG_IPIPE_DEBUG_INTERNAL=y

   CONFIG_IPIPE_TRACE=y

   CONFIG_IPIPE_TRACE_ENABLE=y

   CONFIG_IPIPE_TRACE_MCOUNT=y

   CONFIG_IPIPE_TRACE_IRQSOFF=y

   CONFIG_IPIPE_TRACE_SHIFT=14

   CONFIG_IPIPE_TRACE_VMALLOC=y

   CONFIG_IPIPE_TRACE_PANIC=y

Adding ipipe_trace_freeze to irq/handle.c:146 does not seem to trigger the
trace. Even if I define it in the main code block (without if statement)
this prints nothing. Could this be that a early printk is needed or some
other similar ipipe respective routine?

Is there another way of tracing the issue down?


On 25 February 2014 20:20, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/25/2014 09:04 PM, Gregory Dymarek wrote:
> > Thanks Gilles,
> >
> > Do you mean to execute ipipe_trace_freeze instead of the warning and
> > kernel/irq/handle.c:146
> > ?
>
> Yes.
>
> >
> > I've recompiled the kernel with the following code in handle.c:146
> >  13 irqreturn_t
> >
> >  12 handle_irq_event_percpu(struct irq_desc *desc, struct irqaction
> > *action)
> >  11 {
> >
> >  10     irqreturn_t retval = IRQ_NONE;
> >
> >   9     unsigned int flags = 0, irq = desc->irq_data.irq;
> >
> >   8
> >
> >   7     do {
> >
> >   6         irqreturn_t res;
> >
> >   5
> >
> >   4         trace_irq_handler_entry(irq, action);
> >
> >   3         res = action->handler(irq, action->dev_id);
> >
> >   2         trace_irq_handler_exit(irq, action, res);
> >
> >   1
> >
> > 145         if (!irqs_disabled()) ipipe_trace_freeze(1);
> >
> >   1
> >
> >   2         if (WARN_ONCE(!irqs_disabled(),"irq %u handler %pF enabled
> > interrupts\n",
> >   3                   irq, action->handler))
> >
> >   4             local_irq_disable();
> >
> >
> > But this does not trigger trace freeze.
>
> the tracer should be compiled-in and started, see:
> http://www.xenomai.org/index.php/Xenomai:I-pipe_Tracer#API
>
>
> > What is the 'unsigned int v' in the definition of ipipe_trace_freeze?
>
> It is a value you will find back in the trace.
>
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
       [not found]                 ` <CAEbDrgkJCnbWu_J4svoXOU1x2rz=n95A5+3Ee=R_9CpMgx-JmA@mail.gmail.com>
@ 2014-02-25 20:25                   ` Gilles Chanteperdrix
  2014-02-25 20:43                     ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-25 20:25 UTC (permalink / raw)
  To: Gregory Dymarek

On 02/25/2014 09:21 PM, Gregory Dymarek wrote:
> I should have added more context.
> 
> I'm sure I recompiled the kernel correctly with CONFIG_IPIPE_TRACE
> Because, when I unplug my USB device i get the ipipe trace now instead of
> default kernel panic.
> 
> Adding ipipe_trace_freeze to irq/handle.c:146 does not seem to trigger the
> trace. Even if I define it in the main code block (without if statement)
> this prints nothing. Could this be that a early printk is needed or some
> other similar ipipe respective routine?

The tracer only dumps the trace in case of panic, because in case of
panic, there is no way to dump the trace. But in the usual case, the
frozen trace can be dumped (preferably to a file) with

cat /proc/ipipe/frozen

> 
> Is there another way of tracing the issue down?

Really, the tracer is probably the best tool for the job.


-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 20:25                   ` Gilles Chanteperdrix
@ 2014-02-25 20:43                     ` Gregory Dymarek
  2014-02-25 20:50                       ` Gilles Chanteperdrix
  0 siblings, 1 reply; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-25 20:43 UTC (permalink / raw)
  To: xenomai

Here we go: http://pastebin.com/aDskYjnU

so line 47 is the call handle_irq_event_percpu
looking up of it there is one call to ipipe_unstall_root

I guess some more domain knowledge is needed in here than mine...

What does this tell us?


On 25 February 2014 20:25, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/25/2014 09:21 PM, Gregory Dymarek wrote:
> > I should have added more context.
> >
> > I'm sure I recompiled the kernel correctly with CONFIG_IPIPE_TRACE
> > Because, when I unplug my USB device i get the ipipe trace now instead of
> > default kernel panic.
> >
> > Adding ipipe_trace_freeze to irq/handle.c:146 does not seem to trigger
> the
> > trace. Even if I define it in the main code block (without if statement)
> > this prints nothing. Could this be that a early printk is needed or some
> > other similar ipipe respective routine?
>
> The tracer only dumps the trace in case of panic, because in case of
> panic, there is no way to dump the trace. But in the usual case, the
> frozen trace can be dumped (preferably to a file) with
>
> cat /proc/ipipe/frozen
>
> >
> > Is there another way of tracing the issue down?
>
> Really, the tracer is probably the best tool for the job.
>
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 20:43                     ` Gregory Dymarek
@ 2014-02-25 20:50                       ` Gilles Chanteperdrix
  2014-02-25 21:09                         ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-25 20:50 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/25/2014 09:43 PM, Gregory Dymarek wrote:
> Here we go: http://pastebin.com/aDskYjnU
> 
> so line 47 is the call handle_irq_event_percpu
> looking up of it there is one call to ipipe_unstall_root
> 
> I guess some more domain knowledge is needed in here than mine...
> 
> What does this tell us?

This tells us that dwc_otg_hcd_handle_intr is the function which
re-enables interrupt around dwc_otg_hcd_handle_intr+0x134

Some time before a call to DWC_READ_REG32

Could you make the corresponding code available somewhere?

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 20:50                       ` Gilles Chanteperdrix
@ 2014-02-25 21:09                         ` Gregory Dymarek
  2014-02-25 21:24                           ` Gilles Chanteperdrix
  2014-02-25 21:31                           ` Gilles Chanteperdrix
  0 siblings, 2 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-25 21:09 UTC (permalink / raw)
  To: xenomai

So the frame freeze I got on my version is on line 145 in here:
https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/handle.c

The dwc_otg_hcd_handle_intr is here:
https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c


Is the line 523 the problem?
    local_fiq_enable();



On 25 February 2014 20:50, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/25/2014 09:43 PM, Gregory Dymarek wrote:
> > Here we go: http://pastebin.com/aDskYjnU
> >
> > so line 47 is the call handle_irq_event_percpu
> > looking up of it there is one call to ipipe_unstall_root
> >
> > I guess some more domain knowledge is needed in here than mine...
> >
> > What does this tell us?
>
> This tells us that dwc_otg_hcd_handle_intr is the function which
> re-enables interrupt around dwc_otg_hcd_handle_intr+0x134
>
> Some time before a call to DWC_READ_REG32
>
> Could you make the corresponding code available somewhere?
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 21:09                         ` Gregory Dymarek
@ 2014-02-25 21:24                           ` Gilles Chanteperdrix
  2014-02-25 21:28                             ` Gilles Chanteperdrix
  2014-02-25 21:31                           ` Gilles Chanteperdrix
  1 sibling, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-25 21:24 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/25/2014 10:09 PM, Gregory Dymarek wrote:
> So the frame freeze I got on my version is on line 145 in here:
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/handle.c
> 
> The dwc_otg_hcd_handle_intr is here:
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> 
> 
> Is the line 523 the problem?
>     local_fiq_enable();

No, local_fiq_enable is not visible in the trace. I would say the
problem is after line 546.	

Could you put the compiled code (file vmlinux in the kernel sources
directory) corresponding to the trace in an area where I can download
it? If you compiled the kernel with debug info, it should tell us where
the problem is.


-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 21:24                           ` Gilles Chanteperdrix
@ 2014-02-25 21:28                             ` Gilles Chanteperdrix
  0 siblings, 0 replies; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-25 21:28 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/25/2014 10:24 PM, Gilles Chanteperdrix wrote:
> On 02/25/2014 10:09 PM, Gregory Dymarek wrote:
>> So the frame freeze I got on my version is on line 145 in here:
>> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/handle.c
>>
>> The dwc_otg_hcd_handle_intr is here:
>> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>>
>>
>> Is the line 523 the problem?
>>     local_fiq_enable();
> 
> No, local_fiq_enable is not visible in the trace. I would say the
> problem is after line 546.	

Sorry, yes, the problem is local_fiq_disable / local_fiq_enable.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 21:09                         ` Gregory Dymarek
  2014-02-25 21:24                           ` Gilles Chanteperdrix
@ 2014-02-25 21:31                           ` Gilles Chanteperdrix
  2014-02-25 22:30                             ` Adam Vaughan
  1 sibling, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-25 21:31 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/25/2014 10:09 PM, Gregory Dymarek wrote:
> So the frame freeze I got on my version is on line 145 in here:
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/handle.c
> 
> The dwc_otg_hcd_handle_intr is here:
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> 
> 
> Is the line 523 the problem?
>     local_fiq_enable();

Please try the following patch:

diff --git a/arch/arm/include/asm/ipipe_hwirq.h b/arch/arm/include/asm/ipipe_hwirq.h
index 6b864aa..bd8cda1 100644
--- a/arch/arm/include/asm/ipipe_hwirq.h
+++ b/arch/arm/include/asm/ipipe_hwirq.h
@@ -200,9 +200,9 @@ static inline void hard_local_irq_restore(unsigned long x)
 		ipipe_unstall_root();			\
 	} while (0)
 
-#define local_fiq_enable() ipipe_unstall_root()
+#define local_fiq_enable() hard_local_fiq_enable_notrace()
 
-#define local_fiq_disable() ipipe_stall_root()
+#define local_fiq_disable() hard_local_fiq_disable_notrace()
 
 #define arch_local_irq_restore(flags)			\
 	do {						\


-- 
                                                                Gilles.


^ permalink raw reply related	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 21:31                           ` Gilles Chanteperdrix
@ 2014-02-25 22:30                             ` Adam Vaughan
  2014-02-25 23:20                               ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Adam Vaughan @ 2014-02-25 22:30 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

I just tried the above patch and the warning doesn't show up at boot
anymore.  I tried unplugging and plugging in a flash drive / keyboard and
saw no issues in dmesg.

I mentioned it in a previous email, but just as a friendly reminder this
patch is still needed to allow you to boot with a disabled FIQ:

diff --git a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
index 19abea0..78172ea 100644
--- a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
+++ b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
@@ -742,8 +742,10 @@ int32_t dwc_otg_hcd_handle_sof_intr(dwc_otg_hcd_t *
hcd)
    }

    /* Clear interrupt */
-   //gintsts.b.sofintr = 1;
-   //DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
gintsts.d32);
+   if (!fiq_fix_enable) {
+       gintsts.b.sofintr = 1;
+       DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
gintsts.d32);
+   }

    return 1;
 }


On Tue, Feb 25, 2014 at 4:31 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/25/2014 10:09 PM, Gregory Dymarek wrote:
> > So the frame freeze I got on my version is on line 145 in here:
> > https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/handle.c
> >
> > The dwc_otg_hcd_handle_intr is here:
> >
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> >
> >
> > Is the line 523 the problem?
> >     local_fiq_enable();
>
> Please try the following patch:
>
> diff --git a/arch/arm/include/asm/ipipe_hwirq.h
> b/arch/arm/include/asm/ipipe_hwirq.h
> index 6b864aa..bd8cda1 100644
> --- a/arch/arm/include/asm/ipipe_hwirq.h
> +++ b/arch/arm/include/asm/ipipe_hwirq.h
> @@ -200,9 +200,9 @@ static inline void hard_local_irq_restore(unsigned
> long x)
>                 ipipe_unstall_root();                   \
>         } while (0)
>
> -#define local_fiq_enable() ipipe_unstall_root()
> +#define local_fiq_enable() hard_local_fiq_enable_notrace()
>
> -#define local_fiq_disable() ipipe_stall_root()
> +#define local_fiq_disable() hard_local_fiq_disable_notrace()
>
>  #define arch_local_irq_restore(flags)                  \
>         do {                                            \
>
>
> --
>                                                                 Gilles.
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>

^ permalink raw reply related	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 22:30                             ` Adam Vaughan
@ 2014-02-25 23:20                               ` Gregory Dymarek
  2014-02-25 23:42                                 ` Adam Vaughan
  2014-02-25 23:51                                 ` Gilles Chanteperdrix
  0 siblings, 2 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-25 23:20 UTC (permalink / raw)
  To: xenomai

well, this does not work for me. It boots fine when there is no USB device
plugged in.
However, when my WIFI or bluetooth adapter is plugged in, the boot log
shows: http://pastebin.com/vjLJVDGS

I also tried the patch Adam suggests but it does not seem to affect
anything.



On 25 February 2014 22:30, Adam Vaughan <vaughana@umich.edu> wrote:

> I just tried the above patch and the warning doesn't show up at boot
> anymore.  I tried unplugging and plugging in a flash drive / keyboard and
> saw no issues in dmesg.
>
> I mentioned it in a previous email, but just as a friendly reminder this
> patch is still needed to allow you to boot with a disabled FIQ:
>
> diff --git a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> index 19abea0..78172ea 100644
> --- a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> +++ b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> @@ -742,8 +742,10 @@ int32_t dwc_otg_hcd_handle_sof_intr(dwc_otg_hcd_t *
> hcd)
>     }
>
>     /* Clear interrupt */
> -   //gintsts.b.sofintr = 1;
> -   //DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
> gintsts.d32);
> +   if (!fiq_fix_enable) {
> +       gintsts.b.sofintr = 1;
> +       DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
> gintsts.d32);
> +   }
>
>     return 1;
>  }
>
>
> On Tue, Feb 25, 2014 at 4:31 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
>
>> On 02/25/2014 10:09 PM, Gregory Dymarek wrote:
>> > So the frame freeze I got on my version is on line 145 in here:
>> > https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/handle.c
>> >
>> > The dwc_otg_hcd_handle_intr is here:
>> >
>> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>> >
>> >
>> > Is the line 523 the problem?
>> >     local_fiq_enable();
>>
>> Please try the following patch:
>>
>> diff --git a/arch/arm/include/asm/ipipe_hwirq.h
>> b/arch/arm/include/asm/ipipe_hwirq.h
>> index 6b864aa..bd8cda1 100644
>> --- a/arch/arm/include/asm/ipipe_hwirq.h
>> +++ b/arch/arm/include/asm/ipipe_hwirq.h
>> @@ -200,9 +200,9 @@ static inline void hard_local_irq_restore(unsigned
>> long x)
>>                 ipipe_unstall_root();                   \
>>         } while (0)
>>
>> -#define local_fiq_enable() ipipe_unstall_root()
>> +#define local_fiq_enable() hard_local_fiq_enable_notrace()
>>
>> -#define local_fiq_disable() ipipe_stall_root()
>> +#define local_fiq_disable() hard_local_fiq_disable_notrace()
>>
>>  #define arch_local_irq_restore(flags)                  \
>>         do {                                            \
>>
>>
>> --
>>                                                                 Gilles.
>>
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> http://www.xenomai.org/mailman/listinfo/xenomai
>>
>
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 23:20                               ` Gregory Dymarek
@ 2014-02-25 23:42                                 ` Adam Vaughan
  2014-02-25 23:45                                   ` Adam Vaughan
  2014-02-25 23:51                                 ` Gilles Chanteperdrix
  1 sibling, 1 reply; 61+ messages in thread
From: Adam Vaughan @ 2014-02-25 23:42 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

I don't have a WiFi or Bluetooth adapter with me to try at the moment, but
I just tried booting with my USB flash drive installed prior to power on
and didn't see an issue both with and without the USB FIQ enabled.  I can
try with a Bluetooth adapter tomorrow, if needed.

Your logs are more useful since they show the actual issue, but maybe my
boot logs (attached) will be at least a little helpful in troubleshooting?
 Also, the patch I listed above is only needed if you want to boot with the
USB FIQ disabled.


On Tue, Feb 25, 2014 at 6:20 PM, Gregory Dymarek <gregd72002@gmail.com>wrote:

> well, this does not work for me. It boots fine when there is no USB device
> plugged in.
> However, when my WIFI or bluetooth adapter is plugged in, the boot log
> shows: http://pastebin.com/vjLJVDGS
>
> I also tried the patch Adam suggests but it does not seem to affect
> anything.
>
>
>
> On 25 February 2014 22:30, Adam Vaughan <vaughana@umich.edu> wrote:
>
> > I just tried the above patch and the warning doesn't show up at boot
> > anymore.  I tried unplugging and plugging in a flash drive / keyboard and
> > saw no issues in dmesg.
> >
> > I mentioned it in a previous email, but just as a friendly reminder this
> > patch is still needed to allow you to boot with a disabled FIQ:
> >
> > diff --git a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> > b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> > index 19abea0..78172ea 100644
> > --- a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> > +++ b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> > @@ -742,8 +742,10 @@ int32_t dwc_otg_hcd_handle_sof_intr(dwc_otg_hcd_t *
> > hcd)
> >     }
> >
> >     /* Clear interrupt */
> > -   //gintsts.b.sofintr = 1;
> > -   //DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
> > gintsts.d32);
> > +   if (!fiq_fix_enable) {
> > +       gintsts.b.sofintr = 1;
> > +       DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
> > gintsts.d32);
> > +   }
> >
> >     return 1;
> >  }
> >
> >
> > On Tue, Feb 25, 2014 at 4:31 PM, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> wrote:
> >
> >> On 02/25/2014 10:09 PM, Gregory Dymarek wrote:
> >> > So the frame freeze I got on my version is on line 145 in here:
> >> >
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/handle.c
> >> >
> >> > The dwc_otg_hcd_handle_intr is here:
> >> >
> >>
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> >> >
> >> >
> >> > Is the line 523 the problem?
> >> >     local_fiq_enable();
> >>
> >> Please try the following patch:
> >>
> >> diff --git a/arch/arm/include/asm/ipipe_hwirq.h
> >> b/arch/arm/include/asm/ipipe_hwirq.h
> >> index 6b864aa..bd8cda1 100644
> >> --- a/arch/arm/include/asm/ipipe_hwirq.h
> >> +++ b/arch/arm/include/asm/ipipe_hwirq.h
> >> @@ -200,9 +200,9 @@ static inline void hard_local_irq_restore(unsigned
> >> long x)
> >>                 ipipe_unstall_root();                   \
> >>         } while (0)
> >>
> >> -#define local_fiq_enable() ipipe_unstall_root()
> >> +#define local_fiq_enable() hard_local_fiq_enable_notrace()
> >>
> >> -#define local_fiq_disable() ipipe_stall_root()
> >> +#define local_fiq_disable() hard_local_fiq_disable_notrace()
> >>
> >>  #define arch_local_irq_restore(flags)                  \
> >>         do {                                            \
> >>
> >>
> >> --
> >>                                                                 Gilles.
> >>
> >> _______________________________________________
> >> Xenomai mailing list
> >> Xenomai@xenomai.org
> >> http://www.xenomai.org/mailman/listinfo/xenomai
> >>
> >
> >
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: withFiqDisabled
Type: application/octet-stream
Size: 12004 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140225/858b9392/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: withFiqEnabled
Type: application/octet-stream
Size: 12017 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140225/858b9392/attachment-0001.obj>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 23:42                                 ` Adam Vaughan
@ 2014-02-25 23:45                                   ` Adam Vaughan
  2014-02-26  0:12                                     ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Adam Vaughan @ 2014-02-25 23:45 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

I forgot to add the *.txt extension to the above, sorry about that.


On Tue, Feb 25, 2014 at 6:42 PM, Adam Vaughan <vaughana@umich.edu> wrote:

> I don't have a WiFi or Bluetooth adapter with me to try at the moment, but
> I just tried booting with my USB flash drive installed prior to power on
> and didn't see an issue both with and without the USB FIQ enabled.  I can
> try with a Bluetooth adapter tomorrow, if needed.
>
> Your logs are more useful since they show the actual issue, but maybe my
> boot logs (attached) will be at least a little helpful in troubleshooting?
>  Also, the patch I listed above is only needed if you want to boot with the
> USB FIQ disabled.
>
>
> On Tue, Feb 25, 2014 at 6:20 PM, Gregory Dymarek <gregd72002@gmail.com>wrote:
>
>> well, this does not work for me. It boots fine when there is no USB device
>> plugged in.
>> However, when my WIFI or bluetooth adapter is plugged in, the boot log
>> shows: http://pastebin.com/vjLJVDGS
>>
>> I also tried the patch Adam suggests but it does not seem to affect
>> anything.
>>
>>
>>
>> On 25 February 2014 22:30, Adam Vaughan <vaughana@umich.edu> wrote:
>>
>> > I just tried the above patch and the warning doesn't show up at boot
>> > anymore.  I tried unplugging and plugging in a flash drive / keyboard
>> and
>> > saw no issues in dmesg.
>> >
>> > I mentioned it in a previous email, but just as a friendly reminder this
>> > patch is still needed to allow you to boot with a disabled FIQ:
>> >
>> > diff --git a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>> > b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>> > index 19abea0..78172ea 100644
>> > --- a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>> > +++ b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>> > @@ -742,8 +742,10 @@ int32_t dwc_otg_hcd_handle_sof_intr(dwc_otg_hcd_t *
>> > hcd)
>> >     }
>> >
>> >     /* Clear interrupt */
>> > -   //gintsts.b.sofintr = 1;
>> > -   //DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
>> > gintsts.d32);
>> > +   if (!fiq_fix_enable) {
>> > +       gintsts.b.sofintr = 1;
>> > +       DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
>> > gintsts.d32);
>> > +   }
>> >
>> >     return 1;
>> >  }
>> >
>> >
>> > On Tue, Feb 25, 2014 at 4:31 PM, Gilles Chanteperdrix <
>> > gilles.chanteperdrix@xenomai.org> wrote:
>> >
>> >> On 02/25/2014 10:09 PM, Gregory Dymarek wrote:
>> >> > So the frame freeze I got on my version is on line 145 in here:
>> >> >
>> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/handle.c
>> >> >
>> >> > The dwc_otg_hcd_handle_intr is here:
>> >> >
>> >>
>> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>> >> >
>> >> >
>> >> > Is the line 523 the problem?
>> >> >     local_fiq_enable();
>> >>
>> >> Please try the following patch:
>> >>
>> >> diff --git a/arch/arm/include/asm/ipipe_hwirq.h
>> >> b/arch/arm/include/asm/ipipe_hwirq.h
>> >> index 6b864aa..bd8cda1 100644
>> >> --- a/arch/arm/include/asm/ipipe_hwirq.h
>> >> +++ b/arch/arm/include/asm/ipipe_hwirq.h
>> >> @@ -200,9 +200,9 @@ static inline void hard_local_irq_restore(unsigned
>> >> long x)
>> >>                 ipipe_unstall_root();                   \
>> >>         } while (0)
>> >>
>> >> -#define local_fiq_enable() ipipe_unstall_root()
>> >> +#define local_fiq_enable() hard_local_fiq_enable_notrace()
>> >>
>> >> -#define local_fiq_disable() ipipe_stall_root()
>> >> +#define local_fiq_disable() hard_local_fiq_disable_notrace()
>> >>
>> >>  #define arch_local_irq_restore(flags)                  \
>> >>         do {                                            \
>> >>
>> >>
>> >> --
>> >>                                                                 Gilles.
>> >>
>> >> _______________________________________________
>> >> Xenomai mailing list
>> >> Xenomai@xenomai.org
>> >> http://www.xenomai.org/mailman/listinfo/xenomai
>> >>
>> >
>> >
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> http://www.xenomai.org/mailman/listinfo/xenomai
>>
>
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 23:20                               ` Gregory Dymarek
  2014-02-25 23:42                                 ` Adam Vaughan
@ 2014-02-25 23:51                                 ` Gilles Chanteperdrix
       [not found]                                   ` <CAEbDrgkWZqSxjCUfjR3YCp=YOzh1r-=YC6Wyr-Jvk9d7JYEcmQ@mail.gmail.com>
  1 sibling, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-25 23:51 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/26/2014 12:20 AM, Gregory Dymarek wrote:
> well, this does not work for me. It boots fine when there is no USB device
> plugged in.
> However, when my WIFI or bluetooth adapter is plugged in, the boot log
> shows: http://pastebin.com/vjLJVDGS

Well, it looks like a different issue, which happens when irqs are
re-enabled by DWC_SPINUNLOCK_IRQRESTORE. So, maybe we have progressed. I
am cloning the rpi repository, to see what happens at this point.

But you can try and use the I-pipe tracer again, put a trace freeze in
the "report_bad_irq" function.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-25 23:45                                   ` Adam Vaughan
@ 2014-02-26  0:12                                     ` Gregory Dymarek
  2014-02-26  0:22                                       ` Adam Vaughan
                                                         ` (2 more replies)
  0 siblings, 3 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-26  0:12 UTC (permalink / raw)
  To: xenomai

Adam, when i try to boot with a usb mass storage i got also the same
warning. I'm running with FIQ disabled and on version A board.

What kernel version are you using Adam? Are there any other patches that
you enabled?

I guess this also might be down to the kernel configuration. I'm now
running with a full debug, don't know if this can affect the result.


On 25 February 2014 23:45, Adam Vaughan <vaughana@umich.edu> wrote:

> I forgot to add the *.txt extension to the above, sorry about that.
>
>
> On Tue, Feb 25, 2014 at 6:42 PM, Adam Vaughan <vaughana@umich.edu> wrote:
>
>> I don't have a WiFi or Bluetooth adapter with me to try at the moment,
>> but I just tried booting with my USB flash drive installed prior to power
>> on and didn't see an issue both with and without the USB FIQ enabled.  I
>> can try with a Bluetooth adapter tomorrow, if needed.
>>
>> Your logs are more useful since they show the actual issue, but maybe my
>> boot logs (attached) will be at least a little helpful in troubleshooting?
>>  Also, the patch I listed above is only needed if you want to boot with the
>> USB FIQ disabled.
>>
>>
>> On Tue, Feb 25, 2014 at 6:20 PM, Gregory Dymarek <gregd72002@gmail.com>wrote:
>>
>>> well, this does not work for me. It boots fine when there is no USB
>>> device
>>> plugged in.
>>> However, when my WIFI or bluetooth adapter is plugged in, the boot log
>>> shows: http://pastebin.com/vjLJVDGS
>>>
>>> I also tried the patch Adam suggests but it does not seem to affect
>>> anything.
>>>
>>>
>>>
>>> On 25 February 2014 22:30, Adam Vaughan <vaughana@umich.edu> wrote:
>>>
>>> > I just tried the above patch and the warning doesn't show up at boot
>>> > anymore.  I tried unplugging and plugging in a flash drive / keyboard
>>> and
>>> > saw no issues in dmesg.
>>> >
>>> > I mentioned it in a previous email, but just as a friendly reminder
>>> this
>>> > patch is still needed to allow you to boot with a disabled FIQ:
>>> >
>>> > diff --git a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>>> > b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>>> > index 19abea0..78172ea 100644
>>> > --- a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>>> > +++ b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>>> > @@ -742,8 +742,10 @@ int32_t dwc_otg_hcd_handle_sof_intr(dwc_otg_hcd_t
>>> *
>>> > hcd)
>>> >     }
>>> >
>>> >     /* Clear interrupt */
>>> > -   //gintsts.b.sofintr = 1;
>>> > -   //DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
>>> > gintsts.d32);
>>> > +   if (!fiq_fix_enable) {
>>> > +       gintsts.b.sofintr = 1;
>>> > +       DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
>>> > gintsts.d32);
>>> > +   }
>>> >
>>> >     return 1;
>>> >  }
>>> >
>>> >
>>> > On Tue, Feb 25, 2014 at 4:31 PM, Gilles Chanteperdrix <
>>> > gilles.chanteperdrix@xenomai.org> wrote:
>>> >
>>> >> On 02/25/2014 10:09 PM, Gregory Dymarek wrote:
>>> >> > So the frame freeze I got on my version is on line 145 in here:
>>> >> >
>>> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/handle.c
>>> >> >
>>> >> > The dwc_otg_hcd_handle_intr is here:
>>> >> >
>>> >>
>>> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
>>> >> >
>>> >> >
>>> >> > Is the line 523 the problem?
>>> >> >     local_fiq_enable();
>>> >>
>>> >> Please try the following patch:
>>> >>
>>> >> diff --git a/arch/arm/include/asm/ipipe_hwirq.h
>>> >> b/arch/arm/include/asm/ipipe_hwirq.h
>>> >> index 6b864aa..bd8cda1 100644
>>> >> --- a/arch/arm/include/asm/ipipe_hwirq.h
>>> >> +++ b/arch/arm/include/asm/ipipe_hwirq.h
>>> >> @@ -200,9 +200,9 @@ static inline void hard_local_irq_restore(unsigned
>>> >> long x)
>>> >>                 ipipe_unstall_root();                   \
>>> >>         } while (0)
>>> >>
>>> >> -#define local_fiq_enable() ipipe_unstall_root()
>>> >> +#define local_fiq_enable() hard_local_fiq_enable_notrace()
>>> >>
>>> >> -#define local_fiq_disable() ipipe_stall_root()
>>> >> +#define local_fiq_disable() hard_local_fiq_disable_notrace()
>>> >>
>>> >>  #define arch_local_irq_restore(flags)                  \
>>> >>         do {                                            \
>>> >>
>>> >>
>>> >> --
>>> >>
>>> Gilles.
>>> >>
>>> >> _______________________________________________
>>> >> Xenomai mailing list
>>> >> Xenomai@xenomai.org
>>> >> http://www.xenomai.org/mailman/listinfo/xenomai
>>> >>
>>> >
>>> >
>>> _______________________________________________
>>> Xenomai mailing list
>>> Xenomai@xenomai.org
>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>
>>
>>
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-26  0:12                                     ` Gregory Dymarek
@ 2014-02-26  0:22                                       ` Adam Vaughan
  2014-02-26  0:33                                       ` Gilles Chanteperdrix
  2014-02-26 10:26                                       ` Paul
  2 siblings, 0 replies; 61+ messages in thread
From: Adam Vaughan @ 2014-02-26  0:22 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

I don't believe it makes any difference, but I'm using a model B board.

This is my exact build process (kernel config attached):

wget -q -O - http://download.gna.org/xenomai/stable/xenomai-2.6.3.tar.bz2 |
tar -xjvf -

git clone --depth=1 -b rpi-3.8.y git://github.com/raspberrypi/linux.git
cd linux
git checkout d996a1b

patch -Np1 <
../xenomai-2.6.3/ksrc/arch/arm/patches/raspberry/ipipe-core-3.8.13-raspberry-pre-2.patch
../xenomai-2.6.3/scripts/./prepare-kernel.sh --arch=arm --linux=./
--adeos=../xenomai-2.6.3/ksrc/arch/arm/patches/ipipe-core-3.8.13-arm-3.patch
patch -Np1 <
../xenomai-2.6.3/ksrc/arch/arm/patches/raspberry/ipipe-core-3.8.13-raspberry-post-2.patch

Apply these two patches:

diff --git a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
index 19abea0..78172ea 100644
--- a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
+++ b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
@@ -742,8 +742,10 @@ int32_t dwc_otg_hcd_handle_sof_intr(dwc_otg_hcd_t *
hcd)
    }

    /* Clear interrupt */
-   //gintsts.b.sofintr = 1;
-   //DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
gintsts.d32);
+   if (!fiq_fix_enable) {
+       gintsts.b.sofintr = 1;
+       DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
gintsts.d32);
+   }

    return 1;
 }

diff --git a/arch/arm/include/asm/ipipe_hwirq.h
b/arch/arm/include/asm/ipipe_hwirq.h
index 6b864aa..bd8cda1 100644
--- a/arch/arm/include/asm/ipipe_hwirq.h
+++ b/arch/arm/include/asm/ipipe_hwirq.h
@@ -200,9 +200,9 @@ static inline void hard_local_irq_restore(unsigned long
x)
                ipipe_unstall_root();                   \
        } while (0)

-#define local_fiq_enable() ipipe_unstall_root()
+#define local_fiq_enable() hard_local_fiq_enable_notrace()

-#define local_fiq_disable() ipipe_stall_root()
+#define local_fiq_disable() hard_local_fiq_disable_notrace()

 #define arch_local_irq_restore(flags)                  \
        do {                                            \

make mrproper
wget https://www.dropbox.com/s/dcju74md5sz45at/rpi_xenomai_config
mv rpi_xenomai_config .config
make ARCH=arm oldconfig

make ARCH=arm
CROSS_COMPILE=~/x-tools/armv6j-hardfloat-linux-gnueabi/bin/armv6j-hardfloat-linux-gnueabi-
-j 8


On Tue, Feb 25, 2014 at 7:12 PM, Gregory Dymarek <gregd72002@gmail.com>wrote:

> Adam, when i try to boot with a usb mass storage i got also the same
> warning. I'm running with FIQ disabled and on version A board.
>
> What kernel version are you using Adam? Are there any other patches that
> you enabled?
>
> I guess this also might be down to the kernel configuration. I'm now
> running with a full debug, don't know if this can affect the result.
>
>
> On 25 February 2014 23:45, Adam Vaughan <vaughana@umich.edu> wrote:
>
> > I forgot to add the *.txt extension to the above, sorry about that.
> >
> >
> > On Tue, Feb 25, 2014 at 6:42 PM, Adam Vaughan <vaughana@umich.edu>
> wrote:
> >
> >> I don't have a WiFi or Bluetooth adapter with me to try at the moment,
> >> but I just tried booting with my USB flash drive installed prior to
> power
> >> on and didn't see an issue both with and without the USB FIQ enabled.  I
> >> can try with a Bluetooth adapter tomorrow, if needed.
> >>
> >> Your logs are more useful since they show the actual issue, but maybe my
> >> boot logs (attached) will be at least a little helpful in
> troubleshooting?
> >>  Also, the patch I listed above is only needed if you want to boot with
> the
> >> USB FIQ disabled.
> >>
> >>
> >> On Tue, Feb 25, 2014 at 6:20 PM, Gregory Dymarek <gregd72002@gmail.com
> >wrote:
> >>
> >>> well, this does not work for me. It boots fine when there is no USB
> >>> device
> >>> plugged in.
> >>> However, when my WIFI or bluetooth adapter is plugged in, the boot log
> >>> shows: http://pastebin.com/vjLJVDGS
> >>>
> >>> I also tried the patch Adam suggests but it does not seem to affect
> >>> anything.
> >>>
> >>>
> >>>
> >>> On 25 February 2014 22:30, Adam Vaughan <vaughana@umich.edu> wrote:
> >>>
> >>> > I just tried the above patch and the warning doesn't show up at boot
> >>> > anymore.  I tried unplugging and plugging in a flash drive / keyboard
> >>> and
> >>> > saw no issues in dmesg.
> >>> >
> >>> > I mentioned it in a previous email, but just as a friendly reminder
> >>> this
> >>> > patch is still needed to allow you to boot with a disabled FIQ:
> >>> >
> >>> > diff --git a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> >>> > b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> >>> > index 19abea0..78172ea 100644
> >>> > --- a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> >>> > +++ b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> >>> > @@ -742,8 +742,10 @@ int32_t
> dwc_otg_hcd_handle_sof_intr(dwc_otg_hcd_t
> >>> *
> >>> > hcd)
> >>> >     }
> >>> >
> >>> >     /* Clear interrupt */
> >>> > -   //gintsts.b.sofintr = 1;
> >>> > -   //DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
> >>> > gintsts.d32);
> >>> > +   if (!fiq_fix_enable) {
> >>> > +       gintsts.b.sofintr = 1;
> >>> > +       DWC_WRITE_REG32(&hcd->core_if->core_global_regs->gintsts,
> >>> > gintsts.d32);
> >>> > +   }
> >>> >
> >>> >     return 1;
> >>> >  }
> >>> >
> >>> >
> >>> > On Tue, Feb 25, 2014 at 4:31 PM, Gilles Chanteperdrix <
> >>> > gilles.chanteperdrix@xenomai.org> wrote:
> >>> >
> >>> >> On 02/25/2014 10:09 PM, Gregory Dymarek wrote:
> >>> >> > So the frame freeze I got on my version is on line 145 in here:
> >>> >> >
> >>>
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/handle.c
> >>> >> >
> >>> >> > The dwc_otg_hcd_handle_intr is here:
> >>> >> >
> >>> >>
> >>>
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
> >>> >> >
> >>> >> >
> >>> >> > Is the line 523 the problem?
> >>> >> >     local_fiq_enable();
> >>> >>
> >>> >> Please try the following patch:
> >>> >>
> >>> >> diff --git a/arch/arm/include/asm/ipipe_hwirq.h
> >>> >> b/arch/arm/include/asm/ipipe_hwirq.h
> >>> >> index 6b864aa..bd8cda1 100644
> >>> >> --- a/arch/arm/include/asm/ipipe_hwirq.h
> >>> >> +++ b/arch/arm/include/asm/ipipe_hwirq.h
> >>> >> @@ -200,9 +200,9 @@ static inline void
> hard_local_irq_restore(unsigned
> >>> >> long x)
> >>> >>                 ipipe_unstall_root();                   \
> >>> >>         } while (0)
> >>> >>
> >>> >> -#define local_fiq_enable() ipipe_unstall_root()
> >>> >> +#define local_fiq_enable() hard_local_fiq_enable_notrace()
> >>> >>
> >>> >> -#define local_fiq_disable() ipipe_stall_root()
> >>> >> +#define local_fiq_disable() hard_local_fiq_disable_notrace()
> >>> >>
> >>> >>  #define arch_local_irq_restore(flags)                  \
> >>> >>         do {                                            \
> >>> >>
> >>> >>
> >>> >> --
> >>> >>
> >>> Gilles.
> >>> >>
> >>> >> _______________________________________________
> >>> >> Xenomai mailing list
> >>> >> Xenomai@xenomai.org
> >>> >> http://www.xenomai.org/mailman/listinfo/xenomai
> >>> >>
> >>> >
> >>> >
> >>> _______________________________________________
> >>> Xenomai mailing list
> >>> Xenomai@xenomai.org
> >>> http://www.xenomai.org/mailman/listinfo/xenomai
> >>>
> >>
> >>
> >
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.8.13 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_FIQ=y
CONFIG_VECTORS_BASE=0xffff0000
# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_NEED_MACH_IO_H=y
CONFIG_NEED_MACH_MEMORY_H=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION="-core"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_HAVE_UID16=y
# CONFIG_UID16 is not set
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
# CONFIG_JUMP_LABEL is not set
CONFIG_KRETPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y

#
# Real-time sub-system
#

#
# WARNING! You enabled APM, CPU Frequency scaling, ACPI 'processor'
#

#
# or Intel cpuidle option. These options are known to cause troubles
#

#
# with Xenomai, disable them.
#
CONFIG_XENOMAI=y
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH_DEP=y
CONFIG_XENO_FASTSYNCH=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_PRIOCPL is not set
CONFIG_XENO_OPT_PIPELINE_HEAD=y
# CONFIG_XENO_OPT_SCHED_CLASSES is not set
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_MAP=y
CONFIG_XENO_OPT_VFILE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=256
CONFIG_XENO_OPT_SYS_STACKPOOLSZ=128
CONFIG_XENO_OPT_SEM_HEAPSZ=12
CONFIG_XENO_OPT_GLOBAL_SEM_HEAPSZ=12
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_DEBUG=y
# CONFIG_XENO_OPT_DEBUG_NUCLEUS is not set
# CONFIG_XENO_OPT_DEBUG_XNLOCK is not set
# CONFIG_XENO_OPT_DEBUG_QUEUES is not set
# CONFIG_XENO_OPT_DEBUG_REGISTRY is not set
# CONFIG_XENO_OPT_DEBUG_TIMERS is not set
CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX=y
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=5
CONFIG_XENO_OPT_SHIRQ=y
CONFIG_XENO_OPT_SELECT=y
CONFIG_XENO_OPT_HOSTRT=y

#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_VIRTICK=1000
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0

#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set

#
# Machine
#
CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH=y
CONFIG_IPIPE_WANT_ACTIVE_MM=y
CONFIG_XENO_HW_FPU=y
CONFIG_XENO_HW_UNLOCKED_SWITCH=y

#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_BUFFER=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
CONFIG_XENO_OPT_NATIVE_INTR=y
CONFIG_XENO_OPT_DEBUG_NATIVE=y
CONFIG_XENO_SKIN_POSIX=m
CONFIG_XENO_OPT_POSIX_PERIOD=0
CONFIG_XENO_OPT_POSIX_SHM=y
CONFIG_XENO_OPT_POSIX_INTR=y
CONFIG_XENO_OPT_POSIX_SELECT=y
CONFIG_XENO_OPT_DEBUG_POSIX=y
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
CONFIG_XENO_OPT_RTDM_SELECT=y
# CONFIG_XENO_OPT_DEBUG_RTDM is not set
CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y

#
# Drivers
#

#
# Serial drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set

#
# Testing drivers
#
CONFIG_XENO_DRIVERS_TIMERBENCH=m
CONFIG_XENO_DRIVERS_KLATENCY=m
CONFIG_XENO_DRIVERS_IRQBENCH=m
CONFIG_XENO_DRIVERS_SWITCHTEST=m
CONFIG_XENO_DRIVERS_RTDMTEST=m

#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_CAN is not set

#
# ANALOGY drivers
#
# CONFIG_XENO_DRIVERS_ANALOGY is not set

#
# Real-time IPC drivers
#
CONFIG_XENO_DRIVERS_RTIPC=m
CONFIG_XENO_DRIVERS_RTIPC_XDDP=y
CONFIG_XENO_DRIVERS_RTIPC_IDDP=y
CONFIG_XENO_OPT_IDDP_NRPORT=32
CONFIG_XENO_DRIVERS_RTIPC_BUFP=y
CONFIG_XENO_OPT_BUFP_NRPORT=32
# CONFIG_FREEZER is not set

#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_MULTIPLATFORM is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCM2835 is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXS is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
CONFIG_ARCH_BCM2708=y
# CONFIG_ARCH_VT8500_SINGLE is not set
CONFIG_GPIO_PCA953X=m
# CONFIG_ARCH_VT8500 is not set

#
# Broadcom BCM2708 Implementations
#
CONFIG_MACH_BCM2708=y
CONFIG_BCM2708_GPIO=y
CONFIG_BCM2708_VCMEM=y
# CONFIG_BCM2708_NOL2CACHE is not set
# CONFIG_BCM2708_DMAER is not set
CONFIG_BCM2708_SPIDEV=y
CONFIG_IPIPE_ARM_KUSER_TSC=y

#
# Processor Type
#
CONFIG_CPU_V6=y
CONFIG_CPU_32v6=y
CONFIG_CPU_ABRT_EV6=y
CONFIG_CPU_PABRT_V6=y
CONFIG_CPU_CACHE_V6=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V6=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y

#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
# CONFIG_CACHE_L2X0 is not set
CONFIG_ARM_L1_CACHE_SHIFT=5
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
# CONFIG_ARM_ERRATA_326103 is not set
CONFIG_ARM_ERRATA_411920=y
# CONFIG_ARM_ERRATA_364296 is not set

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_NR_GPIO=0
CONFIG_IPIPE=y
CONFIG_IPIPE_LEGACY=y
CONFIG_IPIPE_CORE=y
CONFIG_IPIPE_CORE_APIREV=2
CONFIG_IPIPE_WANT_APIREV_2=y
CONFIG_IPIPE_TARGET_APIREV=2
CONFIG_IPIPE_HAVE_HOSTRT=y
CONFIG_IPIPE_DELAYED_ATOMICSW=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
# CONFIG_HIGHMEM is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_COMPACTION is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set

#
# Boot options
#
# CONFIG_USE_OF is not set
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="dwc_otg.lpm_enable=0 disable_pvt=1 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_AUTO_ZRELADDR is not set

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_STAT is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# ARM CPU frequency scaling drivers
#
# CONFIG_ARM_EXYNOS4210_CPUFREQ is not set
# CONFIG_ARM_EXYNOS4X12_CPUFREQ is not set
# CONFIG_ARM_EXYNOS5250_CPUFREQ is not set
CONFIG_ARM_BCM2835_CPUFREQ=y
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_COREDUMP=y

#
# Power management options
#
# CONFIG_SUSPEND is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ARM_CPU_SUSPEND is not set
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=m
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_TCPPROBE is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_DRBD is not set
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
CONFIG_EEPROM_93CX6=m
# CONFIG_EEPROM_93XX46 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
CONFIG_BCM2708_VCHIQ=y

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
CONFIG_NETCONSOLE=m
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=m
# CONFIG_VETH is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
# CONFIG_NET_VENDOR_CIRRUS is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_FARADAY is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_ETHOC is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_PHYLIB=m

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
CONFIG_MDIO_BITBANG=m
# CONFIG_MDIO_GPIO is not set
# CONFIG_MICREL_KS8995MA is not set
CONFIG_PPP=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_DEFLATE=m
# CONFIG_PPP_FILTER is not set
# CONFIG_PPP_MPPE is not set
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPPOE is not set
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_SLIP=m
CONFIG_SLHC=m
CONFIG_SLIP_COMPRESSED=y
# CONFIG_SLIP_SMART is not set
# CONFIG_SLIP_MODE_SLIP6 is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
CONFIG_USB_USBNET=y
# CONFIG_USB_NET_AX8817X is not set
# CONFIG_USB_NET_CDCETHER is not set
# CONFIG_USB_NET_CDC_EEM is not set
# CONFIG_USB_NET_CDC_NCM is not set
# CONFIG_USB_NET_CDC_MBIM is not set
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_SMSC75XX is not set
CONFIG_USB_NET_SMSC95XX=y
# CONFIG_USB_NET_GL620A is not set
# CONFIG_USB_NET_NET1080 is not set
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
# CONFIG_USB_NET_CDC_SUBSET is not set
# CONFIG_USB_NET_ZAURUS is not set
# CONFIG_USB_NET_CX82310_ETH is not set
# CONFIG_USB_NET_KALMIA is not set
# CONFIG_USB_NET_QMI_WWAN is not set
# CONFIG_USB_NET_INT51X1 is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_USB_SIERRA_NET is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_GP2A is not set
# CONFIG_INPUT_GPIO_TILT_POLLED is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
CONFIG_INPUT_UINPUT=m
# CONFIG_INPUT_PCF8574 is not set
CONFIG_INPUT_GPIO_ROTARY_ENCODER=m
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=m
CONFIG_SERIO_SERPORT=m
# CONFIG_SERIO_AMBAKMI is not set
# CONFIG_SERIO_LIBPS2 is not set
CONFIG_SERIO_RAW=m
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
# CONFIG_DEVKMEM is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_R3964 is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=256
# CONFIG_TCG_TPM is not set
CONFIG_BRCM_CHAR_DRIVERS=m
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_MUX=m

#
# Multiplexer I2C Chip support
#
CONFIG_I2C_MUX_GPIO=m
CONFIG_I2C_MUX_PCA9541=m
CONFIG_I2C_MUX_PCA954x=m
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=m

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
CONFIG_I2C_BCM2708=m
CONFIG_I2C_BCM2708_BAUDRATE=100000
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
CONFIG_I2C_GPIO=m
# CONFIG_I2C_NOMADIK is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
CONFIG_SPI_BCM2708=m
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_PL022 is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
CONFIG_SPI_SPIDEV=m
# CONFIG_SPI_TLE62X0 is not set
# CONFIG_HSI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_MAX730X=m

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_PL061 is not set
# CONFIG_GPIO_TS5500 is not set

#
# I2C GPIO expanders:
#
CONFIG_GPIO_MAX7300=m
CONFIG_GPIO_MAX732X=m
CONFIG_GPIO_PCF857X=m
# CONFIG_GPIO_ADP5588 is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
CONFIG_HWMON=m
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_AD7314 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADCXX is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7410 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_GPIO_FAN is not set
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_LINEAGE is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX197 is not set
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_MCP3021 is not set
# CONFIG_SENSORS_NTC_THERMISTOR is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_PMBUS is not set
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_SCH5627 is not set
# CONFIG_SENSORS_SCH5636 is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_ADS7871 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_INA2XX is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_THERMAL=m
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_FAIR_SHARE is not set
CONFIG_STEP_WISE=y
# CONFIG_USER_SPACE is not set
# CONFIG_CPU_THERMAL is not set
CONFIG_THERMAL_BCM2835=m
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_CORE is not set
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ARM_SP805_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
CONFIG_BCM2708_WDT=m

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
CONFIG_BCMA=m
# CONFIG_BCMA_DRIVER_GMAC_CMN is not set
# CONFIG_BCMA_DRIVER_GPIO is not set
# CONFIG_BCMA_DEBUG is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_REGULATOR is not set
CONFIG_MEDIA_SUPPORT=m

#
# Multimedia core support
#
# CONFIG_MEDIA_CAMERA_SUPPORT is not set
# CONFIG_MEDIA_ANALOG_TV_SUPPORT is not set
# CONFIG_MEDIA_DIGITAL_TV_SUPPORT is not set
# CONFIG_MEDIA_RADIO_SUPPORT is not set
# CONFIG_MEDIA_RC_SUPPORT is not set
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set

#
# Media drivers
#
# CONFIG_MEDIA_USB_SUPPORT is not set

#
# Supported MMC/SDIO adapters
#

#
# Media ancillary drivers (tuners, sensors, i2c, frontends)
#

#
# Customise DVB Frontends
#
# CONFIG_DVB_TUNER_DIB0070 is not set
# CONFIG_DVB_TUNER_DIB0090 is not set

#
# Tools to develop new frontends
#
# CONFIG_DVB_DUMMY_FE is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_WMT_GE_ROPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
CONFIG_FB_BCM2708=y
# CONFIG_FB_ARMCLCD is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
CONFIG_USB_HIDDEV=y

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set
# CONFIG_USB_ARCH_HAS_EHCI is not set
# CONFIG_USB_ARCH_HAS_XHCI is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
CONFIG_USB_MON=m
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
CONFIG_USB_DWCOTG=y
# CONFIG_USB_HCD_BCMA is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB port drivers
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_CH341 is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP210X is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
CONFIG_USB_SERIAL_FTDI_SIO=m
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_F81232 is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_IUU is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_METRO is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_MOTOROLA is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_OTI6858 is not set
# CONFIG_USB_SERIAL_QCAUX is not set
# CONFIG_USB_SERIAL_QUALCOMM is not set
# CONFIG_USB_SERIAL_SPCP8X5 is not set
# CONFIG_USB_SERIAL_HP4X is not set
CONFIG_USB_SERIAL_SAFE=m
# CONFIG_USB_SERIAL_SAFE_PADDED is not set
# CONFIG_USB_SERIAL_SIEMENS_MPI is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_SYMBOL is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_OPTICON is not set
# CONFIG_USB_SERIAL_VIVOPAY_SERIAL is not set
# CONFIG_USB_SERIAL_ZIO is not set
# CONFIG_USB_SERIAL_ZTE is not set
# CONFIG_USB_SERIAL_SSU100 is not set
# CONFIG_USB_SERIAL_QT2 is not set
# CONFIG_USB_SERIAL_DEBUG is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=m
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set

#
# USB Physical Layer drivers
#
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_RCAR_PHY is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ULPI is not set
# CONFIG_NOP_USB_XCEIV is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_ARMMMCI is not set
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_PLTFM=y
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_SDHCI_BCM2708=y
CONFIG_MMC_SDHCI_BCM2708_DMA=y
# CONFIG_MMC_SPI is not set
# CONFIG_MMC_DW is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
CONFIG_LEDS_GPIO=y
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_RENESAS_TPU is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set
CONFIG_LEDS_TRIGGERS=y

#
# LED Triggers
#
CONFIG_LEDS_TRIGGER_TIMER=m
# CONFIG_LEDS_TRIGGER_ONESHOT is not set
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_CPU is not set
# CONFIG_LEDS_TRIGGER_GPIO is not set
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_LEDS_TRIGGER_TRANSIENT is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_PL030 is not set
# CONFIG_RTC_DRV_PL031 is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=m
CONFIG_UIO_PDRV=m
CONFIG_UIO_PDRV_GENIRQ=m
# CONFIG_UIO_DMEM_GENIRQ is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y

#
# Hardware Spinlock drivers
#
# CONFIG_IOMMU_SUPPORT is not set

#
# Remoteproc drivers (EXPERIMENTAL)
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers (EXPERIMENTAL)
#
# CONFIG_VIRT_DRIVERS is not set
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
CONFIG_IIO=y
# CONFIG_IIO_BUFFER is not set
# CONFIG_IIO_TRIGGER is not set

#
# Accelerometers
#

#
# Analog to digital converters
#
# CONFIG_AD7266 is not set
# CONFIG_AD7298 is not set
# CONFIG_AD7791 is not set
# CONFIG_AD7793 is not set
# CONFIG_AD7476 is not set
# CONFIG_AD7887 is not set
# CONFIG_MAX1363 is not set
# CONFIG_TI_ADC081C is not set

#
# Amplifiers
#
# CONFIG_AD8366 is not set

#
# Hid Sensor IIO Common
#

#
# Digital to analog converters
#
# CONFIG_AD5064 is not set
# CONFIG_AD5360 is not set
# CONFIG_AD5380 is not set
# CONFIG_AD5421 is not set
# CONFIG_AD5624R_SPI is not set
# CONFIG_AD5446 is not set
# CONFIG_AD5449 is not set
# CONFIG_AD5504 is not set
# CONFIG_AD5755 is not set
# CONFIG_AD5764 is not set
# CONFIG_AD5791 is not set
# CONFIG_AD5686 is not set
# CONFIG_MAX517 is not set
# CONFIG_MCP4725 is not set

#
# Frequency Synthesizers DDS/PLL
#

#
# Clock Generator/Distribution
#
# CONFIG_AD9523 is not set

#
# Phase-Locked Loop (PLL) frequency synthesizers
#
# CONFIG_ADF4350 is not set

#
# Digital gyroscope sensors
#
# CONFIG_ADIS16136 is not set

#
# Inertial measurement units
#
# CONFIG_ADIS16480 is not set

#
# Light sensors
#
# CONFIG_ADJD_S311 is not set
# CONFIG_VCNL4000 is not set

#
# Magnetometer sensors
#
# CONFIG_PWM is not set
# CONFIG_IPACK_BUS is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
# CONFIG_PRINT_QUOTA_WARNING is not set
# CONFIG_QUOTA_DEBUG is not set
# CONFIG_QFMT_V1 is not set
# CONFIG_QFMT_V2 is not set
CONFIG_QUOTACTL=y
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=m
CONFIG_CUSE=m
CONFIG_GENERIC_ACL=y

#
# Caches
#
CONFIG_FSCACHE=y
# CONFIG_FSCACHE_STATS is not set
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set
CONFIG_CACHEFILES=y
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
CONFIG_SQUASHFS=m
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_SQUASHFS_LZO=y
CONFIG_SQUASHFS_XZ=y
# CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set
# CONFIG_SQUASHFS_EMBEDDED is not set
CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_SWAP is not set
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
CONFIG_NFS_FSCACHE=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_WEAK_PW_HASH=y
# CONFIG_CIFS_UPCALL is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_ACL is not set
# CONFIG_CIFS_DEBUG is not set
# CONFIG_CIFS_DFS_UPCALL is not set
# CONFIG_CIFS_SMB2 is not set
# CONFIG_CIFS_FSCACHE is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=m
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
# CONFIG_IPIPE_DEBUG is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_ARM_UNWIND is not set
# CONFIG_DEBUG_USER is not set
# CONFIG_DEBUG_LL is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
# CONFIG_OC_ETM is not set
# CONFIG_ARM_KPROBES_TEST is not set
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=m

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_GHASH is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_ARM is not set
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_PERCPU_RWSEM=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=m
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_XZ_DEC=m
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set

^ permalink raw reply related	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-26  0:12                                     ` Gregory Dymarek
  2014-02-26  0:22                                       ` Adam Vaughan
@ 2014-02-26  0:33                                       ` Gilles Chanteperdrix
  2014-02-26 10:00                                         ` Gregory Dymarek
  2014-02-26 10:26                                       ` Paul
  2 siblings, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-26  0:33 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/26/2014 01:12 AM, Gregory Dymarek wrote:
> Adam, when i try to boot with a usb mass storage i got also the same
> warning. I'm running with FIQ disabled and on version A board.
> 
> What kernel version are you using Adam? Are there any other patches that
> you enabled?
> 
> I guess this also might be down to the kernel configuration. I'm now
> running with a full debug, don't know if this can affect the result.

If the same issue does not happen without xenomai, then the issue is
most likely due to the I-pipe patch or xenomai. fiq_print is probably
broken if FIQ_DEBUG is enabled, but if you did not enable it, I see
nothing else that could go wrong. So, I would say the I-pipe tracer will
tell us.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-26  0:33                                       ` Gilles Chanteperdrix
@ 2014-02-26 10:00                                         ` Gregory Dymarek
  2014-02-26 18:48                                           ` Adam Vaughan
  2014-02-26 21:46                                           ` Gilles Chanteperdrix
  0 siblings, 2 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-26 10:00 UTC (permalink / raw)
  To: xenomai

I will have a look later on. However this makes me question, why to spend
time fixing old kernel if there are already ipipe patches for 3.10.
Shouldn't we try to do this for the more recent kernel 3.10 so this can be
eventually incorporated into Xenomai? or this not that straight forward?



On 26 February 2014 00:33, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/26/2014 01:12 AM, Gregory Dymarek wrote:
> > Adam, when i try to boot with a usb mass storage i got also the same
> > warning. I'm running with FIQ disabled and on version A board.
> >
> > What kernel version are you using Adam? Are there any other patches that
> > you enabled?
> >
> > I guess this also might be down to the kernel configuration. I'm now
> > running with a full debug, don't know if this can affect the result.
>
> If the same issue does not happen without xenomai, then the issue is
> most likely due to the I-pipe patch or xenomai. fiq_print is probably
> broken if FIQ_DEBUG is enabled, but if you did not enable it, I see
> nothing else that could go wrong. So, I would say the I-pipe tracer will
> tell us.
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-26  0:12                                     ` Gregory Dymarek
  2014-02-26  0:22                                       ` Adam Vaughan
  2014-02-26  0:33                                       ` Gilles Chanteperdrix
@ 2014-02-26 10:26                                       ` Paul
  2 siblings, 0 replies; 61+ messages in thread
From: Paul @ 2014-02-26 10:26 UTC (permalink / raw)
  To: xenomai

On Wednesday 26 February 2014, Gregory Dymarek wrote:
> I guess this also might be down to the kernel configuration. I'm now
> running with a full debug, don't know if this can affect the result.

Can you guys email me your .config files - I'll take a look at them, 
compare to the minimal config I use and see if I can replicate the 
problem here.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-26 10:00                                         ` Gregory Dymarek
@ 2014-02-26 18:48                                           ` Adam Vaughan
  2014-02-26 21:46                                           ` Gilles Chanteperdrix
  1 sibling, 0 replies; 61+ messages in thread
From: Adam Vaughan @ 2014-02-26 18:48 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

> I will have a look later on. However this makes me question, why to spend
> time fixing old kernel if there are already ipipe patches for 3.10.
> Shouldn't we try to do this for the more recent kernel 3.10 so this can be
> eventually incorporated into Xenomai? or this not that straight forward?

Using a recent 3.10 version would be the most ideal solution as it
ostensibly includes fixes for heavy SD card access issues I was
seeing, the USB FIQ disable fix, and any other mainline issues people
were seeing since the 3.8 branch isn't really being maintained by the
Raspberry Pi foundation.  I believe it would need the patch that
Gilles and you figured out a few emails back.

The only problem is that I've never made a patch of that magnitude.
That said, I imagine it'd be similar to the 3.8 one that Paul made.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-26 10:00                                         ` Gregory Dymarek
  2014-02-26 18:48                                           ` Adam Vaughan
@ 2014-02-26 21:46                                           ` Gilles Chanteperdrix
  1 sibling, 0 replies; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-26 21:46 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/26/2014 11:00 AM, Gregory Dymarek wrote:
> I will have a look later on. However this makes me question, why to spend
> time fixing old kernel if there are already ipipe patches for 3.10.
> Shouldn't we try to do this for the more recent kernel 3.10 so this can be
> eventually incorporated into Xenomai? or this not that straight forward?

Well, the local_fiq_enable/local_fiq_disable fix will apply to 3.10 as
well, and chances are that the second issue is there on 3.10, since it
has not been fixed.


-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
       [not found]                                     ` <530E6159.4050204@xenomai.org>
@ 2014-02-26 22:37                                       ` Gregory Dymarek
  2014-02-27 10:48                                         ` Gilles Chanteperdrix
  0 siblings, 1 reply; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-26 22:37 UTC (permalink / raw)
  To: xenomai

Right,
here is updated trace:
http://pastebin.com/FW6i2Gds

there is unstall root call on line 39
followed by read_current_timer at line 88

if I understand this well read_current_timer fails with bad_irq?


On 26 February 2014 21:49, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/26/2014 08:59 PM, Gregory Dymarek wrote:
> > Gilles
> > here is the ipipe trace (see line 112)
> > http://pastebin.com/EcLn0MxJ
>
> There is not enough details on the trace, you should put it before the
> trace dumps, or increase the number of trace points. Because the only
> thing we see is the trace dump.
>
> >
> > that corresponds to
> > http://pastebin.com/vjLJVDGS
> >
> > I do not see any call to enable irq, but there are plenty calls for
> debug.
> >
> >
> > Could you also explain in a few words the previous patch please.
> > What was wrong with local_fiq_disable() defined as ipipe_stall_root() ?
>
> It was wrong because fiqs are not pipelined, so it does not make sense
> to use ipipe_stall_root/ipipe_unstall_root to disable and enable them.
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-26 22:37                                       ` Gregory Dymarek
@ 2014-02-27 10:48                                         ` Gilles Chanteperdrix
  2014-02-27 18:43                                           ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-27 10:48 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/26/2014 11:37 PM, Gregory Dymarek wrote:
> Right,
> here is updated trace:
> http://pastebin.com/FW6i2Gds
> 
> there is unstall root call on line 39
> followed by read_current_timer at line 88
> 
> if I understand this well read_current_timer fails with bad_irq?

I would say the driver interrupt handler does not acknowledge the
interrupt correctly at device level, so that the interrupt triggers
again, as soon as it is unmasked at interrupt controller level.

Could you take a trace with say 10000 points, in order to confirm this?

To add trace points, use

echo 10000 > /proc/ipipe/trace/back_trace_points

To save the trace to a file use:

cat /proc/ipipe/trace/frozen > frozen.txt

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-27 10:48                                         ` Gilles Chanteperdrix
@ 2014-02-27 18:43                                           ` Gregory Dymarek
  2014-02-27 20:14                                             ` Gilles Chanteperdrix
  0 siblings, 1 reply; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-27 18:43 UTC (permalink / raw)
  To: xenomai

Here is the trace with 10000 points:
https://github.com/gregd72002/rpicopter/blob/master/tmp/frozen



On 27 February 2014 10:48, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/26/2014 11:37 PM, Gregory Dymarek wrote:
> > Right,
> > here is updated trace:
> > http://pastebin.com/FW6i2Gds
> >
> > there is unstall root call on line 39
> > followed by read_current_timer at line 88
> >
> > if I understand this well read_current_timer fails with bad_irq?
>
> I would say the driver interrupt handler does not acknowledge the
> interrupt correctly at device level, so that the interrupt triggers
> again, as soon as it is unmasked at interrupt controller level.
>
> Could you take a trace with say 10000 points, in order to confirm this?
>
> To add trace points, use
>
> echo 10000 > /proc/ipipe/trace/back_trace_points
>
> To save the trace to a file use:
>
> cat /proc/ipipe/trace/frozen > frozen.txt
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-27 18:43                                           ` Gregory Dymarek
@ 2014-02-27 20:14                                             ` Gilles Chanteperdrix
  2014-02-27 20:33                                               ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-27 20:14 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/27/2014 07:43 PM, Gregory Dymarek wrote:
> Here is the trace with 10000 points:
> https://github.com/gregd72002/rpicopter/blob/master/tmp/frozen

Unfortunately, we do not have the beginning of the event. Could you put
the trace freeze at the first call to report_bad_irq (i.e. not wait for
the message)?


-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-27 20:14                                             ` Gilles Chanteperdrix
@ 2014-02-27 20:33                                               ` Gregory Dymarek
  2014-02-27 20:48                                                 ` Gilles Chanteperdrix
                                                                   ` (2 more replies)
  0 siblings, 3 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-27 20:33 UTC (permalink / raw)
  To: xenomai

Not sure if I understand this. This is the first call to __report_bad_irq (
https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/spurious.c )

I added the trace on line 192.

AFAIK this is the first call to the function. the trace freeze i added is
not conditional.




On 27 February 2014 20:14, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/27/2014 07:43 PM, Gregory Dymarek wrote:
> > Here is the trace with 10000 points:
> > https://github.com/gregd72002/rpicopter/blob/master/tmp/frozen
>
> Unfortunately, we do not have the beginning of the event. Could you put
> the trace freeze at the first call to report_bad_irq (i.e. not wait for
> the message)?
>
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-27 20:33                                               ` Gregory Dymarek
@ 2014-02-27 20:48                                                 ` Gilles Chanteperdrix
  2014-02-27 20:58                                                   ` Gilles Chanteperdrix
  2014-02-27 21:15                                                 ` Gilles Chanteperdrix
  2014-02-28 11:41                                                 ` Gilles Chanteperdrix
  2 siblings, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-27 20:48 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/27/2014 09:33 PM, Gregory Dymarek wrote:
> Not sure if I understand this. This is the first call to __report_bad_irq (
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/spurious.c )
> 
> I added the trace on line 192.
> 
> AFAIK this is the first call to the function. the trace freeze i added is
> not conditional.

__report_bad_irq is called when report_bad_irq has been called 100
times. Could you put the trace freeze in report_bad_irq instead of
__report_bad_irq ?


-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-27 20:48                                                 ` Gilles Chanteperdrix
@ 2014-02-27 20:58                                                   ` Gilles Chanteperdrix
  0 siblings, 0 replies; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-27 20:58 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/27/2014 09:48 PM, Gilles Chanteperdrix wrote:
> On 02/27/2014 09:33 PM, Gregory Dymarek wrote:
>> Not sure if I understand this. This is the first call to __report_bad_irq (
>> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/spurious.c )
>>
>> I added the trace on line 192.
>>
>> AFAIK this is the first call to the function. the trace freeze i added is
>> not conditional.
> 
> __report_bad_irq is called when report_bad_irq has been called 100
> times. Could you put the trace freeze in report_bad_irq instead of
> __report_bad_irq ?

Sorry, no, that is not how it works.
-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-27 20:33                                               ` Gregory Dymarek
  2014-02-27 20:48                                                 ` Gilles Chanteperdrix
@ 2014-02-27 21:15                                                 ` Gilles Chanteperdrix
  2014-02-27 22:54                                                   ` Gregory Dymarek
  2014-02-28  1:12                                                   ` Paul
  2014-02-28 11:41                                                 ` Gilles Chanteperdrix
  2 siblings, 2 replies; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-27 21:15 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/27/2014 09:33 PM, Gregory Dymarek wrote:
> Not sure if I understand this. This is the first call to __report_bad_irq (
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/spurious.c )
> 
> I added the trace on line 192.
> 
> AFAIK this is the first call to the function. the trace freeze i added is
> not conditional.

I am looking at the "post" patch for Raspberry, and I do not see that 
it touches drivers/irqchip/irq-bcm2835.c

Here the calls to handle_IRQ are not replaced with ipipe calls, this 
can not work.

See:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Interrupt_controller

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-27 21:15                                                 ` Gilles Chanteperdrix
@ 2014-02-27 22:54                                                   ` Gregory Dymarek
  2014-02-28  1:12                                                   ` Paul
  1 sibling, 0 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-27 22:54 UTC (permalink / raw)
  To: xenomai

right, i think i see it.

Up to and including kernel version 3.6 there was no handle_irq abstraction:
https://github.com/raspberrypi/linux/blob/rpi-3.2.27/arch/arm/mach-bcm2708/bcm2708.c

handle_irq was introduced in 3.8 and as such this is not getting patched.


On 27 February 2014 21:15, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/27/2014 09:33 PM, Gregory Dymarek wrote:
> > Not sure if I understand this. This is the first call to
> __report_bad_irq (
> >
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/spurious.c)
> >
> > I added the trace on line 192.
> >
> > AFAIK this is the first call to the function. the trace freeze i added is
> > not conditional.
>
> I am looking at the "post" patch for Raspberry, and I do not see that
> it touches drivers/irqchip/irq-bcm2835.c
>
> Here the calls to handle_IRQ are not replaced with ipipe calls, this
> can not work.
>
> See:
>
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Interrupt_controller
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-27 21:15                                                 ` Gilles Chanteperdrix
  2014-02-27 22:54                                                   ` Gregory Dymarek
@ 2014-02-28  1:12                                                   ` Paul
  2014-02-28 11:42                                                     ` Gilles Chanteperdrix
  1 sibling, 1 reply; 61+ messages in thread
From: Paul @ 2014-02-28  1:12 UTC (permalink / raw)
  To: xenomai

On Thursday 27 February 2014, Gilles Chanteperdrix wrote:
> I am looking at the "post" patch for Raspberry, and I do not see that
> it touches drivers/irqchip/irq-bcm2835.c
>
> Here the calls to handle_IRQ are not replaced with ipipe calls, this
> can not work.

It is somewhat confusing that there are two sets of code for the 
Raspberry Pi chip. bcm2708* is the original code as used by 
the "official" RPi kernel and is found in the 
github.com/raspberrypi/linux tree.

For the mainline kernel, for various reasons, it was decided that the 
bcm2835 prefix would be used for the RPi SoC - Having two sets of 
sources for one SoC can be somewhat confusing.

drivers/irqchip/irq-bcm2835.c doesn't get compiled for the Raspberry Pi 
kernel - Instead, one should look at arch/arm/mach-bcm2708/armctrl.c

> See:
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Interrupt_con
>troller


Regards, Paul.




^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-27 20:33                                               ` Gregory Dymarek
  2014-02-27 20:48                                                 ` Gilles Chanteperdrix
  2014-02-27 21:15                                                 ` Gilles Chanteperdrix
@ 2014-02-28 11:41                                                 ` Gilles Chanteperdrix
  2014-03-01 12:27                                                   ` Gregory Dymarek
  2 siblings, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-28 11:41 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 02/27/2014 09:33 PM, Gregory Dymarek wrote:
> Not sure if I understand this. This is the first call to __report_bad_irq (
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/spurious.c )
> 
> I added the trace on line 192.
> 
> AFAIK this is the first call to the function. the trace freeze i added is
> not conditional.

I think the issue you observe is that the irqs_unhandled counter goes
over 99000, meaning that the driver returns IRQ_NONE and does not
acknowledge the interrupt at device level, so that the interrupt
triggers again. So, having enough trace points to see what happens
before this irq storm will be hard. Could you try reducing the 100000
and 99000 thresholds in kernel/irq/spurious.c, function note_interrupt?

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-28  1:12                                                   ` Paul
@ 2014-02-28 11:42                                                     ` Gilles Chanteperdrix
  0 siblings, 0 replies; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-28 11:42 UTC (permalink / raw)
  To: Paul; +Cc: xenomai

On 02/28/2014 02:12 AM, Paul wrote:
> On Thursday 27 February 2014, Gilles Chanteperdrix wrote:
>> I am looking at the "post" patch for Raspberry, and I do not see that
>> it touches drivers/irqchip/irq-bcm2835.c
>>
>> Here the calls to handle_IRQ are not replaced with ipipe calls, this
>> can not work.
> 
> It is somewhat confusing that there are two sets of code for the 
> Raspberry Pi chip. bcm2708* is the original code as used by 
> the "official" RPi kernel and is found in the 
> github.com/raspberrypi/linux tree.
> 
> For the mainline kernel, for various reasons, it was decided that the 
> bcm2835 prefix would be used for the RPi SoC - Having two sets of 
> sources for one SoC can be somewhat confusing.
> 
> drivers/irqchip/irq-bcm2835.c doesn't get compiled for the Raspberry Pi 
> kernel - Instead, one should look at arch/arm/mach-bcm2708/armctrl.c

Ok, thanks.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-28 11:41                                                 ` Gilles Chanteperdrix
@ 2014-03-01 12:27                                                   ` Gregory Dymarek
  2014-03-02 15:11                                                     ` Gilles Chanteperdrix
  0 siblings, 1 reply; 61+ messages in thread
From: Gregory Dymarek @ 2014-03-01 12:27 UTC (permalink / raw)
  To: xenomai

Hi Gilles,

Uploaded a new trace in here with them being reduced to 10 and 9
respectively:
 https://github.com/gregd72002/rpicopter/blob/master/tmp/frozen



On 28 February 2014 11:41, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/27/2014 09:33 PM, Gregory Dymarek wrote:
> > Not sure if I understand this. This is the first call to
> __report_bad_irq (
> >
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/kernel/irq/spurious.c)
> >
> > I added the trace on line 192.
> >
> > AFAIK this is the first call to the function. the trace freeze i added is
> > not conditional.
>
> I think the issue you observe is that the irqs_unhandled counter goes
> over 99000, meaning that the driver returns IRQ_NONE and does not
> acknowledge the interrupt at device level, so that the interrupt
> triggers again. So, having enough trace points to see what happens
> before this irq storm will be hard. Could you try reducing the 100000
> and 99000 thresholds in kernel/irq/spurious.c, function note_interrupt?
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-03-01 12:27                                                   ` Gregory Dymarek
@ 2014-03-02 15:11                                                     ` Gilles Chanteperdrix
  2014-03-02 17:26                                                       ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-02 15:11 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 03/01/2014 01:27 PM, Gregory Dymarek wrote:
> Hi Gilles,
> 
> Uploaded a new trace in here with them being reduced to 10 and 9
> respectively:
>  https://github.com/gregd72002/rpicopter/blob/master/tmp/frozen

Hi Gregory,

we see what happens before the irq storm, but unfortunately, this looks
like the USB driver is at fault. A transfer is programmed, a little bit
later the irq is received while the root domain is stalled, so is
logged, a little bit later the root domain is unstalled and the log
played, at the end it is unmasked and it triggers again. From the error
that occur we know that the irq handler returned IRQ_NONE, so did not
acknowledged the irq at device level, so it makes perfect sense that the
irq triggers again.

In order to go further, we would have to understand how the driver
works, but it is something that is hard to do by proxy.

The question is: are you sure that the same issue does not happen with
the exact same configuration, except without Xenomai (and without
CONFIG_IPIPE)?

Regards.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-03-02 15:11                                                     ` Gilles Chanteperdrix
@ 2014-03-02 17:26                                                       ` Gregory Dymarek
  2014-03-02 18:05                                                         ` Gilles Chanteperdrix
  2014-03-02 18:16                                                         ` Gilles Chanteperdrix
  0 siblings, 2 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-03-02 17:26 UTC (permalink / raw)
  To: xenomai

So I started from scratch, have not used any xenomai/ipipe patches. But
used the same .config.
As a result all worked fine. The USB device is getting initialized
correctly.

So the current situation is that xenomai does work on 3.2 but does not on
3.8 because of some USB driver issues.
I diff'ed the code for dwc_otg_hcd_handle_intr and this has changed.
What is intriguing:
https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c#L530

// We should be OK doing this because the common interrupts should already
have been serviced

So I removed all the DEBUG code from this function, but this did not help
either. Not sure if my test is valid in here.



On 2 March 2014 15:11, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 03/01/2014 01:27 PM, Gregory Dymarek wrote:
> > Hi Gilles,
> >
> > Uploaded a new trace in here with them being reduced to 10 and 9
> > respectively:
> >  https://github.com/gregd72002/rpicopter/blob/master/tmp/frozen
>
> Hi Gregory,
>
> we see what happens before the irq storm, but unfortunately, this looks
> like the USB driver is at fault. A transfer is programmed, a little bit
> later the irq is received while the root domain is stalled, so is
> logged, a little bit later the root domain is unstalled and the log
> played, at the end it is unmasked and it triggers again. From the error
> that occur we know that the irq handler returned IRQ_NONE, so did not
> acknowledged the irq at device level, so it makes perfect sense that the
> irq triggers again.
>
> In order to go further, we would have to understand how the driver
> works, but it is something that is hard to do by proxy.
>
> The question is: are you sure that the same issue does not happen with
> the exact same configuration, except without Xenomai (and without
> CONFIG_IPIPE)?
>
> Regards.
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-03-02 17:26                                                       ` Gregory Dymarek
@ 2014-03-02 18:05                                                         ` Gilles Chanteperdrix
  2014-03-02 18:16                                                         ` Gilles Chanteperdrix
  1 sibling, 0 replies; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-02 18:05 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 03/02/2014 06:26 PM, Gregory Dymarek wrote:
> So I started from scratch, have not used any xenomai/ipipe patches. But
> used the same .config.
> As a result all worked fine. The USB device is getting initialized
> correctly.
> 
> So the current situation is that xenomai does work on 3.2 but does not on
> 3.8 because of some USB driver issues.
> I diff'ed the code for dwc_otg_hcd_handle_intr and this has changed.
> What is intriguing:
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c#L530
> 
> // We should be OK doing this because the common interrupts should already
> have been serviced
> 
> So I removed all the DEBUG code from this function, but this did not help
> either. Not sure if my test is valid in here.

As I said, I believe there is now no substitute to understanding how the
driver works if you want to debug the issue on 3.8. The problem to
understand is why the interrupt handler does nothing and returns
IRQ_NONE instead of acknowledging the interrupt and returning IRQ_HANDLED.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-03-02 17:26                                                       ` Gregory Dymarek
  2014-03-02 18:05                                                         ` Gilles Chanteperdrix
@ 2014-03-02 18:16                                                         ` Gilles Chanteperdrix
       [not found]                                                           ` <CAEbDrg=2nX1kKOGt6i7b-w5AsLXkEyoJCGUMw1dkMXvka4MeKw@mail.gmail.com>
  1 sibling, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-02 18:16 UTC (permalink / raw)
  To: Gregory Dymarek; +Cc: xenomai

On 03/02/2014 06:26 PM, Gregory Dymarek wrote:
> So I started from scratch, have not used any xenomai/ipipe patches. But
> used the same .config.
> As a result all worked fine. The USB device is getting initialized
> correctly.
> 
> So the current situation is that xenomai does work on 3.2 but does not on
> 3.8 because of some USB driver issues.
> I diff'ed the code for dwc_otg_hcd_handle_intr and this has changed.
> What is intriguing:
> https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c#L530
> 
> // We should be OK doing this because the common interrupts should already
> have been serviced
> 
> So I removed all the DEBUG code from this function, but this did not help
> either. Not sure if my test is valid in here.

If the driver relies on FIQ to work (which is a bad idea with Xenomai, 
as it will cause an increase in latencies), the following construction:


local_irq_save(flags);
local_fiq_disable();

/* do something */

local_irq_restore(flags);

Will mask the FIQ with CONFIG_IPIPE whereas local_irq_restore unmasks 
both the IRQ and FIQ without CONFIG_IPIPE. 

So, as a last try before giving up, could you try the following patch?

diff --git a/drivers/usb/host/dwc_common_port/dwc_common_linux.c b/drivers/usb/host/dwc_common_port/dwc_common_linux.c
index 0812d3a..6d01261 100644
--- a/drivers/usb/host/dwc_common_port/dwc_common_linux.c
+++ b/drivers/usb/host/dwc_common_port/dwc_common_linux.c
@@ -585,6 +585,7 @@ void DWC_MODIFY_REG32(uint32_t volatile *reg, uint32_t clear_mask, uint32_t set_
 	local_irq_save(flags);
 	local_fiq_disable();
 	writel((readl(reg) & ~clear_mask) | set_mask, reg);
+	local_fiq_enable();
 	local_irq_restore(flags);
 }
 
diff --git a/drivers/usb/host/dwc_otg/dwc_otg_cil_intr.c b/drivers/usb/host/dwc_otg/dwc_otg_cil_intr.c
index b5a007d..10eead2 100644
--- a/drivers/usb/host/dwc_otg/dwc_otg_cil_intr.c
+++ b/drivers/usb/host/dwc_otg/dwc_otg_cil_intr.c
@@ -1354,6 +1354,7 @@ static inline uint32_t dwc_otg_read_common_intr(dwc_otg_core_if_t * core_if, gin
 		gintmsk.d32 |= gintmsk_common.d32;
 		gintsts_saved.d32 &= ~gintmsk_common.d32;
 		reenable_gintmsk->d32 = gintmsk.d32;
+		local_fiq_enable();
 		local_irq_restore(flags);
 	}
 
diff --git a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
index 7d521d9..86d9cbe 100644
--- a/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
+++ b/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
@@ -97,6 +97,7 @@ void notrace _fiq_print(FIQDBG_T dbg_lvl, char *fmt, ...)
 		memcpy(buffer + wptr, text, 16);
 		wptr = (wptr + 16) % sizeof(buffer);
 	}
+	local_fiq_enable();
 	local_irq_restore(flags);
 }
 #endif


-- 
                                                                Gilles.


^ permalink raw reply related	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
       [not found]                                                           ` <CAEbDrg=2nX1kKOGt6i7b-w5AsLXkEyoJCGUMw1dkMXvka4MeKw@mail.gmail.com>
@ 2014-03-02 18:55                                                             ` Gregory Dymarek
  2014-03-02 18:57                                                             ` Gilles Chanteperdrix
  1 sibling, 0 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-03-02 18:55 UTC (permalink / raw)
  To: xenomai

This works!!

I thought xenomai does not deal with fiq. Why is it required to enable them
in the driver when having xenomai on?

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
       [not found]                                                           ` <CAEbDrg=2nX1kKOGt6i7b-w5AsLXkEyoJCGUMw1dkMXvka4MeKw@mail.gmail.com>
  2014-03-02 18:55                                                             ` Gregory Dymarek
@ 2014-03-02 18:57                                                             ` Gilles Chanteperdrix
  2014-03-02 19:04                                                               ` Gilles Chanteperdrix
  1 sibling, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-02 18:57 UTC (permalink / raw)
  To: Gregory Dymarek, Xenomai

On 03/02/2014 07:54 PM, Gregory Dymarek wrote:
> This works!!
> 
> I thought xenomai does not deal with fiq. Why is it required to enable them
> in the driver when having xenomai on?

Because without CONFIG_IPIPE local_irq_restore deals with FIQs
With CONFIG_IPIPE local_irq_restore does not deal with FIQs

We can of course rework local_irq_restore to take into account FIQs with
CONFIG_IPIPE, but that would make local_irq_restore heavier in a lot of
places, whereas there are in fact only three spots to fix, for only one SOC.


-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-03-02 18:57                                                             ` Gilles Chanteperdrix
@ 2014-03-02 19:04                                                               ` Gilles Chanteperdrix
  2014-03-02 19:08                                                                 ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Gilles Chanteperdrix @ 2014-03-02 19:04 UTC (permalink / raw)
  To: Gregory Dymarek, Xenomai

On 03/02/2014 07:57 PM, Gilles Chanteperdrix wrote:
> On 03/02/2014 07:54 PM, Gregory Dymarek wrote:
>> This works!!
>>
>> I thought xenomai does not deal with fiq. Why is it required to enable them
>> in the driver when having xenomai on?
> 
> Because without CONFIG_IPIPE local_irq_restore deals with FIQs
> With CONFIG_IPIPE local_irq_restore does not deal with FIQs
> 
> We can of course rework local_irq_restore to take into account FIQs with
> CONFIG_IPIPE, but that would make local_irq_restore heavier in a lot of
> places, whereas there are in fact only three spots to fix, for only one SOC.
> 
> 
BTW, using FIQs for USB means that USB activity will be able to
influence xenomai latencies. So, it is really not recommended, if there
is a configuration option for disabling the use of FIQ with this driver,
this should be recommended for use with xenomai.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-03-02 19:04                                                               ` Gilles Chanteperdrix
@ 2014-03-02 19:08                                                                 ` Gregory Dymarek
  2014-03-02 21:03                                                                   ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Gregory Dymarek @ 2014-03-02 19:08 UTC (permalink / raw)
  To: xenomai

Understood. I will have a look.

I'll be getting kernel 3.10 in a moment. It looks like USB driver is
different to the one in 3.8.
Will see what it does.

Overall, there has been a lot of debate around the USB driver on this SOC
so you might be right that the driver is not working as it is supposed to.
Not yet at least.



On 2 March 2014 19:04, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 03/02/2014 07:57 PM, Gilles Chanteperdrix wrote:
> > On 03/02/2014 07:54 PM, Gregory Dymarek wrote:
> >> This works!!
> >>
> >> I thought xenomai does not deal with fiq. Why is it required to enable
> them
> >> in the driver when having xenomai on?
> >
> > Because without CONFIG_IPIPE local_irq_restore deals with FIQs
> > With CONFIG_IPIPE local_irq_restore does not deal with FIQs
> >
> > We can of course rework local_irq_restore to take into account FIQs with
> > CONFIG_IPIPE, but that would make local_irq_restore heavier in a lot of
> > places, whereas there are in fact only three spots to fix, for only one
> SOC.
> >
> >
> BTW, using FIQs for USB means that USB activity will be able to
> influence xenomai latencies. So, it is really not recommended, if there
> is a configuration option for disabling the use of FIQ with this driver,
> this should be recommended for use with xenomai.
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-03-02 19:08                                                                 ` Gregory Dymarek
@ 2014-03-02 21:03                                                                   ` Gregory Dymarek
  0 siblings, 0 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-03-02 21:03 UTC (permalink / raw)
  To: xenomai

3.10 does not require the USB patch. It just requires the the ealier patch
where local_fiq_* are defined as hard_local_fiq_*

When I searched the USB issue around the net I found the explanation for
using FIQ in USB driver on this board:
http://hwswbits.blogspot.co.uk/2013/09/dwc-usb-interrupt-spam-in-rockchip-socs.html

"the Synopsys driver relies on the start of frame interrupt for scheduling
transfers if "descriptor DMA" is not implemented (which it isn't, on
BCM2835).  8000 is one interrupt per microframe."

A solution in 3.8 was to use FIQ for USB IRQs to discard USB microframes
that contain no data.

All clear now. Thanks Gilles.


On 2 March 2014 19:08, Gregory Dymarek <gregd72002@gmail.com> wrote:

> Understood. I will have a look.
>
> I'll be getting kernel 3.10 in a moment. It looks like USB driver is
> different to the one in 3.8.
> Will see what it does.
>
> Overall, there has been a lot of debate around the USB driver on this SOC
> so you might be right that the driver is not working as it is supposed to.
> Not yet at least.
>
>
>
> On 2 March 2014 19:04, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
>
>> On 03/02/2014 07:57 PM, Gilles Chanteperdrix wrote:
>> > On 03/02/2014 07:54 PM, Gregory Dymarek wrote:
>> >> This works!!
>> >>
>> >> I thought xenomai does not deal with fiq. Why is it required to enable
>> them
>> >> in the driver when having xenomai on?
>> >
>> > Because without CONFIG_IPIPE local_irq_restore deals with FIQs
>> > With CONFIG_IPIPE local_irq_restore does not deal with FIQs
>> >
>> > We can of course rework local_irq_restore to take into account FIQs with
>> > CONFIG_IPIPE, but that would make local_irq_restore heavier in a lot of
>> > places, whereas there are in fact only three spots to fix, for only one
>> SOC.
>> >
>> >
>> BTW, using FIQs for USB means that USB activity will be able to
>> influence xenomai latencies. So, it is really not recommended, if there
>> is a configuration option for disabling the use of FIQ with this driver,
>> this should be recommended for use with xenomai.
>>
>> --
>>                                                                 Gilles.
>>
>
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
  2014-02-26 19:59 Gregory Dymarek
@ 2014-02-26 20:29 ` Gregory Dymarek
  0 siblings, 0 replies; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-26 20:29 UTC (permalink / raw)
  To: xenomai

Here is one more ipipe trace with less garbage:
http://pastebin.com/WG80f6cx

This happened when i plug usb device after boot is complete


On 26 February 2014 19:59, Gregory Dymarek <gregd72002@gmail.com> wrote:

>
> Gilles
> here is the ipipe trace (see line 112)
> http://pastebin.com/EcLn0MxJ
>
> that corresponds to
> http://pastebin.com/vjLJVDGS
>
> I do not see any call to enable irq, but there are plenty calls for debug.
>
>
> Could you also explain in a few words the previous patch please.
> What was wrong with local_fiq_disable() defined as ipipe_stall_root() ?
>
> Thanks
>
>
> On 25 February 2014 23:51, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
>
>> On 02/26/2014 12:20 AM, Gregory Dymarek wrote:
>> > well, this does not work for me. It boots fine when there is no USB
>> device
>> > plugged in.
>> > However, when my WIFI or bluetooth adapter is plugged in, the boot log
>> > shows: http://pastebin.com/vjLJVDGS
>>
>> Well, it looks like a different issue, which happens when irqs are
>> re-enabled by DWC_SPINUNLOCK_IRQRESTORE. So, maybe we have progressed. I
>> am cloning the rpi repository, to see what happens at this point.
>>
>> But you can try and use the I-pipe tracer again, put a trace freeze in
>> the "report_bad_irq" function.
>>
>> --
>>                                                                 Gilles.
>>
>
>
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [Xenomai] RaspberryPi kernel 3.8 issue
@ 2014-02-26 19:59 Gregory Dymarek
  2014-02-26 20:29 ` Gregory Dymarek
  0 siblings, 1 reply; 61+ messages in thread
From: Gregory Dymarek @ 2014-02-26 19:59 UTC (permalink / raw)
  To: xenomai

Gilles
here is the ipipe trace (see line 112)
http://pastebin.com/EcLn0MxJ

that corresponds to
http://pastebin.com/vjLJVDGS

I do not see any call to enable irq, but there are plenty calls for debug.


Could you also explain in a few words the previous patch please.
What was wrong with local_fiq_disable() defined as ipipe_stall_root() ?

Thanks


On 25 February 2014 23:51, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 02/26/2014 12:20 AM, Gregory Dymarek wrote:
> > well, this does not work for me. It boots fine when there is no USB
> device
> > plugged in.
> > However, when my WIFI or bluetooth adapter is plugged in, the boot log
> > shows: http://pastebin.com/vjLJVDGS
>
> Well, it looks like a different issue, which happens when irqs are
> re-enabled by DWC_SPINUNLOCK_IRQRESTORE. So, maybe we have progressed. I
> am cloning the rpi repository, to see what happens at this point.
>
> But you can try and use the I-pipe tracer again, put a trace freeze in
> the "report_bad_irq" function.
>
> --
>                                                                 Gilles.
>

^ permalink raw reply	[flat|nested] 61+ messages in thread

end of thread, other threads:[~2014-03-02 21:03 UTC | newest]

Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-23 21:27 [Xenomai] RaspberryPi kernel 3.8 issue Gregory Dymarek
2014-02-23 21:37 ` Gilles Chanteperdrix
2014-02-23 22:18   ` Gregory Dymarek
2014-02-23 22:36     ` Gilles Chanteperdrix
2014-02-23 22:37 ` Adam Vaughan
2014-02-23 23:08   ` Adam Vaughan
2014-02-23 23:30     ` Gregory Dymarek
2014-02-23 23:32       ` Gregory Dymarek
2014-02-23 23:42       ` Gilles Chanteperdrix
2014-02-24 21:19         ` Gregory Dymarek
2014-02-24 22:00           ` Gilles Chanteperdrix
2014-02-25 20:04             ` Gregory Dymarek
2014-02-25 20:20               ` Gilles Chanteperdrix
2014-02-25 20:23                 ` Gregory Dymarek
     [not found]                 ` <CAEbDrgkJCnbWu_J4svoXOU1x2rz=n95A5+3Ee=R_9CpMgx-JmA@mail.gmail.com>
2014-02-25 20:25                   ` Gilles Chanteperdrix
2014-02-25 20:43                     ` Gregory Dymarek
2014-02-25 20:50                       ` Gilles Chanteperdrix
2014-02-25 21:09                         ` Gregory Dymarek
2014-02-25 21:24                           ` Gilles Chanteperdrix
2014-02-25 21:28                             ` Gilles Chanteperdrix
2014-02-25 21:31                           ` Gilles Chanteperdrix
2014-02-25 22:30                             ` Adam Vaughan
2014-02-25 23:20                               ` Gregory Dymarek
2014-02-25 23:42                                 ` Adam Vaughan
2014-02-25 23:45                                   ` Adam Vaughan
2014-02-26  0:12                                     ` Gregory Dymarek
2014-02-26  0:22                                       ` Adam Vaughan
2014-02-26  0:33                                       ` Gilles Chanteperdrix
2014-02-26 10:00                                         ` Gregory Dymarek
2014-02-26 18:48                                           ` Adam Vaughan
2014-02-26 21:46                                           ` Gilles Chanteperdrix
2014-02-26 10:26                                       ` Paul
2014-02-25 23:51                                 ` Gilles Chanteperdrix
     [not found]                                   ` <CAEbDrgkWZqSxjCUfjR3YCp=YOzh1r-=YC6Wyr-Jvk9d7JYEcmQ@mail.gmail.com>
     [not found]                                     ` <530E6159.4050204@xenomai.org>
2014-02-26 22:37                                       ` Gregory Dymarek
2014-02-27 10:48                                         ` Gilles Chanteperdrix
2014-02-27 18:43                                           ` Gregory Dymarek
2014-02-27 20:14                                             ` Gilles Chanteperdrix
2014-02-27 20:33                                               ` Gregory Dymarek
2014-02-27 20:48                                                 ` Gilles Chanteperdrix
2014-02-27 20:58                                                   ` Gilles Chanteperdrix
2014-02-27 21:15                                                 ` Gilles Chanteperdrix
2014-02-27 22:54                                                   ` Gregory Dymarek
2014-02-28  1:12                                                   ` Paul
2014-02-28 11:42                                                     ` Gilles Chanteperdrix
2014-02-28 11:41                                                 ` Gilles Chanteperdrix
2014-03-01 12:27                                                   ` Gregory Dymarek
2014-03-02 15:11                                                     ` Gilles Chanteperdrix
2014-03-02 17:26                                                       ` Gregory Dymarek
2014-03-02 18:05                                                         ` Gilles Chanteperdrix
2014-03-02 18:16                                                         ` Gilles Chanteperdrix
     [not found]                                                           ` <CAEbDrg=2nX1kKOGt6i7b-w5AsLXkEyoJCGUMw1dkMXvka4MeKw@mail.gmail.com>
2014-03-02 18:55                                                             ` Gregory Dymarek
2014-03-02 18:57                                                             ` Gilles Chanteperdrix
2014-03-02 19:04                                                               ` Gilles Chanteperdrix
2014-03-02 19:08                                                                 ` Gregory Dymarek
2014-03-02 21:03                                                                   ` Gregory Dymarek
2014-02-24  0:22       ` Paul
2014-02-24  0:47         ` Adam Vaughan
2014-02-24  0:53           ` Adam Vaughan
2014-02-24  1:20             ` Adam Vaughan
2014-02-26 19:59 Gregory Dymarek
2014-02-26 20:29 ` Gregory Dymarek

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.