LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   13.37-rc4+ ATI issues (http://www.linuxquestions.org/questions/slackware-14/13-37-rc4-ati-issues-874753/)

TwinReverb 04-13-2011 07:05 AM

13.37-rc4+ ATI issues
 
All,

I've been having issues with Slackware 13.37-rc4+ on my Acer Aspire 4551-4315 recently and I'm not sure where they're coming from. I get a hard lock-up fairly often and seemingly random times. I think it's graphics card related (ATI Mobility Radeon HD 4200).
First I thought it was hard drive related, due to a bad sector that cropped up on my hard drive. I had experienced the graphics lockups before this but after installing ATI drivers (13.37-rc3 I think) they seemed to go away, but then I got the bad sector so I replaced the hard drive (WD Caviar Blue 320GB stock to WD Caviar Blue 750GB).
Today I got them on a new install of Slackware 13.37-rc4+ with no proprietary drivers (just generic-smp 2.6.37.6 kernel) and no xorg.conf. I thought maybe it was due to not having the proprietary drivers, so I installed them (successfully). But the problem kept coming back, hard locking (this laptop has no caps lock LED so don't know if that was flashing), sometimes with an all-white screen, sometimes all black, sometimes pinstriped. (With the kernel drivers it would lock to black only, if that helps.) Once I even got it with non-proprietary drivers due to a screensaver start (switched to VT5 and could see my rsync jobs in top still going, but then in about 15 seconds the whole machine died).
So far right now I'm using the framebuffer module (i.e. I removepkg'd all xfce86-video-* except fb dummy v4l and vm type).
I tried launching tail -f /var/log/[messages|debug|syslog|Xorg.0.log] and watching all while my rsync job was going (restoring from backup to /home/robert) and didn't see anything. Tried enabling all debug from LILO command line using DYNAMIC_DEBUG KGDB acpi.debug_layer=0x2 acpi.debug_level=0xffffffff apic=debug pnp.debug bootmem_debug debug debugpat debug_locks_verbose=1 debug_objects sched_debug ignore_loglevel memblock=debug print_fatal_signals=debug acpi.enforce_resources=lax and still found nothing useful in the logs.
Checked smartctl -a /dev/sda for any remapped sectors, none found (zero: brand new drive).

I've included what files I thought you'd find useful. These logs are not broken up, so basically where you see fglrx mentioned is after I installed the fglrx.

Xorg.0.log.old (lockup) http://pastebin.mozilla.org/1203523
/var/log/dmesg http://pastebin.mozilla.org/1203524
lspci http://pastebin.mozilla.org/1203525
syslog http://pastebin.mozilla.org/1203526
/var/log/messages http://pastebin.mozilla.org/1203527
lsmod (without ATI Proprietary) http://pastebin.mozilla.org/1203528

(Note that for some reason on first boot an intel speedstep cpufreq module of some sort was loaded, can't remember which, but I blacklisted it and fixed /etc/rc.d/rc.modules accordingly.)

Someone please help me out here, I'm at my wit's end.

adamk75 04-13-2011 08:00 AM

Well, the most obvious thing that jumps out at me from the Xorg log file is:

Code:

[    65.719] (EE) fglrx(0): ACPI: DRM connection failed
[    65.719] (WW) fglrx(0): Hasn't establisted DRM connection
[    65.719] (II) fglrx(0): [FB] MC range(MCFBBase = 0xc0000000, MCFBSize = 0x10000000)
[    65.719] (WW) fglrx(0): No DRM connection for driver fglrx.

Which suggests that, at least at that time, the fglrx kernel module wasn't installed, or the version of the fglrx kernel module was different from the version of the fglrx Xorg module. I suggest removing fglrx entirely, removing any fglrx.ko files anywhere under /lib/modules/ and then reinstalling the driver.

Adam

Didier Spaier 04-13-2011 08:25 AM

Well, I would begin from the beginning.

First, re-install a fresh Slackware-current and don't modify anything.

Then boot (at runlevel 3) it with "vga=normal" appended to the command line, in order not to use any framebuffer driver which could interfere with your X driver.

Then you don't need to removepkg any xf86-video-<something> driver, but type 'startx' and see what happens.

If something goes wrong, write a small video.xorg.conf file in /etc/X11/xorg.conf.d to tell X which video driver to use. Begin with "vesa" which is usually a safe bet:
Code:

Section "Device"
Identifier "my_video_driver"
Driver "vesa"
EndSection

If it works, then you can the try to change it with some more feature-rich driver, e.g. write 'Driver= "ati"' instead of 'Driver = "vesa"'.
'
Of course if it works you can try the proprietary driver too.

Oh, and "removepkg xfce86-video-*" in you post was a typo, should read "removepkg xf86-video-*" instead -- but again, this is unnecessary.

HTH,

TwinReverb 04-13-2011 05:02 PM

Thanks for all replies.

I think the fglrx error in the log may have been user error, as it worked every time I ran it, just that during transfer from USB it died. That may be a resume from suspend (because I tried suspend with those previous instances and it resumed but the video didn't resume, pressing the power button for only a split second resulted in an orderly shutdown).

I got the lock-up with default non-framebuffer VESA as well as the kernel-based ATI and proprietary ATI, so my switch to VESA didn't remedy the situation.

I recompiled a kernel based on generic-smp but with sata, kernel, usb, and agp debug enabled, trimmed what I know I don't have from the kernel config (converting what this laptop doesn't have to modules or, in the sense of PCI/PCIe devices I cannot install, removing them; disabling stack protections and the new ATI modesetting and other things that I thought might cause a mis-compile). Anyways, rebooted with that kernel, installed proprietary ATI, and so far I have no issues (key words: so far).

I'm going to research if there's something the ATI proprietary likes or does not like in the kernel and get back with you, but so far (fingers crossed) no issues.

EDIT: Key words, it worked in the past with ATI, which is why I'm wondering if it's something recent. I can't think it's a hardware issue (other than it simply being an ATI card :) because it didn't have such weird issues in Windows (I was "land-locked" in Windows for a few days due to a bad sector on previous hard drive that just happened to be in my Slackware / partition's district).

adamk75 04-13-2011 05:05 PM

If it's happening with the vesa driver, I'd be inclined to believe that this isn't a driver issue at all. If it is related to graphics, it may just be a hardware issue.

Adam

TwinReverb 04-16-2011 03:17 AM

OK, so far I recompiled the kernel, leaving out gcc stack protection, switching to 586/686, leaving out all SATA and AGP cards that I don't have and leaving out the new ATI Mode Switching. So far, when Skype is not running, I don't get hard locks. When Skype is running (seems to be the common ground once ATI proprietary drivers are working) I sometimes get hard locks.

Is there a way to dig deeper into this with debug or something to try and figure out what's causing the hard lock? Is there a way to run Skype in a "condom" or chroot that should prevent any issues?

I don't get where the problem is. My /var/log/debug is 2GB. I think usbstorage, agp, and sata are all compiled with DEBUG. I may change this and see if it's some other issue like Skype (V4L/Alsa) or software.

So far my remapped sector count on this hard drive is zero (unless it hides the info from SMART).

I searched the internet a LOT for known kernel + ATI issues. The most I found is some forum saying that it does NOT like ATI ModeSetting. Other than that, nothing really.

Other than using sed to set ALL the DEBUG lines in the kernel to "=y", I have no clue what to do here. Someone please help me out here.

TwinReverb 04-16-2011 03:58 AM

<deleted>

TwinReverb 04-16-2011 04:14 AM

Update: I was running Skype 2.1.0.81, downloading 2.2.0.25 right now. Also read Eric Hameleer's "alien pastures" blog on the subject of KDE Compositing and disabled it just to be on the safe side (disabled in KDE, enabled in Xfce).


All times are GMT -5. The time now is 11:06 AM.