[arch-general] Kernel 2.6.32 and Radeon KMS
Hi, I installed kernel26 and kernel26-firmware from testing, and I'm experiencing some problems with KMS. During system initialization, the system requests the firmware radeon/R300_cp.bin, waits a couple of seconds and then proceeds normal initialization. But when I log into X, DRI isn't enabled. Checking dmesg, I see that the kernel couldn't load R300 firmware, therefore disabling GPU acceleration. My problem is the same of this post: http://old.nabble.com/kernel-2.6.32-experiences-td26458040.html. Thomas said that mkinitcpio automatically inserts firmware listed in modinfo module in the initramfs image. When I run modinfo radeon | grep R300, it shows me 'firmware: radeon/R300_cp.bin'. So it should be available to kernel at the time of requesting it, shouldn't it? Has someone any idea to help solving that problem? Thanks in advance. -- Gabriel Morrison
Gabriel Morrison Lima Dantas schrieb:
Hi, I installed kernel26 and kernel26-firmware from testing, and I'm experiencing some problems with KMS. During system initialization, the system requests the firmware radeon/R300_cp.bin, waits a couple of seconds and then proceeds normal initialization. But when I log into X, DRI isn't enabled. Checking dmesg, I see that the kernel couldn't load R300 firmware, therefore disabling GPU acceleration. My problem is the same of this post: http://old.nabble.com/kernel-2.6.32-experiences-td26458040.html. Thomas said that mkinitcpio automatically inserts firmware listed in modinfo module in the initramfs image. When I run modinfo radeon | grep R300, it shows me 'firmware: radeon/R300_cp.bin'. So it should be available to kernel at the time of requesting it, shouldn't it? Has someone any idea to help solving that problem?
Can you remove radeon from initramfs and try in the real system? I suspect that the initramfs/udev firmware loader is broken - this can't be fixed until we dump klibc, which I don't have the time for currently.
Removing radeon from initramfs and putting it in MODULES section of rc.conf solves the problem. 2009/12/5 Thomas Bächler <thomas@archlinux.org>
Gabriel Morrison Lima Dantas schrieb:
Hi, I installed kernel26 and kernel26-firmware from testing, and I'm
experiencing some problems with KMS. During system initialization, the system requests the firmware radeon/R300_cp.bin, waits a couple of seconds and then proceeds normal initialization. But when I log into X, DRI isn't enabled. Checking dmesg, I see that the kernel couldn't load R300 firmware, therefore disabling GPU acceleration. My problem is the same of this post: http://old.nabble.com/kernel-2.6.32-experiences-td26458040.html. Thomas said that mkinitcpio automatically inserts firmware listed in modinfo module in the initramfs image. When I run modinfo radeon | grep R300, it shows me 'firmware: radeon/R300_cp.bin'. So it should be available to kernel at the time of requesting it, shouldn't it? Has someone any idea to help solving that problem?
Can you remove radeon from initramfs and try in the real system? I suspect that the initramfs/udev firmware loader is broken - this can't be fixed until we dump klibc, which I don't have the time for currently.
-- Gabriel Morrison
Gabriel Morrison Lima Dantas schrieb:
Removing radeon from initramfs and putting it in MODULES section of rc.conf solves the problem.
Hm, I hope you are happy this way until we know what's going on ... the problem is certainly not that the firmware is not put in initramfs, but something else ... something weird.
Hmm... strange... but it's fine the way it is :) Thanks 2009/12/5 Thomas Bächler <thomas@archlinux.org>
Gabriel Morrison Lima Dantas schrieb:
Removing radeon from initramfs and putting it in MODULES section of rc.conf solves the problem.
Hm, I hope you are happy this way until we know what's going on ... the problem is certainly not that the firmware is not put in initramfs, but something else ... something weird.
-- Gabriel Morrison
Thomas Bächler wrote:
Gabriel Morrison Lima Dantas schrieb:
Removing radeon from initramfs and putting it in MODULES section of rc.conf solves the problem.
Hm, I hope you are happy this way until we know what's going on ... the problem is certainly not that the firmware is not put in initramfs, but something else ... something weird.
FYI, not-so-happy radeon kms user here: http://bbs.archlinux.org/viewtopic.php?pid=667665#p667665 he'd like it earlier for plymouth. T.
Tom K wrote:
Thomas Bächler wrote:
Gabriel Morrison Lima Dantas schrieb:
Removing radeon from initramfs and putting it in MODULES section of rc.conf solves the problem.
Hm, I hope you are happy this way until we know what's going on ... the problem is certainly not that the firmware is not put in initramfs, but something else ... something weird.
FYI, not-so-happy radeon kms user here: http://bbs.archlinux.org/viewtopic.php?pid=667665#p667665 he'd like it earlier for plymouth.
T.
Interim fix available in the forum thread referenced above. In the longer term, I think a different approach is required, as this could potentially affect any driver that requires firmware and is used in the init image. It doesn't make sense to create individual hooks for all of them. The requirement here is that firmware-dependent modules are loaded after the udev hook has been run i.e. after udevd starts. A simple solution, based on the one in the forum thread, would be a hook called e.g. fwmodules, where modules with this requirement are specified. Alternatively, maybe it would work as a second array in mkinitcpio.conf e.g. MODULES= and FWMODULES=. This would, of course, require a patch for mkinitcpio and related files. I might even write it. :) T.
Tom K schrieb:
The requirement here is that firmware-dependent modules are loaded after the udev hook has been run i.e. after udevd starts. A simple solution, based on the one in the forum thread, would be a hook called e.g. fwmodules, where modules with this requirement are specified. Alternatively, maybe it would work as a second array in mkinitcpio.conf e.g. MODULES= and FWMODULES=. This would, of course, require a patch for mkinitcpio and related files. I might even write it. :)
We probably will have /init start udevd before loading modules, and only do trigger/settle in the udev hook. Something like that. For now, please create a custom hook which is loaded after udev.
Am Montag 07 Dezember 2009 schrieb Tom K:
Tom K wrote:
Thomas Bächler wrote:
Gabriel Morrison Lima Dantas schrieb:
Removing radeon from initramfs and putting it in MODULES section of rc.conf solves the problem.
Hm, I hope you are happy this way until we know what's going on ... the problem is certainly not that the firmware is not put in initramfs, but something else ... something weird.
FYI, not-so-happy radeon kms user here: http://bbs.archlinux.org/viewtopic.php?pid=667665#p667665 he'd like it earlier for plymouth.
T.
Interim fix available in the forum thread referenced above. In the longer term, I think a different approach is required, as this could potentially affect any driver that requires firmware and is used in the init image. It doesn't make sense to create individual hooks for all of them.
The requirement here is that firmware-dependent modules are loaded after the udev hook has been run i.e. after udevd starts. A simple solution, based on the one in the forum thread, would be a hook called e.g. fwmodules, where modules with this requirement are specified. Alternatively, maybe it would work as a second array in mkinitcpio.conf e.g. MODULES= and FWMODULES=. This would, of course, require a patch for mkinitcpio and related files. I might even write it. :)
T.
It would be possible to launch udevd from initcpio's init file. We could add a check for udevd there and launch it. udev hook then only contains trigger and wait. Just my 2c greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Saturday 05 December 2009 08:51:23 and regarding:
Hi, I installed kernel26 and kernel26-firmware from testing, and I'm experiencing some problems with KMS. During system initialization, the system requests the firmware radeon/R300_cp.bin, waits a couple of seconds and then proceeds normal initialization. But when I log into X, DRI isn't enabled. Checking dmesg, I see that the kernel couldn't load R300 firmware, therefore disabling GPU acceleration. My problem is the same of this post: http://old.nabble.com/kernel-2.6.32-experiences-td26458040.html. Thomas said that mkinitcpio automatically inserts firmware listed in modinfo module in the initramfs image. When I run modinfo radeon | grep R300, it shows me 'firmware: radeon/R300_cp.bin'. So it should be available to kernel at the time of requesting it, shouldn't it? Has someone any idea to help solving that problem?
Thanks in advance.
Gabriel, I can confirm. I loaded 2.6.32 tonight and the box hung right after the screen flashed (where it normally goes from big text to small text [i.e. changes resolution]) and the box locked up. I had to use the install cd to downgrade to 2.6.31-6 in order to boot again... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 07.12.2009 05:54, David C. Rankin wrote:
On Saturday 05 December 2009 08:51:23 and regarding:
Hi, I installed kernel26 and kernel26-firmware from testing, and I'm experiencing some problems with KMS. During system initialization, the system requests the firmware radeon/R300_cp.bin, waits a couple of seconds and then proceeds normal initialization. But when I log into X, DRI isn't enabled. Checking dmesg, I see that the kernel couldn't load R300 firmware, therefore disabling GPU acceleration. My problem is the same of this post: http://old.nabble.com/kernel-2.6.32-experiences-td26458040.html. Thomas said that mkinitcpio automatically inserts firmware listed in modinfo module in the initramfs image. When I run modinfo radeon | grep R300, it shows me 'firmware: radeon/R300_cp.bin'. So it should be available to kernel at the time of requesting it, shouldn't it? Has someone any idea to help solving that problem?
Thanks in advance.
Gabriel,
I can confirm. I loaded 2.6.32 tonight and the box hung right after the screen flashed (where it normally goes from big text to small text [i.e. changes resolution]) and the box locked up. I had to use the install cd to downgrade to 2.6.31-6 in order to boot again...
I'm confirming this as well. Mine fails at radeon/R200_cp.bin, though. Loading in rc.conf works alright but the GPU appears to get very hot. I have no diode on it but it just tries to burn a hole through my laptop. Again, KMS performance is just as bad as with kernel 2.6.31. I get better performance without KMS and the system runs a lot cooler in idle as well. My card is a puny rv250 (aka Radeon Mobile 9000). -- Sven-Hendrik
On Monday 07 December 2009 09:05:18 and regarding:
I'm confirming this as well. Mine fails at radeon/R200_cp.bin, though. Loading in rc.conf works alright but the GPU appears to get very hot. I have no diode on it but it just tries to burn a hole through my laptop. Again, KMS performance is just as bad as with kernel 2.6.31. I get better performance without KMS and the system runs a lot cooler in idle as well. My card is a puny rv250 (aka Radeon Mobile 9000).
Sven, I have the RS690M (x1200) card and the gpu used to get so hot with earlier additions of the 1.25x radeonhd driver that it was uncomfortable to rest my palms on the laptop palmrest. AMD really fsck'ed all of the laptop users when it dropped all support for pre-2400 series cards in March automatically converting many fairly new laptops (Q1 2008) to "Legacy" boxes. The fglrx driver did such a marvelous job with gpu powerdown and downclocking that thermal was never an issue and performance was great. Thankfully the radeonhd driver has gotten much better in power management in the past 3 months that I can use the palm rest again, but performance is still way low. Best we can do is keep our fingers crossed -- or go shop nvidia gpu based laptops :p -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Tue, Dec 8, 2009 at 6:52 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On Monday 07 December 2009 09:05:18 and regarding:
I'm confirming this as well. Mine fails at radeon/R200_cp.bin, though. Loading in rc.conf works alright but the GPU appears to get very hot. I have no diode on it but it just tries to burn a hole through my laptop. Again, KMS performance is just as bad as with kernel 2.6.31. I get better performance without KMS and the system runs a lot cooler in idle as well. My card is a puny rv250 (aka Radeon Mobile 9000).
Sven,
I have the RS690M (x1200) card and the gpu used to get so hot with earlier additions of the 1.25x radeonhd driver that it was uncomfortable to rest my palms on the laptop palmrest. AMD really fsck'ed all of the laptop users when it dropped all support for pre-2400 series cards in March automatically converting many fairly new laptops (Q1 2008) to "Legacy" boxes. The fglrx driver did such a marvelous job with gpu powerdown and downclocking that thermal was never an issue and performance was great. Thankfully the radeonhd driver has gotten much better in power management in the past 3 months that I can use the palm rest again, but performance is still way low. Best we can do is keep our fingers crossed -- or go shop nvidia gpu based laptops :p
I am not sure that's a solution at all. The only way to be sure about long term support is with open source drivers. And AMD/ATI position certainly looks better than Nvidia for that. Just compare both : http://en.wikipedia.org/wiki/Graphics_hardware_and_FOSS#ATI.2FAMD -> specs for all? the latest chipsets http://en.wikipedia.org/wiki/Graphics_hardware_and_FOSS#NVIDIA -> nothing,void,nil Now I know nothing about ati fglrx proprietary drivers, but maybe you should know the situation with nvidia. 190.42 drivers : only supports geforce 6 !! and newer 173xx drivers : support geforce 5 (and newer but no point) 96xx drivers : support geforce 4 and some geforce 2 Note that for the recent Xorg 7.5 release, the 173xx and 96xx lagged two weeks behind to get compatible, leaving many users in doubt during that period. And anything older than that is considered legacy and no longer supported. It was the 71xx series which stopped working with Xorg 7.4 release, quite a while ago... But maybe in term of open source support and power consumption, intel is doing better than ati ? I have to admit I don't know these two well. And I am sure things are not perfect there either. Just don't assume that everything is shiny in Nvidia's world, far from that.
On 08.12.2009 11:13, Xavier wrote:
On Tue, Dec 8, 2009 at 6:52 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On Monday 07 December 2009 09:05:18 and regarding:
I'm confirming this as well. Mine fails at radeon/R200_cp.bin, though. Loading in rc.conf works alright but the GPU appears to get very hot. I have no diode on it but it just tries to burn a hole through my laptop. Again, KMS performance is just as bad as with kernel 2.6.31. I get better performance without KMS and the system runs a lot cooler in idle as well. My card is a puny rv250 (aka Radeon Mobile 9000).
Sven,
I have the RS690M (x1200) card and the gpu used to get so hot with earlier additions of the 1.25x radeonhd driver that it was uncomfortable to rest my palms on the laptop palmrest. AMD really fsck'ed all of the laptop users when it dropped all support for pre-2400 series cards in March automatically converting many fairly new laptops (Q1 2008) to "Legacy" boxes. The fglrx driver did such a marvelous job with gpu powerdown and downclocking that thermal was never an issue and performance was great. Thankfully the radeonhd driver has gotten much better in power management in the past 3 months that I can use the palm rest again, but performance is still way low. Best we can do is keep our fingers crossed -- or go shop nvidia gpu based laptops :p
I am not sure that's a solution at all.
The only way to be sure about long term support is with open source drivers. And AMD/ATI position certainly looks better than Nvidia for that. Just compare both : http://en.wikipedia.org/wiki/Graphics_hardware_and_FOSS#ATI.2FAMD -> specs for all? the latest chipsets http://en.wikipedia.org/wiki/Graphics_hardware_and_FOSS#NVIDIA -> nothing,void,nil
Now I know nothing about ati fglrx proprietary drivers, but maybe you should know the situation with nvidia. 190.42 drivers : only supports geforce 6 !! and newer 173xx drivers : support geforce 5 (and newer but no point) 96xx drivers : support geforce 4 and some geforce 2
Note that for the recent Xorg 7.5 release, the 173xx and 96xx lagged two weeks behind to get compatible, leaving many users in doubt during that period.
And anything older than that is considered legacy and no longer supported. It was the 71xx series which stopped working with Xorg 7.4 release, quite a while ago...
But maybe in term of open source support and power consumption, intel is doing better than ati ? I have to admit I don't know these two well. And I am sure things are not perfect there either. Just don't assume that everything is shiny in Nvidia's world, far from that.
Well then, can I actually expect KMS to run slower than "regular" mode (because that's what it does) or would it be faster if it worked right at the driver's current state? I tested both kernel 2.6.31 and 2.6.32 and both give me about 500 FPS less in glxgears (for what it's worth). Also, KMS frequently causes kernel panic and all kinds of other trouble. Changing from vt1 to X is fast, though. Any tips on this or is this actually the current state of KMS? Remember, I'm using xf86-video-ati. -- Sven-Hendrik
On Tue, 08 Dec 2009 17:33:12 +0100 Sven-Hendrik Haase <sh@lutzhaase.com> wrote:
On 08.12.2009 11:13, Xavier wrote:
On Tue, Dec 8, 2009 at 6:52 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On Monday 07 December 2009 09:05:18 and regarding:
I'm confirming this as well. Mine fails at radeon/R200_cp.bin, though. Loading in rc.conf works alright but the GPU appears to get very hot. I have no diode on it but it just tries to burn a hole through my laptop. Again, KMS performance is just as bad as with kernel 2.6.31. I get better performance without KMS and the system runs a lot cooler in idle as well. My card is a puny rv250 (aka Radeon Mobile 9000).
Sven,
I have the RS690M (x1200) card and the gpu used to get so hot with earlier additions of the 1.25x radeonhd driver that it was uncomfortable to rest my palms on the laptop palmrest. AMD really fsck'ed all of the laptop users when it dropped all support for pre-2400 series cards in March automatically converting many fairly new laptops (Q1 2008) to "Legacy" boxes. The fglrx driver did such a marvelous job with gpu powerdown and downclocking that thermal was never an issue and performance was great. Thankfully the radeonhd driver has gotten much better in power management in the past 3 months that I can use the palm rest again, but performance is still way low. Best we can do is keep our fingers crossed -- or go shop nvidia gpu based laptops :p
I am not sure that's a solution at all.
The only way to be sure about long term support is with open source drivers. And AMD/ATI position certainly looks better than Nvidia for that. Just compare both : http://en.wikipedia.org/wiki/Graphics_hardware_and_FOSS#ATI.2FAMD -> specs for all? the latest chipsets http://en.wikipedia.org/wiki/Graphics_hardware_and_FOSS#NVIDIA -> nothing,void,nil
Now I know nothing about ati fglrx proprietary drivers, but maybe you should know the situation with nvidia. 190.42 drivers : only supports geforce 6 !! and newer 173xx drivers : support geforce 5 (and newer but no point) 96xx drivers : support geforce 4 and some geforce 2
Note that for the recent Xorg 7.5 release, the 173xx and 96xx lagged two weeks behind to get compatible, leaving many users in doubt during that period.
And anything older than that is considered legacy and no longer supported. It was the 71xx series which stopped working with Xorg 7.4 release, quite a while ago...
But maybe in term of open source support and power consumption, intel is doing better than ati ? I have to admit I don't know these two well. And I am sure things are not perfect there either. Just don't assume that everything is shiny in Nvidia's world, far from that.
Well then, can I actually expect KMS to run slower than "regular" mode (because that's what it does) or would it be faster if it worked right at the driver's current state? I tested both kernel 2.6.31 and 2.6.32 and both give me about 500 FPS less in glxgears (for what it's worth). Also, KMS frequently causes kernel panic and all kinds of other trouble. Changing from vt1 to X is fast, though. Any tips on this or is this actually the current state of KMS? Remember, I'm using xf86-video-ati.
-- Sven-Hendrik
Well, I think it depends on support for your card. On my ATI card (age-old X700), while using KMS does gives me less FPS in glxgears, most 3D apps run noticeably _faster_ with less glitches. For example, transparency in Neverball is working properly now while in the older kernel it have been broken for quite some time. I'm using the current 2.6.32 kernel, BTW. Try testing using real application, such as the aforementioned Neverball, to better see the different. Regards, Smith
On 12/08/2009 01:47 PM, Smith Dhumbumroong wrote:
Well, I think it depends on support for your card. On my ATI card (age-old X700), while using KMS does gives me less FPS in glxgears, most 3D apps run noticeably_faster_ with less glitches. For example, transparency in Neverball is working properly now while in the older kernel it have been broken for quite some time. I'm using the current 2.6.32 kernel, BTW.
Try testing using real application, such as the aforementioned Neverball, to better see the different.
Unfortunately you are 100% correct -- depends on the card, Also unfortunately, my laptop has the RS690M (X1200) where the radeonhd driver is completely broken and has been since late July. We have gone through git bisect until my head swims, but still no solution. With the current radeonhd driver, X initializes but then shuts itself down for reasons unexplained: (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "evdev" (**) Option "xkb_layout" "us" (II) XKB: reuse xkmfile /var/lib/xkb/compiled/server-D378AD8F86E560F712A83EE36E4E5E92C595B9BD.xkm (II) UnloadModule: "synaptics" (II) AT Translated Set 2 keyboard: Close (II) UnloadModule: "evdev" (II) Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): Close (II) UnloadModule: "evdev" (II) Power Button: Close (II) UnloadModule: "evdev" (II) Video Bus: Close (II) UnloadModule: "evdev" (II) Power Button: Close (II) UnloadModule: "evdev" (II) RADEONHD(0): Attempting to disable power management (WW) RADEONHD(0): AtomBIOS command table 19 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Failed to set power management (II) RADEONHD(0): Query for Set Power Management: failed (II) RADEONHD(0): Attempting to disable clock gating (II) RADEONHD(0): Current Engine Clock: 400000 (WW) RADEONHD(0): AtomBIOS command table 47 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Unusupported SetVoltage Revision Hopefully we will have more time to work on it shortly. It S U C K S to have a laptop that worked perfectly and fast with the unavailable 'legacy' driver, now not work or work like crap with the "new" driver. Progress...??? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
So, any news on this? I 'fixed' it by removing radeon from initramfs, but as has been pointed out, thats not really a solution!?
Am Montag 07 Dezember 2009 schrieb Tom:
So, any news on this? I 'fixed' it by removing radeon from initramfs, but as has been pointed out, thats not really a solution!?
HI guys, This kms firmware issue revealed a bug in initcpio and firmware handling. Would you mind to test a fix for the firmware loading? 2 files attached: This will load udevd before executing MODULES= - Replace /lib/initcpio/init and /lib/initcpio/hooks/udev - Remove the yourself created radeon hook from /etc/mkinitcpio.conf hooks array - Add radeon again to modules array in /etc/mkinitcpio.conf - Recreate a test initrd with mkinitcpio -g test.img and launch this initrd from your bootloader. - Don't forget to reinstall original initcpio files after that! pacman -S initcpio Thanks for your help. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am Freitag 11 Dezember 2009 schrieb Tobias Powalowski:
Am Montag 07 Dezember 2009 schrieb Tom:
So, any news on this? I 'fixed' it by removing radeon from initramfs, but as has been pointed out, thats not really a solution!?
Please get files from bugreport http://bugs.archlinux.org/task/17461 Thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am Freitag 11 Dezember 2009 schrieb Tobias Powalowski:
Am Freitag 11 Dezember 2009 schrieb Tobias Powalowski:
Am Montag 07 Dezember 2009 schrieb Tom:
So, any news on this? I 'fixed' it by removing radeon from initramfs, but as has been pointed out, thats not really a solution!?
Please get files from bugreport http://bugs.archlinux.org/task/17461
Thanks greetings tpowa
Sorry guys i can't test it, due top lack of hardware. It would be nice if anyone would report success or fail. Thanks. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Fri, 11 Dec 2009 10:03:53 +0100 Tobias Powalowski <t.powa@gmx.de> wrote:
Am Montag 07 Dezember 2009 schrieb Tom:
So, any news on this? I 'fixed' it by removing radeon from initramfs, but as has been pointed out, thats not really a solution!?
HI guys, This kms firmware issue revealed a bug in initcpio and firmware handling.
Would you mind to test a fix for the firmware loading? 2 files attached: This will load udevd before executing MODULES= - Replace /lib/initcpio/init and /lib/initcpio/hooks/udev - Remove the yourself created radeon hook from /etc/mkinitcpio.conf hooks array - Add radeon again to modules array in /etc/mkinitcpio.conf - Recreate a test initrd with mkinitcpio -g test.img and launch this initrd from your bootloader. - Don't forget to reinstall original initcpio files after that! pacman -S initcpio
Thanks for your help. greetings tpowa
Hi, I've followed the above instructions (well, except I just go ahead and do a "mkinitcpio -p kernel26") and I'm glad to say that KMS early start method is now working fine again. :) Thanks for all the hard works, Tobias! Regards, Smith
Using radeon hook in mkinitcpio.conf, and KMS is working perfectly.
participants (10)
-
David C. Rankin
-
Gabriel Morrison Lima Dantas
-
Jim Clark
-
Smith Dhumbumroong
-
Sven-Hendrik Haase
-
Thomas Bächler
-
Tobias Powalowski
-
Tom
-
Tom K
-
Xavier