[iBook 2.2] Blank screen, no X - kernel issue?
Hello list! With a fresh Sarge install from d-i RC1 on my iBook 2.2, I cannot get X to work. Using the plain default kernel 2.6.7-5 gives a blank console. 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... This is my first try with Linux on Powerpc, and I've no idea. Any experts around here? Did someone run into the same problem and fixed it? dmesg's output of the plain 2.6.7 kernel is attached, grabbed with a remote shell. 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/ Thanks very much, Nikolaus
Re: [iBook 2.2] Blank screen, no X - kernel issue?
Nikolaus Schulz wrote: > dmesg's output of the plain 2.6.7 kernel is attached, grabbed with > a remote shell. > 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/ Erm, looks like I forgot to actually attach anything. Anyway. It's all available at the site above. Greetz, Nikolaus
Tracking down radeonfb failure (was: [iBook 2.2] Blank screen, no X - kernel issue?)
Hi,
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
one...
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/[EMAIL PROTECTED]/ATY,[EMAIL
PROTECTED]/ATY,Bee_A/
AAPL,gray-page
address
character-set
compatible
depth
device_type
display-type
height
iso6429-1983-colors
linebytes
linux,phandle
name
width
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 :00:10.0 (0086 -> 0087)
| aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC to: a000
| 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" =
| | | | "EDIDerr" =
macos-shell$
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)
{
| u32 tmp = INREG(FP_HORZ_STRETCH) & HORZ_PANEL_SIZE;
| rinfo->panel_info.xres = ((tmp >> HORZ_PANEL_SHIFT) +
1) * 8;
| tmp = INREG(FP_VERT_STRETCH) & VERT_PANEL_SIZE;
| rinfo->panel_info.yres = (tmp >> VERT_PANEL_SHIFT) + 1;
|
Re: Tracking down radeonfb failure
Nikolaus Schulz wrote:
[ blank screen booting kernel 2.6.7 with radeonfb, missing EDID info ]
> Apparently radeonfb fails to retrieve necessary display info.
>
> ,[ 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 :00:10.0 (0086 -> 0087)
> | aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC to: a000
> | 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
^^^
This is the critical failure.
> | 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
> `
[...]
> ,[ radeon_monitor.c lines 825-833 ]
> | RTRACE("Guessing panel info...\n");
> | if (rinfo->panel_info.xres == 0 || rinfo->panel_info.yres == 0)
> {
> | u32 tmp = INREG(FP_HORZ_STRETCH) & HORZ_PANEL_SIZE;
> | rinfo->panel_info.xres = ((tmp >> HORZ_PANEL_SHIFT) +
> 1) * 8;
> | tmp = INREG(FP_VERT_STRETCH) & VERT_PANEL_SIZE;
> | 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.
Hmmm. I'll file this as a kernel bug.
> This is the source of the weird "Assuming panel size 8x1" message in
> dmesg. --
Apparently only this detection of the panel size needs to be fixed to
make it work.
At least AFAICS for now, the patch below, hardcoding the panel size into
the driver, is good enough for me. Both the console and X are now fine.
--- PATCH ---
diff -ru a/drivers/video/aty/radeon_monitor.c
b/drivers/video/aty/radeon_monitor.c
--- a/drivers/video/aty/radeon_monitor.cWed Jun 16 07:18:37 2004
+++ b/drivers/video/aty/radeon_monitor.cSun Sep 5 04:44:14 2004
@@ -829,10 +829,10 @@
tmp = INREG(FP_VERT_STRETCH) & VERT_PANEL_SIZE;
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");
- rinfo->mon1_type = MT_CRT;
- goto pickup_default;
+ if (rinfo->panel_info.xres == 8 || rinfo->panel_info.yres == 1)
{
+ rinfo->panel_info.xres = 1024;
+ rinfo->panel_info.yres = 768;
+ printk(KERN_WARNING "radeonfb: Can't find panel size,
falling back to hardcoded value\n");
}
printk(KERN_WARNING "radeonfb: Assuming panel size %dx%d\n",
rinfo->panel_info.xres, rinfo->panel_info.yres);
--- END PATCH ---
Even if it's really a hardware failure -- as e.g. Benh assumed in [1]:
MacOS is still okay, obviously its driver has some mechanism to cope
with this situation.
This means there is some way to determine the panel size the radeonfb
driver misses, right?
Please, can someone comment on this issue?
Nikolaus
[1] http://lists.debian.org/debian-powerpc/2003/08/msg00473.html
umountfs hangs on shutdown
Hello, perhaps someone has an idea concerning this... Shutting down Sarge on my iBook 2.2, /etc/init.d/umountfs hangs when remounting the root filesystem read-only. Here the relevant lines from umountfs: |# Umount all filesystems except the virtual ones. |umount -tnoproc,noprocfs,nodevfs,nosysfs,nousbfs,nousbdevfs,nodevpts -d -a -r | |# This is superfluous. |mount -n -o remount,ro / The last line above hangs. Sometimes. About every third occasion. I'm pretty much helpless and have absolutely _no_ idea which circumstances trigger this. :-( There is no indication in the syslog that something's going wrong. Making the umountfs script spawn a shell and stracing the remount revealed that it's precisely the "mount" syscall that hangs. But where to go from here? Is this remount really "superfluous" and could be safely removed, as the comment suggests? I'm runnning a Debian kernel 2.6.8 and a XFS root filesystem. Any suggestion will be _very_ appreciated. All the best, Nikolaus
Re: Howto Reconfigure Mode_switch for xf86 keyboard?
Hello, Hubert Krause wrote: > after installing Debian Sarge on my PowerMac G4 I have a Keyboard Problem. I > want to type symbols like at euro backslash, with the right alt key, but have > to use the left Apple-Key. Interesting. Having the Apple-Key as mode switch is exactly what I did some extra fiddling for :-) > As a workaround I have changed with xmodmap the > Mode_switch to be on the right ALT key, but how do I change it systemwide? > > My keyboard section in XF86Config-4: > > Section "InputDevice" > Identifier "Generic Keyboard" > Driver "keyboard" > Option "CoreKeyboard" > Option "XkbRules" "xfree86" > Option "XkbModel" "macintosh" > Option "XkbLayout" "de" > Option "XkbVariant""nodeadkeys" > EndSection You can find a list of relevant options for the xfree86 rules in /etc/X11/xkb/rules/xfree86.lst. The following is my application: ,[ XF86Config-4 ] | Section "InputDevice" | Identifier "Generic Keyboard" | Driver "keyboard" | Option "CoreKeyboard" | Option "XkbRules" "xfree86" | Option "XkbModel" "macintosh" | Option "XkbLayout" "de" | Option "XkbVariant""nodeadkeys" | Option "XkbOptions""grp:win_switch" | EndSection ` BTW I had to tweak it with gnome-keyboard-properties to make it work with Gnome, too. All the best, Nikolaus
