|Summary:||On H12Y based notebooks 8139too (mmio) or sdhci freeze the system|
|Product:||Platform Specific/Hardware||Reporter:||Arne Fitzenreiter (arne)|
|Severity:||normal||CC:||alan, bjorn.helgaas, dominik.bodi, florian, jbarnes, kernel.bugs, yahgrp|
Hack to force linux to use other mmio addresses
iomem without patch
iomem with patch
dmesg without patch
dmesg with patch
lspci without patch
lspci with patch
new version of the patch with more hardwarechecks
H12Y mmio patch
lspci -s1f.0 -xxx
grep . /sys/bus/pnp/devices/*/*
patch for FW/PCI bridge overlap debug
dmesg with bridgewindowpatch
lspci -v with bridgewindowpatch
debug patch to disable FW decoding
Dmesg output with fw disable
Output of dmidecode
Test patch to reserve the problem region
Description Arne Fitzenreiter 2008-03-12 06:17:51 UTC
Distribution: Ubuntu, Fedora, Knoppix (?all?) Hardware Environment: Averatec 2460 - Twinhead H12Y OEM Problem Description: The system freeze if i load "8139too" or "sdhci" kernel module. I have built a special version of "8139too" that use pio mode instead of mmio that works. lspci output: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA]) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at ffe80000 (32-bit, non-prefetchable) [size=512K] I/O ports at ec00 [size=8] Memory at d0000000 (32-bit, prefetchable) [size=256M] Memory at ffe40000 (32-bit, non-prefetchable) [size=256K] Capabilities:  Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, fast devsel, latency 0 Memory at ffd80000 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at ffe38000 (64-bit, non-prefetchable) [size=16K] Capabilities:  Power Management version 2 Capabilities:  Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities:  Express Unknown type IRQ 0 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: ff200000-ff2fffff Capabilities:  Express Root Port (Slot+) IRQ 0 Capabilities:  Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities:  Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Capabilities: [a0] Power Management version 2 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 0000a000-0000afff Memory behind bridge: fef00000-ff1fffff Capabilities:  Express Root Port (Slot+) IRQ 0 Capabilities:  Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities:  Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Capabilities: [a0] Power Management version 2 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, medium devsel, latency 0, IRQ 18 I/O ports at e880 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at e800 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, medium devsel, latency 0, IRQ 21 I/O ports at e480 [size=32] 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI]) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at e400 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, medium devsel, latency 0, IRQ 18 Memory at ffe37c00 (32-bit, non-prefetchable) [size=1K] Capabilities:  Power Management version 2 Capabilities:  Debug port 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=04, sec-latency=32 I/O behind bridge: 0000c000-0000dfff Memory behind bridge: ff300000-ffbfffff Prefetchable memory behind bridge: 00000000bdf00000-00000000bfefffff Capabilities:  Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, medium devsel, latency 0 Capabilities: [e0] Vendor Specific Information 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02) (prog-if 80 [Master]) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 19 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=1] I/O ports at ffa0 [size=16] Capabilities:  Power Management version 2 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: medium devsel, IRQ 5 I/O ports at 0400 [size=32] 01:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) Subsystem: Intel Corporation Unknown device 1001 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at ff2ff000 (32-bit, non-prefetchable) [size=4K] Capabilities: [c8] Power Management version 2 Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [e0] Express Legacy Endpoint IRQ 0 03:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, medium devsel, latency 64, IRQ 16 I/O ports at d800 [size=256] Memory at ffbfec00 (32-bit, non-prefetchable) [size=256] Capabilities:  Power Management version 2 03:06.0 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) (prog-if 10 [OHCI]) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: bus master, medium devsel, latency 64, IRQ 19 Memory at ff300000 (32-bit, non-prefetchable) [size=4K] Memory at ffbfe000 (32-bit, non-prefetchable) [size=2K] Capabilities:  Power Management version 2 03:06.2 Generic system peripheral : O2 Micro, Inc. Integrated MMC/SD Controller (rev 01) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: slow devsel, IRQ 5 Memory at ffbfe800 (32-bit, non-prefetchable) [size=256] Capabilities: [a0] Power Management version 2 03:06.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller (rev 01) Subsystem: TWINHEAD INTERNATIONAL Corp Unknown device a003 Flags: slow devsel, IRQ 5 Memory at ffbff000 (32-bit, non-prefetchable) [size=4K] Capabilities: [a0] Power Management version 2
Comment 1 Jennifer Hodgdon 2008-05-27 07:03:17 UTC
Just a note: This bug can be overcome by using a kernel compiled with PIO off in the sdhci module, as noted in the bug report above. The latest Ubuntu (8.04) comes with the kernel compiled that way, because of this bug.
Comment 2 Jennifer Hodgdon 2008-05-27 07:04:36 UTC
Sorry, that is PIO off in the 8139too module, not sdhci. See also Bug #9905 for more info about the sdhci module on this laptop (or its clone).
Comment 3 Arne Fitzenreiter 2008-05-27 07:45:08 UTC
Hi Jennifer, i have only linked to this report because the lspci log was inside. We have the same laptops. (I think Thwinhead H12Y is the correct name because this was printed on the PCB and in the Bios Data) The reason for crashing is the same for both modules. Some mmio read or write accesses in the assignid memory area. sdhci and 8139too mmio areas assigned very close in the address area. I have seen that windows reconfigure both devices. Maybee there is a addressing issue in a Mainboard chip. The other devices around this are working without problems. Arne
Comment 4 Thomas Gleixner 2008-09-05 05:08:47 UTC
Arne, any updates on this one ? Does the problem persist with recent kernel versions ?
Comment 5 Arne Fitzenreiter 2008-09-08 13:09:47 UTC
Created attachment 17681 [details] Hack to force linux to use other mmio addresses
Comment 6 Arne Fitzenreiter 2008-09-08 13:10:26 UTC
Yes the problem is still present also in 2.6.27-rc5 I think in the laptop is an other device that also use the MMIO Address Area: ffbfe800-ffbfecff of maybee also to ffbfefff If i apply the attached hack that change the size of the MMIO Areas of the Cardreader and the Networkcard so that linux has to move it to an other area both components work.
Comment 7 Bjorn Helgaas 2008-09-18 23:49:08 UTC
In both this and bug #9905, the system hangs when we attempt MMIO to at least some of the devices behind the PCI bridge at 00:1e.0. Arne, you mention hangs when you use 8139too or sdhci. There's also a firewire device behind the bridge. Does the system hang when you load the firewire driver, too? You can get 8139too and sdhci to work with the quirk you attached. But we still have to use the 00:1e.0 bridge, which makes me think it might be an address conflict with another device, not a problem with the bridge itself. Can you please turn on CONFIG_PCI_DEBUG and CONFIG_PNP_DEBUG and attach the complete dmesg log and contents of /proc/iomem? Please do this both with your patch and without it.
Comment 8 Arne Fitzenreiter 2008-09-22 06:30:57 UTC
Created attachment 17939 [details] iomem without patch
Comment 9 Arne Fitzenreiter 2008-09-22 06:31:39 UTC
Created attachment 17940 [details] iomem with patch
Comment 10 Arne Fitzenreiter 2008-09-22 06:32:05 UTC
Created attachment 17941 [details] dmesg without patch
Comment 11 Arne Fitzenreiter 2008-09-22 06:32:26 UTC
Created attachment 17942 [details] dmesg with patch
Comment 12 Arne Fitzenreiter 2008-09-22 06:32:51 UTC
Created attachment 17943 [details] lspci without patch
Comment 13 Arne Fitzenreiter 2008-09-22 06:33:09 UTC
Created attachment 17944 [details] lspci with patch
Comment 14 Arne Fitzenreiter 2008-09-22 06:34:14 UTC
Created attachment 17945 [details] new version of the patch with more hardwarechecks
Comment 15 Arne Fitzenreiter 2008-09-22 06:37:35 UTC
I cant say if the other devices (firewire and memorystick) are affected. Memorystick was not supported at my kernel version and the ohci driver seems not to use the area at ffbfxxxx
Comment 16 Arne Fitzenreiter 2008-10-06 08:26:32 UTC
Created attachment 18179 [details] H12Y mmio patch Here a new version that also move the firewire and the Memorystick out of the problematic mem-area (now lscpi shown no deviced at 0xFFB00000-0xFFBFFFFF
Comment 17 Jennifer Hodgdon 2008-11-24 09:07:54 UTC
Arne - I tried your patch, and it definitely allows me to do a modprobe sdhci and not crash (which in itself is useful), but I don't see any evidence that the SD card reader is working. I applied the patch to 18.104.22.168 (from the linux.org source), and am running Ubuntu 8.10 other than my custom kernel. I insered an SD card into the card reader, after doing "modprobe sdhci", and I don't see any dmesg indicating it was recognized, and it isn't in any of the /dev/sd* devices. Much less an automount via Nautilus... Is there something else I need to do in order to actually use the SD card reader? And by the way, thanks for all your work! I never would have been able to use Linux on this PC in the first place, if it weren't for the install disk you posted on your web site.
Comment 18 Arne Fitzenreiter 2008-11-27 05:31:10 UTC
Hi Jennifer, since Kernel 2.6.27 the sdhci module is split into two modules, sdhci and sdhci_pci. The module for the h12y cardreader is sdhci_pci With this the cardreader should work. I have applied this patch to the ubuntu kernel and created a new package. The sd-card was showed on the desktop like other mass storage.
Comment 19 Jennifer Hodgdon 2008-12-02 14:44:07 UTC
Arne - thanks - that worked - I hadn't realized the module was split, and now for the first time I have been able to use the card reader on my laptop. I have a USB card reader I could plug in, so it wasn't a huge problem, but it's nice to get the hardware actually working under Linux. Now if we can just get the kernel.org or Ubuntu folks to put in your patch, we won't have to compile our own kernels any more...
Comment 20 Bjorn Helgaas 2008-12-17 13:57:43 UTC
Please attach the output of "lspci -s1f.0 -xxx" and "grep . /sys/bus/pnp/devices/*/*". We think there's an issue with something in the ffbfe800-ffbfecff address range (comment #6), and the ICH7 spec mentions ffb80000-ffbfffff as part of a Firmware Hub range. So I want to double-check that Firmware Hub decoding is disabled (see FWH_DEC_EN1, at 0xd8 in 1f.0 config space).
Comment 21 Arne Fitzenreiter 2008-12-18 05:35:52 UTC
Created attachment 19356 [details] lspci -s1f.0 -xxx
Comment 22 Arne Fitzenreiter 2008-12-18 05:36:45 UTC
Created attachment 19357 [details] grep . /sys/bus/pnp/devices/*/*
Comment 23 Bjorn Helgaas 2008-12-18 09:04:36 UTC
The value of FWH_DEC_EN1 (at D8h) is C0C0h (bits 15, 14, 7, 6 set): 15: FFF80000h – FFFFFFFFh, FFB80000h – FFBFFFFFh enabled for Firmware Hub 14: FFF00000h – FFF7FFFFh, FFB00000h – FFB7FFFFh enabled for Firmware Hub 7: F0000h – FFFFFh enabled for Firmware Hub 6: E0000h – EFFFFh enabled for Firmware Hub The PCI bridge at 1e.0 also claims the FFB00000h - FFBFFFFFh range: 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge Bus: primary=00, secondary=03, subordinate=04, sec-latency=32 Memory behind bridge: ff300000-ffbfffff That looks wrong to me, although I'm not an ICH expert. I think the bridge window should be reduced to ff300000-ffafffff. I don't know the best way to do this, but I'll poke around and try to come up with a patch.
Comment 24 Bjorn Helgaas 2008-12-18 13:38:36 UTC
Created attachment 19364 [details] patch for FW/PCI bridge overlap debug Can you try this patch? The idea is to reduce the size of the bridge aperture so it no longer overlaps the firmware range. Then we have to reassign any MMIO resources for downstream devices. This is a gross patch, but maybe we can at least figure out if we're on the right track.
Comment 25 Arne Fitzenreiter 2008-12-19 01:32:52 UTC
Hi Bjorn, the patch works after i have adapted to 2.6.27. I think you have a newer development version. At my kernel the PCI-Quirks are not configurable.
Comment 26 Arne Fitzenreiter 2008-12-19 01:35:16 UTC
Created attachment 19374 [details] dmesg with bridgewindowpatch
Comment 27 Arne Fitzenreiter 2008-12-19 01:36:06 UTC
Created attachment 19375 [details] lspci -v with bridgewindowpatch
Comment 28 Bjorn Helgaas 2008-12-19 07:55:12 UTC
Great! Thanks for testing this, Arne. I think this is pretty good evidence that this is just a BIOS defect. The BIOS should have either disabled the Firmware Hub decoding or reduced the size of the bridge aperture. I'll be on vacation for the next two weeks, but after the holidays, we can figure out a cleaner way to work around this.
Comment 29 Bjorn Helgaas 2009-01-08 16:13:43 UTC
Created attachment 19725 [details] debug patch to disable FW decoding Arne, can I trouble you to try another patch? It occurred to me that my patch from comment #28 doesn't actually confirm that the conflict is with the firmware range. It's just a very complicated way to move the devices, which you already did with your patch in comment #16. This patch just disables the firmware range. If that range is really the source of the conflict, this patch should make the devices work even without moving them. My DL320 booted and seems to work with the firmware range disabled, but it's possible that SMM or other runtime BIOS code depends on it, so I'm not sure it's really safe to disable it. But if this patch makes those devices work, even for a little while, I'll be more confident that we've identified the conflict.
Comment 30 Jennifer Hodgdon 2009-01-09 07:27:54 UTC
I don't think this patch in Comment #29 is good. I did the following: - used git to get the 2.6.28 source from kernel.org - set the 8139too module to use the standard MMIO/PIO that ignites the problem in this laptop. - applied your patch to the quirks.c file - compiled into a deb package, installed (I'm running Ubuntu) The laptop will not boot -- it gets stuck right after it loads the 8239too module, just as the unpatched kernel would. Just to make sure, I am going to apply the patch from Comment #28 again and verify that everything works. Will report back in a couple of hours.
Comment 31 Bjorn Helgaas 2009-01-09 09:06:23 UTC
Thanks testing this, Jennifer. I was sure the conflict was with the firmware range (and maybe it still is), but I guess I don't quite understand this yet. Would you mind attaching the dmesg log from the comment #29 patch when booted with "pci=earlydump"? One other idea: could you modify the comment #29 patch to clear only the upper bits of FWH_DEC_EN1? Arne reported this value: pci 0000:00:1e.0: FWH_DEC_EN1: 0xc0c0 so maybe you could write back 0xc0. Per comment #23, it's only the range enabled by bits 14 and 15 that conflicts with these devices. We should be able to leave the E0000h-FFFFFh range enabled.
Comment 32 Jennifer Hodgdon 2009-01-09 09:25:25 UTC
Just to make sure we were on the same page, I went back to the patch from comment #24, rebuilt the 2.6.28 kernel, and was able to boot up successfully, use the network card (8139too module), and use the SD card reader (sdhci-pci module). I want to run a few more tests on this kernel, while I have a working kernel :), such as seeing if suspend will work (there are suspend issues on this laptop in the 2.6.27 kernel), but after I finish that I'll try the non-working patch again, run the other tests you suggested in comment #31, and report back. Should be sometime in the next 6 hours or so.
Comment 33 Jennifer Hodgdon 2009-01-09 16:11:07 UTC
OK. I am back to the patch from comment #29, and trying to get you some dmesg output. But even with pci=earlydump added to my command line, I am apparently not getting far enough through the boot process for the dmesg log to be saved to the hard drive, before the bad 8139too module causes a problem. I also tried adding blacklist 8139too to my /etc/modprobe.d/blacklist file, but it seems to be ignoring that. I am not sure why that would be, as the directives in that file have always been respected before (especially in regards to the sdhci modules) I can set the 8139too PIO/MMIO flag in my .config and at least have a bootable 8139too module, but will that change the output you are looking for? I'm happy to try whatever you think will be useful... Sorry -- I am not all that knowledgeable about the kernel or device drivers -- I'm just an old C programmer (these days mostly doing web programming instead) with a laptop that matches Arne's... :) Any other suggestions for getting the dmesg output you want?
Comment 34 Jennifer Hodgdon 2009-01-09 16:14:08 UTC
You also asked about changing the range in your patch from comment #29. I am assuming you mean to change the line rc = raw_pci_write(0, 0, PCI_DEVFN(31, 0), 0xd8, 2, 0); to read rc = raw_pci_write(0, 0, PCI_DEVFN(31, 0), 0xc0, 2, 0); I will try making that change, rebuild the kernel, and see what happens. Give me a little while to get the build done... and let me know if I have misunderstood...
Comment 35 Jennifer Hodgdon 2009-01-09 18:00:39 UTC
With the change noted in comment #34, I still cannot boot up (still hangs just after loading the 8139too module), and I still don't get any dmesg output saved from the partial bootup, even with pci=earlydump on the boot command line. This time I tried also blacklisting both 8139too and 8139cp, but my directive in the /etc/modprobe.d/blacklist file is being ignored and they are still being loaded (I can see that on the screen right above where everything freezes, or if I boot into a different kernel, one with the PIO=MMIO fix or the comment #29 patch, where the 8139too module works, they do get loaded during bootup). Let me know if there is some other way I can test this that would be useful to you.
Comment 36 Bjorn Helgaas 2009-01-09 23:16:17 UTC
Wow, thanks for doing all this work. I'm sorry it's been so difficult and time-consuming. Changing the PIO/MMIO .config flag won't change any of the debug output. Since blacklisting isn't working for you, I think the easiest thing would be to rename the module so the loader won't find it. That should be enough to get dmesg output. I did notice today that the pci=earlydump output is missing some devices, but I haven't looked into it yet. If we're lucky, it will include the ones we're interested in. I think you mentioned you're running Ubuntu. In that case, it's fairly easy to skip building the .deb and just build a plain bzImage ("make bzImage") without an initrd or anything. You do have to be careful to build in whatever you need for your root filesystem statically (the right disk driver, filesystem, etc). The advantage is that it's usually much quicker to build a bzImage than to build and install a .deb. Then you can build the single 8139too module you care about and modprobe it by hand. It is a little fiddly to get started -- I just mention it because you seem pretty willing to jump in. If you do build a bzImage from a git tree, it won't match the Ubuntu module versions you have installed, so I don't think any of them will load. As far as the comment #34 change, the value to write is actually the last parameter, so it would look like this: rc = raw_pci_write(0, 0, PCI_DEVFN(31, 0), 0xd8, 2, 0xc0); That's just a shot in the dark, though, because I don't think it's likely that we're using the firmware area at E0000h. I still think this firmware/bridge aperture overlap is the problem. Perhaps the quirk doesn't work on your system because it doesn't match the PCI IDs or something. The dmesg output will tell us. Or you could use lspci to verify that you have a 0x8086 0x2448 device, and change the patch if yours is different.
Comment 37 Jennifer Hodgdon 2009-01-10 10:55:11 UTC
My LSPCI output is identical to Arne's as listed above, with the exception that his wirleses adapater is Intel and mine is Realtek rt73usb. But that's not one of the devices causing the problem. I have identical SD card and 8139 network cards, and everything else except the wireless card. My lspci output is here (attached to a different bug, and it appears the wireless switch was off when it was run): http://bugzilla.kernel.org/attachment.cgi?id=16294 We have different names silk screened on the front of our computers too (his is Averatec and mine is Everex). :) Anyway, I am doing a kernel build now with your corrected quirk line and CONFIG_8139TOO_PIO=y in my .config, so that I can boot up (seems easier than doing all that bzImage stuff), and I'll (a) get the dmesg output and (b) see if the SDHCI works with this latest patch. -- Reporting back later today, this is Jennifer in Seattle. Over and Out.
Comment 38 Jennifer Hodgdon 2009-01-10 18:28:29 UTC
Created attachment 19738 [details] Dmesg output with fw disable OK. I rebuilt the kernel with the corrected firmware range from comment #36, and also with CONFIG_8139TOO_PIO=y This allows me to boot, as the 8139too module will load. I booted with pci=earlydump; attached is the dmesg output. Then I tried modprobe sdhci_pci, and that hung the system. So this patch does not fix the underlying conflict issue. Bjorn -- you and Arne obviously know much more about these device driver things than I do, but I somehow thought the 8139too and sdhci_pci devices (i.e. the ethernet card and the SD card reader) were conflicting with each other, not (or not just) with some other firmware range? Anyway, I'll let you sort that out. Hope this helps... --Jennifer
Comment 39 Arne Fitzenreiter 2009-02-10 12:29:09 UTC
Sorry for the late answer. I had no time last month. I hope i find time to test it next days and add an additional read after write. Maybee the register can't correct written. @Jennifer. The PCI devices are not conflicting with other pci devices but all of them are in this firmware area...
Comment 40 Arne Fitzenreiter 2009-02-18 03:33:49 UTC
Bit 15 cannot be cleared. after writing 0 to it i get pci 0000:00:1e.0: FWH_DEC_EN1: 0x8000 Arne
Comment 41 Arne Fitzenreiter 2009-04-01 10:49:39 UTC
Hi at least i have checked the ICH7 Datasheets and found that bit15 of FH_DEC_EN1 is always on and can't disabled. But there are other config bits to disable the whole Firmware Hub address decoding. RCBA + 3410 bit11:10 has set to 10 to access the PCI and not the FWH. But this bits are set correctly so i think the Firmware Hub is not the conflicting device. http://www.intel.com/assets/pdf/datasheet/307013.pdf I have also checked the bit 3 of RCBA+3401 It is also set to zero but i think this is a typo in the datasheet. (Footnote at MemoryMap table) Is there a way to reserve this memory, if we detect the Twinhead H12Y at boot. if i use reserve=0xFFB00000,100000 at bootprompt any kernel boots without problems.
Comment 42 Alan 2012-05-13 13:51:02 UTC
Confirmed still present in 3.4rc6
Comment 43 Alan 2012-05-13 14:05:56 UTC
Can you attach the output of dmidecode Thanks Alan
Comment 44 Arne Fitzenreiter 2012-05-13 16:34:49 UTC
Created attachment 73279 [details] Output of dmidecode
Comment 45 Alan 2012-05-14 12:30:15 UTC
Created attachment 73289 [details] Test patch to reserve the problem region Test patch
Comment 46 Arne Fitzenreiter 2012-05-14 19:01:15 UTC
The patch does not fix the problem. The hardware detection works (Reserve memory on H12Y message is showed) but the pci devices are not moved out of this area.
Comment 47 Arne Fitzenreiter 2012-05-14 23:37:59 UTC
Created attachment 73299 [details] working patch No i've got it to work. Changed request_region to request_mem_region and the matching device to lpc because older kernel (2.6.32) overwrite the subvendor informations of the bridge with zero.
Comment 48 Alan 2012-05-15 16:46:13 UTC
Ok updated and submitted to x86 maintainers
Comment 49 Ewano 2012-05-18 10:21:00 UTC
(In reply to comment #48) > Ok updated and submitted to x86 maintainers Will this also be migrated to the 64bit kernel? I have been following this bug with some interest after recently inheriting a "Phillips Freevents x53" laptop which is also a re badged Twinhead H12Y. The machine originally came with an Intel T2050 cpu, unfortunately this is a non PAE capable chip - which causes some problems with Ubuntu 12.04. I have successfully upgraded the BIOS to the latest version (1.08), which provides support for Merom Stepping B2 processors, and I have upgraded the CPU for a T5200 cpu which is a 64bit processor. I have successfully installed Ubuntu 12.04 both 32bit (using the mini ISO) and 64bit - using Arne's memory reserving boot parameter. However the final problem is the SD card reader (in fact the main reason for swapping processors was reading somewhere that the sd card had been fixed in the 64bit kernel). I'm not familiar with the bug fixing system for the kernel, hence the initial question.
Comment 50 Alan 2012-05-18 11:22:43 UTC
It'll cover both 32 and 64bit