| Message ID | 4F89C513.3000006@snewbury.org.uk |
|---|---|
| State | Rejected, archived |
| Headers | show |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 19:42, Steven Newbury wrote: > On 14/04/12 19:05, Steven Newbury wrote: >> On 14/04/12 18:37, Steven Newbury wrote: >>> On 12/04/12 17:40, Steven Newbury wrote: >>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>> <yinghai@kernel.org> wrote: > >>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>> <steve@snewbury.org.uk> wrote: >>>>>> Thanks, that fixed it! :) I had a similar patch I've been >>>>>> working on but I had my fix in the wrong place! >>>>>> >>>>>> In the working case, initially the BIOS has set GMA to >>>>>> within the low system DRAM 0xC0000000 obviously invalid. >>>>>> This conflict is detected and it's relallocated to >>>>>> 0x12000000. >>>>>> >>>>>> I've attempted to modify probe.c to disable 64-bit BARs >>>>>> not allocated above 4G so they get reallocated above when >>>>>> possible later. It seemed to work, but again broke GMA >>>>>> despite the BAR originally containing an invalid >>>>>> address as mentioned above, it seems for some reason >>>>>> something is different when the conflict is detected and >>>>>> rellocated, compared to disabling it early then >>>>>> allocating a valid value..? >>>>>> >>> I've created a new quirk utilising an extra PCI resource flag >>> to force reallocation of the resource. It's the first >>> approach I've had any success at. It does work. Only "Intel >>> Page Flush" now gets allocated @0xe0000000! > > >> Hopefully this should fix "Intel Flush Page" > Need to export pci_bus_alloc_resource_fit for intel-gtt. Nearly worked... Or at least it should have worked, but for some reason the allocator failed to utilise 0xe0000000-0xefffffff for 04:00.0 BAR0..? 00000000-0000ffff : reserved 00010000-0009efff : System RAM 0009f000-0009ffff : reserved 000c0000-000c7fff : Video ROM 000cf000-000cffff : Adapter ROM 000f0000-000fffff : System ROM 00100000-df65a7ff : System RAM 01000000-0136defd : Kernel code 0136defe-0169127f : Kernel data 0172f000-01809fff : Kernel bss df65a800-dfffffff : reserved df65a800-df6fffff : pnp 00:0d df700000-df7fffff : pnp 00:0d f0000000-f01fffff : PCI Bus 0000:0d f6900000-f69fffff : PCI Bus 0000:09 f69f0000-f69fffff : 0000:09:00.0 f69f0000-f69fffff : tg3 f6a00000-f6bfffff : PCI Bus 0000:0d f6c00000-f6cfffff : PCI Bus 0000:0c f6cfe000-f6cfffff : 0000:0c:00.0 f6cfe000-f6cfffff : iwl4965 f6dfb700-f6dfb7ff : 0000:00:1f.3 f6dfb800-f6dfbfff : 0000:00:1f.2 f6dfb800-f6dfbfff : ahci f6dfc000-f6dfffff : 0000:00:1b.0 f6dfc000-f6dfffff : ICH HD audio f6e00000-f6efffff : 0000:00:02.0 f6f00000-f6ffffff : 0000:00:02.1 f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f] f8000000-fbffffff : reserved f8000000-fbffffff : pnp 00:0d fec00000-fec0ffff : reserved fec00000-fec003ff : IOAPIC 0 fed00000-fed003ff : HPET 0 fed00000-fed003ff : pnp 00:08 fed18000-fed1bfff : reserved fed18000-fed1bfff : pnp 00:0d fed1c000-fed1c3ff : 0000:00:1d.7 fed1c000-fed1c3ff : ehci_hcd fed1c400-fed1c7ff : 0000:00:1a.7 fed1c400-fed1c7ff : ehci_hcd fed1d000-fed1dfff : Intel Flush Page fed20000-fed8ffff : reserved fed20000-fed3ffff : pnp 00:0d fed40000-fed44fff : pnp 00:0a fed45000-fed8ffff : pnp 00:0d feda0000-feda5fff : reserved feda0000-feda3fff : pnp 00:0d feda4000-feda4fff : pnp 00:0d feda5000-feda5fff : pnp 00:0d feda6000-feda6fff : pnp 00:0d fee00000-fee0ffff : reserved fee00000-fee0ffff : pnp 00:0d fee00000-fee00fff : Local APIC fef00000-feffffff : PCI Bus 0000:04 fefbc000-fefbffff : 0000:04:00.1 fefbc000-fefbffff : ICH HD audio fefc0000-fefdffff : 0000:04:00.0 fefe0000-feffffff : 0000:04:00.0 ffa00000-ffbfffff : pnp 00:0d ffc00000-ffdfffff : PCI Bus 0000:0b ffe00000-ffffffff : reserved ffe00000-ffffffff : pnp 00:0d 100000000-11fffffff : System RAM fefa00000-fefbfffff : PCI Bus 0000:09 fefc00000-fefdfffff : PCI Bus 0000:0c fefe00000-fefffffff : PCI Bus 0000:0b ff0000000-fffffffff : 0000:00:02.0 dmesg after docking: ACPI: \_SB_.PCI0.PCIE.GDCK - docking usb 3-3: new high-speed USB device number 3 using ehci_hcd usb 3-3: New USB device found, idVendor=413c, idProduct=0058 usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 3-3:1.0: USB hub found hub 3-3:1.0: 4 ports detected ACPI Error: Method parse/execution failed [\SMI_] (Node ffff88011b031550), AE_AML_INFINITE_LOOP (20120320/psparse-536) ACPI Error: Method parse/execution failed [\_SB_.PCI0.PCIE.GDCK._DCK] (Node ffff88011b038528), AE_AML_INFINITE_LOOP (20120320/psparse-536) ACPI Exception: AE_AML_INFINITE_LOOP, \_SB_.PCI0.PCIE.GDCK - failed to execute _DCK (20120320/dock-478) usb 3-3.2: new high-speed USB device number 4 using ehci_hcd usb 3-3.2: New USB device found, idVendor=413c, idProduct=0058 usb 3-3.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 3-3.2:1.0: USB hub found hub 3-3.2:1.0: 4 ports detected pci 0000:03:08.0: [10b5:8112] type 01 class 0x060400 pci 0000:03:08.0: supports D1 pci 0000:03:08.0: PME# supported from D0 D1 D3hot pci 0000:03:08.0: PME# disabled pci 0000:03:08.0: scanning [bus 00-00] behind bridge, pass 0 pci 0000:03:08.0: bus configuration invalid, reconfiguring pci 0000:03:08.0: scanning [bus 00-00] behind bridge, pass 1 pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci 0000:03:08.0: find free busn in res: [bus 03] pci 0000:03:08.0: found free busn 0 in res: [bus 03] top pci_bus 0000:03: busn_res: extended 05 to [bus 03-08] pci_bus 0000:04: busn_res: [bus 04-08] is updated under [bus 03-08] pci_bus 0000:04: scanning bus pass 0 pci 0000:04:00.0: [1002:68e1] type 00 class 0x030000 pci 0000:04:00.0: reg 10: [mem 0x00000000-0x0fffffff 64bit pref] pci 0000:04:00.0: reg 18: [mem 0x00000000-0x0001ffff 64bit] pci 0000:04:00.0: reg 20: [io 0x0000-0x00ff] pci 0000:04:00.0: reg 30: [mem 0x00000000-0x0001ffff pref] pci 0000:04:00.0: supports D1 D2 pci 0000:04:00.1: [1002:aa68] type 00 class 0x040300 pci 0000:04:00.1: reg 10: [mem 0x00000000-0x00003fff 64bit] pci 0000:04:00.1: supports D1 D2 pci_bus 0000:04: fixups for bus pass 0 pci 0000:03:08.0: PCI bridge to [bus 04-08] pci_bus 0000:04: bus scan returning with max=04 pass 0 pci_bus 0000:04: scanning bus pass 1 pci_bus 0000:04: fixups for bus pass 1 pci 0000:03:08.0: PCI bridge to [bus 04-08] pci_bus 0000:04: bus scan returning with max=04 pass 1 pci_bus 0000:04: busn_res: [bus 04-08] end updated to [bus 04] pci_bus 0000:03: busn_res: shrunk 04 to [bus 03-04] ACPI: Delete PCI Interrupt Routing Table for 0000:04 pci 0000:03:08.0: BAR 15: can't assign mem pref (size 0x18000000) pci 0000:03:08.0: BAR 14: assigned [mem 0xfef00000-0xfeffffff] pci 0000:03:08.0: BAR 13: assigned [io 0x4000-0x4fff] pci 0000:04:00.0: BAR 0: can't assign mem pref (size 0x10000000) pci 0000:04:00.0: BAR 2: assigned [mem 0xfefe0000-0xfeffffff 64bit] pci 0000:04:00.0: BAR 2: set to [mem 0xfefe0000-0xfeffffff 64bit] (PCI address [0xfefe0000-0xfeffffff]) pci 0000:04:00.0: BAR 6: assigned [mem 0xfefc0000-0xfefdffff pref] pci 0000:04:00.1: BAR 0: assigned [mem 0xfefbc000-0xfefbffff 64bit] pci 0000:04:00.1: BAR 0: set to [mem 0xfefbc000-0xfefbffff 64bit] (PCI address [0xfefbc000-0xfefbffff]) pci 0000:04:00.0: BAR 4: assigned [io 0x4000-0x40ff] pci 0000:04:00.0: BAR 4: set to [io 0x4000-0x40ff] (PCI address [0x4000-0x40ff]) pci 0000:03:08.0: PCI bridge to [bus 04-04] pci 0000:03:08.0: bridge window [io 0x4000-0x4fff] pci 0000:03:08.0: bridge window [mem 0xfef00000-0xfeffffff] pci 0000:03:08.0: no hotplug settings from platform pci 0000:04:00.0: no hotplug settings from platform pci 0000:04:00.1: no hotplug settings from platform pci 0000:03:08.0: enabling device (0000 -> 0003) pci 0000:03:08.0: enabling bus mastering vgaarb: device added: PCI:0000:04:00.0,decodes=io+mem,owns=none,locks=none vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem vgaarb: transferring owner from PCI:0000:00:02.0 to PCI:0000:04:00.0 snd_hda_intel 0000:04:00.1: enabling device (0000 -> 0002) snd_hda_intel 0000:04:00.1: irq 49 for MSI/MSI-X snd_hda_intel 0000:04:00.1: enabling bus mastering input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1e.0/0000:03:08.0/0000:04:00.1/sound/card1/input11 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon 0000:04:00.0: enabling device (0000 -> 0003) radeon 0000:04:00.0: enabling bus mastering [drm] initializing kernel modesetting (CEDAR 0x1002:0x68E1 0x1787:0x3000). [drm] register mmio base: 0xFEFE0000 [drm] register mmio size: 131072 ATOM BIOS: B9127JMA.MFK [drm] GPU not posted. posting now... radeon 0000:04:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) radeon 0000:04:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF mtrr: zero sized request [drm] Detected VRAM RAM=512M, BAR=0M [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 2019690 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator radeon_bo_create:132 alloc size 0M bigger than 0Mb limit radeon 0000:04:00.0: Fatal error during GPU init [drm] radeon: finishing device. radeon 0000:04:00.0: no bo for sa manager [TTM] Trying to take down uninitialized memory manager type 1 [TTM] Finalizing pool allocator [TTM] Finalizing DMA pool allocator [TTM] Zone kernel: Used memory at exit: 0 kiB [drm] radeon: ttm finalized -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JyxUACgkQGcb56gMuC61WdwCcDYlntR5ydafo3lwHcDF6MPsD 9g0AoIYq4Rf+gK36+LTNyT7eQWLVOznf =ckOP -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 20:08, Steven Newbury wrote: > On 14/04/12 19:42, Steven Newbury wrote: >> On 14/04/12 19:05, Steven Newbury wrote: >>> On 14/04/12 18:37, Steven Newbury wrote: >>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>> <yinghai@kernel.org> wrote: > >>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>> <steve@snewbury.org.uk> wrote: >>>>>>> Thanks, that fixed it! :) I had a similar patch I've >>>>>>> been working on but I had my fix in the wrong place! >>>>>>> >>>>>>> In the working case, initially the BIOS has set GMA to >>>>>>> within the low system DRAM 0xC0000000 obviously >>>>>>> invalid. This conflict is detected and it's >>>>>>> relallocated to 0x12000000. >>>>>>> >>>>>>> I've attempted to modify probe.c to disable 64-bit >>>>>>> BARs not allocated above 4G so they get reallocated >>>>>>> above when possible later. It seemed to work, but >>>>>>> again broke GMA despite the BAR originally containing >>>>>>> an invalid address as mentioned above, it seems for >>>>>>> some reason something is different when the conflict is >>>>>>> detected and rellocated, compared to disabling it early >>>>>>> then allocating a valid value..? >>>>>>> >>>> I've created a new quirk utilising an extra PCI resource >>>> flag to force reallocation of the resource. It's the first >>>> approach I've had any success at. It does work. Only >>>> "Intel Page Flush" now gets allocated @0xe0000000! > > >>> Hopefully this should fix "Intel Flush Page" >> Need to export pci_bus_alloc_resource_fit for intel-gtt. > Nearly worked... Or at least it should have worked, but for some > reason the allocator failed to utilise 0xe0000000-0xefffffff for > 04:00.0 BAR0..? > > > pci 0000:03:08.0: BAR 15: can't assign mem pref (size 0x18000000) Ah! Not enough space for the bridge window!:( > pci 0000:03:08.0: BAR 14: assigned [mem 0xfef00000-0xfeffffff] pci > 0000:03:08.0: BAR 13: assigned [io 0x4000-0x4fff] pci > 0000:04:00.0: BAR 0: can't assign mem pref (size 0x10000000) pci > 0000:04:00.0: BAR 2: assigned [mem 0xfefe0000-0xfeffffff 64bit] pci > 0000:04:00.0: BAR 2: set to [mem 0xfefe0000-0xfeffffff 64bit] (PCI > address [0xfefe0000-0xfeffffff]) pci 0000:04:00.0: BAR 6: assigned > [mem 0xfefc0000-0xfefdffff pref] pci 0000:04:00.1: BAR 0: assigned > [mem 0xfefbc000-0xfefbffff 64bit] pci 0000:04:00.1: BAR 0: set to > [mem 0xfefbc000-0xfefbffff 64bit] (PCI address > [0xfefbc000-0xfefbffff]) pci 0000:04:00.0: BAR 4: assigned [io > 0x4000-0x40ff] pci 0000:04:00.0: BAR 4: set to [io 0x4000-0x40ff] > (PCI address [0x4000-0x40ff]) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JzkIACgkQGcb56gMuC63MmQCfSvoLv0y+/sbW2HJKM02QfpLN ld8AoLivGvEaB8ZSlzVcfVi8lJBQDzLS =5T9j -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury <steve@snewbury.org.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 14/04/12 20:08, Steven Newbury wrote: >> On 14/04/12 19:42, Steven Newbury wrote: >>> On 14/04/12 19:05, Steven Newbury wrote: >>>> On 14/04/12 18:37, Steven Newbury wrote: >>>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>>> <yinghai@kernel.org> wrote: >> >>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>>> <steve@snewbury.org.uk> wrote: >>>>>>>> Thanks, that fixed it! :) I had a similar patch I've >>>>>>>> been working on but I had my fix in the wrong place! >>>>>>>> >>>>>>>> In the working case, initially the BIOS has set GMA to >>>>>>>> within the low system DRAM 0xC0000000 obviously >>>>>>>> invalid. This conflict is detected and it's >>>>>>>> relallocated to 0x12000000. >>>>>>>> >>>>>>>> I've attempted to modify probe.c to disable 64-bit >>>>>>>> BARs not allocated above 4G so they get reallocated >>>>>>>> above when possible later. It seemed to work, but >>>>>>>> again broke GMA despite the BAR originally containing >>>>>>>> an invalid address as mentioned above, it seems for >>>>>>>> some reason something is different when the conflict is >>>>>>>> detected and rellocated, compared to disabling it early >>>>>>>> then allocating a valid value..? >>>>>>>> >>>>> I've created a new quirk utilising an extra PCI resource >>>>> flag to force reallocation of the resource. It's the first >>>>> approach I've had any success at. It does work. Only >>>>> "Intel Page Flush" now gets allocated @0xe0000000! >> >> >>>> Hopefully this should fix "Intel Flush Page" >>> Need to export pci_bus_alloc_resource_fit for intel-gtt. >> Nearly worked... Or at least it should have worked, but for some >> reason the allocator failed to utilise 0xe0000000-0xefffffff for >> 04:00.0 BAR0..? >> >> >> pci 0000:03:08.0: BAR 15: can't assign mem pref (size 0x18000000) > Ah! Not enough space for the bridge window!:( > please append pci=norom ... Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 21:48, Yinghai Lu wrote: > On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 14/04/12 20:08, Steven Newbury wrote: >>> On 14/04/12 19:42, Steven Newbury wrote: >>>> On 14/04/12 19:05, Steven Newbury wrote: >>>>> On 14/04/12 18:37, Steven Newbury wrote: >>>>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>>>> <yinghai@kernel.org> wrote: >>> >>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>>>> <steve@snewbury.org.uk> wrote: >>>>>>>>> Thanks, that fixed it! :) I had a similar patch >>>>>>>>> I've been working on but I had my fix in the wrong >>>>>>>>> place! >>>>>>>>> >>>>>>>>> In the working case, initially the BIOS has set GMA >>>>>>>>> to within the low system DRAM 0xC0000000 obviously >>>>>>>>> invalid. This conflict is detected and it's >>>>>>>>> relallocated to 0x12000000. >>>>>>>>> >>>>>>>>> I've attempted to modify probe.c to disable 64-bit >>>>>>>>> BARs not allocated above 4G so they get >>>>>>>>> reallocated above when possible later. It seemed >>>>>>>>> to work, but again broke GMA despite the BAR >>>>>>>>> originally containing an invalid address as >>>>>>>>> mentioned above, it seems for some reason something >>>>>>>>> is different when the conflict is detected and >>>>>>>>> rellocated, compared to disabling it early then >>>>>>>>> allocating a valid value..? >>>>>>>>> >>>>>> I've created a new quirk utilising an extra PCI resource >>>>>> flag to force reallocation of the resource. It's the >>>>>> first approach I've had any success at. It does work. >>>>>> Only "Intel Page Flush" now gets allocated @0xe0000000! >>> >>> >>>>> Hopefully this should fix "Intel Flush Page" >>>> Need to export pci_bus_alloc_resource_fit for intel-gtt. >>> Nearly worked... Or at least it should have worked, but for >>> some reason the allocator failed to utilise >>> 0xe0000000-0xefffffff for 04:00.0 BAR0..? >>> >>> >>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>> 0x18000000) >> Ah! Not enough space for the bridge window!:( >> > > please append pci=norom ... > That worked. Except of course the radeon driver can't POST the card without the ROM! ;) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KoMgACgkQGcb56gMuC62ZrACfcMJDlIVy8EfpwQyyAL91OH/d uEIAoMK2L1LEmy8OZIvaGRqt7UjxlYRM =v+/Q -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 21:48, Yinghai Lu wrote: > On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury > <steve@snewbury.org.uk> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 14/04/12 20:08, Steven Newbury wrote: >>> On 14/04/12 19:42, Steven Newbury wrote: >>>> On 14/04/12 19:05, Steven Newbury wrote: >>>>> On 14/04/12 18:37, Steven Newbury wrote: >>>>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>>>> <yinghai@kernel.org> wrote: >>> >>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>>>> <steve@snewbury.org.uk> wrote: >>>>>>>>> Thanks, that fixed it! :) I had a similar patch >>>>>>>>> I've been working on but I had my fix in the wrong >>>>>>>>> place! >>>>>>>>> >>>>>>>>> In the working case, initially the BIOS has set >>>>>>>>> GMA to within the low system DRAM 0xC0000000 >>>>>>>>> obviously invalid. This conflict is detected and >>>>>>>>> it's relallocated to 0x12000000. >>>>>>>>> >>>>>>>>> I've attempted to modify probe.c to disable 64-bit >>>>>>>>> BARs not allocated above 4G so they get >>>>>>>>> reallocated above when possible later. It seemed >>>>>>>>> to work, but again broke GMA despite the BAR >>>>>>>>> originally containing an invalid address as >>>>>>>>> mentioned above, it seems for some reason >>>>>>>>> something is different when the conflict is >>>>>>>>> detected and rellocated, compared to disabling it >>>>>>>>> early then allocating a valid value..? >>>>>>>>> >>>>>> I've created a new quirk utilising an extra PCI resource >>>>>> flag to force reallocation of the resource. It's the >>>>>> first approach I've had any success at. It does work. >>>>>> Only "Intel Page Flush" now gets allocated @0xe0000000! >>> >>> >>>>> Hopefully this should fix "Intel Flush Page" >>>> Need to export pci_bus_alloc_resource_fit for intel-gtt. >>> Nearly worked... Or at least it should have worked, but for >>> some reason the allocator failed to utilise >>> 0xe0000000-0xefffffff for 04:00.0 BAR0..? >>> >>> >>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>> 0x18000000) >> Ah! Not enough space for the bridge window!:( >> > > please append pci=norom ... > That worked. Except of course the radeon driver can't POST the card without the ROM! :-P -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KoNwACgkQGcb56gMuC62uAACfdaoIb/NT7+7xGIa4G+Wtw0K0 /IsAoL8NIg6g4q3qoTJuQpp6WyqDYUfu =OzC5 -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 11:20, Steven Newbury wrote: > On 14/04/12 21:48, Yinghai Lu wrote: >> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury >> <steve@snewbury.org.uk> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 14/04/12 20:08, Steven Newbury wrote: >>>> On 14/04/12 19:42, Steven Newbury wrote: >>>>> On 14/04/12 19:05, Steven Newbury wrote: >>>>>> On 14/04/12 18:37, Steven Newbury wrote: >>>>>>> On 12/04/12 17:40, Steven Newbury wrote: >>>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>>>>>>> <yinghai@kernel.org> wrote: >>>> >>>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>>>>>>> <steve@snewbury.org.uk> wrote: >>>>>>>>>> Thanks, that fixed it! :) I had a similar patch >>>>>>>>>> I've been working on but I had my fix in the >>>>>>>>>> wrong place! >>>>>>>>>> >>>>>>>>>> In the working case, initially the BIOS has set >>>>>>>>>> GMA to within the low system DRAM 0xC0000000 >>>>>>>>>> obviously invalid. This conflict is detected and >>>>>>>>>> it's relallocated to 0x12000000. >>>>>>>>>> >>>>>>>>>> I've attempted to modify probe.c to disable >>>>>>>>>> 64-bit BARs not allocated above 4G so they get >>>>>>>>>> reallocated above when possible later. It seemed >>>>>>>>>> to work, but again broke GMA despite the BAR >>>>>>>>>> originally containing an invalid address as >>>>>>>>>> mentioned above, it seems for some reason >>>>>>>>>> something is different when the conflict is >>>>>>>>>> detected and rellocated, compared to disabling >>>>>>>>>> it early then allocating a valid value..? >>>>>>>>>> >>>>>>> I've created a new quirk utilising an extra PCI >>>>>>> resource flag to force reallocation of the resource. >>>>>>> It's the first approach I've had any success at. It >>>>>>> does work. Only "Intel Page Flush" now gets allocated >>>>>>> @0xe0000000! >>>> >>>> >>>>>> Hopefully this should fix "Intel Flush Page" >>>>> Need to export pci_bus_alloc_resource_fit for intel-gtt. >>>> Nearly worked... Or at least it should have worked, but for >>>> some reason the allocator failed to utilise >>>> 0xe0000000-0xefffffff for 04:00.0 BAR0..? >>>> >>>> >>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>> 0x18000000) >>> Ah! Not enough space for the bridge window!:( >>> > >> please append pci=norom ... > > That worked. Except of course the radeon driver can't POST the > card without the ROM! :-P Can the ROM resource be mapped above 4G? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KsxIACgkQGcb56gMuC63JTQCeOK9EGuyoWPe8lsSS5Y6QcfPi 9HQAniZQP84biGVRM4bP8R6/ulGjuRWV =i8py -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 12:37, Steven Newbury wrote: > On 15/04/12 11:20, Steven Newbury wrote: >> On 14/04/12 21:48, Yinghai Lu wrote: [snip] >>> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury >>>>> >>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>>> 0x18000000) >>>> Ah! Not enough space for the bridge window!:( >>>> > >>> please append pci=norom ... > >> That worked. Except of course the radeon driver can't POST the >> card without the ROM! :-P > Can the ROM resource be mapped above 4G? I didn't really think that through, obviously it can't because it's not on a 64-bit capable bridge. I wonder though, could it be shadowed then disabled early before the IOMEM? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+LBKQACgkQGcb56gMuC61OjQCeNPLWh+k03+gvjvWtpG6B4gW0 US0AoJpCmnNrxWtScyOdvX3sP62KPGUX =Sl0p -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/12 18:25, Steven Newbury wrote: > On 15/04/12 12:37, Steven Newbury wrote: >> On 15/04/12 11:20, Steven Newbury wrote: >>> On 14/04/12 21:48, Yinghai Lu wrote: > > [snip] > >>>> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury > >>>>>> >>>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>>>> 0x18000000) >>>>> Ah! Not enough space for the bridge window!:( >>>>> > >>>> please append pci=norom ... > >>> That worked. Except of course the radeon driver can't POST the >>> card without the ROM! :-P >> Can the ROM resource be mapped above 4G? > I didn't really think that through, obviously it can't because > it's not on a 64-bit capable bridge. I wonder though, could it be > shadowed then disabled early before the IOMEM? I see there's "#if 0"'d helper functions for exactly that in rom.c. They've been disabled since 2007! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+LBgkACgkQGcb56gMuC61NGgCeJoZY9iUXeM6GuhDAntEjVrAu rsUAoIROJFA5xBrZ9qzYQTGSf7lTJUTA =lofL -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >>>>>>> >>>>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>>>>> 0x18000000) >>>>>> Ah! Not enough space for the bridge window!:( >>>>>> >> >>>>> please append pci=norom ... >> >>>> That worked. Except of course the radeon driver can't POST the >>>> card without the ROM! :-P >>> Can the ROM resource be mapped above 4G? >> I didn't really think that through, obviously it can't because >> it's not on a 64-bit capable bridge. I wonder though, could it be >> shadowed then disabled early before the IOMEM? > I see there's "#if 0"'d helper functions for exactly that in rom.c. > They've been disabled since 2007! solution could be one of three: 1. when bridge support 64bit pref, will not allocate rom bar in bridge pref resource. ====> patch: rom_pref.patch 2. unconditionally to make rom bar allocation in bridge non-pref range. ====> patch: rom_no_pref.patch Looks like BIOS and at least one of other OSes is doing that. I can not find the the history why ROM res is with PREFETCH bit set. Maybe Linus has some idea about that. 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but that could fail. so could hack it like a. disable bar 0x10 and steal BAR address, then set 0x30 to that address then copy ROM to ram. after that, disable rom again and set back address to 0x10. You try to update radeon_get_bios() to achieve that. Yinghai
On Sun, Apr 15, 2012 at 1:05 PM, Yinghai Lu <yinghai@kernel.org> wrote: > On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >>>>>>>> >>>>>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>>>>>> 0x18000000) >>>>>>> Ah! Not enough space for the bridge window!:( >>>>>>> >>> >>>>>> please append pci=norom ... >>> >>>>> That worked. Except of course the radeon driver can't POST the >>>>> card without the ROM! :-P >>>> Can the ROM resource be mapped above 4G? >>> I didn't really think that through, obviously it can't because >>> it's not on a 64-bit capable bridge. I wonder though, could it be >>> shadowed then disabled early before the IOMEM? >> I see there's "#if 0"'d helper functions for exactly that in rom.c. >> They've been disabled since 2007! > > solution could be one of three: > 1. when bridge support 64bit pref, will not allocate rom bar in bridge > pref resource. > ====> patch: rom_pref.patch > > 2. unconditionally to make rom bar allocation in bridge non-pref range. > ====> patch: rom_no_pref.patch missed attach rom_no_pref.patch > Looks like BIOS and at least one of other OSes is doing that. > > I can not find the the history why ROM res is with PREFETCH bit set. > Maybe Linus has some idea about that. > > 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but > that could fail. > so could hack it like a. disable bar 0x10 and steal BAR address, > then set 0x30 to that address then copy ROM to ram. > after that, disable rom again and set back address to 0x10. > You try to update radeon_get_bios() to achieve that. > > Yinghai
On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> wrote: >> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but >> that could fail. >> so could hack it like a. disable bar 0x10 and steal BAR address, >> then set 0x30 to that address then copy ROM to ram. >> after that, disable rom again and set back address to 0x10. >> You try to update radeon_get_bios() to achieve that. patches for solution 3: map_rom.patch will try to borrow mem or mem pref bar for ROM copying and You still need to use pci=norom Yinghai
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/04/12 07:54, Yinghai Lu wrote: > On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> > wrote: >>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> >>> but that could fail. so could hack it like a. disable bar 0x10 >>> and steal BAR address, then set 0x30 to that address then copy >>> ROM to ram. after that, disable rom again and set back address >>> to 0x10. You try to update radeon_get_bios() to achieve that. > > patches for solution 3: map_rom.patch will try to borrow mem or mem > pref bar for ROM copying > > and You still need to use pci=norom > I've tested solution 2 so far and it works well. I'll test your patches for 1 and 3 later today. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Lw9oACgkQGcb56gMuC621nwCeM+6rJo8BQhKrbUNzDCJkhVsu 1sQAoJVf/8XNBsro2tyhHxj1giNrVZ6e =w3sG -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu <yinghai@kernel.org> wrote: > On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> wrote: >>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but >>> that could fail. >>> so could hack it like a. disable bar 0x10 and steal BAR address, >>> then set 0x30 to that address then copy ROM to ram. >>> after that, disable rom again and set back address to 0x10. >>> You try to update radeon_get_bios() to achieve that. > > patches for solution 3: > map_rom.patch will try to borrow mem or mem pref bar for ROM copying > > and You still need to use pci=norom map_rom.patch missed one ! Please check map_rom_v2.patch Thanks Yinghai
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/04/12 18:29, Yinghai Lu wrote: > On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu <yinghai@kernel.org> > wrote: >> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> >> wrote: >>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... >>>> ===> but that could fail. so could hack it like a. disable >>>> bar 0x10 and steal BAR address, then set 0x30 to that address >>>> then copy ROM to ram. after that, disable rom again and set >>>> back address to 0x10. You try to update radeon_get_bios() to >>>> achieve that. >> >> patches for solution 3: map_rom.patch will try to borrow mem or >> mem pref bar for ROM copying >> >> and You still need to use pci=norom > > map_rom.patch missed one ! > > Please check map_rom_v2.patch I've been really busy, and I'm going to be mostly unavailable until Monday. I will get back to it as soon as I can. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Oa3AACgkQGcb56gMuC63HogCfWQTdBSlNcj9zwHy9m4duwmHI A4YAn2bVH1M4BjPxdfzb+AdX7v3wW79Q =mUxP -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/04/12 18:29, Yinghai Lu wrote: > On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu <yinghai@kernel.org> > wrote: >> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu <yinghai@kernel.org> >> wrote: >>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... >>>> ===> but that could fail. so could hack it like a. disable >>>> bar 0x10 and steal BAR address, then set 0x30 to that address >>>> then copy ROM to ram. after that, disable rom again and set >>>> back address to 0x10. You try to update radeon_get_bios() to >>>> achieve that. >> >> patches for solution 3: map_rom.patch will try to borrow mem or >> mem pref bar for ROM copying >> >> and You still need to use pci=norom > > map_rom.patch missed one ! > > Please check map_rom_v2.patch > Hopefully, I'm going to have time to look into this again later today, depending how well other tasks go... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+WdwwACgkQGcb56gMuC62DgQCglk+MxOIxWxbLChNWNlAOdbSp tysAnA83Mfa6tZ6TC97xHIqpFqtPJ5Wc =Vd8+ -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/05/12 18:42, Yinghai Lu wrote: > On Tue, May 15, 2012 at 2:54 AM, Steven Newbury > <steve@snewbury.org.uk> wrote: > >> I'll get re-synced back up, and if they're still relevant give >> the patches a test. Is there an updated branch I should work >> from? > > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > > for-pci-res-alloc > > and attached patch. > > Thanks > > Yinghai Hi Yinghai, I also cherry-picked the pref_bar patch and my local "Intel Flush Page" patch. It boots, and the Intel GMA is allocated >4G, but the radeon doesn't get detected with "for-pci-res-alloc" on hotplug (needs busn-alloc patches), so I can't test it. Booting docked, then undocking/docking does work though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+07pkACgkQGcb56gMuC634nwCfcmr5Ub8mA9HOXjsFdWmttjEb NTAAn0ul6BEKzGz2eoobq2CvpOTzUBzf =kq5H -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/05/12 13:27, Steven Newbury wrote: > On 15/05/12 18:42, Yinghai Lu wrote: >> On Tue, May 15, 2012 at 2:54 AM, Steven Newbury >> <steve@snewbury.org.uk> wrote: > >>> I'll get re-synced back up, and if they're still relevant give >>> the patches a test. Is there an updated branch I should work >>> from? > >> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > >> > > for-pci-res-alloc > >> and attached patch. > >> Thanks > >> Yinghai > > Hi Yinghai, I also cherry-picked the pref_bar patch and my local > "Intel Flush Page" patch. > > It boots, and the Intel GMA is allocated >4G, but the radeon > doesn't get detected with "for-pci-res-alloc" on hotplug (needs > busn-alloc patches), Strange, the busn branch is merged with for-pci-res-alloc, but for some reason it isn't working. Only the bridge is detected, not the devices behind it. so I can't test it. Booting docked, then undocking/docking > does work though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+08DkACgkQGcb56gMuC62miwCgv7nU/Uf3CccBwbqFLHTQL2Zp wygAoLsYma5GaAVHorCRxjS5v6Hw2fQx =bGut -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 17, 2012 at 5:34 AM, Steven Newbury <steve@snewbury.org.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Strange, the busn branch is merged with for-pci-res-alloc, but for > some reason it isn't working. Only the bridge is detected, not the > devices behind it. Can you post the boot log ? maybe recently reordering patches applying sequence break it. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu <yinghai@kernel.org> wrote: > On Thu, May 17, 2012 at 5:34 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Strange, the busn branch is merged with for-pci-res-alloc, but for >> some reason it isn't working. Only the bridge is detected, not the >> devices behind it. > > Can you post the boot log ? maybe recently reordering patches applying > sequence break it. Never mind, found the problem. will check if i could fix it tomorrow. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu <yinghai@kernel.org> wrote: > On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu <yinghai@kernel.org> wrote: >> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Strange, the busn branch is merged with for-pci-res-alloc, but for >>> some reason it isn't working. Only the bridge is detected, not the >>> devices behind it. >> >> Can you post the boot log ? maybe recently reordering patches applying >> sequence break it. > > Never mind, found the problem. updated for-pci-res-alloc branch. please check it. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/05/12 10:08, Yinghai Lu wrote: > On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu <yinghai@kernel.org> > wrote: >> On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu <yinghai@kernel.org> >> wrote: >>> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury >>> <steve@snewbury.org.uk> wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Strange, the busn branch >>>> is merged with for-pci-res-alloc, but for some reason it >>>> isn't working. Only the bridge is detected, not the devices >>>> behind it. >>> >>> Can you post the boot log ? maybe recently reordering patches >>> applying sequence break it. >> >> Never mind, found the problem. > > updated for-pci-res-alloc branch. please check it. > Tested and working fine now. Some random update broke gnome-shell, so couldn't test it straight away. In the end I gave up fixing it and reverted to an earlier system snapshot. btrfs can be very useful! :) There is an outstanding issue with i915 though. With the moved BAR the screen remains blank when i915 loads (should show fbcon) and doesn't light up until X initialises. (X produces a modeset I assume.) After that everything works fine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+6eu4ACgkQGcb56gMuC61InACfa+SvYmWXxJb3x1YTXOJhQWLE 0HkAoKcKhk7elSx1LIaxVdrxiBZibzDa =MaOP -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 21, 2012 at 11:27 AM, Steven Newbury <steve@snewbury.org.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 18/05/12 10:08, Yinghai Lu wrote: >> On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu <yinghai@kernel.org> >> wrote: >>> On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu <yinghai@kernel.org> >>> wrote: >>>> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury >>>> <steve@snewbury.org.uk> wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- Strange, the busn branch >>>>> is merged with for-pci-res-alloc, but for some reason it >>>>> isn't working. Only the bridge is detected, not the devices >>>>> behind it. >>>> >>>> Can you post the boot log ? maybe recently reordering patches >>>> applying sequence break it. >>> >>> Never mind, found the problem. >> >> updated for-pci-res-alloc branch. please check it. >> > Tested and working fine now. Can you attach dmesg logs without Yinghai's patches (where I assume it doesn't work) and with them (where it *does* work) to the bugzilla? I assume https://bugzilla.kernel.org/show_bug.cgi?id=10461 is still the relevant report. I'm confused because I thought your _CRS showed no apertures above 4GB, and I'm trying to figure out how Yinghai's patches can help if that's the case. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 29, 2012 at 5:19 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: > On Mon, May 21, 2012 at 11:27 AM, Steven Newbury <steve@snewbury.org.uk> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 18/05/12 10:08, Yinghai Lu wrote: >>> On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu <yinghai@kernel.org> >>> wrote: >>>> On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu <yinghai@kernel.org> >>>> wrote: >>>>> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury >>>>> <steve@snewbury.org.uk> wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Strange, the busn branch >>>>>> is merged with for-pci-res-alloc, but for some reason it >>>>>> isn't working. Only the bridge is detected, not the devices >>>>>> behind it. >>>>> >>>>> Can you post the boot log ? maybe recently reordering patches >>>>> applying sequence break it. >>>> >>>> Never mind, found the problem. >>> >>> updated for-pci-res-alloc branch. please check it. >>> >> Tested and working fine now. > > Can you attach dmesg logs without Yinghai's patches (where I assume it > doesn't work) and with them (where it *does* work) to the bugzilla? I > assume https://bugzilla.kernel.org/show_bug.cgi?id=10461 is still the > relevant report. > > I'm confused because I thought your _CRS showed no apertures above > 4GB, and I'm trying to figure out how Yinghai's patches can help if > that's the case. Your _CRS *doesn't* show any apertures above 4GB, but you're booting with "pci=nocrs", so we ignore them anyway. Doing hotplug with "pci=nocrs" is not a supportable proposition. Patches that help in the "pci=nocrs" case might be acceptable, but only if there is clearly no risk to the "pci=use_crs" case. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
commit fe2ccc15c3cd75af2a582dc6e2b4deb544aca307
Author: Steven Newbury <steve@snewbury.org.uk>
Date: Sat Apr 14 19:37:32 2012 +0100
PCI: Export pci_bus_alloc_resource_fit()
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 6d2b073..acb51bd 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -391,6 +391,7 @@ void pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *),
EXPORT_SYMBOL_GPL(pci_walk_bus);
EXPORT_SYMBOL(pci_bus_alloc_resource);
+EXPORT_SYMBOL(pci_bus_alloc_resource_fit);
EXPORT_SYMBOL_GPL(pci_bus_add_device);
EXPORT_SYMBOL(pci_bus_add_devices);
EXPORT_SYMBOL(pci_enable_bridges);