Hello
I'm trying to do a long-term network test on 2 platforms.
One is based on imx6q, the other on imx6ul.
imx6q is using linux-fslc, imx6ul is using linux-imx For that, I enabled the busybox inetd service with the echo protocol enabled. I'm flooding the device with echo requests of 12kiB (0x3000B) Most of the time that goes well, but at certain points, the data returned by the platform is corrupted. After some research, it looks like the data returned is copied from memory address 0 instead of the correct data address. Any idea what can cause this?
Here you'll find a screenshot of wireshark showing this behavior: https://snag.gy/S7cBRl.jpg
Thanks
On Wed, Jun 14, 2017 at 10:43 AM, Vanhauwaert Wouter
[off-list ref] wrote:
Hello
I'm trying to do a long-term network test on 2 platforms.
One is based on imx6q, the other on imx6ul.
imx6q is using linux-fslc, imx6ul is using linux-imx For that, I enabled the busybox inetd service with the echo protocol enabled. I'm flooding the device with echo requests of 12kiB (0x3000B) Most of the time that goes well, but at certain points, the data returned by the platform is corrupted. After some research, it looks like the data returned is copied from memory address 0 instead of the correct data address. Any idea what can cause this?
Here you'll find a screenshot of wireshark showing this behavior: https://snag.gy/S7cBRl.jpg
Does the problem happen if you run kernel 4.11.5 or 4.12-rc?
If it does, then please also include the netdev mailing list.
Regards,
Fabio Estevam
Well, I'm on 4.1.38 now
Will see if I can easily move to 4.11+
-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: woensdag 14 juni 2017 16:12
To: Vanhauwaert Wouter
Cc: linux-arm-kernel at lists.infradead.org
Subject: Re: FEC data corruption?
On Wed, Jun 14, 2017 at 10:43 AM, Vanhauwaert Wouter [off-list ref] wrote:
Hello
I'm trying to do a long-term network test on 2 platforms.
One is based on imx6q, the other on imx6ul.
imx6q is using linux-fslc, imx6ul is using linux-imx For that, I enabled the busybox inetd service with the echo protocol enabled. I'm flooding the device with echo requests of 12kiB (0x3000B) Most of the time that goes well, but at certain points, the data returned by the platform is corrupted. After some research, it looks like the data returned is copied from memory address 0 instead of the correct data address. Any idea what can cause this?
Here you'll find a screenshot of wireshark showing this behavior:
https://snag.gy/S7cBRl.jpg
Does the problem happen if you run kernel 4.11.5 or 4.12-rc?
If it does, then please also include the netdev mailing list.
Regards,
Fabio Estevam
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: woensdag 14 juni 2017 16:12
To: Vanhauwaert Wouter
Cc: linux-arm-kernel at lists.infradead.org
Subject: Re: FEC data corruption?
On Wed, Jun 14, 2017 at 10:43 AM, Vanhauwaert Wouter
[off-list ref] wrote:
quoted
Hello
I'm trying to do a long-term network test on 2 platforms.
One is based on imx6q, the other on imx6ul.
imx6q is using linux-fslc, imx6ul is using linux-imx For that, I enabled the
busybox inetd service with the echo protocol enabled. I'm flooding the
device with echo requests of 12kiB (0x3000B) Most of the time that goes
well, but at certain points, the data returned by the platform is corrupted.
After some research, it looks like the data returned is copied from memory
address 0 instead of the correct data address. Any idea what can cause this?
Does the problem happen if you run kernel 4.11.5 or 4.12-rc?
At the moment, I'm running the test on the imx6q on kernel 4.11.4 (also linux-fslc repo)
And it seems to run without problems... (I'm already beyond 1 000 000 successful packages, still running).
Do you have any idea which commit would influence this?
Wouter
On Thu, Jun 15, 2017 at 6:34 AM, Vanhauwaert Wouter
[off-list ref] wrote:
At the moment, I'm running the test on the imx6q on kernel 4.11.4 (also linux-fslc repo)
And it seems to run without problems... (I'm already beyond 1 000 000 successful packages, still running).
Do you have any idea which commit would influence this?
Not sure, but maybe you could consider to switching to 4.11.4 kernel.