Linux 2.5.70 and above have broken ACPI. Again. This is my fifth
machine on which I try ACPI, two notebooks and three desktops, chipsets
from Intel, VIA and SiS, no matter, ACPI still breaks 'em all.
The symptom is that eth0 does not see the others. /proc/interrupts has
the correct interrupt listed, so it took me a while to suspect ACPI.
agpgart also crashes, and firewire and USB didn't find any devices.
Why oh why is ACPI so horrendously broken?
And more to the point: if it _is_ this broken, why ship it at all? I
don't recall a single moment where ACPI did anything good for me, only
crashes, data loss and general brokenness. This may be a technology
fitting Microsoft and Intel PCs, but why give it even more leverage by
supporting it in Linux? I say rip this abomination right out of the
kernel and be done with it.
Felix
On Tue, 2003-06-17 at 10:44, Felix von Leitner wrote:
> Linux 2.5.70 and above have broken ACPI. Again. This is my fifth
> machine on which I try ACPI, two notebooks and three desktops, chipsets
> from Intel, VIA and SiS, no matter, ACPI still breaks 'em all.
> Why oh why is ACPI so horrendously broken?
Because its a moderately bad spec that your vendor implemented to deal
with a horrid redmond interpreter. (And, to make things worse, the
linux-acpi team specifically insists on implementing the spec, not the
reality. "We refuse to be bug-for-bug compatible with the other major
implementation." So linux-acpi is "right" but redmond-acpi is tested
and actually works.)
> And more to the point: if it _is_ this broken, why ship it at all? I
> don't recall a single moment where ACPI did anything good for me, only
I'm kinda fond of battery status. And pci interrupt routing (convenient,
that..) and the half-dozen or so important other functions that even a
half-broken ACPI provides on my main machine (laptop, no APM support at
all.) And as a side note, especially on laptops, the DSDT (bios "talk
to acpi-managed hardware like this" bytecode) tends to be dramatically
broken. acpi.sf.net has info on patching it, some pre-patched tables,
etc.
Hate it? Well... that'd be why its a configure option.
--
Disconnect <[email protected]>
On Tue, Jun 17, 2003 at 04:44:43PM +0200, Felix von Leitner wrote:
> Linux 2.5.70 and above have broken ACPI. Again. This is my fifth
> machine on which I try ACPI, two notebooks and three desktops, chipsets
> from Intel, VIA and SiS, no matter, ACPI still breaks 'em all.
>
> The symptom is that eth0 does not see the others. /proc/interrupts has
> the correct interrupt listed, so it took me a while to suspect ACPI.
> agpgart also crashes, and firewire and USB didn't find any devices.
>
> Why oh why is ACPI so horrendously broken?
>
> And more to the point: if it _is_ this broken, why ship it at all? I
> don't recall a single moment where ACPI did anything good for me, only
> crashes, data loss and general brokenness. This may be a technology
> fitting Microsoft and Intel PCs, but why give it even more leverage by
> supporting it in Linux? I say rip this abomination right out of the
> kernel and be done with it.
>
Then how do you manage if one day you go with a64?
Do you have laptops with via chipsets? If yes, do you
have overheat issues without acpi? Ok, acpi is not stable for
you, but have you at least tryed a 2.4 kernels with
latest patches from sf.net/projects/acpi, or a 2.4 ac kernels?
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
> From: Felix von Leitner [mailto:[email protected]]
> Linux 2.5.70 and above have broken ACPI. Again. This is my fifth
> machine on which I try ACPI, two notebooks and three
> desktops, chipsets
> from Intel, VIA and SiS, no matter, ACPI still breaks 'em all.
"Again." Are you saying it used to work on these machines and then it
stopped? If so I think we have a fix to try in the next ACPI release
(which may or may not make it into the next kernel release.)
> The symptom is that eth0 does not see the others.
> /proc/interrupts has
> the correct interrupt listed, so it took me a while to suspect ACPI.
> agpgart also crashes, and firewire and USB didn't find any devices.
>
> Why oh why is ACPI so horrendously broken?
Do I hear violins playing? Poor, poor you! :)
The ACPI PCI routing code still isn't 100% correct. Have you tried
pci=noacpi? Have you diagnosed exactly what is going wrong on your
system? Have you checked bugzilla for similar bugs? Have you sent a
patch fixing the problem on your system?
> And more to the point: if it _is_ this broken, why ship it at all? I
> don't recall a single moment where ACPI did anything good for me, only
> crashes, data loss and general brokenness. This may be a technology
> fitting Microsoft and Intel PCs, but why give it even more leverage by
> supporting it in Linux? I say rip this abomination right out of the
> kernel and be done with it.
So don't compile it in for now. When you buy a system in a few years
that won't work properly without ACPI, and it *works* because of the
work everyone on acpi-devel is doing, then you'll change your tune.
Regards -- Andy
Hi !
> "Again." Are you saying it used to work on these machines and then it
> stopped? If so I think we have a fix to try in the next ACPI release
> (which may or may not make it into the next kernel release.)
Well, I, for myself, didn't needed ACPI for my desktops/servers - they
were/are working fine without it. When I've dumped processing power for
mobility, however - as much power management as possible is (almost) a
requirement (for me). How/where could I find your fix to test (yes, I'm
reading acpi-devel, but installing bitkeeper to pull these 'assorted fixes'
is somewhat like an overkill. Diff ?)
>
> > The symptom is that eth0 does not see the others.
> > /proc/interrupts has
> > the correct interrupt listed, so it took me a while to suspect ACPI.
> > agpgart also crashes, and firewire and USB didn't find any devices.
> >
> > Why oh why is ACPI so horrendously broken?
>
> Do I hear violins playing? Poor, poor you! :)
If only he was alone...
>
> The ACPI PCI routing code still isn't 100% correct. Have you tried
> pci=noacpi? Have you diagnosed exactly what is going wrong on your
Yes. Doesn't helps (well, my particular problem is miniPCI 3c556 fails to be
detected properly with ACPI enabled. Seems base io addr is detected
incorrectly, and subsequent calls to read data return 0xFF instead of actual
values. I've posted message here few days ago, and I didn't intend to repost
it, but this discussion took me by heart.).
> system? Have you checked bugzilla for similar bugs? Have you sent a
Yes. Nothing similar (I'm wondering if ThinkPad T2x series are so unpopular
among linux users/developers, and nobody stepped on this bug before, or I'm
so very special...).
> > patch fixing the problem on your system?
Well, 3c59x driver source is 100K of tightly hardware-bound code (as almost
every other driver). Looks I'll need another three or four months just to
grok what's happening there - I'm not a Donald Becker (:-)
>
> So don't compile it in for now. When you buy a system in a few years
> that won't work properly without ACPI, and it *works* because of the
> work everyone on acpi-devel is doing, then you'll change your tune.
Well. Probably. Is there some kind of ACPI HCL ?
--
With all the best, yarick at relex dot ru.