> > Unfortunately I have to report that the crashing has resurfaced. I'm
> > currently using kernel 5.0 with Heiner's fix applied. In the last few
> > days I've had the crash occur 4 times now. I'm not sure how to further
> > investigate this but I'm guessing a patch that adds more debugging
> > ou
On 04.04.2019 16:28, VDR User wrote:
> Hi,
>
> Unfortunately I have to report that the crashing has resurfaced. I'm
> currently using kernel 5.0 with Heiner's fix applied. In the last few
> days I've had the crash occur 4 times now. I'm not sure how to further
> investigate this but I'm guessing a
Hi,
Unfortunately I have to report that the crashing has resurfaced. I'm
currently using kernel 5.0 with Heiner's fix applied. In the last few
days I've had the crash occur 4 times now. I'm not sure how to further
investigate this but I'm guessing a patch that adds more debugging
output will be ne
> >>> Just a quick check-in... I was able to do a decent amount of testing
> >>> yesterday after applying Heiner's patches that "removes an extra PCI
> >>> register read in the
> >>> interrupt handler" and adds some debug logging. So far I haven't seen
> >>> any crashes, everything has been smooth
On 21.03.2019 20:35, VDR User wrote:
>>> Just a quick check-in... I was able to do a decent amount of testing
>>> yesterday after applying Heiner's patches that "removes an extra PCI
>>> register read in the
>>> interrupt handler" and adds some debug logging. So far I haven't seen
>>> any crashes,
> > Just a quick check-in... I was able to do a decent amount of testing
> > yesterday after applying Heiner's patches that "removes an extra PCI
> > register read in the
> > interrupt handler" and adds some debug logging. So far I haven't seen
> > any crashes, everything has been smooth. It may b
On 18.03.2019 17:17, VDR User wrote:
> Just a quick check-in... I was able to do a decent amount of testing
> yesterday after applying Heiner's patches that "removes an extra PCI
> register read in the
> interrupt handler" and adds some debug logging. So far I haven't seen
> any crashes, everythin
Just a quick check-in... I was able to do a decent amount of testing
yesterday after applying Heiner's patches that "removes an extra PCI
register read in the
interrupt handler" and adds some debug logging. So far I haven't seen
any crashes, everything has been smooth. It may be worth noting that
On 17.03.2019 16:41, VDR User wrote:
> A quick comment on patch 1:
>
>> @@ -1294,6 +1295,7 @@ static void rtl_ack_events(struct rtl8169_private *tp,
>> u16 bits)
>> static void rtl_irq_disable(struct rtl8169_private *tp)
>> {
>> RTL_W16(tp, IntrMask, 0);
>> + tp->irq_enabled = 0;
A quick comment on patch 1:
> @@ -1294,6 +1295,7 @@ static void rtl_ack_events(struct rtl8169_private *tp,
> u16 bits)
> static void rtl_irq_disable(struct rtl8169_private *tp)
> {
> RTL_W16(tp, IntrMask, 0);
> + tp->irq_enabled = 0;
> }
This function is slightly different in th
> Below are two patches. The first removes an extra PCI register read in the
> interrupt handler, the second one just adds some tracing for debugging.
>
> Interesting would be whether patch 1 has an impact on the issue, and the
> trace output of patch 2 after the issue occurred (w/ or w/o patch 1).
On 16.03.2019 15:38, VDR User wrote:
>> Part of the issue though is that we don't know how reliable that test
>> was. I believe Derek he hasn't had any crashes, but he wasn't confident
>> that it had actually resolved the issue.
>
> Previously I thought I could easily & consistently reproduce the
On 16.03.2019 18:08, Alexander Duyck wrote:
> On Sat, Mar 16, 2019 at 8:12 AM Heiner Kallweit wrote:
>>
>> On 16.03.2019 15:38, VDR User wrote:
Part of the issue though is that we don't know how reliable that test
was. I believe Derek he hasn't had any crashes, but he wasn't confident
>>
On Sat, Mar 16, 2019 at 8:12 AM Heiner Kallweit wrote:
>
> On 16.03.2019 15:38, VDR User wrote:
> >> Part of the issue though is that we don't know how reliable that test
> >> was. I believe Derek he hasn't had any crashes, but he wasn't confident
> >> that it had actually resolved the issue.
> >
On 16.03.2019 15:38, VDR User wrote:
>> Part of the issue though is that we don't know how reliable that test
>> was. I believe Derek he hasn't had any crashes, but he wasn't confident
>> that it had actually resolved the issue.
>
> Previously I thought I could easily & consistently reproduce the
> Part of the issue though is that we don't know how reliable that test
> was. I believe Derek he hasn't had any crashes, but he wasn't confident
> that it had actually resolved the issue.
Previously I thought I could easily & consistently reproduce the crash
but the more testing I did, the more I
On 16.03.2019 00:54, Alexander Duyck wrote:
> On Fri, 2019-03-15 at 23:27 +0100, Heiner Kallweit wrote:
>> On 15.03.2019 23:09, Alexander Duyck wrote:
>>> On Fri, 2019-03-15 at 21:46 +0100, Heiner Kallweit wrote:
On 15.03.2019 21:40, Alexander Duyck wrote:
> On Fri, 2019-03-15 at 21:26 +01
On 15.03.2019 23:09, Alexander Duyck wrote:
> On Fri, 2019-03-15 at 21:46 +0100, Heiner Kallweit wrote:
>> On 15.03.2019 21:40, Alexander Duyck wrote:
>>> On Fri, 2019-03-15 at 21:26 +0100, Heiner Kallweit wrote:
On 15.03.2019 21:09, VDR User wrote:
> Thanks for the additional info and
On Fri, 2019-03-15 at 21:46 +0100, Heiner Kallweit wrote:
> On 15.03.2019 21:40, Alexander Duyck wrote:
> > On Fri, 2019-03-15 at 21:26 +0100, Heiner Kallweit wrote:
> > > On 15.03.2019 21:09, VDR User wrote:
> > > > > > > > Thanks for the additional info and for testing 4.20.15.
> > > > > > > > To
On 15.03.2019 21:40, Alexander Duyck wrote:
> On Fri, 2019-03-15 at 21:26 +0100, Heiner Kallweit wrote:
>> On 15.03.2019 21:09, VDR User wrote:
>>> Thanks for the additional info and for testing 4.20.15.
>>> To rule out that the issue is caused by a regression in network or
>>> some oth
On Fri, 2019-03-15 at 21:26 +0100, Heiner Kallweit wrote:
> On 15.03.2019 21:09, VDR User wrote:
> > > > > > Thanks for the additional info and for testing 4.20.15.
> > > > > > To rule out that the issue is caused by a regression in network or
> > > > > > some other subsystem: Can you take the r816
On 15.03.2019 21:09, VDR User wrote:
> Thanks for the additional info and for testing 4.20.15.
> To rule out that the issue is caused by a regression in network or
> some other subsystem: Can you take the r8169.c from 4.20.15 and test
> it on top of 5.0?
> Meanwhile I'll look at
> > >> Thanks for the additional info and for testing 4.20.15.
> > >> To rule out that the issue is caused by a regression in network or
> > >> some other subsystem: Can you take the r8169.c from 4.20.15 and test
> > >> it on top of 5.0?
> > >> Meanwhile I'll look at the changes in the driver betwe
> >> Thanks for the additional info and for testing 4.20.15.
> >> To rule out that the issue is caused by a regression in network or
> >> some other subsystem: Can you take the r8169.c from 4.20.15 and test
> >> it on top of 5.0?
> >> Meanwhile I'll look at the changes in the driver between 4.20 an
On 14.03.2019 16:10, VDR User wrote:
>> Thanks for the additional info and for testing 4.20.15.
>> To rule out that the issue is caused by a regression in network or
>> some other subsystem: Can you take the r8169.c from 4.20.15 and test
>> it on top of 5.0?
>> Meanwhile I'll look at the changes in
> Thanks for the additional info and for testing 4.20.15.
> To rule out that the issue is caused by a regression in network or
> some other subsystem: Can you take the r8169.c from 4.20.15 and test
> it on top of 5.0?
> Meanwhile I'll look at the changes in the driver between 4.20 and 5.0.
Sure, n
On 14.03.2019 04:04, VDR User wrote:
> Hi Heiner,
>
> Thanks for your response. Request info follows..
>
>>> Hi, after updating to kernel 5.0, the nic driver (r8169) has been
>>> crashing whenever I start using heavy traffic on it (for example,
>>> xferring large files to the box across my lan).
Hi Heiner,
Thanks for your response. Request info follows..
> > Hi, after updating to kernel 5.0, the nic driver (r8169) has been
> > crashing whenever I start using heavy traffic on it (for example,
> > xferring large files to the box across my lan). The destination
> > harddrive may be sleeping
On 10.03.2019 20:02, VDR User wrote:
> Hi, after updating to kernel 5.0, the nic driver (r8169) has been
> crashing whenever I start using heavy traffic on it (for example,
> xferring large files to the box across my lan). The destination
> harddrive may be sleeping and need to spin-up, or not, but
Hi, after updating to kernel 5.0, the nic driver (r8169) has been
crashing whenever I start using heavy traffic on it (for example,
xferring large files to the box across my lan). The destination
harddrive may be sleeping and need to spin-up, or not, but the box
itself does not suspend/hibernate. T
30 matches
Mail list logo
