Re: 6.0-RC1 Panic

On Friday 14 October 2005 03:17 pm, John Baldwin wrote:
> On Wednesday 12 October 2005 07:24 pm, Benjamin Close wrote:
> > Hi All,
> >     I can repeatedly get this panic at boot if I have my wi0 (802.11b
> > Lucent / Hermes chipset) card in my laptop.
> >
> > Fatal trap 18: integer divide fault while in kernel mode
> > instruction pointer     = 0x20:0xc06474fa
> > stack pointer           = 0x28:0xd9927c78
> > frame pointer           = 0x28:0xd9927c88
> > code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                         = DPL 0, pres 1, def32 1, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 242 (netstat)
> > trap number             = 18
> > panic: integer divide fault
> > Uptime: 3m32s
> > Dumping 511 MB (2 chunks)
> >   chunk 0: 1MB (159 pages) ... ok
> >   chunk 1: 511MB (130794 pages) 495 479 463 447 431 415 399 383 367 351
> > 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111
> >  95 79 63 47 31 15
> >
> > Full Details below...
>
> Hmm, so it looks like maybe your ipfw.ko KLD doesn't have a DT_HASH
> section. Try doing an objdump of your ipfw.ko and see if it has a .hash. 
> Here's the
>
> objdump from the ipfw.ko on my laptop:
> > objdump -h /boot/kernel.GENERIC/ipfw.ko | head
>
> /boot/kernel.GENERIC/ipfw.ko:     file format elf32-i386-freebsd
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .hash         00000348  00000094  00000094  00000094  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   1 .dynsym       000006f0  000003dc  000003dc  000003dc  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   2 .dynstr       00000439  00000acc  00000acc  00000acc  2**0
>
> Note the .hash as the first section.
>
> You can also try this patch which might fix the problem (though your
> ipfw.ko still won't load):
>
> Index: kern/link_elf.c
> ===================================================================
> RCS file: /usr/cvs/src/sys/kern/link_elf.c,v
> retrieving revision 1.84
> diff -u -r1.84 link_elf.c
> --- kern/link_elf.c	28 Aug 2005 04:50:11 -0000	1.84
> +++ kern/link_elf.c	14 Oct 2005 19:16:48 -0000
> _at__at_ -1019,6 +1019,12 _at__at_
>      unsigned long hash;
>      int i;
>
> +    /* If we don't have a hash, bail. */
> +    if (ef->buckets == NULL || ef->nbuckets == 0) {
> +	printf("link_elf_lookup_symbol: missing symbol hash table\n");
> +	return ENOENT;
> +    }
> +
>      /* First, search hashed global symbols */
>      hash = elf_hash(name);
>      symnum = ef->buckets[hash % ef->nbuckets];

Did you ever resolve your issue and/or get a chance to test this patch to see 
if it at least kept the kernel from panicing?

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org