Re: New builds won't boot (fwd)

On Mon, 29 Jun 2009, Kip Macy wrote:
> I went through the commits from that time period and identified
> possible candidates:
>
> svn commit: r188755 - head/sys/dev/ata
>
> Remove unused variable.
>
> svn commit: r188761 - in stable/7: lib/libc lib/libc/string
> lib/libc/sys sys sys/contrib/pf sys/dev/ath/ath_hal sys/d\
> ev/cxgb sys/kern sys/net sys/netinet sys/netinet6 sys/sys
>
> r188144:
>    Standardize the various prison_foo_ip[46] functions and prison_if to
>    return zero on success and an error code otherwise.  The possible errors
>    are EADDRNOTAVAIL if an address being checked for doesn't match the
>    prison, and EAFNOSUPPORT if the prison doesn't have any addresses in
>    that address family.  For most callers of these functions, use the
>    returned error code instead of e.g. a hard-coded EADDRNOTAVAIL or
>    EINVAL.
>
>
> svn commit: r188763 - head/sys/dev/ata
> Make ch->dma.free() called symmetrically to ch->dma.alloc().
>
> svn commit: r188765 - in head/sys/dev/ata: . chipsets
>
> Log:
> As soon as they called in only same one place (ata_pcichannel_attach()),
> join allocate() and dmainit() atapci subdriver's channel initialization
> methods into single ch_attach() method.
>
>
>
> As opposite to ch_attach() add new ch_detach() method to deallocate/disable
> channel.
>
> svn commit: r188743 - head/sys/dev/aac
> Log:
> Use outbound message register 0 instead of mailbox 7 in
> aac_{rx,rkt}_get_fwstatus, as done in Adaptec's vendor driver as well as
> the Linux drivers.
>
> Submitted by:   jkim, from Adaptec's driver

Thanks for that--it reminded me I still have the aac drivers in my current 
kernel which I no longer need as I've long since removed that card, so I 
recompiled without and... well, still no change.

But it did give me an opportunity to spot something weird which I hadn't 
noticed before, which is the device numbering: instead of getting the 
usual ad0-ad9 for my discs, the numbering was a bit peculiar, ad4, ad6 and 
so on, as if it were enumerating them according to each logical slot 
rather than doing them by discs as they're found.

I thought I'd try and outwit it by setting vfs.root.mountfrom to /dev/ad4a 
(part of my boot gmirror set with a hopefully usable rescue subsystem on 
it) but all this did was cause it to renumber them again, this time 
starting at ad12.

I think it's possible to use device.hints to force it to assign particular 
IDs to the discs but I'll have to wade through the documentation to figure 
out how it's done, assuming that's the problem, anyway.

And there's still the oddity with my keyboard where it's as if the CTRL 
key is jammed down on newer kernels, which is another thing I need to fix 
if I want to use the debugger (or the console, for that matter...)

So some inadvertent progress of sorts.  Possibly. :)

Chris.