From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 30 02:36:08 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A3821065672; Tue, 30 Jun 2009 02:36:08 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from atmail-8.bnguk.net (atmail-8.bnguk.net [80.74.253.5]) by mx1.freebsd.org (Postfix) with ESMTP id C04028FC08; Tue, 30 Jun 2009 02:36:07 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from 53-233.adsl.zetnet.co.uk ([194.247.53.233] helo=mail.chrishedley.com) by atmail-8.bnguk.net with esmtp (Exim 4.69) (envelope-from ) id 1MLTCX-0002ob-TP; Tue, 30 Jun 2009 03:36:06 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.chrishedley.com (Postfix) with ESMTP id 5C4B9920E9; Tue, 30 Jun 2009 03:36:05 +0100 (BST) X-Virus-Scanned: amavisd-new at chrishedley.com Received: from mail.chrishedley.com ([127.0.0.1]) by localhost (mail.chrishedley.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QesG4g7uU49S; Tue, 30 Jun 2009 03:36:03 +0100 (BST) Received: from teapot.cbhnet (teapot.cbhnet [192.168.1.1]) by mail.chrishedley.com (Postfix) with ESMTP id C9CD4920CD; Tue, 30 Jun 2009 03:36:02 +0100 (BST) Date: Tue, 30 Jun 2009 03:36:02 +0100 (BST) From: Chris Hedley X-X-Sender: cbh@teapot.cbhnet To: Kip Macy In-Reply-To: <3c1674c90906291830g1c79c80bq42ce99f44588e968@mail.gmail.com> Message-ID: References: <4A2C124A.1050707@freebsd.org> <3c1674c90906291830g1c79c80bq42ce99f44588e968@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: New builds won't boot (fwd) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 02:36:08 -0000 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.