[opensuse-kernel] cirrus fb textconsoles broken
Hi, Current Factory has problems with text consoles when using the cirrus driver in qemu/kvm. Only a cursor shows up but no getty. The following message shows up in dmesg: [ 3.197938] fb: conflicting fb hw usage cirrusdrmfb vs simple - removing generic driver [ 3.199240] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM [ 3.201360] cirrus 0000:00:02.0: Fatal error during GPU init: -6 The funny thing is that the text console works during installation. Any idea what could be wrong and how to fix it? With "-vga std" in qemu the getty shows up. In general I wonder what would be the best video driver to use in qemu? The requirement would be to be able to define a fixed resolution of the text console and X somehow and that UEFI works with it (for openQA). cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Fri, 10 Jan 2014 10:38:21 +0100, Ludwig Nussel wrote:
Hi,
Current Factory has problems with text consoles when using the cirrus driver in qemu/kvm. Only a cursor shows up but no getty. The following message shows up in dmesg:
[ 3.197938] fb: conflicting fb hw usage cirrusdrmfb vs simple - removing generic driver [ 3.199240] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM [ 3.201360] cirrus 0000:00:02.0: Fatal error during GPU init: -6
The funny thing is that the text console works during installation. Any idea what could be wrong and how to fix it? With "-vga std" in qemu the getty shows up.
In general I wonder what would be the best video driver to use in qemu? The requirement would be to be able to define a fixed resolution of the text console and X somehow and that UEFI works with it (for openQA).
Isn't it the bnc#855821? Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Takashi Iwai wrote:
At Fri, 10 Jan 2014 10:38:21 +0100, Ludwig Nussel wrote:
Current Factory has problems with text consoles when using the cirrus driver in qemu/kvm. Only a cursor shows up but no getty. The following message shows up in dmesg:
[ 3.197938] fb: conflicting fb hw usage cirrusdrmfb vs simple - removing generic driver [ 3.199240] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM [ 3.201360] cirrus 0000:00:02.0: Fatal error during GPU init: -6
Isn't it the bnc#855821?
Looks like it but Factory still suffers from that problem even though the bug is resolved fixed. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 10.01.2014 10:48, Takashi Iwai wrote:
At Fri, 10 Jan 2014 10:38:21 +0100, Ludwig Nussel wrote:
Hi,
Current Factory has problems with text consoles when using the cirrus driver in qemu/kvm. Only a cursor shows up but no getty. The following message shows up in dmesg:
[ 3.197938] fb: conflicting fb hw usage cirrusdrmfb vs simple - removing generic driver [ 3.199240] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM [ 3.201360] cirrus 0000:00:02.0: Fatal error during GPU init: -6
The funny thing is that the text console works during installation. Any idea what could be wrong and how to fix it? With "-vga std" in qemu the getty shows up.
In general I wonder what would be the best video driver to use in qemu? The requirement would be to be able to define a fixed resolution of the text console and X somehow and that UEFI works with it (for openQA).
Isn't it the bnc#855821?
Sounds like it. It's a pitty that we have no kernel branch for factory where such fixes are collected while master is RC1-RC7 ;( Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Fri, 10 Jan 2014 10:57:37 +0100, Stephan Kulow wrote:
On 10.01.2014 10:48, Takashi Iwai wrote:
At Fri, 10 Jan 2014 10:38:21 +0100, Ludwig Nussel wrote:
Hi,
Current Factory has problems with text consoles when using the cirrus driver in qemu/kvm. Only a cursor shows up but no getty. The following message shows up in dmesg:
[ 3.197938] fb: conflicting fb hw usage cirrusdrmfb vs simple - removing generic driver [ 3.199240] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM [ 3.201360] cirrus 0000:00:02.0: Fatal error during GPU init: -6
The funny thing is that the text console works during installation. Any idea what could be wrong and how to fix it? With "-vga std" in qemu the getty shows up.
In general I wonder what would be the best video driver to use in qemu? The requirement would be to be able to define a fixed resolution of the text console and X somehow and that UEFI works with it (for openQA).
Isn't it the bnc#855821?
Sounds like it. It's a pitty that we have no kernel branch for factory where such fixes are collected while master is RC1-RC7 ;(
Or what about just taking stable branch? It can be either temporarily taken until the new kernel is released, or we can use always stable branch for FACTORY. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 10.01.2014 11:32, Takashi Iwai wrote:
At Fri, 10 Jan 2014 10:57:37 +0100, Stephan Kulow wrote:
On 10.01.2014 10:48, Takashi Iwai wrote:
At Fri, 10 Jan 2014 10:38:21 +0100, Ludwig Nussel wrote:
Hi,
Current Factory has problems with text consoles when using the cirrus driver in qemu/kvm. Only a cursor shows up but no getty. The following message shows up in dmesg:
[ 3.197938] fb: conflicting fb hw usage cirrusdrmfb vs simple - removing generic driver [ 3.199240] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM [ 3.201360] cirrus 0000:00:02.0: Fatal error during GPU init: -6
The funny thing is that the text console works during installation. Any idea what could be wrong and how to fix it? With "-vga std" in qemu the getty shows up.
In general I wonder what would be the best video driver to use in qemu? The requirement would be to be able to define a fixed resolution of the text console and X somehow and that UEFI works with it (for openQA).
Isn't it the bnc#855821?
Sounds like it. It's a pitty that we have no kernel branch for factory where such fixes are collected while master is RC1-RC7 ;(
Or what about just taking stable branch? It can be either temporarily taken until the new kernel is released, or we can use always stable branch for FACTORY.
I would be fine with always taking stable branch. As factory is supposed to be stable itself, that sounds like a good idea in general :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Fri, 10 Jan 2014 12:33:58 +0100, Stephan Kulow wrote:
On 10.01.2014 11:32, Takashi Iwai wrote:
At Fri, 10 Jan 2014 10:57:37 +0100, Stephan Kulow wrote:
On 10.01.2014 10:48, Takashi Iwai wrote:
At Fri, 10 Jan 2014 10:38:21 +0100, Ludwig Nussel wrote:
Hi,
Current Factory has problems with text consoles when using the cirrus driver in qemu/kvm. Only a cursor shows up but no getty. The following message shows up in dmesg:
[ 3.197938] fb: conflicting fb hw usage cirrusdrmfb vs simple - removing generic driver [ 3.199240] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM [ 3.201360] cirrus 0000:00:02.0: Fatal error during GPU init: -6
The funny thing is that the text console works during installation. Any idea what could be wrong and how to fix it? With "-vga std" in qemu the getty shows up.
In general I wonder what would be the best video driver to use in qemu? The requirement would be to be able to define a fixed resolution of the text console and X somehow and that UEFI works with it (for openQA).
Isn't it the bnc#855821?
Sounds like it. It's a pitty that we have no kernel branch for factory where such fixes are collected while master is RC1-RC7 ;(
Or what about just taking stable branch? It can be either temporarily taken until the new kernel is released, or we can use always stable branch for FACTORY.
I would be fine with always taking stable branch. As factory is supposed to be stable itself, that sounds like a good idea in general :)
Jiri, what do you think? Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 01/13/2014 11:38 AM, Takashi Iwai wrote:
Or what about just taking stable branch? It can be either temporarily taken until the new kernel is released, or we can use always stable branch for FACTORY.
I would be fine with always taking stable branch. As factory is supposed to be stable itself, that sounds like a good idea in general :)
Jiri, what do you think?
I don't mind; stable is there for you to take it, if you want :). BUT: where is the "next" kernel going to be tested then? -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi Jiri, Am 13.01.2014 21:30, schrieb Jiri Slaby:
On 01/13/2014 11:38 AM, Takashi Iwai wrote:
Or what about just taking stable branch? It can be either temporarily taken until the new kernel is released, or we can use always stable branch for FACTORY.
I would be fine with always taking stable branch. As factory is supposed to be stable itself, that sounds like a good idea in general :)
Jiri, what do you think?
I don't mind; stable is there for you to take it, if you want :).
BUT: where is the "next" kernel going to be tested then?
On my main work machine (a laptop) :-P -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Mon, 13 Jan 2014 21:30:30 +0100, Jiri Slaby wrote:
On 01/13/2014 11:38 AM, Takashi Iwai wrote:
Or what about just taking stable branch? It can be either temporarily taken until the new kernel is released, or we can use always stable branch for FACTORY.
I would be fine with always taking stable branch. As factory is supposed to be stable itself, that sounds like a good idea in general :)
Jiri, what do you think?
I don't mind; stable is there for you to take it, if you want :).
BUT: where is the "next" kernel going to be tested then?
Do you mean linux-next, or the current rc kernels? That is, should we let stable for Tumbleweed, and rather FACTORY testing rc kernels? I thought that using stable kernel for FACTORY would align to the policy we're trying to achieve recently -- make FACTORY stable / usable. But, of course, this cuts off the side as a tester. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 01/14/2014 03:40 PM, Takashi Iwai wrote:
At Mon, 13 Jan 2014 21:30:30 +0100, Jiri Slaby wrote:
On 01/13/2014 11:38 AM, Takashi Iwai wrote:
Or what about just taking stable branch? It can be either temporarily taken until the new kernel is released, or we can use always stable branch for FACTORY.
I would be fine with always taking stable branch. As factory is supposed to be stable itself, that sounds like a good idea in general :)
Jiri, what do you think?
I don't mind; stable is there for you to take it, if you want :).
BUT: where is the "next" kernel going to be tested then?
Do you mean linux-next, or the current rc kernels?
Oh, I meant rc kernels.
That is, should we let stable for Tumbleweed, and rather FACTORY testing rc kernels?
I thought that using stable kernel for FACTORY would align to the policy we're trying to achieve recently -- make FACTORY stable / usable. But, of course, this cuts off the side as a tester.
This was exactly my point. But I'm not biased to any of the sides. For me, both have equal pros&cons. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Wed, 15 Jan 2014 10:27:12 +0100, Jiri Slaby wrote:
On 01/14/2014 03:40 PM, Takashi Iwai wrote:
At Mon, 13 Jan 2014 21:30:30 +0100, Jiri Slaby wrote:
On 01/13/2014 11:38 AM, Takashi Iwai wrote:
Or what about just taking stable branch? It can be either temporarily taken until the new kernel is released, or we can use always stable branch for FACTORY.
I would be fine with always taking stable branch. As factory is supposed to be stable itself, that sounds like a good idea in general :)
Jiri, what do you think?
I don't mind; stable is there for you to take it, if you want :).
BUT: where is the "next" kernel going to be tested then?
Do you mean linux-next, or the current rc kernels?
Oh, I meant rc kernels.
That is, should we let stable for Tumbleweed, and rather FACTORY testing rc kernels?
I thought that using stable kernel for FACTORY would align to the policy we're trying to achieve recently -- make FACTORY stable / usable. But, of course, this cuts off the side as a tester.
This was exactly my point. But I'm not biased to any of the sides. For me, both have equal pros&cons.
I guess it's a call for Jeff and Coolo, then :) Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 15.01.2014 11:04, Takashi Iwai wrote:
At Wed, 15 Jan 2014 10:27:12 +0100, Jiri Slaby wrote:
On 01/14/2014 03:40 PM, Takashi Iwai wrote:
At Mon, 13 Jan 2014 21:30:30 +0100, Jiri Slaby wrote:
On 01/13/2014 11:38 AM, Takashi Iwai wrote:
> Or what about just taking stable branch? It can be either temporarily > taken until the new kernel is released, or we can use always stable > branch for FACTORY. > I would be fine with always taking stable branch. As factory is supposed to be stable itself, that sounds like a good idea in general :)
Jiri, what do you think?
I don't mind; stable is there for you to take it, if you want :).
BUT: where is the "next" kernel going to be tested then?
Do you mean linux-next, or the current rc kernels?
Oh, I meant rc kernels.
That is, should we let stable for Tumbleweed, and rather FACTORY testing rc kernels?
I thought that using stable kernel for FACTORY would align to the policy we're trying to achieve recently -- make FACTORY stable / usable. But, of course, this cuts off the side as a tester.
This was exactly my point. But I'm not biased to any of the sides. For me, both have equal pros&cons.
I guess it's a call for Jeff and Coolo, then :)
I have no problem with having RC kernels in factory - if they work, including xen support. I'm fine with changing the devel project of the kernel, but the stable kernel needs to be submitted to factory then. Right now Michal creates a submit request to factory whenever his script changes Kernel:HEAD. If that could be changed to only do so if it's the devel project and we have something similiar for Kernel:Stable, I could play the director. The real problem I'm having with this: it reduces the pressure to fix xen patches support for RCs even more. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 1/15/14, 5:12 AM, Stephan Kulow wrote:
On 15.01.2014 11:04, Takashi Iwai wrote:
At Wed, 15 Jan 2014 10:27:12 +0100, Jiri Slaby wrote:
On 01/14/2014 03:40 PM, Takashi Iwai wrote:
At Mon, 13 Jan 2014 21:30:30 +0100, Jiri Slaby wrote:
On 01/13/2014 11:38 AM, Takashi Iwai wrote:
>> Or what about just taking stable branch? It can be either temporarily >> taken until the new kernel is released, or we can use always stable >> branch for FACTORY. >> > I would be fine with always taking stable branch. As factory is supposed > to be stable itself, that sounds like a good idea in general :)
Jiri, what do you think?
I don't mind; stable is there for you to take it, if you want :).
BUT: where is the "next" kernel going to be tested then?
Do you mean linux-next, or the current rc kernels?
Oh, I meant rc kernels.
That is, should we let stable for Tumbleweed, and rather FACTORY testing rc kernels?
I thought that using stable kernel for FACTORY would align to the policy we're trying to achieve recently -- make FACTORY stable / usable. But, of course, this cuts off the side as a tester.
This was exactly my point. But I'm not biased to any of the sides. For me, both have equal pros&cons.
I guess it's a call for Jeff and Coolo, then :)
I have no problem with having RC kernels in factory - if they work, including xen support. I'm fine with changing the devel project of the kernel, but the stable kernel needs to be submitted to factory then. Right now Michal creates a submit request to factory whenever his script changes Kernel:HEAD. If that could be changed to only do so if it's the devel project and we have something similiar for Kernel:Stable, I could play the director.
I don't have a strong opinion on what kernel ends up in Factory, so long as Kernel:HEAD still tracks -rc releases the way it has been. Michal could probably automate the submissions to pick from Kernel:Stable vs Kernel:HEAD based on the contents of HEAD (rc? Xen present? really we could use any heuristic here). The only hiccup would be automating the swapping of the devel project.
The real problem I'm having with this: it reduces the pressure to fix xen patches support for RCs even more.
I don't think pressure from Factory has anything to do with the patches getting updated on RCs. The developers responsible for those have very full plates and the patches get updated when there's time. This cycle took a bit longer than is typical, but it also crossed the holidays when most of us where on vacation anyway. -Jeff -- Jeff Mahoney SUSE Labs
I don't have a strong opinion on what kernel ends up in Factory, so long as Kernel:HEAD still tracks -rc releases the way it has been. Michal could probably automate the submissions to pick from Kernel:Stable vs Kernel:HEAD based on the contents of HEAD (rc? Xen present? really we could use any heuristic here). The only hiccup would be automating the swapping of the devel project. As I said: I could swap the devel project and Michal's scripts submits whatever is devel prj. And if you feel confident with the RC, you just
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15.01.2014 16:30, Jeff Mahoney wrote: ping me to swap.
The real problem I'm having with this: it reduces the pressure to fix xen patches support for RCs even more.
I don't think pressure from Factory has anything to do with the patches getting updated on RCs. The developers responsible for those have very full plates and the patches get updated when there's time. This cycle took a bit longer than is typical, but it also crossed the holidays when most of us where on vacation anyway.
If you say so, even better. Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFS1qxmwFSBhlBjoJYRAsvfAJ4xeJexVCVvZXb6Jivmk3mKShRriwCfTjiy 0fMMojYDxsi1RzSU2pGcmi8= =2Iez -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (6)
-
Jeff Mahoney -
Jiri Slaby -
Ludwig Nussel -
Stefan Seyfried -
Stephan Kulow -
Takashi Iwai