From: Yaroslav Rastrigin <yarick@relex.ru>
To: "Grover, Andrew" <andrew.grover@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: ACPI broken... again!
Date: Tue, 17 Jun 2003 22:02:47 +0400 [thread overview]
Message-ID: <200306172202.47579.yarick@relex.ru> (raw)
In-Reply-To: <F760B14C9561B941B89469F59BA3A84725A2F1@orsmsx401.jf.intel.com>
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.
next prev parent reply other threads:[~2003-06-17 17:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-17 17:10 Grover, Andrew
2003-06-17 18:02 ` Yaroslav Rastrigin [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-06-17 14:44 Felix von Leitner
2003-06-17 15:12 ` Disconnect
2003-06-17 16:03 ` Ducrot Bruno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200306172202.47579.yarick@relex.ru \
--to=yarick@relex.ru \
--cc=andrew.grover@intel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®