Hi there,
Some old i386 systems have flaky APIC hardware that doesn't always work
right. Right now, enabling the APIC code in Kconfig means that the APIC
code will try to activate the APICs unless 'noapic nolapic' are passed
to force them off. The attached patch provides a config option to
change that default to keep the APICs off unless specified otherwise,
disables get_smp_config if we are not initializing the local APIC, and
makes init_apic_mappings not init the IOAPICs if they are disabled.
Note that the current behavior is maintained if
CONFIG_X86_UP_APIC_DEFAULT_OFF=n.
This patch is particularly useful for anybody booting a distro UP kernel
on a multi-chassis IBM x440/x445, because that system requires APIC
support to boot properly. If booting a UP kernel on a large SMP machine
seems silly, think of distro installer kernels. :) Joe Flakybox can run
his single-proc i386 box without APIC related breakage, and someone with
a x445 enable APICs in the UP kernel long enough to install a proper SMP
kernel.
Most everybody else in the world can configure their UP kernel with
CONFIG_APIC=y/n as desired and ignore this patch.
I know, it seems silly to be providing a patch that changes "enabled
unless explicitly disabled" to "disabled unless explicitly enabled",
especially since the APIC code can be forced off. However, I _am_
curious to hear what people think about the other parts of the patch.
At the very least, I'm not quite convinced that noapic & nolapic are
doing their jobs, because it seems to me that get_smp_config pokes the
LAPIC and init_apic_mappings maps the IOAPICs into memory regardless of
whatever flags are passed. But, I'm not an APIC expert so I'll defer to
anybody who knows more than I. Most curiously, passing 'noapic nolapic'
still yields things like this in dmesg:
"Enabling APIC mode: Flat. Using 1 I/O APICs"
FWIW, this has been tested on a Sun V40z, IBM x205, x226, x206m, x445,
x260, x366, x225, x336 and a dual-node x460 without problems. A similar
patch has been lurking in Redhat Rawhide kernels for several months
without problems.
Questions? Flames? The asbestos underpants have been strapped on. :)
--D
And the usual stamp for said patch:
Signed-off-by: Darrick J. Wong <[email protected]>
>This patch is particularly useful for anybody booting a distro UP kernel
>on a multi-chassis IBM x440/x445, because that system requires APIC
>support to boot properly. If booting a UP kernel on a large SMP machine
>seems silly, think of distro installer kernels. :) Joe Flakybox can run
>his single-proc i386 box without APIC related breakage, and someone with
>a x445 enable APICs in the UP kernel long enough to install a proper SMP
>kernel.
>
>I know, it seems silly to be providing a patch that changes "enabled
>unless explicitly disabled" to "disabled unless explicitly enabled",
>especially since the APIC code can be forced off. However, I _am_
>curious to hear what people think about the other parts of the patch.
>At the very least, I'm not quite convinced that noapic & nolapic are
>doing their jobs, because it seems to me that get_smp_config pokes the
>LAPIC and init_apic_mappings maps the IOAPICs into memory regardless of
>whatever flags are passed. But, I'm not an APIC expert so I'll defer to
>anybody who knows more than I. Most curiously, passing 'noapic nolapic'
>still yields things like this in dmesg:
>
>Questions? Flames? The asbestos underpants have been strapped on. :)
Do you think that people can't properly configure their bootloader to
include "noapic nolapic" in the options?
Jan Engelhardt
--
On 1/20/06, Darrick J. Wong <[email protected]> wrote:
> Hi there,
>
> Some old i386 systems have flaky APIC hardware that doesn't always work
> right. Right now, enabling the APIC code in Kconfig means that the APIC
> code will try to activate the APICs unless 'noapic nolapic' are passed
> to force them off. The attached patch provides a config option to
> change that default to keep the APICs off unless specified otherwise,
> disables get_smp_config if we are not initializing the local APIC, and
> makes init_apic_mappings not init the IOAPICs if they are disabled.
> Note that the current behavior is maintained if
> CONFIG_X86_UP_APIC_DEFAULT_OFF=n.
...
Did this hit the floor? It strikes me as a pretty good solution. This
is pretty nasty for newbies installing distro kernels, they get some
of the way through an install and then their machine just locks - not
good PR.
cheers
On Wed, Mar 01, 2006 at 02:57:05PM +1100, Michael Ellerman wrote:
> On 1/20/06, Darrick J. Wong <[email protected]> wrote:
> > Hi there,
> >
> > Some old i386 systems have flaky APIC hardware that doesn't always work
> > right. Right now, enabling the APIC code in Kconfig means that the APIC
> > code will try to activate the APICs unless 'noapic nolapic' are passed
> > to force them off. The attached patch provides a config option to
> > change that default to keep the APICs off unless specified otherwise,
> > disables get_smp_config if we are not initializing the local APIC, and
> > makes init_apic_mappings not init the IOAPICs if they are disabled.
> > Note that the current behavior is maintained if
> > CONFIG_X86_UP_APIC_DEFAULT_OFF=n.
> Did this hit the floor?
It's still being kicked around. I saw one patch off-list earlier this
week that has some small improvements over the variant originally posted,
but still had 1-2 kinks.
> It strikes me as a pretty good solution. This
> is pretty nasty for newbies installing distro kernels, they get some
> of the way through an install and then their machine just locks - not
> good PR.
The number of systems that actually *need* APIC enabled are in the
vast (though growing) minority, so it's unlikely that most newbies
will hit this. The problem is also the inverse of what you describe.
Typically the distros have DMI lists of machines that *need* APIC
to make it enabled by default so everything 'just works'.
The big problem the patch solves is allowing it to be possible
to build a kernel with UP APIC code, but disabled by default
(Because there a lot of older machines that die horribly if it
was enabled by default).
Dave
On Wed, 1 Mar 2006 15:33, Dave Jones wrote:
> On Wed, Mar 01, 2006 at 02:57:05PM +1100, Michael Ellerman wrote:
> > On 1/20/06, Darrick J. Wong <[email protected]> wrote:
> > > Hi there,
> > >
> > > Some old i386 systems have flaky APIC hardware that doesn't always
> > > work right. Right now, enabling the APIC code in Kconfig means that
> > > the APIC code will try to activate the APICs unless 'noapic nolapic'
> > > are passed to force them off. The attached patch provides a config
> > > option to change that default to keep the APICs off unless specified
> > > otherwise, disables get_smp_config if we are not initializing the
> > > local APIC, and makes init_apic_mappings not init the IOAPICs if they
> > > are disabled. Note that the current behavior is maintained if
> > > CONFIG_X86_UP_APIC_DEFAULT_OFF=n.
> >
> > Did this hit the floor?
>
> It's still being kicked around. I saw one patch off-list earlier this
> week that has some small improvements over the variant originally posted,
> but still had 1-2 kinks.
Cool. Let's get ironing. I have no idea about the implementation, but the
concept is double ++ good as far as I'm concerned.
> The number of systems that actually *need* APIC enabled are in the
> vast (though growing) minority, so it's unlikely that most newbies
> will hit this. The problem is also the inverse of what you describe.
> Typically the distros have DMI lists of machines that *need* APIC
> to make it enabled by default so everything 'just works'.
Ok, even more reason for it to go in. Someone might want to let the folks at
Ubuntu know too, they seem to have it enabled in their installer kernel. :D
cheers
On Tue, 28 Feb 2006, Dave Jones wrote:
> On Wed, Mar 01, 2006 at 02:57:05PM +1100, Michael Ellerman wrote:
> > On 1/20/06, Darrick J. Wong <[email protected]> wrote:
> > > Hi there,
> > >
> > > Some old i386 systems have flaky APIC hardware that doesn't always work
> > > right. Right now, enabling the APIC code in Kconfig means that the APIC
> > > code will try to activate the APICs unless 'noapic nolapic' are passed
> > > to force them off. The attached patch provides a config option to
> > > change that default to keep the APICs off unless specified otherwise,
> > > disables get_smp_config if we are not initializing the local APIC, and
> > > makes init_apic_mappings not init the IOAPICs if they are disabled.
> > > Note that the current behavior is maintained if
> > > CONFIG_X86_UP_APIC_DEFAULT_OFF=n.
> > Did this hit the floor?
>
> It's still being kicked around. I saw one patch off-list earlier this
> week that has some small improvements over the variant originally posted,
> but still had 1-2 kinks.
>
> > It strikes me as a pretty good solution. This
> > is pretty nasty for newbies installing distro kernels, they get some
> > of the way through an install and then their machine just locks - not
> > good PR.
>
> The number of systems that actually *need* APIC enabled are in the
> vast (though growing) minority, so it's unlikely that most newbies
> will hit this. The problem is also the inverse of what you describe.
> Typically the distros have DMI lists of machines that *need* APIC
> to make it enabled by default so everything 'just works'.
>
> The big problem the patch solves is allowing it to be possible
> to build a kernel with UP APIC code, but disabled by default
> (Because there a lot of older machines that die horribly if it
> was enabled by default).
The current policy is off if it was disabled by the BIOS. Is the intention
of this patch to have it off unconditionally unless explicitely enabled by
kernel parameter?
Thanks,
Zwane
On Wed, Mar 01, 2006 at 04:10:26PM +1100, Michael Ellerman wrote:
> > The number of systems that actually *need* APIC enabled are in the
> > vast (though growing) minority, so it's unlikely that most newbies
> > will hit this. The problem is also the inverse of what you describe.
> > Typically the distros have DMI lists of machines that *need* APIC
> > to make it enabled by default so everything 'just works'.
>
> Ok, even more reason for it to go in. Someone might want to let the folks at
> Ubuntu know too, they seem to have it enabled in their installer kernel. :D
Last I looked they picked up the same patch we were carrying in Fedora.
Dave
On Tue, Feb 28, 2006 at 10:36:09PM -0800, Zwane Mwaikambo wrote:
> > The number of systems that actually *need* APIC enabled are in the
> > vast (though growing) minority, so it's unlikely that most newbies
> > will hit this. The problem is also the inverse of what you describe.
> > Typically the distros have DMI lists of machines that *need* APIC
> > to make it enabled by default so everything 'just works'.
> >
> > The big problem the patch solves is allowing it to be possible
> > to build a kernel with UP APIC code, but disabled by default
> > (Because there a lot of older machines that die horribly if it
> > was enabled by default).
>
> The current policy is off if it was disabled by the BIOS. Is the intention
> of this patch to have it off unconditionally unless explicitely enabled by
> kernel parameter?
Yes, (or forced on by dmi string)
Dave
Dave Jones <[email protected]> wrote:
> On Wed, Mar 01, 2006 at 04:10:26PM +1100, Michael Ellerman wrote:
> >
> > Ok, even more reason for it to go in. Someone might want to let the folks at
> > Ubuntu know too, they seem to have it enabled in their installer kernel. :D
>
> Last I looked they picked up the same patch we were carrying in Fedora.
No, we use the standard kernel behaviour (use APIC if the BIOS enabled
it, otherwise don't).
--
Matthew Garrett | [email protected]
On Tue, 2006-02-28 at 23:33 -0500, Dave Jones wrote:
> It's still being kicked around. I saw one patch off-list earlier this
> week that has some small improvements over the variant originally posted,
> but still had 1-2 kinks.
Hm... what kinks are you referring to? Anything you want me to look at?
--D
On Wed, Mar 01, 2006 at 01:29:06PM -0800, Darrick J. Wong wrote:
> On Tue, 2006-02-28 at 23:33 -0500, Dave Jones wrote:
>
> > It's still being kicked around. I saw one patch off-list earlier this
> > week that has some small improvements over the variant originally posted,
> > but still had 1-2 kinks.
>
> Hm... what kinks are you referring to? Anything you want me to look at?
I think Konrad was on top of it, mostly just confusion over variants
of the same diff leading to things previously fixed being dropped again.
In light of Matthew's comments in this thread though, I'm also wondering
if we can now get by without this diff, and just enable it by default now
that the kernel respects that the BIOS and leaves it alone if it's been
disabled.
Dave
On Wed, 2006-03-01 at 17:14 -0500, Dave Jones wrote:
> In light of Matthew's comments in this thread though, I'm also wondering
> if we can now get by without this diff, and just enable it by default now
> that the kernel respects that the BIOS and leaves it alone if it's been
> disabled.
Actually, it seems that there are Lenovo ThinkCenter P4 machines with
buggy BIOSes that tell us that we can enable the APIC ... but doing so
eventually causes the system to hang. Granted, the Google-recommended
fixes are "noapic" or "Update the BIOS", but perhaps it would be best to
leave it off _except_ for the few cases where we know that we need it.
(Then again, the correct solution in this case is to fix the BIOS...)
--D
On Wed, Mar 01, 2006 at 02:47:38PM -0800, Darrick J. Wong wrote:
> On Wed, 2006-03-01 at 17:14 -0500, Dave Jones wrote:
>
> > In light of Matthew's comments in this thread though, I'm also wondering
> > if we can now get by without this diff, and just enable it by default now
> > that the kernel respects that the BIOS and leaves it alone if it's been
> > disabled.
>
> Actually, it seems that there are Lenovo ThinkCenter P4 machines with
> buggy BIOSes that tell us that we can enable the APIC ... but doing so
> eventually causes the system to hang. Granted, the Google-recommended
> fixes are "noapic" or "Update the BIOS", but perhaps it would be best to
> leave it off _except_ for the few cases where we know that we need it.
>
> (Then again, the correct solution in this case is to fix the BIOS...)
Indeed. And also blacklist the bad ones with DMI entries.
Dave
On Wed, 2006-03-01 at 17:51 -0500, Dave Jones wrote:
> On Wed, Mar 01, 2006 at 02:47:38PM -0800, Darrick J. Wong wrote:
> > On Wed, 2006-03-01 at 17:14 -0500, Dave Jones wrote:
> >
> > > In light of Matthew's comments in this thread though, I'm also wondering
> > > if we can now get by without this diff, and just enable it by default now
> > > that the kernel respects that the BIOS and leaves it alone if it's been
> > > disabled.
> >
> > Actually, it seems that there are Lenovo ThinkCenter P4 machines with
> > buggy BIOSes that tell us that we can enable the APIC ... but doing so
> > eventually causes the system to hang. Granted, the Google-recommended
> > fixes are "noapic" or "Update the BIOS", but perhaps it would be best to
> > leave it off _except_ for the few cases where we know that we need it.
> >
> > (Then again, the correct solution in this case is to fix the BIOS...)
>
> Indeed. And also blacklist the bad ones with DMI entries.
Yeah. Since the kernel honors the BIOS's APIC settings, we might as
well enable the APIC code by default.
--D
On ?t 28-02-06 23:33:53, Dave Jones wrote:
> On Wed, Mar 01, 2006 at 02:57:05PM +1100, Michael Ellerman wrote:
> > On 1/20/06, Darrick J. Wong <[email protected]> wrote:
> > > Hi there,
> > >
> > > Some old i386 systems have flaky APIC hardware that doesn't always work
> > > right. Right now, enabling the APIC code in Kconfig means that the APIC
> > > code will try to activate the APICs unless 'noapic nolapic' are passed
> > > to force them off. The attached patch provides a config option to
> > > change that default to keep the APICs off unless specified otherwise,
> > > disables get_smp_config if we are not initializing the local APIC, and
> > > makes init_apic_mappings not init the IOAPICs if they are disabled.
> > > Note that the current behavior is maintained if
> > > CONFIG_X86_UP_APIC_DEFAULT_OFF=n.
> > Did this hit the floor?
>
> It's still being kicked around. I saw one patch off-list earlier this
> week that has some small improvements over the variant originally posted,
> but still had 1-2 kinks.
>
> > It strikes me as a pretty good solution. This
> > is pretty nasty for newbies installing distro kernels, they get some
> > of the way through an install and then their machine just locks - not
> > good PR.
>
> The number of systems that actually *need* APIC enabled are in the
> vast (though growing) minority, so it's unlikely that most newbies
> will hit this. The problem is also the inverse of what you describe.
> Typically the distros have DMI lists of machines that *need* APIC
> to make it enabled by default so everything 'just works'.
Well, blacklisting "new" machines is a problem -- their number
grows. Would not it be better to blacklist machines broken by APIC
("old" ones, presumably)?
> The big problem the patch solves is allowing it to be possible
> to build a kernel with UP APIC code, but disabled by default
> (Because there a lot of older machines that die horribly if it
> was enabled by default).
Is adding "noapic nolapic" to default command line a big problem?
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Mon, Mar 06, 2006 at 01:50:18PM +0100, Pavel Machek wrote:
> > The number of systems that actually *need* APIC enabled are in the
> > vast (though growing) minority, so it's unlikely that most newbies
> > will hit this. The problem is also the inverse of what you describe.
> > Typically the distros have DMI lists of machines that *need* APIC
> > to make it enabled by default so everything 'just works'.
>
> Well, blacklisting "new" machines is a problem -- their number
> grows. Would not it be better to blacklist machines broken by APIC
> ("old" ones, presumably)?
It would. Though some new machines also falsely advertise it as
working aparently. I heard a report of a thinkpad going boom last week.
> Is adding "noapic nolapic" to default command line a big problem?
For end-users, yes. People want things to 'just work', not have
to find arcane commands to type in to make things work.
Dave
--
http://www.codemonkey.org.uk
On Mon, Mar 06, 2006 at 06:58:11PM +0100, Pavel Machek wrote:
> I just do not want to see CONFIG_DO_NOAPIC_BY_DEFAULT someone suggested
> here (heh, it is still in subject :-). Whitelist/blacklist is fine
> with me.
I (and Darrick) already agreed further up in this thread that it wasn't needed.
I think we're actually in agreement ;)
Dave
--
http://www.codemonkey.org.uk
On Mon, 2006-03-06 at 13:17 -0500, Dave Jones wrote:
> I (and Darrick) already agreed further up in this thread that it wasn't needed.
> I think we're actually in agreement ;)
Yep. Maybe it's time I cough up a patch that does this. :)
--D
> > One more config-option is also not "cheap" (half of users will get it
> > wrong), and having config-option to change command-line-default seems
> > wrong to me.
> >
> > [Well, you could add CONFIG_CMDLINE to i386, like arm has... that
> > solves more than just this problem...]
>
> I'm not arguing for extra command line options. The inverse, I want
> *no* command line options.
>
> What's so hard to understand about expecting something to just work?
I don't argue with "just works". I just do not want to see
CONFIG_DO_NOAPIC_BY_DEFAULT someone suggested
here (heh, it is still in subject :-). Whitelist/blacklist is fine
with me.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Mon, Mar 06, 2006 at 06:41:22PM +0100, Pavel Machek wrote:
> > > Is adding "noapic nolapic" to default command line a big problem?
> > For end-users, yes. People want things to 'just work', not have
> > to find arcane commands to type in to make things work.
> If distro puts "noapic nolapic" on kernel command line, I'd say users
> are unlikely to remove it.. And if they do remove it and it breaks,
> they'll only blame themselves...
If distros put 'noapic nolapic' on the command line they've only
themselves to blame when systems that need local apic for
correct operation don't work.
> One more config-option is also not "cheap" (half of users will get it
> wrong), and having config-option to change command-line-default seems
> wrong to me.
>
> [Well, you could add CONFIG_CMDLINE to i386, like arm has... that
> solves more than just this problem...]
I'm not arguing for extra command line options. The inverse, I want
*no* command line options.
What's so hard to understand about expecting something to just work?
Dave
--
http://www.codemonkey.org.uk
> > Is adding "noapic nolapic" to default command line a big problem?
>
> For end-users, yes. People want things to 'just work', not have
> to find arcane commands to type in to make things work.
If distro puts "noapic nolapic" on kernel command line, I'd say users
are unlikely to remove it.. And if they do remove it and it breaks,
they'll only blame themselves...
One more config-option is also not "cheap" (half of users will get it
wrong), and having config-option to change command-line-default seems
wrong to me.
[Well, you could add CONFIG_CMDLINE to i386, like arm has... that
solves more than just this problem...]
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...