On 01/08/2011 01:16 AM, Bjorn Helgaas wrote:

On Friday, January 07, 2011 04:29:00 pm Jiri Slaby wrote:

quoted

On 01/08/2011 12:03 AM, Bjorn Helgaas wrote:

quoted

On Friday, January 07, 2011 01:44:35 pm Jiri Slaby wrote:

quoted

On 01/06/2011 08:24 PM, Bjorn Helgaas wrote:

quoted

Theoretically, ACPI tells us about the GPIO/TCO/etc. regions in a
generic way via namespace devices or something in the static tables.
Is that generic information missing, or is it there and Linux is
ignoring it?  If we're ignoring it, I'd rather fix that.

It works for most boxes I would say. Try to google for "claimed by ICH4
ACPI/GPIO/TCO", it reports sane ranges like 0400-047f or 4000-407f.

My point is that BIOS should be telling the OS about GPIO/TCO/etc.
regions via an ACPI mechanism, and, ideally, we would use that rather
than reading the address out of chipset-dependent registers.

Even though PMBASE says the ACPI registers occupy 128 bytes from
0x100-0x17f, it's likely there's no actual conflict between the
last 16 bytes and the IDE device.

I wouldn't say so. According to the datasheet 0x60-0x7f of the space
(i.e. 0x160-0x17f here) is for TCO registers. There:
0x10 -- Software IRQ Generation Register (i.e. 0x170)
0x11-0x1f -- reserved (0x171-0x17f)

So at least 0x170 should be conflicting. Unless TCO is unused/disabled
and not mapped there at all. May be that the case?

Maybe.  All your patch does is avoid reserving this 0x100-0x1f7
region; it doesn't actually *move* anything.  And the IDE device
apparently works at the 0x170 compatibility address.  So the
ICH ACPI stuff is still at 0x100-0x17f, so apparently they don't
conflict or maybe the ICH ACPI stuff is disabled.  If the box
doesn't even have ACPI, I suppose there would be no reason to
have the ACPI registers enabled.  Is there something in ICH
that tells us whether they're enabled?

Hmm, there is:
bit 4: ACPI Enable (ACPI_EN) — R/W.
  0 = Disable.
  1 = Decode of the I/O range pointed to by the ACPI Base register is
enabled, and the ACPI power management function is enabled. Note that
the APM power management ranges (B2/B3h) are always enabled and are not
affected by this bit.

at 0x44 in the bridge conf space. So we should definitely check the value.

I don't have the actual value in that register when ACPI is disabled in
BIOS. From the run where acpi=off was passed to the kernel, there is
0x10 (i.e. ACPI_EN=1). However I don't know whether ACPI was disabled in
BIOS at that time.

quoted

quoted

ACPI probably reports this region via the FADT (the GPE PM register
blocks) and possibly a PNP0C02 device.  These will probably report
something that doesn't conflict with the legacy IDE ports, i.e., a
subset of the 0x100-0x17f range.

Ooooh, I notice in the bugzilla that something's wrong with SMBIOS
(comment 29) and ACPI is disabled because we couldn't find the
RSDP (dmesg in comment 27).  What sort of machine is this, anyway?
We didn't find PNPBIOS, either.

Hmm, it looks like some old crap. What exact information you would like
to know? I've just asked if ACPI is not disabled in BIOS. There should
be no machine without ACPI running still in the 21st century, I think.

I'm just wondering if the machine actually does have ACPI, but
there's some Linux problem related to finding the tables.  If it's
really old enough, that wouldn't be so surprising, but I see USB
and gigabit NIC hardware, so it's not truly ancient.

The box is:
http://www.xembedded.com/content/vme/processors/xvme-690.php
and has ACPI, but the user disabled ACPI (I don't know why yet).

thanks,
-- 
js