All of lore.kernel.org
 help / color / mirror / Atom feed
* PCI Radeon RV100 detection hang on sparc64
@ 2012-09-06 14:41 ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2012-09-06 14:41 UTC (permalink / raw)
  To: sparclinux, dri-devel

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\x1ff08000000 and size@000) and tries to read 
2 bytes from there and hangs on reading bios[0].

With radeon.modeset=0, it boots and I collected the following info:

02:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA controller])
        Subsystem: Advanced Micro Devices [AMD] nee ATI XVR-100 (supplied by Sun)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0 (2000ns min)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at 08000000 (32-bit, prefetchable) [sizedM]
        Region 1: I/O ports at 0400 [disabled] [size%6]
        Region 2: Memory at 10000000 (32-bit, non-prefetchable) [size2K]
        Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
        Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
        Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
        Expansion ROM at 10020000 [disabled] [size\x128K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

# cat /proc/iomem 
1fc00400000-1fc0040000f : ffb dac
1fc00600000-1fc00600983 : ffb fbc
1ff00000000-1ffffffffff : /pci@1f,0
  1ff00002000-1ff00002fff : aic7xxx
  1ff000a0000-1ff000bffff : Video RAM area
  1ff000f0000-1ff000fffff : System ROM
  1ff11000000-1ff11ffffff : atyfb
  1ff12040000-1ff1204ffff : tg3
  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


-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* PCI Radeon RV100 detection hang on sparc64
@ 2012-09-06 14:41 ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2012-09-06 14:41 UTC (permalink / raw)
  To: sparclinux, dri-devel

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].

With radeon.modeset=0, it boots and I collected the following info:

02:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA controller])
        Subsystem: Advanced Micro Devices [AMD] nee ATI XVR-100 (supplied by Sun)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0 (2000ns min)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at 08000000 (32-bit, prefetchable) [size=64M]
        Region 1: I/O ports at 0400 [disabled] [size=256]
        Region 2: Memory at 10000000 (32-bit, non-prefetchable) [size=32K]
        Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
        Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
        Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
        Expansion ROM at 10020000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

# cat /proc/iomem 
1fc00400000-1fc0040000f : ffb dac
1fc00600000-1fc00600983 : ffb fbc
1ff00000000-1ffffffffff : /pci@1f,0
  1ff00002000-1ff00002fff : aic7xxx
  1ff000a0000-1ff000bffff : Video RAM area
  1ff000f0000-1ff000fffff : System ROM
  1ff11000000-1ff11ffffff : atyfb
  1ff12040000-1ff1204ffff : tg3
  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


-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2012-09-06 14:41 ` Meelis Roos
@ 2012-09-06 16:51   ` Adam Jackson
  -1 siblings, 0 replies; 62+ messages in thread
From: Adam Jackson @ 2012-09-06 16:51 UTC (permalink / raw)
  To: Meelis Roos; +Cc: sparclinux, dri-devel

[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]

On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:

> [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

This particular message looks like it might actually be harmless, all
the code paths that use the I/O BAR can use the MMIO mirror of it
instead.  No idea how well tested that is, but at any rate it's not
what's breaking your setup.

> 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].

This is probably because...

> 02:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA controller])
>         Subsystem: Advanced Micro Devices [AMD] nee ATI XVR-100 (supplied by Sun)
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0 (2000ns min)
>         Interrupt: pin A routed to IRQ 16
>         Region 0: Memory at 08000000 (32-bit, prefetchable) [size=64M]
>         Region 1: I/O ports at 0400 [disabled] [size=256]
>         Region 2: Memory at 10000000 (32-bit, non-prefetchable) [size=32K]
>         Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
>         Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
>         Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
>         Expansion ROM at 10020000 [disabled] [size=128K]

... the ROM BAR looks like it's not routed.

On x86 you could fix this by booting with 'pci=rom' to force the ROM BAR
to be routed regardless of firmware setup, no idea how that's meant to
work on sparc though.

- ajax

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2012-09-06 16:51   ` Adam Jackson
  0 siblings, 0 replies; 62+ messages in thread
From: Adam Jackson @ 2012-09-06 16:51 UTC (permalink / raw)
  To: Meelis Roos; +Cc: sparclinux, dri-devel

[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]

On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:

> [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

This particular message looks like it might actually be harmless, all
the code paths that use the I/O BAR can use the MMIO mirror of it
instead.  No idea how well tested that is, but at any rate it's not
what's breaking your setup.

> 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].

This is probably because...

> 02:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA controller])
>         Subsystem: Advanced Micro Devices [AMD] nee ATI XVR-100 (supplied by Sun)
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0 (2000ns min)
>         Interrupt: pin A routed to IRQ 16
>         Region 0: Memory at 08000000 (32-bit, prefetchable) [size=64M]
>         Region 1: I/O ports at 0400 [disabled] [size=256]
>         Region 2: Memory at 10000000 (32-bit, non-prefetchable) [size=32K]
>         Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
>         Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
>         Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
>         Expansion ROM at 10020000 [disabled] [size=128K]

... the ROM BAR looks like it's not routed.

On x86 you could fix this by booting with 'pci=rom' to force the ROM BAR
to be routed regardless of firmware setup, no idea how that's meant to
work on sparc though.

- ajax

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2012-09-06 14:41 ` Meelis Roos
@ 2012-09-06 16:55   ` Michel Dänzer
  -1 siblings, 0 replies; 62+ messages in thread
From: Michel Dänzer @ 2012-09-06 16:55 UTC (permalink / raw)
  To: Meelis Roos; +Cc: sparclinux, dri-devel

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\x1ff08000000 and size@000) 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?


> With radeon.modeset=0, it boots [...]

Does X work with DRI enabled then?


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2012-09-06 16:55   ` Michel Dänzer
  0 siblings, 0 replies; 62+ messages in thread
From: Michel Dänzer @ 2012-09-06 16:55 UTC (permalink / raw)
  To: Meelis Roos; +Cc: sparclinux, dri-devel

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?


> With radeon.modeset=0, it boots [...]

Does X work with DRI enabled then?


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2012-09-06 14:41 ` Meelis Roos
@ 2012-09-06 18:08   ` David Miller
  -1 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2012-09-06 18:08 UTC (permalink / raw)
  To: mroos; +Cc: sparclinux, dri-devel

From: Meelis Roos <mroos@linux.ee>
Date: Thu, 6 Sep 2012 17:41:13 +0300 (EEST)

> 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\x1ff08000000 and size@000) and tries to read 
> 2 bytes from there and hangs on reading bios[0].

Mappings obtained from ioremap() may not be derefenced directly.

What you get back from ioremap() isn't a pointer.  It's an opaque
__iomem cookie, which must only be used via readl() et al.

On sparc64 ioremap() happens to return a physical address, that's why
this non-portable code crashes.

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2012-09-06 18:08   ` David Miller
  0 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2012-09-06 18:08 UTC (permalink / raw)
  To: mroos; +Cc: sparclinux, dri-devel

From: Meelis Roos <mroos@linux.ee>
Date: Thu, 6 Sep 2012 17:41:13 +0300 (EEST)

> 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].

Mappings obtained from ioremap() may not be derefenced directly.

What you get back from ioremap() isn't a pointer.  It's an opaque
__iomem cookie, which must only be used via readl() et al.

On sparc64 ioremap() happens to return a physical address, that's why
this non-portable code crashes.

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2012-09-06 16:51   ` Adam Jackson
@ 2012-09-06 18:15     ` David Miller
  -1 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2012-09-06 18:15 UTC (permalink / raw)
  To: ajax; +Cc: mroos, sparclinux, dri-devel

From: Adam Jackson <ajax@redhat.com>
Date: Thu, 06 Sep 2012 12:51:17 -0400

> On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
> 
>> 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\x1ff08000000 and size@000) and tries to read 
>> 2 bytes from there and hangs on reading bios[0].
> 
> This is probably because...

I think the real issue is that the VRAM bios reading code is buggy, see
my other email.  It deferences ioremap()'d memory, and that's not allowed.

One must use the proper __iomem pointer accessors, such as readl(), readb(),
etc.

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2012-09-06 18:15     ` David Miller
  0 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2012-09-06 18:15 UTC (permalink / raw)
  To: ajax; +Cc: mroos, sparclinux, dri-devel

From: Adam Jackson <ajax@redhat.com>
Date: Thu, 06 Sep 2012 12:51:17 -0400

> On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
> 
>> 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].
> 
> This is probably because...

I think the real issue is that the VRAM bios reading code is buggy, see
my other email.  It deferences ioremap()'d memory, and that's not allowed.

One must use the proper __iomem pointer accessors, such as readl(), readb(),
etc.

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2012-09-06 16:55   ` Michel Dänzer
@ 2012-09-06 18:18     ` David Miller
  -1 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2012-09-06 18:18 UTC (permalink / raw)
  To: michel; +Cc: mroos, sparclinux, dri-devel

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\x1ff08000000 and size@000) 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().

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2012-09-06 18:18     ` David Miller
  0 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2012-09-06 18:18 UTC (permalink / raw)
  To: michel; +Cc: mroos, sparclinux, dri-devel

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().
--
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

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2012-09-06 18:18     ` David Miller
@ 2012-09-07  7:18       ` Dave Airlie
  -1 siblings, 0 replies; 62+ messages in thread
From: Dave Airlie @ 2012-09-07  7:18 UTC (permalink / raw)
  To: David Miller; +Cc: michel, sparclinux, mroos, dri-devel

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\x1ff08000000 and size@000) 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.

Dave.

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2012-09-07  7:18       ` Dave Airlie
  0 siblings, 0 replies; 62+ messages in thread
From: Dave Airlie @ 2012-09-07  7:18 UTC (permalink / raw)
  To: David Miller; +Cc: michel, sparclinux, mroos, dri-devel

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.

Dave.
--
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

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2012-09-07  7:18       ` Dave Airlie
@ 2012-09-19  7:51         ` mroos
  -1 siblings, 0 replies; 62+ messages in thread
From: mroos @ 2012-09-19  7:51 UTC (permalink / raw)
  To: Dave Airlie; +Cc: David Miller, michel, sparclinux, dri-devel

> we should just skip the igp reading function on not-x86, since IGP on
> not x86 makes no sense.

I #ifdef'ed out the igp part with CONFIG_X86. This time it got to
[drm] radeon: ring at 0x000001FF0C002000
and stopped here. Some printks showed the actual hang happens in
radeon_ring_commit() with the line

(void)RREG32(ring->wptr_reg);

Any ideas where to continue here?

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2012-09-19  7:51         ` mroos
  0 siblings, 0 replies; 62+ messages in thread
From: mroos @ 2012-09-19  7:51 UTC (permalink / raw)
  To: Dave Airlie; +Cc: David Miller, michel, sparclinux, dri-devel

> we should just skip the igp reading function on not-x86, since IGP on
> not x86 makes no sense.

I #ifdef'ed out the igp part with CONFIG_X86. This time it got to
[drm] radeon: ring at 0x000001FF0C002000
and stopped here. Some printks showed the actual hang happens in
radeon_ring_commit() with the line

(void)RREG32(ring->wptr_reg);

Any ideas where to continue here?

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2012-09-07  7:18       ` Dave Airlie
@ 2013-09-23 13:48         ` mroos
  -1 siblings, 0 replies; 62+ messages in thread
From: mroos @ 2013-09-23 13:48 UTC (permalink / raw)
  To: Dave Airlie; +Cc: sparclinux, michel, David Miller, dri-devel

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\x1ff08000000 and size@000) 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.

1. 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.

2. Since "bios" is __iomem pointer, changed its dereferences to 
readb(bios) and readb(bios+1). Maybe relevant, maybe not.

3. 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\00001ff00000000 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\00001ff00000000, sizeF592

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)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2013-09-23 13:48         ` mroos
  0 siblings, 0 replies; 62+ messages in thread
From: mroos @ 2013-09-23 13:48 UTC (permalink / raw)
  To: Dave Airlie; +Cc: sparclinux, michel, David Miller, dri-devel

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.

1. 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.

2. Since "bios" is __iomem pointer, changed its dereferences to 
readb(bios) and readb(bios+1). Maybe relevant, maybe not.

3. 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)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2013-09-23 13:48         ` mroos
@ 2013-09-23 19:06           ` Kjetil Oftedal
  -1 siblings, 0 replies; 62+ messages in thread
From: Kjetil Oftedal @ 2013-09-23 19:06 UTC (permalink / raw)
  To: mroos; +Cc: Dave Airlie, David Miller, michel, sparclinux, dri-devel

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\x1ff08000000 and size@000) 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.
>
> 1. 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.
>
> 2. Since "bios" is __iomem pointer, changed its dereferences to
> readb(bios) and readb(bios+1). Maybe relevant, maybe not.
>
> 3. 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\00001ff00000000 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\00001ff00000000, sizeF592
>
> 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
>

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2013-09-23 19:06           ` Kjetil Oftedal
  0 siblings, 0 replies; 62+ messages in thread
From: Kjetil Oftedal @ 2013-09-23 19:06 UTC (permalink / raw)
  To: mroos; +Cc: Dave Airlie, David Miller, michel, sparclinux, dri-devel

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.
>
> 1. 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.
>
> 2. Since "bios" is __iomem pointer, changed its dereferences to
> readb(bios) and readb(bios+1). Maybe relevant, maybe not.
>
> 3. 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
>
--
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

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2013-09-23 19:06           ` Kjetil Oftedal
@ 2013-09-23 20:36             ` David Miller
  -1 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2013-09-23 20:36 UTC (permalink / raw)
  To: oftedal; +Cc: mroos, airlied, michel, sparclinux, dri-devel

From: Kjetil Oftedal <oftedal@gmail.com>
Date: Mon, 23 Sep 2013 21:06:11 +0200

> That looks quite strange. I guess the kernel should map the ROM at the
> address OpenBoot/OF assigned to it. ( 10020000 ).

The address you see is a raw physical I/O address, which is a concatenation
of the I/O window physical address for that PCI controller and the
PCI bus assigned address.

This is what we store in the resource values.

The pci_assign_resource() path must have some bug that causes the
resource values to be set incorrectly or similar.

Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
before the pci_map_rom() call?



^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2013-09-23 20:36             ` David Miller
  0 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2013-09-23 20:36 UTC (permalink / raw)
  To: oftedal; +Cc: mroos, airlied, michel, sparclinux, dri-devel

From: Kjetil Oftedal <oftedal@gmail.com>
Date: Mon, 23 Sep 2013 21:06:11 +0200

> That looks quite strange. I guess the kernel should map the ROM at the
> address OpenBoot/OF assigned to it. ( 10020000 ).

The address you see is a raw physical I/O address, which is a concatenation
of the I/O window physical address for that PCI controller and the
PCI bus assigned address.

This is what we store in the resource values.

The pci_assign_resource() path must have some bug that causes the
resource values to be set incorrectly or similar.

Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
before the pci_map_rom() call?



^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2013-09-23 20:36             ` David Miller
@ 2013-09-23 21:14               ` mroos
  -1 siblings, 0 replies; 62+ messages in thread
From: mroos @ 2013-09-23 21:14 UTC (permalink / raw)
  To: David Miller; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

> > That looks quite strange. I guess the kernel should map the ROM at the
> > address OpenBoot/OF assigned to it. ( 10020000 ).
> 
> The address you see is a raw physical I/O address, which is a concatenation
> of the I/O window physical address for that PCI controller and the
> PCI bus assigned address.
> 
> This is what we store in the resource values.
> 
> The pci_assign_resource() path must have some bug that causes the
> resource values to be set incorrectly or similar.
> 
> Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
> before the pci_map_rom() call?

[drm] radeon_read_bios: pci_resource_start(ROM)\00001FF10020000

I am a little confused here. ROM addressis OK but after pci_map_rom it 
results in address that corresponds to another device?

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2013-09-23 21:14               ` mroos
  0 siblings, 0 replies; 62+ messages in thread
From: mroos @ 2013-09-23 21:14 UTC (permalink / raw)
  To: David Miller; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

> > That looks quite strange. I guess the kernel should map the ROM at the
> > address OpenBoot/OF assigned to it. ( 10020000 ).
> 
> The address you see is a raw physical I/O address, which is a concatenation
> of the I/O window physical address for that PCI controller and the
> PCI bus assigned address.
> 
> This is what we store in the resource values.
> 
> The pci_assign_resource() path must have some bug that causes the
> resource values to be set incorrectly or similar.
> 
> Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
> before the pci_map_rom() call?

[drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000

I am a little confused here. ROM addressis OK but after pci_map_rom it 
results in address that corresponds to another device?

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2013-09-23 19:06           ` Kjetil Oftedal
@ 2013-09-23 21:18             ` Meelis Roos
  -1 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-09-23 21:18 UTC (permalink / raw)
  To: Kjetil Oftedal; +Cc: Dave Airlie, David Miller, michel, sparclinux, dri-devel

> That looks quite strange. I guess the kernel should map the ROM at the
> address OpenBoot/OF assigned to it. ( 10020000 ).

DaveM already explained about the phys/virt mapping.

> 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 ?

But here it is anyway if it is of any help.

Expansion ROM at 10020000 [disabled] [size\x128K], it seems to have 128K 
window but pci_map_rom returns smaller size.


00:01.0 PCI bridge: Oracle/SUN Simba Advanced PCI Bridge (rev 13) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64, Cache Line Size: 64 bytes
	Region 0: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 1: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Bus: primary\0, secondary\x02, subordinateÿ, sec-latencyd
	I/O behind bridge: 00000000-00000fff
	Memory behind bridge: 00000000-000fffff
	Prefetchable memory behind bridge: 00000000-000fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	[virtual] Expansion ROM at fffffe0100000000 [disabled] [size=1]
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort+ >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

00:01.1 PCI bridge: Oracle/SUN Simba Advanced PCI Bridge (rev 13) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64, Cache Line Size: 64 bytes
	Region 0: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 1: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Bus: primary\0, secondary\x01, subordinate\x01, sec-latencyd
	I/O behind bridge: 00000000-00000fff
	Memory behind bridge: 00000000-000fffff
	Prefetchable memory behind bridge: 00000000-000fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	[virtual] Expansion ROM at fffffe0100000000 [disabled] [size=1]
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort+ >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

01:01.0 Bridge: Oracle/SUN EBUS (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (2500ns min, 6250ns max)
	Region 0: Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 1: Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 2: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at fffffe0100000000 [disabled] [size=1]

01:01.1 Ethernet controller: Oracle/SUN Happy Meal 10/100 Ethernet [hme] (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (2500ns min, 1250ns max)
	Interrupt: pin ? routed to IRQ 12
	Region 0: Memory at e0000000 (32-bit, non-prefetchable) [size(K]
	Region 1: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 2: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at fffffe0100000000 [disabled] [size=1]
	Kernel driver in use: hme

01:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI 3D Rage Pro 215GP (rev 5c) (prog-if 00 [VGA controller])
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 13
	Region 0: Memory at e1000000 (32-bit, non-prefetchable) [size\x16M]
	Region 1: I/O ports at fffffe0100000000 [disabled] [size=1]
	Region 2: Memory at e2000000 (32-bit, non-prefetchable) [size=4K]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at fffffe0100000000 [disabled] [size=1]
	Kernel driver in use: atyfb

01:03.0 IDE interface: Silicon Image, Inc. PCI0646 (rev 03) (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: Silicon Image, Inc. PCI0646
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (500ns min, 1000ns max)
	Interrupt: pin A routed to IRQ 14
	Region 0: I/O ports at c00000 [size=8]
	Region 1: I/O ports at c00008 [size=4]
	Region 2: I/O ports at c00010 [size=8]
	Region 3: I/O ports at c00018 [size=4]
	Region 4: I/O ports at c00020 [size\x16]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	[virtual] Expansion ROM at fffffe0100000000 [disabled] [size=1]
	Kernel driver in use: pata_cmd64x

02:01.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 128 (2000ns min, 2000ns max)
	Interrupt: pin A routed to IRQ 15
	Region 0: I/O ports at fffffe0100000000 [disabled] [size=1]
	Region 1: Memory at 00002000 (32-bit, non-prefetchable) [size%6]
	Region 2: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at 00010000 [disabled] [sizedK]
	Kernel driver in use: aic7xxx

02:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA controller])
	Subsystem: Advanced Micro Devices [AMD] nee ATI XVR-100 (supplied by Sun)
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at 08000000 (32-bit, prefetchable) [disabled] [sizedM]
	Region 1: I/O ports at 0400 [disabled] [size%6]
	Region 2: Memory at 10000000 (32-bit, non-prefetchable) [disabled] [size2K]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at 10020000 [disabled] [size\x128K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

02:03.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Rage XL (rev 27) (prog-if 00 [VGA controller])
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 17
	Region 0: Memory at 11000000 (32-bit, non-prefetchable) [size\x16M]
	Region 1: I/O ports at fffffe0100000000 [disabled] [size=1]
	Region 2: Memory at 12000000 (32-bit, non-prefetchable) [size=4K]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at 12020000 [disabled] [size\x128K]
	Capabilities: [5c] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: atyfb

02:04.0 Ethernet controller: Fujitsu Limited. Device 11a2 (rev 02)
	Subsystem: Fujitsu Limited. Device 11a2
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at 12040000 (64-bit, non-prefetchable) [disabled] [sizedK]
	Region 2: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at fffffe0100000000 [disabled] [size=1]
	Capabilities: [40] PCI-X non-bridge device
		Command: DPERE- ERO+ RBCQ2 OST=1
		Status: Devÿ:1f.1 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC 48 DMOST=1 DMCRS\x16 RSCEM- 266MHz- 533MHz-
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] Vital Product Data
		Unknown small resource type 00, will not decode more.
	Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
		Address: 082024c310601050  Data: 1080


-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2013-09-23 21:18             ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-09-23 21:18 UTC (permalink / raw)
  To: Kjetil Oftedal; +Cc: Dave Airlie, David Miller, michel, sparclinux, dri-devel

> That looks quite strange. I guess the kernel should map the ROM at the
> address OpenBoot/OF assigned to it. ( 10020000 ).

DaveM already explained about the phys/virt mapping.

> 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 ?

But here it is anyway if it is of any help.

Expansion ROM at 10020000 [disabled] [size=128K], it seems to have 128K 
window but pci_map_rom returns smaller size.


00:01.0 PCI bridge: Oracle/SUN Simba Advanced PCI Bridge (rev 13) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64, Cache Line Size: 64 bytes
	Region 0: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 1: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Bus: primary=00, secondary=02, subordinate=ff, sec-latency=64
	I/O behind bridge: 00000000-00000fff
	Memory behind bridge: 00000000-000fffff
	Prefetchable memory behind bridge: 00000000-000fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	[virtual] Expansion ROM at fffffe0100000000 [disabled] [size=1]
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort+ >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

00:01.1 PCI bridge: Oracle/SUN Simba Advanced PCI Bridge (rev 13) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64, Cache Line Size: 64 bytes
	Region 0: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 1: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 00000000-00000fff
	Memory behind bridge: 00000000-000fffff
	Prefetchable memory behind bridge: 00000000-000fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	[virtual] Expansion ROM at fffffe0100000000 [disabled] [size=1]
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort+ >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

01:01.0 Bridge: Oracle/SUN EBUS (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (2500ns min, 6250ns max)
	Region 0: Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 1: Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 2: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at fffffe0100000000 [disabled] [size=1]

01:01.1 Ethernet controller: Oracle/SUN Happy Meal 10/100 Ethernet [hme] (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (2500ns min, 1250ns max)
	Interrupt: pin ? routed to IRQ 12
	Region 0: Memory at e0000000 (32-bit, non-prefetchable) [size=28K]
	Region 1: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 2: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at fffffe0100000000 [disabled] [size=1]
	Kernel driver in use: hme

01:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI 3D Rage Pro 215GP (rev 5c) (prog-if 00 [VGA controller])
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 13
	Region 0: Memory at e1000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: I/O ports at fffffe0100000000 [disabled] [size=1]
	Region 2: Memory at e2000000 (32-bit, non-prefetchable) [size=4K]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at fffffe0100000000 [disabled] [size=1]
	Kernel driver in use: atyfb

01:03.0 IDE interface: Silicon Image, Inc. PCI0646 (rev 03) (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: Silicon Image, Inc. PCI0646
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (500ns min, 1000ns max)
	Interrupt: pin A routed to IRQ 14
	Region 0: I/O ports at c00000 [size=8]
	Region 1: I/O ports at c00008 [size=4]
	Region 2: I/O ports at c00010 [size=8]
	Region 3: I/O ports at c00018 [size=4]
	Region 4: I/O ports at c00020 [size=16]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	[virtual] Expansion ROM at fffffe0100000000 [disabled] [size=1]
	Kernel driver in use: pata_cmd64x

02:01.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 128 (2000ns min, 2000ns max)
	Interrupt: pin A routed to IRQ 15
	Region 0: I/O ports at fffffe0100000000 [disabled] [size=1]
	Region 1: Memory at 00002000 (32-bit, non-prefetchable) [size=256]
	Region 2: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at 00010000 [disabled] [size=64K]
	Kernel driver in use: aic7xxx

02:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA controller])
	Subsystem: Advanced Micro Devices [AMD] nee ATI XVR-100 (supplied by Sun)
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at 08000000 (32-bit, prefetchable) [disabled] [size=64M]
	Region 1: I/O ports at 0400 [disabled] [size=256]
	Region 2: Memory at 10000000 (32-bit, non-prefetchable) [disabled] [size=32K]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at 10020000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

02:03.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Rage XL (rev 27) (prog-if 00 [VGA controller])
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 17
	Region 0: Memory at 11000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: I/O ports at fffffe0100000000 [disabled] [size=1]
	Region 2: Memory at 12000000 (32-bit, non-prefetchable) [size=4K]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at 12020000 [disabled] [size=128K]
	Capabilities: [5c] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: atyfb

02:04.0 Ethernet controller: Fujitsu Limited. Device 11a2 (rev 02)
	Subsystem: Fujitsu Limited. Device 11a2
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at 12040000 (64-bit, non-prefetchable) [disabled] [size=64K]
	Region 2: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable) [size=1]
	Expansion ROM at fffffe0100000000 [disabled] [size=1]
	Capabilities: [40] PCI-X non-bridge device
		Command: DPERE- ERO+ RBC=512 OST=1
		Status: Dev=ff:1f.1 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] Vital Product Data
		Unknown small resource type 00, will not decode more.
	Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
		Address: 082024c310601050  Data: 1080


-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2013-09-23 21:14               ` mroos
@ 2013-09-23 21:33                 ` David Miller
  -1 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2013-09-23 21:33 UTC (permalink / raw)
  To: mroos; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

From: mroos@linux.ee
Date: Tue, 24 Sep 2013 00:14:41 +0300 (EEST)

>> > That looks quite strange. I guess the kernel should map the ROM at the
>> > address OpenBoot/OF assigned to it. ( 10020000 ).
>> 
>> The address you see is a raw physical I/O address, which is a concatenation
>> of the I/O window physical address for that PCI controller and the
>> PCI bus assigned address.
>> 
>> This is what we store in the resource values.
>> 
>> The pci_assign_resource() path must have some bug that causes the
>> resource values to be set incorrectly or similar.
>> 
>> Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
>> before the pci_map_rom() call?
> 
> [drm] radeon_read_bios: pci_resource_start(ROM)\00001FF10020000
> 
> I am a little confused here. ROM addressis OK but after pci_map_rom it 
> results in address that corresponds to another device?

That's certainly a bug.

So after pci_map_rom() pci_resource_start(ROM)\00001FF00000000, right?

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2013-09-23 21:33                 ` David Miller
  0 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2013-09-23 21:33 UTC (permalink / raw)
  To: mroos; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

From: mroos@linux.ee
Date: Tue, 24 Sep 2013 00:14:41 +0300 (EEST)

>> > That looks quite strange. I guess the kernel should map the ROM at the
>> > address OpenBoot/OF assigned to it. ( 10020000 ).
>> 
>> The address you see is a raw physical I/O address, which is a concatenation
>> of the I/O window physical address for that PCI controller and the
>> PCI bus assigned address.
>> 
>> This is what we store in the resource values.
>> 
>> The pci_assign_resource() path must have some bug that causes the
>> resource values to be set incorrectly or similar.
>> 
>> Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
>> before the pci_map_rom() call?
> 
> [drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000
> 
> I am a little confused here. ROM addressis OK but after pci_map_rom it 
> results in address that corresponds to another device?

That's certainly a bug.

So after pci_map_rom() pci_resource_start(ROM)=000001FF00000000, right?

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2013-09-23 21:33                 ` David Miller
@ 2013-09-24 11:06                   ` Meelis Roos
  -1 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-09-24 11:06 UTC (permalink / raw)
  To: David Miller; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

> >> > That looks quite strange. I guess the kernel should map the ROM at the
> >> > address OpenBoot/OF assigned to it. ( 10020000 ).
> >> 
> >> The address you see is a raw physical I/O address, which is a concatenation
> >> of the I/O window physical address for that PCI controller and the
> >> PCI bus assigned address.
> >> 
> >> This is what we store in the resource values.
> >> 
> >> The pci_assign_resource() path must have some bug that causes the
> >> resource values to be set incorrectly or similar.
> >> 
> >> Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
> >> before the pci_map_rom() call?
> > 
> > [drm] radeon_read_bios: pci_resource_start(ROM)\00001FF10020000
> > 
> > I am a little confused here. ROM addressis OK but after pci_map_rom it 
> > results in address that corresponds to another device?
> 
> That's certainly a bug.
> 
> So after pci_map_rom() pci_resource_start(ROM)\00001FF00000000, right?

I double checked it - yes:

before pci_map_rom:
[drm] radeon_read_bios: pci_resource_start(ROM)\00001FF10020000                                                                          

radeon 0000:02:02.0: BAR 6: assigned [mem 0x1ff00000000-0x1ff0001ffff]

after pci_map_rom:

[drm] radeon_read_bios, bios\00001ff00000000, pci_resource_start(ROM)\00001FF00000000, sizeF592


[drm] radeon_read_bios: found ROM signature at 000001ff00000000
[drm] radeon_read_bios: bios\00001ff00000000, sizeF592


-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2013-09-24 11:06                   ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-09-24 11:06 UTC (permalink / raw)
  To: David Miller; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

> >> > That looks quite strange. I guess the kernel should map the ROM at the
> >> > address OpenBoot/OF assigned to it. ( 10020000 ).
> >> 
> >> The address you see is a raw physical I/O address, which is a concatenation
> >> of the I/O window physical address for that PCI controller and the
> >> PCI bus assigned address.
> >> 
> >> This is what we store in the resource values.
> >> 
> >> The pci_assign_resource() path must have some bug that causes the
> >> resource values to be set incorrectly or similar.
> >> 
> >> Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
> >> before the pci_map_rom() call?
> > 
> > [drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000
> > 
> > I am a little confused here. ROM addressis OK but after pci_map_rom it 
> > results in address that corresponds to another device?
> 
> That's certainly a bug.
> 
> So after pci_map_rom() pci_resource_start(ROM)=000001FF00000000, right?

I double checked it - yes:

before pci_map_rom:
[drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000                                                                          

radeon 0000:02:02.0: BAR 6: assigned [mem 0x1ff00000000-0x1ff0001ffff]

after pci_map_rom:

[drm] radeon_read_bios, bios=000001ff00000000, pci_resource_start(ROM)=000001FF00000000, size=46592


[drm] radeon_read_bios: found ROM signature at 000001ff00000000
[drm] radeon_read_bios: bios=000001ff00000000, size=46592


-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2013-09-24 11:06                   ` Meelis Roos
@ 2013-09-25 23:26                     ` Meelis Roos
  -1 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-09-25 23:26 UTC (permalink / raw)
  To: David Miller; +Cc: oftedal, airlied, michel, sparclinux, dri-devel


> > >> The pci_assign_resource() path must have some bug that causes the
> > >> resource values to be set incorrectly or similar.
> > >> 
> > >> Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
> > >> before the pci_map_rom() call?
> > > 
> > > [drm] radeon_read_bios: pci_resource_start(ROM)\00001FF10020000
> > > 
> > > I am a little confused here. ROM addressis OK but after pci_map_rom it 
> > > results in address that corresponds to another device?
> > 
> > That's certainly a bug.
> > 
> > So after pci_map_rom() pci_resource_start(ROM)\00001FF00000000, right?
> 
> I double checked it - yes:
> 
> before pci_map_rom:
> [drm] radeon_read_bios: pci_resource_start(ROM)\00001FF10020000                                                                          
> 
> radeon 0000:02:02.0: BAR 6: assigned [mem 0x1ff00000000-0x1ff0001ffff]
> 
> after pci_map_rom:
> 
> [drm] radeon_read_bios, bios\00001ff00000000, pci_resource_start(ROM)\00001FF00000000, sizeF592

This is first range in pci bus 0000:02 that is tried, and it matches:
pci_bus 0000:02: pci_bus_alloc_resource trying [mem 0x1ff00000000-0x1ff00bfffff]

I instrumented bootup with pci_bus_add_resource_offset and 
pci_bus_add_resource logs if this of any help:

/pci@1f,0: PCI IO[1fe02000000] MEM[1ff00000000]
/pci@1f,0: SABRE PCI Bus Module ver[0:0]
PCI: Scanning PBM /pci@1f,0
pci_bus_add_resource_offset adding [io  0x1fe02000000-0x1fe02ffffff]
pci_bus_add_resource_offset adding [mem 0x1ff00000000-0x1ffffffffff]
pci_bus_add_resource_offset adding [bus 00-02]
sabre f005f9c0: PCI host bridge to bus 0000:00
pci_bus 0000:00: pci_bus_add_resource adding [io  0x1fe02000000-0x1fe02ffffff] with flags 0
pci_bus 0000:00: root bus resource [io  0x1fe02000000-0x1fe02ffffff] (bus address [0x0000-0xffffff])
pci_bus 0000:00: pci_bus_add_resource adding [mem 0x1ff00000000-0x1ffffffffff] with flags 0
pci_bus 0000:00: root bus resource [mem 0x1ff00000000-0x1ffffffffff] (bus address [0x00000000-0xffffffff])
pci_bus 0000:00: root bus resource [bus 00-02]

To me it looks like we get the PCI bus ranges and store them and nobody 
uses them until now, and then we insert PCI devices with allocations 
from OF and do not update PCI bus available windows?

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2013-09-25 23:26                     ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-09-25 23:26 UTC (permalink / raw)
  To: David Miller; +Cc: oftedal, airlied, michel, sparclinux, dri-devel


> > >> The pci_assign_resource() path must have some bug that causes the
> > >> resource values to be set incorrectly or similar.
> > >> 
> > >> Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
> > >> before the pci_map_rom() call?
> > > 
> > > [drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000
> > > 
> > > I am a little confused here. ROM addressis OK but after pci_map_rom it 
> > > results in address that corresponds to another device?
> > 
> > That's certainly a bug.
> > 
> > So after pci_map_rom() pci_resource_start(ROM)=000001FF00000000, right?
> 
> I double checked it - yes:
> 
> before pci_map_rom:
> [drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000                                                                          
> 
> radeon 0000:02:02.0: BAR 6: assigned [mem 0x1ff00000000-0x1ff0001ffff]
> 
> after pci_map_rom:
> 
> [drm] radeon_read_bios, bios=000001ff00000000, pci_resource_start(ROM)=000001FF00000000, size=46592

This is first range in pci bus 0000:02 that is tried, and it matches:
pci_bus 0000:02: pci_bus_alloc_resource trying [mem 0x1ff00000000-0x1ff00bfffff]

I instrumented bootup with pci_bus_add_resource_offset and 
pci_bus_add_resource logs if this of any help:

/pci@1f,0: PCI IO[1fe02000000] MEM[1ff00000000]
/pci@1f,0: SABRE PCI Bus Module ver[0:0]
PCI: Scanning PBM /pci@1f,0
pci_bus_add_resource_offset adding [io  0x1fe02000000-0x1fe02ffffff]
pci_bus_add_resource_offset adding [mem 0x1ff00000000-0x1ffffffffff]
pci_bus_add_resource_offset adding [bus 00-02]
sabre f005f9c0: PCI host bridge to bus 0000:00
pci_bus 0000:00: pci_bus_add_resource adding [io  0x1fe02000000-0x1fe02ffffff] with flags 0
pci_bus 0000:00: root bus resource [io  0x1fe02000000-0x1fe02ffffff] (bus address [0x0000-0xffffff])
pci_bus 0000:00: pci_bus_add_resource adding [mem 0x1ff00000000-0x1ffffffffff] with flags 0
pci_bus 0000:00: root bus resource [mem 0x1ff00000000-0x1ffffffffff] (bus address [0x00000000-0xffffffff])
pci_bus 0000:00: root bus resource [bus 00-02]

To me it looks like we get the PCI bus ranges and store them and nobody 
uses them until now, and then we insert PCI devices with allocations 
from OF and do not update PCI bus available windows?

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2013-09-23 21:14               ` mroos
@ 2013-10-01  8:43                 ` Meelis Roos
  -1 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-10-01  8:43 UTC (permalink / raw)
  To: David Miller; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

> > > That looks quite strange. I guess the kernel should map the ROM at the
> > > address OpenBoot/OF assigned to it. ( 10020000 ).
> > 
> > The address you see is a raw physical I/O address, which is a concatenation
> > of the I/O window physical address for that PCI controller and the
> > PCI bus assigned address.
> > 
> > This is what we store in the resource values.
> > 
> > The pci_assign_resource() path must have some bug that causes the
> > resource values to be set incorrectly or similar.
> > 
> > Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
> > before the pci_map_rom() call?
> 
> [drm] radeon_read_bios: pci_resource_start(ROM)\00001FF10020000
> 
> I am a little confused here. ROM addressis OK but after pci_map_rom it 
> results in address that corresponds to another device?

I read more code and tried a couple of more things.

Using ofpci_debug=1 I get sensible output for scsi:

PCI: scan_bus[/pci@1f,0/pci@1] bus no 2
  * /pci@1f,0/pci@1/scsi@1
    create device, devfn: 8, type: scsi-2
    class: 0x10000 device name: 0000:02:01.0
    parse addresses (40 bytes) @ fffff8003fedc1c0
  start: 1ff00002000, end: 1ff000020ff, i: 14
  start: 1ff00010000, end: 1ff0001ffff, i: 30
    adding to system ...

adding to system refers to pci_device_add(dev, bus) and that does not 
modify the PCI bus available windows in any way, at least by my reafing 
of the PCI code, so the PCI code does not know the resource ranges are 
now busy?

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2013-10-01  8:43                 ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-10-01  8:43 UTC (permalink / raw)
  To: David Miller; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

> > > That looks quite strange. I guess the kernel should map the ROM at the
> > > address OpenBoot/OF assigned to it. ( 10020000 ).
> > 
> > The address you see is a raw physical I/O address, which is a concatenation
> > of the I/O window physical address for that PCI controller and the
> > PCI bus assigned address.
> > 
> > This is what we store in the resource values.
> > 
> > The pci_assign_resource() path must have some bug that causes the
> > resource values to be set incorrectly or similar.
> > 
> > Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
> > before the pci_map_rom() call?
> 
> [drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000
> 
> I am a little confused here. ROM addressis OK but after pci_map_rom it 
> results in address that corresponds to another device?

I read more code and tried a couple of more things.

Using ofpci_debug=1 I get sensible output for scsi:

PCI: scan_bus[/pci@1f,0/pci@1] bus no 2
  * /pci@1f,0/pci@1/scsi@1
    create device, devfn: 8, type: scsi-2
    class: 0x10000 device name: 0000:02:01.0
    parse addresses (40 bytes) @ fffff8003fedc1c0
  start: 1ff00002000, end: 1ff000020ff, i: 14
  start: 1ff00010000, end: 1ff0001ffff, i: 30
    adding to system ...

adding to system refers to pci_device_add(dev, bus) and that does not 
modify the PCI bus available windows in any way, at least by my reafing 
of the PCI code, so the PCI code does not know the resource ranges are 
now busy?

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* [PATCH] only try to find radeon IGP ROM on X86
  2013-09-23 19:06           ` Kjetil Oftedal
@ 2013-10-10 11:51             ` Meelis Roos
  -1 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-10-10 11:51 UTC (permalink / raw)
  To: Dave Airlie, Alex Deucher; +Cc: David Miller, sparclinux, dri-devel

To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM 
from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon 
detection to move on to next problem.

Signed-off-by: Meelis Roos <mroos@linux.ee>

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
index 061b227..48ef97c 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -49,6 +49,11 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
 	resource_size_t vram_base;
 	resource_size_t size = 256 * 1024; /* ??? */
 
+#ifndef CONFIG_X86
+	/* IGP only exists on X86 (32- and 64-bit) */
+	return false;
+#endif
+
 	if (!(rdev->flags & RADEON_IS_IGP))
 		if (!radeon_card_posted(rdev))
 			return false;

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply related	[flat|nested] 62+ messages in thread

* [PATCH] only try to find radeon IGP ROM on X86
@ 2013-10-10 11:51             ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-10-10 11:51 UTC (permalink / raw)
  To: Dave Airlie, Alex Deucher; +Cc: David Miller, sparclinux, dri-devel

To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM 
from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon 
detection to move on to next problem.

Signed-off-by: Meelis Roos <mroos@linux.ee>

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
index 061b227..48ef97c 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -49,6 +49,11 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
 	resource_size_t vram_base;
 	resource_size_t size = 256 * 1024; /* ??? */
 
+#ifndef CONFIG_X86
+	/* IGP only exists on X86 (32- and 64-bit) */
+	return false;
+#endif
+
 	if (!(rdev->flags & RADEON_IS_IGP))
 		if (!radeon_card_posted(rdev))
 			return false;

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply related	[flat|nested] 62+ messages in thread

* Re: [PATCH] only try to find radeon IGP ROM on X86
  2013-10-10 11:51             ` Meelis Roos
@ 2013-10-10 14:38               ` Alex Deucher
  -1 siblings, 0 replies; 62+ messages in thread
From: Alex Deucher @ 2013-10-10 14:38 UTC (permalink / raw)
  To: Meelis Roos
  Cc: Dave Airlie, David Miller, sparclinux, Maling list - DRI developers

On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos <mroos@linux.ee> wrote:
> To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
> from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
> detection to move on to next problem.

NACK.  All this function does it attempt to read the rom from the
framebuffer PCI BAR.  If you get hangs reading the BAR, then you have
larger problems on your platform.  Also, there are non-x86 platforms
that IGP chips which this may break.

Alex

>
> Signed-off-by: Meelis Roos <mroos@linux.ee>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
> index 061b227..48ef97c 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -49,6 +49,11 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
>         resource_size_t vram_base;
>         resource_size_t size = 256 * 1024; /* ??? */
>
> +#ifndef CONFIG_X86
> +       /* IGP only exists on X86 (32- and 64-bit) */
> +       return false;
> +#endif
> +
>         if (!(rdev->flags & RADEON_IS_IGP))
>                 if (!radeon_card_posted(rdev))
>                         return false;
>
> --
> Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: [PATCH] only try to find radeon IGP ROM on X86
@ 2013-10-10 14:38               ` Alex Deucher
  0 siblings, 0 replies; 62+ messages in thread
From: Alex Deucher @ 2013-10-10 14:38 UTC (permalink / raw)
  To: Meelis Roos
  Cc: Dave Airlie, David Miller, sparclinux, Maling list - DRI developers

On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos <mroos@linux.ee> wrote:
> To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
> from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
> detection to move on to next problem.

NACK.  All this function does it attempt to read the rom from the
framebuffer PCI BAR.  If you get hangs reading the BAR, then you have
larger problems on your platform.  Also, there are non-x86 platforms
that IGP chips which this may break.

Alex

>
> Signed-off-by: Meelis Roos <mroos@linux.ee>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
> index 061b227..48ef97c 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -49,6 +49,11 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
>         resource_size_t vram_base;
>         resource_size_t size = 256 * 1024; /* ??? */
>
> +#ifndef CONFIG_X86
> +       /* IGP only exists on X86 (32- and 64-bit) */
> +       return false;
> +#endif
> +
>         if (!(rdev->flags & RADEON_IS_IGP))
>                 if (!radeon_card_posted(rdev))
>                         return false;
>
> --
> Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: [PATCH] only try to find radeon IGP ROM on X86
  2013-10-10 14:38               ` Alex Deucher
@ 2013-10-10 15:26                 ` Meelis Roos
  -1 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-10-10 15:26 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Dave Airlie, David Miller, sparclinux, Maling list - DRI developers

> On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos <mroos@linux.ee> wrote:
> > To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
> > from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
> > detection to move on to next problem.
> 
> NACK.  All this function does it attempt to read the rom from the
> framebuffer PCI BAR.  If you get hangs reading the BAR, then you have
> larger problems on your platform.  Also, there are non-x86 platforms
> that IGP chips which this may break.

OK. But the code seems to just dereference addresses returned from 
ioremap, but to the best of my knowledge, these are not universally 
(like on each arch) safe to read without readb/readw/readl. Should I 
convert these to readb for test?

> > Signed-off-by: Meelis Roos <mroos@linux.ee>
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
> > index 061b227..48ef97c 100644
> > --- a/drivers/gpu/drm/radeon/radeon_bios.c
> > +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> > @@ -49,6 +49,11 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
> >         resource_size_t vram_base;
> >         resource_size_t size = 256 * 1024; /* ??? */
> >
> > +#ifndef CONFIG_X86
> > +       /* IGP only exists on X86 (32- and 64-bit) */
> > +       return false;
> > +#endif
> > +
> >         if (!(rdev->flags & RADEON_IS_IGP))
> >                 if (!radeon_card_posted(rdev))
> >                         return false;
> >
> > --
> > Meelis Roos (mroos@linux.ee)
> 

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: [PATCH] only try to find radeon IGP ROM on X86
@ 2013-10-10 15:26                 ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2013-10-10 15:26 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Dave Airlie, David Miller, sparclinux, Maling list - DRI developers

> On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos <mroos@linux.ee> wrote:
> > To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
> > from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
> > detection to move on to next problem.
> 
> NACK.  All this function does it attempt to read the rom from the
> framebuffer PCI BAR.  If you get hangs reading the BAR, then you have
> larger problems on your platform.  Also, there are non-x86 platforms
> that IGP chips which this may break.

OK. But the code seems to just dereference addresses returned from 
ioremap, but to the best of my knowledge, these are not universally 
(like on each arch) safe to read without readb/readw/readl. Should I 
convert these to readb for test?

> > Signed-off-by: Meelis Roos <mroos@linux.ee>
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
> > index 061b227..48ef97c 100644
> > --- a/drivers/gpu/drm/radeon/radeon_bios.c
> > +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> > @@ -49,6 +49,11 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
> >         resource_size_t vram_base;
> >         resource_size_t size = 256 * 1024; /* ??? */
> >
> > +#ifndef CONFIG_X86
> > +       /* IGP only exists on X86 (32- and 64-bit) */
> > +       return false;
> > +#endif
> > +
> >         if (!(rdev->flags & RADEON_IS_IGP))
> >                 if (!radeon_card_posted(rdev))
> >                         return false;
> >
> > --
> > Meelis Roos (mroos@linux.ee)
> 

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: [PATCH] only try to find radeon IGP ROM on X86
  2013-10-10 15:26                 ` Meelis Roos
@ 2013-10-10 17:02                   ` David Miller
  -1 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2013-10-10 17:02 UTC (permalink / raw)
  To: mroos; +Cc: alexdeucher, airlied, sparclinux, dri-devel

From: Meelis Roos <mroos@linux.ee>
Date: Thu, 10 Oct 2013 18:26:39 +0300 (EEST)

>> On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos <mroos@linux.ee> wrote:
>> > To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
>> > from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
>> > detection to move on to next problem.
>> 
>> NACK.  All this function does it attempt to read the rom from the
>> framebuffer PCI BAR.  If you get hangs reading the BAR, then you have
>> larger problems on your platform.  Also, there are non-x86 platforms
>> that IGP chips which this may break.
> 
> OK. But the code seems to just dereference addresses returned from 
> ioremap, but to the best of my knowledge, these are not universally 
> (like on each arch) safe to read without readb/readw/readl. Should I 
> convert these to readb for test?

That's correct, ioremap() returned pointers must not be directly
dereferenced, and must be accessed through the appropriate accessors.

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: [PATCH] only try to find radeon IGP ROM on X86
@ 2013-10-10 17:02                   ` David Miller
  0 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2013-10-10 17:02 UTC (permalink / raw)
  To: mroos; +Cc: alexdeucher, airlied, sparclinux, dri-devel

From: Meelis Roos <mroos@linux.ee>
Date: Thu, 10 Oct 2013 18:26:39 +0300 (EEST)

>> On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos <mroos@linux.ee> wrote:
>> > To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
>> > from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
>> > detection to move on to next problem.
>> 
>> NACK.  All this function does it attempt to read the rom from the
>> framebuffer PCI BAR.  If you get hangs reading the BAR, then you have
>> larger problems on your platform.  Also, there are non-x86 platforms
>> that IGP chips which this may break.
> 
> OK. But the code seems to just dereference addresses returned from 
> ioremap, but to the best of my knowledge, these are not universally 
> (like on each arch) safe to read without readb/readw/readl. Should I 
> convert these to readb for test?

That's correct, ioremap() returned pointers must not be directly
dereferenced, and must be accessed through the appropriate accessors.

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: [PATCH] only try to find radeon IGP ROM on X86
  2013-10-10 15:26                 ` Meelis Roos
@ 2013-10-10 17:10                   ` Alex Deucher
  -1 siblings, 0 replies; 62+ messages in thread
From: Alex Deucher @ 2013-10-10 17:10 UTC (permalink / raw)
  To: Meelis Roos; +Cc: sparclinux, David Miller, Maling list - DRI developers

On Thu, Oct 10, 2013 at 11:26 AM, Meelis Roos <mroos@linux.ee> wrote:
>> On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos <mroos@linux.ee> wrote:
>> > To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
>> > from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
>> > detection to move on to next problem.
>>
>> NACK.  All this function does it attempt to read the rom from the
>> framebuffer PCI BAR.  If you get hangs reading the BAR, then you have
>> larger problems on your platform.  Also, there are non-x86 platforms
>> that IGP chips which this may break.
>
> OK. But the code seems to just dereference addresses returned from
> ioremap, but to the best of my knowledge, these are not universally
> (like on each arch) safe to read without readb/readw/readl. Should I
> convert these to readb for test?

Yeah, that would be great.

Thanks,

Alex

>
>> > Signed-off-by: Meelis Roos <mroos@linux.ee>
>> >
>> > diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
>> > index 061b227..48ef97c 100644
>> > --- a/drivers/gpu/drm/radeon/radeon_bios.c
>> > +++ b/drivers/gpu/drm/radeon/radeon_bios.c
>> > @@ -49,6 +49,11 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
>> >         resource_size_t vram_base;
>> >         resource_size_t size = 256 * 1024; /* ??? */
>> >
>> > +#ifndef CONFIG_X86
>> > +       /* IGP only exists on X86 (32- and 64-bit) */
>> > +       return false;
>> > +#endif
>> > +
>> >         if (!(rdev->flags & RADEON_IS_IGP))
>> >                 if (!radeon_card_posted(rdev))
>> >                         return false;
>> >
>> > --
>> > Meelis Roos (mroos@linux.ee)
>>
>
> --
> Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: [PATCH] only try to find radeon IGP ROM on X86
@ 2013-10-10 17:10                   ` Alex Deucher
  0 siblings, 0 replies; 62+ messages in thread
From: Alex Deucher @ 2013-10-10 17:10 UTC (permalink / raw)
  To: Meelis Roos; +Cc: sparclinux, David Miller, Maling list - DRI developers

On Thu, Oct 10, 2013 at 11:26 AM, Meelis Roos <mroos@linux.ee> wrote:
>> On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos <mroos@linux.ee> wrote:
>> > To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
>> > from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
>> > detection to move on to next problem.
>>
>> NACK.  All this function does it attempt to read the rom from the
>> framebuffer PCI BAR.  If you get hangs reading the BAR, then you have
>> larger problems on your platform.  Also, there are non-x86 platforms
>> that IGP chips which this may break.
>
> OK. But the code seems to just dereference addresses returned from
> ioremap, but to the best of my knowledge, these are not universally
> (like on each arch) safe to read without readb/readw/readl. Should I
> convert these to readb for test?

Yeah, that would be great.

Thanks,

Alex

>
>> > Signed-off-by: Meelis Roos <mroos@linux.ee>
>> >
>> > diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
>> > index 061b227..48ef97c 100644
>> > --- a/drivers/gpu/drm/radeon/radeon_bios.c
>> > +++ b/drivers/gpu/drm/radeon/radeon_bios.c
>> > @@ -49,6 +49,11 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
>> >         resource_size_t vram_base;
>> >         resource_size_t size = 256 * 1024; /* ??? */
>> >
>> > +#ifndef CONFIG_X86
>> > +       /* IGP only exists on X86 (32- and 64-bit) */
>> > +       return false;
>> > +#endif
>> > +
>> >         if (!(rdev->flags & RADEON_IS_IGP))
>> >                 if (!radeon_card_posted(rdev))
>> >                         return false;
>> >
>> > --
>> > Meelis Roos (mroos@linux.ee)
>>
>
> --
> Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2013-10-01  8:43                 ` Meelis Roos
@ 2014-04-04 20:52                   ` David Miller
  -1 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2014-04-04 20:52 UTC (permalink / raw)
  To: mroos; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

From: Meelis Roos <mroos@linux.ee>
Date: Tue, 1 Oct 2013 11:43:20 +0300 (EEST)

>> > > That looks quite strange. I guess the kernel should map the ROM at the
>> > > address OpenBoot/OF assigned to it. ( 10020000 ).
>> > 
>> > The address you see is a raw physical I/O address, which is a concatenation
>> > of the I/O window physical address for that PCI controller and the
>> > PCI bus assigned address.
>> > 
>> > This is what we store in the resource values.
>> > 
>> > The pci_assign_resource() path must have some bug that causes the
>> > resource values to be set incorrectly or similar.
>> > 
>> > Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
>> > before the pci_map_rom() call?
>> 
>> [drm] radeon_read_bios: pci_resource_start(ROM)\00001FF10020000
>> 
>> I am a little confused here. ROM addressis OK but after pci_map_rom it 
>> results in address that corresponds to another device?
> 
> I read more code and tried a couple of more things.
> 
> Using ofpci_debug=1 I get sensible output for scsi:
> 
> PCI: scan_bus[/pci@1f,0/pci@1] bus no 2
>   * /pci@1f,0/pci@1/scsi@1
>     create device, devfn: 8, type: scsi-2
>     class: 0x10000 device name: 0000:02:01.0
>     parse addresses (40 bytes) @ fffff8003fedc1c0
>   start: 1ff00002000, end: 1ff000020ff, i: 14
>   start: 1ff00010000, end: 1ff0001ffff, i: 30
>     adding to system ...
> 
> adding to system refers to pci_device_add(dev, bus) and that does not 
> modify the PCI bus available windows in any way, at least by my reafing 
> of the PCI code, so the PCI code does not know the resource ranges are 
> now busy?

I finally did some digging into this, and I think the issue is that
sparc needs to do pci_claim_resource() calls over all the PCI device
resources which are valid after we finish adding the PCI devices.

I'll try to follow up with a patch some time next week.

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2014-04-04 20:52                   ` David Miller
  0 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2014-04-04 20:52 UTC (permalink / raw)
  To: mroos; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

From: Meelis Roos <mroos@linux.ee>
Date: Tue, 1 Oct 2013 11:43:20 +0300 (EEST)

>> > > That looks quite strange. I guess the kernel should map the ROM at the
>> > > address OpenBoot/OF assigned to it. ( 10020000 ).
>> > 
>> > The address you see is a raw physical I/O address, which is a concatenation
>> > of the I/O window physical address for that PCI controller and the
>> > PCI bus assigned address.
>> > 
>> > This is what we store in the resource values.
>> > 
>> > The pci_assign_resource() path must have some bug that causes the
>> > resource values to be set incorrectly or similar.
>> > 
>> > Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
>> > before the pci_map_rom() call?
>> 
>> [drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000
>> 
>> I am a little confused here. ROM addressis OK but after pci_map_rom it 
>> results in address that corresponds to another device?
> 
> I read more code and tried a couple of more things.
> 
> Using ofpci_debug=1 I get sensible output for scsi:
> 
> PCI: scan_bus[/pci@1f,0/pci@1] bus no 2
>   * /pci@1f,0/pci@1/scsi@1
>     create device, devfn: 8, type: scsi-2
>     class: 0x10000 device name: 0000:02:01.0
>     parse addresses (40 bytes) @ fffff8003fedc1c0
>   start: 1ff00002000, end: 1ff000020ff, i: 14
>   start: 1ff00010000, end: 1ff0001ffff, i: 30
>     adding to system ...
> 
> adding to system refers to pci_device_add(dev, bus) and that does not 
> modify the PCI bus available windows in any way, at least by my reafing 
> of the PCI code, so the PCI code does not know the resource ranges are 
> now busy?

I finally did some digging into this, and I think the issue is that
sparc needs to do pci_claim_resource() calls over all the PCI device
resources which are valid after we finish adding the PCI devices.

I'll try to follow up with a patch some time next week.

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2014-04-04 20:52                   ` David Miller
@ 2014-08-13  6:30                     ` David Miller
  -1 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2014-08-13  6:30 UTC (permalink / raw)
  To: mroos; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

From: David Miller <davem@davemloft.net>
Date: Fri, 04 Apr 2014 16:52:02 -0400 (EDT)

> I'll try to follow up with a patch some time next week.

And next week became 4 months later, sorry :-/

Meelis, I've coded up a patch series that should take care of this
issue, which I'll post to sparclinux with you CC:'d right now.

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2014-08-13  6:30                     ` David Miller
  0 siblings, 0 replies; 62+ messages in thread
From: David Miller @ 2014-08-13  6:30 UTC (permalink / raw)
  To: mroos; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

From: David Miller <davem@davemloft.net>
Date: Fri, 04 Apr 2014 16:52:02 -0400 (EDT)

> I'll try to follow up with a patch some time next week.

And next week became 4 months later, sorry :-/

Meelis, I've coded up a patch series that should take care of this
issue, which I'll post to sparclinux with you CC:'d right now.

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2014-08-13  6:30                     ` David Miller
@ 2014-08-19 11:17                       ` Meelis Roos
  -1 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2014-08-19 11:17 UTC (permalink / raw)
  To: David Miller; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

> > I'll try to follow up with a patch some time next week.
> 
> And next week became 4 months later, sorry :-/
> 
> Meelis, I've coded up a patch series that should take care of this
> issue, which I'll post to sparclinux with you CC:'d right now.

Tested them yesterday.

PCI ROM allocation seems to be better now (ROM at 000001ff10020000) but 
r100 resources do not appear in /proc/iomem - at least when 
radeon.modeset=0 (maybe because it's unallocated for now).

dmesg shows r100 resource at start: 1ff10020000, end: 1ff1003ffff, i: 30
but lspci displays 32-bit address for ROM - is it correct? This lspci is 
from radeon.modeset=0 bootup.

        Region 0: Memory at 08000000 (32-bit, prefetchable) [disabled] [sizedM]
        Region 1: I/O ports at 0400 [disabled] [size%6]
        Region 2: Memory at 10000000 (32-bit, non-prefetchable) [disabled] [size2K]
        Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable)
        Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable)
        Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable)
        Expansion ROM at 10020000 [disabled] [size\x128K]



r100 init hangs in a different place. Original dmesg first, then my 
instrumented dmesg (seems to get further):

PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1 (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #56 Tue Aug 19 05:41:23 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits = 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87654 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3745K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign2, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1 (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #56 Tue Aug 19 05:41:23 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits = 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87654 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3745K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign2, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
Calibrating delay using timer specific routine.. 880.98 BogoMIPS (lpjD04947)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 16384 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 16384 bytes)
Initializing cgroup subsys net_cls
devtmpfs: initialized
NET: Registered protocol family 16
/pci@1f,0: PCI IO[1fe02000000] MEM[1ff00000000]
/pci@1f,0: SABRE PCI Bus Module ver[0:0]
PCI: Scanning PBM /pci@1f,0
sabre f005f9c0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1fe02000000-0x1fe02ffffff] (bus address [0x0000-0xffffff])
pci_bus 0000:00: root bus resource [mem 0x1ff00000000-0x1ffffffffff] (bus address [0x00000000-0xffffffff])
pci_bus 0000:00: root bus resource [bus 00-02]
PCI: scan_bus[/pci@1f,0] bus no 0
  * /pci@1f,0/pci@1,1
    create device, devfn: 9, type: pci
    class: 0x60400 device name: 0000:00:01.1
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1,1)
    Bridge bus range [1 --> 1]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:01
PCI: scan_bus[/pci@1f,0/pci@1,1] bus no 1
  * /pci@1f,0/pci@1,1/ebus@1
    create device, devfn: 8, type: 
    class: 0x68000 device name: 0000:01:01.0
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/network@1,1
    create device, devfn: 9, type: network
    class: 0x20000 device name: 0000:01:01.1
    parse addresses (20 bytes) @ ffffff003fee21c0
  start: 1ffe0000000, end: 1ffe000701f, i: 10
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/SUNW,m64B@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:01:02.0
    parse addresses (40 bytes) @ ffffff003fee0e40
  start: 1ffe1000000, end: 1ffe1ffffff, i: 10
  start: 1ffe2000000, end: 1ffe2000fff, i: 18
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/ide@3
    create device, devfn: 18, type: ide
    class: 0x1018f device name: 0000:01:03.0
    parse addresses (100 bytes) @ ffffff003feda400
  start: 1fe02c00000, end: 1fe02c00007, i: 10
  start: 1fe02c00008, end: 1fe02c0000b, i: 14
  start: 1fe02c00010, end: 1fe02c00017, i: 18
  start: 1fe02c00018, end: 1fe02c0001b, i: 1c
  start: 1fe02c00020, end: 1fe02c0002f, i: 20
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1
    create device, devfn: 8, type: pci
    class: 0x60400 device name: 0000:00:01.0
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1)
    Bridge bus range [2 --> 2]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:02
PCI: scan_bus[/pci@1f,0/pci@1] bus no 2
  * /pci@1f,0/pci@1/scsi@1
    create device, devfn: 8, type: scsi-2
    class: 0x10000 device name: 0000:02:01.0
    parse addresses (40 bytes) @ ffffff003febeac0
  start: 1ff00002000, end: 1ff000020ff, i: 14
  start: 1ff00010000, end: 1ff0001ffff, i: 30
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,XVR-100@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:02:02.0
    parse addresses (80 bytes) @ ffffff003febc8c0
  start: 1ff08000000, end: 1ff0bffffff, i: 10
  start: 1ff00000400, end: 1ff000004ff, i: 14
  start: 1ff10000000, end: 1ff10007fff, i: 18
  start: 1ff10020000, end: 1ff1003ffff, i: 30
    adding to system ...
pci 0000:02:02.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,m64B@3
    create device, devfn: 18, type: display
    class: 0x30000 device name: 0000:02:03.0
    parse addresses (60 bytes) @ ffffff003feba700
  start: 1ff11000000, end: 1ff11ffffff, i: 10
  start: 1ff12000000, end: 1ff12000fff, i: 18
  start: 1ff12020000, end: 1ff1203ffff, i: 30
    adding to system ...
pci 0000:02:03.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/FJSV,pgsb@4
    create device, devfn: 20, type: network
    class: 0x20000 device name: 0000:02:04.0
    parse addresses (20 bytes) @ ffffff003feb8740
  start: 1ff12040000, end: 1ff1204ffff, i: 10
    adding to system ...
pci 0000:02:04.0: PME# supported from D3hot
PCI: dev header type: 0
PCI: Claiming 0000:00:01.1: Resource 7: 000001fe02c00000..000001fe02ffffff [100]
PCI: Claiming 0000:00:01.1: Resource 8: 000001ffe0000000..000001ffffffffff [200]
PCI: Claiming 0000:00:01.0: Resource 7: 000001fe02000000..000001fe02bfffff [100]
PCI: Claiming 0000:00:01.0: Resource 8: 000001ff00000000..000001ffbfffffff [200]
pci 0000:00:01.0: can't claim BAR 8 [mem 0x1ff00000000-0x1ffbfffffff]: address conflict with Video RAM area [??? 0x1ff000a0000-0x1ff000bffff flags 0x80000000]
PCI: Claiming 0000:01:01.1: Resource 0: 000001ffe0000000..000001ffe000701f [200]
PCI: Claiming 0000:01:02.0: Resource 0: 000001ffe1000000..000001ffe1ffffff [200]
PCI: Claiming 0000:01:02.0: Resource 2: 000001ffe2000000..000001ffe2000fff [200]
PCI: Claiming 0000:01:03.0: Resource 0: 000001fe02c00000..000001fe02c00007 [101]
PCI: Claiming 0000:01:03.0: Resource 1: 000001fe02c00008..000001fe02c0000b [101]
PCI: Claiming 0000:01:03.0: Resource 2: 000001fe02c00010..000001fe02c00017 [101]
PCI: Claiming 0000:01:03.0: Resource 3: 000001fe02c00018..000001fe02c0001b [101]
PCI: Claiming 0000:01:03.0: Resource 4: 000001fe02c00020..000001fe02c0002f [101]
PCI: Claiming 0000:02:01.0: Resource 1: 000001ff00002000..000001ff000020ff [200]
PCI: Claiming 0000:02:01.0: Resource 6: 000001ff00010000..000001ff0001ffff [4c200]
PCI: Claiming 0000:02:02.0: Resource 0: 000001ff08000000..000001ff0bffffff [200]
PCI: Claiming 0000:02:02.0: Resource 1: 000001ff00000400..000001ff000004ff [200]
PCI: Claiming 0000:02:02.0: Resource 2: 000001ff10000000..000001ff10007fff [200]
PCI: Claiming 0000:02:02.0: Resource 6: 000001ff10020000..000001ff1003ffff [4c200]
PCI: Claiming 0000:02:03.0: Resource 0: 000001ff11000000..000001ff11ffffff [200]
PCI: Claiming 0000:02:03.0: Resource 2: 000001ff12000000..000001ff12000fff [200]
PCI: Claiming 0000:02:03.0: Resource 6: 000001ff12020000..000001ff1203ffff [4c200]
PCI: Claiming 0000:02:04.0: Resource 0: 000001ff12040000..000001ff1204ffff [204]
vgaarb: device added: PCI:0000:01:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:03.0,decodes=io+mem,owns=none,locks=none
vgaarb: loaded
vgaarb: no bridge control possible 0000:02:03.0
vgaarb: no bridge control possible 0000:02:02.0
vgaarb: bridge control possible 0000:01:02.0
SCSI subsystem initialized
/pci@1f,0/pci@1,1/ebus@1/eeprom@14,0: Mostek regs at 0x1fff1000000
AUXIO: Found device at /pci@1f,0/pci@1,1/ebus@1/auxio@14,726000
Switched to clocksource tick
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 1, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 1, 16384 bytes)
NET: Registered protocol family 1
PCI: CLS 64 bytes, default 64
power: Control reg at 1fff1724000
futex hash table entries: 256 (order: -1, 6144 bytes)
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 8192 bytes)
msgmni has been set to 2002
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
PCI: Enabling device: (0000:01:02.0), cmd 82
atyfb: 3D RAGE PRO (Mach64 GP, PQFP, PCI) [0x4750 rev 0x7c]
atyfb: 4M SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100 MHz XCLK
Console: switching to colour frame buffer device 80x30
atyfb: fb0: ATY Mach64 frame buffer device on PCI
PCI: Enabling device: (0000:02:03.0), cmd 82
atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27]
atyfb: 8M SGRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
atyfb: fb1: ATY Mach64 frame buffer device on PCI
/SUNW,ffb@1e,0: FFB at 000001fc00000000, type 51, DAC pnum[236e] rev[10] manuf_rev[1]
/pci@1f,0/pci@1,1/ebus@1/su@14,3083f8: Keyboard port at 1fff13083f8, irq 6
/pci@1f,0/pci@1,1/ebus@1/su@14,3062f8: Mouse port at 1fff13062f8, irq 7
f0061c64: ttyS0 at MMIO 0x1fff1400000 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
Console: ttyS0 (SAB82532)
console [ttyS0] enabled
[sched_delayed] sched: RT throttling activated
f0061c64: ttyS1 at MMIO 0x1fff1400040 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 2940 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

PCI: Enabling device: (0000:01:01.1), cmd 2
sunhme.c:v3.10 August 26, 2008 David S. Miller (davem@davemloft.net)
eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:9e:82:fd
mousedev: PS/2 mouse device common for all mice
scsi 0:0:0:0: Direct-Access     QUANTUM  ATLAS IV 18 WLS  0909 PQ: 0 ANSI: 3
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
scsi target0:0:0: Beginning Domain Validation
rtc-m48t59 rtc-m48t59.0: rtc core: registered m48t59 as rtc0
hidraw: raw HID events driver (C) Jiri Kosina
TCP: cubic registered
NET: Registered protocol family 17
Key type dns_resolver registered
rtc-m48t59 rtc-m48t59.0: setting system clock to 2014-08-19 07:01:12 UTC (1408431672)
scsi target0:0:0: wide asynchronous
scsi target0:0:0: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8)
scsi target0:0:0: Domain Validation skipping write tests
scsi target0:0:0: Ending Domain Validation
input: Sun Mouse as /devices/root/f005f9c0/f00601b4/f0061504/f0064df4/serio1/input/input1
sd 0:0:0:0: [sda] 35885168 512-byte logical blocks: (18.3 GB/17.1 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: e3 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
EXT4-fs (sda4): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (sda4): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:4.
devtmpfs: mounted
Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory
???????ɹ?????ѥ???
[info] Using makefile-style concurrent boot in runlevel S.
[....] Starting the hotplug events dispatcher: udevdsystemd-udevd[145]: starting version 204
[ ok .
[....] Synthesizing the initial hotplug events...[ ok done.
[....] Waiting for /dev to be fully populated...libata version 3.00 loaded.
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[drm] Initialized drm 1.1.0 20060810
scsi host1: pata_cmd64x
scsi host2: pata_cmd64x
ata1: PATA max MWDMA2 cmd 0x1fe02c00000 ctl 0x1fe02c00008 bmdma 0x1fe02c00020 irq 14
ata2: PATA max MWDMA2 cmd 0x1fe02c00010 ctl 0x1fe02c00018 bmdma 0x1fe02c00028 irq 14
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
PTP clock support registered
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
tg3.c:v3.137 (May 11, 2014)
PCI: Enabling device: (0000:02:04.0), cmd 2
tg3 0000:02:04.0 eth1: Tigon3 [partno(none) rev 1002] (PCI:33MHz:32-bit) MAC address 00:e0:00:a9:09:6a
tg3 0000:02:04.0 eth1: attached PHY is serdes (1000Base-SX Ethernet) (WireSpeed[0], EEE[0])
tg3 0000:02:04.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:02:04.0 eth1: dma_rwctrl[763f0000] dma_mask[32-bit]
[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

=================================
PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1-dirty (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #57 Tue Aug 19 13:49:13 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits = 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87652 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3746K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign2, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1-dirty (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #57 Tue Aug 19 13:49:13 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits = 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87652 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3746K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign2, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
Calibrating delay using timer specific routine.. 880.99 BogoMIPS (lpjD04994)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 16384 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 16384 bytes)
Initializing cgroup subsys net_cls
devtmpfs: initialized
NET: Registered protocol family 16
/pci@1f,0: PCI IO[1fe02000000] MEM[1ff00000000]
/pci@1f,0: SABRE PCI Bus Module ver[0:0]
PCI: Scanning PBM /pci@1f,0
pci_bus_add_resource_offset adding [io  0x1fe02000000-0x1fe02ffffff]
pci_bus_add_resource_offset adding [mem 0x1ff00000000-0x1ffffffffff]
pci_bus_add_resource_offset adding [bus 00-02]
sabre f005f9c0: PCI host bridge to bus 0000:00
pci_bus 0000:00: pci_bus_add_resource adding [io  0x1fe02000000-0x1fe02ffffff] with flags 0
pci_bus 0000:00: root bus resource [io  0x1fe02000000-0x1fe02ffffff] (bus address [0x0000-0xffffff])
pci_bus 0000:00: pci_bus_add_resource adding [mem 0x1ff00000000-0x1ffffffffff] with flags 0
pci_bus 0000:00: root bus resource [mem 0x1ff00000000-0x1ffffffffff] (bus address [0x00000000-0xffffffff])
pci_bus 0000:00: root bus resource [bus 00-02]
PCI: scan_bus[/pci@1f,0] bus no 0
  * /pci@1f,0/pci@1,1
    create device, devfn: 9, type: pci
    class: 0x60400 device name: 0000:00:01.1
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1,1)
    Bridge bus range [1 --> 1]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:01
PCI: scan_bus[/pci@1f,0/pci@1,1] bus no 1
  * /pci@1f,0/pci@1,1/ebus@1
    create device, devfn: 8, type: 
    class: 0x68000 device name: 0000:01:01.0
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/network@1,1
    create device, devfn: 9, type: network
    class: 0x20000 device name: 0000:01:01.1
    parse addresses (20 bytes) @ ffffff003fee21c0
  start: 1ffe0000000, end: 1ffe000701f, i: 10
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/SUNW,m64B@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:01:02.0
    parse addresses (40 bytes) @ ffffff003fee0e40
  start: 1ffe1000000, end: 1ffe1ffffff, i: 10
  start: 1ffe2000000, end: 1ffe2000fff, i: 18
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/ide@3
    create device, devfn: 18, type: ide
    class: 0x1018f device name: 0000:01:03.0
    parse addresses (100 bytes) @ ffffff003feda400
  start: 1fe02c00000, end: 1fe02c00007, i: 10
  start: 1fe02c00008, end: 1fe02c0000b, i: 14
  start: 1fe02c00010, end: 1fe02c00017, i: 18
  start: 1fe02c00018, end: 1fe02c0001b, i: 1c
  start: 1fe02c00020, end: 1fe02c0002f, i: 20
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1
    create device, devfn: 8, type: pci
    class: 0x60400 device name: 0000:00:01.0
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1)
    Bridge bus range [2 --> 2]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:02
PCI: scan_bus[/pci@1f,0/pci@1] bus no 2
  * /pci@1f,0/pci@1/scsi@1
    create device, devfn: 8, type: scsi-2
    class: 0x10000 device name: 0000:02:01.0
    parse addresses (40 bytes) @ ffffff003febeac0
  start: 1ff00002000, end: 1ff000020ff, i: 14
  start: 1ff00010000, end: 1ff0001ffff, i: 30
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,XVR-100@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:02:02.0
    parse addresses (80 bytes) @ ffffff003febc8c0
  start: 1ff08000000, end: 1ff0bffffff, i: 10
  start: 1ff00000400, end: 1ff000004ff, i: 14
  start: 1ff10000000, end: 1ff10007fff, i: 18
  start: 1ff10020000, end: 1ff1003ffff, i: 30
    adding to system ...
pci 0000:02:02.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,m64B@3
    create device, devfn: 18, type: display
    class: 0x30000 device name: 0000:02:03.0
    parse addresses (60 bytes) @ ffffff003feba700
  start: 1ff11000000, end: 1ff11ffffff, i: 10
  start: 1ff12000000, end: 1ff12000fff, i: 18
  start: 1ff12020000, end: 1ff1203ffff, i: 30
    adding to system ...
pci 0000:02:03.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/FJSV,pgsb@4
    create device, devfn: 20, type: network
    class: 0x20000 device name: 0000:02:04.0
    parse addresses (20 bytes) @ ffffff003feb8740
  start: 1ff12040000, end: 1ff1204ffff, i: 10
    adding to system ...
pci 0000:02:04.0: PME# supported from D3hot
PCI: dev header type: 0
PCI: Claiming 0000:00:01.1: Resource 7: 000001fe02c00000..000001fe02ffffff [100]
PCI: Claiming 0000:00:01.1: Resource 8: 000001ffe0000000..000001ffffffffff [200]
PCI: Claiming 0000:00:01.0: Resource 7: 000001fe02000000..000001fe02bfffff [100]
PCI: Claiming 0000:00:01.0: Resource 8: 000001ff00000000..000001ffbfffffff [200]
pci 0000:00:01.0: can't claim BAR 8 [mem 0x1ff00000000-0x1ffbfffffff]: address conflict with Video RAM area [??? 0x1ff000a0000-0x1ff000bffff flags 0x80000000]
PCI: Claiming 0000:01:01.1: Resource 0: 000001ffe0000000..000001ffe000701f [200]
PCI: Claiming 0000:01:02.0: Resource 0: 000001ffe1000000..000001ffe1ffffff [200]
PCI: Claiming 0000:01:02.0: Resource 2: 000001ffe2000000..000001ffe2000fff [200]
PCI: Claiming 0000:01:03.0: Resource 0: 000001fe02c00000..000001fe02c00007 [101]
PCI: Claiming 0000:01:03.0: Resource 1: 000001fe02c00008..000001fe02c0000b [101]
PCI: Claiming 0000:01:03.0: Resource 2: 000001fe02c00010..000001fe02c00017 [101]
PCI: Claiming 0000:01:03.0: Resource 3: 000001fe02c00018..000001fe02c0001b [101]
PCI: Claiming 0000:01:03.0: Resource 4: 000001fe02c00020..000001fe02c0002f [101]
PCI: Claiming 0000:02:01.0: Resource 1: 000001ff00002000..000001ff000020ff [200]
PCI: Claiming 0000:02:01.0: Resource 6: 000001ff00010000..000001ff0001ffff [4c200]
PCI: Claiming 0000:02:02.0: Resource 0: 000001ff08000000..000001ff0bffffff [200]
PCI: Claiming 0000:02:02.0: Resource 1: 000001ff00000400..000001ff000004ff [200]
PCI: Claiming 0000:02:02.0: Resource 2: 000001ff10000000..000001ff10007fff [200]
PCI: Claiming 0000:02:02.0: Resource 6: 000001ff10020000..000001ff1003ffff [4c200]
PCI: Claiming 0000:02:03.0: Resource 0: 000001ff11000000..000001ff11ffffff [200]
PCI: Claiming 0000:02:03.0: Resource 2: 000001ff12000000..000001ff12000fff [200]
PCI: Claiming 0000:02:03.0: Resource 6: 000001ff12020000..000001ff1203ffff [4c200]
PCI: Claiming 0000:02:04.0: Resource 0: 000001ff12040000..000001ff1204ffff [204]
vgaarb: device added: PCI:0000:01:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:03.0,decodes=io+mem,owns=none,locks=none
vgaarb: loaded
vgaarb: no bridge control possible 0000:02:03.0
vgaarb: no bridge control possible 0000:02:02.0
vgaarb: bridge control possible 0000:01:02.0
SCSI subsystem initialized
/pci@1f,0/pci@1,1/ebus@1/eeprom@14,0: Mostek regs at 0x1fff1000000
AUXIO: Found device at /pci@1f,0/pci@1,1/ebus@1/auxio@14,726000
Switched to clocksource tick
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 1, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 1, 16384 bytes)
NET: Registered protocol family 1
PCI: CLS 64 bytes, default 64
power: Control reg at 1fff1724000
futex hash table entries: 256 (order: -1, 6144 bytes)
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 8192 bytes)
msgmni has been set to 2002
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
PCI: Enabling device: (0000:01:02.0), cmd 82
atyfb: 3D RAGE PRO (Mach64 GP, PQFP, PCI) [0x4750 rev 0x7c]
atyfb: 4M SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100 MHz XCLK
Console: switching to colour frame buffer device 80x30
atyfb: fb0: ATY Mach64 frame buffer device on PCI
PCI: Enabling device: (0000:02:03.0), cmd 82
atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27]
atyfb: 8M SGRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
atyfb: fb1: ATY Mach64 frame buffer device on PCI
/SUNW,ffb@1e,0: FFB at 000001fc00000000, type 51, DAC pnum[236e] rev[10] manuf_rev[1]
/pci@1f,0/pci@1,1/ebus@1/su@14,3083f8: Keyboard port at 1fff13083f8, irq 6
/pci@1f,0/pci@1,1/ebus@1/su@14,3062f8: Mouse port at 1fff13062f8, irq 7
f0061c64: ttyS0 at MMIO 0x1fff1400000 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
Console: ttyS0 (SAB82532)
console [ttyS0] enabled
[sched_delayed] sched: RT throttling activated
f0061c64: ttyS1 at MMIO 0x1fff1400040 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
ioremap: 000001FF00002000, 0000000000000100
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 2940 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

PCI: Enabling device: (0000:01:01.1), cmd 2
sunhme.c:v3.10 August 26, 2008 David S. Miller (davem@davemloft.net)
ioremap: 000001FFE0000000, 0000000000008000
eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:9e:82:fd
mousedev: PS/2 mouse device common for all mice
ioremap: 000001FFF1000000, 0000000000002000
scsi 0:0:0:0: Direct-Access     QUANTUM  ATLAS IV 18 WLS  0909 PQ: 0 ANSI: 3
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
scsi target0:0:0: Beginning Domain Validation
rtc-m48t59 rtc-m48t59.0: rtc core: registered m48t59 as rtc0
hidraw: raw HID events driver (C) Jiri Kosina
TCP: cubic registered
NET: Registered protocol family 17
Key type dns_resolver registered
rtc-m48t59 rtc-m48t59.0: setting system clock to 2014-08-19 11:51:09 UTC (1408449069)
scsi target0:0:0: wide asynchronous
scsi target0:0:0: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8)
scsi target0:0:0: Domain Validation skipping write tests
scsi target0:0:0: Ending Domain Validation
input: Sun Mouse as /devices/root/f005f9c0/f00601b4/f0061504/f0064df4/serio1/input/input1
sd 0:0:0:0: [sda] 35885168 512-byte logical blocks: (18.3 GB/17.1 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: e3 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
EXT4-fs (sda4): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (sda4): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:4.
devtmpfs: mounted
Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory
version 2.88 booting
[info] Using makefile-style concurrent boot in runlevel S.
[....] Starting the hotplug events dispatcher: udevdsystemd-udevd[145]: starting version 204
[ ok .
[....] Synthesizing the initial hotplug events...[ ok done.
[....] Waiting for /dev to be fully populated...libata version 3.00 loaded.
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
tg3.c:v3.137 (May 11, 2014)
PCI: Enabling device: (0000:02:04.0), cmd 2
ioremap: 000001FF12040000, 0000000000010000
scsi host1: pata_cmd64x
scsi host2: pata_cmd64x
ata1: PATA max MWDMA2 cmd 0x1fe02c00000 ctl 0x1fe02c00008 bmdma 0x1fe02c00020 irq 14
ata2: PATA max MWDMA2 cmd 0x1fe02c00010 ctl 0x1fe02c00018 bmdma 0x1fe02c00028 irq 14
[drm] Initialized drm 1.1.0 20060810
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
tg3 0000:02:04.0 eth1: Tigon3 [partno(none) rev 1002] (PCI:33MHz:32-bit) MAC address 00:e0:00:a9:09:6a
tg3 0000:02:04.0 eth1: attached PHY is serdes (1000Base-SX Ethernet) (WireSpeed[0], EEE[0])
tg3 0000:02:04.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:02:04.0 eth1: dma_rwctrl[763f0000] dma_mask[32-bit]
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
random: nonblocking pool is initialized
[drm] radeon kernel modesetting enabled.
PCI: Enabling device: (0000:02:02.0), cmd 82
[drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908).
ioremap: 000001FF10000000, 0000000000008000
[drm] register mmio base: 0x000001FF10000000
[drm] register mmio size: 32768
[drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR
[drm] r100_init start
[drm] radeon_get_bios atrm
[drm] radeon_get_bios vfct
[drm] radeon_get_bios vram
[drm] radeon_get_bios read
[drm] radeon_read_bios 1
[drm] radeon_read_bios: pci_resource_start(ROM)\00001FF10020000
ioremap: 000001FF10020000, 0000000000020000
[drm] radeon_read_bios 2
[drm] radeon_read_bios 4, bios\00001ff10020000, pci_resource_start(ROM)\00001FF10020000, sizeF592
[drm] radeon_read_bios 5
iounmap: 000001ff10020000
[drm] radeon_read_bios 6
[drm] radeon_get_bios disabled
[drm] radeon_read_bios 1
[drm] radeon_read_bios: pci_resource_start(ROM)\00001FF10020000
ioremap: 000001FF10020000, 0000000000020000
[drm] radeon_read_bios 2
[drm] radeon_read_bios 4, bios\00001ff10020000, pci_resource_start(ROM)\00001FF10020000, sizeF592
[drm] radeon_read_bios 5
iounmap: 000001ff10020000
[drm] radeon_read_bios 6
[drm] radeon_get_bios platform
[drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
[drm] r100_init before AVIVO
[drm] r100_init before atom_bios
[drm] r100_init before combios init
[drm] r100_init after combios init 
[drm] r100_init before asic reset
[drm] r100_init before boot test post card
[drm] Using device-tree clock info
radeon 0000:02:02.0: VRAM: 64M 0x000001FF08000000 - 0x000001FF0BFFFFFF (64M used)
radeon 0000:02:02.0: GTT: 512M 0x000001FF0C000000 - 0x000001FF2BFFFFFF
[drm] Detected VRAM RAMdM, BARdM
[drm] RAM width 64bits DDR
[TTM] Zone  kernel: Available graphics memory: 512796 kiB
[TTM] Initializing pool allocator
[drm] radeon: 64M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 65536, num gpu pages 131072
[drm] PCI GART of 512M enabled (table at 0x00000000C1236000).
radeon 0000:02:02.0: WB disabled
radeon 0000:02:02.0: fence driver on ring 0 use gpu addr 0x000001ff0c000000 and cpu addr 0xffffff003c90c000
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Loading R100 Microcode
[drm] radeon: ring at 0x000001FF0C002000
[drm] r100_ring_test: 1
[drm] r100_ring_test: 2, r\00015e4d
[drm] r100_ring_test: 3

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2014-08-19 11:17                       ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2014-08-19 11:17 UTC (permalink / raw)
  To: David Miller; +Cc: oftedal, airlied, michel, sparclinux, dri-devel

> > I'll try to follow up with a patch some time next week.
> 
> And next week became 4 months later, sorry :-/
> 
> Meelis, I've coded up a patch series that should take care of this
> issue, which I'll post to sparclinux with you CC:'d right now.

Tested them yesterday.

PCI ROM allocation seems to be better now (ROM at 000001ff10020000) but 
r100 resources do not appear in /proc/iomem - at least when 
radeon.modeset=0 (maybe because it's unallocated for now).

dmesg shows r100 resource at start: 1ff10020000, end: 1ff1003ffff, i: 30
but lspci displays 32-bit address for ROM - is it correct? This lspci is 
from radeon.modeset=0 bootup.

        Region 0: Memory at 08000000 (32-bit, prefetchable) [disabled] [size=64M]
        Region 1: I/O ports at 0400 [disabled] [size=256]
        Region 2: Memory at 10000000 (32-bit, non-prefetchable) [disabled] [size=32K]
        Region 3: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable)
        Region 4: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable)
        Region 5: [virtual] Memory at fffffe0100000000 (32-bit, non-prefetchable)
        Expansion ROM at 10020000 [disabled] [size=128K]



r100 init hangs in a different place. Original dmesg first, then my 
instrumented dmesg (seems to get further):

PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1 (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #56 Tue Aug 19 05:41:23 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits == 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87654 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3745K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1 (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #56 Tue Aug 19 05:41:23 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits == 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87654 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3745K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
Calibrating delay using timer specific routine.. 880.98 BogoMIPS (lpj=4404947)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 16384 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 16384 bytes)
Initializing cgroup subsys net_cls
devtmpfs: initialized
NET: Registered protocol family 16
/pci@1f,0: PCI IO[1fe02000000] MEM[1ff00000000]
/pci@1f,0: SABRE PCI Bus Module ver[0:0]
PCI: Scanning PBM /pci@1f,0
sabre f005f9c0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1fe02000000-0x1fe02ffffff] (bus address [0x0000-0xffffff])
pci_bus 0000:00: root bus resource [mem 0x1ff00000000-0x1ffffffffff] (bus address [0x00000000-0xffffffff])
pci_bus 0000:00: root bus resource [bus 00-02]
PCI: scan_bus[/pci@1f,0] bus no 0
  * /pci@1f,0/pci@1,1
    create device, devfn: 9, type: pci
    class: 0x60400 device name: 0000:00:01.1
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1,1)
    Bridge bus range [1 --> 1]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:01
PCI: scan_bus[/pci@1f,0/pci@1,1] bus no 1
  * /pci@1f,0/pci@1,1/ebus@1
    create device, devfn: 8, type: 
    class: 0x68000 device name: 0000:01:01.0
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/network@1,1
    create device, devfn: 9, type: network
    class: 0x20000 device name: 0000:01:01.1
    parse addresses (20 bytes) @ ffffff003fee21c0
  start: 1ffe0000000, end: 1ffe000701f, i: 10
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/SUNW,m64B@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:01:02.0
    parse addresses (40 bytes) @ ffffff003fee0e40
  start: 1ffe1000000, end: 1ffe1ffffff, i: 10
  start: 1ffe2000000, end: 1ffe2000fff, i: 18
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/ide@3
    create device, devfn: 18, type: ide
    class: 0x1018f device name: 0000:01:03.0
    parse addresses (100 bytes) @ ffffff003feda400
  start: 1fe02c00000, end: 1fe02c00007, i: 10
  start: 1fe02c00008, end: 1fe02c0000b, i: 14
  start: 1fe02c00010, end: 1fe02c00017, i: 18
  start: 1fe02c00018, end: 1fe02c0001b, i: 1c
  start: 1fe02c00020, end: 1fe02c0002f, i: 20
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1
    create device, devfn: 8, type: pci
    class: 0x60400 device name: 0000:00:01.0
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1)
    Bridge bus range [2 --> 2]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:02
PCI: scan_bus[/pci@1f,0/pci@1] bus no 2
  * /pci@1f,0/pci@1/scsi@1
    create device, devfn: 8, type: scsi-2
    class: 0x10000 device name: 0000:02:01.0
    parse addresses (40 bytes) @ ffffff003febeac0
  start: 1ff00002000, end: 1ff000020ff, i: 14
  start: 1ff00010000, end: 1ff0001ffff, i: 30
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,XVR-100@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:02:02.0
    parse addresses (80 bytes) @ ffffff003febc8c0
  start: 1ff08000000, end: 1ff0bffffff, i: 10
  start: 1ff00000400, end: 1ff000004ff, i: 14
  start: 1ff10000000, end: 1ff10007fff, i: 18
  start: 1ff10020000, end: 1ff1003ffff, i: 30
    adding to system ...
pci 0000:02:02.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,m64B@3
    create device, devfn: 18, type: display
    class: 0x30000 device name: 0000:02:03.0
    parse addresses (60 bytes) @ ffffff003feba700
  start: 1ff11000000, end: 1ff11ffffff, i: 10
  start: 1ff12000000, end: 1ff12000fff, i: 18
  start: 1ff12020000, end: 1ff1203ffff, i: 30
    adding to system ...
pci 0000:02:03.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/FJSV,pgsb@4
    create device, devfn: 20, type: network
    class: 0x20000 device name: 0000:02:04.0
    parse addresses (20 bytes) @ ffffff003feb8740
  start: 1ff12040000, end: 1ff1204ffff, i: 10
    adding to system ...
pci 0000:02:04.0: PME# supported from D3hot
PCI: dev header type: 0
PCI: Claiming 0000:00:01.1: Resource 7: 000001fe02c00000..000001fe02ffffff [100]
PCI: Claiming 0000:00:01.1: Resource 8: 000001ffe0000000..000001ffffffffff [200]
PCI: Claiming 0000:00:01.0: Resource 7: 000001fe02000000..000001fe02bfffff [100]
PCI: Claiming 0000:00:01.0: Resource 8: 000001ff00000000..000001ffbfffffff [200]
pci 0000:00:01.0: can't claim BAR 8 [mem 0x1ff00000000-0x1ffbfffffff]: address conflict with Video RAM area [??? 0x1ff000a0000-0x1ff000bffff flags 0x80000000]
PCI: Claiming 0000:01:01.1: Resource 0: 000001ffe0000000..000001ffe000701f [200]
PCI: Claiming 0000:01:02.0: Resource 0: 000001ffe1000000..000001ffe1ffffff [200]
PCI: Claiming 0000:01:02.0: Resource 2: 000001ffe2000000..000001ffe2000fff [200]
PCI: Claiming 0000:01:03.0: Resource 0: 000001fe02c00000..000001fe02c00007 [101]
PCI: Claiming 0000:01:03.0: Resource 1: 000001fe02c00008..000001fe02c0000b [101]
PCI: Claiming 0000:01:03.0: Resource 2: 000001fe02c00010..000001fe02c00017 [101]
PCI: Claiming 0000:01:03.0: Resource 3: 000001fe02c00018..000001fe02c0001b [101]
PCI: Claiming 0000:01:03.0: Resource 4: 000001fe02c00020..000001fe02c0002f [101]
PCI: Claiming 0000:02:01.0: Resource 1: 000001ff00002000..000001ff000020ff [200]
PCI: Claiming 0000:02:01.0: Resource 6: 000001ff00010000..000001ff0001ffff [4c200]
PCI: Claiming 0000:02:02.0: Resource 0: 000001ff08000000..000001ff0bffffff [200]
PCI: Claiming 0000:02:02.0: Resource 1: 000001ff00000400..000001ff000004ff [200]
PCI: Claiming 0000:02:02.0: Resource 2: 000001ff10000000..000001ff10007fff [200]
PCI: Claiming 0000:02:02.0: Resource 6: 000001ff10020000..000001ff1003ffff [4c200]
PCI: Claiming 0000:02:03.0: Resource 0: 000001ff11000000..000001ff11ffffff [200]
PCI: Claiming 0000:02:03.0: Resource 2: 000001ff12000000..000001ff12000fff [200]
PCI: Claiming 0000:02:03.0: Resource 6: 000001ff12020000..000001ff1203ffff [4c200]
PCI: Claiming 0000:02:04.0: Resource 0: 000001ff12040000..000001ff1204ffff [204]
vgaarb: device added: PCI:0000:01:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:03.0,decodes=io+mem,owns=none,locks=none
vgaarb: loaded
vgaarb: no bridge control possible 0000:02:03.0
vgaarb: no bridge control possible 0000:02:02.0
vgaarb: bridge control possible 0000:01:02.0
SCSI subsystem initialized
/pci@1f,0/pci@1,1/ebus@1/eeprom@14,0: Mostek regs at 0x1fff1000000
AUXIO: Found device at /pci@1f,0/pci@1,1/ebus@1/auxio@14,726000
Switched to clocksource tick
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 1, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 1, 16384 bytes)
NET: Registered protocol family 1
PCI: CLS 64 bytes, default 64
power: Control reg at 1fff1724000
futex hash table entries: 256 (order: -1, 6144 bytes)
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 8192 bytes)
msgmni has been set to 2002
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
PCI: Enabling device: (0000:01:02.0), cmd 82
atyfb: 3D RAGE PRO (Mach64 GP, PQFP, PCI) [0x4750 rev 0x7c]
atyfb: 4M SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100 MHz XCLK
Console: switching to colour frame buffer device 80x30
atyfb: fb0: ATY Mach64 frame buffer device on PCI
PCI: Enabling device: (0000:02:03.0), cmd 82
atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27]
atyfb: 8M SGRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
atyfb: fb1: ATY Mach64 frame buffer device on PCI
/SUNW,ffb@1e,0: FFB at 000001fc00000000, type 51, DAC pnum[236e] rev[10] manuf_rev[1]
/pci@1f,0/pci@1,1/ebus@1/su@14,3083f8: Keyboard port at 1fff13083f8, irq 6
/pci@1f,0/pci@1,1/ebus@1/su@14,3062f8: Mouse port at 1fff13062f8, irq 7
f0061c64: ttyS0 at MMIO 0x1fff1400000 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
Console: ttyS0 (SAB82532)
console [ttyS0] enabled
[sched_delayed] sched: RT throttling activated
f0061c64: ttyS1 at MMIO 0x1fff1400040 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 2940 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

PCI: Enabling device: (0000:01:01.1), cmd 2
sunhme.c:v3.10 August 26, 2008 David S. Miller (davem@davemloft.net)
eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:9e:82:fd
mousedev: PS/2 mouse device common for all mice
scsi 0:0:0:0: Direct-Access     QUANTUM  ATLAS IV 18 WLS  0909 PQ: 0 ANSI: 3
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
scsi target0:0:0: Beginning Domain Validation
rtc-m48t59 rtc-m48t59.0: rtc core: registered m48t59 as rtc0
hidraw: raw HID events driver (C) Jiri Kosina
TCP: cubic registered
NET: Registered protocol family 17
Key type dns_resolver registered
rtc-m48t59 rtc-m48t59.0: setting system clock to 2014-08-19 07:01:12 UTC (1408431672)
scsi target0:0:0: wide asynchronous
scsi target0:0:0: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8)
scsi target0:0:0: Domain Validation skipping write tests
scsi target0:0:0: Ending Domain Validation
input: Sun Mouse as /devices/root/f005f9c0/f00601b4/f0061504/f0064df4/serio1/input/input1
sd 0:0:0:0: [sda] 35885168 512-byte logical blocks: (18.3 GB/17.1 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: e3 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
EXT4-fs (sda4): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (sda4): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:4.
devtmpfs: mounted
Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory
???????ɹ?????ѥ???
[info] Using makefile-style concurrent boot in runlevel S.
[....] Starting the hotplug events dispatcher: udevdsystemd-udevd[145]: starting version 204
[ ok .
[....] Synthesizing the initial hotplug events...[ ok done.
[....] Waiting for /dev to be fully populated...libata version 3.00 loaded.
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[drm] Initialized drm 1.1.0 20060810
scsi host1: pata_cmd64x
scsi host2: pata_cmd64x
ata1: PATA max MWDMA2 cmd 0x1fe02c00000 ctl 0x1fe02c00008 bmdma 0x1fe02c00020 irq 14
ata2: PATA max MWDMA2 cmd 0x1fe02c00010 ctl 0x1fe02c00018 bmdma 0x1fe02c00028 irq 14
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
PTP clock support registered
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
tg3.c:v3.137 (May 11, 2014)
PCI: Enabling device: (0000:02:04.0), cmd 2
tg3 0000:02:04.0 eth1: Tigon3 [partno(none) rev 1002] (PCI:33MHz:32-bit) MAC address 00:e0:00:a9:09:6a
tg3 0000:02:04.0 eth1: attached PHY is serdes (1000Base-SX Ethernet) (WireSpeed[0], EEE[0])
tg3 0000:02:04.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:02:04.0 eth1: dma_rwctrl[763f0000] dma_mask[32-bit]
[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

==================================================================
PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1-dirty (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #57 Tue Aug 19 13:49:13 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits == 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87652 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3746K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1-dirty (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #57 Tue Aug 19 13:49:13 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits == 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87652 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3746K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
Calibrating delay using timer specific routine.. 880.99 BogoMIPS (lpj=4404994)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 16384 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 16384 bytes)
Initializing cgroup subsys net_cls
devtmpfs: initialized
NET: Registered protocol family 16
/pci@1f,0: PCI IO[1fe02000000] MEM[1ff00000000]
/pci@1f,0: SABRE PCI Bus Module ver[0:0]
PCI: Scanning PBM /pci@1f,0
pci_bus_add_resource_offset adding [io  0x1fe02000000-0x1fe02ffffff]
pci_bus_add_resource_offset adding [mem 0x1ff00000000-0x1ffffffffff]
pci_bus_add_resource_offset adding [bus 00-02]
sabre f005f9c0: PCI host bridge to bus 0000:00
pci_bus 0000:00: pci_bus_add_resource adding [io  0x1fe02000000-0x1fe02ffffff] with flags 0
pci_bus 0000:00: root bus resource [io  0x1fe02000000-0x1fe02ffffff] (bus address [0x0000-0xffffff])
pci_bus 0000:00: pci_bus_add_resource adding [mem 0x1ff00000000-0x1ffffffffff] with flags 0
pci_bus 0000:00: root bus resource [mem 0x1ff00000000-0x1ffffffffff] (bus address [0x00000000-0xffffffff])
pci_bus 0000:00: root bus resource [bus 00-02]
PCI: scan_bus[/pci@1f,0] bus no 0
  * /pci@1f,0/pci@1,1
    create device, devfn: 9, type: pci
    class: 0x60400 device name: 0000:00:01.1
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1,1)
    Bridge bus range [1 --> 1]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:01
PCI: scan_bus[/pci@1f,0/pci@1,1] bus no 1
  * /pci@1f,0/pci@1,1/ebus@1
    create device, devfn: 8, type: 
    class: 0x68000 device name: 0000:01:01.0
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/network@1,1
    create device, devfn: 9, type: network
    class: 0x20000 device name: 0000:01:01.1
    parse addresses (20 bytes) @ ffffff003fee21c0
  start: 1ffe0000000, end: 1ffe000701f, i: 10
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/SUNW,m64B@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:01:02.0
    parse addresses (40 bytes) @ ffffff003fee0e40
  start: 1ffe1000000, end: 1ffe1ffffff, i: 10
  start: 1ffe2000000, end: 1ffe2000fff, i: 18
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/ide@3
    create device, devfn: 18, type: ide
    class: 0x1018f device name: 0000:01:03.0
    parse addresses (100 bytes) @ ffffff003feda400
  start: 1fe02c00000, end: 1fe02c00007, i: 10
  start: 1fe02c00008, end: 1fe02c0000b, i: 14
  start: 1fe02c00010, end: 1fe02c00017, i: 18
  start: 1fe02c00018, end: 1fe02c0001b, i: 1c
  start: 1fe02c00020, end: 1fe02c0002f, i: 20
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1
    create device, devfn: 8, type: pci
    class: 0x60400 device name: 0000:00:01.0
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1)
    Bridge bus range [2 --> 2]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:02
PCI: scan_bus[/pci@1f,0/pci@1] bus no 2
  * /pci@1f,0/pci@1/scsi@1
    create device, devfn: 8, type: scsi-2
    class: 0x10000 device name: 0000:02:01.0
    parse addresses (40 bytes) @ ffffff003febeac0
  start: 1ff00002000, end: 1ff000020ff, i: 14
  start: 1ff00010000, end: 1ff0001ffff, i: 30
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,XVR-100@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:02:02.0
    parse addresses (80 bytes) @ ffffff003febc8c0
  start: 1ff08000000, end: 1ff0bffffff, i: 10
  start: 1ff00000400, end: 1ff000004ff, i: 14
  start: 1ff10000000, end: 1ff10007fff, i: 18
  start: 1ff10020000, end: 1ff1003ffff, i: 30
    adding to system ...
pci 0000:02:02.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,m64B@3
    create device, devfn: 18, type: display
    class: 0x30000 device name: 0000:02:03.0
    parse addresses (60 bytes) @ ffffff003feba700
  start: 1ff11000000, end: 1ff11ffffff, i: 10
  start: 1ff12000000, end: 1ff12000fff, i: 18
  start: 1ff12020000, end: 1ff1203ffff, i: 30
    adding to system ...
pci 0000:02:03.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/FJSV,pgsb@4
    create device, devfn: 20, type: network
    class: 0x20000 device name: 0000:02:04.0
    parse addresses (20 bytes) @ ffffff003feb8740
  start: 1ff12040000, end: 1ff1204ffff, i: 10
    adding to system ...
pci 0000:02:04.0: PME# supported from D3hot
PCI: dev header type: 0
PCI: Claiming 0000:00:01.1: Resource 7: 000001fe02c00000..000001fe02ffffff [100]
PCI: Claiming 0000:00:01.1: Resource 8: 000001ffe0000000..000001ffffffffff [200]
PCI: Claiming 0000:00:01.0: Resource 7: 000001fe02000000..000001fe02bfffff [100]
PCI: Claiming 0000:00:01.0: Resource 8: 000001ff00000000..000001ffbfffffff [200]
pci 0000:00:01.0: can't claim BAR 8 [mem 0x1ff00000000-0x1ffbfffffff]: address conflict with Video RAM area [??? 0x1ff000a0000-0x1ff000bffff flags 0x80000000]
PCI: Claiming 0000:01:01.1: Resource 0: 000001ffe0000000..000001ffe000701f [200]
PCI: Claiming 0000:01:02.0: Resource 0: 000001ffe1000000..000001ffe1ffffff [200]
PCI: Claiming 0000:01:02.0: Resource 2: 000001ffe2000000..000001ffe2000fff [200]
PCI: Claiming 0000:01:03.0: Resource 0: 000001fe02c00000..000001fe02c00007 [101]
PCI: Claiming 0000:01:03.0: Resource 1: 000001fe02c00008..000001fe02c0000b [101]
PCI: Claiming 0000:01:03.0: Resource 2: 000001fe02c00010..000001fe02c00017 [101]
PCI: Claiming 0000:01:03.0: Resource 3: 000001fe02c00018..000001fe02c0001b [101]
PCI: Claiming 0000:01:03.0: Resource 4: 000001fe02c00020..000001fe02c0002f [101]
PCI: Claiming 0000:02:01.0: Resource 1: 000001ff00002000..000001ff000020ff [200]
PCI: Claiming 0000:02:01.0: Resource 6: 000001ff00010000..000001ff0001ffff [4c200]
PCI: Claiming 0000:02:02.0: Resource 0: 000001ff08000000..000001ff0bffffff [200]
PCI: Claiming 0000:02:02.0: Resource 1: 000001ff00000400..000001ff000004ff [200]
PCI: Claiming 0000:02:02.0: Resource 2: 000001ff10000000..000001ff10007fff [200]
PCI: Claiming 0000:02:02.0: Resource 6: 000001ff10020000..000001ff1003ffff [4c200]
PCI: Claiming 0000:02:03.0: Resource 0: 000001ff11000000..000001ff11ffffff [200]
PCI: Claiming 0000:02:03.0: Resource 2: 000001ff12000000..000001ff12000fff [200]
PCI: Claiming 0000:02:03.0: Resource 6: 000001ff12020000..000001ff1203ffff [4c200]
PCI: Claiming 0000:02:04.0: Resource 0: 000001ff12040000..000001ff1204ffff [204]
vgaarb: device added: PCI:0000:01:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:03.0,decodes=io+mem,owns=none,locks=none
vgaarb: loaded
vgaarb: no bridge control possible 0000:02:03.0
vgaarb: no bridge control possible 0000:02:02.0
vgaarb: bridge control possible 0000:01:02.0
SCSI subsystem initialized
/pci@1f,0/pci@1,1/ebus@1/eeprom@14,0: Mostek regs at 0x1fff1000000
AUXIO: Found device at /pci@1f,0/pci@1,1/ebus@1/auxio@14,726000
Switched to clocksource tick
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 1, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 1, 16384 bytes)
NET: Registered protocol family 1
PCI: CLS 64 bytes, default 64
power: Control reg at 1fff1724000
futex hash table entries: 256 (order: -1, 6144 bytes)
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 8192 bytes)
msgmni has been set to 2002
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
PCI: Enabling device: (0000:01:02.0), cmd 82
atyfb: 3D RAGE PRO (Mach64 GP, PQFP, PCI) [0x4750 rev 0x7c]
atyfb: 4M SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100 MHz XCLK
Console: switching to colour frame buffer device 80x30
atyfb: fb0: ATY Mach64 frame buffer device on PCI
PCI: Enabling device: (0000:02:03.0), cmd 82
atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27]
atyfb: 8M SGRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
atyfb: fb1: ATY Mach64 frame buffer device on PCI
/SUNW,ffb@1e,0: FFB at 000001fc00000000, type 51, DAC pnum[236e] rev[10] manuf_rev[1]
/pci@1f,0/pci@1,1/ebus@1/su@14,3083f8: Keyboard port at 1fff13083f8, irq 6
/pci@1f,0/pci@1,1/ebus@1/su@14,3062f8: Mouse port at 1fff13062f8, irq 7
f0061c64: ttyS0 at MMIO 0x1fff1400000 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
Console: ttyS0 (SAB82532)
console [ttyS0] enabled
[sched_delayed] sched: RT throttling activated
f0061c64: ttyS1 at MMIO 0x1fff1400040 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
ioremap: 000001FF00002000, 0000000000000100
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 2940 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

PCI: Enabling device: (0000:01:01.1), cmd 2
sunhme.c:v3.10 August 26, 2008 David S. Miller (davem@davemloft.net)
ioremap: 000001FFE0000000, 0000000000008000
eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:9e:82:fd
mousedev: PS/2 mouse device common for all mice
ioremap: 000001FFF1000000, 0000000000002000
scsi 0:0:0:0: Direct-Access     QUANTUM  ATLAS IV 18 WLS  0909 PQ: 0 ANSI: 3
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
scsi target0:0:0: Beginning Domain Validation
rtc-m48t59 rtc-m48t59.0: rtc core: registered m48t59 as rtc0
hidraw: raw HID events driver (C) Jiri Kosina
TCP: cubic registered
NET: Registered protocol family 17
Key type dns_resolver registered
rtc-m48t59 rtc-m48t59.0: setting system clock to 2014-08-19 11:51:09 UTC (1408449069)
scsi target0:0:0: wide asynchronous
scsi target0:0:0: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8)
scsi target0:0:0: Domain Validation skipping write tests
scsi target0:0:0: Ending Domain Validation
input: Sun Mouse as /devices/root/f005f9c0/f00601b4/f0061504/f0064df4/serio1/input/input1
sd 0:0:0:0: [sda] 35885168 512-byte logical blocks: (18.3 GB/17.1 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: e3 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
EXT4-fs (sda4): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (sda4): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:4.
devtmpfs: mounted
Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory
version 2.88 booting
[info] Using makefile-style concurrent boot in runlevel S.
[....] Starting the hotplug events dispatcher: udevdsystemd-udevd[145]: starting version 204
[ ok .
[....] Synthesizing the initial hotplug events...[ ok done.
[....] Waiting for /dev to be fully populated...libata version 3.00 loaded.
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
tg3.c:v3.137 (May 11, 2014)
PCI: Enabling device: (0000:02:04.0), cmd 2
ioremap: 000001FF12040000, 0000000000010000
scsi host1: pata_cmd64x
scsi host2: pata_cmd64x
ata1: PATA max MWDMA2 cmd 0x1fe02c00000 ctl 0x1fe02c00008 bmdma 0x1fe02c00020 irq 14
ata2: PATA max MWDMA2 cmd 0x1fe02c00010 ctl 0x1fe02c00018 bmdma 0x1fe02c00028 irq 14
[drm] Initialized drm 1.1.0 20060810
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
tg3 0000:02:04.0 eth1: Tigon3 [partno(none) rev 1002] (PCI:33MHz:32-bit) MAC address 00:e0:00:a9:09:6a
tg3 0000:02:04.0 eth1: attached PHY is serdes (1000Base-SX Ethernet) (WireSpeed[0], EEE[0])
tg3 0000:02:04.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:02:04.0 eth1: dma_rwctrl[763f0000] dma_mask[32-bit]
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
random: nonblocking pool is initialized
[drm] radeon kernel modesetting enabled.
PCI: Enabling device: (0000:02:02.0), cmd 82
[drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908).
ioremap: 000001FF10000000, 0000000000008000
[drm] register mmio base: 0x000001FF10000000
[drm] register mmio size: 32768
[drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR
[drm] r100_init start
[drm] radeon_get_bios atrm
[drm] radeon_get_bios vfct
[drm] radeon_get_bios vram
[drm] radeon_get_bios read
[drm] radeon_read_bios 1
[drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000
ioremap: 000001FF10020000, 0000000000020000
[drm] radeon_read_bios 2
[drm] radeon_read_bios 4, bios=000001ff10020000, pci_resource_start(ROM)=000001FF10020000, size=46592
[drm] radeon_read_bios 5
iounmap: 000001ff10020000
[drm] radeon_read_bios 6
[drm] radeon_get_bios disabled
[drm] radeon_read_bios 1
[drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000
ioremap: 000001FF10020000, 0000000000020000
[drm] radeon_read_bios 2
[drm] radeon_read_bios 4, bios=000001ff10020000, pci_resource_start(ROM)=000001FF10020000, size=46592
[drm] radeon_read_bios 5
iounmap: 000001ff10020000
[drm] radeon_read_bios 6
[drm] radeon_get_bios platform
[drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
[drm] r100_init before AVIVO
[drm] r100_init before atom_bios
[drm] r100_init before combios init
[drm] r100_init after combios init 
[drm] r100_init before asic reset
[drm] r100_init before boot test post card
[drm] Using device-tree clock info
radeon 0000:02:02.0: VRAM: 64M 0x000001FF08000000 - 0x000001FF0BFFFFFF (64M used)
radeon 0000:02:02.0: GTT: 512M 0x000001FF0C000000 - 0x000001FF2BFFFFFF
[drm] Detected VRAM RAM=64M, BAR=64M
[drm] RAM width 64bits DDR
[TTM] Zone  kernel: Available graphics memory: 512796 kiB
[TTM] Initializing pool allocator
[drm] radeon: 64M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 65536, num gpu pages 131072
[drm] PCI GART of 512M enabled (table at 0x00000000C1236000).
radeon 0000:02:02.0: WB disabled
radeon 0000:02:02.0: fence driver on ring 0 use gpu addr 0x000001ff0c000000 and cpu addr 0xffffff003c90c000
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Loading R100 Microcode
[drm] radeon: ring at 0x000001FF0C002000
[drm] r100_ring_test: 1
[drm] r100_ring_test: 2, r=000015e4d
[drm] r100_ring_test: 3

-- 
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

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2014-08-19 11:17                       ` Meelis Roos
@ 2014-08-25 14:48                         ` Meelis Roos
  -1 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2014-08-25 14:48 UTC (permalink / raw)
  To: David Miller; +Cc: sparclinux, michel, oftedal, dri-devel

> r100 init hangs in a different place. Original dmesg first, then my 
> instrumented dmesg (seems to get further):

The instrumented dmesg had a couple of my local test changes and was 
bad now that I had ROM. Reverted them exept my readb changes (instead 
of direct dereferences of iomapped space) and redid 
logging to be more precise.

> [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

This was still the unchanged kernel hanging.

Below is a new debug log to pinpoint the hang. It seems to hang in 
r100_gfx_get_rptr but not on first try.

Where should I look next?

PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1-dirty (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #59 Tue Aug 19 22:26:05 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits = 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87652 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3745K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign2, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1-dirty (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #59 Tue Aug 19 22:26:05 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits = 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87652 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3745K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign2, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
Calibrating delay using timer specific routine.. 880.99 BogoMIPS (lpjD04994)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 16384 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 16384 bytes)
Initializing cgroup subsys net_cls
devtmpfs: initialized
NET: Registered protocol family 16
/pci@1f,0: PCI IO[1fe02000000] MEM[1ff00000000]
/pci@1f,0: SABRE PCI Bus Module ver[0:0]
PCI: Scanning PBM /pci@1f,0
sabre f005f9c0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1fe02000000-0x1fe02ffffff] (bus address [0x0000-0xffffff])
pci_bus 0000:00: root bus resource [mem 0x1ff00000000-0x1ffffffffff] (bus address [0x00000000-0xffffffff])
pci_bus 0000:00: root bus resource [bus 00-02]
PCI: scan_bus[/pci@1f,0] bus no 0
  * /pci@1f,0/pci@1,1
    create device, devfn: 9, type: pci
    class: 0x60400 device name: 0000:00:01.1
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1,1)
    Bridge bus range [1 --> 1]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:01
PCI: scan_bus[/pci@1f,0/pci@1,1] bus no 1
  * /pci@1f,0/pci@1,1/ebus@1
    create device, devfn: 8, type: 
    class: 0x68000 device name: 0000:01:01.0
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/network@1,1
    create device, devfn: 9, type: network
    class: 0x20000 device name: 0000:01:01.1
    parse addresses (20 bytes) @ ffffff003fee21c0
  start: 1ffe0000000, end: 1ffe000701f, i: 10
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/SUNW,m64B@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:01:02.0
    parse addresses (40 bytes) @ ffffff003fee0e40
  start: 1ffe1000000, end: 1ffe1ffffff, i: 10
  start: 1ffe2000000, end: 1ffe2000fff, i: 18
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/ide@3
    create device, devfn: 18, type: ide
    class: 0x1018f device name: 0000:01:03.0
    parse addresses (100 bytes) @ ffffff003feda400
  start: 1fe02c00000, end: 1fe02c00007, i: 10
  start: 1fe02c00008, end: 1fe02c0000b, i: 14
  start: 1fe02c00010, end: 1fe02c00017, i: 18
  start: 1fe02c00018, end: 1fe02c0001b, i: 1c
  start: 1fe02c00020, end: 1fe02c0002f, i: 20
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1
    create device, devfn: 8, type: pci
    class: 0x60400 device name: 0000:00:01.0
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1)
    Bridge bus range [2 --> 2]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:02
PCI: scan_bus[/pci@1f,0/pci@1] bus no 2
  * /pci@1f,0/pci@1/scsi@1
    create device, devfn: 8, type: scsi-2
    class: 0x10000 device name: 0000:02:01.0
    parse addresses (40 bytes) @ ffffff003febeac0
  start: 1ff00002000, end: 1ff000020ff, i: 14
  start: 1ff00010000, end: 1ff0001ffff, i: 30
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,XVR-100@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:02:02.0
    parse addresses (80 bytes) @ ffffff003febc8c0
  start: 1ff08000000, end: 1ff0bffffff, i: 10
  start: 1ff00000400, end: 1ff000004ff, i: 14
  start: 1ff10000000, end: 1ff10007fff, i: 18
  start: 1ff10020000, end: 1ff1003ffff, i: 30
    adding to system ...
pci 0000:02:02.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,m64B@3
    create device, devfn: 18, type: display
    class: 0x30000 device name: 0000:02:03.0
    parse addresses (60 bytes) @ ffffff003feba700
  start: 1ff11000000, end: 1ff11ffffff, i: 10
  start: 1ff12000000, end: 1ff12000fff, i: 18
  start: 1ff12020000, end: 1ff1203ffff, i: 30
    adding to system ...
pci 0000:02:03.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/FJSV,pgsb@4
    create device, devfn: 20, type: network
    class: 0x20000 device name: 0000:02:04.0
    parse addresses (20 bytes) @ ffffff003feb8740
  start: 1ff12040000, end: 1ff1204ffff, i: 10
    adding to system ...
pci 0000:02:04.0: PME# supported from D3hot
PCI: dev header type: 0
PCI: Claiming 0000:00:01.1: Resource 7: 000001fe02c00000..000001fe02ffffff [100]
PCI: Claiming 0000:00:01.1: Resource 8: 000001ffe0000000..000001ffffffffff [200]
PCI: Claiming 0000:00:01.0: Resource 7: 000001fe02000000..000001fe02bfffff [100]
PCI: Claiming 0000:00:01.0: Resource 8: 000001ff00000000..000001ffbfffffff [200]
pci 0000:00:01.0: can't claim BAR 8 [mem 0x1ff00000000-0x1ffbfffffff]: address conflict with Video RAM area [??? 0x1ff000a0000-0x1ff000bffff flags 0x80000000]
PCI: Claiming 0000:01:01.1: Resource 0: 000001ffe0000000..000001ffe000701f [200]
PCI: Claiming 0000:01:02.0: Resource 0: 000001ffe1000000..000001ffe1ffffff [200]
PCI: Claiming 0000:01:02.0: Resource 2: 000001ffe2000000..000001ffe2000fff [200]
PCI: Claiming 0000:01:03.0: Resource 0: 000001fe02c00000..000001fe02c00007 [101]
PCI: Claiming 0000:01:03.0: Resource 1: 000001fe02c00008..000001fe02c0000b [101]
PCI: Claiming 0000:01:03.0: Resource 2: 000001fe02c00010..000001fe02c00017 [101]
PCI: Claiming 0000:01:03.0: Resource 3: 000001fe02c00018..000001fe02c0001b [101]
PCI: Claiming 0000:01:03.0: Resource 4: 000001fe02c00020..000001fe02c0002f [101]
PCI: Claiming 0000:02:01.0: Resource 1: 000001ff00002000..000001ff000020ff [200]
PCI: Claiming 0000:02:01.0: Resource 6: 000001ff00010000..000001ff0001ffff [4c200]
PCI: Claiming 0000:02:02.0: Resource 0: 000001ff08000000..000001ff0bffffff [200]
PCI: Claiming 0000:02:02.0: Resource 1: 000001ff00000400..000001ff000004ff [200]
PCI: Claiming 0000:02:02.0: Resource 2: 000001ff10000000..000001ff10007fff [200]
PCI: Claiming 0000:02:02.0: Resource 6: 000001ff10020000..000001ff1003ffff [4c200]
PCI: Claiming 0000:02:03.0: Resource 0: 000001ff11000000..000001ff11ffffff [200]
PCI: Claiming 0000:02:03.0: Resource 2: 000001ff12000000..000001ff12000fff [200]
PCI: Claiming 0000:02:03.0: Resource 6: 000001ff12020000..000001ff1203ffff [4c200]
PCI: Claiming 0000:02:04.0: Resource 0: 000001ff12040000..000001ff1204ffff [204]
vgaarb: device added: PCI:0000:01:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:03.0,decodes=io+mem,owns=none,locks=none
vgaarb: loaded
vgaarb: no bridge control possible 0000:02:03.0
vgaarb: no bridge control possible 0000:02:02.0
vgaarb: bridge control possible 0000:01:02.0
SCSI subsystem initialized
/pci@1f,0/pci@1,1/ebus@1/eeprom@14,0: Mostek regs at 0x1fff1000000
AUXIO: Found device at /pci@1f,0/pci@1,1/ebus@1/auxio@14,726000
Switched to clocksource tick
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 1, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 1, 16384 bytes)
NET: Registered protocol family 1
PCI: CLS 64 bytes, default 64
power: Control reg at 1fff1724000
futex hash table entries: 256 (order: -1, 6144 bytes)
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 8192 bytes)
msgmni has been set to 2002
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
PCI: Enabling device: (0000:01:02.0), cmd 82
atyfb: 3D RAGE PRO (Mach64 GP, PQFP, PCI) [0x4750 rev 0x7c]
atyfb: 4M SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100 MHz XCLK
Console: switching to colour frame buffer device 80x30
atyfb: fb0: ATY Mach64 frame buffer device on PCI
PCI: Enabling device: (0000:02:03.0), cmd 82
atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27]
atyfb: 8M SGRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
atyfb: fb1: ATY Mach64 frame buffer device on PCI
/SUNW,ffb@1e,0: FFB at 000001fc00000000, type 51, DAC pnum[236e] rev[10] manuf_rev[1]
/pci@1f,0/pci@1,1/ebus@1/su@14,3083f8: Keyboard port at 1fff13083f8, irq 6
/pci@1f,0/pci@1,1/ebus@1/su@14,3062f8: Mouse port at 1fff13062f8, irq 7
f0061c64: ttyS0 at MMIO 0x1fff1400000 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
Console: ttyS0 (SAB82532)
console [ttyS0] enabled
[sched_delayed] sched: RT throttling activated
f0061c64: ttyS1 at MMIO 0x1fff1400040 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 2940 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

PCI: Enabling device: (0000:01:01.1), cmd 2
sunhme.c:v3.10 August 26, 2008 David S. Miller (davem@davemloft.net)
eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:9e:82:fd
mousedev: PS/2 mouse device common for all mice
scsi 0:0:0:0: Direct-Access     QUANTUM  ATLAS IV 18 WLS  0909 PQ: 0 ANSI: 3
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
scsi target0:0:0: Beginning Domain Validation
rtc-m48t59 rtc-m48t59.0: rtc core: registered m48t59 as rtc0
hidraw: raw HID events driver (C) Jiri Kosina
TCP: cubic registered
NET: Registered protocol family 17
Key type dns_resolver registered
rtc-m48t59 rtc-m48t59.0: setting system clock to 2014-08-21 11:11:22 UTC (1408619482)
scsi target0:0:0: wide asynchronous
scsi target0:0:0: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8)
scsi target0:0:0: Domain Validation skipping write tests
scsi target0:0:0: Ending Domain Validation
input: Sun Mouse as /devices/root/f005f9c0/f00601b4/f0061504/f0064df4/serio1/input/input1
sd 0:0:0:0: [sda] 35885168 512-byte logical blocks: (18.3 GB/17.1 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: e3 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
EXT4-fs (sda4): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (sda4): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (sda4): INFO: recovery required on readonly filesystem
EXT4-fs (sda4): write access will be enabled during recovery
EXT4-fs (sda4): orphan cleanup on readonly fs
EXT4-fs (sda4): 4 orphan inodes deleted
EXT4-fs (sda4): recovery complete
EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:4.
devtmpfs: mounted
Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory
???????ɹ?????ѥ???
[info] Using makefile-style concurrent boot in runlevel S.
[....] Starting the hotplug events dispatcher: udevdsystemd-udevd[145]: starting version 204
[ ok .
[.random: nonblocking pool is initialized
...] Synthesizing the initial hotplug events...[ ok done.
[....] Waiting for /dev to be fully populated...pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[drm] Initialized drm 1.1.0 20060810
libata version 3.00 loaded.
scsi host1: pata_cmd64x
PTP clock support registered
scsi host2: pata_cmd64x
ata1: PATA max MWDMA2 cmd 0x1fe02c00000 ctl 0x1fe02c00008 bmdma 0x1fe02c00020 irq 14
ata2: PATA max MWDMA2 cmd 0x1fe02c00010 ctl 0x1fe02c00018 bmdma 0x1fe02c00028 irq 14
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
tg3.c:v3.137 (May 11, 2014)
PCI: Enabling device: (0000:02:04.0), cmd 2
tg3 0000:02:04.0 eth1: Tigon3 [partno(none) rev 1002] (PCI:33MHz:32-bit) MAC address 00:e0:00:a9:09:6a
tg3 0000:02:04.0 eth1: attached PHY is serdes (1000Base-SX Ethernet) (WireSpeed[0], EEE[0])
tg3 0000:02:04.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:02:04.0 eth1: dma_rwctrl[763f0000] dma_mask[32-bit]
[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] r100_init start
[drm] r100_init before render disable
[drm] r100_init before scratch
[drm] r100_init before surface
[drm] r100_init before sanity restore
[drm] r100_init before get_gios
[drm] radeon_get_bios atrm
[drm] radeon_get_bios vfct
[drm] radeon_get_bios vram
[drm] radeon_get_bios read
[drm] radeon_read_bios 1
[drm] radeon_read_bios: pci_resource_start(ROM)\00001FF10020000
[drm] radeon_read_bios 2
[drm] radeon_read_bios 4, bios\00001ff10020000, pci_resource_start(ROM)\00001FF10020000, sizeF592
[drm] radeon_read_bios: found ROM signature at 000001ff10020000
[drm] radeon_read_bios 7: bios\00001ff10020000, sizeF592
[drm] mydup done!
[drm] radeon_read_bios 8
[drm] radeon_read_bios b
[drm] radeon_read_bios c
[drm] radeon_get_bios disabled
[drm] radeon_get_bios platform
[drm] Not an x86 BIOS ROM, not using.
[drm] r100_init before AVIVO
[drm] r100_init before atom_bios
[drm] r100_init before combios init
[drm] r100_init after combios init 
[drm] r100_init before asic reset
[drm] r100_init before boot test post card
[drm] Using device-tree clock info
radeon 0000:02:02.0: VRAM: 64M 0x000001FF08000000 - 0x000001FF0BFFFFFF (64M used)
radeon 0000:02:02.0: GTT: 512M 0x000001FF0C000000 - 0x000001FF2BFFFFFF
[drm] Detected VRAM RAMdM, BARdM
[drm] RAM width 64bits DDR
[TTM] Zone  kernel: Available graphics memory: 512796 kiB
[TTM] Initializing pool allocator
[drm] radeon: 64M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 65536, num gpu pages 131072
[drm] PCI GART of 512M enabled (table at 0x00000000C1F9E000).
radeon 0000:02:02.0: WB disabled
radeon 0000:02:02.0: fence driver on ring 0 use gpu addr 0x000001ff0c000000 and cpu addr 0xffffff003c00a000
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Loading R100 Microcode
[drm] radeon_ring_lockup_update start
[drm] r100_gfx_get_rptr start
[drm] r100_gfx_get_rptr case 2
[drm] r100_gfx_get_rptr end
[drm] radeon_ring_lockup_update middle
[drm] radeon_ring_lockup_update end
[drm] radeon: ring at 0x000001FF0C002000
[drm] radeon_ring_lock start
[drm] radeon_ring_lock got mutex
[drm] radeon_ring_alloc start
[drm] radeon_ring_alloc before radeon_ring_free_size
[drm] radeon_ring_free_size before radeon_ring_get_rptr
[drm] r100_gfx_get_rptr start
[drm] r100_gfx_get_rptr case 2
[drm] r100_gfx_get_rptr end
[drm] radeon_ring_free_size after radeon_ring_get_rptr
[drm] radeon_ring_free_size before radeon_ring_lockup_update
[drm] radeon_ring_lockup_update start
[drm] r100_gfx_get_rptr start
[drm] r100_gfx_get_rptr case 2
[drm] r100_gfx_get_rptr end
[drm] radeon_ring_lockup_update middle
[drm] radeon_ring_lockup_update end
[drm] radeon_ring_alloc after radeon_ring_free_size
[drm] radeon_ring_alloc end
[drm] radeon_ring_lock after alloc, r=0
[drm] radeon_ring_lock end (locked)
[drm] radeon_ring_unlock_commit unlocking
[drm] r100_ring_test start
[drm] r100_ring_test: after radeon_scratch_get, r\0000000d
[drm] r100_ring_test before radeon_ring_lock
[drm] radeon_ring_lock start
[drm] radeon_ring_lock got mutex
[drm] radeon_ring_alloc start
[drm] radeon_ring_alloc before radeon_ring_free_size
[drm] radeon_ring_free_size before radeon_ring_get_rptr
[drm] r100_gfx_get_rptr start
[drm] r100_gfx_get_rptr case 2

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2014-08-25 14:48                         ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2014-08-25 14:48 UTC (permalink / raw)
  To: David Miller; +Cc: sparclinux, michel, oftedal, dri-devel

> r100 init hangs in a different place. Original dmesg first, then my 
> instrumented dmesg (seems to get further):

The instrumented dmesg had a couple of my local test changes and was 
bad now that I had ROM. Reverted them exept my readb changes (instead 
of direct dereferences of iomapped space) and redid 
logging to be more precise.

> [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

This was still the unchanged kernel hanging.

Below is a new debug log to pinpoint the hang. It seems to hang in 
r100_gfx_get_rptr but not on first try.

Where should I look next?

PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1-dirty (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #59 Tue Aug 19 22:26:05 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits == 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87652 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3745K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
PROMLIB: Root node compatible: 
Initializing cgroup subsys cpu
Linux version 3.17.0-rc1-dirty (mroos@u10) (gcc version 4.6.4 (Debian 4.6.4-4) ) #59 Tue Aug 19 22:26:05 EEST 2014
debug: ignoring loglevel setting.
bootconsole [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:9e:82:fd
PAGE_OFFSET is 0xffffff0000000000 (max_phys_bits == 40)
Kernel: Using 3 locked TLB entries for main kernel image.
Remapping the kernel... done.
OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a
PROM: Built device tree with 87652 bytes of memory.
Top of RAM: 0x3fef0000, Total RAM: 0x3fee0000
Memory hole size: 0MB
Zone ranges:
  Normal   [mem 0x00000000-0x3feeffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00000000-0x3fec9fff]
  node   0: [mem 0x3feda000-0x3feeffff]
On node 0 totalpages: 130928
  Normal zone: 1023 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 130928 pages, LIFO batch:15
Booting Linux...
CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
CPU CAPS: [vis]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129905
Kernel command line: root=/dev/sda4 ro debug ignore_loglevel ofpci_debug=1 radeon.modeset=1
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Sorting __ex_table...
Memory: 1025424K/1047424K available (3745K kernel code, 319K rwdata, 1064K rodata, 168K init, 6562K bss, 22000K reserved)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:255
clocksource: mult[245d174] shift[24]
clockevent: mult[70a3d70a] shift[32]
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [earlyprom0] disabled
Calibrating delay using timer specific routine.. 880.99 BogoMIPS (lpj=4404994)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 16384 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 16384 bytes)
Initializing cgroup subsys net_cls
devtmpfs: initialized
NET: Registered protocol family 16
/pci@1f,0: PCI IO[1fe02000000] MEM[1ff00000000]
/pci@1f,0: SABRE PCI Bus Module ver[0:0]
PCI: Scanning PBM /pci@1f,0
sabre f005f9c0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1fe02000000-0x1fe02ffffff] (bus address [0x0000-0xffffff])
pci_bus 0000:00: root bus resource [mem 0x1ff00000000-0x1ffffffffff] (bus address [0x00000000-0xffffffff])
pci_bus 0000:00: root bus resource [bus 00-02]
PCI: scan_bus[/pci@1f,0] bus no 0
  * /pci@1f,0/pci@1,1
    create device, devfn: 9, type: pci
    class: 0x60400 device name: 0000:00:01.1
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1,1)
    Bridge bus range [1 --> 1]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:01
PCI: scan_bus[/pci@1f,0/pci@1,1] bus no 1
  * /pci@1f,0/pci@1,1/ebus@1
    create device, devfn: 8, type: 
    class: 0x68000 device name: 0000:01:01.0
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/network@1,1
    create device, devfn: 9, type: network
    class: 0x20000 device name: 0000:01:01.1
    parse addresses (20 bytes) @ ffffff003fee21c0
  start: 1ffe0000000, end: 1ffe000701f, i: 10
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/SUNW,m64B@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:01:02.0
    parse addresses (40 bytes) @ ffffff003fee0e40
  start: 1ffe1000000, end: 1ffe1ffffff, i: 10
  start: 1ffe2000000, end: 1ffe2000fff, i: 18
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1,1/ide@3
    create device, devfn: 18, type: ide
    class: 0x1018f device name: 0000:01:03.0
    parse addresses (100 bytes) @ ffffff003feda400
  start: 1fe02c00000, end: 1fe02c00007, i: 10
  start: 1fe02c00008, end: 1fe02c0000b, i: 14
  start: 1fe02c00010, end: 1fe02c00017, i: 18
  start: 1fe02c00018, end: 1fe02c0001b, i: 1c
  start: 1fe02c00020, end: 1fe02c0002f, i: 20
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1
    create device, devfn: 8, type: pci
    class: 0x60400 device name: 0000:00:01.0
    adding to system ...
PCI: dev header type: 1
of_scan_pci_bridge(/pci@1f,0/pci@1)
    Bridge bus range [2 --> 2]
    Bridge ranges[          (null)] simba[1]
    bus name: PCI Bus 0000:02
PCI: scan_bus[/pci@1f,0/pci@1] bus no 2
  * /pci@1f,0/pci@1/scsi@1
    create device, devfn: 8, type: scsi-2
    class: 0x10000 device name: 0000:02:01.0
    parse addresses (40 bytes) @ ffffff003febeac0
  start: 1ff00002000, end: 1ff000020ff, i: 14
  start: 1ff00010000, end: 1ff0001ffff, i: 30
    adding to system ...
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,XVR-100@2
    create device, devfn: 10, type: display
    class: 0x30000 device name: 0000:02:02.0
    parse addresses (80 bytes) @ ffffff003febc8c0
  start: 1ff08000000, end: 1ff0bffffff, i: 10
  start: 1ff00000400, end: 1ff000004ff, i: 14
  start: 1ff10000000, end: 1ff10007fff, i: 18
  start: 1ff10020000, end: 1ff1003ffff, i: 30
    adding to system ...
pci 0000:02:02.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/SUNW,m64B@3
    create device, devfn: 18, type: display
    class: 0x30000 device name: 0000:02:03.0
    parse addresses (60 bytes) @ ffffff003feba700
  start: 1ff11000000, end: 1ff11ffffff, i: 10
  start: 1ff12000000, end: 1ff12000fff, i: 18
  start: 1ff12020000, end: 1ff1203ffff, i: 30
    adding to system ...
pci 0000:02:03.0: supports D1 D2
PCI: dev header type: 0
  * /pci@1f,0/pci@1/FJSV,pgsb@4
    create device, devfn: 20, type: network
    class: 0x20000 device name: 0000:02:04.0
    parse addresses (20 bytes) @ ffffff003feb8740
  start: 1ff12040000, end: 1ff1204ffff, i: 10
    adding to system ...
pci 0000:02:04.0: PME# supported from D3hot
PCI: dev header type: 0
PCI: Claiming 0000:00:01.1: Resource 7: 000001fe02c00000..000001fe02ffffff [100]
PCI: Claiming 0000:00:01.1: Resource 8: 000001ffe0000000..000001ffffffffff [200]
PCI: Claiming 0000:00:01.0: Resource 7: 000001fe02000000..000001fe02bfffff [100]
PCI: Claiming 0000:00:01.0: Resource 8: 000001ff00000000..000001ffbfffffff [200]
pci 0000:00:01.0: can't claim BAR 8 [mem 0x1ff00000000-0x1ffbfffffff]: address conflict with Video RAM area [??? 0x1ff000a0000-0x1ff000bffff flags 0x80000000]
PCI: Claiming 0000:01:01.1: Resource 0: 000001ffe0000000..000001ffe000701f [200]
PCI: Claiming 0000:01:02.0: Resource 0: 000001ffe1000000..000001ffe1ffffff [200]
PCI: Claiming 0000:01:02.0: Resource 2: 000001ffe2000000..000001ffe2000fff [200]
PCI: Claiming 0000:01:03.0: Resource 0: 000001fe02c00000..000001fe02c00007 [101]
PCI: Claiming 0000:01:03.0: Resource 1: 000001fe02c00008..000001fe02c0000b [101]
PCI: Claiming 0000:01:03.0: Resource 2: 000001fe02c00010..000001fe02c00017 [101]
PCI: Claiming 0000:01:03.0: Resource 3: 000001fe02c00018..000001fe02c0001b [101]
PCI: Claiming 0000:01:03.0: Resource 4: 000001fe02c00020..000001fe02c0002f [101]
PCI: Claiming 0000:02:01.0: Resource 1: 000001ff00002000..000001ff000020ff [200]
PCI: Claiming 0000:02:01.0: Resource 6: 000001ff00010000..000001ff0001ffff [4c200]
PCI: Claiming 0000:02:02.0: Resource 0: 000001ff08000000..000001ff0bffffff [200]
PCI: Claiming 0000:02:02.0: Resource 1: 000001ff00000400..000001ff000004ff [200]
PCI: Claiming 0000:02:02.0: Resource 2: 000001ff10000000..000001ff10007fff [200]
PCI: Claiming 0000:02:02.0: Resource 6: 000001ff10020000..000001ff1003ffff [4c200]
PCI: Claiming 0000:02:03.0: Resource 0: 000001ff11000000..000001ff11ffffff [200]
PCI: Claiming 0000:02:03.0: Resource 2: 000001ff12000000..000001ff12000fff [200]
PCI: Claiming 0000:02:03.0: Resource 6: 000001ff12020000..000001ff1203ffff [4c200]
PCI: Claiming 0000:02:04.0: Resource 0: 000001ff12040000..000001ff1204ffff [204]
vgaarb: device added: PCI:0000:01:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:02.0,decodes=io+mem,owns=none,locks=none
vgaarb: device added: PCI:0000:02:03.0,decodes=io+mem,owns=none,locks=none
vgaarb: loaded
vgaarb: no bridge control possible 0000:02:03.0
vgaarb: no bridge control possible 0000:02:02.0
vgaarb: bridge control possible 0000:01:02.0
SCSI subsystem initialized
/pci@1f,0/pci@1,1/ebus@1/eeprom@14,0: Mostek regs at 0x1fff1000000
AUXIO: Found device at /pci@1f,0/pci@1,1/ebus@1/auxio@14,726000
Switched to clocksource tick
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 1, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 1, 16384 bytes)
NET: Registered protocol family 1
PCI: CLS 64 bytes, default 64
power: Control reg at 1fff1724000
futex hash table entries: 256 (order: -1, 6144 bytes)
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 8192 bytes)
msgmni has been set to 2002
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
PCI: Enabling device: (0000:01:02.0), cmd 82
atyfb: 3D RAGE PRO (Mach64 GP, PQFP, PCI) [0x4750 rev 0x7c]
atyfb: 4M SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100 MHz XCLK
Console: switching to colour frame buffer device 80x30
atyfb: fb0: ATY Mach64 frame buffer device on PCI
PCI: Enabling device: (0000:02:03.0), cmd 82
atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27]
atyfb: 8M SGRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
atyfb: fb1: ATY Mach64 frame buffer device on PCI
/SUNW,ffb@1e,0: FFB at 000001fc00000000, type 51, DAC pnum[236e] rev[10] manuf_rev[1]
/pci@1f,0/pci@1,1/ebus@1/su@14,3083f8: Keyboard port at 1fff13083f8, irq 6
/pci@1f,0/pci@1,1/ebus@1/su@14,3062f8: Mouse port at 1fff13062f8, irq 7
f0061c64: ttyS0 at MMIO 0x1fff1400000 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
Console: ttyS0 (SAB82532)
console [ttyS0] enabled
[sched_delayed] sched: RT throttling activated
f0061c64: ttyS1 at MMIO 0x1fff1400040 (irq = 5, base_baud = 115200) is a SAB82532 V3.2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 2940 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

PCI: Enabling device: (0000:01:01.1), cmd 2
sunhme.c:v3.10 August 26, 2008 David S. Miller (davem@davemloft.net)
eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:9e:82:fd
mousedev: PS/2 mouse device common for all mice
scsi 0:0:0:0: Direct-Access     QUANTUM  ATLAS IV 18 WLS  0909 PQ: 0 ANSI: 3
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
scsi target0:0:0: Beginning Domain Validation
rtc-m48t59 rtc-m48t59.0: rtc core: registered m48t59 as rtc0
hidraw: raw HID events driver (C) Jiri Kosina
TCP: cubic registered
NET: Registered protocol family 17
Key type dns_resolver registered
rtc-m48t59 rtc-m48t59.0: setting system clock to 2014-08-21 11:11:22 UTC (1408619482)
scsi target0:0:0: wide asynchronous
scsi target0:0:0: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8)
scsi target0:0:0: Domain Validation skipping write tests
scsi target0:0:0: Ending Domain Validation
input: Sun Mouse as /devices/root/f005f9c0/f00601b4/f0061504/f0064df4/serio1/input/input1
sd 0:0:0:0: [sda] 35885168 512-byte logical blocks: (18.3 GB/17.1 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: e3 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
EXT4-fs (sda4): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (sda4): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (sda4): INFO: recovery required on readonly filesystem
EXT4-fs (sda4): write access will be enabled during recovery
EXT4-fs (sda4): orphan cleanup on readonly fs
EXT4-fs (sda4): 4 orphan inodes deleted
EXT4-fs (sda4): recovery complete
EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:4.
devtmpfs: mounted
Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory
???????ɹ?????ѥ???
[info] Using makefile-style concurrent boot in runlevel S.
[....] Starting the hotplug events dispatcher: udevdsystemd-udevd[145]: starting version 204
[ ok .
[.random: nonblocking pool is initialized
...] Synthesizing the initial hotplug events...[ ok done.
[....] Waiting for /dev to be fully populated...pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[drm] Initialized drm 1.1.0 20060810
libata version 3.00 loaded.
scsi host1: pata_cmd64x
PTP clock support registered
scsi host2: pata_cmd64x
ata1: PATA max MWDMA2 cmd 0x1fe02c00000 ctl 0x1fe02c00008 bmdma 0x1fe02c00020 irq 14
ata2: PATA max MWDMA2 cmd 0x1fe02c00010 ctl 0x1fe02c00018 bmdma 0x1fe02c00028 irq 14
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
tg3.c:v3.137 (May 11, 2014)
PCI: Enabling device: (0000:02:04.0), cmd 2
tg3 0000:02:04.0 eth1: Tigon3 [partno(none) rev 1002] (PCI:33MHz:32-bit) MAC address 00:e0:00:a9:09:6a
tg3 0000:02:04.0 eth1: attached PHY is serdes (1000Base-SX Ethernet) (WireSpeed[0], EEE[0])
tg3 0000:02:04.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:02:04.0 eth1: dma_rwctrl[763f0000] dma_mask[32-bit]
[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] r100_init start
[drm] r100_init before render disable
[drm] r100_init before scratch
[drm] r100_init before surface
[drm] r100_init before sanity restore
[drm] r100_init before get_gios
[drm] radeon_get_bios atrm
[drm] radeon_get_bios vfct
[drm] radeon_get_bios vram
[drm] radeon_get_bios read
[drm] radeon_read_bios 1
[drm] radeon_read_bios: pci_resource_start(ROM)=000001FF10020000
[drm] radeon_read_bios 2
[drm] radeon_read_bios 4, bios=000001ff10020000, pci_resource_start(ROM)=000001FF10020000, size=46592
[drm] radeon_read_bios: found ROM signature at 000001ff10020000
[drm] radeon_read_bios 7: bios=000001ff10020000, size=46592
[drm] mydup done!
[drm] radeon_read_bios 8
[drm] radeon_read_bios b
[drm] radeon_read_bios c
[drm] radeon_get_bios disabled
[drm] radeon_get_bios platform
[drm] Not an x86 BIOS ROM, not using.
[drm] r100_init before AVIVO
[drm] r100_init before atom_bios
[drm] r100_init before combios init
[drm] r100_init after combios init 
[drm] r100_init before asic reset
[drm] r100_init before boot test post card
[drm] Using device-tree clock info
radeon 0000:02:02.0: VRAM: 64M 0x000001FF08000000 - 0x000001FF0BFFFFFF (64M used)
radeon 0000:02:02.0: GTT: 512M 0x000001FF0C000000 - 0x000001FF2BFFFFFF
[drm] Detected VRAM RAM=64M, BAR=64M
[drm] RAM width 64bits DDR
[TTM] Zone  kernel: Available graphics memory: 512796 kiB
[TTM] Initializing pool allocator
[drm] radeon: 64M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 65536, num gpu pages 131072
[drm] PCI GART of 512M enabled (table at 0x00000000C1F9E000).
radeon 0000:02:02.0: WB disabled
radeon 0000:02:02.0: fence driver on ring 0 use gpu addr 0x000001ff0c000000 and cpu addr 0xffffff003c00a000
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Loading R100 Microcode
[drm] radeon_ring_lockup_update start
[drm] r100_gfx_get_rptr start
[drm] r100_gfx_get_rptr case 2
[drm] r100_gfx_get_rptr end
[drm] radeon_ring_lockup_update middle
[drm] radeon_ring_lockup_update end
[drm] radeon: ring at 0x000001FF0C002000
[drm] radeon_ring_lock start
[drm] radeon_ring_lock got mutex
[drm] radeon_ring_alloc start
[drm] radeon_ring_alloc before radeon_ring_free_size
[drm] radeon_ring_free_size before radeon_ring_get_rptr
[drm] r100_gfx_get_rptr start
[drm] r100_gfx_get_rptr case 2
[drm] r100_gfx_get_rptr end
[drm] radeon_ring_free_size after radeon_ring_get_rptr
[drm] radeon_ring_free_size before radeon_ring_lockup_update
[drm] radeon_ring_lockup_update start
[drm] r100_gfx_get_rptr start
[drm] r100_gfx_get_rptr case 2
[drm] r100_gfx_get_rptr end
[drm] radeon_ring_lockup_update middle
[drm] radeon_ring_lockup_update end
[drm] radeon_ring_alloc after radeon_ring_free_size
[drm] radeon_ring_alloc end
[drm] radeon_ring_lock after alloc, r=0
[drm] radeon_ring_lock end (locked)
[drm] radeon_ring_unlock_commit unlocking
[drm] r100_ring_test start
[drm] r100_ring_test: after radeon_scratch_get, r=00000000d
[drm] r100_ring_test before radeon_ring_lock
[drm] radeon_ring_lock start
[drm] radeon_ring_lock got mutex
[drm] radeon_ring_alloc start
[drm] radeon_ring_alloc before radeon_ring_free_size
[drm] radeon_ring_free_size before radeon_ring_get_rptr
[drm] r100_gfx_get_rptr start
[drm] r100_gfx_get_rptr case 2

-- 
Meelis Roos (mroos@linux.ee)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2014-08-25 14:48                         ` Meelis Roos
@ 2014-08-26  2:46                           ` Michel Dänzer
  -1 siblings, 0 replies; 62+ messages in thread
From: Michel Dänzer @ 2014-08-26  2:46 UTC (permalink / raw)
  To: Meelis Roos, David Miller; +Cc: sparclinux, oftedal, dri-devel

On 25.08.2014 23:48, Meelis Roos wrote:
>> r100 init hangs in a different place. Original dmesg first, then my
>> instrumented dmesg (seems to get further):
>
> The instrumented dmesg had a couple of my local test changes and was
> bad now that I had ROM. Reverted them exept my readb changes (instead
> of direct dereferences of iomapped space) and redid
> logging to be more precise.
>
>> [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
>
> This was still the unchanged kernel hanging.
>
> Below is a new debug log to pinpoint the hang. It seems to hang in
> r100_gfx_get_rptr but not on first try.

It's most likely hanging in readl() in r100_mm_rreg() then.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2014-08-26  2:46                           ` Michel Dänzer
  0 siblings, 0 replies; 62+ messages in thread
From: Michel Dänzer @ 2014-08-26  2:46 UTC (permalink / raw)
  To: Meelis Roos, David Miller; +Cc: sparclinux, oftedal, dri-devel

On 25.08.2014 23:48, Meelis Roos wrote:
>> r100 init hangs in a different place. Original dmesg first, then my
>> instrumented dmesg (seems to get further):
>
> The instrumented dmesg had a couple of my local test changes and was
> bad now that I had ROM. Reverted them exept my readb changes (instead
> of direct dereferences of iomapped space) and redid
> logging to be more precise.
>
>> [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
>
> This was still the unchanged kernel hanging.
>
> Below is a new debug log to pinpoint the hang. It seems to hang in
> r100_gfx_get_rptr but not on first try.

It's most likely hanging in readl() in r100_mm_rreg() then.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2014-08-26  2:46                           ` Michel Dänzer
@ 2014-08-26  7:07                             ` Meelis Roos
  -1 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2014-08-26  7:07 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: sparclinux, oftedal, David Miller, dri-devel

> > > r100 init hangs in a different place. Original dmesg first, then my
> > > instrumented dmesg (seems to get further):
> >
> > The instrumented dmesg had a couple of my local test changes and was
> > bad now that I had ROM. Reverted them exept my readb changes (instead
> > of direct dereferences of iomapped space) and redid
> > logging to be more precise.
> >
> > > [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
> >
> > This was still the unchanged kernel hanging.
> >
> > Below is a new debug log to pinpoint the hang. It seems to hang in
> > r100_gfx_get_rptr but not on first try.
> 
> It's most likely hanging in readl() in r100_mm_rreg() then.

Yes, it is doing direct readl() there. But what does this hang mean?


By the way, I get these warnings from r100. Seem to be unrelated but 
still worth reporting IMHO:

  CC [M]  drivers/gpu/drm/radeon/r100.o
drivers/gpu/drm/radeon/r100.c: In function ¡r100_bandwidth_update¢:
include/drm/drm_fixed.h:64:13: warning: ¡crit_point_ff.full¢ may be used uninitialized in this function [-Wuninitialized]
drivers/gpu/drm/radeon/r100.c:3149:63: note: ¡crit_point_ff.full¢ was declared here
drivers/gpu/drm/radeon/r100.c:3573:42: warning: ¡disp_drain_rate.full¢ may be used uninitialized in this function [-Wuninitialized]


-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2014-08-26  7:07                             ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2014-08-26  7:07 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: sparclinux, oftedal, David Miller, dri-devel

> > > r100 init hangs in a different place. Original dmesg first, then my
> > > instrumented dmesg (seems to get further):
> >
> > The instrumented dmesg had a couple of my local test changes and was
> > bad now that I had ROM. Reverted them exept my readb changes (instead
> > of direct dereferences of iomapped space) and redid
> > logging to be more precise.
> >
> > > [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
> >
> > This was still the unchanged kernel hanging.
> >
> > Below is a new debug log to pinpoint the hang. It seems to hang in
> > r100_gfx_get_rptr but not on first try.
> 
> It's most likely hanging in readl() in r100_mm_rreg() then.

Yes, it is doing direct readl() there. But what does this hang mean?


By the way, I get these warnings from r100. Seem to be unrelated but 
still worth reporting IMHO:

  CC [M]  drivers/gpu/drm/radeon/r100.o
drivers/gpu/drm/radeon/r100.c: In function ‘r100_bandwidth_update’:
include/drm/drm_fixed.h:64:13: warning: ‘crit_point_ff.full’ may be used uninitialized in this function [-Wuninitialized]
drivers/gpu/drm/radeon/r100.c:3149:63: note: ‘crit_point_ff.full’ was declared here
drivers/gpu/drm/radeon/r100.c:3573:42: warning: ‘disp_drain_rate.full’ may be used uninitialized in this function [-Wuninitialized]


-- 
Meelis Roos (mroos@linux.ee)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2014-08-26  7:07                             ` Meelis Roos
@ 2014-08-27  2:24                               ` Michel Dänzer
  -1 siblings, 0 replies; 62+ messages in thread
From: Michel Dänzer @ 2014-08-27  2:24 UTC (permalink / raw)
  To: Meelis Roos; +Cc: sparclinux, oftedal, David Miller, dri-devel

On 26.08.2014 16:07, Meelis Roos wrote:
>>>> r100 init hangs in a different place. Original dmesg first, then my
>>>> instrumented dmesg (seems to get further):
>>>
>>> The instrumented dmesg had a couple of my local test changes and was
>>> bad now that I had ROM. Reverted them exept my readb changes (instead
>>> of direct dereferences of iomapped space) and redid
>>> logging to be more precise.
>>>
>>>> [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
>>>
>>> This was still the unchanged kernel hanging.
>>>
>>> Below is a new debug log to pinpoint the hang. It seems to hang in
>>> r100_gfx_get_rptr but not on first try.
>>
>> It's most likely hanging in readl() in r100_mm_rreg() then.
>
> Yes, it is doing direct readl() there. But what does this hang mean?

I'm not sure if the read can hang because of the GPU, or if indicates a 
more fundamental PCI issue. Dave?


> By the way, I get these warnings from r100. Seem to be unrelated but
> still worth reporting IMHO:

Looks unrelated indeed.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2014-08-27  2:24                               ` Michel Dänzer
  0 siblings, 0 replies; 62+ messages in thread
From: Michel Dänzer @ 2014-08-27  2:24 UTC (permalink / raw)
  To: Meelis Roos; +Cc: sparclinux, oftedal, David Miller, dri-devel

On 26.08.2014 16:07, Meelis Roos wrote:
>>>> r100 init hangs in a different place. Original dmesg first, then my
>>>> instrumented dmesg (seems to get further):
>>>
>>> The instrumented dmesg had a couple of my local test changes and was
>>> bad now that I had ROM. Reverted them exept my readb changes (instead
>>> of direct dereferences of iomapped space) and redid
>>> logging to be more precise.
>>>
>>>> [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
>>>
>>> This was still the unchanged kernel hanging.
>>>
>>> Below is a new debug log to pinpoint the hang. It seems to hang in
>>> r100_gfx_get_rptr but not on first try.
>>
>> It's most likely hanging in readl() in r100_mm_rreg() then.
>
> Yes, it is doing direct readl() there. But what does this hang mean?

I'm not sure if the read can hang because of the GPU, or if indicates a 
more fundamental PCI issue. Dave?


> By the way, I get these warnings from r100. Seem to be unrelated but
> still worth reporting IMHO:

Looks unrelated indeed.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer
--
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

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2014-08-27  2:24                               ` Michel Dänzer
@ 2014-08-30 19:20                                 ` Kjetil Oftedal
  -1 siblings, 0 replies; 62+ messages in thread
From: Kjetil Oftedal @ 2014-08-30 19:20 UTC (permalink / raw)
  To: Meelis Roos; +Cc: sparclinux, Michel Dänzer, David Miller, dri-devel

On 27 August 2014 04:24, Michel Dänzer <michel@daenzer.net> wrote:
> On 26.08.2014 16:07, Meelis Roos wrote:
>>>>>
>>>>> r100 init hangs in a different place. Original dmesg first, then my
>>>>> instrumented dmesg (seems to get further):
>>>>
>>>>
>>>> The instrumented dmesg had a couple of my local test changes and was
>>>> bad now that I had ROM. Reverted them exept my readb changes (instead
>>>> of direct dereferences of iomapped space) and redid
>>>> logging to be more precise.
>>>>
>>>>> [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
>>>>
>>>>
>>>> This was still the unchanged kernel hanging.
>>>>
>>>> Below is a new debug log to pinpoint the hang. It seems to hang in
>>>> r100_gfx_get_rptr but not on first try.
>>>
>>>
>>> It's most likely hanging in readl() in r100_mm_rreg() then.
>>
>>
>> Yes, it is doing direct readl() there. But what does this hang mean?
>
>
> I'm not sure if the read can hang because of the GPU, or if indicates a more
> fundamental PCI issue. Dave?
>
>
>
>> By the way, I get these warnings from r100. Seem to be unrelated but
>> still worth reporting IMHO:
>
>
> Looks unrelated indeed.
>
>
>
> --
> Earthling Michel Dänzer            |                  http://www.amd.com
> Libre software enthusiast          |                Mesa and X developer

Hi,

Just a short question regarding the test setup.
Is the video card a Sun XVR-100 or is it a vanilla ATI RV100 ?
(If it is a vanilla RV100 there might be some kind of initialization issue
as the video ROM is not executed during boot?)

Regards,
Kjetil Oftedal

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2014-08-30 19:20                                 ` Kjetil Oftedal
  0 siblings, 0 replies; 62+ messages in thread
From: Kjetil Oftedal @ 2014-08-30 19:20 UTC (permalink / raw)
  To: Meelis Roos; +Cc: sparclinux, Michel Dänzer, David Miller, dri-devel

On 27 August 2014 04:24, Michel Dänzer <michel@daenzer.net> wrote:
> On 26.08.2014 16:07, Meelis Roos wrote:
>>>>>
>>>>> r100 init hangs in a different place. Original dmesg first, then my
>>>>> instrumented dmesg (seems to get further):
>>>>
>>>>
>>>> The instrumented dmesg had a couple of my local test changes and was
>>>> bad now that I had ROM. Reverted them exept my readb changes (instead
>>>> of direct dereferences of iomapped space) and redid
>>>> logging to be more precise.
>>>>
>>>>> [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
>>>>
>>>>
>>>> This was still the unchanged kernel hanging.
>>>>
>>>> Below is a new debug log to pinpoint the hang. It seems to hang in
>>>> r100_gfx_get_rptr but not on first try.
>>>
>>>
>>> It's most likely hanging in readl() in r100_mm_rreg() then.
>>
>>
>> Yes, it is doing direct readl() there. But what does this hang mean?
>
>
> I'm not sure if the read can hang because of the GPU, or if indicates a more
> fundamental PCI issue. Dave?
>
>
>
>> By the way, I get these warnings from r100. Seem to be unrelated but
>> still worth reporting IMHO:
>
>
> Looks unrelated indeed.
>
>
>
> --
> Earthling Michel Dänzer            |                  http://www.amd.com
> Libre software enthusiast          |                Mesa and X developer

Hi,

Just a short question regarding the test setup.
Is the video card a Sun XVR-100 or is it a vanilla ATI RV100 ?
(If it is a vanilla RV100 there might be some kind of initialization issue
as the video ROM is not executed during boot?)

Regards,
Kjetil Oftedal
--
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

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
  2014-08-30 19:20                                 ` Kjetil Oftedal
@ 2014-08-31  5:59                                   ` Meelis Roos
  -1 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2014-08-31  5:59 UTC (permalink / raw)
  To: Kjetil Oftedal; +Cc: sparclinux, Michel Dänzer, David Miller, dri-devel

> >>>> The instrumented dmesg had a couple of my local test changes and was
> >>>> bad now that I had ROM. Reverted them exept my readb changes (instead
> >>>> of direct dereferences of iomapped space) and redid
> >>>> logging to be more precise.
> >>>>
> >>>>> [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
> >>>>
> >>>>
> >>>> This was still the unchanged kernel hanging.
> >>>>
> >>>> Below is a new debug log to pinpoint the hang. It seems to hang in
> >>>> r100_gfx_get_rptr but not on first try.
> >>>
> >>>
> >>> It's most likely hanging in readl() in r100_mm_rreg() then.
> >>
> >> Yes, it is doing direct readl() there. But what does this hang mean?
> >
> > I'm not sure if the read can hang because of the GPU, or if indicates a more
> > fundamental PCI issue. Dave?
[...]
> Just a short question regarding the test setup.
> Is the video card a Sun XVR-100 or is it a vanilla ATI RV100 ?
> (If it is a vanilla RV100 there might be some kind of initialization issue
> as the video ROM is not executed during boot?)

It,s SUNW,XVR-100 with F-code ROM.

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: PCI Radeon RV100 detection hang on sparc64
@ 2014-08-31  5:59                                   ` Meelis Roos
  0 siblings, 0 replies; 62+ messages in thread
From: Meelis Roos @ 2014-08-31  5:59 UTC (permalink / raw)
  To: Kjetil Oftedal; +Cc: sparclinux, Michel Dänzer, David Miller, dri-devel

> >>>> The instrumented dmesg had a couple of my local test changes and was
> >>>> bad now that I had ROM. Reverted them exept my readb changes (instead
> >>>> of direct dereferences of iomapped space) and redid
> >>>> logging to be more precise.
> >>>>
> >>>>> [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
> >>>>
> >>>>
> >>>> This was still the unchanged kernel hanging.
> >>>>
> >>>> Below is a new debug log to pinpoint the hang. It seems to hang in
> >>>> r100_gfx_get_rptr but not on first try.
> >>>
> >>>
> >>> It's most likely hanging in readl() in r100_mm_rreg() then.
> >>
> >> Yes, it is doing direct readl() there. But what does this hang mean?
> >
> > I'm not sure if the read can hang because of the GPU, or if indicates a more
> > fundamental PCI issue. Dave?
[...]
> Just a short question regarding the test setup.
> Is the video card a Sun XVR-100 or is it a vanilla ATI RV100 ?
> (If it is a vanilla RV100 there might be some kind of initialization issue
> as the video ROM is not executed during boot?)

It,s SUNW,XVR-100 with F-code ROM.

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 62+ messages in thread

end of thread, other threads:[~2014-08-31  6:01 UTC | newest]

Thread overview: 62+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-06 14:41 PCI Radeon RV100 detection hang on sparc64 Meelis Roos
2012-09-06 14:41 ` Meelis Roos
2012-09-06 16:51 ` Adam Jackson
2012-09-06 16:51   ` Adam Jackson
2012-09-06 18:15   ` David Miller
2012-09-06 18:15     ` David Miller
2012-09-06 16:55 ` Michel Dänzer
2012-09-06 16:55   ` Michel Dänzer
2012-09-06 18:18   ` David Miller
2012-09-06 18:18     ` David Miller
2012-09-07  7:18     ` Dave Airlie
2012-09-07  7:18       ` Dave Airlie
2012-09-19  7:51       ` mroos
2012-09-19  7:51         ` mroos
2013-09-23 13:48       ` mroos
2013-09-23 13:48         ` mroos
2013-09-23 19:06         ` Kjetil Oftedal
2013-09-23 19:06           ` Kjetil Oftedal
2013-09-23 20:36           ` David Miller
2013-09-23 20:36             ` David Miller
2013-09-23 21:14             ` mroos
2013-09-23 21:14               ` mroos
2013-09-23 21:33               ` David Miller
2013-09-23 21:33                 ` David Miller
2013-09-24 11:06                 ` Meelis Roos
2013-09-24 11:06                   ` Meelis Roos
2013-09-25 23:26                   ` Meelis Roos
2013-09-25 23:26                     ` Meelis Roos
2013-10-01  8:43               ` Meelis Roos
2013-10-01  8:43                 ` Meelis Roos
2014-04-04 20:52                 ` David Miller
2014-04-04 20:52                   ` David Miller
2014-08-13  6:30                   ` David Miller
2014-08-13  6:30                     ` David Miller
2014-08-19 11:17                     ` Meelis Roos
2014-08-19 11:17                       ` Meelis Roos
2014-08-25 14:48                       ` Meelis Roos
2014-08-25 14:48                         ` Meelis Roos
2014-08-26  2:46                         ` Michel Dänzer
2014-08-26  2:46                           ` Michel Dänzer
2014-08-26  7:07                           ` Meelis Roos
2014-08-26  7:07                             ` Meelis Roos
2014-08-27  2:24                             ` Michel Dänzer
2014-08-27  2:24                               ` Michel Dänzer
2014-08-30 19:20                               ` Kjetil Oftedal
2014-08-30 19:20                                 ` Kjetil Oftedal
2014-08-31  5:59                                 ` Meelis Roos
2014-08-31  5:59                                   ` Meelis Roos
2013-09-23 21:18           ` Meelis Roos
2013-09-23 21:18             ` Meelis Roos
2013-10-10 11:51           ` [PATCH] only try to find radeon IGP ROM on X86 Meelis Roos
2013-10-10 11:51             ` Meelis Roos
2013-10-10 14:38             ` Alex Deucher
2013-10-10 14:38               ` Alex Deucher
2013-10-10 15:26               ` Meelis Roos
2013-10-10 15:26                 ` Meelis Roos
2013-10-10 17:02                 ` David Miller
2013-10-10 17:02                   ` David Miller
2013-10-10 17:10                 ` Alex Deucher
2013-10-10 17:10                   ` Alex Deucher
2012-09-06 18:08 ` PCI Radeon RV100 detection hang on sparc64 David Miller
2012-09-06 18:08   ` David Miller

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.