this seems to be a regression from 6.8.2
if driver "savage" is selected in xorg.conf, video output is garbled (some
parts of screen appear in wrong places, pictures missing etc) and after a
little while the computer hangs completely (does not responf to any key
combination or network)
in 6.8.2, video was working without any problems with savage driver; changing
the driver to vesa results in a working system, too.
this is slackware-current with slackware provided packages
lspci line :
01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266]
Xorg.0.log contains a couple of warnings and one error :
(WW) SAVAGE(0): Failed to set up write-combining range (0x94000000,0x3000000)
(WW) SAVAGE(0): Failed to set up write-combining range (0x92000000,0x5000000)
(EE) SAVAGE(0): DRI isn't enabled
can you attach your xorg log and config?
you might try:
Option "disabletile" "true"
Option "BCIforXv" "false"
Also, when you say video output, do you mean the desktop itself or the playback
of a video file using Xv?
Created attachment 4606 [details]
xorg.conf without comments
attaching conf and logfile.
with video output i meant desktop itself - basically kde doesn't even finish
Created attachment 4607 [details]
(In reply to comment #3)
> with video output i meant desktop itself - basically kde doesn't even finish
did any of trhe options I suggested help? Also try setting:
Option "AGPMode" "4"
Option "AGPMode" "2"
depending on whether your board is AGP 4x or 2x capable.
sorry for not mentioning before - none of these options helped (including agp)
Option "usebios" "false"
ugh. i feel stupid. turns out, i have been setting the options in the wrong
when i moved them from server flags to video device section, a single parameter
got rid of the problem :
Option "disabletile" "true"
Added regression keyword. Any better luck using 7.1RC1?
i'm using slackware prebuilt packages - i don't feel brave or knowledgeable
enough to compile it myself, unfortunately.
It sounds like it may be DRI related. try playing with the following options:
see the savage man page for more about the options. You'll have to remove the
"disabletile" option to test these.
tried to play around with these parameters - saw no changes at all.
starting x both with and without disabletile produces :
mtrr: no more MTRRs available
twice in dmesg output (related to "Failed to set up write-combining range" ?).
(In reply to comment #12)
> tried to play around with these parameters - saw no changes at all.
> starting x both with and without disabletile produces :
> mtrr: no more MTRRs available
> twice in dmesg output (related to "Failed to set up write-combining range" ?).
I assume you still get lockups without disabletile? Are you using a kernel
framebuffer driver? FWIW, you can generally ignore the write combining
warnings. I suspect you have an MTRR set up for a kernel fb device that's
conflicting with X. Shouldn't hurt anything though; just potentially slightly
ugh. turns out, it is not a lockup as such, the computer just becomes EXTREMLY
slow and unresponsive.
first, the screen is garbled (after it has finished loading cached kde in 3 to
5 minutes..).. icons are offscreen, text is in incorrect locations. mouse
responds for half a second every 7 seconds or so.
i tried switching to the console, haven't got anything besides blank screen for
3 minutes now.
it seems that there is a really big load on the computer, as it's ventilation
is not turning off at all now (it normally just turns on now and then); trying
to ssh into it times out.
i am using savagefb in kernel
(In reply to comment #14)
> i am using savagefb in kernel
that's the problem. Savagefb and the current X savage driver are not compatible.
ahh. and which one is "the guilty one" ?
will this be fixed in x.org, or should i file a report against savagefb ?
(In reply to comment #16)
> ahh. and which one is "the guilty one" ?
Depends on you persepctive :)
> will this be fixed in x.org, or should i file a report against savagefb ?
Probably both. I think the X driver needs to save and restore some additional
streams and 3D related regs; however that should really only affect VT switching
and console restoration. the fact that X has problems starting means that
savagefb is doing something weird to the hardware that the X server doesn't
like. For the time being, I would say use vesa of vgafb for console.
Did disabling the fb-driver resolve your problem?
(In reply to comment #18)
> Did disabling the fb-driver resolve your problem?
hmm. meaning savagefb ?
actually i filed a report at kernel bugzilla, where a couple of patches were
made. after applying them, my computer is happily working with savagefb and x.
org savage driver.
the patch was added to -mm at 22/04/2006 - i'm not sure where it went after
The patch titled
savagefb: Add state save and_restore hooks
has been added to the -mm tree. Its filename is
here's the entry at kernel bugzilla :
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
So was this entirely a kernel issue? Can this be closed out?
comment #17 said "I think the X driver needs to save and restore some additional
streams and 3D related regs" - but i don't have access to the hardware anymore, so feel free to close this
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.