I missed this thread for a few days, What's the conclusion?
Thanks,
Luming
> -----Original Message-----
> From: Stephan von Krawczynski [mailto:[email protected]]
> Sent: Friday, January 16, 2004 9:23 PM
> To: Andreas Haumer
> Cc: [email protected]; [email protected]; Yu,
> Luming; [email protected]
> Subject: Re: ACPI: problem on ASUS PR-DLS533
>
>
>
> > For the system I noticed the ACPI problems (Asus PR-DLS533),
> > the regression occured after 2.4.21
> >
> > With pristine 2.4.21 the system could boot with ACPI enabled,
> > but with the new ACPI patches introduced with the 2.4.21-ac
> > series (and integrated in the 2.4.x series later on) it did not.
> >
> > Does your board have several PCI busses (lspci -v) ?
>
> You asked ;-)
> The last two entries are the controllers in question.
>
>
> 00:00.0 Host bridge: ServerWorks CNB20HE Host Bridge (rev 23)
> Flags: fast devsel
>
> 00:00.1 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01)
> Flags: bus master, medium devsel, latency 32
>
> 00:00.2 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01)
> Flags: medium devsel
>
> 00:00.3 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01)
> Flags: medium devsel
>
> 00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet
> Pro 100] (rev 0d)
> Subsystem: Intel Corp. EtherExpress PRO/100 S Server Adapter
> Flags: bus master, medium devsel, latency 32, IRQ 18
> Memory at ef000000 (32-bit, non-prefetchable) [size=4K]
> I/O ports at d800 [size=64]
> Memory at ee800000 (32-bit, non-prefetchable) [size=128K]
> Expansion ROM at febf0000 [disabled] [size=64K]
> Capabilities: [dc] Power Management version 2
>
> 00:03.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet
> Pro 100] (rev 0d)
> Subsystem: Intel Corp. EtherExpress PRO/100 S Server Adapter
> Flags: bus master, medium devsel, latency 32, IRQ 18
> Memory at ee000000 (32-bit, non-prefetchable) [size=4K]
> I/O ports at d400 [size=64]
> Memory at ed800000 (32-bit, non-prefetchable) [size=128K]
> Expansion ROM at febe0000 [disabled] [size=64K]
> Capabilities: [dc] Power Management version 2
>
> 00:04.0 VGA compatible controller: ATI Technologies Inc
> Radeon RV200 QW [Radeon 7500] (prog-if 00 [VGA])
> Subsystem: C.P. Technology Co. Ltd RV200 QW [Radeon
> 7500 PCI Dual Display]
> Flags: bus master, stepping, medium devsel, latency 32, IRQ 25
> Memory at f0000000 (32-bit, prefetchable) [size=128M]
> I/O ports at d000 [size=256]
> Memory at ed000000 (32-bit, non-prefetchable) [size=64K]
> Expansion ROM at effe0000 [disabled] [size=128K]
> Capabilities: [50] Power Management version 2
>
> 00:05.0 Multimedia audio controller: Creative Labs SB Live!
> EMU10k1 (rev 07)
> Subsystem: Creative Labs SBLive! Player 5.1
> Flags: bus master, medium devsel, latency 32, IRQ 26
> I/O ports at b800 [size=32]
> Capabilities: [dc] Power Management version 1
>
> 00:05.1 Input device controller: Creative Labs SB Live!
> MIDI/Game Port (rev 07)
> Subsystem: Creative Labs Gameport Joystick
> Flags: bus master, medium devsel, latency 32
> I/O ports at b400 [size=8]
> Capabilities: [dc] Power Management version 1
>
> 00:07.0 VGA compatible controller: ATI Technologies Inc Rage
> XL (rev 27) (prog-if 00 [VGA])
> Subsystem: Asustek Computer, Inc.: Unknown device 1234
> Flags: bus master, stepping, medium devsel, latency 32, IRQ 19
> Memory at ec000000 (32-bit, non-prefetchable)
> [disabled] [size=16M]
> I/O ports at b000 [disabled] [size=256]
> Memory at eb800000 (32-bit, non-prefetchable)
> [disabled] [size=4K]
> Expansion ROM at effc0000 [disabled] [size=128K]
> Capabilities: [5c] Power Management version 2
>
> 00:0f.0 ISA bridge: ServerWorks CSB5 South Bridge (rev 93)
> Subsystem: ServerWorks CSB5 South Bridge
> Flags: bus master, medium devsel, latency 32
>
> 00:0f.1 IDE interface: ServerWorks CSB5 IDE Controller (rev
> 93) (prog-if 8a [Master SecP PriP])
> Subsystem: ServerWorks CSB5 IDE Controller
> Flags: bus master, medium devsel, latency 64
> I/O ports at <ignored>
> I/O ports at <ignored>
> I/O ports at <ignored>
> I/O ports at <ignored>
> I/O ports at 9400 [size=16]
>
> 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB
> Controller (rev 05) (prog-if 10 [OHCI])
> Subsystem: ServerWorks OSB4/CSB5 OHCI USB Controller
> Flags: bus master, medium devsel, latency 32, IRQ 11
> Memory at eb000000 (32-bit, non-prefetchable) [size=4K]
>
> 00:0f.3 Host bridge: ServerWorks GCLE Host Bridge
> Subsystem: ServerWorks: Unknown device 0230
> Flags: bus master, medium devsel, latency 0
>
> 01:02.0 RAID bus controller: 3ware Inc 3ware 7000-series
> ATA-RAID (rev 01)
> Subsystem: 3ware Inc 3ware 7000-series ATA-RAID
> Flags: bus master, medium devsel, latency 32, IRQ 17
> I/O ports at 9000 [size=16]
> Memory at ea800000 (32-bit, non-prefetchable) [size=16]
> Memory at ea000000 (32-bit, non-prefetchable) [size=8M]
> Expansion ROM at <unassigned> [disabled] [size=64K]
> Capabilities: [40] Power Management version 1
>
> 01:03.0 Network controller: AVM Audiovisuelles MKTG &
> Computer System GmbH Fritz!PCI v2.0 ISDN (rev 01)
> Subsystem: AVM Audiovisuelles MKTG & Computer System
> GmbH Fritz!PCI v2.0 ISDN
> Flags: medium devsel, IRQ 20
> Memory at e9800000 (32-bit, non-prefetchable) [size=32]
> I/O ports at 8800 [size=32]
> Capabilities: [40] Power Management version 2
>
> 01:04.0 Ethernet controller: Broadcom Corporation NetXtreme
> BCM5701 Gigabit Ethernet (rev 15)
> Subsystem: 3Com Corporation 3C996B-T 1000Base-T
> Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 21
> Memory at e9000000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [40] PCI-X non-bridge device.
> Capabilities: [48] Power Management version 2
> Capabilities: [50] Vital Product Data
> Capabilities: [58] Message Signalled Interrupts: 64bit+
> Queue=0/3 Enable-
>
> 02:02.0 Ethernet controller: Broadcom Corporation NetXtreme
> BCM5701 Gigabit Ethernet (rev 15)
> Subsystem: 3Com Corporation 3C996B-T 1000Base-T
> Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 24
> Memory at e8800000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [40] PCI-X non-bridge device.
> Capabilities: [48] Power Management version 2
> Capabilities: [50] Vital Product Data
> Capabilities: [58] Message Signalled Interrupts: 64bit+
> Queue=0/3 Enable-
>
> 02:03.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)
> Subsystem: Adaptec AIC-7899P U160/m
> Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 22
> BIST result: 00
> I/O ports at 7800 [disabled] [size=256]
> Memory at e8000000 (64-bit, non-prefetchable) [size=4K]
> Expansion ROM at efde0000 [disabled] [size=128K]
> Capabilities: [dc] Power Management version 2
>
> 02:03.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)
> Subsystem: Adaptec AIC-7899P U160/m
> Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 23
> BIST result: 00
> I/O ports at 7400 [disabled] [size=256]
> Memory at e7800000 (64-bit, non-prefetchable) [size=4K]
> Expansion ROM at efdc0000 [disabled] [size=128K]
> Capabilities: [dc] Power Management version 2
>
>
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
Yu, Luming wrote:
> I missed this thread for a few days, What's the conclusion?
>
Good question! :-)
It seems clear, the problem stems from a broken BIOS which
does not correctly initialize some ACPI data structures.
It seems, the specific problem occurs on several different
motherboards, but they are all from the same vendor (ASUS).
So IMHO there are the following possibilities:
a) Find a workaround for this class of broken BIOS behaviour
in the Linux ACPI code.
I do not know if this is A Good Thing(tm) though (and if
it's even possible). This should be decided by the Linux
ACPI driver maintainers. Several bug reports are filed in
the OSDL Bugzilla system already (for example, see
<http://bugme.osdl.org/show_bug.cgi?id=1662> and
<http://bugme.osdl.org/show_bug.cgi?id=1741>)
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?)
c) Ignore it and disable Linux ACPI support on these motherboards
Any comments?
- - andreas
- --
Andreas Haumer | mailto:[email protected]
*x Software + Systeme | http://www.xss.co.at/
Karmarschgasse 51/2/20 | Tel: +43-1-6060114-0
A-1100 Vienna, Austria | Fax: +43-1-6060114-71
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFACnEPxJmyeGcXPhERAmKEAKC6ED8nghvXV4ti2DLEOOcnhKnLIACfdupb
RNztxbT71WtLMF51siS6cKk=
=BZZ6
-----END PGP SIGNATURE-----
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
On Sun, 18 Jan 2004 16:01:58 +0000
Andrew Walrond <[email protected]> wrote:
> > 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!
Just a short (general) note on that:
I find it amazing how some companies manage to ignore valuable input, because
even good companies can always get better through listening to customers. Alas
good companies can get real bad if they don't. So take a customers' choice:
stop buying their products if they don't listen to you in case of problems.
This is market, you always have another choice.
Are we _really_ sure this is a BIOS issue? What's the ACPI-maintainers opinion?
I can't really comment technically, I have no deep knowledge about ACPI ...
Regards,
Stephan