[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#266472: Tracking down radeonfb failure (was: [iBook 2.2] Blank screen, no X - kernel issue?)


this is crossposted as I'm not sure where to put this.
The referenced posting to debian-powerpc hasn't seen a reply yet.

Nikolaus Schulz wrote:
> With a fresh Sarge install from d-i RC1 on my iBook 2.2, I cannot get X
> to work. 

Perhaps I should have mentioned that there is an installation report
(Bug #266472) available at [1]. 

To be more verbose and make this posting a little bit more
self-contained: the affected machine is an iBook G3, 800MHz Combo, with
a Radeon Mobility M7 (7500 LW) graphics chip. 

> Using the plain default kernel 2.6.7-5 gives a blank console.

Note that the backlight is working, but nothing more. 

> Adding video=ofonly makes the console work, but startx again blanks
> the screen. 
> Some people wrote that the Open Firmware framebuffer driver (aka ofonly)
> breaks X, so that's not very surprising. But radeonfb seems to be
> broken, too, and I've found nobody experiencing the same behaviour :-(
> Using kernel 2.4.26, there's no need to specify boot parameters for
> the console, but X still doesn't function...

In fact kernel 2.4.26 falls back to offb, too. This can be seen in the
dmesg, I just missed it.


> Rather than posting all potentially relevant configs and logs, I've put
> the dmesg, XF86Config-4 and, if possible, XFree86.logs for the kernels
> 2.6.7 and 2.4.26 on a website:
> http://www.math.fu-berlin.de/~nschulz/linux/trouble/ibook/

Okay, I have further investigated the problem. Looks like a serious
Apparently radeonfb fails to retrieve necessary display info.

Once again searching the lists, I finally found two postings describing
similar problems, see [2]: "DualHead-hack for iBook breaks radeonfb" and
[3]: "Powerbook 15" 1Ghz radeonfb/XFree86 woes".

In fact I once had applied the Dual-Head hack -- but the mainboard has
been replaced by Apple with a new one after it broke completely...  
This was a case for the "iBook Logic Board Repair Extension Program" [4].

Just like Michael Klein reported in [2], EDID information seems to be
missing. (Never heard of EDID before...)

ibook$ ls -1 /proc/device-tree/pci@f0000000/ATY,BeeParent@10/ATY,Bee_A/

I have made a tarball of the directory tree below /proc/device-tree/ and
uploaded it to my site given above. 
In addition I gathered the dmesg output running kernel 2.6.7 with
CONFIG_FB_RADEON_DEBUG enabled and uploaded it, too.

For the record, and to put some meat onto this posting, here a snippet
from dmesg.
The XFree86 logs are probably irrelevant with offb running, right?
In any case, I've uploaded everything.

,----[ dmesg of 2.6.7 with CONFIG_FB_RADEON_DEBUG ]
| PCI: Probing PCI hardware
| Registering openpic with sysfs...
| radeonfb_pci_register BEGIN
| PCI: Enabling device 0000:00:10.0 (0086 -> 0087)
| aper_base: 98000000 MC_FB_LOC to: 9bff9800, MC_AGP_LOC to: ffffa000
| radeonfb: probed DDR SGRAM 32768k videoram
| radeonfb: mapped 16384k videoram
| radeonfb: Invalid ROM signature 0 should be 0xaa55
| radeonfb: Retreived PLL infos from Open Firmware
| radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=180.00 Mhz, System=180.00 MHz
| Starting monitor auto detection...
| radeonfb: I2C (port 1) ... not found
| radeonfb: I2C (port 2) ... not found
| radeonfb: I2C (port 3) ... not found
| radeonfb: I2C (port 4) ... not found
| radeon_probe_OF_head
| head: ATY,Bee_A (letter: A, head_no: 0)
| analyzing OF properties...
| display-type: LCD
| radeon_probe_OF_head
| head: ATY,Bee_A (letter: A, head_no: 1)
| radeonfb: I2C (port 3) ... not found
| radeonfb: I2C (port 4) ... not found
| radeonfb: Monitor 1 type LCD found
| radeonfb: Monitor 2 type no found
| Guessing panel info...
| radeonfb: Assuming panel size 8x1
| radeonfb: Power Management enabled for Mobility chipsets
| Registered "ati" backlight controller, level: 15/15
| radeonfb: ATI Radeon LW  DDR SGRAM 32 MB
| radeonfb_pci_register END

The finding in [5] regarding [3] and [2] is the same here: 

macos-shell$ ioreg -l | grep EDID 
    | |     | |     "EDIDerr" = <f615>
    | |     | |     "EDIDerr" = <f615>
Looking into kernel-source-2.6.7/drivers/video/aty/radeon_monitor.c, I
found the following, BTW:

,----[ radeon_monitor.c lines 825-833 ]
| 		RTRACE("Guessing panel info...\n");
| 		if (rinfo->panel_info.xres == 0 || rinfo->panel_info.yres == 0) {
| 			rinfo->panel_info.xres = ((tmp >> HORZ_PANEL_SHIFT) + 1) * 8;
| 			rinfo->panel_info.yres = (tmp >> VERT_PANEL_SHIFT) + 1;
| 		}
| 		if (rinfo->panel_info.xres == 0 || rinfo->panel_info.yres == 0) {
| 			printk(KERN_WARNING "radeonfb: Can't find panel size, going back to CRT\n");

I'd say this looks plain wrong, the second "if" will never be triggered.
This is the source of the weird "Assuming panel size 8x1" message in
dmesg. --

As Michael Klein wrote in [5], he fixed his problems by hardcoding the
EDID values into radeonfb.c. I hope there is another way!?


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266472
[2] http://lists.debian.org/debian-powerpc/2003/08/msg00199.html
[3] http://lists.debian.org/debian-powerpc/2003/08/msg00398.html
[4] http://www.apple.com/support/ibook/faq/
[5] http://lists.debian.org/debian-powerpc/2003/08/msg00489.html

Reply to: