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

On 05/16/15 15:27, Hans Petter Selasky wrote:
> On 05/15/15 22:07, David Wolfskill wrote:
>> On Fri, May 15, 2015 at 02:59:10PM -0400, John Baldwin wrote:
>>> ...
>>> Hummm, the only recent change is 281544, but that should be in your
>>> working
>>> kernel.
>>
>> Yes; that dates from 14 April, and I had been doing daily build/boots of
>> head/i386 through thta period without incident.  Absent something
>> compelling, I'm pretty sure that experience alone removes 281544 from
>> plausibly being implicated.
>>
>>> 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.
>>> ....
>>
>> OK; I tried reverting 282650, but the result wouldn't build because the
>> AFMT_CHANNEL_MAX token wasn't defined.
>>
>> Turns out it had been used by 282651, so I reverted that (and found that
>> it would have been cleaner had I reverted them in reverse sequence, but
>> "svn patch" seemed to merely whine a bit, but cope anyway).
>>
>> After reverting both 282650 & 282651, the resulting kernel built.
>>
>
> Hi,
>
> I'm seeing two of my commits mentioned here, r282650 & r282651. Are
> these what is causing the problem? You are sure the built the kernel and
> all modules from clean, hence some structures are changed, panic would
> be expected if you don't.
>
> --HPS

Hi,

Can you collect output from booting with bootverbose set? From current 
amd64 as of today. Then repeat using i386. Possibly some array is out of 
bounds or code has not been compiled properly. I just quickly counted 
the fmtlist size and from what I can see we are using 30 of 32 entries 
at least.

Before that ensure /usr/obj is clean: "rm -rf /usr/obj"

--HPS