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.
--
~Randy
Hi Thinh,
On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap <[email protected]> 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=v5.17-rc2&id=c54467482ffd407a4404c990697f432bfcb6cdc4
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 <[email protected]> wrote:
>>>> Fabio Estevam wrote:
>>>>> On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap <[email protected]> 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.
>
> 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
Hi,
Fabio Estevam wrote:
> Hi Thinh,
>
> On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap <[email protected]> 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/torvalds/linux.git/commit/?h=v5.17-rc2&id=c54467482ffd407a4404c990697f432bfcb6cdc4__;!!A4F2R9G_pg!JDcPdVX2KHTTcIAjPRE57a4oF9vw8jOBecFs72ia13jhK5q6GNtBrSuA-zpNCZhuVY6t$
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 <[email protected]> wrote:
>>> Arnd Bergmann wrote:
>>>> On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen <[email protected]> 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_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.
>>
>> 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
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 <[email protected]> wrote:
>>>> Arnd Bergmann wrote:
>>>>> On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen <[email protected]> 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_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.
>>>
>>> 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 <[email protected]> wrote:
>>>>> Arnd Bergmann wrote:
>>>>>> On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen <[email protected]> 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_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.
>>>>
>>>> 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
On Tue, Feb 8, 2022 at 11:42 PM Thinh Nguyen <[email protected]> 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
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 <[email protected]> wrote:
>>>>>> Arnd Bergmann wrote:
>>>>>>> On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen <[email protected]> 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_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.
>>>>>
>>>>> 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.
>
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
Arnd Bergmann wrote:
> On Tue, Feb 8, 2022 at 11:42 PM Thinh Nguyen <[email protected]> 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