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
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 wi
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 happ
I forgot to add the *.txt extension to the above, sorry about that.
On Tue, Feb 25, 2014 at 6:42 PM, Adam Vaughan 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 is
\
> >>
> >>
> >> --
> >> Gilles.
> >>
> >> ___
> >> Xenomai mailing list
> >> X
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:
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
The following changes since commit 21c98d8c4e2ce4320f688163570dab9b11da55c1:
doc: provide details about the new registry hierarchy (2014-02-21 17:31:27
+0100)
are available in the git repository at:
git://git.xenomai.org/xenomai-gch.git for-forge
for you to fetch changes up to 87d6615a4572
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
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://gi
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
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
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
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.ch
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
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
CONFI
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(s
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
On 02/25/2014 06:54 PM, Philippe Gerum wrote:
Hi,
This is the remaining work toward 3.0 from my perspective. Please
comment, amend, extend or shatter as needed.
- RTDM
* decide and freeze API changes.
* the native implementation may need some care and testing, we never
had any
Hi,
This is the remaining work toward 3.0 from my perspective. Please
comment, amend, extend or shatter as needed.
- RTDM
* decide and freeze API changes.
* the native implementation may need some care and testing, we never
had any feedback for this code.
* fixup of in-tree
On Thursday, February 20, 2014 3:19 AM Gilles Chanteperdrix wrote:
> On 02/20/2014 08:47 AM, Wolfgang Grandegger wrote:
>> Am Mi, 19.02.2014, 23:05 schrieb Wayne Ross:
>>> On Wednesday, February 19, 2014 3:16 AM Wolfgang Grandegger wrote:
- What does "/proc/xenomai/irq" list after you have se
On 02/25/2014 10:07 AM, Kim De Mey wrote:
Hello all,
I noticed that when enabling the registry in Xenomai-forge (mercury
core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
spawn_daemon() call.
I guess this choice was made to make sure no zombies of the daemon
stay alive. Correct?
Yes.
On 02/25/2014 01:15 PM, Marcel van Mierlo wrote:
Hi,
I posted this information a few weeks back but got no response...does
anyone have insight on this...I've been digging into the queue
management code in Xenomai but I'm not getting very far...any help on
this would be appreciated as I am not su
On 02/25/2014 02:35 PM, Bruno Tunes de Mello wrote:
Hi Gilles,
I applied this new patch and I got the results below.
This is the complete boot log: http://pastebin.com/YY5pFyaN
Ok, bit 23 seems enabled in the L2 cache auxiliary register, which is
what I wanted to see.
I executed latency
Hi Gilles,
I applied this new patch and I got the results below.
This is the complete boot log: http://pastebin.com/YY5pFyaN
I executed latency and xeno-test some times and the results:
linaro@linaro-alip:/usr/xenomai/bin$ sudo ./latency
== Sampling period: 1000 us
== Test mode: periodic user-m
problem.
Any assistance with this would be appreciated.
Marcel.
-- next part --
A non-text attachment was scrubbed...
Name: qvcreatetest.tar.gz
Type: application/x-gzip
Size: 625 bytes
Desc: not available
URL:
<http://www.xenomai.org/pipermail/xenomai/attachments/20140225/8032fb74/atta
el.
-- next part --
A non-text attachment was scrubbed...
Name: qvcreatetest.tar.gz
Type: application/x-gzip
Size: 625 bytes
Desc: not available
URL:
<http://www.xenomai.org/pipermail/xenomai/attachments/20140225/8032fb74/attachment.bin>
__
On 02/25/2014 04:26 AM, Bruno Tunes de Mello wrote:
> Hi Gilles,
> The kernel is booting and I executed latency and xeno-test commands. The
> results are below.
You also need this patch.
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index d9cb476..1e2c52d 100644
--- a/arch/arm
On 02/25/2014 04:26 AM, Bruno Tunes de Mello wrote:
> Hi Gilles,
> The kernel is booting and I executed latency and xeno-test commands. The
> results are below.
Could you show us the boot logs?
--
Gilles.
_
Hello all,
I noticed that when enabling the registry in Xenomai-forge (mercury
core), that the SIGCHLD gets set to ignore (SIG_IGN) in the
spawn_daemon() call.
I guess this choice was made to make sure no zombies of the daemon
stay alive. Correct?
This does however mean that the default behaviour
30 matches
Mail list logo
