Hardware Environment: Arima W720-K8/eMachines M6807
Software Environment: Linux 2.6.5
io ports known about by acpi are not reserved which causes problems. Windows
XP does reserve the ports which apparently keeps problems from occuring from
trying to use the ioports for other things...
Steps to reproduce:
Note which ports are reserved by "Motherboard Resources" under Windows XP and
see if they are reserved under Linux, in most/all cases they are not.
Created attachment 2792 [details]
eMachines M6807 - WinXP I/O Ports
Created attachment 2793 [details]
eMachines M6807 - Linux I/O Ports
Created attachment 2794 [details]
eMachines M6807 - WinXP I/O Ports - ACPI info
please attach the output from acpidmp
Created attachment 2795 [details]
eMachines M6807 - acpidmp
The original problem that I noticed that seemed to be caused by this issue is
that yenta cardbus driver hangs the M6807 system. Pavel Machek created a patch
that Tony Lindgren has on his site that simply moved the starting cardbus i/o
port range from 0x4000 -> 0x5000. This appears to just be an ugly hack. On the
eMachines M6807 the i/o port range 0x4000-0x407F is reserved under Windows
which seems to be done via ACPI. Configuring reserved i/o port ranges (and
possibly memory?) via ACPI under Linux will probably help alleviate various
hard to find issues with acpi. At least that is my hope. ;)
In the case of the 0x4000-0x407F region I no longer think that WinXP reserves
OperationRegion listed fields but instead reserves what is marked in the FACP.
I also think that WinXP reserves ranges based on DecodeXX fields but treats
the sizes listed in them as less accurate than what is in the FACP, its size
being preferred. If I decoded the FACP correctly the 0x4000-0x407F range is
used by the PM1a Event Register Block.
Generally, the IO ports is reserved in quirks.c, which does the issue for many
chipsets, like ICH4, etc. Please show the type of your chipsets, so we can
verify if there is a quirk for it.
The chipset is VIA K8T800, there are some other dumps (biosdecode/dmidecode)
on bug #2090.
Is there a particular reason that Linux hardcodes this stuff in pci quirks or
is it just that no has wanted to take the time to fix it properly? As far as I
can tell WinXP doesn't need a quirks file since it works properly with
chipsets that didn't even exist when it was released... It would be nice if
Linux could do whatever WinXP does, possibly allocating the ports from
ACPI(?), so that new hardware isn't broken for months and possibly years,
which by the way the K8T800 has been out over a year now, until someone
figures out what is wrong.
BTW - The ACPI DSDT PNP0C02 _CRS does reserve all the i/o ranges that WinXP
shows as used by "Motherboard resources" except for what appears to be a typo
of 0x8000 instead of 0x4000. However, WinXP knows to reserve 0x4000-0x407F
instead, is it getting this information from some other means, maybe pnpbios?
I don't know how to dump information besides the ACPI tables. If someone knows
how to get other related info let me know. Except for the 0x8000 issue what
ACPI shows and what WinXP reserves for all devices match up, unlike what Linux
reserves for devices in general (almost all of which is different).
The problem here is if we disable ACPI, how could we reserve the io ports.
I'm not certain whether the system even works properly with ACPI disabled, it
works to a certain extent but I don't think everything works. I tested it
several months ago and I seem to recall there being some issues even under
WinXP. In this case in particular though the ports having issues are the
ports that need to be reserved for ACPI. Also it doesn't seem to be the
chipset itself that determines the ports used by ACPI, I guess that is by the
ACPI chipset instead? My desktop K8T800 uses ports in the 0x8000-0x807F range
according to my FADT table, I haven't tested booting into WinXP on it though.
Unless WinXP does some kind of magic fixup on my laptop there must be some
other way its getting the I/O port range for my ACPI registers since _CRS for
it appears to be wrong, any ideas?
Sorry I typod, it appears my desktop athlon64 (MSI Neo FIS2R) actually uses ~
Desktop K8T800 (FADT)
Laptop K8T800 (FADT)
Created attachment 2819 [details]
m6807 lspci output (Knoppix)
This lspci output is from running under Knoppix since currently I do not have
linux on my system, I had to reformat the drive due to some WinXP issues. I
will be reinstalling Linux on the system soon so if it needs to be run under
the patched 2.6 kernel let me know and I will update it.
Created attachment 2851 [details]
proposal patch for the issue
Could you please try the patch? It will reserve IO ports used by motherboard.
Tried it out with 2.6.6 and 2.6.5 that comes with fedora core 2 test 3 for
x86_64. In both cases, the machine freezes during boot. With 2.6.6, this happens
very rapidly and once it does freeze the screen is all screwed up (mostly blank
with some illegible junk). In case of FC2T3 + your patch, it goes upto "freeing
up kernel memory" and then freezes. The stock kernel from FC2T3 didn't lock up
Created attachment 2881 [details]
And how about this updated patch. It reserve more IO ports according to DSDT
and FADT. Thanks.
OK. Tried out that second patch and this is much better. I tried it so far only
with FC2T3 stock kernel. It at least booted properly. I can provide you with any
dumps of /proc or /sys.
The yenta on my M6805 no longer hangs the machine after I applied the 2nd patch
to a 2.6.6-bk3.
More info about the second patch. The FC2T3 stock kernel (2.6.5 + fedora
patches) with the updated patch of 16-May did give me dis-functional usb and
flash reader. I then applied the following patches on top of the May-16 patch:
Booting the resultant kernel with "acpi ioapic" on the command-line resulted in
the emachines 6805 work quite well with uhci usb drivers.
1. The USB ports work, I was able to mount my usb key.
2. The built-in flash reader works.
3. The ACPI seems to be quite functional:
lid switch open/close detect worked.
acpi daemon detected power switch press and did graceful shutdown.
Check if the ethernet is functional.
Sound from the onboard via h/w is quite broken.
Check dual head display support.
2.6.6-bk3 supersedes patch-amd64-via-ioapic, the proposal patch from this bug
supersedes patch-m680x-pcmcia-acpi-fix. By the way those muru.com patches are
hackish and not proper fixes for the underlying problems.
Hey cool, the reserve motherboard ioports patch does some good things :)
It fixes the problem where system would hang if power was plugged/unplugged
with the PCMCIA driver loaded. So that takes care of the patch by Pavel.
It does not make the power button work for me though, are you running in x86_64
mode or x86 mode? I'm running x86_64 mode. Version 2.6.6-bk.
Hitting power button just turns off my machine immediately. What about if you
hit Fn + F4 to try to change the display from between laptop and external
monitor? For me it hangs the system. (The cursor blinks but nothing works)
Also, if the processor module is compiled in, system hangs during boot before
Created attachment 2920 [details]
patch for 2.6 kernel
Created attachment 2921 [details]
patch for 2.4 kernel
Tried both the patches. Patch for 2.6 is good. Everything I tested works. I
tried it with 2.6.6 and the FC2 testing update version of 2.6.6. The 2.4 version
was not good when tried with 2.4.22 (FC1 stock) though. It crapped out during
compile with error "acpi_disabled" not defined. After fixing that, it had more
I didn't try FC1, but my test in base kernel 2.4.27-pre3 just works fine, no
compiler error. could you tell me what's the error? thansk.
Why was this report closed? The patch never made it into the kernel but it is
closed as resolved code_fix. I was sick for about a month and just now noticed
this bug got closed accidentally(?)
This patch (2.4.x version - 2.4.27 +
breaks lm_sensors on ASUS A7V8X. The i2c-viapro module does not load, because
the I/O ports are already reserved:
# cat /proc/ioports | grep motherboard
e400-e47f : motherboard
e800-e81f : motherboard
Therefore I get:
i2c-viapro.o version 2.8.6 (20040405)
VIA Technologies, Inc. VT8235 ISA Bridge: SMBus region 0xe800 already in use!
Please try latest -mm tree which includes a final fix for such problems.
Has been in base kernel