From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 16 12:43:27 2015 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E065CC4E for ; Mon, 16 Mar 2015 12:43:27 +0000 (UTC) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50CC1A4C for ; Mon, 16 Mar 2015 12:43:27 +0000 (UTC) Received: by wibg7 with SMTP id g7so36633813wib.1 for ; Mon, 16 Mar 2015 05:43:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=Km8gOxNZujHeLpGk8J9gtQAbJSQ70G2TqlHteafk+NM=; b=bWiiZLgylg1US7Gxe1/VneevViF90Jhr3yqAFf2bBmR7IXfC0/Pow97uw+j5WdNQim 9TKpmDZ6uIf9N/4eiirxt2/T0SBNvnQc0tQkGDMRhTyXe89yTnSIi1kkFo1U9IMvl33R fAnLfdasDRnt4BEVuEujvhPIAZVKfhIorH9GrRiWji3VAm85AWXOTzcBDCDIAToLhiam 3k/O5C5wM1nRk8/xFN0DoD4rSmxjYbMuZ9V63kUwFsffWcvHEMaZEyiABv/Pl3NTfyLS 5h5biGX/1+WuULjvtPgwuS1jJxNokv6n2qrtEsrAx/Pc2Np9jTr57lbZ9dtsdslj1TcD wk2w== X-Gm-Message-State: ALoCoQn8mbKueUgoWd1oStYXf0OYbQ8PsC1X8lECfC1X0lGyB8EIz/QxH9JqTahr0wXuOOch576F X-Received: by 10.180.106.225 with SMTP id gx1mr166621142wib.53.1426509805430; Mon, 16 Mar 2015 05:43:25 -0700 (PDT) From: Sibananda Sahu References: 4d8df3d1c15489c01665e69703ab0050@mail.gmail.com In-Reply-To: 4d8df3d1c15489c01665e69703ab0050@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBcvKnIAR8sP8a0TDu6+GipRP0OvADJdM5A Date: Mon, 16 Mar 2015 18:13:22 +0530 Message-ID: <44ed50503f6c017a18c4d9df294c7391@mail.gmail.com> Subject: RE: Kenrel panic in bus_dmamem_alloc() To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 12:43:28 -0000 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: 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=, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 #2 0xffffffff8033f08d in db_command (cmd_table=) 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=, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff808b9bc3 in kdb_trap (type=9, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:656 #6 0xffffffff80c4b442 in trap_fatal (frame=0xfffffe01213d4120, eva=) at /usr/src/sys/amd64/amd64/trap.c:877 #7 0xffffffff80c4b0bf in trap (frame=) 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=, npages=, low=0, high=18446735281027570048, alignment=, boundary=) 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=) 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=, 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