Hi,
Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet weekend).
Anyway, it seems that radeonfb and my:
"01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE)"
don't get along anymore, by:
a) X somehow fails to initialize the card and everything moves really slow (I can
see how surfaces are drawn pixel-by-pixel); furthermore, garbage stuff appears
on the screen;
b) after powering up from a s2ram, the system freezes;
b) is not that bad, s2ram never worked on my machine (kjournald and some other kernel
processes, enter disk-sleep and in a matter of seconds, everything just... freezes.
I can type a few commands at the normal console but that is all);
Following the advices in 'Documentation/power/s2ram.txt' helped. Using the regular
VGA console got X on the right track (no more slowness);
Now that I got my hands "dirty", I'm in the mood to make my s2ram work (I've
been using Linux (exclusively) for three years now, it's about time I do a small
contribution). What kernel option must I enable to determine why some processes
enter (and stay in) disk-sleep? I'm on a laptop and I don't think it will withstand
too many reboots :)
I've also attached the output of lspci and dmesg. Maybe someone spots something.
Thanks,
--
Mihai Donțu
On Saturday 22 September 2007, Mihai Donțu wrote:
> Hi,
>
> Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet weekend).
> Anyway, it seems that radeonfb and my:
> "01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE)"
> don't get along anymore, by:
> a) X somehow fails to initialize the card and everything moves really slow (I can
> see how surfaces are drawn pixel-by-pixel); furthermore, garbage stuff appears
> on the screen;
> b) after powering up from a s2ram, the system freezes;
>
> b) is not that bad, s2ram never worked on my machine (kjournald and some other kernel
> processes, enter disk-sleep and in a matter of seconds, everything just... freezes.
> I can type a few commands at the normal console but that is all);
>
> Following the advices in 'Documentation/power/s2ram.txt' helped. Using the regular
> VGA console got X on the right track (no more slowness);
>
> Now that I got my hands "dirty", I'm in the mood to make my s2ram work (I've
> been using Linux (exclusively) for three years now, it's about time I do a small
> contribution). What kernel option must I enable to determine why some processes
> enter (and stay in) disk-sleep? I'm on a laptop and I don't think it will withstand
> too many reboots :)
>
> I've also attached the output of lspci and dmesg. Maybe someone spots something.
>
> Thanks,
>
Since there was no reply, I assume people *do* take the weekend off :)
Anyway, I took matters into my own hands and enabled whatever debugging
feature seamed reasonable enough (ACPI, SysRq, etc).
Reboot, play, echo "mem" >/sys/power/state. I waited 5s and powered up
and found this in dmesg
"
hda:task_out_intr:status = 0x51 { DriveReady SeekComplete Error }
hda:task_out_intr:error = 0x04 { DriveStatusError }
ide:failed opcode was: unknown
"
I figured my IDE woke up in a bad mood so I alt-sysrq-s, alt-sysrq-u and
alt-sysrq-b (blessed be he who invented alt-sysrq-<command>). After
boot I went back to my "make menuconfig" and stared for ... 15s, when I
found this: "IDE ACPI support" (boy do I feel silly).
Reboot, play, echo "mem" >/sys/power/state ... [5s] ... power up. Ta-da!
Everything works. Well, maybe the audio needed a little "jolt" (turn sound
off, back on, move the volume a bit and voila!).
I've attached the dmesg, again, maybe someone spots something bad.
Thanks,
--
Mihai Donțu
On Sat, 2007-09-22 at 17:46 +0300, Mihai Donțu wrote:
> On Saturday 22 September 2007, Mihai Donțu wrote:
> > Hi,
> >
> > Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet weekend).
> > Anyway, it seems that radeonfb and my:
> > "01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE)"
> > don't get along anymore, by:
> > a) X somehow fails to initialize the card and everything moves really slow (I can
> > see how surfaces are drawn pixel-by-pixel); furthermore, garbage stuff appears
> > on the screen;
> > b) after powering up from a s2ram, the system freezes;
> >
> > b) is not that bad, s2ram never worked on my machine (kjournald and some other kernel
> > processes, enter disk-sleep and in a matter of seconds, everything just... freezes.
> > I can type a few commands at the normal console but that is all);
> >
> > Following the advices in 'Documentation/power/s2ram.txt' helped. Using the regular
> > VGA console got X on the right track (no more slowness);
> >
> > Now that I got my hands "dirty", I'm in the mood to make my s2ram work (I've
> > been using Linux (exclusively) for three years now, it's about time I do a small
> > contribution). What kernel option must I enable to determine why some processes
> > enter (and stay in) disk-sleep? I'm on a laptop and I don't think it will withstand
> > too many reboots :)
> >
> > I've also attached the output of lspci and dmesg. Maybe someone spots something.
> >
> > Thanks,
> >
>
> Since there was no reply, I assume people *do* take the weekend off :)
Heh, yup.
There have been some radeonfb patches around -rc6 or so. Can you try
backing them out and letting us know if that helps a) ?
In that case, Linus, we probably want to revert them...
Though looking at your PCI ID (5955), I don't think the patches should
have changed anything.
Ben.
On Sunday 23 September 2007, Benjamin Herrenschmidt wrote:
> Heh, yup.
>
> There have been some radeonfb patches around -rc6 or so. Can you try
> backing them out and letting us know if that helps a) ?
>
> In that case, Linus, we probably want to revert them...
>
> Though looking at your PCI ID (5955), I don't think the patches should
> have changed anything.
After four hours of bisecting, I got this, which dates back to 2.6.21, but
I've been on 2.6.21.3 for too long and thus missed the commit (I just decided
to be a good citizen and test things before they get out).
dd1447134454b169d5ae353aceb93f2368db8547 is first bad commit
commit dd1447134454b169d5ae353aceb93f2368db8547
Author: johan henriksson <[email protected]>
Date: Tue May 8 00:37:59 2007 -0700
radeonfb: Add support for Radeon xpress 200m
Added support for radeon xpress 200m(rs480). Note that the card doesn't
like dynclk turned on.
Signed-off-by: Johan Henriksson <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: "Antonino A. Daplas" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
:040000 040000 e553664a656ee329152789818b5b071a36ac1e45 0a698ad7daa8cdfd9eb5304812845306c9feb2f9 M drivers
I turned dynclk off, no result (although dynclk is preferred).
What is interesting, is that the driver ignores "vga=normal" and "jumps" to
a quite high res (I think is 1024x768 or something; the fonts look really nice
though :)).
--
Mihai Donțu
On Sunday 23 September 2007, Mihai Donțu wrote:
> On Sunday 23 September 2007, Benjamin Herrenschmidt wrote:
> > Heh, yup.
> >
> > There have been some radeonfb patches around -rc6 or so. Can you try
> > backing them out and letting us know if that helps a) ?
> >
> > In that case, Linus, we probably want to revert them...
> >
> > Though looking at your PCI ID (5955), I don't think the patches should
> > have changed anything.
>
> After four hours of bisecting, I got this, which dates back to 2.6.21, but
> I've been on 2.6.21.3 for too long and thus missed the commit (I just decided
> to be a good citizen and test things before they get out).
>
> dd1447134454b169d5ae353aceb93f2368db8547 is first bad commit
> commit dd1447134454b169d5ae353aceb93f2368db8547
> Author: johan henriksson <[email protected]>
> Date: Tue May 8 00:37:59 2007 -0700
>
> radeonfb: Add support for Radeon xpress 200m
>
> Added support for radeon xpress 200m(rs480). Note that the card doesn't
> like dynclk turned on.
>
> Signed-off-by: Johan Henriksson <[email protected]>
> Cc: Benjamin Herrenschmidt <[email protected]>
> Cc: "Antonino A. Daplas" <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
>
> :040000 040000 e553664a656ee329152789818b5b071a36ac1e45 0a698ad7daa8cdfd9eb5304812845306c9feb2f9 M drivers
>
> I turned dynclk off, no result (although dynclk is preferred).
>
> What is interesting, is that the driver ignores "vga=normal" and "jumps" to
> a quite high res (I think is 1024x768 or something; the fonts look really nice
> though :)).
Something strange is going on here: after I cleaned up the bisect kernels,
I booted 2.6.23-rc7 using something like:
"vga=normal nohz=on root=/dev/sda7 libata.noacpi=0 pci=assing-busses"
and explicitly selecting "Enable Video Mode Handling Helpers" (which normally
gets automatically selected once I choose "ATI Radeon display support" but I
- suffering from intense paranoia - selected it by hand prior to selecting ATI
Radeon ...).
I works! X is no longer acting weird. I can't use "vga=791" anymore (the screen
goes blank until X loads => timings definitely changed) but it *works* and I don't
know why _and_ I can't seem to be able to make it go back to being bad :)
I did a diff between the .config used in bisect and the current .config. I don't
see anything suspicious.
I'll to do a full cleanup and start all over. I'm going to nail this thing down if
it's the last thing I do! (so help me God) :)
--
Mihai Donțu
On Sunday 23 September 2007, Mihai Donțu wrote:
> I'll to do a full cleanup and start all over. I'm going to nail this thing down if
> it's the last thing I do! (so help me God) :)
Found it!
The problem was "Framebuffer Console support". It was enabled by default in older
configs (like 2.6.22.7) but I think someone noticed this was bad and put it to
default N in newer (2.6.23-rc7); and since I reused the .config from 2.6.21.3 ...
So there, if one wants "ATI Radeon display support" on Radeon XPRESS 200M with
X using radeon_drv.so, *should* put "Framebuffer Console support" to N (if it's
not already).
Now all I have to do is figure out what's the equivalent of "vga=791" on the new
kernel (default text console looks really bad on my laptop).
Sorry for all the noise (and spam),
--
Mihai Donțu
On Sunday, 23 September 2007 20:31, Mihai Donțu wrote:
> On Sunday 23 September 2007, Mihai Donțu wrote:
> > I'll to do a full cleanup and start all over. I'm going to nail this thing down if
> > it's the last thing I do! (so help me God) :)
>
> Found it!
>
> The problem was "Framebuffer Console support". It was enabled by default in older
> configs (like 2.6.22.7) but I think someone noticed this was bad and put it to
> default N in newer (2.6.23-rc7); and since I reused the .config from 2.6.21.3 ...
>
> So there, if one wants "ATI Radeon display support" on Radeon XPRESS 200M with
> X using radeon_drv.so, *should* put "Framebuffer Console support" to N (if it's
> not already).
>
> Now all I have to do is figure out what's the equivalent of "vga=791" on the new
> kernel (default text console looks really bad on my laptop).
>
> Sorry for all the noise (and spam),
No, this actually is valuable information, thanks for it. :-)
[I have missed your first post, sorry for that.]
Greetings,
Rafael
On Sunday 23 September 2007, Rafael J. Wysocki wrote:
> On Sunday, 23 September 2007 20:31, Mihai Donțu wrote:
> > On Sunday 23 September 2007, Mihai Donțu wrote:
> > > I'll to do a full cleanup and start all over. I'm going to nail this thing down if
> > > it's the last thing I do! (so help me God) :)
> >
> > Found it!
> >
> > The problem was "Framebuffer Console support". It was enabled by default in older
> > configs (like 2.6.22.7) but I think someone noticed this was bad and put it to
> > default N in newer (2.6.23-rc7); and since I reused the .config from 2.6.21.3 ...
> >
> > So there, if one wants "ATI Radeon display support" on Radeon XPRESS 200M with
> > X using radeon_drv.so, *should* put "Framebuffer Console support" to N (if it's
> > not already).
> >
> > Now all I have to do is figure out what's the equivalent of "vga=791" on the new
> > kernel (default text console looks really bad on my laptop).
> >
> > Sorry for all the noise (and spam),
>
> No, this actually is valuable information, thanks for it. :-)
>
> [I have missed your first post, sorry for that.]
Don't worry.
Now, one last update (I've just ran into it): I was preparing my laptop (to brag
tomorrow with my new s2ram thinggie) when I noticed that after powering up from a
suspend-to-ram, X doesn't like radeonfb working behind it's back, as a result
it goes crazy (corrupted pixmaps and such). I should have tested these two together :|
Bottom line: no radeonfb for me :( at least, not now; but I have to be honest with
you: I don't see what commit dd1447134454b169d5ae353aceb93f2368db8547 brought new
into the picture. The previous radeonfb worked just great, but then, again, maybe I'm
not using the console at it's full power :)
I have attached the dmesg after power up.
Thanks,
(last post today, I swear to God!)
--
Mihai Donțu
* Sun, 23 Sep 2007 22:22:28 +0300
* Organization: Home
[]
>> >
>> > So there, if one wants "ATI Radeon display support" on Radeon XPRESS 200M with
>> > X using radeon_drv.so, *should* put "Framebuffer Console support" to N (if it's
>> > not already).
[]
> Bottom line: no radeonfb for me :( at least, not now; but I have to be honest with
> you: I don't see what commit dd1447134454b169d5ae353aceb93f2368db8547 brought new
> into the picture. The previous radeonfb worked just great, but then, again, maybe I'm
> not using the console at it's full power :)
In fact, it's known statement, that there must only one hardware driver
for graphic adapter. Be it framebuffer with X fb driver on it or legacy
VGA text and X with its driver.so and 3D stuff.
(i choose legacy text without X for the most of my time, though :)
_____
On Sun, 2007-09-23 at 22:22 +0300, Mihai Donțu wrote:
>
> Bottom line: no radeonfb for me :( at least, not now; but I have to
> be honest with
> you: I don't see what commit
> dd1447134454b169d5ae353aceb93f2368db8547 brought new
> into the picture. The previous radeonfb worked just great, but then,
> again, maybe I'm
> not using the console at it's full power :)
It might have simply not initialized :-)
Ben.
On Sun, 2007-09-23 at 23:31 +0200, Oleg Verych wrote:
> * Sun, 23 Sep 2007 22:22:28 +0300
> * Organization: Home
>
> []
> >> >
> >> > So there, if one wants "ATI Radeon display support" on Radeon XPRESS 200M with
> >> > X using radeon_drv.so, *should* put "Framebuffer Console support" to N (if it's
> >> > not already).
> []
> > Bottom line: no radeonfb for me :( at least, not now; but I have to be honest with
> > you: I don't see what commit dd1447134454b169d5ae353aceb93f2368db8547 brought new
> > into the picture. The previous radeonfb worked just great, but then, again, maybe I'm
> > not using the console at it's full power :)
>
> In fact, it's known statement, that there must only one hardware driver
> for graphic adapter. Be it framebuffer with X fb driver on it or legacy
> VGA text and X with its driver.so and 3D stuff.
>
> (i choose legacy text without X for the most of my time, though :)
Not quite ... on PowerMacs, we've been routinely using radeonfb and X
together. However, for that to work, in general, one has to be careful
to switch back to console mode before suspending and back to X after
resume, which seems to have been broken by many distro lately, probably
because somebody made it optional in the kernel...
Ben.
On Sat, Sep 22, 2007 at 07:27:59AM +0200, Mihai Donțu wrote:
> Hi,
>
> Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet weekend).
> Anyway, it seems that radeonfb and my:
> "01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE)"
> don't get along anymore, by:
> a) X somehow fails to initialize the card and everything moves really slow (I can
> see how surfaces are drawn pixel-by-pixel); furthermore, garbage stuff appears
> on the screen;
Have you tried to boot your kernel with
video=radeonfb:noaccel
I usual add this kernel parameter when running radeonfb and X.
Otherwise I've observed the same symptoms (e.g. with my radeon card
at home: Radeon X300SE, 1002:5b70).
Regards,
Andreas
On Monday 24 September 2007, Andreas Herrmann wrote:
> Have you tried to boot your kernel with
>
> video=radeonfb:noaccel
>
> I usual add this kernel parameter when running radeonfb and X.
>
> Otherwise I've observed the same symptoms (e.g. with my radeon card
> at home: Radeon X300SE, 1002:5b70).
It works. Golden option. Should be documented somewhere.
Thanks,
--
Mihai Donțu
On Tue, 25 Sep 2007 10:09:29 +0300 Mihai Donțu wrote:
> On Monday 24 September 2007, Andreas Herrmann wrote:
> > Have you tried to boot your kernel with
> >
> > video=radeonfb:noaccel
> >
> > I usual add this kernel parameter when running radeonfb and X.
> >
> > Otherwise I've observed the same symptoms (e.g. with my radeon card
> > at home: Radeon X300SE, 1002:5b70).
>
> It works. Golden option. Should be documented somewhere.
Looks like radeonfb needs a radeonfb.txt file in
Documentation/fb/. There is a txt file for aty128fb which does
include this option and others...
---
~Randy
Phaedrus says that Quality is about caring.