diff for duplicates of <49A14956.7080500@gmail.com> diff --git a/a/1.txt b/N1/1.txt index d21d5cf..eff8ecf 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,28 +1,18 @@ On 22.2.2009 13:20, Sitsofe Wheeler wrote: > On Sun, Feb 22, 2009 at 01:01:21PM +0100, Jiri Slaby wrote: ->> The unsupported jumbo message might be a clue. When we jump to the n= -ext: +>> The unsupported jumbo message might be a clue. When we jump to the next: >> label, the buffer is at the end of the list in software, while in >> hardware it isn't. In theory, we might hit the bug with rx buffers ->> exhaustion, because the test (bf_last =3D=3D bf) doesn't work as exp= -ected then. +>> exhaustion, because the test (bf_last == bf) doesn't work as expected then. > > This seems to be happening somewhat regularly now - I've got a small > collections of the warnings (I'll include them below in case they are > any help): [...] -> [11207.741042] Object 0xd7060000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b= - 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk -> [11207.741071] Object 0xd7060010: 80 00 00 00 ff ff ff ff ff ff 00= - 30 ab 1a 32 3f ....=FF=FF=FF=FF=FF=FF.0=AB.2? +> [11207.741042] Object 0xd7060000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk +> [11207.741071] Object 0xd7060010: 80 00 00 00 ff ff ff ff ff ff 00 30 ab 1a 32 3f ....ÿÿÿÿÿÿ.0«.2? -All of them are almost the same scenario, the last one was data not=20 -beacon, but it's irrelevant. And previously I was wrong, we move the=20 -buffer to the end even on hardware side. Thanks so far, I personally se= -e=20 +All of them are almost the same scenario, the last one was data not +beacon, but it's irrelevant. And previously I was wrong, we move the +buffer to the end even on hardware side. Thanks so far, I personally see no reason for this to happen yet. --- -To unsubscribe from this list: send the line "unsubscribe linux-wireles= -s" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 868329f..51066e1 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -15,31 +15,21 @@ "b\0" "On 22.2.2009 13:20, Sitsofe Wheeler wrote:\n" "> On Sun, Feb 22, 2009 at 01:01:21PM +0100, Jiri Slaby wrote:\n" - ">> The unsupported jumbo message might be a clue. When we jump to the n=\n" - "ext:\n" + ">> The unsupported jumbo message might be a clue. When we jump to the next:\n" ">> label, the buffer is at the end of the list in software, while in\n" ">> hardware it isn't. In theory, we might hit the bug with rx buffers\n" - ">> exhaustion, because the test (bf_last =3D=3D bf) doesn't work as exp=\n" - "ected then.\n" + ">> exhaustion, because the test (bf_last == bf) doesn't work as expected then.\n" ">\n" "> This seems to be happening somewhat regularly now - I've got a small\n" "> collections of the warnings (I'll include them below in case they are\n" "> any help):\n" "[...]\n" - "> [11207.741042] Object 0xd7060000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b=\n" - " 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n" - "> [11207.741071] Object 0xd7060010: 80 00 00 00 ff ff ff ff ff ff 00=\n" - " 30 ab 1a 32 3f ....=FF=FF=FF=FF=FF=FF.0=AB.2?\n" + "> [11207.741042] Object 0xd7060000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n" + "> [11207.741071] Object 0xd7060010: 80 00 00 00 ff ff ff ff ff ff 00 30 ab 1a 32 3f ....\303\277\303\277\303\277\303\277\303\277\303\277.0\302\253.2?\n" "\n" - "All of them are almost the same scenario, the last one was data not=20\n" - "beacon, but it's irrelevant. And previously I was wrong, we move the=20\n" - "buffer to the end even on hardware side. Thanks so far, I personally se=\n" - "e=20\n" - "no reason for this to happen yet.\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-wireles=\n" - "s\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + "All of them are almost the same scenario, the last one was data not \n" + "beacon, but it's irrelevant. And previously I was wrong, we move the \n" + "buffer to the end even on hardware side. Thanks so far, I personally see \n" + no reason for this to happen yet. -c8e68123040688a7251762c670a80c36cbc4fa3719751207099d93b4847161ab +7cbaef23bf90285d1958ad3eb47a46d9824b46e269257bf00d206ce7c0a32964
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.