On Sat, Oct 24, 2009 at 01:56:51PM +0200, Christopher Zimmermann wrote: > Hello again! > > In porting this SIS191 driver from freeBSD I'm stuck trying to fix a > kernel panic in pool_do_get: > > panic: pool_do_get(mbpl: free list modified >
Free list modified means that you hit a use after free or even worse overflowed the previous mbuf and wrote data into the the mbuf you try to allocate now. > trace: > panic() > pool_do_get() > pool_get() > m_gethdr() > > What I don't understand is in my driver m_gethdr(M_DONTWAIT, M_DATA) is > called. Therefore pool_get should only get pool_get(&mbpool, 0). > So what is my driver doing wrong to produce this crash??? > Could it be a hint that my driver is leaking memory? > More that it is writing data into memory it should not touch. Make sure you map the mbuf correctly into the DMA ring and remove it correctly from the ring before passing it on to ether_input. > What is also very funny is that this panic is very accurately > reproducible. When doing a scp (big packets ?!) to produce some traffic > it almost always panics exactly when handling the 80th interupt for rx > packets. > > When doing ping (small packets ?!) it happens in the 256th packet, > therefore when the rx-ring is wrapping. But this may be yet another bug? > This sounds like you map the mbuf as cluster without attachin a cluster to it and so the dma length is wrong. FreeBSD has a special function to return mbufs + clusters that is not implemented in OpenBSD. We on the other hand have MCLGETI which does the same and way more. I guess you need to check your newbuf function. > Any ideas or hints? I'm pretty lost in all this mbuf handling. The > manpage doesn't help me too much and looking at other drivers confuses > me even more, although they all look pretty similar in the rxeof() > functions. > It would help to see the code in question. I bet it is just a two or three line change to make it work but finding can be painful (been there many times). -- :wq Claudio
