Re: r8152: data corruption in various scenarios

nal device speed is High Speed (480Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat2047 micro seconds Device Status: 0x000c (Bus Powered) U1 Enabled U2 Enabled -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: r8152: data corruption in various scenarios

ystem's > USB host controller. Thank-you, Mario. So.. why are we enabling the r8153 (USB-ethernet) workaround on this WD15 dock? The discussion back in 2017 was that only the TB15/TB16 were affected by the XHCI overruns it produces? -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: r8152: data corruption in various scenarios

On 2019-01-07 1:46 a.m., Kai Heng Feng wrote: > > Do you happen to use a Dell system? We can do some test here. Yes. It is a Dell XPS 13 9360 i7-8550U notebook, with the Dell WD15 USB-C dock. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: r8152: data corruption in various scenarios

On 2019-01-06 11:09 p.m., Kai Heng Feng wrote: > > >> On Jan 7, 2019, at 05:16, Mark Lord wrote: >> >> On 2019-01-06 4:13 p.m., Mark Lord wrote: >>> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 >>> PM, Mark Lord >

Re: r8152: data corruption in various scenarios

On 2019-01-06 4:13 p.m., Mark Lord wrote: > On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM, > Mark Lord > wrote: > .. >>> There is even now a special hack in the upstream r8152.c to attempt to >>> detect >>> a Dell TB16

Re: r8152: data corruption in various scenarios

On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM, Mark Lord wrote: .. >> There is even now a special hack in the upstream r8152.c to attempt to detect >> a Dell TB16 dock and disable RX Aggregation in the driver to prevent such >> issues. &g

Re: r8152: data corruption in various scenarios

On 2019-01-05 9:14 a.m., Mark Lord wrote: > A couple of years back, I reported data corruption resulting from > a change in kernel 3.16 which enabled hardware checksums in the r8152 driver. > This was happening on an embedded system that was using a r8152 USB dongle. > > At the ti

r8152: data corruption in various scenarios

.0. >From this I conclude that the workaround is not 100% complete yet. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

524280U +#define COALESCE_SUPER 8500U +#define COALESCE_HIGH 25000U +#define COALESCE_SLOW 52428U The RTL_VER_02 chip that I was using does not support interrupt coalescing in the driver [see the rtl8152_set_coalesce() function]. So that workaround would not help here.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

524280U +#define COALESCE_SUPER 8500U +#define COALESCE_HIGH 25000U +#define COALESCE_SLOW 52428U The RTL_VER_02 chip that I was using does not support interrupt coalescing in the driver [see the rtl8152_set_coalesce() function]. So that workaround would not help here.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-12-08 10:23 PM, Hayes Wang wrote: > Mark Lord <ml...@pobox.com> > > I find an issue about autosuspend, and it may result in the same > problem with you. I don't sure if this is helpful to you, because > it only occurs when enabling the autosuspend. Thanks. I am using

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-12-08 10:23 PM, Hayes Wang wrote: > Mark Lord > > I find an issue about autosuspend, and it may result in the same > problem with you. I don't sure if this is helpful to you, because > it only occurs when enabling the autosuspend. Thanks. I am using ASIX adapters

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 09:22 AM, Greg KH wrote: > On Fri, Nov 25, 2016 at 07:41:42AM -0500, Mark Lord wrote: >> On 16-11-25 07:34 AM, Mark Lord wrote: >>> On 16-11-25 04:53 AM, Greg KH wrote: >>>> Note, there are "cheap" USB monitors that can be quite handy an

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 09:22 AM, Greg KH wrote: > On Fri, Nov 25, 2016 at 07:41:42AM -0500, Mark Lord wrote: >> On 16-11-25 07:34 AM, Mark Lord wrote: >>> On 16-11-25 04:53 AM, Greg KH wrote: >>>> Note, there are "cheap" USB monitors that can be quite handy an

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:52 AM, Hayes Wang wrote: .. > What is the value of /sys/bus/usb/devices/.../power/control ? That entry does not exist -- power control is completely disabled on this board. Good try, though -- USB power control still causes me trouble on PCs with mice and remote controls. But not

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:52 AM, Hayes Wang wrote: .. > What is the value of /sys/bus/usb/devices/.../power/control ? That entry does not exist -- power control is completely disabled on this board. Good try, though -- USB power control still causes me trouble on PCs with mice and remote controls. But not

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:53 AM, Greg KH wrote: > On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote: >> There is no possibility for them to be used for anything other than >> USB receive buffers, for this driver only. Nothing in the driver >> or kernel ever writes to those

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:53 AM, Greg KH wrote: > On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote: >> There is no possibility for them to be used for anything other than >> USB receive buffers, for this driver only. Nothing in the driver >> or kernel ever writes to those

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:53 AM, Greg KH wrote: > Note, there are "cheap" USB monitors that can be quite handy and that work on > Linux: > http://www.totalphase.com/products/beagle-usb12/ USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:53 AM, Greg KH wrote: > Note, there are "cheap" USB monitors that can be quite handy and that work on > Linux: > http://www.totalphase.com/products/beagle-usb12/ USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 07:34 AM, Mark Lord wrote: > On 16-11-25 04:53 AM, Greg KH wrote: >> Note, there are "cheap" USB monitors that can be quite handy and that work >> on Linux: >> http://www.totalphase.com/products/beagle-usb12/ > > USD$455/each in quantity,

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 07:34 AM, Mark Lord wrote: > On 16-11-25 04:53 AM, Greg KH wrote: >> Note, there are "cheap" USB monitors that can be quite handy and that work >> on Linux: >> http://www.totalphase.com/products/beagle-usb12/ > > USD$455/each in quantity,

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 01:11 AM, Hayes Wang wrote: > Mark Lord [mailto:ml...@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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 01:11 AM, Hayes Wang wrote: > Mark Lord [mailto:ml...@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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

to those buffers after initial allocation, and only the driver and USB host controller ever have pointers to the buffers. -- Mark Lord

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

to those buffers after initial allocation, and only the driver and USB host controller ever have pointers to the buffers. -- Mark Lord

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 02:00 PM, Greg KH wrote: > On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote: >> One thought: bulk data streams are byte streams, not packets. >> Scheduling on the USB bus can break up larger transfers across >> multiple in-kernel buffers. A "real&

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 02:00 PM, Greg KH wrote: > On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote: >> One thought: bulk data streams are byte streams, not packets. >> Scheduling on the USB bus can break up larger transfers across >> multiple in-kernel buffers. A "real&

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 01:42 PM, Greg KH wrote: > > Have you tried using usbmon? This system is running rootfs over NFS, so usbmon isn't realistically going to be usable in that scenario without a lot of reconfiguration of the setup (which in itself might obscure the original problem). There is a hardware

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 01:42 PM, Greg KH wrote: > > Have you tried using usbmon? This system is running rootfs over NFS, so usbmon isn't realistically going to be usable in that scenario without a lot of reconfiguration of the setup (which in itself might obscure the original problem). There is a hardware

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 01:34 PM, Mark Lord wrote: >From tracing through the powerpc arch code, this is the buffer that > is being directly DMA'd into. And the USB layer does an invalidate_dcache > on that entire buffer before initiating the DMA (confirmed via printk). Slight c

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 01:34 PM, Mark Lord wrote: >From tracing through the powerpc arch code, this is the buffer that > is being directly DMA'd into. And the USB layer does an invalidate_dcache > on that entire buffer before initiating the DMA (confirmed via printk). Slight c

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 12:11 PM, David Miller wrote: > From: Mark Lord <ml...@pobox.com> > Date: Thu, 24 Nov 2016 11:43:53 -0500 > >> So even if this were a platform memory coherency issue, one should >> still never see ASCII data at the beginning of an rx buffer. >

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 12:11 PM, David Miller wrote: > From: Mark Lord > Date: Thu, 24 Nov 2016 11:43:53 -0500 > >> So even if this were a platform memory coherency issue, one should >> still never see ASCII data at the beginning of an rx buffer. > > I'm not so convinced, since

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 11:43 AM, Mark Lord wrote: .. 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. Answering my own question here, I suspect it ends up there as a result

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 11:43 AM, Mark Lord wrote: .. 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. Answering my own question here, I suspect it ends up there as a result

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 11:21 AM, David Miller wrote: From: Hayes Wang Date: Thu, 24 Nov 2016 13:26:55 + I don't think the garbage results from our driver or device. This is my impression with what has been presented so far as well. It's not garbage. The latest run with the

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 11:21 AM, David Miller wrote: From: Hayes Wang Date: Thu, 24 Nov 2016 13:26:55 + I don't think the garbage results from our driver or device. This is my impression with what has been presented so far as well. It's not garbage. The latest run with the debug code I posted

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 08:26 AM, Hayes Wang wrote: .. Besides, it doesn't seem to occur for all platforms. I have tested the iperf more than 26 hours, and it still works fine. I think I would get the same result on x86 or x86_64 platform. .. x86 has near fully-coherent memory, so it is the "easy"

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 08:26 AM, Hayes Wang wrote: .. Besides, it doesn't seem to occur for all platforms. I have tested the iperf more than 26 hours, and it still works fine. I think I would get the same result on x86 or x86_64 platform. .. x86 has near fully-coherent memory, so it is the "easy"

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-23 02:29 PM, Mark Lord wrote: On 16-11-23 10:12 AM, Hayes Wang wrote: Mark Lord [ml...@pobox.com] [...] What does this code do: static void r8153_set_rx_early_size(struct r8152 *tp) { u32 mtu = tp->netdev->mtu; u32 ocp_data = (agg_buf_sz - mtu - VLAN_ET

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-23 02:29 PM, Mark Lord wrote: On 16-11-23 10:12 AM, Hayes Wang wrote: Mark Lord [ml...@pobox.com] [...] What does this code do: static void r8153_set_rx_early_size(struct r8152 *tp) { u32 mtu = tp->netdev->mtu; u32 ocp_data = (agg_buf_sz - mtu - VLAN_ET

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-23 10:12 AM, Hayes Wang wrote: Mark Lord [ml...@pobox.com] [...] What does this code do: 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_w

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-23 10:12 AM, Hayes Wang wrote: Mark Lord [ml...@pobox.com] [...] What does this code do: 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_w

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

>} How is ocp_data used by the hardware? Shouldn't the calculation also include sizeof(rx_desc) in there somewhere? Thanks -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

>} How is ocp_data used by the hardware? Shouldn't the calculation also include sizeof(rx_desc) in there somewhere? Thanks -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-18 07:03 AM, Mark Lord wrote: On 16-11-18 02:57 AM, Hayes Wang wrote: .. Besides, the maximum data length which the RTL8152 would send to the host is 16KB. That is, if the agg_buf_sz is 16KB, the host wouldn't split it. However, you still see problems for it. How does the RTL8152

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-18 07:03 AM, Mark Lord wrote: On 16-11-18 02:57 AM, Hayes Wang wrote: .. Besides, the maximum data length which the RTL8152 would send to the host is 16KB. That is, if the agg_buf_sz is 16KB, the host wouldn't split it. However, you still see problems for it. How does the RTL8152

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

ngths/ranges before accessing the actual buffer, and everything should begin working reliably. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

ngths/ranges before accessing the actual buffer, and everything should begin working reliably. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

(resending.. not sure if the original had mailer errors) On 16-11-16 10:36 PM, Hayes Wang wrote: > [...] >> Fix the hw rx checksum is always enabled, and the user couldn't switch >> it to sw rx checksum. >> >> Note that the RTL_VER_01 only supports sw rx checksum only. Besides, >> the hw rx

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

(resending.. not sure if the original had mailer errors) On 16-11-16 10:36 PM, Hayes Wang wrote: > [...] >> Fix the hw rx checksum is always enabled, and the user couldn't switch >> it to sw rx checksum. >> >> Note that the RTL_VER_01 only supports sw rx checksum only. Besides, >> the hw rx

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-17 09:14 AM, Mark Lord wrote: .. Using coherent buffers (non-cacheable, allocated with usb_alloc_coherent), Note that the same behaviour also happens with the original kmalloc'd buffers. I can get it to fail extremely regularly by simply reducing the buffer size (agg_buf_sz) from

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-17 09:14 AM, Mark Lord wrote: .. Using coherent buffers (non-cacheable, allocated with usb_alloc_coherent), Note that the same behaviour also happens with the original kmalloc'd buffers. I can get it to fail extremely regularly by simply reducing the buffer size (agg_buf_sz) from

Re: [PATCH net 2/2] r8152: rx descriptor check

On 16-11-13 03:34 PM, Mark Lord wrote: > > The system I use it with is a 32-bit ppc476, with non-coherent RAM, > and using 16KB page sizes. > > The dongle instantly becomes a lot more reliable when r8152.c is updated > to use usb_alloc_coherent() for URB buffers, r

Re: [PATCH net 2/2] r8152: rx descriptor check

On 16-11-13 03:34 PM, Mark Lord wrote: > > The system I use it with is a 32-bit ppc476, with non-coherent RAM, > and using 16KB page sizes. > > The dongle instantly becomes a lot more reliable when r8152.c is updated > to use usb_alloc_coherent() for URB buffers, r

Re: [PATCH net 2/2] r8152: rx descriptor check

cess to the test system only for a day or two a week, and it takes a few hours to do a good test as to whether something helps or not. I'll continue to poke at it as time and New Ideas permit. New Ideas welcome! -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: [PATCH net 2/2] r8152: rx descriptor check

nd it takes a few hours to do a good test as to whether something helps or not. I'll continue to poke at it as time and New Ideas permit. New Ideas welcome! -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: [PATCH net 2/2] r8152: rx descriptor check

ularly attempts to process huge unreal packet sizes here. I've had to patch it to reject "packets" larger than the configured MRU. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: [PATCH net 2/2] r8152: rx descriptor check

huge unreal packet sizes here. I've had to patch it to reject "packets" larger than the configured MRU. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-11-09 08:09 AM, Hayes Wang wrote: > Mark Lord [mailto:ml...@pobox.com] .. >> The MTU/MRU on this link is the standard 1500 bytes, so a pkt_len of 2045 >> isn't >> valid here. >> And the rx_desc values look an awful lot like the rx_data values that follow >

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-11-09 08:09 AM, Hayes Wang wrote: > Mark Lord [mailto:ml...@pobox.com] .. >> The MTU/MRU on this link is the standard 1500 bytes, so a pkt_len of 2045 >> isn't >> valid here. >> And the rx_desc values look an awful lot like the rx_data values that follow >

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-11-04 09:50 AM, Mark Lord wrote: > Yeah, the device or driver is definitely getting confused with rx_desc > structures. > I added code to check for unlikely rx_desc values, and it found this for > starters: > > rx_desc: 00480801 00480401 00480001 0048fc00 0048f800 004

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-11-04 09:50 AM, Mark Lord wrote: > Yeah, the device or driver is definitely getting confused with rx_desc > structures. > I added code to check for unlikely rx_desc values, and it found this for > starters: > > rx_desc: 00480801 00480401 00480001 0048fc00 0048f800 004

Re: [PATCH net] r8152: Fix broken RX checksums.

Yeah, the device or driver is definitely getting confused with rx_desc structures. I added code to check for unlikely rx_desc values, and it found this for starters: rx_desc: 00480801 00480401 00480001 0048fc00 0048f800 0048f400 pkt_len=2045 rx_data: 00 f0 48 00 00 ec 48 00 00 e8 48 00 00 e4

Re: [PATCH net] r8152: Fix broken RX checksums.

Yeah, the device or driver is definitely getting confused with rx_desc structures. I added code to check for unlikely rx_desc values, and it found this for starters: rx_desc: 00480801 00480401 00480001 0048fc00 0048f800 0048f400 pkt_len=2045 rx_data: 00 f0 48 00 00 ec 48 00 00 e8 48 00 00 e4

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-11-02 02:29 PM, Mark Lord wrote: I have poked at it some more, and thus far it appears that it is only necessary to disable TCP rx checksums. The system doesn't crash when only IP/UDP checksums are enabled, but does when TCP checksums are on. This happens regardless of whether RX_AGG

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-11-02 02:29 PM, Mark Lord wrote: I have poked at it some more, and thus far it appears that it is only necessary to disable TCP rx checksums. The system doesn't crash when only IP/UDP checksums are enabled, but does when TCP checksums are on. This happens regardless of whether RX_AGG

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-11-03 04:56 AM, Hayes Wang wrote: > Mark Lord [mailto:ml...@pobox.com] >> Sent: Thursday, November 03, 2016 2:30 AM >> To: Hayes Wang; David Miller > [...] >> I have poked at it some more, and thus far it appears that it is >> only necessary to disable TCP rx

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-11-03 04:56 AM, Hayes Wang wrote: > Mark Lord [mailto:ml...@pobox.com] >> Sent: Thursday, November 03, 2016 2:30 AM >> To: Hayes Wang; David Miller > [...] >> I have poked at it some more, and thus far it appears that it is >> only necessary to disable TCP rx

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-10-31 04:14 AM, Hayes Wang wrote: The r8152 driver has been broken since (approx) 3.16.xx when support was added for hardware RX checksums on newer chip versions. Symptoms include random segfaults and silent data corruption over NFS. The hardware checksum logig does not work on the

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-10-31 04:14 AM, Hayes Wang wrote: The r8152 driver has been broken since (approx) 3.16.xx when support was added for hardware RX checksums on newer chip versions. Symptoms include random segfaults and silent data corruption over NFS. The hardware checksum logig does not work on the

Re: [PATCH net] r8152: Fix broken RX checksums.

the wrong bits. Either way, this results in data corruption and until otherwise fixed, it is safest to just not enable RX checksums. If it happens on a slow embedded CPU, then it can also happen on a heavily loaded Intel/AMD CPU -- just a lot less frequently. Cheers -- Mark Lord Real-Time Remedie

Re: [PATCH net] r8152: Fix broken RX checksums.

the wrong bits. Either way, this results in data corruption and until otherwise fixed, it is safest to just not enable RX checksums. If it happens on a slow embedded CPU, then it can also happen on a heavily loaded Intel/AMD CPU -- just a lot less frequently. Cheers -- Mark Lord Real-Time Remedie

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-10-30 08:57 PM, David Miller wrote: > From: Mark Lord <ml...@pobox.com> > Date: Sun, 30 Oct 2016 19:28:27 -0400 > >> The r8152 driver has been broken since (approx) 3.16.xx >> when support was added for hardware RX checksums >> on newer chip versions. Sym

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-10-30 08:57 PM, David Miller wrote: > From: Mark Lord > Date: Sun, 30 Oct 2016 19:28:27 -0400 > >> The r8152 driver has been broken since (approx) 3.16.xx >> when support was added for hardware RX checksums >> on newer chip versions. Symptoms include random &

[PATCH net] r8152: Fix broken RX checksums.

-porting to -stable >= 3.16.xx. Signed-off-by: Mark Lord <ml...@pobox.com> --- old/drivers/net/usb/r8152.c 2016-09-30 04:20:43.0 -0400 +++ linux/drivers/net/usb/r8152.c 2016-10-26 14:15:44.932517676 -0400 @@ -1645,7 +1645,7 @@ u8 checksum = CHECKSUM_NONE;

[PATCH net] r8152: Fix broken RX checksums.

-porting to -stable >= 3.16.xx. Signed-off-by: Mark Lord --- old/drivers/net/usb/r8152.c 2016-09-30 04:20:43.0 -0400 +++ linux/drivers/net/usb/r8152.c 2016-10-26 14:15:44.932517676 -0400 @@ -1645,7 +1645,7 @@ u8 checksum = CHECKSUM_NONE; u32 opts2, op

Re: [PATCH] drivers/net/usb/r8152 fix broken rx checksums

On 16-10-26 06:36 PM, Mark Lord wrote: The r8152 driver has been broken since (approx) 3.6.16, Correction: broken since 3.16.xx. when support was added for hardware rx checksum on newer chip versions. Symptoms include random segfaults and silent data corruption over NFS. This does not work

Re: [PATCH] drivers/net/usb/r8152 fix broken rx checksums

On 16-10-26 06:36 PM, Mark Lord wrote: The r8152 driver has been broken since (approx) 3.6.16, Correction: broken since 3.16.xx. when support was added for hardware rx checksum on newer chip versions. Symptoms include random segfaults and silent data corruption over NFS. This does not work

[PATCH] drivers/net/usb/r8152 fix broken rx checksums

.xx. Patch attached (to deal with buggy mailer) and also below for review. Signed-off-by: Mark Lord <ml...@pobox.com> --- old/drivers/net/usb/r8152.c 2016-09-30 04:20:43.0 -0400 +++ linux/drivers/net/usb/r8152.c 2016-10-26 14:15:44.932517676 -0400 @@ -1645,7 +1645,7 @@ u8

[PATCH] drivers/net/usb/r8152 fix broken rx checksums

.xx. Patch attached (to deal with buggy mailer) and also below for review. Signed-off-by: Mark Lord --- old/drivers/net/usb/r8152.c 2016-09-30 04:20:43.0 -0400 +++ linux/drivers/net/usb/r8152.c 2016-10-26 14:15:44.932517676 -0400 @@ -1645,7 +1645,7 @@ u8 checksum = CHECKSUM_N

Re: [PATCH v2] libata: add support for NCQ commands for SG interface

On 15-10-27 01:49 AM, vinayak.k...@gmail.com wrote: From: Vinayak Kale This patch is needed to make NCQ commands with FPDMA protocol value (eg READ/WRITE FPDMA) work over SCSI Generic (SG) interface. .. + /* For NCQ commands with FPDMA protocol, copy the tag value */ + if

Re: [PATCH v2] libata: add support for NCQ commands for SG interface

On 15-10-27 01:49 AM, vinayak.k...@gmail.com wrote: From: Vinayak Kale This patch is needed to make NCQ commands with FPDMA protocol value (eg READ/WRITE FPDMA) work over SCSI Generic (SG) interface. .. + /* For NCQ commands with FPDMA protocol, copy the tag

Re: linux: sata_nv: adma support

On 15-08-01 09:45 PM, Robert Hancock wrote: On Sat, Aug 1, 2015 at 2:09 PM, Pali Rohár wrote: On Thursday 25 December 2014 07:22:13 Robert Hancock wrote: On Tue, Dec 23, 2014 at 1:51 PM, Pali Rohár wrote: Hello, I have nvidia nforce4 motherboard with nvidia sata controller: .. It looks

Re: linux: sata_nv: adma support

On 15-08-01 09:45 PM, Robert Hancock wrote: On Sat, Aug 1, 2015 at 2:09 PM, Pali Rohár pali.ro...@gmail.com wrote: On Thursday 25 December 2014 07:22:13 Robert Hancock wrote: On Tue, Dec 23, 2014 at 1:51 PM, Pali Rohár pali.ro...@gmail.com wrote: Hello, I have nvidia nforce4 motherboard with

Re: linux-3.14 nfsd regression

gt; > This reverts the part of commit 6e14b46b91fee8a049b0940333ce13a820beaaa5 > that changes NFSv2 behavior. > > Mark Lord found that it broke nfs-root for Linux clients, because it > broke NFSv2. > > In fact, from RFC 1094: &g

Re: linux-3.14 nfsd regression

35a8dff14e76c00e5b52140290cfb498dc2454a0 Author: J. Bruce Fields bfie...@redhat.com Date: Thu Apr 3 15:10:35 2014 -0400 nfsd: revert v2 half of nfsd: don't return high mode bits This reverts the part of commit 6e14b46b91fee8a049b0940333ce13a820beaaa5 that changes NFSv2 behavior. Mark Lord

Re: driver skip pci_set_master, fix it? No.

On 14-04-09 11:52 AM, Bjorn Helgaas wrote: > On Wed, Apr 9, 2014 at 8:18 AM, Mark Lord wrote: >> On 14-04-09 10:12 AM, Mark Lord wrote: >>> On 14-04-09 09:08 AM, Mark Lord wrote: >>>> On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote: >>>>> On Tu

Re: driver skip pci_set_master, fix it? No.

On 14-04-09 10:12 AM, Mark Lord wrote: > On 14-04-09 09:08 AM, Mark Lord wrote: >> On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote: >>> On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote: >>>>> I assume you're talking about the one added by cf3e1feba7f

Re: driver skip pci_set_master, fix it? No.

On 14-04-09 09:08 AM, Mark Lord wrote: > On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote: >> On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote: >>>> I assume you're talking about the one added by cf3e1feba7f9 ("PCI: >>>> Workaround missing pci_set_ma

Re: driver skip pci_set_master, fix it? No.

On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote: > On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote: >>> I assume you're talking about the one added by cf3e1feba7f9 ("PCI: >>> Workaround missing pci_set_master in pci drivers"), but as far as I >>>

Re: driver skip pci_set_master, fix it? No.

On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote: On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote: I assume you're talking about the one added by cf3e1feba7f9 (PCI: Workaround missing pci_set_master in pci drivers), but as far as I can tell, it only calls pci_set_master() for *bridge

Re: driver skip pci_set_master, fix it? No.

On 14-04-09 09:08 AM, Mark Lord wrote: On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote: On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote: I assume you're talking about the one added by cf3e1feba7f9 (PCI: Workaround missing pci_set_master in pci drivers), but as far as I can tell, it only

Re: driver skip pci_set_master, fix it? No.

On 14-04-09 10:12 AM, Mark Lord wrote: On 14-04-09 09:08 AM, Mark Lord wrote: On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote: On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote: I assume you're talking about the one added by cf3e1feba7f9 (PCI: Workaround missing pci_set_master in pci

Re: driver skip pci_set_master, fix it? No.

On 14-04-09 11:52 AM, Bjorn Helgaas wrote: On Wed, Apr 9, 2014 at 8:18 AM, Mark Lord ml...@pobox.com wrote: On 14-04-09 10:12 AM, Mark Lord wrote: On 14-04-09 09:08 AM, Mark Lord wrote: On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote: On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote: I

Re: driver skip pci_set_master, fix it? No.

On 14-04-08 02:27 PM, Bjorn Helgaas wrote: > [+cc Ben, linux-pci] > > On Tue, Apr 8, 2014 at 10:34 AM, Mark Lord wrote: >> I am working a couple of drivers for chips that perform extensive >> bus-mastering ops. >> These including full SRIOV support, and allow

driver skip pci_set_master, fix it? No.

e_device(), courtesy of the embedded call to pci_set_master(). This isn't good, and these may not be the only devices affected in this way. Can we perhaps not do that, or provide some other way to return control of bus-mastering to the device driver ? -- ml...@pobox.com Mark Lord -- To unsubscribe

  1   2   3   4   5   6   7   8   9   10   >