Date: Fri, 22 May 2015 09:48:36 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" Message-ID: <bug-148807-2472-W4zzHMYEdr@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-148807-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-148807-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807 --- Comment #19 from sebastian.huber@embedded-brains.de --- (In reply to sebastian.huber from comment #18) I found one problem with the driver. In the RTEMS port of the network stack I don't use the BUS_DMA(9) support and instead directly use cache invalidate/flush routines (the Altera Cyclone V has no automatic cache coherency between the Ethernet module and the processors). In the receive path it was done like this: invalidate buffer (mcluster) register buffer in receive DMA descriptor ... DMA done hand over buffer to interface input It seems that due to a cache line prefetch sometimes cache lines of the buffer are loaded to the cache after the invalidate, but before the receive DMA completed its transfers. I changed the sequence like this: invalidate buffer (mcluster) register buffer in receive DMA descriptor ... DMA done invalidate buffer hand over buffer to interface input Now it works very stable and I didn't observe a mbuf or socketbuf corruption any more. So as an off hand guess it seems in case the network stack is presented with partially invalid data (previously received IP and TCP headers mixed with new data most likely), then this could lead to a crash in the TCP input processing. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-148807-2472-W4zzHMYEdr>