You are not logged in.
The last working kernel for me is 3.4.9-1
system info:
VGA compatible controller: Advanced Micro Devices [AMD] nee ATI M64-S
[Mobility Radeon X2300] (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company 6910p
With the all new kernels I cannot get my laptop to work.
Without nomodeset in Kernel Mode Setting the system freezes momentarily
-Decompresing Linux...Parsing ELF..done
Booting the kernel
When i pun nomodeset in Kernel Mode Setting the freezing is by
-Reached target Graphical Interface
Last edited by mini (2013-02-07 20:08:29)
Offline
I cannot find any xorg-video-modesetting in Package Database
Offline
Thank you for your help, but system still freezes at
-Reached target Graphical Interface
Offline
Does CTRL+ALT+F1 work ?
if so , you can login to console and view Xorg.0.log for errors.
If not, boot from a rescue cd/usbstick and use chroot (see the wiki for details) to troubleshoot.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Yes, i can read xorg.0.log but i do not know what is the problem:
....
(II) KMS drm report modesetting isn't supported
KMS drm report modesetting isn't supported
KMS drm report modesetting isn't supported
(EE) Screen 0 deleted because of no matching config section
(II)UnloadModule "radeon"
(II)UnloadModule "radeon"
Fatal server error..
I have not any xorg.conf file
Offline
Ok, the failure when starting X is now clear :
you boot up with nomodeset = KMS disabled, and xf86-video-ati only works with KMS enabled, so x fails to start.
As a temporary workaround you could remove xf86-video-ati , and install xf86-video-vesa instead.
graphics will be slow then without any accelaration, but X should work.
did you have the ati proprietary driver fglrx installed in the past ?
if so, a remnant of fglrx might be preventing KMS to work correctly.
Check the arch wiki on radeon.
the output of lspci on your system and a dmesg from a boot with a recent kernel would be helpful.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thanks a lot for your input. I have not installed catalyst (fglrx) in the past, maybe for many weeks ago.
Sorry for stupid question. Which way can I check remnant of fglrx driver?
Offline
Thanks a lot for your input. I have not installed catalyst (fglrx) in the past, maybe for many weeks ago.
Sorry for stupid question. Which way can I check remnant of fglrx driver?
that can be tough, but some things to check :
/etc/modules-load.d/
/etc/modprobe/
pacman -Qs dkms (if any dkms pacakages are present, they should be removed)
dmesg | grep fglrx
Last edited by Lone_Wolf (2013-01-30 09:48:48)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I do not find any remnant of fglrx driver. It is something strange with the new kernels because my radeon driver works very well with kernel 3.4.9-1, so i am back on it.
Offline
Check your Xorg0.log from 3.4.9-1 .
I think you'll find X is using User Mode Switching (UMS) instead of Kernel Mode Switching (KMS) .
If that's correct, then the problem between KMS and your card exists in kernel 3.4.9 also.
(UMS was disabled in the radeon kernel module at some point, but i can't find in which kernel version that was)
Either way, this seems to be a kernel/driver bug.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
From my Xorg0.log:
[ 18.088] (II) [KMS] Kernel modesetting enabled.
[ 18.088] (II) RADEON(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/32
[ 18.088] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
[ 18.088] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[ 18.088] (==) RADEON(0): Default visual is TrueColor
[ 18.088] (==) RADEON(0): RGB weight 888
[ 18.088] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[ 18.088] (--) RADEON(0): Chipset: "ATI Mobility Radeon X2300" (ChipID = 0x7188)
[ 18.088] (II) Loading sub module "dri2"
[ 18.088] (II) LoadModule: "dri2"
[ 18.088] (II) Module "dri2" already built-in
[ 18.088] (II) Loading sub module "exa"
[ 18.088] (II) LoadModule: "exa"
[ 18.088] (II) Loading /usr/lib/xorg/modules/libexa.so
[ 18.104] (II) Module exa: vendor="X.Org Foundation"
[ 18.104] compiled for 1.13.2, module version = 2.6.0
[ 18.104] ABI class: X.Org Video Driver, version 13.1
[ 18.104] (II) RADEON(0): KMS Color Tiling: enabled
[ 18.104] (II) RADEON(0): KMS Color Tiling 2D: disabled
[ 18.104] (II) RADEON(0): KMS Pageflipping: enabled
BTW today it has been updated ati driver to xf86-video-ati 1:7.1.0-1, but for my Radeon X2300 it has not helped.
Offline
Ok, my assumption about UMS was clearly wrong, so i did some searching.
Check out this redhat bug report : https://bugzilla.redhat.com/show_bug.cgi?id=845745
In comment #102 of that bugreport a workaround is mentioned that solved the problem for several people.
I suggest you try out that workaround
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
You are the best. When I run:
modprobe -r radeon
modprobe -r drm
modprobe radeon modeset=1
the windows manager starter correctly.
I have created /etc/rc.local:
modprobe -r radeon
modprobe -r drm
modprobe radeon modeset=1
and
mod a+x /etc/rc.local
but the script will not start at boot. Which way can I make it executable?
Last edited by mini (2013-02-05 19:48:17)
Offline
rc.local depends on initscripts, but systemd doesn't use initscripts anymore.
arch Systemd wiki suggests you have to write your own systemd .service file.
I can't help with that, but i think you'll find several threads about writing .service files on forum.
If you want to go that way, imo it would be best to start a new thread.
Incase you use startx to get into x, an alternative would be to put those commands in ~/.xinitrc.
modprobe requires root-rights, so you'll have to use /etc/sudoers to give your user those rights (check the wiki).
If you use a login manager (xdm, gdm , kdm etc) i think only the systemd .service file way will work.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thank you for the info, I packaged such a service file for our convenience: https://aur.archlinux.org/packages/rade … t-service/
Offline
Thanks a lot. Now my system works very well with the last kernel 3.7.5-1-ARCH
Offline
Finally, with 3.9.6, the issue seems to be fixed on my system (RV516/M62-S [Mobility Radeon X1350]).
Offline