kernel panic, unknown / reserved trap

Andre Oppermann andre at freebsd.org
Wed Sep 1 17:20:26 PDT 2004


Sam wrote:
> Hello,
> 
> I'm working on a driver for AoE (ATA over Ethernet)
> for the 4.x kernel (check recent freebsd-arch
> postings for info).  I have modified a few files in order to support 
> catching ethernet frames of type
> 0x88a2.  The make kernel completes successfully,
> but on boot the kernel panics with an unknown/reserved
> trap failure.  I've modified the following:
> 
> freebsd% for i in `find . -type f | tr \\\n ' '`; do
> 
>> echo $i; diff $i ../sysorig/$i; done

Please provice unified diffs.  That makes them a lot easier to read.

> ./net/ethernet.h
> 310d309
> < #define       ETHERTYPE_AOE           0x88A2  /* ATA over Ethernet */
> ./net/if_ethersubr.c
> 43d42
> < #include "opt_aoe.h"
> 103,106d101
> < #ifdef AOE
> < struct ifqueue *aoeintrq;
> < #endif /* AOE */
> <
> 751,761d745
> < #ifdef AOE
> <       case ETHERTYPE_AOE:
> <               if(aoeintrq) {
> <                       schednetisr(NETISR_AOE);
> <                       inq = aoeintrq;
> <                       break;
> <               }
> <               m_freem(m);
		  ^^^^^^^^^^
This looks wrong.  If you free the packet here you get a stale pointer
in the netisr queue leading to interesting panics. ;-)  If there is no
aoeintrq then it will free'd at the end of the switch statement.

> <               return;
> < #endif /* AOE */
> <
> ./net/netisr.h
> 59d58
> < #define       NETISR_AOE      17      /* ATA over Ethernet */
> ./conf/options
> 256,258d255
> < # AoE network option
> < AOE                   opt_aoe.h
> <
> ./conf/files
> 288,293d287
> < dev/aoe/aoe.c         optional aoe
> < dev/aoe/aoedev.c      optional aoe
> < dev/aoe/aoecmd.c      optional aoe
> < dev/aoe/aoenet.c      optional aoe
> < dev/aoe/aoeblk.c      optional aoe
> < dev/aoe/utils.c               optional aoe
> 
> I've also added dev/aoe/ with the files listed
> above and modules/aoe/ with a makefile similar
> to modules/md/Makefile.
> 
> I don't really see how what I did is causing
> the kernel to panic so early ... is anything
> obvious?

-- 
Andre



More information about the freebsd-hackers mailing list