Hi Bjorn,
On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote:
> On Friday 13 April 2007 14:07, Pavel Machek wrote:
> > > > ... The primary issue is the concurrent access
> > > > to resources, which cause lots of trouble which are hard to investigate.
> > > > If ACPI reserves the ports, then the SMBus or hardware monitoring
> > > > drivers (or any other conflicting driver) will cleanly fail to load,
> > > > which would be a move in the right direction. ...
> > > >
> > > > So, can ACPI actually reserve the ports it accesses?
> > >
> > > Sorry to join this discussion so late.
> > >
> > > ACPI tells us the resources used by devices. Today, we don't
> > > reserve
> >
> > Problem seems to be that ACPI does _not_ tell us which ports it
> > accesses from AML code.
>
> I think that would violate at least the spirit of the ACPI spec.
> The example in section 11.6 of the ACPI 3.0 spec shows a _TMP
> method that runs an EC method to read the temp, and the EC ioport
> usage is correctly declared in the EC device's _CRS method.
>
> Of course, there are always BIOS defects. But if we could make a
> case that a BIOS that doesn't declare the resources used by the AML
> is defective, we could add quirks to reserve the undeclared resources.
Only realistic if the list of systems needing a quirk is small. Do you
think that would be the case?
> > But we already found a lock we can take; AFAICT we know how to solve
> > this problem.
We even have two solutions, but both have drawbacks.
The AML lock solution has performance issue. It could be improved with a
better semaphore primitive, but that needs to be implemented first. It
also requires to modify all drivers ACPI might conflict with, and
that's a rather long list.
Rudolf Marek's port forwarding idea should perform better, and might
also be useful for other problems than ACPI vs. regular drivers,
however it makes resources bigger, and requires to modify the same long
list of drivers, and with specific code for every driver. I'm not sure
that it will be possible for all driver in practice, as this more or
less requires to forecast the I/O access pattern of ACPI.
> This might solve it, but doesn't seem like a clean way to do it.
> I don't like the idea of sharing a lock between drivers and ACPI.
> k8temp happens to be x86-dependent, so we'll always have ACPI, but
> in principle, we could have the same problem with an arch-independent
> PCI driver that only has ACPI on x86 and ia64 platforms.
We can protect the additional driver code with #ifdef CONFIG_ACPI, as I
did in my proof-of-concept. Not particularly elegant, granted, but it
should work.
If something cleaner can be done, I'm all for it. Could you please
propose an implementation of your idea? It doesn't need to be perfect,
but I would like to see what it would look like.
> (BTW, if Chuck's problem was solved by the BIOS update, I assume
> there *is* another instance of the problem that we're trying to
> solve with this lock.)
Yes, there are several other systems out there which are known to be
affected by the problem. And probably many others where ACPI access I/O
ports reserved by regular drivers and we are simply lucky that nothing
bad happens. My desktop system has such a motherboard (Jetway K8M8MS).
But SMP alternatives are becoming more popular, so we might start
seeing more problems in practice in a near future.
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
