Hi, everybody!
I can confirm this bug, too.
Macmini G4, Apple Cinema Display 23", etc.
I found a workaround: recompiled the kernel disabling the option:
CONFIG_FB_RADEON_I2C
Tested the workaround in lenny and etch (two G4 macminis here).
This is the relevant diff.
So it seems that the nasty I2C behaviour is back... At least we know
where to look at!
Hope that it helps.
Greetings,
pancho.
--- config-2.6.22-2-powerpc 2007-08-30 23:37:18.000000000 +0200
+++ config-2.6.22-2-powerpc-noi2c 2007-10-08 09:08:33.000000000 +0200
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.22
-# Thu Aug 30 20:28:06 2007
+# Linux kernel version: 2.6.22noi2c
+# Mon Oct 8 09:08:33 2007
#
# CONFIG_PPC64 is not set
CONFIG_PPC_PM_NEEDS_RTC_LIB=y
@@ -2224,7 +2224,7 @@
CONFIG_FB_MATROX_MAVEN=m
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_RADEON=y
-CONFIG_FB_RADEON_I2C=y
+# CONFIG_FB_RADEON_I2C is not set
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
CONFIG_FB_ATY128=y
On Sat, Oct 06, 2007 at 01:29:27PM +0200, Stephane Louise wrote:
> Hi,
>
> So yesterday was kernel upgrade day for testing, it seems. I allowed it
> since I knew I could have a way-back whatever the odds.
>
> Well, in fact the bug is still there with 2.6.22-2-powerpc: the Apple
> cinema display is stuck in sleep mode as soon as the kernel boot starts.
>
> As previously, the computer works fine otherwise(although my Win-TV nova
> usb-2 box is not activated: it seems to be a firmware update problem, I'll
> try to investigate). It is also possible to make it kind'of work by the use
> of the option "video=ofonly" at boot time, but it is really non-optimal,
> since it prevents from using console login, once X11 is started.
>
> I suggest to reclassify this bug as linux-2.6 as a whole since it is not
> specific to linux-2.6.21 anymore, and it may be a show-stopper for debian
> on mac-mini users (OK, it's not like there should be more than a few
> hundreds of us there, but still...).
>
> BTW, would it be possible that the vmlinux.old is not updated when the
> running kernel is the one actually linked as vmlinux.old ? I mean, if the
> current running kernel is the "old" one, there could be a reason, and I
> don't see a case when it would be useful to update the "old" link to a non
> running kernel. This one is only whishlist, of course. Should I send it as
> separate bug with a whishlist status ?
>
> Regards,
>
> mata ne
> --
> Luigi
>
>
>
--
Pancho Horrillo
To be conscious that
you are ignorant is a great step
to knowledge.
Benjamin Disraeli
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
