Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again

On Friday, May 15, 2015 11:39:56 AM David Wolfskill wrote:
> On Fri, May 15, 2015 at 11:40:44AM -0400, John Baldwin wrote:
> > On Saturday, May 09, 2015 07:27:51 AM David Wolfskill wrote:
> > > Ref. <http://docs.FreeBSD.org/cgi/mid.cgi?20150415134515.GQ1224> --
> > > similar symptoms.  And again, I captured screenshots on a phone, but
> > > FreeBSD doesn't seem to recognize the (USB-attached) phone as something
> > > that might act like a file system (I guess; I'm a bit new to
> > > "smartphones").
> > > 
> > > In this case, my starting-point was r282623; sources were updated to
> > > r282676.  I was able to update from:
> > ...
> > > Stopped at ... = hdaa_configure+0x14af:	movb	0x3,%dl
> > 
> > Can you do 'l *hdaa_configure+0x14af' in gdb against the kernel.debug?
> > Perhaps set 'hint.hdac.0.disabled=1' at the loader prompt as a temporary
> > workaround to boot if needed?
> > ...
> 
> 'hint.hdac.0.disabled=1' appended to /boot/device.hints temporarily.
> 
> now running:
> FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1597  r282948M/282952:1100073: Fri May 15 09:13:17 PDT 2015     root_at_g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386
> 
> Info you requested:
> 
> (gdb) l *hdaa_configure+0x14af
> 0xc08c8e3f is in hdaa_configure (/usr/src/sys/dev/sound/pci/hda/hdaa.c:3280).
> 3275                            as[cnt].pincnt++;
> 3276                            /* Association 15 is a multiple unassociated pins. */
> 3277                            if (j == 15)
> 3278                                    cnt++;
> 3279                    }
> 3280                    if (j != 15 && as[cnt].pincnt > 0) {
> 3281                            if (hpredir && as[cnt].pincnt > 1)
> 3282                                    as[cnt].hpredir = first;
> 3283                            cnt++;
> 3284                    }
> (gdb) 

Hummm, the only recent change is 281544, but that should be in your working
kernel.  It does mess with the layout of pins though so maybe try reverting it
anyway?

It might also be worth trying to revert just the one commit you identified
earlier.  It just seems odd for 'as[cnt]' to fault here but not earlier.

-- 
John Baldwin