if that helps in any way - disabling ddc2 and console acceleration for savagefb 
did not change anything.

This is a problem with Xorg incompletely restoring some critical hardware
registers which savagefb altered. But with recent kernels, the framebuffer layer
has functionality to restore the hardware into some sane state from which X can
start working on, so hopefully preventing Xorg from completely hanging.

I'm attaching 2 patches, apply them in order as the second patch relies on the
first one.  Please try first without DRI, and if it works, you can try with DRI.

Created attachment 7928 [details]
Allocate structure for current and default register states

Apply this first

Created attachment 7929 [details]
Create hook to save and restore hardware state

Apply this on top of the first patch

seems that it is working fine with these patches (though there are several 
garbled screens just as x starts shown).

i have ddc2 and console acceleration enabled, but had dri disabled. enabling it 
results in x.org claiming that dri is not used, so probably my chipset just 
doesn't have proper support for that, right ?

> seems that it is working fine with these patches (though there are several 
> garbled screens just as x starts shown).

Does the corruption disappear spontaneously?  Does switching to and from X and
console work properly?

> i have ddc2 and console acceleration enabled, but had dri disabled. enabling it 
> results in x.org claiming that dri is not used, so probably my chipset just 
> doesn't have proper support for that, right ?

Possibly, I'm not sure if savagedri is already included in the main Xorg source.
I'll try it out myself...

1. "Does the corruption disappear spontaneously?"
well, depends what you mean with that :)
they appear before x screen as such is drawn - a couple of screens with dots 
appear for a half of a second each, one is b/w, other with colorful dots =)
after x has started, there are no visible screen artifacts.

2. "Does switching to and from X and console work properly?"
yes. switching from console to x results in single very short appearance of 
vertical white lines, switching from x to console results in colorful vertical 
lines flickering 2 or 3 times before console itself is drawn.

3. it seems that in some cases i have a problem that might or might not be 
connected - cursor position is incorrect in console. cursor blinks somewhere in 
the screen, text is entered at the correct location.
if this problem appears when mc is running, several black blocks are spread 
across the screen and cursor blinks in one of them.
i have seen this behaviour before applying these patches (but not before 2.6.16
), but i haven't found a reliable way to reproduce them (this doesn't happen 
always), thus no dedicated bugreport yet.

> they appear before x screen as such is drawn - a couple of screens with dots 
> appear for a half of a second each, one is b/w, other with colorful dots =)
> after x has started, there are no visible screen artifacts.

Ahh, okay, I thought it was X's screen that was garbled.  I guess the garbling
is understandable, since savagefb, just before X loads, is writing the saved
state to the hardware registers, thus the artifacts.  Perhaps, I can blank the
screen while writing to the registers if this is really, really bothersome...

> yes. switching from console to x results in single very short appearance of 
> vertical white lines,

Same reasoning as above...

> switching from x to console results in colorful vertical 
> lines flickering 2 or 3 times before console itself is drawn.

This should be X's job, perhaps it can also blank the screen while restoring the
registers just before the console switch...

> 3. it seems that in some cases i have a problem that might or might not be 
> connected - cursor position is incorrect in console. cursor blinks somewhere in 
> the screen, text is entered at the correct location.
> if this problem appears when mc is running, several black blocks are spread 
> across the screen and cursor blinks in one of them.
> i have seen this behaviour before applying these patches (but not before 2.6.16
> ), but i haven't found a reliable way to reproduce them (this doesn't happen 
> always), thus no dedicated bugreport yet.

I'll try to reproduce this myself and just open a separate bugzilla report if
you chance on this bug again.

I'll submit this patch to the -mm tree for testing. Is it okay if I close this bug?

> Perhaps, I can blank the screen while writing to the registers if this is 
really, really bothersome...

it doesn't bother me much, i'm sort of used to it already - but every single 
bith counts when i'm showing off my linux laptop to others ;)
so, it would be nice unless that is a lot of work or introduces unacceptable 
overhead

> Is it okay if I close this bug?

i think yes, the primary problem is solved and i'll try reproducing & 
submitting separately the one about traveling cursor.

It would only take a few lines at the most to blank the screen, so yes, I'll
just hide the transient artifacts.

I will submit the final patch to Andrew Morton and I will include you on the CC
list. Resolving this bug, thank you for the report. 

these patches were not included in 2.6.17 - how could i help to speed up their 
inclusion ?
i have been using kernel compiled with them all this time without any problems.

It was too late for 2.6.17, so expect it by 2.6.18-rc1.