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

DISCUSSION `VL 3 participants 14 messages Jan 7, 2014 – Oct 13, 2014 2 messages not in the archive

Subsystems (2)

x86 PCI

lore

Share & tools

lore

`VL

author

2014-01-07 09:11 UTC #0 lore raw

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

maintainer

2014-01-07 18:28 UTC #1 lore raw

[+cc Yinghai]

Quoted 21 lines · `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)
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.

Quoted 8 lines

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.

Quoted 23 lines

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:

Quoted 8 lines

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 UTC #3 lore raw

In reply to a message not in the archive

Quoted 3 lines · `VL

I've enabled netconsole and got some output.
Here it is: http://dpaste.com/1542030/

It does include any realloc message.

Quoted 10 lines

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

author

2014-01-09 05:14 UTC #4 lore raw

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

Quoted 4 lines · Yinghai Lu

Quoted 2 lines · `VL
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.

Quoted 11 lines

Quoted 11 lines
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.

Quoted 5 lines

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)

Quoted 4 lines

Thanks
Yinghai

Yinghai Lu

2014-01-09 20:18 UTC #5 lore raw

Quoted 6 lines · `VL

I've put all logs here: http://inspert.ru/pci/
Quoted 4 lines
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

author

2014-01-10 04:42 UTC #6 lore raw

Quoted 84 lines · Yinghai Lu

Quoted 4 lines · `VL

I've put all logs here: http://inspert.ru/pci/
Quoted 3 lines
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]

Quoted 5 lines

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 UTC #7 lore raw

Quoted 93 lines · `VL

Quoted 92 lines · Yinghai Lu

Quoted 6 lines · `VL

I've put all logs here: http://inspert.ru/pci/
Quoted 4 lines
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]

Quoted 8 lines

Quoted 6 lines
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

author

2014-01-11 08:38 UTC #8 lore raw

Quoted 90 lines · Yinghai Lu

Quoted 89 lines · `VL

Quoted 88 lines · Yinghai Lu

Quoted 4 lines · `VL

I've put all logs here: http://inspert.ru/pci/
Quoted 3 lines
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]

Quoted 8 lines

Quoted 7 lines
Quoted 6 lines
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 UTC #9 lore raw

Quoted 9 lines · `VL

Quoted 1 line
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?

Quoted 2 lines

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

looks like that server is down.

Quoted 10 lines

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,

`VL

author

2014-01-15 09:10 UTC #10 lore raw

Quoted 2 lines

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.

Quoted 1 line

looks like that server is down.

should be up now

Quoted 30 lines · Yinghai Lu

Quoted 9 lines · `VL
Quoted 1 line
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?
Quoted 2 lines
http://inspert.ru/pci/dmesg-earlydump.txt
looks like that server is down.
Quoted 10 lines
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,

`VL

author

2014-01-30 05:31 UTC #12 lore raw

In reply to a message not in the archive

Quoted 10 lines · `VL

Quoted 3 lines · `VL
Quoted 2 lines
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

Quoted 9 lines

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 UTC #13 lore raw

Quoted 21 lines · `VL

Quoted 20 lines · `VL
Quoted 5 lines · `VL
Quoted 3 lines
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.

Quoted 5 lines

Quoted 4 lines
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

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

Signed-off-by Yinghai Lu <[email protected]>

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

arch/x86/pci/common.c +4 -4

Index: 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;
 }

`VL

author

2014-02-01 10:30 UTC #14 lore raw

Quoted 23 lines · Yinghai Lu

Quoted 17 lines · `VL
Quoted 16 lines · `VL
Quoted 3 lines · `VL
Quoted 2 lines
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.
Quoted 5 lines
Quoted 4 lines
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?

Quoted 8 lines

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

maintainer

2014-10-13 20:48 UTC #15 lore raw

Quoted 35 lines · `VL

Quoted 34 lines · Yinghai Lu
Quoted 23 lines · `VL
Quoted 21 lines · `VL
Quoted 5 lines · `VL
Quoted 3 lines
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.
Quoted 5 lines
Quoted 4 lines
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.

Quoted 7 lines

Quoted 5 lines
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