Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Oct 2012 09:03:50 -0400
From:      Eitan Adler <eadler@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r241856 - in head/sys: arm/xscale/pxa dev/acpica dev/agp dev/amdsbwd dev/amdtemp dev/asmc dev/coretemp dev/e1000 dev/glxiic dev/ixgbe dev/kbdmux dev/sound/pci i386/acpica i386/bios x86/...
Message-ID:  <CAF6rxgnt5YAjxS0JvfZtwg8=8ZQF=87vEGG2x3VdsORhGkbRRg@mail.gmail.com>
In-Reply-To: <201210220842.31106.jhb@freebsd.org>
References:  <201210220341.q9M3fEdu023999@svn.freebsd.org> <201210220842.31106.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 22 October 2012 08:42, John Baldwin <jhb@freebsd.org> wrote:
> On Sunday, October 21, 2012 11:41:14 pm Eitan Adler wrote:
>> Author: eadler
>> Date: Mon Oct 22 03:41:14 2012
>> New Revision: 241856
>> URL: http://svn.freebsd.org/changeset/base/241856
>>
>> Log:
>>   Now that device disabling is generic, remove extraneous code from the
>>   device drivers that used to provide this feature.
>
> This isn't functionally identical.  In some cases a hint to disable
> unit 0 would in fact disable all units.  For example, disabling est0 and
> acpi_perf0 disabled all instances of estX and acpi_perfX, not just the
> first one.  You should test this on a multi-CPU machine before and after
> to see the different effects.
>
> The one in the x86 code that handles early mapping of ACPI tables before
> new-bus is around is also very important (acpi_find_table()).  You just
> broke booting on SMP systems where ACPI is disabled but that contain an
> MADT for example (pretty much all modern x86 SMP systems).
>
> elcr is also not a new-bus device, so removing that hint broke that
> psuedo-driver as well.
>
> It is only safe to remove these calls in new-bus attach (not probe!)
> routines that are using 'device_get_unit()' and not hardcoding the
> unit to 0 (unless you know for certain that there can only ever be one
> instance of this device such as acpi0 or asmc0).

Thanks for the information. I will revert and come up with a better patch.


-- 
Eitan Adler
Source & Ports committer
X11, Bugmeister, Ports Security teams



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF6rxgnt5YAjxS0JvfZtwg8=8ZQF=87vEGG2x3VdsORhGkbRRg>