Discussion:
pci->pcie bridge issue: kernel unable to find a free I/O port range.
`VL
2014-01-07 09:11:45 UTC
Permalink
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.
Bjorn Helgaas
2014-01-07 18:27:40 UTC
Permalink
[+cc Yinghai]
Post by `VL
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)
07:00.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24]
PCI Multi-Channel I/O Controller (rev 02)
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.
[ 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.
Post by `VL
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)
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
Yinghai Lu
2014-01-08 20:28:41 UTC
Permalink
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
`VL
2014-01-09 05:14:06 UTC
Permalink
I've put all logs here: http://inspert.ru/pci/
Post by Yinghai Lu
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.
Post by Yinghai Lu
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)
Post by Yinghai Lu
Thanks
Yinghai
Yinghai Lu
2014-01-09 20:17:59 UTC
Permalink
Post by `VL
I've put all logs here: http://inspert.ru/pci/
Post by Yinghai Lu
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
`VL
2014-01-10 04:41:59 UTC
Permalink
Post by Yinghai Lu
Post by `VL
I've put all logs here: http://inspert.ru/pci/
Post by Yinghai Lu
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])
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
Yinghai Lu
2014-01-10 05:19:23 UTC
Permalink
Post by `VL
Post by Yinghai Lu
Post by `VL
I've put all logs here: http://inspert.ru/pci/
Post by Yinghai Lu
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])
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.
`VL
2014-01-11 08:38:07 UTC
Permalink
Post by Yinghai Lu
Post by `VL
Post by Yinghai Lu
Post by `VL
I've put all logs here: http://inspert.ru/pci/
Post by Yinghai Lu
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])
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]
Yinghai Lu
2014-01-14 19:31:03 UTC
Permalink
Post by `VL
Post by Yinghai Lu
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?
Post by `VL
http://inspert.ru/pci/dmesg-earlydump.txt
looks like that server is down.
Post by `VL
[ 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,
`VL
2014-01-15 09:10:46 UTC
Permalink
Post by Yinghai Lu
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.
Post by Yinghai Lu
looks like that server is down.
should be up now
Post by Yinghai Lu
Post by `VL
Post by Yinghai Lu
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?
Post by `VL
http://inspert.ru/pci/dmesg-earlydump.txt
looks like that server is down.
Post by `VL
[ 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,
`VL
2014-01-30 05:31:23 UTC
Permalink
Post by `VL
Post by Yinghai Lu
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.
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?
Yinghai Lu
2014-01-30 18:56:13 UTC
Permalink
Post by `VL
Post by `VL
Post by Yinghai Lu
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.
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
`VL
2014-02-01 10:30:14 UTC
Permalink
Post by Yinghai Lu
Post by `VL
Post by `VL
Post by Yinghai Lu
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.
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.
Bjorn Helgaas
2014-10-13 20:48:12 UTC
Permalink
Post by `VL
Post by Yinghai Lu
Post by `VL
Post by `VL
Post by Yinghai Lu
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.
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

Loading...