Vladimir Cotfas wrote:
> Jan,
>
>> You were asking me to make the delay timeouts configurable. Problem is
>> that
>>> there's more than one and I think they should be left as-is.
>> If you look closer, you'll find only one effective timeout: that for the
>> outer loop.
>>
>>> I've had
>>> problems
Vladimir Cotfas wrote:
> Jan
>
>> OK, to recover from a transmitter hang (or timeout) let's go this route:
>>
>> rtdm_nrtsig_init(&nic->tx_timeout_signal, e100_timeout_handler, nic);
>>
>> e100_exec_cb:
>>if (err == -ENOSPC)
>>rtdm_nrtsig_pend(nic->tx_timeout_signal);
>>
>>
Jan Kiszka wrote:
> Vladimir Cotfas wrote:
>> Jan,
>> I may have missed that point. But if the original code already uses
>> schedule_work, there is likely not much to gain via an RT task: when it
>> triggers, RT systems are typically already broken.
>>
>> I have no problem with error detection, al
Jan,
> I may have missed that point. But if the original code already uses
> schedule_work, there is likely not much to gain via an RT task: when it
> triggers, RT systems are typically already broken.
>
> I have no problem with error detection, also error recovery. We should
> just avoid over-des
Vladimir Cotfas wrote:
> Jan,
> I may have missed that point. But if the original code already uses
> schedule_work, there is likely not much to gain via an RT task: when it
> triggers, RT systems are typically already broken.
>
> I have no problem with error detection, also error recovery. We sho
Vladimir Cotfas wrote:
> Jan,
>
>
>>> - same for USE_RTAI_IRQ, which has to become always on
>>> It is on right now. It exists in the patch so we have less work when we
>> hack
>>> the driver for our FPGA ISR.
>> They are irrelevant for anything else than your system. I will not merge
>> them as
Jan,
> >
> > - same for USE_RTAI_IRQ, which has to become always on
> > It is on right now. It exists in the patch so we have less work when we
> hack
> > the driver for our FPGA ISR.
>
> They are irrelevant for anything else than your system. I will not merge
> them as they increase the diff to
Vladimir Cotfas wrote:
> Jan,
>
>
>> Some remaining issues:
>>
>> - command timeout handling should follow rt_eepro100 (CONFIG option,
>> low timeout by default - you can still raise it at configure time if
>> you need that for your setup)
>>
> Please indicate the place in code. Will look into
Hi Vlad,
please avoid top-posts. If you have nothing to cite, just drop it.
Otherwise follow up under the citation.
Vladimir Cotfas wrote:
> Jan,
>
> I moved all the RTAI calls to RTDM and corrected a potential deadlock. Would
> you accept this patch? (again the base is 2.6.29).
Some remaining
Scott Gilbertson wrote:
>> To make your local patch to rt_e100.c as small as possible, I would
>> suggest to let the custom FPGA driver export some callback registration
>> interface, and then simply exchange rtdm_irq_request/free with that one.
>> I don't see that this callback requires task conte
Vladimir Cotfas wrote:
> Jan,
>
> Please understand that I will not merge any ha^w"extensions" on top of
>> an RT Linux variant, neither RTAI nor any other approach. The proper
>> abstractions are RTDM for RT, Linux for non-RT base services, and any
>> other services have to be provided by the RTn
Jan,
Please understand that I will not merge any ha^w"extensions" on top of
> an RT Linux variant, neither RTAI nor any other approach. The proper
> abstractions are RTDM for RT, Linux for non-RT base services, and any
> other services have to be provided by the RTnet core. If something is
> missi
Vladimir Cotfas wrote:
> Jan,
>
>> I had it running only for a short while w/o the WDT and I did not see any
>>> lockup. I could do a longer test.
>> That would make e100 _very_ interesting as a eepro100 replacement, at
>> least mid-term when we know that no eepro100 users suffer from potential
>>
Jan,
> I had it running only for a short while w/o the WDT and I did not see any
> > lockup. I could do a longer test.
>
> That would make e100 _very_ interesting as a eepro100 replacement, at
> least mid-term when we know that no eepro100 users suffer from potential
> regressions with e100.
>
I
Vladimir Cotfas wrote:
> Jan,
>
>
>> Better look at the git commits upstream ("gitk v2.6.29..HEAD --
>> drivers/net/e100.c", or so), they are more telling than an all-in-one
>> diff. But already that diff tells me that upstream gained support for
>> yet another adapter variant. Maybe it also rece
Jan,
> Better look at the git commits upstream ("gitk v2.6.29..HEAD --
> drivers/net/e100.c", or so), they are more telling than an all-in-one
> diff. But already that diff tells me that upstream gained support for
> yet another adapter variant. Maybe it also received some bug fixes.>
>
I could p
Vladimir Cotfas wrote:
> Jan,
>
> Sorry for the delay in my response: I have been away due to my work
> schedule.
>
> On Fri, May 14, 2010 at 6:24 AM, Jan Kiszka wrote:
>
>> Vladimir Cotfas wrote:
>>> Folks,
>>>
>>> At Manta Test we have noticed that the rt_eepro100 driver would sometimes
>>> l
Jan,
Sorry for the delay in my response: I have been away due to my work
schedule.
On Fri, May 14, 2010 at 6:24 AM, Jan Kiszka wrote:
> Vladimir Cotfas wrote:
> > Folks,
> >
> > At Manta Test we have noticed that the rt_eepro100 driver would sometimes
> > lock up overnight due to traffic on the
Vladimir Cotfas wrote:
> Folks,
>
> At Manta Test we have noticed that the rt_eepro100 driver would sometimes
> lock up overnight due to traffic on the local net (the same did not happen
> if we used an isolated segment that had well-known traffic generated by us).
That chip, at least some varian
19 matches
Mail list logo
