Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1524067 > unrolled thread
| Started by | Hayes Wang <hayeswang@realtek.com> |
|---|---|
| First post | 2016-11-17 04:40 +0100 |
| Last post | 2016-11-24 13:40 +0100 |
| Articles | 6 on this page of 46 — 6 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-17 04:40 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-17 15:30 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-17 15:40 +0100
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-18 09:00 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-18 13:10 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-22 14:20 +0100
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-23 05:00 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-23 14:50 +0100
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-23 16:20 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-23 20:30 +0100
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-24 04:30 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 13:40 +0100
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-24 14:30 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable David Miller <davem@davemloft.net> - 2016-11-24 17:30 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 17:50 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 18:10 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable David Miller <davem@davemloft.net> - 2016-11-24 18:20 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable David Miller <davem@davemloft.net> - 2016-11-24 18:20 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 19:40 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 19:50 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <greg@kroah.com> - 2016-11-24 20:10 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <greg@kroah.com> - 2016-11-24 20:20 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 20:20 +0100
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-25 11:00 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 14:40 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Francois Romieu <romieu@fr.zoreil.com> - 2016-11-25 01:30 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 04:50 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <greg@kroah.com> - 2016-11-25 11:00 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 13:50 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 13:50 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <greg@kroah.com> - 2016-11-25 15:30 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 15:40 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 14:00 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <greg@kroah.com> - 2016-11-25 15:40 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable David Miller <davem@davemloft.net> - 2016-11-25 18:10 +0100
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-30 13:00 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-12-09 14:10 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <gregkh@linuxfoundation.org> - 2016-11-24 19:50 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 20:00 +0100
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-25 07:40 +0100
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-25 08:00 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 13:50 +0100
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-25 07:20 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 13:50 +0100
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable David Miller <davem@davemloft.net> - 2016-11-24 17:30 +0100
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-24 13:40 +0100
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Hayes Wang <hayeswang@realtek.com> |
|---|---|
| Date | 2016-11-25 08:00 +0100 |
| Message-ID | <sHiEh-5Bf-7@gated-at.bofh.it> |
| In reply to | #1529832 |
> Mark Lord [mailto:mlord@pobox.com]
> > Sent: Friday, November 25, 2016 12:44 AM
> [...]
> > The bad data in this case is ASCII:
> >
> > "SRC=m3400:/ TARGET=/m340"
> >
> > This data is what is seen in /run/mount/utab, a file that is read/written over NFS
> on
> > each boot.
> >
> > "SRC=m3400:/ TARGET=/m3400 ROOT=/
> > ATTRS=nolock,addr=192.168.8.1\n"
> >
> > But how does this ASCII data end up at offset zero of the rx buffer??
> > Not possible -- this isn't even stale data, because only an rx_desc could
> > be at that offset in that buffer.
> >
> > So even if this were a platform memory coherency issue, one should still
> > never see ASCII data at the beginning of an rx buffer. The driver NEVER
> > writes anything to the rx buffers. Only the USB hardware ever does.
> >
> > And only the r8152 dongle/driver exhibits this issue.
> > Other USB dongles do not. They *might* still have such issues,
> > but because they use software checksums, the bad packets are caught/rejected.
>
> Do you test it by rebooting? Maybe you could try a patch
> commit 93fe9b183840 ("r8152: reset the bmu"). However, it should
> only occur for the first urb buffer after rx is reset. I don't
> think you would reset the rx frequently, so the situation seems
> to be different.
Forgive me. I provide wrong information. This is about RTL8153,
not RTL8152.
Best Regards,
Hayes
[toc] | [prev] | [next] | [standalone]
| From | Mark Lord <mlord@pobox.com> |
|---|---|
| Date | 2016-11-25 13:50 +0100 |
| Message-ID | <sHo70-CC-39@gated-at.bofh.it> |
| In reply to | #1529837 |
On 16-11-25 01:51 AM, Hayes Wang wrote: > > Forgive me. I provide wrong information. This is about RTL8153, not RTL8152. No problem. Thanks for trying though.
[toc] | [prev] | [next] | [standalone]
| From | Hayes Wang <hayeswang@realtek.com> |
|---|---|
| Date | 2016-11-25 07:20 +0100 |
| Message-ID | <sHi1z-5nW-5@gated-at.bofh.it> |
| In reply to | #1529271 |
Mark Lord [mailto:mlord@pobox.com] > Sent: Thursday, November 24, 2016 11:25 PM [...] > x86 has near fully-coherent memory, so it is the "easy" platform > to get things working on. But Linux supports a very diverse number > of platforms, with varying degrees of cache/memory coherency, > and it can be tricky for things to work correctly on all of them. However, I have test iperf on raspberry pi v1 which you suggest for more than one day. I still couldn't reproduce your issue. > If you are testing with the driver as currently in 4.4.34, > then you won't even notice when things are screwing up, > because the driver just silently drops packets. > Or it passes them on without noticing that they have bad data. I only drop the packet silently when the rx descriptor outside the urb buffer. Then, I check the rx descriptor before checking the length of the packet. > Here (attached) is the instrumented driver I am using here now. > I suggest you use it or something similar when testing, > and not the stock driver. I would test it again with your driver. [...] > Also, unrelated, but inside r8152_submit_rx() there is this code: > > /* The rx would be stopped, so skip submitting */ > if (test_bit(RTL8152_UNPLUG, &tp->flags) || > !test_bit(WORK_ENABLE, &tp->flags) > || !netif_carrier_ok(tp->netdev)) > return 0; > > If that "return 0" statement is ever executed, doesn't it result > in the loss/leak of a buffer? They would be found back by calling rtl_start_rx(), when the rx is restarted. Best Regards, Hayes
[toc] | [prev] | [next] | [standalone]
| From | Mark Lord <mlord@pobox.com> |
|---|---|
| Date | 2016-11-25 13:50 +0100 |
| Message-ID | <sHo70-CC-47@gated-at.bofh.it> |
| In reply to | #1529827 |
On 16-11-25 01:11 AM, Hayes Wang wrote: > Mark Lord [mailto:mlord@pobox.com] .. >> If that "return 0" statement is ever executed, doesn't it result >> in the loss/leak of a buffer? > > They would be found back by calling rtl_start_rx(), when the rx > is restarted. Good. I figured it was probably something like that, but wasn't entirely sure about the control flow around stop/restart there. Thanks.
[toc] | [prev] | [next] | [standalone]
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2016-11-24 17:30 +0100 |
| Message-ID | <sH54l-5b9-17@gated-at.bofh.it> |
| In reply to | #1529246 |
From: Mark Lord <mlord@pobox.com> Date: Thu, 24 Nov 2016 07:31:17 -0500 > Any way we look at it though, the chip/driver are simply unreliable, > and relying upon hardware checksums (which fail due to the driver > looking at garbage rather than the checksum bits) leads to data > corruption. If the cpu/DMA implementation is the problem, then turning off checksums is not an appropriate fix at all. In fact, we have no idea what the cause is yet. That makes turning off random features no more than grasping at straws and makes no sense at all upstream. It may make sense for you to do such a change locally in _your_ tree to fix your situation temporarily. But upstream we shouldn't be doing it.
[toc] | [prev] | [next] | [standalone]
| From | Hayes Wang <hayeswang@realtek.com> |
|---|---|
| Date | 2016-11-24 13:40 +0100 |
| Message-ID | <sH1tM-2E0-29@gated-at.bofh.it> |
| In reply to | #1528426 |
Mark Lord [mailto:mlord@pobox.com]
> Sent: Wednesday, November 23, 2016 9:41 PM
[...]
> >static void r8153_set_rx_early_size(struct r8152 *tp)
> >{
> > u32 mtu = tp->netdev->mtu;
> > u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
> >
> > ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE, ocp_data);
> >}
>
> How is ocp_data used by the hardware?
> Shouldn't the calculation also include sizeof(rx_desc) in there somewhere?
I check your question with our hw engineers, and you are right.
The size of rx descriptor should be calculated, too.
Best Regards,
Hayes
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web