> Now that the backlight keys do something (that is,
> CONFIG_PMAC_BACKLIGHT=y) I can test what they do after the machine
> wakes and the screen is black. Hitting the keys does the same thing
> described above. The screen remains black (but backlit) until the
> 15th hit at which point the screen
Hi,
To refresh our memories, I get a black display when my iBook wakes
from sleep. Under OSX the machine can sleep and wake with a working
display.
The thread started here:
http://lists.debian.org/debian-powerpc/2003/debian-powerpc-200311/msg00283.html
After a while we got my kernel better con
> okay, here is some more info.
>
> FWIW, the backlight keys (f1, f2) do not change the state of the
> backlight, ever. I am running pbbuttonsd. Instead of seeing the
> display change I see on the console:
>
> keyboard: unknown scancode e0 4c
> keyboard: unknown scancode e0 54
>
> for first d
On Tue, Nov 18, 2003 at 11:16:28AM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2003-11-18 at 06:46, David Kimdon wrote:
> > On Mon, Nov 17, 2003 at 10:24:17AM +1100, Benjamin Herrenschmidt wrote:
> > > Ok, so what's up with sleep now ? Can you send me a dmesg output from
> > > after wakeup ? (ss
> > Update: compiling the kernel without preemption seems to fix it. What's
> > needed to make critical sections in the framebuffer code preemption safe?
> > (local_irq_save() didn't help, FWIW)
>
> Ah that explains it ! Do no use CONFIG_PREEMPT if you want some
> thing that works ;) Preemp
On Wed, 2003-11-19 at 06:14, Michael Schmitz wrote:
> > > > Just in case it's a similar problem with radeonfb :-)
> > >
> > > No, radeonfb uses the PCI stuff nowadays, but I'll look into fixing
> > > atyfb ;)
> >
> > It's worse than I originally assumed: the kernel hangs in
> > aty_power_mgmt(). Th
> > > Just in case it's a similar problem with radeonfb :-)
> >
> > No, radeonfb uses the PCI stuff nowadays, but I'll look into fixing
> > atyfb ;)
>
> It's worse than I originally assumed: the kernel hangs in
> aty_power_mgmt(). The info and par pointers are OK.
Update: compiling the kernel with
> > I've not found the proper incantation to fix that - first_display = info
> > just hangs the machine on sleep request. I suspect a null pointer
> > someplace, or par->next is garbage.
> >
> > Just in case it's a similar problem with radeonfb :-)
>
> No, radeonfb uses the PCI stuff nowadays, but
On Mon, 2003-11-17 at 20:51, Michael Schmitz wrote:
> > > If anyone has a clue as to where to look further that would be great.
> > > I've poked around in the Linux radeonfb driver as well as in the
> > > xfree86 radeon driver for clues, so far no success.
> >
> > Is radeonfb detecting the display
On Tue, 2003-11-18 at 06:46, David Kimdon wrote:
> On Mon, Nov 17, 2003 at 10:24:17AM +1100, Benjamin Herrenschmidt wrote:
> > Ok, so what's up with sleep now ? Can you send me a dmesg output from
> > after wakeup ? (ssh into the box remotely for example)
Hrm... traces look fine. Can you tell me m
On Mon, Nov 17, 2003 at 10:24:17AM +1100, Benjamin Herrenschmidt wrote:
> Ok, so what's up with sleep now ? Can you send me a dmesg output from
> after wakeup ? (ssh into the box remotely for example)
>
Sure, here you go.
I also put :
config device-tree.tar.gz dmesg uname
updated at :
http:/
> > If anyone has a clue as to where to look further that would be great.
> > I've poked around in the Linux radeonfb driver as well as in the
> > xfree86 radeon driver for clues, so far no success.
>
> Is radeonfb detecting the display at all ? Also can you test my
> current 2.6 with "new" radeonf
On Mon, 2003-11-17 at 01:13, David Kimdon wrote:
> On Sun, Nov 16, 2003 at 03:33:09PM +1100, Benjamin Herrenschmidt wrote:
> > On Sun, 2003-11-16 at 14:04, David Kimdon wrote:
> > > On Sun, Nov 16, 2003 at 10:20:28AM +1100, Benjamin Herrenschmidt wrote:
> > Do you have:
> >
> > CONFIG_FRAMEBUFFER_
On Sun, Nov 16, 2003 at 03:33:09PM +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2003-11-16 at 14:04, David Kimdon wrote:
> > On Sun, Nov 16, 2003 at 10:20:28AM +1100, Benjamin Herrenschmidt wrote:
> Do you have:
>
> CONFIG_FRAMEBUFFER_CONSOLE=ySet ?
Ah, I didn't, now I do, and it works (still d
On Sun, 2003-11-16 at 14:04, David Kimdon wrote:
> On Sun, Nov 16, 2003 at 10:20:28AM +1100, Benjamin Herrenschmidt wrote:
> >
> > > sure, same problem (blank display on wake-up from sleep).
> > > Additionally with the 2.6 new driver console is always blank, but X
> > > works until the machine sle
On Sun, Nov 16, 2003 at 10:20:28AM +1100, Benjamin Herrenschmidt wrote:
>
> > sure, same problem (blank display on wake-up from sleep).
> > Additionally with the 2.6 new driver console is always blank, but X
> > works until the machine sleeps.
>
> Ah ? You mean at boot you get a blank console ? i
> sure, same problem (blank display on wake-up from sleep).
> Additionally with the 2.6 new driver console is always blank, but X
> works until the machine sleeps.
Ah ? You mean at boot you get a blank console ? interesting... Is the
display really blank or is it just the backlight that is off ?
On Sat, Nov 15, 2003 at 06:34:32PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2003-11-12 at 08:51, David Kimdon wrote:
> > Hi,
> >
> > If anyone has a clue as to where to look further that would be great.
> > I've poked around in the Linux radeonfb driver as well as in the
> > xfree86 radeon d
On Wed, 2003-11-12 at 08:51, David Kimdon wrote:
> Hi,
>
> If anyone has a clue as to where to look further that would be great.
> I've poked around in the Linux radeonfb driver as well as in the
> xfree86 radeon driver for clues, so far no success.
Is radeonfb detecting the display at all ? Also
Hi,
If anyone has a clue as to where to look further that would be great.
I've poked around in the Linux radeonfb driver as well as in the
xfree86 radeon driver for clues, so far no success.
I recently had a broken motherboard on my iBook replaced. Previous to
the replacement suspend worked well
20 matches
Mail list logo
