Re: [Xenomai-core] [RTnet-users] Potential problem with rt_eepro100

2010-10-28 Thread Anders Blomdell
Anders Blomdell wrote: Anders Blomdell wrote: Hi, I'm trying to use rt_eepro100, for sending raw ethernet packets, but I'm experincing occasionally weird behaviour. Versions of things: linux-2.6.34.5 xenomai-2.5.5.2 rtnet-39f7fcf The testprogram runs on two computers with Intel

Re: [Xenomai-core] [RTnet-users] Potential problem with rt_eepro100

2010-10-28 Thread Jan Kiszka
Am 28.10.2010 09:34, Anders Blomdell wrote: Anders Blomdell wrote: Anders Blomdell wrote: Hi, I'm trying to use rt_eepro100, for sending raw ethernet packets, but I'm experincing occasionally weird behaviour. Versions of things: linux-2.6.34.5 xenomai-2.5.5.2 rtnet-39f7fcf The

Re: [Xenomai-core] [RTnet-users] Potential problem with rt_eepro100

2010-10-28 Thread Anders Blomdell
Jan Kiszka wrote: Am 28.10.2010 09:34, Anders Blomdell wrote: Anders Blomdell wrote: Anders Blomdell wrote: Hi, I'm trying to use rt_eepro100, for sending raw ethernet packets, but I'm experincing occasionally weird behaviour. Versions of things: linux-2.6.34.5 xenomai-2.5.5.2

Re: [Xenomai-core] [RTnet-users] Potential problem with rt_eepro100

2010-10-28 Thread Jan Kiszka
Am 28.10.2010 11:34, Anders Blomdell wrote: Jan Kiszka wrote: Am 28.10.2010 09:34, Anders Blomdell wrote: Anders Blomdell wrote: Anders Blomdell wrote: Hi, I'm trying to use rt_eepro100, for sending raw ethernet packets, but I'm experincing occasionally weird behaviour. Versions of

Re: [Xenomai-core] Potential problem with rt_eepro100

2010-10-28 Thread Anders Blomdell
Jan Kiszka wrote: Am 28.10.2010 11:34, Anders Blomdell wrote: Jan Kiszka wrote: Am 28.10.2010 09:34, Anders Blomdell wrote: Anders Blomdell wrote: Anders Blomdell wrote: Hi, I'm trying to use rt_eepro100, for sending raw ethernet packets, but I'm experincing occasionally weird behaviour.

Re: [Xenomai-core] Potential problem with rt_eepro100

2010-10-28 Thread Jan Kiszka
Am 28.10.2010 17:05, Anders Blomdell wrote: Current results: 1. 2.6.35.7, maxcpus=1; a few thousand rounds, freeze and this after some time: BUG: spinlock lockup on CPU#0, raw_test/2924, c0a1b540 Process raw_test (pid: 2924, ti=f18bc000 task=f1bdab00 task.ti=f18bc000) I-pipe domain

Re: [Xenomai-core] Potential problem with rt_eepro100

2010-10-28 Thread Jan Kiszka
Am 28.10.2010 17:18, Anders Blomdell wrote: On 2010-10-28 17.09, Jan Kiszka wrote: Am 28.10.2010 17:05, Anders Blomdell wrote: Current results: 1. 2.6.35.7, maxcpus=1; a few thousand rounds, freeze and this after some time: BUG: spinlock lockup on CPU#0, raw_test/2924, c0a1b540 Process

[Xenomai-core] arm: Unprotected access to irq_desc field?

2010-10-28 Thread Jan Kiszka
Gilles, I happened to come across rthal_mark_irq_disabled/enabled on arm. On first glance, it looks like these helpers manipulate irq_desc::status non-atomically, i.e. without holding irq_desc::lock. Isn't this fragile? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence

Re: [Xenomai-core] arm: Unprotected access to irq_desc field?

2010-10-28 Thread Gilles Chanteperdrix
Jan Kiszka wrote: Gilles, I happened to come across rthal_mark_irq_disabled/enabled on arm. On first glance, it looks like these helpers manipulate irq_desc::status non-atomically, i.e. without holding irq_desc::lock. Isn't this fragile? I have no idea. How do the other architectures do? As

Re: [Xenomai-core] arm: Unprotected access to irq_desc field?

2010-10-28 Thread Philippe Gerum
On Thu, 2010-10-28 at 21:15 +0200, Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles, I happened to come across rthal_mark_irq_disabled/enabled on arm. On first glance, it looks like these helpers manipulate irq_desc::status non-atomically, i.e. without holding irq_desc::lock. Isn't

Re: [Xenomai-core] arm: Unprotected access to irq_desc field?

2010-10-28 Thread Gilles Chanteperdrix
Jan Kiszka wrote: Gilles, I happened to come across rthal_mark_irq_disabled/enabled on arm. On first glance, it looks like these helpers manipulate irq_desc::status non-atomically, i.e. without holding irq_desc::lock. Isn't this fragile? From my point of view, locking anything would be