> > 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
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
> > 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
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
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).
> 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
> > >> 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
> 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
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
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
Sean, I'd like to echo Matthias's appreciation for your work with this
BPF project. I'm very much looking forward to the possibility of using
my remotes directly with decoders generated from the existing
lircd.conf's. Excited seeing your work progress!
Cheers,
Derek
On Tue, May 22, 2018 at 6:50 A
> - err("firmare chunk size bigger than 64 bytes.");
> + err("firmware chunk size bigger than 64 bytes.");
Yup.
> -"HW don't support CMAC encrypiton, use software CMAC
> encrypiton\n");
> +"HW don't suppo
15 matches
Mail list logo
