Subject: Re: The radeon framebuffer device panics init (on i386)
To: Michael Lorenz <macallan@netbsd.org>
From: Vincent <10.50@free.fr>
List: tech-kern
Date: 12/19/2006 07:51:33
Michael Lorenz hat diese Wörter geschrieben:

> Radeonfb has absolutely nothing to do with X.

Well, to some extent, it does. Just because it has to do with graphics ;)

> Yup, happens when no console output device attaches.

Yet, I cannot fathom why a failing radeonfb should prevent wscons to 
attach to vga!

> Hard to tell. For some reason radeonfb can't map your BIOS and barfs 
> about that - not sure why.
> Do you have 'options RADEON_BIOS_INIT' in your kernel? Try without it.

I try with and without. Same effect.

> Then, please post the output of 'pcictl pci1 dump -d 0' - this should 
> dump your graphics controller's PCI config space - might contain a hint 
> why the BIOS couldn't be mapped.

If you say it might help…

pcictl pci1 dump -d 0
PCI configuration registers:
   Common header:
     0x00: 0x4c571002 0x02b00087 0x03000000 0x00004208

     Vendor Name: ATI Technologies (0x1002)
     Device Name: Radeon Mobility M7 LW (0x4c57)
     Command register: 0x0087
       I/O space accesses: on
       Memory space accesses: on
       Bus mastering: on
       Special cycles: off
       MWI transactions: off
       Palette snooping: off
       Parity error checking: off
       Address/data stepping: on
       System error (SERR): off
       Fast back-to-back transactions: off
       Interrupt disable: off
     Status register: 0x02b0
       Capability List support: on
       66 MHz capable: on
       User Definable Features (UDF) support: off
       Fast back-to-back capable: on
       Data parity error detected: off
       DEVSEL timing: medium (0x1)
       Slave signaled Target Abort: off
       Master received Target Abort: off
       Master received Master Abort: off
       Asserted System Error (SERR): off
       Parity error detected: off
     Class Name: display (0x03)
     Subclass Name: VGA (0x00)
     Interface: 0x00
     Revision ID: 0x00
     BIST: 0x00
     Header Type: 0x00 (0x00)
     Latency Timer: 0x42
     Cache Line Size: 0x08

   Type 0 ("normal" device) header:
     0x10: 0x88000008 0x00003001 0x80380000 0x00000000
     0x20: 0x00000000 0x00000000 0x00000000 0x004a0e11
     0x30: 0x00000000 0x00000058 0x00000000 0x0008010b

     Base address register at 0x10
       type: 32-bit prefetchable memory
       base: 0x88000000, not sized
     Base address register at 0x14
       type: i/o
       base: 0x00003000, not sized
     Base address register at 0x18
       type: 32-bit nonprefetchable memory
       base: 0x80380000, not sized
     Base address register at 0x1c
       not implemented(?)
     Base address register at 0x20
       not implemented(?)
     Base address register at 0x24
       not implemented(?)
     Cardbus CIS Pointer: 0x00000000
     Subsystem vendor ID: 0x0e11
     Subsystem ID: 0x004a
     Expansion ROM Base Address: 0x00000000
     Capability list pointer: 0x58
     Reserved @ 0x38: 0x00000000
     Maximum Latency: 0x00
     Minimum Grant: 0x08
     Interrupt pin: 0x01 (pin A)
     Interrupt line: 0x0b

   Capability register at 0x58
     type: 0x02 (AGP, rev. 2.0)
   Capability register at 0x50
     type: 0x01 (Power Management, rev. 1.0)

   Device-dependent header:
     0x40: 0x00000000 0x00000000 0x00000000 0x004a0e11
     0x50: 0x06020001 0x00000000 0x00205002 0x2f000207
     0x60: 0x00000200 0x00000000 0x00000000 0x00000000
     0x70: 0x00000000 0x00000000 0x00000000 0x00000000
     0x80: 0x00000000 0x00000000 0x00000000 0x00000000
     0x90: 0x00000000 0x00000000 0x00000000 0x00000000
     0xa0: 0x00000000 0x00000000 0x00000000 0x00000000
     0xb0: 0x00000000 0x00000000 0x00000000 0x00000000
     0xc0: 0x00000000 0x00000000 0x00000000 0x00000000
     0xd0: 0x00000000 0x00000000 0x00000000 0x00000000
     0xe0: 0x00000000 0x00000000 0x00000000 0x00000000
     0xf0: 0x00000000 0x00000000 0x00000000 0x00000000

There are at least three different BAR, and if I am not mistaken, only 
the last corresponds to the ROM. Is it possible that the attach routine 
tries to map a wrong area?

Thanks,
Vincent