Hi,
One of our test setups is unable to boot (stuck at initramfs). Git bisection points to the commit below:
f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
Reverting this patch resolves the issue. This issue persists in mainline also. Unfortunately there isn't any meaningful log. Hopefully someone can give some insight as to what could be the issue and revert/fix this issue.
Thanks, Thinh
On 2/1/22 15:01, Thinh Nguyen wrote:
Hi,
One of our test setups is unable to boot (stuck at initramfs). Git bisection points to the commit below:
f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
Reverting this patch resolves the issue. This issue persists in mainline also. Unfortunately there isn't any meaningful log. Hopefully someone can give some insight as to what could be the issue and revert/fix this issue.
Hi, Did you enable DRM_FBDEV_EMULATION? Please provide the failing .config file.
Hi Thinh,
On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap rdunlap@infradead.org wrote:
On 2/1/22 15:01, Thinh Nguyen wrote:
Hi,
One of our test setups is unable to boot (stuck at initramfs). Git bisection points to the commit below:
f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
Reverting this patch resolves the issue. This issue persists in mainline also. Unfortunately there isn't any meaningful log. Hopefully someone can give some insight as to what could be the issue and revert/fix this issue.
Hi, Did you enable DRM_FBDEV_EMULATION? Please provide the failing .config file.
Does selecting CONFIG_FB=y help?
We had to manually select this option in imx_v6_v7_defconfig after f611b1e7624c.
Please see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h...
Hi,
Fabio Estevam wrote:
Hi Thinh,
On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap rdunlap@infradead.org wrote:
On 2/1/22 15:01, Thinh Nguyen wrote:
Hi,
One of our test setups is unable to boot (stuck at initramfs). Git bisection points to the commit below:
f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
Reverting this patch resolves the issue. This issue persists in mainline also. Unfortunately there isn't any meaningful log. Hopefully someone can give some insight as to what could be the issue and revert/fix this issue.
Hi, Did you enable DRM_FBDEV_EMULATION?
I did not enable it.
Please provide the failing .config file.
Does selecting CONFIG_FB=y help?
On the config that has the issue, this isn't set. After reverting the commit above, this was set. Maybe this is what's needed? I need to test it.
We had to manually select this option in imx_v6_v7_defconfig after f611b1e7624c.
Please see: https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/...
Thanks, Thinh
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Fabio Estevam wrote:
On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap rdunlap@infradead.org wrote:
On 2/1/22 15:01, Thinh Nguyen wrote:
Hi,
One of our test setups is unable to boot (stuck at initramfs). Git bisection points to the commit below:
f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
Reverting this patch resolves the issue. This issue persists in mainline also. Unfortunately there isn't any meaningful log. Hopefully someone can give some insight as to what could be the issue and revert/fix this issue.
Hi, Did you enable DRM_FBDEV_EMULATION?
I did not enable it.
Please provide the failing .config file.
Does selecting CONFIG_FB=y help?
On the config that has the issue, this isn't set. After reverting the commit above, this was set. Maybe this is what's needed? I need to test it.
CONFIG_FB should not normally be needed for booting, so unless you have a graphical application in your initramfs that requires the /dev/fb0 device to work, it is not supposed to make a difference.
Are there any other differences in your .config before and after the patch? It's possible that you use some other driver that in turn depends on CONFIG_FB. Does your machine have any graphical output device? If yes, which driver do you use?
You may also want to make sure that you have 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency") in your kernel, which fixes a minor problem with my original patch.
Arnd
Arnd Bergmann wrote:
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Fabio Estevam wrote:
On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap rdunlap@infradead.org wrote:
On 2/1/22 15:01, Thinh Nguyen wrote:
Hi,
One of our test setups is unable to boot (stuck at initramfs). Git bisection points to the commit below:
f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
Reverting this patch resolves the issue. This issue persists in mainline also. Unfortunately there isn't any meaningful log. Hopefully someone can give some insight as to what could be the issue and revert/fix this issue.
Hi, Did you enable DRM_FBDEV_EMULATION?
I did not enable it.
Please provide the failing .config file.
Does selecting CONFIG_FB=y help?
On the config that has the issue, this isn't set. After reverting the commit above, this was set. Maybe this is what's needed? I need to test it.
CONFIG_FB should not normally be needed for booting, so unless you have a graphical application in your initramfs that requires the /dev/fb0 device to work, it is not supposed to make a difference.
I'm not sure, but it seems like the setup we have isn't the only one that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs to have CONFIG_FB set.
Are there any other differences in your .config before and after the patch? It's possible that you use some other driver that in turn depends on CONFIG_FB. Does your machine have any graphical output device? If yes, which driver do you use?
I don't have the answer to those questions yet. Need more investigation. I'm new to this particular test setup.
You may also want to make sure that you have 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency") in your kernel, which fixes a minor problem with my original patch.
Arnd
The issue also occurs in mainline, which has your minor fix commit above. The revert isn't clean for the latest kernel version. I also have to revert some of the changes along with CONFIG_FB. The revert looks more like this for the latest kernel:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..7cbc733a8569 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver" - depends on DRM_KMS_HELPER - depends on FB=y || FB=DRM_KMS_HELPER + depends on DRM + select DRM_KMS_HELPER + select FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT
I attached the configs for kernel v5.17-rc1. The "bad" config is without any revert, the "good" config is with the change above.
Thanks, Thinh
Hi--
On 2/2/22 15:55, Thinh Nguyen wrote:
Arnd Bergmann wrote:
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Fabio Estevam wrote:
On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap rdunlap@infradead.org wrote:
On 2/1/22 15:01, Thinh Nguyen wrote:
Hi,
One of our test setups is unable to boot (stuck at initramfs). Git bisection points to the commit below:
f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
Reverting this patch resolves the issue. This issue persists in mainline also. Unfortunately there isn't any meaningful log. Hopefully someone can give some insight as to what could be the issue and revert/fix this issue.
Hi, Did you enable DRM_FBDEV_EMULATION?
I did not enable it.
Please provide the failing .config file.
Does selecting CONFIG_FB=y help?
On the config that has the issue, this isn't set. After reverting the commit above, this was set. Maybe this is what's needed? I need to test it.
CONFIG_FB should not normally be needed for booting, so unless you have a graphical application in your initramfs that requires the /dev/fb0 device to work, it is not supposed to make a difference.
I'm not sure, but it seems like the setup we have isn't the only one that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs to have CONFIG_FB set.
Are there any other differences in your .config before and after the patch? It's possible that you use some other driver that in turn depends on CONFIG_FB. Does your machine have any graphical output device? If yes, which driver do you use?
I don't have the answer to those questions yet. Need more investigation. I'm new to this particular test setup.
You may also want to make sure that you have 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency") in your kernel, which fixes a minor problem with my original patch.
ArndThe issue also occurs in mainline, which has your minor fix commit above. The revert isn't clean for the latest kernel version. I also have to revert some of the changes along with CONFIG_FB. The revert looks more like this for the latest kernel:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..7cbc733a8569 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPERdepends on FB=y || FB=DRM_KMS_HELPER
depends on DRMselect DRM_KMS_HELPERselect FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLITI attached the configs for kernel v5.17-rc1. The "bad" config is without any revert, the "good" config is with the change above.
I took bad.config with kernel 5.17-rc1 and then manually set/enabled:
CONFIG_FB CONFIG_FB_EFI CONFIG_FB_MODE_HELPERS CONFIG_FB_TILEBLITTING CONFIG_LOGO
and I got very close to your good.config file. Can you do the same and see if it works for you? If so, then we can decide what to do about it.
thanks.
Randy Dunlap wrote:
Hi--
On 2/2/22 15:55, Thinh Nguyen wrote:
Arnd Bergmann wrote:
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Fabio Estevam wrote:
On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap rdunlap@infradead.org wrote:
On 2/1/22 15:01, Thinh Nguyen wrote: > Hi, > > One of our test setups is unable to boot (stuck at initramfs). Git > bisection points to the commit below: > > f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB") > > Reverting this patch resolves the issue. This issue persists in mainline > also. Unfortunately there isn't any meaningful log. Hopefully someone > can give some insight as to what could be the issue and revert/fix this > issue.
Hi, Did you enable DRM_FBDEV_EMULATION?
I did not enable it.
Please provide the failing .config file.
Does selecting CONFIG_FB=y help?
On the config that has the issue, this isn't set. After reverting the commit above, this was set. Maybe this is what's needed? I need to test it.
CONFIG_FB should not normally be needed for booting, so unless you have a graphical application in your initramfs that requires the /dev/fb0 device to work, it is not supposed to make a difference.
I'm not sure, but it seems like the setup we have isn't the only one that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs to have CONFIG_FB set.
Are there any other differences in your .config before and after the patch? It's possible that you use some other driver that in turn depends on CONFIG_FB. Does your machine have any graphical output device? If yes, which driver do you use?
I don't have the answer to those questions yet. Need more investigation. I'm new to this particular test setup.
You may also want to make sure that you have 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency") in your kernel, which fixes a minor problem with my original patch.
ArndThe issue also occurs in mainline, which has your minor fix commit above. The revert isn't clean for the latest kernel version. I also have to revert some of the changes along with CONFIG_FB. The revert looks more like this for the latest kernel:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..7cbc733a8569 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPERdepends on FB=y || FB=DRM_KMS_HELPER
depends on DRMselect DRM_KMS_HELPERselect FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLITI attached the configs for kernel v5.17-rc1. The "bad" config is without any revert, the "good" config is with the change above.
I took bad.config with kernel 5.17-rc1 and then manually set/enabled:
CONFIG_FB CONFIG_FB_EFI CONFIG_FB_MODE_HELPERS CONFIG_FB_TILEBLITTING CONFIG_LOGO
and I got very close to your good.config file. Can you do the same and see if it works for you? If so, then we can decide what to do about it.
thanks.
Yes. It works as expected.
Thanks, Thinh
On Thu, Feb 3, 2022 at 12:55 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Arnd Bergmann wrote:
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Fabio Estevam wrote:
CONFIG_FB should not normally be needed for booting, so unless you have a graphical application in your initramfs that requires the /dev/fb0 device to work, it is not supposed to make a difference.
I'm not sure, but it seems like the setup we have isn't the only one that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs to have CONFIG_FB set.
No, that one is different: the change for imx_v6_v7_defconfig was done because they actually use a framebuffer console on some devices, so the patch just adds the symbol to enable the drivers they are using.
This is expected with my original patch that doesn't implicitly enable the framebuffer layer any more. What is not expected is for the kernel to hang during boot as you reported for your unidentified platform.
Are there any other differences in your .config before and after the patch? It's possible that you use some other driver that in turn depends on CONFIG_FB. Does your machine have any graphical output device? If yes, which driver do you use?
I don't have the answer to those questions yet. Need more investigation. I'm new to this particular test setup.
Do you mean you don't know if there is a screen attached to the system?
You may also want to make sure that you have 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency") in your kernel, which fixes a minor problem with my original patch.
The issue also occurs in mainline, which has your minor fix commit above. The revert isn't clean for the latest kernel version. I also have to revert some of the changes along with CONFIG_FB. The revert looks more like this for the latest kernel:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..7cbc733a8569 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPERdepends on FB=y || FB=DRM_KMS_HELPER
depends on DRMselect DRM_KMS_HELPERselect FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLITI attached the configs for kernel v5.17-rc1. The "bad" config is without any revert, the "good" config is with the change above.
Looking at the config, I see that this is for an x86 machine, and you have the FB_EFI driver and EFI_EARLYCON enabled.
What I suspec is going on is that you are looking at a screen rather than a serial console, and the kernel doesn't actually hang but you just don't see any more messages after the DRM driver takes over from EFI_EARLYCON because there is no console driver.
In this case, what you see is the intended behavior, not a bug. If you want a graphical console in your system, you need to enable the support for this in your config.
Arnd
Arnd Bergmann wrote:
On Thu, Feb 3, 2022 at 12:55 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Arnd Bergmann wrote:
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Fabio Estevam wrote:
CONFIG_FB should not normally be needed for booting, so unless you have a graphical application in your initramfs that requires the /dev/fb0 device to work, it is not supposed to make a difference.
I'm not sure, but it seems like the setup we have isn't the only one that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs to have CONFIG_FB set.
No, that one is different: the change for imx_v6_v7_defconfig was done because they actually use a framebuffer console on some devices, so the patch just adds the symbol to enable the drivers they are using.
This is expected with my original patch that doesn't implicitly enable the framebuffer layer any more. What is not expected is for the kernel to hang during boot as you reported for your unidentified platform.
Are there any other differences in your .config before and after the patch? It's possible that you use some other driver that in turn depends on CONFIG_FB. Does your machine have any graphical output device? If yes, which driver do you use?
I don't have the answer to those questions yet. Need more investigation. I'm new to this particular test setup.
Do you mean you don't know if there is a screen attached to the system?
It does have a graphical output device, but I didn't check what it is or what driver is driving it. I just notice that after the reported commit, something stopped working.
You may also want to make sure that you have 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency") in your kernel, which fixes a minor problem with my original patch.
The issue also occurs in mainline, which has your minor fix commit above. The revert isn't clean for the latest kernel version. I also have to revert some of the changes along with CONFIG_FB. The revert looks more like this for the latest kernel:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..7cbc733a8569 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPERdepends on FB=y || FB=DRM_KMS_HELPER
depends on DRMselect DRM_KMS_HELPERselect FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLITI attached the configs for kernel v5.17-rc1. The "bad" config is without any revert, the "good" config is with the change above.
Looking at the config, I see that this is for an x86 machine, and you have the FB_EFI driver and EFI_EARLYCON enabled.
What I suspec is going on is that you are looking at a screen rather than a serial console, and the kernel doesn't actually hang but you just don't see any more messages after the DRM driver takes over from EFI_EARLYCON because there is no console driver.
In this case, what you see is the intended behavior, not a bug. If you want a graphical console in your system, you need to enable the support for this in your config.
It sounds like that's the case. Unfortunately I'm not familiar with this subsystem to say that's what happening. If there's nothing actually broken from review, we can ignore this email thread.
Thanks, Thinh
On 2/3/22 19:21, Thinh Nguyen wrote:
Arnd Bergmann wrote:
On Thu, Feb 3, 2022 at 12:55 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Arnd Bergmann wrote:
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Fabio Estevam wrote:
CONFIG_FB should not normally be needed for booting, so unless you have a graphical application in your initramfs that requires the /dev/fb0 device to work, it is not supposed to make a difference.
I'm not sure, but it seems like the setup we have isn't the only one that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs to have CONFIG_FB set.
No, that one is different: the change for imx_v6_v7_defconfig was done because they actually use a framebuffer console on some devices, so the patch just adds the symbol to enable the drivers they are using.
This is expected with my original patch that doesn't implicitly enable the framebuffer layer any more. What is not expected is for the kernel to hang during boot as you reported for your unidentified platform.
Are there any other differences in your .config before and after the patch? It's possible that you use some other driver that in turn depends on CONFIG_FB. Does your machine have any graphical output device? If yes, which driver do you use?
I don't have the answer to those questions yet. Need more investigation. I'm new to this particular test setup.
Do you mean you don't know if there is a screen attached to the system?
It does have a graphical output device, but I didn't check what it is or what driver is driving it. I just notice that after the reported commit, something stopped working.
You may also want to make sure that you have 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency") in your kernel, which fixes a minor problem with my original patch.
The issue also occurs in mainline, which has your minor fix commit above. The revert isn't clean for the latest kernel version. I also have to revert some of the changes along with CONFIG_FB. The revert looks more like this for the latest kernel:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..7cbc733a8569 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPERdepends on FB=y || FB=DRM_KMS_HELPER
depends on DRMselect DRM_KMS_HELPERselect FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLITI attached the configs for kernel v5.17-rc1. The "bad" config is without any revert, the "good" config is with the change above.
Looking at the config, I see that this is for an x86 machine, and you have the FB_EFI driver and EFI_EARLYCON enabled.
What I suspec is going on is that you are looking at a screen rather than a serial console, and the kernel doesn't actually hang but you just don't see any more messages after the DRM driver takes over from EFI_EARLYCON because there is no console driver.
In this case, what you see is the intended behavior, not a bug. If you want a graphical console in your system, you need to enable the support for this in your config.
It sounds like that's the case. Unfortunately I'm not familiar with this subsystem to say that's what happening. If there's nothing actually broken from review, we can ignore this email thread.
Hi, I don't know of anything that is broken...
I am curious how CONFIG_FB_EFI came to be set when going from bad.config to good.config. Can you explain that?
thanks.
Randy Dunlap wrote:
On 2/3/22 19:21, Thinh Nguyen wrote:
Arnd Bergmann wrote:
On Thu, Feb 3, 2022 at 12:55 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Arnd Bergmann wrote:
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Fabio Estevam wrote:
CONFIG_FB should not normally be needed for booting, so unless you have a graphical application in your initramfs that requires the /dev/fb0 device to work, it is not supposed to make a difference.
I'm not sure, but it seems like the setup we have isn't the only one that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs to have CONFIG_FB set.
No, that one is different: the change for imx_v6_v7_defconfig was done because they actually use a framebuffer console on some devices, so the patch just adds the symbol to enable the drivers they are using.
This is expected with my original patch that doesn't implicitly enable the framebuffer layer any more. What is not expected is for the kernel to hang during boot as you reported for your unidentified platform.
Are there any other differences in your .config before and after the patch? It's possible that you use some other driver that in turn depends on CONFIG_FB. Does your machine have any graphical output device? If yes, which driver do you use?
I don't have the answer to those questions yet. Need more investigation. I'm new to this particular test setup.
Do you mean you don't know if there is a screen attached to the system?
It does have a graphical output device, but I didn't check what it is or what driver is driving it. I just notice that after the reported commit, something stopped working.
You may also want to make sure that you have 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency") in your kernel, which fixes a minor problem with my original patch.
The issue also occurs in mainline, which has your minor fix commit above. The revert isn't clean for the latest kernel version. I also have to revert some of the changes along with CONFIG_FB. The revert looks more like this for the latest kernel:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..7cbc733a8569 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPERdepends on FB=y || FB=DRM_KMS_HELPER
depends on DRMselect DRM_KMS_HELPERselect FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLITI attached the configs for kernel v5.17-rc1. The "bad" config is without any revert, the "good" config is with the change above.
Looking at the config, I see that this is for an x86 machine, and you have the FB_EFI driver and EFI_EARLYCON enabled.
What I suspec is going on is that you are looking at a screen rather than a serial console, and the kernel doesn't actually hang but you just don't see any more messages after the DRM driver takes over from EFI_EARLYCON because there is no console driver.
In this case, what you see is the intended behavior, not a bug. If you want a graphical console in your system, you need to enable the support for this in your config.
It sounds like that's the case. Unfortunately I'm not familiar with this subsystem to say that's what happening. If there's nothing actually broken from review, we can ignore this email thread.
Hi, I don't know of anything that is broken...
I am curious how CONFIG_FB_EFI came to be set when going from bad.config to good.config. Can you explain that?
I just use the change above and "make" with olddefconfig option. Is it not expected?
Thanks, Thinh
Hi--
On 2/8/22 12:10, Thinh Nguyen wrote:
Randy Dunlap wrote:
On 2/3/22 19:21, Thinh Nguyen wrote:
Arnd Bergmann wrote:
On Thu, Feb 3, 2022 at 12:55 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Arnd Bergmann wrote:
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote: > Fabio Estevam wrote:
CONFIG_FB should not normally be needed for booting, so unless you have a graphical application in your initramfs that requires the /dev/fb0 device to work, it is not supposed to make a difference.
I'm not sure, but it seems like the setup we have isn't the only one that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs to have CONFIG_FB set.
No, that one is different: the change for imx_v6_v7_defconfig was done because they actually use a framebuffer console on some devices, so the patch just adds the symbol to enable the drivers they are using.
This is expected with my original patch that doesn't implicitly enable the framebuffer layer any more. What is not expected is for the kernel to hang during boot as you reported for your unidentified platform.
Are there any other differences in your .config before and after the patch? It's possible that you use some other driver that in turn depends on CONFIG_FB. Does your machine have any graphical output device? If yes, which driver do you use?
I don't have the answer to those questions yet. Need more investigation. I'm new to this particular test setup.
Do you mean you don't know if there is a screen attached to the system?
It does have a graphical output device, but I didn't check what it is or what driver is driving it. I just notice that after the reported commit, something stopped working.
You may also want to make sure that you have 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency") in your kernel, which fixes a minor problem with my original patch.
The issue also occurs in mainline, which has your minor fix commit above. The revert isn't clean for the latest kernel version. I also have to revert some of the changes along with CONFIG_FB. The revert looks more like this for the latest kernel:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..7cbc733a8569 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPERdepends on FB=y || FB=DRM_KMS_HELPER
depends on DRMselect DRM_KMS_HELPERselect FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLITI attached the configs for kernel v5.17-rc1. The "bad" config is without any revert, the "good" config is with the change above.
Looking at the config, I see that this is for an x86 machine, and you have the FB_EFI driver and EFI_EARLYCON enabled.
What I suspec is going on is that you are looking at a screen rather than a serial console, and the kernel doesn't actually hang but you just don't see any more messages after the DRM driver takes over from EFI_EARLYCON because there is no console driver.
In this case, what you see is the intended behavior, not a bug. If you want a graphical console in your system, you need to enable the support for this in your config.
It sounds like that's the case. Unfortunately I'm not familiar with this subsystem to say that's what happening. If there's nothing actually broken from review, we can ignore this email thread.
Hi, I don't know of anything that is broken...
I am curious how CONFIG_FB_EFI came to be set when going from bad.config to good.config. Can you explain that?
I just use the change above and "make" with olddefconfig option. Is it not expected?
Maybe I am not doing the same as you. If I take your previous bad.config with kernel v5.17-rc2 and use your Kconfig patch:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..7cbc733a8569 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver" - depends on DRM_KMS_HELPER - depends on FB=y || FB=DRM_KMS_HELPER + depends on DRM + select DRM_KMS_HELPER + select FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT
and then run 'make olddefconfig', I see:
# CONFIG_FB_EFI is not set
which is what I would expect to see.
thanks.
Randy Dunlap wrote:
Hi--
On 2/8/22 12:10, Thinh Nguyen wrote:
Randy Dunlap wrote:
On 2/3/22 19:21, Thinh Nguyen wrote:
Arnd Bergmann wrote:
On Thu, Feb 3, 2022 at 12:55 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Arnd Bergmann wrote: > On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote: >> Fabio Estevam wrote: > > CONFIG_FB should not normally be needed for booting, so unless > you have a graphical application in your initramfs that requires the /dev/fb0 > device to work, it is not supposed to make a difference. >
I'm not sure, but it seems like the setup we have isn't the only one that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs to have CONFIG_FB set.
No, that one is different: the change for imx_v6_v7_defconfig was done because they actually use a framebuffer console on some devices, so the patch just adds the symbol to enable the drivers they are using.
This is expected with my original patch that doesn't implicitly enable the framebuffer layer any more. What is not expected is for the kernel to hang during boot as you reported for your unidentified platform.
> Are there any other differences in your .config before and after the patch? > It's possible that you use some other driver that in turn depends on > CONFIG_FB. Does your machine have any graphical output device? > If yes, which driver do you use?
I don't have the answer to those questions yet. Need more investigation. I'm new to this particular test setup.
Do you mean you don't know if there is a screen attached to the system?
It does have a graphical output device, but I didn't check what it is or what driver is driving it. I just notice that after the reported commit, something stopped working.
> > You may also want to make sure that you have 9d6366e743f3 ("drm: > fb_helper: improve CONFIG_FB dependency") in your kernel, which > fixes a minor problem with my original patch. >
The issue also occurs in mainline, which has your minor fix commit above. The revert isn't clean for the latest kernel version. I also have to revert some of the changes along with CONFIG_FB. The revert looks more like this for the latest kernel:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..7cbc733a8569 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPERdepends on FB=y || FB=DRM_KMS_HELPER
depends on DRMselect DRM_KMS_HELPERselect FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLITI attached the configs for kernel v5.17-rc1. The "bad" config is without any revert, the "good" config is with the change above.
Looking at the config, I see that this is for an x86 machine, and you have the FB_EFI driver and EFI_EARLYCON enabled.
What I suspec is going on is that you are looking at a screen rather than a serial console, and the kernel doesn't actually hang but you just don't see any more messages after the DRM driver takes over from EFI_EARLYCON because there is no console driver.
In this case, what you see is the intended behavior, not a bug. If you want a graphical console in your system, you need to enable the support for this in your config.
It sounds like that's the case. Unfortunately I'm not familiar with this subsystem to say that's what happening. If there's nothing actually broken from review, we can ignore this email thread.
Hi, I don't know of anything that is broken...
I am curious how CONFIG_FB_EFI came to be set when going from bad.config to good.config. Can you explain that?
I just use the change above and "make" with olddefconfig option. Is it not expected?
Maybe I am not doing the same as you. If I take your previous bad.config with kernel v5.17-rc2 and use your Kconfig patch:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..7cbc733a8569 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPERdepends on FB=y || FB=DRM_KMS_HELPER
depends on DRMselect DRM_KMS_HELPERselect FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLITand then run 'make olddefconfig', I see:
# CONFIG_FB_EFI is not set
which is what I would expect to see.
Ah.. It's because I don't use old.config as the base config. I use x86_64_defconfig as the base plus some additional configs I need, and it has CONFIG_FB_EFI set by default.
BR, Thinh
On Tue, Feb 8, 2022 at 11:42 PM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Randy Dunlap wrote:
On 2/8/22 12:10, Thinh Nguyen wrote:
Randy Dunlap wrote:
On 2/3/22 19:21, Thinh Nguyen wrote:
Ah.. It's because I don't use old.config as the base config. I use x86_64_defconfig as the base plus some additional configs I need, and it has CONFIG_FB_EFI set by default.
Does it hang if you just disable CONFIG_FB_EFI on an otherwise working kernel? This is supposed to only disable the framebuffer, but it could be the actual cause if something else depends on its presence.
Arnd
Arnd Bergmann wrote:
On Tue, Feb 8, 2022 at 11:42 PM Thinh Nguyen Thinh.Nguyen@synopsys.com wrote:
Randy Dunlap wrote:
On 2/8/22 12:10, Thinh Nguyen wrote:
Randy Dunlap wrote:
On 2/3/22 19:21, Thinh Nguyen wrote:
Ah.. It's because I don't use old.config as the base config. I use x86_64_defconfig as the base plus some additional configs I need, and it has CONFIG_FB_EFI set by default.
Does it hang if you just disable CONFIG_FB_EFI on an otherwise working kernel? This is supposed to only disable the framebuffer, but it could be the actual cause if something else depends on its presence.
Looks like disabling it works. Not sure why config x86_64_defconfig needs it.
Thanks, Thinh
dri-devel@lists.freedesktop.org
-
Arnd Bergmann -
Fabio Estevam -
Randy Dunlap -
Thinh Nguyen