Re: Panic on boot after upgrade from r320827 -> r320869

On Sat, Jul 15, 2017 at 1:32 PM, Michael Butler <imb_at_protected-networks.net>
wrote:

> On 07/11/17 19:53, Michael Butler wrote:
>
>> On 07/11/17 13:13, I wrote:
>>
>>> Take sdhci out of the kernel and try again. If that works, it tells us
>>>> one
>>>> thing (need to troubleshoot sdhci stuff more). If not it tells us
>>>> another
>>>> (need to troubleshoot CAM more), do we get errors with the ATA_IDENTIFY
>>>> command? Does it try multiple times per AHCI port? What AHCI device do
>>>> you
>>>> have? You may need to scroll back with the screen-lock / pageup keys to
>>>> see
>>>> these messages.
>>>>
>>>
>>   [ .. snip .. ]
>>
>> I'll try this tonight when I'm back at home. The laptop concerned uses
>>> the ICH-7M part in "legacy mode" so it doesn't do AHCI at all :-(
>>>
>>
>> Without sdhci and mmc, it actually boots but everything KDE aborts with
>> signal 6 :-(
>>
>> I'm not prepared to rebuild the ~1900 ports on this box to pursue this
>> further,
>>
>
> Something about SVN r320844 causes almost all KDE applications to fail on
> a signal 6.
>

I don't think that's possible, unless (a) your build hit the 'not
everything in the kernel rebuilt' bug or (b) KDE is issuing raw CAM
requests. Since I don't know KDE, don't run KDE or have any clue about KDE,
I can't help you trace it down further.


> I've recompiled KDE and other components obviously dependent on kernel
> structures (e.g. everything dbus-related). I still get core-files with a
> back-trace that looks like:
>
> (gdb) bt
> #0  0x0000000804232f6a in thr_kill () from /lib/libc.so.7
> #1  0x0000000804232f34 in raise () from /lib/libc.so.7
> #2  0x0000000804232ea9 in abort () from /lib/libc.so.7
> #3  0x00000008188597af in ?? () from /usr/local/lib/libdbus-1.so.3
> #4  0x000000081884ef2c in _dbus_warn_check_failed () from
> /usr/local/lib/libdbus-1.so.3
> #5  0x000000081883f539 in dbus_message_new_method_call () from
> /usr/local/lib/libdbus-1.so.3
> #6  0x0000000801bddfe8 in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
> #7  0x0000000801bd591e in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
> #8  0x0000000801bd9af6 in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
> #9  0x0000000801be656d in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
> #10 0x0000000801be6807 in QDBusInterface::QDBusInterface(QString const&,
> QString const&, QString const&, QDBusConnection const&, QObject*) ()
>    from /usr/local/lib/qt4/libQtDBus.so.4
> #11 0x000000080d12728e in ?? () from /usr/local/lib/libsolid.so.4
> #12 0x000000080d11e68c in ?? () from /usr/local/lib/libsolid.so.4
> #13 0x000000080d12a525 in ?? () from /usr/local/lib/libsolid.so.4
> #14 0x000000080d0e7aac in Solid::Device::listFromType(Solid::DeviceInterface::Type
> const&, QString const&) () from /usr/local/lib/libsolid.so.4
> #15 0x000000080e7e889a in ?? () from /usr/local/lib/libplasma.so.3
> #16 0x000000080e7e6094 in Plasma::RunnerManager::RunnerManager(QObject*)
> () from /usr/local/lib/libplasma.so.3
> #17 0x00000008172fab42 in ?? () from /usr/local/lib/libkdeinit4_krunner.so
> #18 0x00000008172fa9b4 in ?? () from /usr/local/lib/libkdeinit4_krunner.so
>
> #19 0x00000008172fd303 in kdemain () from /usr/local/lib/libkdeinit4_krunner.so
>
> #20 0x000000000040a015 in ?? ()
>
> #21 0x000000000040aec0 in ?? ()
>
>
> SVN r320843 works, r320844 doesn't :-(
>

I'd look to see if any of that software uses a CAM CCB for any reason.
That's the only thing I can think of that might have been affected. Perhaps
it's doing an identify? There was one CCB that changed size (and did so in
an incompatible way between rev 320844 and 320878), I didn't think it was
user visible.

Does camcontrol identify or camcontrol inquiry work?

Warner