fixup for pci config_access on alchemy au1x000
PATCH 1/1 fixup for pci config_access on alchemy au1x000
Hi all,
I've encountered a serious problem with PCI config space access on Au1x000 platforms with recent 2.6.x-kernel. With 2.4.31 the same hardware works fine. So I was looking for the differences:
Symptoms:
- no PCI-device is seen on bootup though two or three cards are present
- lspci output is empty
- OR: lspci shows 20 times the same device
(- OR: in some slot-configurations it worked anyhow)
System(s):
1. platform with Au1500 and three PCI-devices (actually a mycable XXS1500 with backplane for three PCI-devices)
2. platform with Au1550 and two PCI-devices (custom board)
Debugging:
I digged down to the config_access() of the au1xxx-processors in arch/mips/pci/ops-au1000.c and switched on DEBUG.
The code of config_access() seems to be almost the same as of the 2.4.x-kernel. But the "pci_cfg_vm->addr" returned by get_vm_area(0x2000, 0) once on booting is different. That's of course not forbidden. But the alignment seems to be wrong. In my case, I received:
2.4.31: pci_cfg_vm->addr = c0000000
2.6.18-rc5: pci_cfg_vm->addr = c0101000
To make it short: With 2.6.x it fails on the first config-access with:
"PCI ERR detected: status 83a00356".
Fixup:
My fix is now, to use the VM_IOREMAP-flag in the get_vm_area call. This flag seems to be introduced in mm/vmalloc.c a long time ago (in 2.6.7-bk13, I found in gitweb).
Now, the returned address is pci_cfg_vm->addr = c0104000 and everything works fine.
What do you think about my fixup-patch?
Nobody's using the get_vm_area()-call without any flag ("0"). Was it only forgotten in the arch/mips/pci/ops-au1000.c?
Or am I completely wrong?
Thanks a lot for your comments!
Best regard,
Alexander
--- linux-2.6.18-rc5/arch/mips/pci/ops-au1000.c 2006-08-28 12:09:15.000000000
+0200
+++ linux-2.6.18-rc5-dev/arch/mips/pci/ops-au1000.c 2006-08-29
13:08:59.000000000 +0200
@@ -110,7 +110,7 @@
if (first_cfg) {
/* reserve a wired entry for pci config accesses */ first_cfg = 0;
- pci_cfg_vm = get_vm_area(0x2000, 0);
+ pci_cfg_vm = get_vm_area(0x2000, VM_IOREMAP);
if (!pci_cfg_vm)
panic (KERN_ERR "PCI unable to get vm area\n");
pci_cfg_wired_entry = read_c0_wired();
Signature · 4 lines
Alexander Bigga Tel: +49 4873 90 10 866 mycable GmbH Fax: +49 4873 901 976 Boeker Stieg 43 D-24613 Aukrug eMail: [email protected]
Quoted 7 lines · Alexander Bigga
What do you think about my fixup-patch?
Nobody's using the get_vm_area()-call without any flag ("0"). Was it only forgotten in thearch/mips/pci/ops-au1000.c?Or am I completely wrong?
Thanks a lot for your comments!
The patch looks ok, so just the usual technicalities:
- Please include a Signed-off-by: line.
- Don't use a bloody crapmailer that garbles patches into some sort of ASCII spinach.
Ralf
Thanks for applying.
Quoted 3 lines · Ralf Baechle
The patch looks ok, so just the usual technicalities:
- Please include a Signed-off-by: line.
Ok. Will do this in future.
Quoted 2 lines
- Don't use a bloody crapmailer that garbles patches into some sort of ASCII spinach.
I'm really sorry. I don't like spinach too ;-) For future mailings and patches, I will take mutt again.
Alexander
Signature · 4 lines
Alexander Bigga Tel: +49 4873 90 10 866 mycable GmbH Fax: +49 4873 901 976 Boeker Stieg 43 D-24613 Aukrug eMail: [email protected]
Hello.
Quoted 23 lines · Alexander Bigga
I've encountered a serious problem with PCI config space access on Au1x000 platforms with recent 2.6.x-kernel. With 2.4.31 the same hardware works fine. So I was looking for the differences:
Symptoms:
- no PCI-device is seen on bootup though two or three cards are present
- lspci output is empty
- OR: lspci shows 20 times the same device
(- OR: in some slot-configurations it worked anyhow)System(s): 1. platform with Au1500 and three PCI-devices (actually a mycable XXS1500
with backplane for three PCI-devices)
2. platform with Au1550 and two PCI-devices (custom board)Debugging:
I digged down to theconfig_access()of the au1xxx-processors inarch/mips/pci/ops-au1000.cand switched on DEBUG.The code of
config_access()seems to be almost the same as of the 2.4.x-kernel. But the "pci_cfg_vm->addr" returned byget_vm_area(0x2000, 0)once on booting is different. That's of course not forbidden. But the alignment seems to be wrong. In my case, I received:2.4.31:
pci_cfg_vm->addr=c0000000
2.6.18-rc5:pci_cfg_vm->addr=c0101000To make it short: With 2.6.x it fails on the first config-access with:
"PCI ERR detected: status83a00356".
Quoted 6 lines
Fixup:
My fix is now, to use the VM_IOREMAP-flag in theget_vm_areacall. This flag seems to be introduced inmm/vmalloc.ca long time ago (in 2.6.7-bk13, I found in gitweb). Now, the returned address ispci_cfg_vm->addr=c0104000and everything works fine.What do you think about my fixup-patch? Nobody's using the get_vm_area()-call without any flag ("0"). Was it only forgotten in the
arch/mips/pci/ops-au1000.c?Or am I completely wrong?
You're correct -- this code was only working by some chance. Once you get
a virtual address not aligned to 8K, it breaks completely since the pages can't constitute a valid pair for wired entry anymore.
Actually, in 2.4 the situation seems to be even worse as get_vm_area()
there has no provision for the address alignment at all!
Quoted 3 lines
Best regard,
Alexander
WBR, Sergei