[SOLVED] Kernel Screensaver problem

business_kid · 11-11-2014, 07:01 AM

All works after a fairly normal fashion except the screen goes fairly bright white instead of dark. We are talking kernel screen saver in Console mode, not screensaver in X. All worked normally before :-o.

The box: slackware-current as of 30-09-2014 installed on a vintage 2007 HP6715S, All-AMD laptop, Twin Turion, 3G RS690/SB600 chipset and RS690M/x1250/r3xx pcie GPU. There is llvm installed, but I have no idea if it's working.

mlslk31 · 11-12-2014, 12:32 PM

You might Google "rs690m backlight" and see what comes up. I don't know anything about what seems to be in the Radeon family of chipsets.

I get this same problem on Intel, but it's usually one of two things. 1) I compiled all of the backlight and LCD drivers out of the kernel; or 2) something VGA or especially KMS is acting up. There's a program called "setterm" that fires from /etc/rc.d/rc.M. At work, it's set like `setterm -blank 20 -powersave off -powerdown 60`. For testing purposes, you can issue that command like `setterm -blank 1 -powersave off -powerdown 1` and see if your monitor shuts off after a minute of activity. The "-powersave" setting has had to be changed several times to dodge kernel warnings, so you might issue a `dmesg` command to see if anything is unusual there.

There are other things that could go wrong, too. I'd look at that dmesg output to see if the kernel has taken issue with your ACPI setup as well. If in doubt, post the output.

Maybe the AMD/ATI/Radeon pros might weigh in here, they'll most certainly give a better answer than what I just gave.

business_kid · 11-12-2014, 02:37 PM

Thanks for the reply. I will play with setterm.

Anyone who still has an RS690M is not too fussy about video quality :-/. So I am not expecting heavyweights on what is a B.S card to chime in with their expertise. I think it's a largely white background from the video out, and not the backlight at all.

mlslk31 · 11-12-2014, 04:49 PM

Hmmm...with my eldest flat-screen monitor, the white screen is like looking into a 10-watt light bulb from the front, more like a 25-watt bulb from the side and top views. It might get a little worse after the console has blanked.

Can you see the text OK after the monitor has been un-blanked?

business_kid · 11-13-2014, 05:59 AM

Everything is fine at once if I unblank the screen. It's not a hard full on, but a white as like the background of a white terminal. We're talking a laptop, tft screen, and no oversaturation, although it makes a bright night light if you want that (Which I don't).

I tried setterm. powerdown and powersave options are ignored; -blank gives me white :-/; -inversescreen gives me the type of white I get on -blank with black writing; with inversescreen active, -blank gives a whiter white :-O!

So I checked dmesg. Attached are some random pieces where various things are bellyaching

Code:

[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Node 0: aperture @ 9050000000 size 32 MB
[    0.000000] Aperture beyond 4GB. Ignoring. #It always does that!
[    0.000000] tsc: Fast TSC calibration failed
[    0.000000] tsc: Unable to calibrate against PIT
[    0.000000] tsc: using PMTIMER reference calibration
[    0.000000] tsc: Detected 1991.463 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized

[    0.359059] ACPI: Interpreter enabled
[    0.359123] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20131218/hwxface-580)
[    0.359255] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20131218/hwxface-580)
[    0.359405] ACPI: (supports S0 S3 S4 S5)

[    0.382534] pci 0000:00:13.4: System wakeup disabled by ACPI#I get this one about 10 times
[    0.390435] pci_bus 0000:03: busn_res: can not insert [bus 03-ff] under [bus 02-03] (conflicts with (null) [bus 02-03])
[    0.390441] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 06
[    0.390445] pci_bus 0000:03: busn_res: can not insert [bus 03-06] under [bus 02-03] (conflicts with (null) [bus 02-03])
[    0.390450] pci_bus 0000:03: [bus 03-06] partially hidden behind transparent bridge 0000:02 [bus 02-03]
[    0.390574] pci_bus 0000:00: on NUMA node 0
[    0.391022] ACPI: PCI Interrupt Link [C145] (IRQs 10 11) *0, disabled.
[    0.391339] ACPI: PCI Interrupt Link [C146] (IRQs 10 11) *0, disabled.
[    0.391653] ACPI: PCI Interrupt Link [C147] (IRQs 10 11) *0, disabled.
[    0.391966] ACPI: PCI Interrupt Link [C148] (IRQs 10 11) *0, disabled.
[    0.392286] ACPI: PCI Interrupt Link [C149] (IRQs 10 11) *0, disabled.
[    0.392602] ACPI: PCI Interrupt Link [C14A] (IRQs 9) *0, disabled.
[    0.392884] ACPI: PCI Interrupt Link [C14B] (IRQs 10 11) *0, disabled.
[    0.393191] ACPI: PCI Interrupt Link [C14C] (IRQs 10 11) *0, disabled.
[    0.393872] ACPI: Enabled 8 GPEs in block 00 to 1F # dmesg has alway been full of this sort of stuff - alarming, but it works somehow 

[    3.544924] microcode: AMD CPU family 0xf not supported
[    3.549278] microcode: AMD CPU family 0xf not supported
[    3.830265] k8temp 0000:00:18.3: Temperature readouts might be wrong - check erratum #141

[    6.366552] WARNING! power/level is deprecated; use power/control instead


[  237.559485] tumblerd[898]: segfault at 0 ip 00007f55924e5972 sp 00007fff9ec5a2b0 error 4 in libtumbler-1.so.0.0.0[7f55924de000+b000]
[  237.606468] tumblerd[903]: segfault at 0 ip 00007f4ba0eb7972 sp 00007fffc0574b00 error 4 in libtumbler-1.so.0.0.0[7f4ba0eb0000+b000]

Amidst all that, video is remarkably alarm free. Despite all this, everything _else_ works pretty well. I did leave out some less inconsequential ACPI errors. My reaction to reading dmesg is as it has always been "Why does anything work on this box?"

mlslk31 · 11-13-2014, 10:15 AM

I'm wondering about that myself...and about what to do without wasting your time. There's probably a display driver glitch of some sort, but I don't know what driver you're using now...or which driver was in use when the PC was running correctly.

On Intel, you can pass something like "drm.debug=0xe" to the kernel, and every last thing done to the console will be added to dmesg output, including screen blanking and shutting the display off. It looks like it could work for all DRM drivers, assuming you're not running your laptop in standard VGA mode. That magic One Page of Documentation for Generic Options is eluding me, though.

I've been having fairly good luck passing "mmconfig=bios" to the kernel when booting older PCs. This is the part where I'd tinker in the BIOS setup program to get things jiggled into place, but that may not work and waste time along the way. Still, PCI is choosing between 2 IRQs instead of many IRQs, and the CPU timestamp counter (TSC) is being rejected outright. Lots of things having to do with power and sleep are not being auto-configured correctly. tumblerd is segfaulting, but that might be a separate userspace issue. [New glibc issue, or an upgrade issue?]

What does `cat /proc/interrupts` show? It shouldn't matter much--nothing's locking up--just curious about what happened to the other 14-22 interrupts on the system.

Also, what display drivers are you using? Maybe with the output of one of these commands...

fbset -i
lspci -v | grep "^..:\|driver in use"

...I'd have a name to use when surfing LKML or the DRM Bugzilla. If you're using slackware-current, does that mean you're using kernel 3.14 as well?

business_kid · 11-14-2014, 10:58 AM

Code:

What does `cat /proc/interrupts` show? It shouldn't matter much--nothing's locking up--just curious about what happened to the other 14-22 interrupts on the system.
Also, what display drivers are you using? Maybe with the output of one of these commands...
    fbset -i
    lspci -v | grep "^..:\|driver in use"
...I'd have a name to use when surfing LKML or the DRM Bugzilla. If you're using slackware-current, does that mean you're using kernel 3.14 as well?

Well I can save you a bit of bother; Kernel 3.14.18, radeon kernel module is the relevant display driver; mesa 10.2.6( & compat32-10.2.6) xf86-video-ati-7.4.0 are ok running in X. The interrupts thing is a weirdness of my most recent kernel, and I will drop back a version. I have interrupts numbered up to 43 and some named ones with 3 letters on the slackware kernel.

I am marking this one solved. It is anything but solved. But frankly, the screensaver is the least of my worries atm. Some other issues are:

wlan0 stopped working since yesterday.
I got online with a usb wifi from my raspberry pi, but I couldn't post as firefox goes out to lunch
Suddenly since yesterday it takes ages for X to start - it's sitting there for a full minute
Although I am online, I can't ping the router (192.168.0.1) but I can ping another box (192.168.0.103) through the router :-/.

FYI, here's the o/p of fbset -i (done in a console sent >> file)

Code:

mode "1280x800"
    geometry 1280 800 1280 800 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

Frame buffer device information:
    Name        : radeondrmfb
    Address     : 0xc0040000
    Size        : 4096000
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 5120
    Accelerator : No

lspci -v | grep "^..:\|driver in use"

Code:

00:00.0 Host bridge: AMD/ATI [Advanced Micro Devices, Inc.] RS690 Host Bridge
00:01.0 PCI bridge: AMD/ATI [Advanced Micro Devices, Inc.] RS690 PCI to PCI Bridge (Internal gfx) (prog-if 00 [Normal decode])
00:04.0 PCI bridge: AMD/ATI [Advanced Micro Devices, Inc.] Device 7914 (prog-if 00 [Normal decode])
	Kernel driver in use: pcieport
00:05.0 PCI bridge: AMD/ATI [Advanced Micro Devices, Inc.] RS690 PCI to PCI Bridge (PCI Express Port 1) (prog-if 00 [Normal decode])
	Kernel driver in use: pcieport
00:06.0 PCI bridge: AMD/ATI [Advanced Micro Devices, Inc.] RS690 PCI to PCI Bridge (PCI Express Port 2) (prog-if 00 [Normal decode])
	Kernel driver in use: pcieport
00:12.0 SATA controller: AMD/ATI [Advanced Micro Devices, Inc.] SB600 Non-Raid-5 SATA (prog-if 01 [AHCI 1.0])
	Kernel driver in use: ahci
00:13.0 USB controller: AMD/ATI [Advanced Micro Devices, Inc.] SB600 USB (OHCI0) (prog-if 10 [OHCI])
	Kernel driver in use: ohci-pci
00:13.1 USB controller: AMD/ATI [Advanced Micro Devices, Inc.] SB600 USB (OHCI1) (prog-if 10 [OHCI])
	Kernel driver in use: ohci-pci
00:13.2 USB controller: AMD/ATI [Advanced Micro Devices, Inc.] SB600 USB (OHCI2) (prog-if 10 [OHCI])
	Kernel driver in use: ohci-pci
00:13.3 USB controller: AMD/ATI [Advanced Micro Devices, Inc.] SB600 USB (OHCI3) (prog-if 10 [OHCI])
	Kernel driver in use: ohci-pci
00:13.4 USB controller: AMD/ATI [Advanced Micro Devices, Inc.] SB600 USB (OHCI4) (prog-if 10 [OHCI])
	Kernel driver in use: ohci-pci
00:13.5 USB controller: AMD/ATI [Advanced Micro Devices, Inc.] SB600 USB Controller (EHCI) (prog-if 20 [EHCI])
	Kernel driver in use: ehci-pci
00:14.0 SMBus: AMD/ATI [Advanced Micro Devices, Inc.] SBx00 SMBus Controller (rev 14)
	Kernel driver in use: piix4_smbus
00:14.1 IDE interface: AMD/ATI [Advanced Micro Devices, Inc.] SB600 IDE (prog-if 82 [Master PriP])
	Kernel driver in use: pata_atiixp
00:14.2 Audio device: AMD/ATI [Advanced Micro Devices, Inc.] SBx00 Azalia (Intel HDA)
	Kernel driver in use: snd_hda_intel
00:14.3 ISA bridge: AMD/ATI [Advanced Micro Devices, Inc.] SB600 PCI to LPC Bridge
00:14.4 PCI bridge: AMD/ATI [Advanced Micro Devices, Inc.] SBx00 PCI to PCI Bridge (prog-if 01 [Subtractive decode])
00:18.0 Host bridge: AMD [Advanced Micro Devices, Inc.] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: AMD [Advanced Micro Devices, Inc.] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: AMD [Advanced Micro Devices, Inc.] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: AMD [Advanced Micro Devices, Inc.] K8 [Athlon64/Opteron] Miscellaneous Control
	Kernel driver in use: k8temp
01:05.0 VGA compatible controller: AMD/ATI [Advanced Micro Devices, Inc.] RS690M [Radeon Xpress 1200/1250/1270] (prog-if 00 [VGA controller])
	Kernel driver in use: radeon
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)
	Kernel driver in use: yenta_cardbus
10:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M Fast Ethernet PCI Express (rev 02)
	Kernel driver in use: tg3
30:00.0 Network controller: Broadcom Corporation BCM4311 802.11a/b/g (rev 02)
	Kernel driver in use: b43-pci-bridge

The fact that the Broadcom 4311 shows on the pcibus is a sign of rude good health. But it refuses ifconfig wlan0 up - 'no such device.' :-o!

There is also the weirdness that if it is powered off for a while, I get 2 minutes from firefox before it goes out to lunch. That kind of thing (working for a minute then no more) is a telltale sign of hardware dying. The box was manufactured in 2007.

I personally suspect a southbridge (SB600) issue, but really, without the details, I couldn't be more precise. It's also possibly a voltage issue, as the battery blew away the charging circuit and a new battery was not detected or charged. It's been like that for some years. I can't get voltage measurements out of the bios but I don't have to think too hard before slinging it. I can drop back to slackware-13.37 if need be.

The irritating thing is that the screensaver worked when I was on the install CD.

business_kid · 11-15-2014, 08:43 AM

Well, my last kernel build somehow obliterated the /lib/firmware directory and I lost my b43 firmware. All the X related problems have vanished on the box(along with the usb wifi adapter), and firefox is no longer going out to lunch. All good.

The screensaver remains an issue. I am going to post on phoronix forums, and will post back if anything comes of that. AMD developers hang out there. You sometimes get something useful from them.

mlslk31 · 11-15-2014, 09:06 PM

Excellent!

DRM/Radeon is a product listed at the freedesktop.org Bugzilla:

https://bugs.freedesktop.org/buglist.cgi?component=DRM%2FRadeon&product=DRI

I didn't see a matching entry for "console blank white" or "RS690M", but at least Dave Airlie was handling the first bug I clicked, a good sign. It's worth a try. The Intel guys hang out in the DRM/Intel section, and the console problems I posted there were resolved in short order.

business_kid · 11-16-2014, 11:02 AM

Staying on the new install, I dropped back in my available kernels on local ftp mirror and backups
Swapping nothing but kernel & modules and staying on Slackware-=current, with the slackware-huge kernel and not my own compiles,

Kernel 3.14.18 & kernel 3.10.17 go white on the console screensaver - X not running.
Kernel 3.2.29 goes black as it should. As I only changed the kernel, that's a fairly clear kernel bug.

I am going to post here looking for some more approved kernels, and try to narrow the range down somewhat.

mlslk31 · 11-16-2014, 07:33 PM

If you're handy with git, you could bisect the problem down to the exact commit. This means taking (preferably) the Linus kernel tree or the -stable kernel tree from git.kernel.org, then building 14-16 kernels to figure out which was the very first bad kernel. That way, you have a better case when you find AMD developers and contact them. If git is installed on your PC, `git help bisect` or `man git-bisect` should give an overview of the process.

Note that I don't know how much abuse laptop drives can take, so it might be safer to build on a desktop machine and transfer the files over to the laptop. Also, bisects go better on the Linus tree, but the -stable tree is the tree that has the vX.Y.Z version tags (like "v3.10.60") in them. The Linus tree has just the vX.Y and vX.Y-rcN version tags (like "v3.17" and "v3.18-rc4"), at least for v3.X kernels.

business_kid · 11-17-2014, 05:00 AM

Thanks for that. The "Slackware" kernel source _is_ the Linux kernel source, afaict. I am not aware of any kernel patching being done in slackware.

So I grab the latest git kernel, and start hacking with git-bisect. That is one download, and doable during the week. Any suggestions on how to handle the config? Start with a config from 3.10.17 I suppose? Hack out the extra modules, and that should do it. As for doing it on a desktop, I only have 2 laptops here atm. I think I will take my chances with the turion, rather than lay wear on the ssd in the other. That box is past it's normal life expectancy anyhow.

mlslk31 · 11-17-2014, 09:47 AM

Keep a good config in your home directory, in case you need it. When switching kernel versions, a `make oldconfig` can be tedious, and I'll get lazy and start running `make oldnoconfig` or `make olddefconfig` after a while. As for trimming, look for things in the USB and input/HID sections for drivers you'll never use (webcams and joysticks here); then go into graphics, sound, and networking to remove drivers you'll never use.

Once you get your git kernel (Linus tree or otherwise), be sure to tar it first. That way, you have a fast way to start in case the kernel tree gets scrambled beyond what a `git reset --hard master` can fix.

The general approach is to start a bit like this:

Code:

# This example assumes that v3.11 is indeed a bad kernel.
# Might compile a v3.11 kernel before starting this, else it's a long and tedious dead end!

git bisect start
git bisect good v3.2
# If you want to bisect from v3.2 to the current commit, the command is just "git bisect bad"
git bisect bad v3.11

# Update the config.  `make menuconfig` can be used here, as with tarball kernels.
zcat /proc/config.gz > ~/GOOD-CONFIG
zcat /proc/config.gz > .config
make oldconfig

# Make the kernel:
make && make modules && make modules_install && make install

# This is in case the firmware gets lost again, doesn't need to be run throughout the bisect:
make firmware_install

If you reboot to a bad kernel, it goes like this:

Code:

cd /usr/src/linux
git bisect bad
# In some cases, you might have to get that good config that was saved elsewhere, but for now:
make oldconfig            # or `make oldnoconfig` or `make menuconfig`, etc.
make && make modules && make modules_install && make install

If you reboot to a good kernel, just substitute `git bisect good` in there.

Should you need to simply check out a kernel to try out before the bisect, it can go like this:

Code:

git branch local-3.11 v3.11
git checkout local-3.11
# Go through the normal kernel steps from here...

To see what commit you're actually on, `git log` is the fastest way to do it. This applies to just about all source code that is downloaded using git. `git bisect log` shows where you've gone so far. `git bisect reset` resets things to the commit that you had checked out before the reset.

Good luck!

business_kid · 11-17-2014, 01:12 PM

Thanks. I gave it 3.2.29 good and 3.10.17 as bad, and the first one was 3.10.0 :-/.
Anyhos, IO did update the firmware. I will do a make install firmware next time, as the b43 module has stopped loading firmware, and I get it growling at me in the logs. fscking the disk because lilo managed to boot a kernel I had deleted :-O!

Expect this to go quiet for a few days.

business_kid · 11-18-2014, 03:30 AM

Just as I stand, I'm down to 3.6 (good) - 3.8(bad) atm. I got this on the phoronix site
http://www.phoronix.com/forums/showt...d=1#post454183

So I can reset and build the 3.17 tree to see if that sorts it.