| Message ID | 555CB8C1.1040007@lwfinger.net (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On 20 May 2015 at 19:39, Larry Finger <Larry.Finger@lwfinger.net> wrote: > On 05/20/2015 01:17 AM, Haggai Eran wrote: >> >> On May 19, 2015 08:47, "Haggai Eran" <haggai.eran@gmail.com >> <mailto:haggai.eran@gmail.com>> wrote: >> > >> > With an RTL8191SU USB adaptor, sometimes the hints for a fragmented >> > packet are set, but the packet length is too large. Truncate the packet >> > to prevent memory corruption. >> > >> > Signed-off-by: Haggai Eran <haggai.eran@gmail.com >> <mailto:haggai.eran@gmail.com>> >> > --- >> > >> > Hi, >> > >> > I think this solves the issue for me. I'll test it more thoroughly >> later. I >> > still don't know why a fragmented packet has such a large pkt_len value >> though. >> > >> > Thanks, >> > Haggai >> > >> >> I guess I was too quick with this patch. It prevents the kernel page >> faults, but >> with it I still see sometimes the connectivity disappear for a minute or >> two. > > > Is anything logged when that happens? No. I get once in a while the other corrupted entries I told you about, but nothing special to these freezes > I'm still trying to see where that magic number of 1658 comes from, and how > that affects the RX buffer size. I tried to look at the new driver (rtl8192su), but it doesn't seem to handle this more-fragment bit at all. > When I unconditionally set alloc_sz to tmp_len as in the attached patch (I > remembered to refresh it this time), nothing bad has happened here yet. What > happens on your box? The same freezes still occur. Thanks, Haggai -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 20 May 2015 at 22:20, Haggai Eran <haggai.eran@gmail.com> wrote: > On 20 May 2015 at 19:39, Larry Finger <Larry.Finger@lwfinger.net> wrote: >> On 05/20/2015 01:17 AM, Haggai Eran wrote: >>> >>> On May 19, 2015 08:47, "Haggai Eran" <haggai.eran@gmail.com >>> <mailto:haggai.eran@gmail.com>> wrote: >>> > >>> > With an RTL8191SU USB adaptor, sometimes the hints for a fragmented >>> > packet are set, but the packet length is too large. Truncate the packet >>> > to prevent memory corruption. >>> > >>> > Signed-off-by: Haggai Eran <haggai.eran@gmail.com >>> <mailto:haggai.eran@gmail.com>> >>> > --- >>> > >>> > Hi, >>> > >>> > I think this solves the issue for me. I'll test it more thoroughly >>> later. I >>> > still don't know why a fragmented packet has such a large pkt_len value >>> though. >>> > >>> > Thanks, >>> > Haggai >>> > >>> >>> I guess I was too quick with this patch. It prevents the kernel page >>> faults, but >>> with it I still see sometimes the connectivity disappear for a minute or >>> two. >> >> >> Is anything logged when that happens? > No. I get once in a while the other corrupted entries I told you > about, but nothing special to these freezes > >> I'm still trying to see where that magic number of 1658 comes from, and how >> that affects the RX buffer size. > > I tried to look at the new driver (rtl8192su), but it doesn't seem to > handle this more-fragment bit at all. > >> When I unconditionally set alloc_sz to tmp_len as in the attached patch (I >> remembered to refresh it this time), nothing bad has happened here yet. What >> happens on your box? > > The same freezes still occur. I think the freezes I saw weren't related to the same issue. I was running a debugging kernel, and I saw the same freezes also with a different wifi adaptor. After switching to a non-debugging kernel, and using your patch, the freezes stopped. Thanks, Haggai -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/23/2015 12:24 PM, Haggai Eran wrote: > On 20 May 2015 at 22:20, Haggai Eran <haggai.eran@gmail.com> wrote: >> On 20 May 2015 at 19:39, Larry Finger <Larry.Finger@lwfinger.net> wrote: >>> On 05/20/2015 01:17 AM, Haggai Eran wrote: >>>> >>>> On May 19, 2015 08:47, "Haggai Eran" <haggai.eran@gmail.com >>>> <mailto:haggai.eran@gmail.com>> wrote: >>>> > >>>> > With an RTL8191SU USB adaptor, sometimes the hints for a fragmented >>>> > packet are set, but the packet length is too large. Truncate the packet >>>> > to prevent memory corruption. >>>> > >>>> > Signed-off-by: Haggai Eran <haggai.eran@gmail.com >>>> <mailto:haggai.eran@gmail.com>> >>>> > --- >>>> > >>>> > Hi, >>>> > >>>> > I think this solves the issue for me. I'll test it more thoroughly >>>> later. I >>>> > still don't know why a fragmented packet has such a large pkt_len value >>>> though. >>>> > >>>> > Thanks, >>>> > Haggai >>>> > >>>> >>>> I guess I was too quick with this patch. It prevents the kernel page >>>> faults, but >>>> with it I still see sometimes the connectivity disappear for a minute or >>>> two. >>> >>> >>> Is anything logged when that happens? >> No. I get once in a while the other corrupted entries I told you >> about, but nothing special to these freezes >> >>> I'm still trying to see where that magic number of 1658 comes from, and how >>> that affects the RX buffer size. >> >> I tried to look at the new driver (rtl8192su), but it doesn't seem to >> handle this more-fragment bit at all. >> >>> When I unconditionally set alloc_sz to tmp_len as in the attached patch (I >>> remembered to refresh it this time), nothing bad has happened here yet. What >>> happens on your box? >> >> The same freezes still occur. > > I think the freezes I saw weren't related to the same issue. I was > running a debugging kernel, and I saw the same freezes also with a > different wifi adaptor. After switching to a non-debugging kernel, and > using your patch, the freezes stopped. That is good news. Perhaps the debugging kernel is overflowing the stack. Did your debugging kernel have "Check for stack overflows" set in the "Memory Debugging" section of the configuration? I did not have that turned on until today, but it seems like a good idea. Do you want to prepare the final version of the patch, or should I? Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23 May 2015 at 20:48, Larry Finger <Larry.Finger@lwfinger.net> wrote: > That is good news. Perhaps the debugging kernel is overflowing the stack. > Did your debugging kernel have "Check for stack overflows" set in the > "Memory Debugging" section of the configuration? I did not have that turned > on until today, but it seems like a good idea. No, I don't think they have it implemented for ARM. > Do you want to prepare the final version of the patch, or should I? I can send an updated patch. Thanks, Haggai -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: wireless-drivers-next/drivers/staging/rtl8712/rtl8712_recv.c =================================================================== --- wireless-drivers-next.orig/drivers/staging/rtl8712/rtl8712_recv.c +++ wireless-drivers-next/drivers/staging/rtl8712/rtl8712_recv.c @@ -1053,12 +1053,7 @@ static int recvbuf2recvframe(struct _ada precvframe->u.hdr.len = 0; tmp_len = pkt_len + drvinfo_sz + RXDESC_SIZE; pkt_offset = (u16)round_up(tmp_len, 128); - /* for first fragment packet, driver need allocate 1536 + - * drvinfo_sz + RXDESC_SIZE to defrag packet. */ - if ((mf == 1) && (frag == 0)) - alloc_sz = 1658;/*1658+6=1664, 1664 is 128 alignment.*/ - else - alloc_sz = tmp_len; + alloc_sz = tmp_len; /* 2 is for IP header 4 bytes alignment in QoS packet case. * 4 is for skb->data 4 bytes alignment. */ alloc_sz += 6;