Bug 2641 - Reserve Device IO ports enumerated in DSDT
Summary: Reserve Device IO ports enumerated in DSDT
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Other (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: Shaohua
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-04 22:21 UTC by Chris Cheney
Modified: 2004-10-14 23:43 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.5
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
eMachines M6807 - WinXP I/O Ports (1.88 KB, text/plain)
2004-05-04 22:53 UTC, Chris Cheney
Details
eMachines M6807 - Linux I/O Ports (761 bytes, text/plain)
2004-05-04 22:53 UTC, Chris Cheney
Details
eMachines M6807 - WinXP I/O Ports - ACPI info (2.54 KB, text/plain)
2004-05-04 23:46 UTC, Chris Cheney
Details
eMachines M6807 - acpidmp (80.24 KB, text/plain)
2004-05-05 00:27 UTC, Chris Cheney
Details
m6807 lspci output (Knoppix) (25.07 KB, text/plain)
2004-05-08 17:39 UTC, Chris Cheney
Details
proposal patch for the issue (2.67 KB, patch)
2004-05-12 20:44 UTC, Shaohua
Details | Diff
proposal patch (5.10 KB, patch)
2004-05-16 21:40 UTC, Shaohua
Details | Diff
patch for 2.6 kernel (6.64 KB, patch)
2004-05-20 02:28 UTC, Shaohua
Details | Diff
patch for 2.4 kernel (7.22 KB, patch)
2004-05-20 02:30 UTC, Shaohua
Details | Diff

Description Chris Cheney 2004-05-04 22:21:10 UTC
Distribution: Debian
Hardware Environment: Arima W720-K8/eMachines M6807
Software Environment: Linux 2.6.5
Problem Description:

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.
Comment 1 Chris Cheney 2004-05-04 22:53:02 UTC
Created attachment 2792 [details]
eMachines M6807 - WinXP I/O Ports
Comment 2 Chris Cheney 2004-05-04 22:53:51 UTC
Created attachment 2793 [details]
eMachines M6807 - Linux I/O Ports
Comment 3 Chris Cheney 2004-05-04 23:46:24 UTC
Created attachment 2794 [details]
eMachines M6807 - WinXP I/O Ports - ACPI info
Comment 4 Len Brown 2004-05-05 00:06:39 UTC
please attach the output from acpidmp 
Comment 5 Chris Cheney 2004-05-05 00:27:58 UTC
Created attachment 2795 [details]
eMachines M6807 - acpidmp
Comment 6 Chris Cheney 2004-05-05 00:35:00 UTC
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. ;)

http://www.muru.com/linux/amd64/patches/patch-m680x-pcmcia-acpi-fix
Comment 7 Chris Cheney 2004-05-05 13:25:49 UTC
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. 
Comment 8 Shaohua 2004-05-07 17:34:05 UTC
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.
Comment 9 Chris Cheney 2004-05-08 01:02:30 UTC
David, 
 
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). 
 
Thanks, 
Chris 
Comment 10 Shaohua 2004-05-08 02:33:32 UTC
The problem here is if we disable ACPI, how could we reserve the io ports. 
Comment 11 Chris Cheney 2004-05-08 03:04:33 UTC
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? 
Comment 12 Chris Cheney 2004-05-08 03:16:34 UTC
Sorry I typod, it appears my desktop athlon64 (MSI Neo FIS2R) actually uses ~ 
0x0800-0x087F. 
 
Desktop K8T800 (FADT) 
--------------------- 
PM1a_EVT_BLK 0x0800-0x0803 
PM1a_CNT_BLK 0x0804-0x0805 
PM_TMR_BLK   0x0808-0x080B 
GPE0_BLK     0x0820-0x0823 
SMI_CMD      0x082F 
 
Laptop K8T800 (FADT) 
-------------------- 
PM1a_EVT_BLK 0x4000-0x4003 
PM_TMR_BLK   0x4008-0x400B 
GPE0_BLK     0x4020-0x4023 
SMI_CMD      0x402F 
PM1a_CNT_BLK 0xF510-0xF511 
 
Comment 13 Chris Cheney 2004-05-08 17:39:20 UTC
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.
Comment 14 Shaohua 2004-05-12 20:44:24 UTC
Created attachment 2851 [details]
proposal patch for the issue

Could you please try the patch? It will reserve IO ports used by motherboard.
Thanks.
Comment 15 Kedar Patankar 2004-05-16 19:51:19 UTC
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
like this.
Comment 16 Kedar Patankar 2004-05-16 21:36:40 UTC
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
like this.
Comment 17 Shaohua 2004-05-16 21:40:29 UTC
Created attachment 2881 [details]
proposal patch

And how about this updated patch. It reserve more IO ports according to DSDT
and FADT. Thanks.
Comment 18 Kedar Patankar 2004-05-17 01:37:44 UTC
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.
Comment 19 Guyang Mao 2004-05-17 02:18:33 UTC
The yenta on my M6805 no longer hangs the machine after I applied the 2nd patch
to a 2.6.6-bk3.
Comment 20 Kedar Patankar 2004-05-17 23:11:45 UTC
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:

http://www.muru.com/linux/amd64/patches/patch-m680x-pcmcia-acpi-fix
http://www.muru.com/linux/amd64/patches/patch-amd64-via-ioapic

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.

Todo/Broken:
============
Check if the ethernet is functional.
Sound from the onboard via h/w is quite broken.
Check dual head display support.
Comment 21 Guyang Mao 2004-05-18 20:30:24 UTC
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.
Comment 22 Tony Lindgren 2004-05-18 21:59:25 UTC
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
init starts.

Tony
Comment 23 Shaohua 2004-05-20 02:28:53 UTC
Created attachment 2920 [details]
patch for 2.6 kernel
Comment 24 Shaohua 2004-05-20 02:30:11 UTC
Created attachment 2921 [details]
patch for 2.4 kernel
Comment 25 Kedar Patankar 2004-05-27 22:22:30 UTC
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
errors
Comment 26 Shaohua 2004-05-27 22:39:49 UTC
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.
Comment 27 Chris Cheney 2004-07-20 09:58:41 UTC
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(?) 
Comment 28 Sergey Vlasov 2004-10-09 10:31:36 UTC
This patch (2.4.x version - 2.4.27 +
http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/24-stable-release/acpi-20040326-24-stable-release.diff.bz2)
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!
Comment 29 Shaohua 2004-10-09 18:01:53 UTC
Please try latest -mm tree which includes a final fix for such problems.
Comment 30 Shaohua 2004-10-14 23:43:53 UTC
Has been in base kernel

Note You need to log in before you can comment on or make changes to this bug.