Re: [PATCH 6/29] x86-apic-virtwire-on-shutdown

[ebiederm@xmission.com (Eric W. Biederman)]

Len Brown <len.brown@intel.com> writes:

> On Tue, 2005-01-25 at 01:39, Eric W. Biederman wrote:
> > Yes there are bleeding edge systems that fail without this patch.
> > And I have them.  That is why I wrote the code.
> 
> What bleeding edge system support MPS and does not support ACPI?

All I was talking about is the hardware here.  Last I looked the
errata on the E7520 E7525 and E7530 chipsets listed using the IOAPIC
in virtual wire mode the only way to get them to get the system
to work stably if you did not have an SMP kernel.  If there is an
updated errata work around I'd love to hear it.

The fact that ACPI is quite common is one of the reasons this code
path needs more work.

I have not seen the problems with ACPI as I have yet to see a
compelling reason to turn it on.  And my few experiences with
it have lead me to put acpi=off on my kernel command-line by default.

> I belive we don't touch the IO_APICS in either MPS or ACPI mode before
> setup_IO_APIC.

Thanks I will have a lookup.  That sounds like a likely place.

> If the goal of this patch is to restore the hardware to the state
> that it was before Linux scribbed on it, then it might be a better
> ideal to save/restore the actual register values the BIOS gave us rather
> than writing hard-coded values, no?

Nope that is not the goal.  The goal is to place system devices in
a state close enough to pc compatibility mode that an unpatched kernel
will start.  A secondary goal is to place the system in a state where
the firmware is likely not to have problems.  

As the apics are architectural hardware and we only touch the bits we
understand there is no reason for us to be modest and pretend we don't
know what we are doing.  The architecture defines a very narrow
set of states that are valid when you are not using the apics.  The
question is only which of those states will work?  pic_mode,
virt_wire mode in local apic, virt_wire mode in ioapic.  Looking at
the hardware is probably the most consistently reliable method of
determining that as the kernel will not boot if the firmware
sets it up wrong.

Eric