Date: Mon, 16 Mar 2015 18:13:22 +0530 From: Sibananda Sahu <sibananda.sahu@avagotech.com> To: freebsd-scsi@freebsd.org Subject: RE: Kenrel panic in bus_dmamem_alloc() Message-ID: <44ed50503f6c017a18c4d9df294c7391@mail.gmail.com> In-Reply-To: 4d8df3d1c15489c01665e69703ab0050@mail.gmail.com References: 4d8df3d1c15489c01665e69703ab0050@mail.gmail.com
next in thread | raw e-mail | index | archive | help
Hi,
Regarding this issue I have some more information to update.
System info:
- FreeBSD 10.0-RELEASE
- Amd64
- 4GB of memory
The bus_dmamem_alloc() tries to allocate 3796992 bytes of contiguous memory.
The size that this call asks is exactly 927 pages.
#11 0xffffffff80acc153 in kmem_alloc_contig (vmem=0xffffffff8144bd80,
size=3796992, flags=1, low=0, high=4294967295, alignment=4)
at /usr/src/sys/vm/vm_kern.c:239
After loading and unloading the mrsas.ko module for several times it
crashes at bus_dmamem_alloc().
When I modified the size from 3796992 bytes to 3801088 bytes, which is
exactly 928 pages, I have observed that:
I loaded mrsas.ko and unloaded immediately.
Again I loaded mrsas.ko and the system just crashed at bus_dmamem_alloc().
Following are the dma tag and memory allocation calls:
/*
* Allocate Chain Frames
*/
chain_frame_size = sc->chain_frames_alloc_sz; //
chain_frame_size accounts for 3796992 bytes
if (bus_dma_tag_create(sc->mrsas_parent_tag,
4, 0,
BUS_SPACE_MAXADDR_32BIT,
BUS_SPACE_MAXADDR,
NULL, NULL,
chain_frame_size,
1,
chain_frame_size,
BUS_DMA_ALLOCNOW,
NULL, NULL,
&sc->chain_frame_tag)) {
device_printf(sc->mrsas_dev, "Cannot create chain frame tag\n");
return (ENOMEM);
}
if (bus_dmamem_alloc(sc->chain_frame_tag, (void **)&sc->chain_frame_mem,
BUS_DMA_NOWAIT, &sc->chain_frame_dmamap)) {
device_printf(sc->mrsas_dev, "Cannot alloc chain frame memory\n");
return (ENOMEM);
}
bzero(sc->chain_frame_mem, chain_frame_size);
if (bus_dmamap_load(sc->chain_frame_tag, sc->chain_frame_dmamap,
sc->chain_frame_mem, chain_frame_size, mrsas_addr_cb,
&sc->chain_frame_phys_addr, BUS_DMA_NOWAIT)) {
device_printf(sc->mrsas_dev, "Cannot load chain frame memory\n");
return (ENOMEM);
}
Following are the de-allocations made while unloading the driver:
/*
* Free chain frame memory
*/
if (sc->chain_frame_phys_addr)
bus_dmamap_unload(sc->chain_frame_tag, sc->chain_frame_dmamap);
if (sc->chain_frame_mem != NULL)
bus_dmamem_free(sc->chain_frame_tag, sc->chain_frame_mem,
sc->chain_frame_dmamap);
if (sc->chain_frame_tag != NULL)
bus_dma_tag_destroy(sc->chain_frame_tag);
Why the kernel panics when I load the driver for second time and not the
first time??
Am I doing something wrong somewhere while allocating the dma tag or
memory??
Or am I leaving to release some extra stuffs while unloading the driver??
Is there any memory allocation limitations either from architecture or OS
design?
Please suggest me what to do on this case and what is the reason for this
behaviour???
Please tell me if some more information is required.
I hope I will get some response this time.
Thanks,
Sibananda Sahu
*From:* Sibananda Sahu [mailto:sibananda.sahu@avagotech.com]
*Sent:* Thursday, March 12, 2015 5:34 PM
*To:* 'freebsd-scsi@freebsd.org'
*Subject:* Kenrel panic in bus_dmamem_alloc()
Hi,
Recently I was working with the mrsas(4) driver and found that after
several operations when I unload and reload the driver the kernel was
entering into panic at the bus_dmamem_alloc() call.
I have attached the core.txt file.
Although this is primarily not related to SCSI, but still I thought if any
kind of help from any kernel developers will be very much helpful.
Below is the Back trace info extracted from the core text file:
Unread portion of the kernel message buffer:
AVAGO MegaRAID SAS FreeBSD mrsas driver version: 06.708.09.00
mrsas0: <AVAGO Invader SAS Controller> port 0xfc00-0xfcff mem
0xdf2f0000-0xdf2fffff,0xdf300000-0xdf3fffff irq 32 at device 0.0 on pci5
mrsas0: Waiting for FW to come to ready state
mrsas0: FW now in Ready state
mrsas0: Using MSI-X with 4 number of vectors
mrsas0: FW supports <96> MSIX vector,Online CPU 4 Current MSIX <4>
mrsas0: Avago Debug: MAX sge 0x106 MAX chain frame size 0x1000
mrsas0: Allocating ver buf memory size 256
mrsas0: Allocating IO req memory 237824
mrsas0: Allocating chain frame memory 3796992
Fatal trap 9: general protection fault while in kernel mode
cpuid = 2; apic id = 32
instruction pointer = 0x20:0xffffffff80ae16f3
stack pointer = 0x28:0xfffffe01213d41d0
frame pointer = 0x28:0xfffffe01213d4240
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1,
def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 1406 (kldload)
Error while mapping shared library sections:
./mrsas.ko: No such file or directory.
Reading symbols from /boot/kernel/ums.ko.symbols...done.
Loaded symbols for /boot/kernel/ums.ko.symbols
Reading symbols from /boot/kernel/uftdi.ko.symbols...done.
Loaded symbols for /boot/kernel/uftdi.ko.symbols
Reading symbols from /boot/kernel/ucom.ko.symbols...done.
Loaded symbols for /boot/kernel/ucom.ko.symbols
Error while reading shared library symbols:
./mrsas.ko: No such file or directory.
#0 doadump (textdump=0) at pcpu.h:219
219 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0 doadump (textdump=0) at pcpu.h:219
#1 0xffffffff8033f5ae in db_dump (dummy=<value optimized out>, dummy2=0,
dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543
#2 0xffffffff8033f08d in db_command (cmd_table=<value optimized out>)
at /usr/src/sys/ddb/db_command.c:449
#3 0xffffffff8033ee04 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:502
#4 0xffffffff80341720 in db_trap (type=<value optimized out>, code=0)
at /usr/src/sys/ddb/db_main.c:231
#5 0xffffffff808b9bc3 in kdb_trap (type=9, code=0, tf=<value optimized
out>)
at /usr/src/sys/kern/subr_kdb.c:656
#6 0xffffffff80c4b442 in trap_fatal (frame=0xfffffe01213d4120,
eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:877
#7 0xffffffff80c4b0bf in trap (frame=<value optimized out>)
at /usr/src/sys/amd64/amd64/trap.c:224
#8 0xffffffff80c32d02 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:232
#9 0xffffffff80ae16f3 in vm_reserv_alloc_contig
(object=0xffffffff8166d9c8,
pindex=<value optimized out>, npages=<value optimized out>, low=0,
high=18446735281027570048, alignment=<value optimized out>,
boundary=<value optimized out>) at /usr/src/sys/vm/vm_reserv.c:252
#10 0xffffffff80ada2ee in vm_page_alloc_contig (object=0xffffffff8166d9c8,
pindex=1183744, req=546, npages=927, low=0, high=4294967295,
memattr=<value optimized out>) at /usr/src/sys/vm/vm_page.c:1741
#11 0xffffffff80acc153 in kmem_alloc_contig (vmem=0xffffffff8144bd80,
size=3796992, flags=1, low=0, high=4294967295, alignment=4)
at /usr/src/sys/vm/vm_kern.c:239
#12 0xffffffff80d454cd in bus_dmamem_alloc (dmat=0xfffff80099ba3480,
vaddr=0xfffffe00019aa0b8, flags=<value optimized out>,
mapp=0xfffffe00019aa0b0) at /usr/src/sys/x86/x86/busdma_machdep.c:551
#13 0xffffffff81a2500b in ?? ()
#14 0x0000000000000000 in ?? ()
Current language: auto; currently minimal
(kgdb)
Can anybody suggest me what might have gone wrong so this disaster
happened???
Thanks,
Sibananda Sahu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44ed50503f6c017a18c4d9df294c7391>