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.
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. ;) http://www.muru.com/linux/amd64/patches/patch-m680x-pcmcia-acpi-fix
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.
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
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 ~ 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
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. Thanks.
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.
Created attachment 2881 [details] proposal patch 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: 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.
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 init starts. Tony
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 errors
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 + 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!
Please try latest -mm tree which includes a final fix for such problems.
Has been in base kernel