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/...

John Baldwin jhb at freebsd.org
Mon Oct 22 13:33:45 UTC 2012


On Monday, October 22, 2012 9:03:50 am Eitan Adler wrote:
> On 22 October 2012 08:42, John Baldwin <jhb at 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.

I don't think you need to revert all of them.  Just go back over your patch
and revert the ones that aren't definitely safe.  I think the ones I included
in my first e-mail are the ones you need to revert, but I haven't double
checked that list.

-- 
John Baldwin


More information about the svn-src-head mailing list