Return-path: Received: from mail-lb0-f174.google.com ([209.85.217.174]:39719 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756337Ab2GFUig (ORCPT ); Fri, 6 Jul 2012 16:38:36 -0400 Received: by lbbgm6 with SMTP id gm6so15955498lbb.19 for ; Fri, 06 Jul 2012 13:38:35 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20120313081235.GC15333@redhat.com> <20120528140448.GA22783@redhat.com> <20120529092154.GA2441@redhat.com> <20120702053110.GA2500@redhat.com> From: Bjorn Helgaas Date: Fri, 6 Jul 2012 14:38:14 -0600 Message-ID: (sfid-20120706_223853_859350_A90CE8EF) Subject: Re: Initializing iwl3945 error To: Kamil Grzebien Cc: Stanislaw Gruszka , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, Yinghai Lu Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Mon, Jul 2, 2012 at 2:49 PM, Kamil Grzebien wrote: > On Mon, Jul 2, 2012 at 6:31 AM, Stanislaw Gruszka wrote: >> On Sun, Jul 01, 2012 at 07:01:58PM +0100, Kamil Grzebien wrote: >>> 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