Date: Mon, 31 Aug 2015 18:20:31 -0700 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org, cem@freebsd.org Subject: Re: Panic on boot during scan with pmspcv Message-ID: <1907622.HsVbIIOtmz@ralph.baldwin.cx> In-Reply-To: <CAG6CVpU4dP3jFag8A1fLaYpPwqSeErL54iERL5iFMAKbmW=Bdw@mail.gmail.com> References: <CAG6CVpU4dP3jFag8A1fLaYpPwqSeErL54iERL5iFMAKbmW=Bdw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, August 25, 2015 02:27:42 PM Conrad Meyer wrote: > For some reason, it only crops up on UEFI boot. "Legacy" boot "just works." > > It looks like we're locking a mutex in a struct at NULL. > > (trap) > __mtx_assert+0xdb > agtiapi_cam_action+0x45 > xpt_action_default+0xbe3(?) > scsi_scan_bus+0x1cd > xpt_scanner_thread+0x15c > ... > > > Fault is at 0x18. > > http://i.imgur.com/615PC6b.jpg > > (kgdb) l *(agtiapi_cam_action+0x45) > 0xffffffff806d4ef5 is in agtiapi_cam_action > (/usr/src/sys/dev/pms/freebsd/driver/ini/src/agtiapi.c:1818). > > Possibly here? > > 1814 mtx_assert( &(pmcsc->pCardInfo->pmIOLock), MA_OWNED ); Probably pCardInfo is NULL. Looking at the pms driver source is making my stomach churn, but I don't see anything obvious. The field is set during attach, so it shouldn't be NULL when the intrhook runs. Do you have any other storage devices on this box? If so, I would try to kldload the pms driver after you have booted far enough to setup dumps (either that or setup remote kgdb). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1907622.HsVbIIOtmz>