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
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
It might also be worth trying to revert just the one commit you
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.
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.
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
Before that ensure /usr/obj is clean: "rm -rf /usr/obj"
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"