Hi,
new kernel release cycle returning with new bugs
Today my system got stuck in initramfs environment after updating to
commit d2980d8d826554fa6981d621e569a453787472f8.
I still do not understand how to configure the network inside the
initramfs environment to grab the logs.
Since an attempt to rebuild the initramfs with all modules (dracut
--no-hostonly --force) leads to the stuck initramfs environment and
impossible entering into initramfs console.
But I can bisect the problem and bisection blames this commit:
❯ git bisect good
7170b7ed6acbde523c5d362c8978c60df4c30f30 is the first bad commit
commit 7170b7ed6acbde523c5d362c8978c60df4c30f30
Author: David Gow <[email protected]>
Date: Sat Jan 28 15:10:07 2023 +0800
kunit: Add "hooks" to call into KUnit when it's built as a module
KUnit has several macros and functions intended for use from non-test
code. These hooks, currently the kunit_get_current_test() and
kunit_fail_current_test() macros, didn't work when CONFIG_KUNIT=m.
In order to support this case, the required functions and static data
need to be available unconditionally, even when KUnit itself is not
built-in. The new 'hooks.c' file is therefore always included, and has
both the static key required for kunit_get_current_test(), and a table
of function pointers in struct kunit_hooks_table. This is filled in with
the real implementations by kunit_install_hooks(), which is kept in
hooks-impl.h and called when the kunit module is loaded.
This can be extended for future features which require similar
"hook" behaviour, such as static stubs, by simply adding new entries to
the struct, and the appropriate code to set them.
Fixed white-space errors during commit:
Shuah Khan <[email protected]>
Resolved merge conflicts with:
db105c37a4d6 ("kunit: Export kunit_running()")
This patch supersedes the above.
Shuah Khan <[email protected]>
Signed-off-by: David Gow <[email protected]>
Reviewed-by: Rae Moar <[email protected]>
Reviewed-by: Brendan Higgins <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
Documentation/dev-tools/kunit/usage.rst | 15 ++++++---------
include/kunit/test-bug.h | 28 ++++++++++------------------
lib/Makefile | 8 ++++++++
lib/kunit/Makefile | 3 +++
lib/kunit/hooks-impl.h | 27 +++++++++++++++++++++++++++
lib/kunit/hooks.c | 21 +++++++++++++++++++++
lib/kunit/test.c | 15 +++++++--------
7 files changed, 82 insertions(+), 35 deletions(-)
create mode 100644 lib/kunit/hooks-impl.h
create mode 100644 lib/kunit/hooks.c
Unfortunately I couldn't revert this commit staying on
d2980d8d826554fa6981d621e569a453787472f8 because of conflicts:
❯ git revert 7170b7ed6acbde523c5d362c8978c60df4c30f30 -n
Auto-merging include/kunit/test-bug.h
CONFLICT (content): Merge conflict in include/kunit/test-bug.h
Auto-merging lib/Makefile
Auto-merging lib/kunit/Makefile
CONFLICT (modify/delete): lib/kunit/hooks-impl.h deleted in parent of
7170b7ed6acb (kunit: Add "hooks" to call into KUnit when it's built as
a module) and modified in HEAD. Version HEAD of
lib/kunit/hooks-impl.h left in tree.
Auto-merging lib/kunit/test.c
CONFLICT (content): Merge conflict in lib/kunit/test.c
error: could not revert 7170b7ed6acb... kunit: Add "hooks" to call
into KUnit when it's built as a module
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
--
Best Regards,
Mike Gavrilov.
[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]
On 25.02.23 14:51, Mikhail Gavrilov wrote:
> new kernel release cycle returning with new bugs
> Today my system got stuck in initramfs environment after updating to
> commit d2980d8d826554fa6981d621e569a453787472f8.
>
> I still do not understand how to configure the network inside the
> initramfs environment to grab the logs.
> Since an attempt to rebuild the initramfs with all modules (dracut
> --no-hostonly --force) leads to the stuck initramfs environment and
> impossible entering into initramfs console.
Do you see any error messages? I have problems since Friday morning as
well (stuck in Fedora's initramfs) and see a lot of BPF warnings like
"BPF: invalid name" and "failed to validate module". Was able to do a
screenshot:
https://www.leemhuis.info/files/misc/Screenshot_ktst-f36-x86-64_2023-02-24_07:53:14.png
Funny detail: my Thursday morning built for my Fedora vanilla repos[1]
(which happened after the main net and thus bpf merge) worked; my Friday
morning built (which among others contained the kunit updates) was the
first to fail, so maybe we have the same problem. I did a quick
localmodconfig earlier today, which worked (but localmodconfig disabled
KUNIT, which might explain why it worked).
Ciao, Thorsten
[1] https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories
> But I can bisect the problem and bisection blames this commit:
>
> ❯ git bisect good
> 7170b7ed6acbde523c5d362c8978c60df4c30f30 is the first bad commit
> commit 7170b7ed6acbde523c5d362c8978c60df4c30f30
> Author: David Gow <[email protected]>
> Date: Sat Jan 28 15:10:07 2023 +0800
>
> kunit: Add "hooks" to call into KUnit when it's built as a module
>
> KUnit has several macros and functions intended for use from non-test
> code. These hooks, currently the kunit_get_current_test() and
> kunit_fail_current_test() macros, didn't work when CONFIG_KUNIT=m.
>
> In order to support this case, the required functions and static data
> need to be available unconditionally, even when KUnit itself is not
> built-in. The new 'hooks.c' file is therefore always included, and has
> both the static key required for kunit_get_current_test(), and a table
> of function pointers in struct kunit_hooks_table. This is filled in with
> the real implementations by kunit_install_hooks(), which is kept in
> hooks-impl.h and called when the kunit module is loaded.
>
> This can be extended for future features which require similar
> "hook" behaviour, such as static stubs, by simply adding new entries to
> the struct, and the appropriate code to set them.
>
> Fixed white-space errors during commit:
> Shuah Khan <[email protected]>
>
> Resolved merge conflicts with:
> db105c37a4d6 ("kunit: Export kunit_running()")
> This patch supersedes the above.
> Shuah Khan <[email protected]>
>
> Signed-off-by: David Gow <[email protected]>
> Reviewed-by: Rae Moar <[email protected]>
> Reviewed-by: Brendan Higgins <[email protected]>
> Signed-off-by: Shuah Khan <[email protected]>
>
> Documentation/dev-tools/kunit/usage.rst | 15 ++++++---------
> include/kunit/test-bug.h | 28 ++++++++++------------------
> lib/Makefile | 8 ++++++++
> lib/kunit/Makefile | 3 +++
> lib/kunit/hooks-impl.h | 27 +++++++++++++++++++++++++++
> lib/kunit/hooks.c | 21 +++++++++++++++++++++
> lib/kunit/test.c | 15 +++++++--------
> 7 files changed, 82 insertions(+), 35 deletions(-)
> create mode 100644 lib/kunit/hooks-impl.h
> create mode 100644 lib/kunit/hooks.c
>
> Unfortunately I couldn't revert this commit staying on
> d2980d8d826554fa6981d621e569a453787472f8 because of conflicts:
> ❯ git revert 7170b7ed6acbde523c5d362c8978c60df4c30f30 -n
> Auto-merging include/kunit/test-bug.h
> CONFLICT (content): Merge conflict in include/kunit/test-bug.h
> Auto-merging lib/Makefile
> Auto-merging lib/kunit/Makefile
> CONFLICT (modify/delete): lib/kunit/hooks-impl.h deleted in parent of
> 7170b7ed6acb (kunit: Add "hooks" to call into KUnit when it's built as
> a module) and modified in HEAD. Version HEAD of
> lib/kunit/hooks-impl.h left in tree.
> Auto-merging lib/kunit/test.c
> CONFLICT (content): Merge conflict in lib/kunit/test.c
> error: could not revert 7170b7ed6acb... kunit: Add "hooks" to call
> into KUnit when it's built as a module
> hint: after resolving the conflicts, mark the corrected paths
> hint: with 'git add <paths>' or 'git rm <paths>'
>
On Sat, Feb 25, 2023 at 7:22 PM Thorsten Leemhuis <[email protected]> wrote:
>
> [CCing the regression list, as it should be in the loop for regressions:
> https://docs.kernel.org/admin-guide/reporting-regressions.html]
>
> On 25.02.23 14:51, Mikhail Gavrilov wrote:
> > new kernel release cycle returning with new bugs
> > Today my system got stuck in initramfs environment after updating to
> > commit d2980d8d826554fa6981d621e569a453787472f8.
> >
> > I still do not understand how to configure the network inside the
> > initramfs environment to grab the logs.
> > Since an attempt to rebuild the initramfs with all modules (dracut
> > --no-hostonly --force) leads to the stuck initramfs environment and
> > impossible entering into initramfs console.
>
> Do you see any error messages? I have problems since Friday morning as
> well (stuck in Fedora's initramfs) and see a lot of BPF warnings like
> "BPF: invalid name" and "failed to validate module". Was able to do a
> screenshot:
>
> https://www.leemhuis.info/files/misc/Screenshot_ktst-f36-x86-64_2023-02-24_07:53:14.png
>
I also seen such messages
https://freeimage.host/i/img-1475.HMPL26l
And if initramfs is configured without --no-hostonly I even could
enter in emergency mode.
https://freeimage.host/i/img-1480.HMPsZ3N
But the module for my Keychrone K1 keyboard couldn't be loaded :(
P.S.: I also use Fedora Rawhide.
--
Best Regards,
Mike Gavrilov.
On 25.02.23 15:55, Mikhail Gavrilov wrote:
> On Sat, Feb 25, 2023 at 7:22 PM Thorsten Leemhuis <[email protected]> wrote:
>>
>> [CCing the regression list, as it should be in the loop for regressions:
>> https://docs.kernel.org/admin-guide/reporting-regressions.html]
>>
>> On 25.02.23 14:51, Mikhail Gavrilov wrote:
>>> new kernel release cycle returning with new bugs
>>> Today my system got stuck in initramfs environment after updating to
>>> commit d2980d8d826554fa6981d621e569a453787472f8.
>>>
>>> I still do not understand how to configure the network inside the
>>> initramfs environment to grab the logs.
>>> Since an attempt to rebuild the initramfs with all modules (dracut
>>> --no-hostonly --force) leads to the stuck initramfs environment and
>>> impossible entering into initramfs console.
>>
>> Do you see any error messages? I have problems since Friday morning as
>> well (stuck in Fedora's initramfs) and see a lot of BPF warnings like
>> "BPF: invalid name" and "failed to validate module". Was able to do a
>> screenshot:
>>
>> https://www.leemhuis.info/files/misc/Screenshot_ktst-f36-x86-64_2023-02-24_07:53:14.png
>
> I also seen such messages
> https://freeimage.host/i/img-1475.HMPL26l
Pretty sure that's the same problem, at least the symptoms match. If
anyone needs a config to reproduce this, here's one of mine that shows
the problem:
https://www.leemhuis.info/files/misc/config
> P.S.: I also use Fedora Rawhide.
Happens for me on all Fedora 36, 37, and 38 (my rawhide build failed for
other reasons, so I couldn't test).
Ciao, Thorsten
On Sat, 25 Feb 2023 at 23:53, Thorsten Leemhuis <[email protected]> wrote:
>
> On 25.02.23 15:55, Mikhail Gavrilov wrote:
> > On Sat, Feb 25, 2023 at 7:22 PM Thorsten Leemhuis <[email protected]> wrote:
> >>
> >> [CCing the regression list, as it should be in the loop for regressions:
> >> https://docs.kernel.org/admin-guide/reporting-regressions.html]
> >>
> >> On 25.02.23 14:51, Mikhail Gavrilov wrote:
> >>> new kernel release cycle returning with new bugs
> >>> Today my system got stuck in initramfs environment after updating to
> >>> commit d2980d8d826554fa6981d621e569a453787472f8.
> >>>
> >>> I still do not understand how to configure the network inside the
> >>> initramfs environment to grab the logs.
> >>> Since an attempt to rebuild the initramfs with all modules (dracut
> >>> --no-hostonly --force) leads to the stuck initramfs environment and
> >>> impossible entering into initramfs console.
> >>
> >> Do you see any error messages? I have problems since Friday morning as
> >> well (stuck in Fedora's initramfs) and see a lot of BPF warnings like
> >> "BPF: invalid name" and "failed to validate module". Was able to do a
> >> screenshot:
> >>
> >> https://www.leemhuis.info/files/misc/Screenshot_ktst-f36-x86-64_2023-02-24_07:53:14.png
> >
> > I also seen such messages
> > https://freeimage.host/i/img-1475.HMPL26l
>
> Pretty sure that's the same problem, at least the symptoms match. If
> anyone needs a config to reproduce this, here's one of mine that shows
> the problem:
>
> https://www.leemhuis.info/files/misc/config
>
> > P.S.: I also use Fedora Rawhide.
>
> Happens for me on all Fedora 36, 37, and 38 (my rawhide build failed for
> other reasons, so I couldn't test).
>
> Ciao, Thorsten
Thanks for the report, and sorry this seems to have broken.
I've not been able to reproduce this locally yet, but I'm looking into it.
In the meantime, a few questions if you have time:
- Does this happen with CONFIG_KUNIT=y as well as CONFIG_KUNIT=m?
- Does this patch fix it?
https://lore.kernel.org/linux-kselftest/[email protected]/T/#u
I can't think of any particular reason this commit would cause these
problems, but there were some issues with the way these 'hooks' were
built, so it's possibly related.
Sorry again for the inconvenience!
Cheers,
-- David
On 26.02.23 02:11, David Gow wrote:
> On Sat, 25 Feb 2023 at 23:53, Thorsten Leemhuis <[email protected]> wrote:
>> On 25.02.23 15:55, Mikhail Gavrilov wrote:
>>> On Sat, Feb 25, 2023 at 7:22 PM Thorsten Leemhuis <[email protected]> wrote:
>>>>
>>>> [CCing the regression list, as it should be in the loop for regressions:
>>>> https://docs.kernel.org/admin-guide/reporting-regressions.html]
>>>>
>>>> On 25.02.23 14:51, Mikhail Gavrilov wrote:
>>>>> new kernel release cycle returning with new bugs
>>>>> Today my system got stuck in initramfs environment after updating to
>>>>> commit d2980d8d826554fa6981d621e569a453787472f8.
>>>>>
>>>>> I still do not understand how to configure the network inside the
>>>>> initramfs environment to grab the logs.
>>>>> Since an attempt to rebuild the initramfs with all modules (dracut
>>>>> --no-hostonly --force) leads to the stuck initramfs environment and
>>>>> impossible entering into initramfs console.
>>>>
>>>> Do you see any error messages? I have problems since Friday morning as
>>>> well (stuck in Fedora's initramfs) and see a lot of BPF warnings like
>>>> "BPF: invalid name" and "failed to validate module". Was able to do a
>>>> screenshot:
>>>>
>>>> https://www.leemhuis.info/files/misc/Screenshot_ktst-f36-x86-64_2023-02-24_07:53:14.png
>>>
>>> I also seen such messages
>>> https://freeimage.host/i/img-1475.HMPL26l
>>
>> Pretty sure that's the same problem, at least the symptoms match. If
>> anyone needs a config to reproduce this, here's one of mine that shows
>> the problem:
>>
>> https://www.leemhuis.info/files/misc/config
>>
>>> P.S.: I also use Fedora Rawhide.
>>
>> Happens for me on all Fedora 36, 37, and 38 (my rawhide build failed for
>> other reasons, so I couldn't test).
>
> Thanks for the report, and sorry this seems to have broken.
>
> I've not been able to reproduce this locally yet, but I'm looking into it.
>
> In the meantime, a few questions if you have time:
> - Does this happen with CONFIG_KUNIT=y as well as CONFIG_KUNIT=m?
> - Does this patch fix it?
> https://lore.kernel.org/linux-kselftest/[email protected]/T/#u
Sorry, limited time and about to leave the house for the day. I only
could try the latter and did only do a very quick test, but it seems
that patch fixes the issue for me.
Ciao, Thorsten
> I can't think of any particular reason this commit would cause these
> problems, but there were some issues with the way these 'hooks' were
> built, so it's possibly related.
>
> Sorry again for the inconvenience!
>
> Cheers,
> -- David
On Sun, 26 Feb 2023 at 14:02, Thorsten Leemhuis <[email protected]> wrote:
>
> On 26.02.23 02:11, David Gow wrote:
> > On Sat, 25 Feb 2023 at 23:53, Thorsten Leemhuis <[email protected]> wrote:
> >> On 25.02.23 15:55, Mikhail Gavrilov wrote:
> >>> On Sat, Feb 25, 2023 at 7:22 PM Thorsten Leemhuis <[email protected]> wrote:
> >>>>
> >>>> [CCing the regression list, as it should be in the loop for regressions:
> >>>> https://docs.kernel.org/admin-guide/reporting-regressions.html]
> >>>>
> >>>> On 25.02.23 14:51, Mikhail Gavrilov wrote:
> >>>>> new kernel release cycle returning with new bugs
> >>>>> Today my system got stuck in initramfs environment after updating to
> >>>>> commit d2980d8d826554fa6981d621e569a453787472f8.
> >>>>>
> >>>>> I still do not understand how to configure the network inside the
> >>>>> initramfs environment to grab the logs.
> >>>>> Since an attempt to rebuild the initramfs with all modules (dracut
> >>>>> --no-hostonly --force) leads to the stuck initramfs environment and
> >>>>> impossible entering into initramfs console.
> >>>>
> >>>> Do you see any error messages? I have problems since Friday morning as
> >>>> well (stuck in Fedora's initramfs) and see a lot of BPF warnings like
> >>>> "BPF: invalid name" and "failed to validate module". Was able to do a
> >>>> screenshot:
> >>>>
> >>>> https://www.leemhuis.info/files/misc/Screenshot_ktst-f36-x86-64_2023-02-24_07:53:14.png
> >>>
> >>> I also seen such messages
> >>> https://freeimage.host/i/img-1475.HMPL26l
> >>
> >> Pretty sure that's the same problem, at least the symptoms match. If
> >> anyone needs a config to reproduce this, here's one of mine that shows
> >> the problem:
> >>
> >> https://www.leemhuis.info/files/misc/config
> >>
> >>> P.S.: I also use Fedora Rawhide.
> >>
> >> Happens for me on all Fedora 36, 37, and 38 (my rawhide build failed for
> >> other reasons, so I couldn't test).
> >
> > Thanks for the report, and sorry this seems to have broken.
> >
> > I've not been able to reproduce this locally yet, but I'm looking into it.
> >
> > In the meantime, a few questions if you have time:
> > - Does this happen with CONFIG_KUNIT=y as well as CONFIG_KUNIT=m?
> > - Does this patch fix it?
> > https://lore.kernel.org/linux-kselftest/[email protected]/T/#u
>
> Sorry, limited time and about to leave the house for the day. I only
> could try the latter and did only do a very quick test, but it seems
> that patch fixes the issue for me.
>
Thanks! Glad to hear that patch seems to fix it: we'll try to get it
upstream as soon as possible, then.
I wouldn't worry about testing with CONFIG_KUNIT=y as well at this
point: I doubt it'll shed any more light on the situation.
I've still been unable to reproduce the issue here, even with a fresh
install of Fedora Rawhide, and a very recent torvalds/master:
1ec35eadc3b4 ("Merge tag 'clk-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux")[1].
I even tried plugging in a Keychron C2 keyboard (which also uses
hid_apple), as well as running several KUnit tests which make use of
the hooks functionality: everything worked fine.
Given everything else seems fine here, and the makefile issues fixed
by the above patch both seems to fix this, and is the only real issue
I could imagine having unpredictable behaviour, I'm reasonably happy
to consider this "fixed" by that patch. But if this patch _doesn't_
fix it, or you continue to see some other strange behaviour, we can
look into fixing it further.
Thanks again,
-- David
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1ec35eadc3b448c91a6b763371a7073444e95f9d
On Sun, Feb 26, 2023 at 6:11 AM David Gow <[email protected]> wrote:
>
> Thanks for the report, and sorry this seems to have broken.
>
> I've not been able to reproduce this locally yet, but I'm looking into it.
>
> In the meantime, a few questions if you have time:
> - Does this happen with CONFIG_KUNIT=y as well as CONFIG_KUNIT=m?
Yes. CONFIG_KUNIT=y or CONFIG_KUNIT=m it doesn't matter. Both options
leads to being stuck in initramfs forever.
> - Does this patch fix it?
> https://lore.kernel.org/linux-kselftest/[email protected]/T/#u
Yes. The patch by this link fixes the issue. Thanks.
Tested-by: Mikhail Gavrilov <[email protected]>
--
Best Regards,
Mike Gavrilov.
On 26.02.23 08:31, David Gow wrote:
> On Sun, 26 Feb 2023 at 14:02, Thorsten Leemhuis <[email protected]> wrote:
>> On 26.02.23 02:11, David Gow wrote:
>>> On Sat, 25 Feb 2023 at 23:53, Thorsten Leemhuis <[email protected]> wrote:
>>>> On 25.02.23 15:55, Mikhail Gavrilov wrote:
>>>>> On Sat, Feb 25, 2023 at 7:22 PM Thorsten Leemhuis <[email protected]> wrote:
>>>>>>
>>>>>> [CCing the regression list, as it should be in the loop for regressions:
>>>>>> https://docs.kernel.org/admin-guide/reporting-regressions.html]
>>>>>>
>>>>>> On 25.02.23 14:51, Mikhail Gavrilov wrote:
>>>>>>> new kernel release cycle returning with new bugs
>>>>>>> Today my system got stuck in initramfs environment after updating to
>>>>>>> commit d2980d8d826554fa6981d621e569a453787472f8.
>>>>>>>
>>>>>>> I still do not understand how to configure the network inside the
>>>>>>> initramfs environment to grab the logs.
>>>>>>> Since an attempt to rebuild the initramfs with all modules (dracut
>>>>>>> --no-hostonly --force) leads to the stuck initramfs environment and
>>>>>>> impossible entering into initramfs console.
>>>>>>
>>>>>> Do you see any error messages? I have problems since Friday morning as
>>>>>> well (stuck in Fedora's initramfs) and see a lot of BPF warnings like
>>>>>> "BPF: invalid name" and "failed to validate module". Was able to do a
>>>>>> screenshot:
>>>>>>
>>>>>> https://www.leemhuis.info/files/misc/Screenshot_ktst-f36-x86-64_2023-02-24_07:53:14.png
>>>>>
>>>>> I also seen such messages
>>>>> https://freeimage.host/i/img-1475.HMPL26l
>>>>
>>>> Pretty sure that's the same problem, at least the symptoms match. If
>>>> anyone needs a config to reproduce this, here's one of mine that shows
>>>> the problem:
>>>>
>>>> https://www.leemhuis.info/files/misc/config
>>>>
>>>>> P.S.: I also use Fedora Rawhide.
>>>>
>>>> Happens for me on all Fedora 36, 37, and 38 (my rawhide build failed for
>>>> other reasons, so I couldn't test).
>>>
>>> Thanks for the report, and sorry this seems to have broken.
>>>
>>> I've not been able to reproduce this locally yet, but I'm looking into it.
>>>
>>> In the meantime, a few questions if you have time:
>>> - Does this happen with CONFIG_KUNIT=y as well as CONFIG_KUNIT=m?
>>> - Does this patch fix it?
>>> https://lore.kernel.org/linux-kselftest/[email protected]/T/#u
>>
>> Sorry, limited time and about to leave the house for the day. I only
>> could try the latter and did only do a very quick test, but it seems
>> that patch fixes the issue for me.
>>
>
> Thanks! Glad to hear that patch seems to fix it: we'll try to get it
> upstream as soon as possible, then.
Great. I did some more tests (still not much) earlier today, feel free
Tested-by: Thorsten Leemhuis <[email protected]>
but I don't care if that doesn't make it.
> I wouldn't worry about testing with CONFIG_KUNIT=y as well at this
> point: I doubt it'll shed any more light on the situation.
>
> I've still been unable to reproduce the issue here, even with a fresh
> install of Fedora Rawhide, and a very recent torvalds/master:
Strange. Wondering if that has something to do with the way Mikhail and
I build the kernel. I'm build using something that very closely
resembles the SRPM used by Fedora.
> [...]
> Given everything else seems fine here, and the makefile issues fixed
> by the above patch both seems to fix this, and is the only real issue
> I could imagine having unpredictable behaviour, I'm reasonably happy
> to consider this "fixed" by that patch. But if this patch _doesn't_
> fix it, or you continue to see some other strange behaviour, we can
> look into fixing it further.
+1
Ciao, Thorsten
