From owner-freebsd-current@FreeBSD.ORG Wed May 16 16:18:29 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC4801065670; Wed, 16 May 2012 16:18:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 870808FC12; Wed, 16 May 2012 16:18:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA27762; Wed, 16 May 2012 19:18:26 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB3D351.6030804@FreeBSD.org> Date: Wed, 16 May 2012 19:18:25 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <4FAF7343.8010808@cran.org.uk> <201205151034.13994.jhb@freebsd.org> <4FB285C0.1090905@FreeBSD.org> <201205161050.35759.jhb@freebsd.org> In-Reply-To: <201205161050.35759.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 16:18:29 -0000 on 16/05/2012 17:50 John Baldwin said the following: > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: >> Not sure what you disagree with... >> First, the wildcard device is added to the child list during the walk. >> Then, the unit 0 device is added to the list when acpi_timer identify is executed. >> Then, the wildcard device is probed and gets unit number of zero. >> Then, the fixed device is being probed and the unit number conflict arises. >> >> Am I misunderstanding something? > > Yes. The third step will see that unit 0 is already in use and shouldn't > reuse unit 0. > Looks like I missed the call to devclass_add_device() in make_device(). Your guess: > I wonder if this is related to the recent changes to set the unit number for CPUs? seems to be true. The device_t-s created for CPUs have NULL driver name / devclass, but a non-wildcard unit number. So when such a device with unit number 0 is probed by acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the identify. Similarly we get conflicts for acpi_sysresource driver, because we do an early probe-and-attach for this driver and the attached devices get some unit numbers (0, 1, etc). So when during the normal probe pass the "CPU" devices with matching unit numbers are passed to the driver the conflict results. I guess that it is an unorthodox use of newbus to specify a unit number without specifying a driver name... It's like saying "this device must be unit N whatever driver claims it (be it kbdN or diskN) just because I say so". Not sure if this ever makes sense and maybe we should prohibit such a combination (reject it earlier). I guess that in this particular case we already know that the devices are really CPU devices and are going to be claimed by acpi cpu driver. So we should pass "cpu" as the name. -- Andriy Gapon