Hello Chris,
On Sunday 25 of September 2016 03:24:06 Chris Johns wrote:
> Hi Pavel,
>
> Thank you for this. What testing has the patch had?
Only QEMU, serial and E100 and VirtIO NIC.
So I agree that testing on the real HW is a must.
We have some test PCs with remote booting and monitoring
at univ
On 25/09/2016 11:28, Joel Sherrill wrote:
We have an old PC of mine at the office which is pretty reliable at
generating the spurious interrupt. I won't be there this week though.
Same. I have gear here but lacking time.
Is there still a print when one occurs?
No, there is a counter somew
We have an old PC of mine at the office which is pretty reliable at
generating the spurious interrupt. I won't be there this week though.
Is there still a print when one occurs?
On Sep 24, 2016 8:24 PM, "Chris Johns" wrote:
> Hi Pavel,
>
> Thank you for this. What testing has the patch had?
>
>
Hi Pavel,
Thank you for this. What testing has the patch had?
It needs to be tested on real hardware and hardware which showed the
spurious interrupt issue. The issue appears around the interrupt enable
call and my guess is it relates to some type of a race condition in the
PIC between the si
Hello Jin-Hyun Kim, Hyun-Wook Jin and others,
I have returned back to VirtIO based network driver
after I have make PCI based E100 card work by woraround
which re-enables IRQ in driver worker daemon.
In meanwhile, I have included alternative networking setup
with E100 to RTEMS QEMU Wiki page
ht
From: Pavel Pisa
The global state of enabled and disabled interrupts has to hold
interrupts really disabled by drivers and system. If the state is
combined with interrupts temporarily disabled because they are
processed at given time then it is impossible to maintain state
by interrupt handlers i
