pci->pcie bridge issue: kernel unable to find a free I/O port range.

linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* pci->pcie bridge issue: kernel unable to find a free I/O port range.
@ 2014-01-07  9:11 `VL
  2014-01-07 18:27 ` Bjorn Helgaas
  0 siblings, 1 reply; 14+ messages in thread
From: `VL @ 2014-01-07  9:11 UTC (permalink / raw)
  To: linux-pci

Hello,

I'm having an issue with my M-Audio Delta 44 soundcard installed into
the PCI->PCIe adapter. When installed into PCI slot on my old computer,
it works perfectly, but the new one lacks PCI slots, so I installed it 
using
the adapter (http://www.espada-tech.ru/pr_-12351.shtml)

lspci shows the audio card:

07:00.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 
[Envy24] PCI Multi-Channel I/O Controller (rev 02)

but the driver won't load:

snd_ice1712 0000:07:00.0: Refused to change power state, currently in D3
ice1712: No matching model found for ID 0x6c6c6c6c
invalid EEPROM (size = 108)
snd_ice1712: probe of 0000:07:00.0 failed with error -5

Unknown ID and EEPROM size may differ from boot to boot.

Looking into message I see this:

[    0.384542] pci 0000:05:01.0: BAR 7: can't assign io (size 0x1000)
[    0.384714] pci 0000:06:00.0: BAR 7: can't assign io (size 0x1000)
[    0.384885] pci 0000:07:00.0: BAR 3: can't assign io (size 0x40)
[    0.385056] pci 0000:07:00.0: BAR 0: can't assign io (size 0x20)
[    0.385227] pci 0000:07:00.0: BAR 1: can't assign io (size 0x10)
[    0.385411] pci 0000:07:00.0: BAR 2: can't assign io (size 0x10)

The bridge is based on PLX PEX 8112(?) chip and lspci shows:

04:00.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI 
Express Gen 2 (5.0 GT/s) Switch (rev ba)
05:01.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI 
Express Gen 2 (5.0 GT/s) Switch (rev ba)
05:04.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI 
Express Gen 2 (5.0 GT/s) Switch (rev ba)
05:05.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI 
Express Gen 2 (5.0 GT/s) Switch (rev ba)
05:06.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI 
Express Gen 2 (5.0 GT/s) Switch (rev ba)
05:07.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI 
Express Gen 2 (5.0 GT/s) Switch (rev ba)
05:08.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI 
Express Gen 2 (5.0 GT/s) Switch (rev ba)
05:09.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI 
Express Gen 2 (5.0 GT/s) Switch (rev ba)
06:00.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI 
Bridge (rev 21)

my kernel is 3.11.10:

lspci -vvv: http://dpaste.com/1539094/
dmesg: http://dpaste.com/1539095/

I've tried to boot with pci=realloc, but the system hangs in this case 
(looks like during initialization
of sound card driver, but I'm not sure, since it hangs completely: no 
kernel panic, system just stopped
in the middle of usual boot message)

Feel free to ask for more information.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
  2014-01-07  9:11 pci->pcie bridge issue: kernel unable to find a free I/O port range `VL
@ 2014-01-07 18:27 ` Bjorn Helgaas
       [not found]   ` <52CD2387.2030403@gmail.com>
  0 siblings, 1 reply; 14+ messages in thread
From: Bjorn Helgaas @ 2014-01-07 18:27 UTC (permalink / raw)
  To: `VL; +Cc: linux-pci@vger.kernel.org, Yinghai Lu

[+cc Yinghai]

On Tue, Jan 7, 2014 at 2:11 AM, `VL <vl.homutov@gmail.com> wrote:
> Hello,
>
> I'm having an issue with my M-Audio Delta 44 soundcard installed into
> the PCI->PCIe adapter. When installed into PCI slot on my old computer,
> it works perfectly, but the new one lacks PCI slots, so I installed it using
> the adapter (http://www.espada-tech.ru/pr_-12351.shtml)
>
> lspci shows the audio card:
>
> 07:00.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24]
> PCI Multi-Channel I/O Controller (rev 02)
>
> but the driver won't load:
>
> snd_ice1712 0000:07:00.0: Refused to change power state, currently in D3
> ice1712: No matching model found for ID 0x6c6c6c6c
> invalid EEPROM (size = 108)
> snd_ice1712: probe of 0000:07:00.0 failed with error -5
>
> Unknown ID and EEPROM size may differ from boot to boot.
>
> Looking into message I see this:
>
> [    0.384542] pci 0000:05:01.0: BAR 7: can't assign io (size 0x1000)
> [    0.384714] pci 0000:06:00.0: BAR 7: can't assign io (size 0x1000)
> [    0.384885] pci 0000:07:00.0: BAR 3: can't assign io (size 0x40)
> [    0.385056] pci 0000:07:00.0: BAR 0: can't assign io (size 0x20)
> [    0.385227] pci 0000:07:00.0: BAR 1: can't assign io (size 0x10)
> [    0.385411] pci 0000:07:00.0: BAR 2: can't assign io (size 0x10)

Yep, this is the problem.  We ran out of I/O space.  We had 8K leading
to the switch, but 4K go to the Realtek NIC, and 4K go to SATA:

pci 0000:00:1c.3:   bridge window [io  0xb000-0xcfff]  to [bus 04-0d]
pci 0000:05:05.0:   bridge window [io  0xc000-0xcfff]  to [bus 09]
pci 0000:09:00.0: reg 0x10: [io  0xc000-0xc0ff]  Realtek NIC
pci 0000:05:09.0:   bridge window [io  0xb000-0xbfff]  to [bus 0d]
pci 0000:0d:00.0: reg 0x10: [io  0xb050-0xb057]  SATA

It seems like there *is* I/O space available in the system, so I'm not
sure why BIOS didn't assign enough here.  But it's still a bug that
Linux couldn't fix it.

> The bridge is based on PLX PEX 8112(?) chip and lspci shows:
>
> 04:00.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express
> Gen 2 (5.0 GT/s) Switch (rev ba)
> 05:01.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express
> Gen 2 (5.0 GT/s) Switch (rev ba)
> 05:04.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express
> Gen 2 (5.0 GT/s) Switch (rev ba)
> 05:05.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express
> Gen 2 (5.0 GT/s) Switch (rev ba)
> 05:06.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express
> Gen 2 (5.0 GT/s) Switch (rev ba)
> 05:07.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express
> Gen 2 (5.0 GT/s) Switch (rev ba)
> 05:08.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express
> Gen 2 (5.0 GT/s) Switch (rev ba)
> 05:09.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express
> Gen 2 (5.0 GT/s) Switch (rev ba)
> 06:00.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge
> (rev 21)
>
> my kernel is 3.11.10:
>
> lspci -vvv: http://dpaste.com/1539094/
> dmesg: http://dpaste.com/1539095/
>
> I've tried to boot with pci=realloc, but the system hangs in this case
> (looks like during initialization
> of sound card driver, but I'm not sure, since it hangs completely: no kernel
> panic, system just stopped
> in the middle of usual boot message)

Is there any way you can capture the output with a serial console or a
video camera?

Bjorn

^ permalink raw reply	[flat|nested] 14+ messages in thread

[parent not found: <52CD2387.2030403@gmail.com>]

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
       [not found]   ` <52CD2387.2030403@gmail.com>
@ 2014-01-08 20:28     ` Yinghai Lu
  2014-01-09  5:14       ` `VL
  0 siblings, 1 reply; 14+ messages in thread
From: Yinghai Lu @ 2014-01-08 20:28 UTC (permalink / raw)
  To: `VL; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org

On Wed, Jan 8, 2014 at 2:08 AM, `VL <vl.homutov@gmail.com> wrote:
>
> I've enabled netconsole and got some output.
> Here it is: http://dpaste.com/1542030/

It does include any realloc message.

> Note that since the hang occurs on the module load, netconsole was unable
> to send latest messages and the log looks clear
>
> I've rebuilt kernel with sound driver compiled in, and the hang occured
> during
> kernel load, userspace was not reached (but in this case, netconsole was
> useless at
> all) and I've made a photo of screen (attached). Note there is ACPI warning
> about
> system IO conflict.

Can you enable

CONFIG_PCI_DEBUG=y

and boot with "debug ignore_loglevel initcall_debug"?

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
  2014-01-08 20:28     ` Yinghai Lu
@ 2014-01-09  5:14       ` `VL
  2014-01-09 20:17         ` Yinghai Lu
  0 siblings, 1 reply; 14+ messages in thread
From: `VL @ 2014-01-09  5:14 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org

I've put all logs here: http://inspert.ru/pci/

On 09.01.2014 00:28, Yinghai Lu wrote:
> On Wed, Jan 8, 2014 at 2:08 AM, `VL <vl.homutov@gmail.com> wrote:
>> I've enabled netconsole and got some output.
>> Here it is: http://dpaste.com/1542030/
> It does include any realloc message.
not sure I understood you.
The message I was talking about is:

Jan  8 12:51:52 10 Some PCI device resources are unassigned, try booting 
with pci=realloc

and you can see it in this log: 
http://inspert.ru/pci/netconsole-norealloc.txt

The kernel hangs if I add this option.
>
>> Note that since the hang occurs on the module load, netconsole was 
>> unable
>> to send latest messages and the log looks clear
>>
>> I've rebuilt kernel with sound driver compiled in, and the hang occured
>> during
>> kernel load, userspace was not reached (but in this case, netconsole was
>> useless at
>> all) and I've made a photo of screen (attached). Note there is ACPI 
>> warning
>> about
>> system IO conflict.
> Can you enable
>
> CONFIG_PCI_DEBUG=y
>
> and boot with "debug ignore_loglevel initcall_debug"?

Here it is: http://inspert.ru/pci/netconsole-pcidebug.txt

(problem is when snd_ice17 is loaded; this is for the card installed 
into adapter)
>
> Thanks
>
> Yinghai


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
  2014-01-09  5:14       ` `VL
@ 2014-01-09 20:17         ` Yinghai Lu
  2014-01-10  4:41           ` `VL
  0 siblings, 1 reply; 14+ messages in thread
From: Yinghai Lu @ 2014-01-09 20:17 UTC (permalink / raw)
  To: `VL; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org

On Wed, Jan 8, 2014 at 9:14 PM, `VL <vl.homutov@gmail.com> wrote:
> I've put all logs here: http://inspert.ru/pci/
>>
>> CONFIG_PCI_DEBUG=y
>>
>> and boot with "debug ignore_loglevel initcall_debug"?
>

Jan  9 08:51:49 10 pci 0000:04:00.0: BAR 7: assigned [io  0x2000-0x4fff]
Jan  9 08:51:49 10 pci 0000:05:01.0: BAR 7: assigned [io  0x2000-0x2fff]
Jan  9 08:51:49 10 pci 0000:06:00.0: BAR 7: assigned [io  0x2000-0x2fff]
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: assigned [io  0x2000-0x203f]
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: error updating (0x002001
!= 0xffffffff)
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: set to [io  0x2000-0x203f]
(PCI address [0x2000-0x203f])
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: assigned [io  0x2040-0x205f]
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: error updating (0x002041
!= 0xffffffff)
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: set to [io  0x2040-0x205f]
(PCI address [0x2040-0x205f])
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: assigned [io  0x2060-0x206f]
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: error updating (0x002061
!= 0xffffffff)
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: set to [io  0x2060-0x206f]
(PCI address [0x2060-0x206f])
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: assigned [io  0x2070-0x207f]
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: error updating (0x002071
!= 0xffffffff)
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: set to [io  0x2070-0x207f]
(PCI address [0x2070-0x207f])
Jan  9 08:51:49 10 pci 0000:06:00.0: PCI bridge to [bus 07]
Jan  9 08:51:49 10 pci 0000:06:00.0:   bridge window [io  0x2000-0x2fff]
Jan  9 08:51:49 10 pci 0000:05:01.0: PCI bridge to [bus 06-07]
Jan  9 08:51:49 10 pci 0000:05:01.0:   bridge window [io  0x2000-0x2fff]
Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 0: set to [io  0x4020-0x4027]
(PCI address [0x4020-0x4027])
Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 2: assigned [io  0x4028-0x402f]
Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 3: assigned [io  0x4034-0x4037]
Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 3: set to [io  0x4034-0x4037]
(PCI address [0x4034-0x4037])
Jan  9 08:51:49 10 pci 0000:05:09.0: PCI bridge to [bus 0d]
Jan  9 08:51:49 10 pci 0000:05:09.0:   bridge window [io  0x4000-0x4fff]
Jan  9 08:51:49 10 pci 0000:05:09.0:   bridge window [mem 0xf7600000-0xf76fffff]
Jan  9 08:51:49 10 pci 0000:04:00.0: PCI bridge to [bus 05-0d]
Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [io  0x2000-0x4fff]
Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [mem 0xf7200000-0xf77fffff]
Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [mem
0xf0000000-0xf00fffff 64bit pref]
Jan  9 08:51:49 10 pci 0000:00:1c.3: PCI bridge to [bus 04-0d]
Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [io  0x2000-0x4fff]
Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [mem 0xf7200000-0xf78fffff]
Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [mem
0xf0000000-0xf00fffff 64bit pref]

The realloc code does reassign big range to the devices.

but one device refuse to change bar to new assigned vaule, or it is read-only?

Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: assigned [io  0x2000-0x203f]
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: error updating (0x002001
!= 0xffffffff)
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: set to [io  0x2000-0x203f]
(PCI address [0x2000-0x203f])
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: assigned [io  0x2040-0x205f]
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: error updating (0x002041
!= 0xffffffff)
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: set to [io  0x2040-0x205f]
(PCI address [0x2040-0x205f])
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: assigned [io  0x2060-0x206f]
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: error updating (0x002061
!= 0xffffffff)
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: set to [io  0x2060-0x206f]
(PCI address [0x2060-0x206f])
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: assigned [io  0x2070-0x207f]
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: error updating (0x002071
!= 0xffffffff)
Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: set to [io  0x2070-0x207f]
(PCI address [0x2070-0x207f])


also BIOS does not assign any vaule to it:

Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x10: [io  0x0000-0x001f]
Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x18: [io  0x0000-0x000f]
Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x1c: [io  0x0000-0x003f]

It is strange 05:01.0/07:00.0 does not work, but 05:09.0/0d:00.0 does work.

Can you boot with "pci=earlydump"?

Yinghai

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
  2014-01-09 20:17         ` Yinghai Lu
@ 2014-01-10  4:41           ` `VL
  2014-01-10  5:19             ` Yinghai Lu
  0 siblings, 1 reply; 14+ messages in thread
From: `VL @ 2014-01-10  4:41 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org

On 10.01.2014 00:17, Yinghai Lu wrote:
> On Wed, Jan 8, 2014 at 9:14 PM, `VL <vl.homutov@gmail.com> wrote:
>> I've put all logs here: http://inspert.ru/pci/
>>> CONFIG_PCI_DEBUG=y
>>>
>>> and boot with "debug ignore_loglevel initcall_debug"?
> Jan  9 08:51:49 10 pci 0000:04:00.0: BAR 7: assigned [io  0x2000-0x4fff]
> Jan  9 08:51:49 10 pci 0000:05:01.0: BAR 7: assigned [io  0x2000-0x2fff]
> Jan  9 08:51:49 10 pci 0000:06:00.0: BAR 7: assigned [io  0x2000-0x2fff]
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: assigned [io  0x2000-0x203f]
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: error updating (0x002001
> != 0xffffffff)
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: set to [io  0x2000-0x203f]
> (PCI address [0x2000-0x203f])
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: assigned [io  0x2040-0x205f]
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: error updating (0x002041
> != 0xffffffff)
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: set to [io  0x2040-0x205f]
> (PCI address [0x2040-0x205f])
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: assigned [io  0x2060-0x206f]
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: error updating (0x002061
> != 0xffffffff)
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: set to [io  0x2060-0x206f]
> (PCI address [0x2060-0x206f])
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: assigned [io  0x2070-0x207f]
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: error updating (0x002071
> != 0xffffffff)
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: set to [io  0x2070-0x207f]
> (PCI address [0x2070-0x207f])
> Jan  9 08:51:49 10 pci 0000:06:00.0: PCI bridge to [bus 07]
> Jan  9 08:51:49 10 pci 0000:06:00.0:   bridge window [io  0x2000-0x2fff]
> Jan  9 08:51:49 10 pci 0000:05:01.0: PCI bridge to [bus 06-07]
> Jan  9 08:51:49 10 pci 0000:05:01.0:   bridge window [io  0x2000-0x2fff]
> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 0: set to [io  0x4020-0x4027]
> (PCI address [0x4020-0x4027])
> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 2: assigned [io  0x4028-0x402f]
> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 3: assigned [io  0x4034-0x4037]
> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 3: set to [io  0x4034-0x4037]
> (PCI address [0x4034-0x4037])
> Jan  9 08:51:49 10 pci 0000:05:09.0: PCI bridge to [bus 0d]
> Jan  9 08:51:49 10 pci 0000:05:09.0:   bridge window [io  0x4000-0x4fff]
> Jan  9 08:51:49 10 pci 0000:05:09.0:   bridge window [mem 0xf7600000-0xf76fffff]
> Jan  9 08:51:49 10 pci 0000:04:00.0: PCI bridge to [bus 05-0d]
> Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [io  0x2000-0x4fff]
> Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [mem 0xf7200000-0xf77fffff]
> Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [mem
> 0xf0000000-0xf00fffff 64bit pref]
> Jan  9 08:51:49 10 pci 0000:00:1c.3: PCI bridge to [bus 04-0d]
> Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [io  0x2000-0x4fff]
> Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [mem 0xf7200000-0xf78fffff]
> Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [mem
> 0xf0000000-0xf00fffff 64bit pref]
>
> The realloc code does reassign big range to the devices.
>
> but one device refuse to change bar to new assigned vaule, or it is read-only?
>
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: assigned [io  0x2000-0x203f]
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: error updating (0x002001
> != 0xffffffff)
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: set to [io  0x2000-0x203f]
> (PCI address [0x2000-0x203f])
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: assigned [io  0x2040-0x205f]
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: error updating (0x002041
> != 0xffffffff)
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: set to [io  0x2040-0x205f]
> (PCI address [0x2040-0x205f])
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: assigned [io  0x2060-0x206f]
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: error updating (0x002061
> != 0xffffffff)
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: set to [io  0x2060-0x206f]
> (PCI address [0x2060-0x206f])
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: assigned [io  0x2070-0x207f]
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: error updating (0x002071
> != 0xffffffff)
> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: set to [io  0x2070-0x207f]
> (PCI address [0x2070-0x207f])
>
>
> also BIOS does not assign any vaule to it:
>
> Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x10: [io  0x0000-0x001f]
> Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x18: [io  0x0000-0x000f]
> Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x1c: [io  0x0000-0x003f]
>
> It is strange 05:01.0/07:00.0 does not work, but 05:09.0/0d:00.0 does work.
>
> Can you boot with "pci=earlydump"?
>
> Yinghai
Here it is: http://inspert.ru/pci/netconsole-realloc-earlydump.txt

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
  2014-01-10  4:41           ` `VL
@ 2014-01-10  5:19             ` Yinghai Lu
  2014-01-11  8:38               ` `VL
  0 siblings, 1 reply; 14+ messages in thread
From: Yinghai Lu @ 2014-01-10  5:19 UTC (permalink / raw)
  To: `VL; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org

On Thu, Jan 9, 2014 at 8:41 PM, `VL <vl.homutov@gmail.com> wrote:
> On 10.01.2014 00:17, Yinghai Lu wrote:
>>
>> On Wed, Jan 8, 2014 at 9:14 PM, `VL <vl.homutov@gmail.com> wrote:
>>>
>>> I've put all logs here: http://inspert.ru/pci/
>>>>
>>>> CONFIG_PCI_DEBUG=y
>>>>
>>>> and boot with "debug ignore_loglevel initcall_debug"?
>>
>> Jan  9 08:51:49 10 pci 0000:04:00.0: BAR 7: assigned [io  0x2000-0x4fff]
>> Jan  9 08:51:49 10 pci 0000:05:01.0: BAR 7: assigned [io  0x2000-0x2fff]
>> Jan  9 08:51:49 10 pci 0000:06:00.0: BAR 7: assigned [io  0x2000-0x2fff]
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: assigned [io  0x2000-0x203f]
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: error updating (0x002001
>> != 0xffffffff)
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: set to [io  0x2000-0x203f]
>> (PCI address [0x2000-0x203f])
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: assigned [io  0x2040-0x205f]
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: error updating (0x002041
>> != 0xffffffff)
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: set to [io  0x2040-0x205f]
>> (PCI address [0x2040-0x205f])
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: assigned [io  0x2060-0x206f]
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: error updating (0x002061
>> != 0xffffffff)
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: set to [io  0x2060-0x206f]
>> (PCI address [0x2060-0x206f])
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: assigned [io  0x2070-0x207f]
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: error updating (0x002071
>> != 0xffffffff)
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: set to [io  0x2070-0x207f]
>> (PCI address [0x2070-0x207f])
>> Jan  9 08:51:49 10 pci 0000:06:00.0: PCI bridge to [bus 07]
>> Jan  9 08:51:49 10 pci 0000:06:00.0:   bridge window [io  0x2000-0x2fff]
>> Jan  9 08:51:49 10 pci 0000:05:01.0: PCI bridge to [bus 06-07]
>> Jan  9 08:51:49 10 pci 0000:05:01.0:   bridge window [io  0x2000-0x2fff]
>> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 0: set to [io  0x4020-0x4027]
>> (PCI address [0x4020-0x4027])
>> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 2: assigned [io  0x4028-0x402f]
>> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 3: assigned [io  0x4034-0x4037]
>> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 3: set to [io  0x4034-0x4037]
>> (PCI address [0x4034-0x4037])
>> Jan  9 08:51:49 10 pci 0000:05:09.0: PCI bridge to [bus 0d]
>> Jan  9 08:51:49 10 pci 0000:05:09.0:   bridge window [io  0x4000-0x4fff]
>> Jan  9 08:51:49 10 pci 0000:05:09.0:   bridge window [mem
>> 0xf7600000-0xf76fffff]
>> Jan  9 08:51:49 10 pci 0000:04:00.0: PCI bridge to [bus 05-0d]
>> Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [io  0x2000-0x4fff]
>> Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [mem
>> 0xf7200000-0xf77fffff]
>> Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [mem
>> 0xf0000000-0xf00fffff 64bit pref]
>> Jan  9 08:51:49 10 pci 0000:00:1c.3: PCI bridge to [bus 04-0d]
>> Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [io  0x2000-0x4fff]
>> Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [mem
>> 0xf7200000-0xf78fffff]
>> Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [mem
>> 0xf0000000-0xf00fffff 64bit pref]
>>
>> The realloc code does reassign big range to the devices.
>>
>> but one device refuse to change bar to new assigned vaule, or it is
>> read-only?
>>
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: assigned [io  0x2000-0x203f]
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: error updating (0x002001
>> != 0xffffffff)
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: set to [io  0x2000-0x203f]
>> (PCI address [0x2000-0x203f])
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: assigned [io  0x2040-0x205f]
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: error updating (0x002041
>> != 0xffffffff)
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: set to [io  0x2040-0x205f]
>> (PCI address [0x2040-0x205f])
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: assigned [io  0x2060-0x206f]
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: error updating (0x002061
>> != 0xffffffff)
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: set to [io  0x2060-0x206f]
>> (PCI address [0x2060-0x206f])
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: assigned [io  0x2070-0x207f]
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: error updating (0x002071
>> != 0xffffffff)
>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: set to [io  0x2070-0x207f]
>> (PCI address [0x2070-0x207f])
>>
>>
>> also BIOS does not assign any vaule to it:
>>
>> Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x10: [io  0x0000-0x001f]
>> Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x18: [io  0x0000-0x000f]
>> Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x1c: [io  0x0000-0x003f]
>>
>> It is strange 05:01.0/07:00.0 does not work, but 05:09.0/0d:00.0 does
>> work.
>>
>> Can you boot with "pci=earlydump"?
>>
>> Yinghai
>
> Here it is: http://inspert.ru/pci/netconsole-realloc-earlydump.txt

there is no 07:00.0 in the print out.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
  2014-01-10  5:19             ` Yinghai Lu
@ 2014-01-11  8:38               ` `VL
  2014-01-14 19:31                 ` Yinghai Lu
  0 siblings, 1 reply; 14+ messages in thread
From: `VL @ 2014-01-11  8:38 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org

On 10.01.2014 09:19, Yinghai Lu wrote:
> On Thu, Jan 9, 2014 at 8:41 PM, `VL <vl.homutov@gmail.com> wrote:
>> On 10.01.2014 00:17, Yinghai Lu wrote:
>>> On Wed, Jan 8, 2014 at 9:14 PM, `VL <vl.homutov@gmail.com> wrote:
>>>> I've put all logs here: http://inspert.ru/pci/
>>>>> CONFIG_PCI_DEBUG=y
>>>>>
>>>>> and boot with "debug ignore_loglevel initcall_debug"?
>>> Jan  9 08:51:49 10 pci 0000:04:00.0: BAR 7: assigned [io  0x2000-0x4fff]
>>> Jan  9 08:51:49 10 pci 0000:05:01.0: BAR 7: assigned [io  0x2000-0x2fff]
>>> Jan  9 08:51:49 10 pci 0000:06:00.0: BAR 7: assigned [io  0x2000-0x2fff]
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: assigned [io  0x2000-0x203f]
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: error updating (0x002001
>>> != 0xffffffff)
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: set to [io  0x2000-0x203f]
>>> (PCI address [0x2000-0x203f])
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: assigned [io  0x2040-0x205f]
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: error updating (0x002041
>>> != 0xffffffff)
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: set to [io  0x2040-0x205f]
>>> (PCI address [0x2040-0x205f])
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: assigned [io  0x2060-0x206f]
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: error updating (0x002061
>>> != 0xffffffff)
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: set to [io  0x2060-0x206f]
>>> (PCI address [0x2060-0x206f])
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: assigned [io  0x2070-0x207f]
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: error updating (0x002071
>>> != 0xffffffff)
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: set to [io  0x2070-0x207f]
>>> (PCI address [0x2070-0x207f])
>>> Jan  9 08:51:49 10 pci 0000:06:00.0: PCI bridge to [bus 07]
>>> Jan  9 08:51:49 10 pci 0000:06:00.0:   bridge window [io  0x2000-0x2fff]
>>> Jan  9 08:51:49 10 pci 0000:05:01.0: PCI bridge to [bus 06-07]
>>> Jan  9 08:51:49 10 pci 0000:05:01.0:   bridge window [io  0x2000-0x2fff]
>>> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 0: set to [io  0x4020-0x4027]
>>> (PCI address [0x4020-0x4027])
>>> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 2: assigned [io  0x4028-0x402f]
>>> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 3: assigned [io  0x4034-0x4037]
>>> Jan  9 08:51:49 10 pci 0000:0d:00.0: BAR 3: set to [io  0x4034-0x4037]
>>> (PCI address [0x4034-0x4037])
>>> Jan  9 08:51:49 10 pci 0000:05:09.0: PCI bridge to [bus 0d]
>>> Jan  9 08:51:49 10 pci 0000:05:09.0:   bridge window [io  0x4000-0x4fff]
>>> Jan  9 08:51:49 10 pci 0000:05:09.0:   bridge window [mem
>>> 0xf7600000-0xf76fffff]
>>> Jan  9 08:51:49 10 pci 0000:04:00.0: PCI bridge to [bus 05-0d]
>>> Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [io  0x2000-0x4fff]
>>> Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [mem
>>> 0xf7200000-0xf77fffff]
>>> Jan  9 08:51:49 10 pci 0000:04:00.0:   bridge window [mem
>>> 0xf0000000-0xf00fffff 64bit pref]
>>> Jan  9 08:51:49 10 pci 0000:00:1c.3: PCI bridge to [bus 04-0d]
>>> Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [io  0x2000-0x4fff]
>>> Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [mem
>>> 0xf7200000-0xf78fffff]
>>> Jan  9 08:51:49 10 pci 0000:00:1c.3:   bridge window [mem
>>> 0xf0000000-0xf00fffff 64bit pref]
>>>
>>> The realloc code does reassign big range to the devices.
>>>
>>> but one device refuse to change bar to new assigned vaule, or it is
>>> read-only?
>>>
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: assigned [io  0x2000-0x203f]
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: error updating (0x002001
>>> != 0xffffffff)
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 3: set to [io  0x2000-0x203f]
>>> (PCI address [0x2000-0x203f])
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: assigned [io  0x2040-0x205f]
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: error updating (0x002041
>>> != 0xffffffff)
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 0: set to [io  0x2040-0x205f]
>>> (PCI address [0x2040-0x205f])
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: assigned [io  0x2060-0x206f]
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: error updating (0x002061
>>> != 0xffffffff)
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 1: set to [io  0x2060-0x206f]
>>> (PCI address [0x2060-0x206f])
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: assigned [io  0x2070-0x207f]
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: error updating (0x002071
>>> != 0xffffffff)
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: BAR 2: set to [io  0x2070-0x207f]
>>> (PCI address [0x2070-0x207f])
>>>
>>>
>>> also BIOS does not assign any vaule to it:
>>>
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x10: [io  0x0000-0x001f]
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x18: [io  0x0000-0x000f]
>>> Jan  9 08:51:49 10 pci 0000:07:00.0: reg 0x1c: [io  0x0000-0x003f]
>>>
>>> It is strange 05:01.0/07:00.0 does not work, but 05:09.0/0d:00.0 does
>>> work.
>>>
>>> Can you boot with "pci=earlydump"?
>>>
>>> Yinghai
>> Here it is: http://inspert.ru/pci/netconsole-realloc-earlydump.txt
> there is no 07:00.0 in the print out.
Well, so it looks like procedure, doing earlydump somehow misses this 
device.
I have collected one more log (without pci=realloc but with debug) so 
I'm pretty sure
that device is there (it appears later in dmesg output) but still not 
shown in earlydump -
it shows 00:06, then 00:09.

http://inspert.ru/pci/dmesg-earlydump.txt

First messages about 00:07 are:

[    0.402838] pci 0000:07:00.0: [1412:1712] type 00 class 0x040100
[    0.403042] pci 0000:07:00.0: reg 0x10: [io  0x0000-0x001f]
[    0.403230] pci 0000:07:00.0: reg 0x14: [io  0x0000-0x000f]
[    0.403418] pci 0000:07:00.0: reg 0x18: [io  0x0000-0x000f]
[    0.403607] pci 0000:07:00.0: reg 0x1c: [io  0x0000-0x003f]
[    0.403888] pci 0000:07:00.0: supports D2,

then:

[    0.457334] pnp 00:05: disabling [io  0x002e-0x002f] because it 
overlaps 0000:07:00.0 BAR 3 [io  0x0000-0x003f]

[    0.459820] system 00:07: [io  0x1854-0x1857] has been reserved
[    0.459991] system 00:07: Plug and Play ACPI device, IDs INT3f0d 
PNP0c02 (active)

[    0.460592] pnp 00:09: disabling [io  0x0010-0x001f] because it 
overlaps 0000:07:00.0 BAR 0 [io  0x0000-0x001f]
[    0.460908] pnp 00:09: disabling [io  0x0010-0x001f disabled] because 
it overlaps 0000:07:00.0 BAR 3 [io  0x0000-0x003f]
[    0.461208] pnp 00:09: disabling [io  0x0022-0x003f] because it 
overlaps 0000:07:00.0 BAR 3 [io  0x0000-0x003f]




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
  2014-01-11  8:38               ` `VL
@ 2014-01-14 19:31                 ` Yinghai Lu
  2014-01-15  9:10                   ` `VL
  0 siblings, 1 reply; 14+ messages in thread
From: Yinghai Lu @ 2014-01-14 19:31 UTC (permalink / raw)
  To: `VL; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org

On Sat, Jan 11, 2014 at 12:38 AM, `VL <vl.homutov@gmail.com> wrote:
>> there is no 07:00.0 in the print out.
>
> Well, so it looks like procedure, doing earlydump somehow misses this
> device.
> I have collected one more log (without pci=realloc but with debug) so I'm
> pretty sure
> that device is there (it appears later in dmesg output) but still not shown
> in earlydump -
> it shows 00:06, then 00:09.

looks like the your adapter need more time to settle down?

Can you check if you can enable slow boot mode in BIOS setup?

>
> http://inspert.ru/pci/dmesg-earlydump.txt

looks like that server is down.

>
> First messages about 00:07 are:
>
> [    0.402838] pci 0000:07:00.0: [1412:1712] type 00 class 0x040100
> [    0.403042] pci 0000:07:00.0: reg 0x10: [io  0x0000-0x001f]
> [    0.403230] pci 0000:07:00.0: reg 0x14: [io  0x0000-0x000f]
> [    0.403418] pci 0000:07:00.0: reg 0x18: [io  0x0000-0x000f]
> [    0.403607] pci 0000:07:00.0: reg 0x1c: [io  0x0000-0x003f]
> [    0.403888] pci 0000:07:00.0: supports D2,
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
  2014-01-14 19:31                 ` Yinghai Lu
@ 2014-01-15  9:10                   ` `VL
       [not found]                     ` <52D6CEC6.2000901@gmail.com>
  0 siblings, 1 reply; 14+ messages in thread
From: `VL @ 2014-01-15  9:10 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org

> looks like the your adapter need more time to settle down?
> Can you check if you can enable slow boot mode in BIOS setup?

yes, probably. I'll try to repeat steps with disabled fast boot.

> looks like that server is down.

should be up now

On Tue, Jan 14, 2014 at 11:31 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Sat, Jan 11, 2014 at 12:38 AM, `VL <vl.homutov@gmail.com> wrote:
>>> there is no 07:00.0 in the print out.
>>
>> Well, so it looks like procedure, doing earlydump somehow misses this
>> device.
>> I have collected one more log (without pci=realloc but with debug) so I'm
>> pretty sure
>> that device is there (it appears later in dmesg output) but still not shown
>> in earlydump -
>> it shows 00:06, then 00:09.
>
> looks like the your adapter need more time to settle down?
>
> Can you check if you can enable slow boot mode in BIOS setup?
>
>>
>> http://inspert.ru/pci/dmesg-earlydump.txt
>
> looks like that server is down.
>
>>
>> First messages about 00:07 are:
>>
>> [    0.402838] pci 0000:07:00.0: [1412:1712] type 00 class 0x040100
>> [    0.403042] pci 0000:07:00.0: reg 0x10: [io  0x0000-0x001f]
>> [    0.403230] pci 0000:07:00.0: reg 0x14: [io  0x0000-0x000f]
>> [    0.403418] pci 0000:07:00.0: reg 0x18: [io  0x0000-0x000f]
>> [    0.403607] pci 0000:07:00.0: reg 0x1c: [io  0x0000-0x003f]
>> [    0.403888] pci 0000:07:00.0: supports D2,
>>

^ permalink raw reply	[flat|nested] 14+ messages in thread

[parent not found: <52D6CEC6.2000901@gmail.com>]

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
       [not found]                     ` <52D6CEC6.2000901@gmail.com>
@ 2014-01-30  5:31                       ` `VL
  2014-01-30 18:56                         ` Yinghai Lu
  0 siblings, 1 reply; 14+ messages in thread
From: `VL @ 2014-01-30  5:31 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org

On 15.01.2014 22:09, `VL wrote:
> On 15.01.2014 13:10, `VL wrote:
>>> looks like the your adapter need more time to settle down?
>>> Can you check if you can enable slow boot mode in BIOS setup?
>> yes, probably. I'll try to repeat steps with disabled fast boot.
> no, this is not the case. I've disabled all fast boot in BIOS and nothing
> changed in logs.
>
> so this is the best of what we have:
> http://inspert.ru/pci/dmesg-earlydump.txt
>
> I was also able to reproduce the issue without pci=realloc. I have 
> disabled
> all builtin devices on motherboard (unused controllers, NICs and audio).
> Looks like in this conditions kernel was able to allocate some resource
> and hang during snd_ice1712 driver load.
>
> Attached is the photo of boot with this situation.
> Unfortunately, since NICs are disabled and there is no serial onboard,
> I cannot provide full log.
>
up: any concluision/suggestions?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
  2014-01-30  5:31                       ` `VL
@ 2014-01-30 18:56                         ` Yinghai Lu
  2014-02-01 10:30                           ` `VL
  0 siblings, 1 reply; 14+ messages in thread
From: Yinghai Lu @ 2014-01-30 18:56 UTC (permalink / raw)
  To: `VL; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org

[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]

On Wed, Jan 29, 2014 at 9:31 PM, `VL <vl.homutov@gmail.com> wrote:
> On 15.01.2014 22:09, `VL wrote:
>>
>> On 15.01.2014 13:10, `VL wrote:
>>>>
>>>> looks like the your adapter need more time to settle down?
>>>> Can you check if you can enable slow boot mode in BIOS setup?
>>>
>>> yes, probably. I'll try to repeat steps with disabled fast boot.
>>
>> no, this is not the case. I've disabled all fast boot in BIOS and nothing
>> changed in logs.
>>
>> so this is the best of what we have:
>> http://inspert.ru/pci/dmesg-earlydump.txt
>>
>> I was also able to reproduce the issue without pci=realloc. I have
>> disabled
>> all builtin devices on motherboard (unused controllers, NICs and audio).
>> Looks like in this conditions kernel was able to allocate some resource
>> and hang during snd_ice1712 driver load.
>>
>> Attached is the photo of boot with this situation.
>> Unfortunately, since NICs are disabled and there is no serial onboard,
>> I cannot provide full log.
>>
> up: any concluision/suggestions?

I don't know why the io bar of 07:00.0 can not be updated.
also it's weird that 07:0.0 is not showing up in earlydump.

anyway please try attached patch to see if it could make any difference.

Thanks

Yinghai

[-- Attachment #2: raw_pci_ext_ops_all.patch --]
[-- Type: text/x-patch, Size: 1347 bytes --]

Suject: [PATCH] x86, pci: use raw_pci_ext_ops for conf1

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/pci/common.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6/arch/x86/pci/common.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/common.c
+++ linux-2.6/arch/x86/pci/common.c
@@ -41,20 +41,20 @@ const struct pci_raw_ops *__read_mostly
 int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
 						int reg, int len, u32 *val)
 {
-	if (domain == 0 && reg < 256 && raw_pci_ops)
-		return raw_pci_ops->read(domain, bus, devfn, reg, len, val);
 	if (raw_pci_ext_ops)
 		return raw_pci_ext_ops->read(domain, bus, devfn, reg, len, val);
+	if (domain == 0 && reg < 256 && raw_pci_ops)
+		return raw_pci_ops->read(domain, bus, devfn, reg, len, val);
 	return -EINVAL;
 }
 
 int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
 						int reg, int len, u32 val)
 {
-	if (domain == 0 && reg < 256 && raw_pci_ops)
-		return raw_pci_ops->write(domain, bus, devfn, reg, len, val);
 	if (raw_pci_ext_ops)
 		return raw_pci_ext_ops->write(domain, bus, devfn, reg, len, val);
+	if (domain == 0 && reg < 256 && raw_pci_ops)
+		return raw_pci_ops->write(domain, bus, devfn, reg, len, val);
 	return -EINVAL;
 }
 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
  2014-01-30 18:56                         ` Yinghai Lu
@ 2014-02-01 10:30                           ` `VL
  2014-10-13 20:48                             ` Bjorn Helgaas
  0 siblings, 1 reply; 14+ messages in thread
From: `VL @ 2014-02-01 10:30 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org

On 30.01.2014 22:56, Yinghai Lu wrote:
> On Wed, Jan 29, 2014 at 9:31 PM, `VL <vl.homutov@gmail.com> wrote:
>> On 15.01.2014 22:09, `VL wrote:
>>> On 15.01.2014 13:10, `VL wrote:
>>>>> looks like the your adapter need more time to settle down?
>>>>> Can you check if you can enable slow boot mode in BIOS setup?
>>>> yes, probably. I'll try to repeat steps with disabled fast boot.
>>> no, this is not the case. I've disabled all fast boot in BIOS and nothing
>>> changed in logs.
>>>
>>> so this is the best of what we have:
>>> http://inspert.ru/pci/dmesg-earlydump.txt
>>>
>>> I was also able to reproduce the issue without pci=realloc. I have
>>> disabled
>>> all builtin devices on motherboard (unused controllers, NICs and audio).
>>> Looks like in this conditions kernel was able to allocate some resource
>>> and hang during snd_ice1712 driver load.
>>>
>>> Attached is the photo of boot with this situation.
>>> Unfortunately, since NICs are disabled and there is no serial onboard,
>>> I cannot provide full log.
>>>
>> up: any concluision/suggestions?
> I don't know why the io bar of 07:00.0 can not be updated.
> also it's weird that 07:0.0 is not showing up in earlydump.
>
> anyway please try attached patch to see if it could make any difference.
>
> Thanks
>
> Yinghai
thank you, I'll try the patch and report results.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: pci->pcie bridge issue: kernel unable to find a free I/O port range.
  2014-02-01 10:30                           ` `VL
@ 2014-10-13 20:48                             ` Bjorn Helgaas
  0 siblings, 0 replies; 14+ messages in thread
From: Bjorn Helgaas @ 2014-10-13 20:48 UTC (permalink / raw)
  To: `VL; +Cc: Yinghai Lu, linux-pci@vger.kernel.org

On Sat, Feb 1, 2014 at 3:30 AM, `VL <vl.homutov@gmail.com> wrote:
> On 30.01.2014 22:56, Yinghai Lu wrote:
>>
>> On Wed, Jan 29, 2014 at 9:31 PM, `VL <vl.homutov@gmail.com> wrote:
>>>
>>> On 15.01.2014 22:09, `VL wrote:
>>>>
>>>> On 15.01.2014 13:10, `VL wrote:
>>>>>>
>>>>>> looks like the your adapter need more time to settle down?
>>>>>> Can you check if you can enable slow boot mode in BIOS setup?
>>>>>
>>>>> yes, probably. I'll try to repeat steps with disabled fast boot.
>>>>
>>>> no, this is not the case. I've disabled all fast boot in BIOS and
>>>> nothing
>>>> changed in logs.
>>>>
>>>> so this is the best of what we have:
>>>> http://inspert.ru/pci/dmesg-earlydump.txt
>>>>
>>>> I was also able to reproduce the issue without pci=realloc. I have
>>>> disabled
>>>> all builtin devices on motherboard (unused controllers, NICs and audio).
>>>> Looks like in this conditions kernel was able to allocate some resource
>>>> and hang during snd_ice1712 driver load.
>>>>
>>>> Attached is the photo of boot with this situation.
>>>> Unfortunately, since NICs are disabled and there is no serial onboard,
>>>> I cannot provide full log.
>>>>
>>> up: any concluision/suggestions?
>>
>> I don't know why the io bar of 07:00.0 can not be updated.
>> also it's weird that 07:0.0 is not showing up in earlydump.
>>
>> anyway please try attached patch to see if it could make any difference.
>>
>> Thanks
>>
>> Yinghai
>
> thank you, I'll try the patch and report results.

Did this ever get resolved?  If not, can you open a report at
bugzilla.kernel.org and attach the info you have?

Bjorn

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2014-10-13 20:48 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-07  9:11 pci->pcie bridge issue: kernel unable to find a free I/O port range `VL
2014-01-07 18:27 ` Bjorn Helgaas
     [not found]   ` <52CD2387.2030403@gmail.com>
2014-01-08 20:28     ` Yinghai Lu
2014-01-09  5:14       ` `VL
2014-01-09 20:17         ` Yinghai Lu
2014-01-10  4:41           ` `VL
2014-01-10  5:19             ` Yinghai Lu
2014-01-11  8:38               ` `VL
2014-01-14 19:31                 ` Yinghai Lu
2014-01-15  9:10                   ` `VL
     [not found]                     ` <52D6CEC6.2000901@gmail.com>
2014-01-30  5:31                       ` `VL
2014-01-30 18:56                         ` Yinghai Lu
2014-02-01 10:30                           ` `VL
2014-10-13 20:48                             ` Bjorn Helgaas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).