On Mon, Jul 2, 2012 at 2:49 PM, Kamil Grzebien [off-list ref] wrote:

On Mon, Jul 2, 2012 at 6:31 AM, Stanislaw Gruszka [off-list ref] wrote:

quoted

On Sun, Jul 01, 2012 at 07:01:58PM +0100, Kamil Grzebien wrote:

quoted

I haven't tried your patch yet, but wanted to share with one thing.
Currently I use new kernel 3.4.3, where the problem doesn't exist
anymore. However I still would like to know what was the cause and
which change brought the solution. Is there anything which comes to
your mind in terms of recent changes in kernel? I also added logs from
the newest kernel, so it might be easier for track it.

Below is the diff from working kernel and non working kernel.
You are using PAE kernel what influence PCI mappings. Is this fixed also
on 3.4 non-PAE kernel?

The problem is also fixed in non-PAE kernel. I've attached the logs
from that kernel also. Besides that currently I was comparing both PAE
kernels installed on my machine - kernel 3.3.7 (problem exist) and
kernel 3.4.3 (problem solved). There must be something that has
changed either in the code or maybe kernel configuration!?

I compared your 3.3.0 and 3.4.3 logs:

    -Linux version 3.3.0-4.fc16.i686
(mockbuild@x86-04.phx2.fedoraproject.org) gcc version 4.6.2 20111027
(Red Hat 4.6.2-1) (GCC) ) #1 SMP Tue Mar 20 18:45:14 UTC 2012
    +Linux version 3.4.3-1.fc17.i686
(mockbuild@x86-04.phx2.fedoraproject.org) gcc
version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC) ) #1 SMP Mon Jun 18
20:52:37 UTC 2012

I don't see much that's different, except this:

    -pci 0000:03:09.1: reg 10: [mem 0xf1bff400-0xf1bff4ff]
    +pci 0000:03:09.1: reg 10: [mem 0xf1bff500-0xf1bff5ff]

which hints that the BIOS configured that device (an SD Host
controller) differently.  Is it possible that a BIOS setup change is
what made the difference?  Can you reproduce the failure and success
on the exact same hardware & BIOS setup?  I also notice the 3.3.0
failure was apparently on battery power and the 3.4.3 success was with
AC power.  Shouldn't matter, but obviously *something* that shouldn't
matter does matter in this case.

The problem device is 0000:0b:00.0, and the bridge 00:1c.1 leads to
bus 0b.  There's a little bit more noise in 3.4.3 related to 1c.1
bridge windows, but the ultimate configuration is the same except for
the 64-bit pref window, which 0b:00.0 doesn't use anyway:

 pci 0000:0b:00.0: reg 10: [mem 0xf1eff000-0xf1efffff]
-pci 0000:00:1c.1: BAR 15: assigned [mem 0xf0200000-0xf03fffff 64bit pref]
+pci 0000:00:1c.1: bridge window [io  0x1000-0x0fff] to [bus 0b-0b]
add_size 1000
+pci 0000:00:1c.1: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus
0b-0b] add_size 200000
+pci 0000:00:1c.1: res[15]=[mem 0x00100000-0x000fffff 64bit pref]
get_res_add_size add_size 200000
+pci 0000:00:1c.1: res[13]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
+pci 0000:00:1c.1: BAR 15: assigned [mem 0xf0400000-0xf05fffff 64bit pref]
 pci_bus 0000:0b: resource 1 [mem 0xf1e00000-0xf1efffff]
-pci_bus 0000:0b: resource 2 [mem 0xf0200000-0xf03fffff 64bit pref]
+pci_bus 0000:0b: resource 2 [mem 0xf0400000-0xf05fffff 64bit pref]

Any ideas, Yinghai?

Bjorn