* 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, 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
* 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
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
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
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
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
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
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
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
> 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
* 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
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
[-- 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
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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.