Summary: | Savage hangs, conflicts with savagefb | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | richlv <richlv> | ||||||
Component: | Driver/savage | Assignee: | Tormod Volden <bugzi11.fdo.tormod> | ||||||
Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | major | ||||||||
Priority: | high | CC: | alexdeucher, erik.andren | ||||||
Version: | 6.9.0 | Keywords: | regression | ||||||
Hardware: | x86 (IA32) | ||||||||
OS: | Linux (All) | ||||||||
Whiteboard: | 2011BRB_Reviewed | ||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
Description
richlv
2006-02-14 02:39:39 UTC
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.