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" and/or 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 loading
Created attachment 4607 [details] Xorg.0.log
(In reply to comment #3) > > with video output i meant desktop itself - basically kde doesn't even finish > loading did any of trhe options I suggested help? Also try setting: Option "AGPMode" "4" or 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)
try: Option "usebios" "false"
ugh. i feel stupid. turns out, i have been setting the options in the wrong section... 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: "DmaMode" "DmaType" "BusType" 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 lower performance.
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 that. The patch titled savagefb: Add state save and_restore hooks has been added to the -mm tree. Its filename is savagefb-add-state-save-and_restore-hooks.patch here's the entry at kernel bugzilla : http://bugzilla.kernel.org/show_bug.cgi?id=6417
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.