Hi,
I recently had trouble with loading a 4.9rcX kernel, which was hanging
after loading the initial kernel ramdisk. After some painful bisecting
I found this:
bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
commit bea5b158ff0da9c7246ff391f754f5f38e34577a
Author: Rob Herring <[email protected]>
Date: Thu Aug 11 10:20:58 2016 -0500
driver core: add test of driver remove calls during probe
In recent discussions on ksummit-discuss[1], it was suggested to do a
sequence of probe, remove, probe for testing driver remove paths. This
adds a kconfig option for said test.
[1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
Suggested-by: Arnd Bergmann <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
It turns out that the package i was using to build the kernel had
DEBUG_TEST_DRIVER_REMOVE enabled.
How do I actually figure out why this test causes a hang. I don't have
a COM port available to use as serial console, and i don't know if it
would even help.
Please CC me as i'm not a member of this mailinglist.
Maarten.
--
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
Anyone have suggestions?
On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis <[email protected]> wrote:
> Hi,
>
> I recently had trouble with loading a 4.9rcX kernel, which was hanging
> after loading the initial kernel ramdisk. After some painful bisecting
> I found this:
>
> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
> Author: Rob Herring <[email protected]>
> Date: Thu Aug 11 10:20:58 2016 -0500
>
> driver core: add test of driver remove calls during probe
>
> In recent discussions on ksummit-discuss[1], it was suggested to do a
> sequence of probe, remove, probe for testing driver remove paths. This
> adds a kconfig option for said test.
>
> [1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>
> Suggested-by: Arnd Bergmann <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Rob Herring <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> It turns out that the package i was using to build the kernel had
> DEBUG_TEST_DRIVER_REMOVE enabled.
>
> How do I actually figure out why this test causes a hang. I don't have
> a COM port available to use as serial console, and i don't know if it
> would even help.
>
> Please CC me as i'm not a member of this mailinglist.
>
> Maarten.
>
> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.
--
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
Anyone have advice where else I can ask?
On Sat, Oct 29, 2016 at 1:07 PM, Maarten Maathuis <[email protected]> wrote:
> Anyone have suggestions?
>
> On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis <[email protected]> wrote:
>> Hi,
>>
>> I recently had trouble with loading a 4.9rcX kernel, which was hanging
>> after loading the initial kernel ramdisk. After some painful bisecting
>> I found this:
>>
>> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
>> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
>> Author: Rob Herring <[email protected]>
>> Date: Thu Aug 11 10:20:58 2016 -0500
>>
>> driver core: add test of driver remove calls during probe
>>
>> In recent discussions on ksummit-discuss[1], it was suggested to do a
>> sequence of probe, remove, probe for testing driver remove paths. This
>> adds a kconfig option for said test.
>>
>> [1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>>
>> Suggested-by: Arnd Bergmann <[email protected]>
>> Cc: Greg Kroah-Hartman <[email protected]>
>> Signed-off-by: Rob Herring <[email protected]>
>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>
>> It turns out that the package i was using to build the kernel had
>> DEBUG_TEST_DRIVER_REMOVE enabled.
>>
>> How do I actually figure out why this test causes a hang. I don't have
>> a COM port available to use as serial console, and i don't know if it
>> would even help.
>>
>> Please CC me as i'm not a member of this mailinglist.
>>
>> Maarten.
>>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.
>
>
>
> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.
--
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
On 11/04/16 13:47, Maarten Maathuis wrote:
> Anyone have advice where else I can ask?
>
> On Sat, Oct 29, 2016 at 1:07 PM, Maarten Maathuis <[email protected]> wrote:
>> Anyone have suggestions?
Besides serial console, there are also netconsole, earlycon (probably not
useful to you), and earlyprintk.
You can use the boot option "initcall_debug" to see what drivers are being loaded
and possibly which one is causing the system hang.
You can use the boot option "ignore_loglevel" to have all kernel messages printed.
Who is enabling DEBUG_TEST_DRIVER_REMOVE? Its help text says:
This option is expected to find errors and may render your system
unusable. You should say N here unless you are explicitly looking to
test this functionality.
>> On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis <[email protected]> wrote:
>>> Hi,
>>>
>>> I recently had trouble with loading a 4.9rcX kernel, which was hanging
>>> after loading the initial kernel ramdisk. After some painful bisecting
>>> I found this:
>>>
>>> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
>>> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
>>> Author: Rob Herring <[email protected]>
>>> Date: Thu Aug 11 10:20:58 2016 -0500
>>>
>>> driver core: add test of driver remove calls during probe
>>>
>>> In recent discussions on ksummit-discuss[1], it was suggested to do a
>>> sequence of probe, remove, probe for testing driver remove paths. This
>>> adds a kconfig option for said test.
>>>
>>> [1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>>>
>>> Suggested-by: Arnd Bergmann <[email protected]>
>>> Cc: Greg Kroah-Hartman <[email protected]>
>>> Signed-off-by: Rob Herring <[email protected]>
>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>
>>> It turns out that the package i was using to build the kernel had
>>> DEBUG_TEST_DRIVER_REMOVE enabled.
>>>
>>> How do I actually figure out why this test causes a hang. I don't have
>>> a COM port available to use as serial console, and i don't know if it
>>> would even help.
>>>
>>> Please CC me as i'm not a member of this mailinglist.
>>>
>>> Maarten.
--
~Randy