Hi,
That looks quite strange. I guess the kernel should map the ROM at the address OpenBoot/OF assigned to it. ( 10020000 ).
Are pci devices located beneatch pci@1f,0 not reserving resources correctly ? (Thus the reuse of addresses when the addresses are assigned during runtime ? or is there some virtual memory magic fooling me ?)
Can you provide a dump of lspci -v ?
Regards, Kjetil Oftedal
On 23/09/2013, mroos@linux.ee mroos@linux.ee wrote:
Resurrecting an old thread...
On Fri, Sep 7, 2012 at 4:18 AM, David Miller davem@davemloft.net wrote:
From: Michel Dänzer michel@daenzer.net Date: Thu, 06 Sep 2012 18:55:51 +0200
On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in Ultra 10 (clean, without my "Video RAM" hack that I talked in other sparclinux posts). When I saw that Sun XVR-100 was detected fine by the kernel, I compiled radeon drm driver with modesetting enabled and tried it:
[drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. PCI: Enabling device: (0000:02:02.0), cmd 82 [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). [drm] register mmio base: 0x10000000 [drm] register mmio size: 32768 [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR
And here the machine hangs. Debugging printk-s reveal that it does not find any active I/O port resources and then continues into initializing the card. Down in igp_read_bios_from_vram() it successfully ioremaps memory region 0 (vram_base=1ff08000000 and size=40000) and tries to read 2 bytes from there and hangs on reading bios[0].
Is the card initialized by OpenFirmware? E.g., does it display anything before the kernel boots?
I think Meelis gave you every single detail you need to know to analyze and fix this bug.
He says it crashes on reading bios[0].
If you look at the function he tells you the crash occurs in, you'll see clearly that bios is an ioremap()'d pointer.
You cannot dereference ioremap()'d pointers, you must use the proper accessors such as readl().
we should just skip the igp reading function on not-x86, since IGP on not x86 makes no sense.
the other option is to readl out the whole bios from vram instead.
I made several changes.
- In igp_read_bios_from_vram():
+#ifndef CONFIG_X86
/* IGP only exists on X86 (32- and 64-bit) */return false;+#endif
This gets me further.
- Since "bios" is __iomem pointer, changed its dereferences to
readb(bios) and readb(bios+1). Maybe relevant, maybe not.
- Next it got stuck in radeon_read_bios() trying to do
kmemdup(bios, size, GFP_KERNEL);
This I changed to mydup for test:
+static void *mydup(uint8_t __iomem *src, size_t len, gfp_t gfp) +{
unsigned char *p;int i;p = kmalloc(len, gfp);if (p) {for (i=0; i<len; i++) {p[i] = readb(src+i);}}return p;+}
And this copying crashes Adaptec scsi driver in different ways.
Investigating this, I found that it makes BAR 6 of the PCI radeon and gets bios=000001ff00000000 assigned. There is also some "Unable to find PCI I/O BAR" before - seesm that firmware does not map this ROM... To make things worse, the 2 first bytes at 000001ff00000000 actually do contain the ROM marker, so it goes on to copying.
[drm] radeon kernel modesetting enabled. PCI: Enabling device: (0000:02:02.0), cmd 82 [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). [drm] register mmio base: 0x000001FF10000000 [drm] register mmio size: 32768 [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR [drm] radeon_read_bios 1 radeon 0000:02:02.0: BAR 6: assigned [mem 0x1ff00000000-0x1ff0001ffff] [drm] radeon_read_bios: found ROM signature at 000001ff00000000 [drm] radeon_read_bios 7: bios=000001ff00000000, size=46592
However, this is where aic7xxx is mapped - /proc/iomem contains this (yes, the machine has ffb graphics and 2 ATI magc64 graphics heads too):
1fc00400000-1fc0040000f : ffb dac 1fc00600000-1fc00600983 : ffb fbc 1ff00000000-1ffffffffff : /pci@1f,0 1ff00002000-1ff00002fff : aic7xxx 1ff000a0000-1ff000bffff : Video RAM area 1ff000c0000-1ff000c7fff : Video ROM 1ff000f0000-1ff000fffff : System ROM 1ff11000000-1ff11ffffff : atyfb 1ffc0000000-1ffdfffffff : IOMMU 1ffe0000000-1ffe000701f : sunhme 1ffe1000000-1ffe1ffffff : atyfb 1fff1000000-1fff1001fff : eeprom 1fff1200000-1fff120000f : cs4231 1fff13062f8-1fff13062ff : su 1fff13083f8-1fff13083ff : su 1fff1400000-1fff140003f : sab 1fff1400040-1fff140007f : sab 1fff1702000-1fff170200f : cs4231_pdma 1fff1704000-1fff170400f : cs4231_cdma 1fff1724000-1fff1724003 : power 1fff1726000-1fff1726003 : auxio
Where do I go from here?
-- Meelis Roos (mroos@linux.ee) -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html