Date: Wed, 24 Sep 2014 10:48:20 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: current@FreeBSD.org Subject: Re: Cam panic on r271170 Message-ID: <5422E7C4.8070801@FreeBSD.org> In-Reply-To: <5419AB24.9050809@FreeBSD.org> References: <5418F1B9.2000903@FreeBSD.org> <5419AB24.9050809@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PaQh5Jrvt03dJs7Ub5bBEj0okIPdEhkuc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/17/2014 10:39 AM, Bryan Drewery wrote: > On 9/16/2014 9:28 PM, Bryan Drewery wrote: >> I've been getting this quite frequently on head recently. I have dumps= >> if anyone is interested in more information. >> >>> Fatal trap 9: general protection fault while in kernel mode >>> cpuid =3D 10; Memory modified after free 0xfffff8003e0b0800(2040) >>> val=3Dffffffff @ 0xfffff8003e0b0808 >>> apanic: Most recently used by CAM CCB >>> >>> cpuid =3D 6 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xfffffe124735b4c0 >>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe124735b570 >>> vpanic() at vpanic+0x189/frame 0xfffffe124735b5f0 >>> panic() at panic+0x43/frame 0xfffffe124735b650 >>> mtrash_ctor() at mtrash_ctor+0x8a/frame 0xfffffe124735b680 >>> uma_zalloc_arg() at uma_zalloc_arg+0x4f1/frame 0xfffffe124735b6f0 >>> malloc() at malloc+0x192/frame 0xfffffe124735b740 >>> xpt_run_allocq() at xpt_run_allocq+0xb5/frame 0xfffffe124735b780 >>> adastrategy() at adastrategy+0x117/frame 0xfffffe124735b7b0 >>> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b810 >>> g_part_start() at g_part_start+0x2b7/frame 0xfffffe124735b890 >>> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b8f0 >>> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b950 >>> vdev_geom_io_start() at vdev_geom_io_start+0x137/frame 0xfffffe124735= b970 >>> zio_vdev_io_start() at zio_vdev_io_start+0x49f/frame 0xfffffe124735b9= d0 >>> zio_execute() at zio_execute+0x204/frame 0xfffffe124735ba30 >>> vdev_queue_io_done() at vdev_queue_io_done+0x180/frame 0xfffffe124735= ba80 >>> zio_vdev_io_done() at zio_vdev_io_done+0x11d/frame 0xfffffe124735bac0= >>> zio_execute() at zio_execute+0x204/frame 0xfffffe124735bb20 >>> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame >>> 0xfffffe124735bb80 >>> taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame >>> 0xfffffe124735bbb0 >>> fork_exit() at fork_exit+0x84/frame 0xfffffe124735bbf0 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe124735bbf0 >>> --- trap 0, rip =3D 0, rsp =3D 0xfffffe124735bcb0, rbp =3D 0 --- >>> KDB: enter: panic >>> [ thread pid 0 tid 100571 ] >>> Stopped at kdb_enter+0x3e: movq $0,kdb_why >> >> >=20 > I also had this one recently: >=20 >> #8 0xffffffff80d1a162 in calltrap () at /usr/src/sys/amd64/amd64/exce= ption.S:231 >> #9 0xffffffff802e52c4 in xpt_path_periph (path=3D0xdeadc0dedeadc0de) = at /usr/src/sys/cam/cam_xpt.c:3738 >> #10 0xffffffff802dfe62 in cam_periph_error (ccb=3D0xfffff8003e0b6000, = camflags=3DCAM_FLAG_NONE, sense_flags=3D0, save_ccb=3D0x0) at /usr/src/sy= s/cam/cam_periph.c:1602 >> #11 0xffffffff803057e4 in adadone (periph=3D0xfffff8003e09b700, done_c= cb=3D0xfffff8003e0b6000) at /usr/src/sys/cam/ata/ata_da.c:1877 >> #12 0xffffffff802e6e44 in xpt_done_process (ccb_h=3D0xfffff8003e0b6000= ) at /usr/src/sys/cam/cam_xpt.c:5245 >> #13 0xffffffff80394d59 in ahci_ch_intr_direct (arg=3D<value optimized = out>) at /usr/src/sys/dev/ahci/ahci.c:1132 >> #14 0xffffffff80390ff1 in ahci_intr (data=3D<value optimized out>) at = /usr/src/sys/dev/ahci/ahci.c:417 >> #15 0xffffffff808ea5d3 in intr_event_execute_handlers (p=3D<value opti= mized out>, ie=3D0xfffff8000f725d00) at /usr/src/sys/kern/kern_intr.c:125= 2 >> #16 0xffffffff808eafb6 in ithread_loop (arg=3D0xfffff8000f6dea60) at /= usr/src/sys/kern/kern_intr.c:1265 >> #17 0xffffffff808e7fc4 in fork_exit (callout=3D0xffffffff808eaf10 <ith= read_loop>, arg=3D0xfffff8000f6dea60, frame=3D0xfffffe1245083c00) at /usr= /src/sys/kern/kern_fork.c:977 >> #18 0xffffffff80d1a69e in fork_trampoline () at /usr/src/sys/amd64/amd= 64/exception.S:605 >=20 >=20 Another, with much more information here: https://people.freebsd.org/~bdrewery/cam.panic.txt This was with memguard (vm.memguard.desc=3D"CAM CCB") and a KASSERT in malloc(9) and uma_zalloc_arg() to prevent M_WAITOK in non-sleepable threads. Neither triggered. It seems to be when syncing to the SSD ZFS log I have. --=20 Regards, Bryan Drewery --PaQh5Jrvt03dJs7Ub5bBEj0okIPdEhkuc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUIufEAAoJEDXXcbtuRpfPhp4IAIo8L8c6/j/tFahivDBuXmAG IAfQgJ7EdXDdsRMEDqFK+4B10hwUkx1u685j6wKc+GDDKqsJsyV8TyNyiCPafDqN iLzjMYvwp67ir0VNy8v8MTeAMS5Cl/WSF96EgvqO6YIA2OHZdLn3psCHjZ5lJoJm rLl+UUK2Jo/zCtCY0TPy4RZFu2aPCDNhpiWaZM+Hj8/U3ay/wDpiehTXlaoTPNtE Z/eJht7vuA7/jiCurqo8TipqcgNqTMZ3XXzFt0rpClsVc5Br5KvRw/+uhevz44GL X9sZ7l5JmCDUw8rQaXavQMBZhSfjo9dbouU5XyoGCqh9ZT3NrWHmwFWitwUUvDA= =J9aq -----END PGP SIGNATURE----- --PaQh5Jrvt03dJs7Ub5bBEj0okIPdEhkuc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5422E7C4.8070801>