On Wed, Apr 15, 2015 at 11:31:52AM +0200, Martin Pieuchot wrote: > On 14/04/15(Tue) 16:58, Theo Buehler wrote: > > >Synopsis: panic: ipintr no HDR > > >Category: kernel amd64 > > >Environment: > > System : OpenBSD 5.7 > > Details : OpenBSD 5.7-current (GENERIC.MP) #919: Mon Apr 13 > > 21:03:43 MDT 2015 > > > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > > > I use security/vpnc to connect to my university network via WIFI, using > > > > $ dmesg | grep athn0 > > athn0 at pci2 dev 0 function 0 "Atheros AR5418" rev 0x01: apic 1 int 17 > > athn0: MAC AR5418 rev 2, RF AR5133 (2T3R), ROM rev 4, address > > 00:1b:63:02:1c:22 > > > > and try to download my mail using mail/offlineimap. With both GENERIC and > > GENERIC.MP from the April 14 snapshot, running mail/offlineimap triggers the > > following panic (transcribed by hand below). > > [...] > > >Fix/Workaround: > > > > It seems likely that the panic has to do with this commit: > > https://marc.info/?l=openbsd-cvs&m=142867432629365&w=2 > > see also: > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_input.c.diff?r1=1.247&r2=1.248&f=h > > > > I have a GENERIC.MP kernel compiled from freshly updated sources just two > > hours > > before this commit with which I am unable to reproduce this panic. > > Thanks for tracking the problematic commit, it seems to be a typo, could > you tell me if the diff below fixes the problem? > > Index: net/if_tun.c > =================================================================== > RCS file: /cvs/src/sys/net/if_tun.c,v > retrieving revision 1.136 > diff -u -p -r1.136 if_tun.c > --- net/if_tun.c 10 Apr 2015 13:58:20 -0000 1.136 > +++ net/if_tun.c 15 Apr 2015 09:29:52 -0000 > @@ -897,7 +897,7 @@ tunwrite(dev_t dev, struct uio *uio, int > return (EAFNOSUPPORT); > } > > - if (niq_enqueue(ifq, m) != 0) { > + if (niq_enqueue(ifq, top) != 0) { > ifp->if_collisions++; > return (ENOBUFS); > } >
Thank you for the quick response. I've tried your patch with both GENERIC and GENERIC.MP and it indeed seems to fix the problem. At least I was unable to trigger the panic in 4 attempts on each kernel, previously each attempt resulted in a panic.
