From: Andrew Walrond <andrew@walrond.org>
To: Andreas Haumer <andreas@xss.co.at>, "Yu, Luming" <luming.yu@intel.com>
Cc: Stephan von Krawczynski <skraw@ithnet.com>,
marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org
Subject: Re: ACPI: problem on ASUS PR-DLS533
Date: Sun, 18 Jan 2004 16:01:58 +0000 [thread overview]
Message-ID: <200401181601.58105.andrew@walrond.org> (raw)
In-Reply-To: <400A7119.7000803@xss.co.at>
On Sunday 18 Jan 2004 11:42 am, Andreas Haumer wrote:
>
> b) Wait for the vendor to fix the problem in the BIOS.
> This requires to file a bug report with the vendor first,
> of course. For this it would be necessary to describe the
> issue in detail and make clear that it's a BIOS problem
> and not a Linux problem. And it would be necessary the
> vendor acknowledges the problem.
> Alas, in my experience chances are high that any bug report
> of this kind vanishes in the dungeons of a vendors internal
> bug report escalation strategy... (Does anyone know a direct
> technical contact at ASUS?)
>
I've tried contacting ASUS several times with this issue as I have lots of
their dual P3 and dual Xeon servers, but end up butting a brick wall, so If
somebody does have a useful Asus contact, please step forward!
It does raise the issue of exactly what we want out of the kernel though. Ie
should the kernel just not work with all these asus machines when ACPI is
enabled, or recognise the problem and fall back to the old discovery
mechanism.
_I_ can get my asus servers working because 1) I read lkml and am aware of the
issues 2) Can compile a custom kernel 3) Care enough to keep trying until it
works. But I'm not normal ;)
And of course The Proprietory OS (tm) seems to manage.
How do the major distros cope? Not enable ACPI at all, or do alot of discovery
during installation and select an appropriate kernel?
Andrew Walrond
next prev parent reply other threads:[~2004-01-18 16:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-18 4:23 ACPI: problem on ASUS PR-DLS533 Yu, Luming
2004-01-18 11:42 ` Andreas Haumer
2004-01-18 16:01 ` Andrew Walrond [this message]
2004-01-18 17:00 ` Stephan von Krawczynski
[not found] <BF1FE1855350A0479097B3A0D2A80EE0020ADE84@hdsmsx402.hd.intel.com>
2004-01-18 18:19 ` Len Brown
-- strict thread matches above, loose matches on Subject: below --
2004-01-18 4:18 Yu, Luming
2004-01-18 9:01 ` Andrew Walrond
2004-01-12 5:14 Yu, Luming
2004-01-15 18:14 ` Andrew Walrond
2004-01-16 10:30 ` Marcelo Tosatti
2004-01-16 11:25 ` Stephan von Krawczynski
2004-01-16 13:14 ` Andreas Haumer
2004-01-16 13:22 ` Stephan von Krawczynski
2004-01-16 12:07 ` Andrew Walrond
2004-01-07 10:50 Yu, Luming
2004-01-07 12:35 ` Stephan von Krawczynski
2004-01-07 22:58 ` Marcelo Tosatti
2003-12-23 12:04 Andreas Haumer
2003-12-23 14:48 ` Andrew Walrond
2003-12-23 15:21 ` Andreas Haumer
2004-01-07 10:37 ` Stephan von Krawczynski
2004-01-07 14:30 ` Andrew Walrond
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=200401181601.58105.andrew@walrond.org \
--to=andrew@walrond.org \
--cc=andreas@xss.co.at \
--cc=linux-kernel@vger.kernel.org \
--cc=luming.yu@intel.com \
--cc=marcelo.tosatti@cyclades.com \
--cc=skraw@ithnet.com \
/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