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
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
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
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
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.
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
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
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
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
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
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
11 matches
Mail list logo