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

[Michael Butler]

On 07/15/17 15:32, I wrote:

Something about SVN r320844 causes almost all KDE applications to fail 
on a signal 6.


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:


 [ .. ]


SVN r320843 works, r320844 doesn't :-(


Apparently, the failing port was HALD. It couldn't accept the revised 
kernel structure, failed and caused a cascade of failures up the KDE 
process-chain, including DBUS. Sorry it took so long to find :-(


Recompiling HALD fixed the problem,

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mark Millard]

Warner Losh imp at bsdimp.com wrote on Sat Jul 15 23:22:22 UTC 2017 :

> On Sat, Jul 15, 2017 at 1:32 PM, Michael Butler  protected-networks.net>
> wrote:
> 
> > On 07/11/17 19:53, Michael Butler wrote:
> >
> . . .
> >
> > 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.

FYI for Michael B.: the incomplete kernel rebuild problem has a fix: -r320919 .
See the fix (to the building problem that was created in -r320220 ):

https://lists.freebsd.org/pipermail/svn-src-head/2017-July/102622.html

If the KDE problem persists based on a -r320919 or later build, it would
be appropriate to report it again as a separate issue.

Unfortunately various odd problems have shown up over -r320220 through
-r320918 from incorrect rebuilds (and other oddities overlapping in the
time frame).

Of course if you built (or build) -r320844 based on a empty directory in
the first place so that it was a full-build but the KDE problem persisted
when using the rebuilt kernel then the above material does not apply. In
such a case reporting that about the context for the KDE problem would be
appropriate.

You may well have other things to be doing instead of what the above
suggests. If so, just take the above as background information.


===
Mark Millard
markmi at dsl-only.net

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Warner Losh]

On Sat, Jul 15, 2017 at 6:49 PM, Michael Butler 
wrote:

> On 07/15/17 20:39, Mark Millard wrote:
>
>> FYI for Michael B.: the incomplete kernel rebuild problem has a fix:
>> -r320919 .
>> See the fix (to the building problem that was created in -r320220 ):
>>
>> https://lists.freebsd.org/pipermail/svn-src-head/2017-July/102622.html
>>
>> If the KDE problem persists based on a -r320919 or later build, it would
>> be appropriate to report it again as a separate issue.
>>
>> Unfortunately various odd problems have shown up over -r320220 through
>> -r320918 from incorrect rebuilds (and other oddities overlapping in the
>> time frame).
>>
>> Of course if you built (or build) -r320844 based on a empty directory in
>> the first place so that it was a full-build but the KDE problem persisted
>> when using the rebuilt kernel then the above material does not apply. In
>> such a case reporting that about the context for the KDE problem would be
>> appropriate.
>>
>> You may well have other things to be doing instead of what the above
>> suggests. If so, just take the above as background information.
>>
>
> Prior to testing this, I did 'rm -rf /usr/obj/*' so it is a clean build. I
> can run with user-land at SVN r321021 but any kernel at or after r320844
> fails :-(
>

Right. We need to find out what, exactly, is failing to make progress. I
have exactly one guess as to what might be going on, and it's a long shot
at best. To gather more evidence, I need to know if the kde thing that's
segfaulting is accessing /dev/pass* or /dev/xpt*. If you can confirm that
it is, then we'll need to see how to fix that.

Also, you'll need an installworld as well as an installkernel so the new
headers are installed prior to running kde. If that fixes it, then my guess
goes from a long shot to close to a sure thing.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Michael Butler]

On 07/15/17 20:39, Mark Millard wrote:

FYI for Michael B.: the incomplete kernel rebuild problem has a fix: -r320919 .
See the fix (to the building problem that was created in -r320220 ):

https://lists.freebsd.org/pipermail/svn-src-head/2017-July/102622.html

If the KDE problem persists based on a -r320919 or later build, it would
be appropriate to report it again as a separate issue.

Unfortunately various odd problems have shown up over -r320220 through
-r320918 from incorrect rebuilds (and other oddities overlapping in the
time frame).

Of course if you built (or build) -r320844 based on a empty directory in
the first place so that it was a full-build but the KDE problem persisted
when using the rebuilt kernel then the above material does not apply. In
such a case reporting that about the context for the KDE problem would be
appropriate.

You may well have other things to be doing instead of what the above
suggests. If so, just take the above as background information.


Prior to testing this, I did 'rm -rf /usr/obj/*' so it is a clean build. 
I can run with user-land at SVN r321021 but any kernel at or after 
r320844 fails :-(


imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Warner Losh]

On Sat, Jul 15, 2017 at 1:32 PM, Michael Butler 
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  0x000804232f6a in thr_kill () from /lib/libc.so.7
> #1  0x000804232f34 in raise () from /lib/libc.so.7
> #2  0x000804232ea9 in abort () from /lib/libc.so.7
> #3  0x0008188597af in ?? () from /usr/local/lib/libdbus-1.so.3
> #4  0x00081884ef2c in _dbus_warn_check_failed () from
> /usr/local/lib/libdbus-1.so.3
> #5  0x00081883f539 in dbus_message_new_method_call () from
> /usr/local/lib/libdbus-1.so.3
> #6  0x000801bddfe8 in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
> #7  0x000801bd591e in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
> #8  0x000801bd9af6 in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
> #9  0x000801be656d in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
> #10 0x000801be6807 in QDBusInterface::QDBusInterface(QString const&,
> QString const&, QString const&, QDBusConnection const&, QObject*) ()
>from /usr/local/lib/qt4/libQtDBus.so.4
> #11 0x00080d12728e in ?? () from /usr/local/lib/libsolid.so.4
> #12 0x00080d11e68c in ?? () from /usr/local/lib/libsolid.so.4
> #13 0x00080d12a525 in ?? () from /usr/local/lib/libsolid.so.4
> #14 0x00080d0e7aac in 
> Solid::Device::listFromType(Solid::DeviceInterface::Type
> const&, QString const&) () from /usr/local/lib/libsolid.so.4
> #15 0x00080e7e889a in ?? () from /usr/local/lib/libplasma.so.3
> #16 0x00080e7e6094 in Plasma::RunnerManager::RunnerManager(QObject*)
> () from /usr/local/lib/libplasma.so.3
> #17 0x0008172fab42 in ?? () from /usr/local/lib/libkdeinit4_krunner.so
> #18 0x0008172fa9b4 in ?? () from /usr/local/lib/libkdeinit4_krunner.so
>
> #19 0x0008172fd303 in kdemain () from 
> /usr/local/lib/libkdeinit4_krunner.so
>
> #20 0x0040a015 in ?? ()
>
> #21 0x0040aec0 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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Michael Butler]

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'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  0x000804232f6a in thr_kill () from /lib/libc.so.7
#1  0x000804232f34 in raise () from /lib/libc.so.7
#2  0x000804232ea9 in abort () from /lib/libc.so.7
#3  0x0008188597af in ?? () from /usr/local/lib/libdbus-1.so.3
#4  0x00081884ef2c in _dbus_warn_check_failed () from 
/usr/local/lib/libdbus-1.so.3
#5  0x00081883f539 in dbus_message_new_method_call () from 
/usr/local/lib/libdbus-1.so.3

#6  0x000801bddfe8 in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
#7  0x000801bd591e in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
#8  0x000801bd9af6 in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
#9  0x000801be656d in ?? () from /usr/local/lib/qt4/libQtDBus.so.4
#10 0x000801be6807 in QDBusInterface::QDBusInterface(QString const&, 
QString const&, QString const&, QDBusConnection const&, QObject*) ()

   from /usr/local/lib/qt4/libQtDBus.so.4
#11 0x00080d12728e in ?? () from /usr/local/lib/libsolid.so.4
#12 0x00080d11e68c in ?? () from /usr/local/lib/libsolid.so.4
#13 0x00080d12a525 in ?? () from /usr/local/lib/libsolid.so.4
#14 0x00080d0e7aac in 
Solid::Device::listFromType(Solid::DeviceInterface::Type const&, QString 
const&) () from /usr/local/lib/libsolid.so.4

#15 0x00080e7e889a in ?? () from /usr/local/lib/libplasma.so.3
#16 0x00080e7e6094 in Plasma::RunnerManager::RunnerManager(QObject*) 
() from /usr/local/lib/libplasma.so.3

#17 0x0008172fab42 in ?? () from /usr/local/lib/libkdeinit4_krunner.so
#18 0x0008172fa9b4 in ?? () from 
/usr/local/lib/libkdeinit4_krunner.so 

#19 0x0008172fd303 in kdemain () from 
/usr/local/lib/libkdeinit4_krunner.so 

#20 0x0040a015 in ?? () 



#21 0x0040aec0 in ?? () 




SVN r320843 works, r320844 doesn't :-(

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Bryan Drewery]

On 7/11/17 10:13 AM, Bryan Drewery wrote:
> On 7/11/17 10:09 AM, Warner Losh wrote:
>> Plus we know we have at least one bug in meta-mode rebuilding since not
>> everything is being rebuilt that should be across this change.
> 
> Yes I'm looking into that.
> 

This was a bug with buildkernel with META_MODE using filemon (the
default with META_MODE).  It is fixed in r320919.  I recommend doing
another buildkernel after that and installing to ensure everything gets
updated.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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

[Michael Butler]

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,


imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Michael Butler]

On 7/11/17 1:09 PM, Warner Losh wrote:

On a machine with SDHCI, a clean rebuild (after "r -rf /usr/obj") refuses
to find /dev/ada0 :-(



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.

Plus we know we have at least one bug in meta-mode rebuilding since not
everything is being rebuilt that should be across this change.

The change itself didn't change CAM except for copying one set of data it
didn't used to, into a structure whose size grew (which is why we're seeing
crashes / failures for a 'cross-threaded' rebuild). There's nothing else
that changed (especially after I removed the bogus debug printfs) that I
can see in auditing the change.

I was really hoping David's machine would exhibit the behavior since we're
co-workers and have a shared infrastructure for debugging we can leverage.


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 :-(


imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Bryan Drewery]

On 7/11/17 10:09 AM, Warner Losh wrote:
> Plus we know we have at least one bug in meta-mode rebuilding since not
> everything is being rebuilt that should be across this change.

Yes I'm looking into that.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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

[Warner Losh]

On Tue, Jul 11, 2017 at 10:47 AM, Michael Butler  wrote:

> On 7/11/17 10:32 AM, Warner Losh wrote:
>
>> On Tue, Jul 11, 2017 at 6:13 AM, David Wolfskill 
>> wrote:
>>
>>> I believe that each of the machines has an MMC slot, but I also believe
>>> that in each case, it is empty.
>>>
>>> Is there anything else I might be able to do to help resolve this?
>>>
>>>
>> Try building a kernel without sdhci in it.
>>
>> It's looking like the scans for ata devices are returning errors on the
>> desktop machine you have, which shouldn't have been happening.
>>
>> Also, can you try a 100% clean build of GENERIC to make sure there's not a
>> meta-mode bug?
>>
>
> On a machine with SDHCI, a clean rebuild (after "r -rf /usr/obj") refuses
> to find /dev/ada0 :-(
>

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.

Plus we know we have at least one bug in meta-mode rebuilding since not
everything is being rebuilt that should be across this change.

The change itself didn't change CAM except for copying one set of data it
didn't used to, into a structure whose size grew (which is why we're seeing
crashes / failures for a 'cross-threaded' rebuild). There's nothing else
that changed (especially after I removed the bogus debug printfs) that I
can see in auditing the change.

I was really hoping David's machine would exhibit the behavior since we're
co-workers and have a shared infrastructure for debugging we can leverage.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Michael Butler]

On 7/11/17 10:32 AM, Warner Losh wrote:

On Tue, Jul 11, 2017 at 6:13 AM, David Wolfskill 
wrote:

I believe that each of the machines has an MMC slot, but I also believe
that in each case, it is empty.

Is there anything else I might be able to do to help resolve this?



Try building a kernel without sdhci in it.

It's looking like the scans for ata devices are returning errors on the
desktop machine you have, which shouldn't have been happening.

Also, can you try a 100% clean build of GENERIC to make sure there's not a
meta-mode bug?


On a machine with SDHCI, a clean rebuild (after "r -rf /usr/obj") 
refuses to find /dev/ada0 :-(


imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[David Wolfskill]

On Tue, Jul 11, 2017 at 08:32:26AM -0600, Warner Losh wrote:
> ...
> > While O. Hartmann had written to indicate the he had identified r320844
> > as the culprit, and I had other reason to suspect it, I was a bit busy
> > at work yesterday, and unable to determine this for myself empirically.
> >
> > I went ahead and updated my "head" sources to r320884 (without
> > attempting to revert r320844), while running head @r320827.
> >
> > On reboot, I (again) had a panic on the laptop that looked similar
> > to the one from yesterday (r320869).
> >
> > On the build machine, however, I encountered the "mountroot" issue that
> > O. Hartmann had described.
> ...
> > Is there anything else I might be able to do to help resolve this?
> >
> 
> Try building a kernel without sdhci in it.
> 
> It's looking like the scans for ata devices are returning errors on the
> desktop machine you have, which shouldn't have been happening.
> 
> Also, can you try a 100% clean build of GENERIC to make sure there's not a
> meta-mode bug?
> 
> Warner

In thinking about the order of operations, it occurred to me that
trying the last option first would make sense, so I did that (cleared
/usr/obj/usr/src/sys/GENERIC, then re-built and -installed the
kernel).

And the build machine came up in multi-user mode:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #404  
r320884M/320891:1200038: Tue Jul 11 09:12:03 PDT 2017 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

I'll call that "success" and stop while I'm ahead. :-)

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
POTUS impeachment requires Congress buy-in.  First, fix Congress, THEN impeach.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

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

[Warner Losh]

On Tue, Jul 11, 2017 at 6:13 AM, David Wolfskill 
wrote:

> On Mon, Jul 10, 2017 at 04:51:09AM -0700, David Wolfskill wrote:
> > Pnic occurred prior to mounting file systems
>
> While O. Hartmann had written to indicate the he had identified r320844
> as the culprit, and I had other reason to suspect it, I was a bit busy
> at work yesterday, and unable to determine this for myself empirically.
>
> I went ahead and updated my "head" sources to r320884 (without
> attempting to revert r320844), while running head @r320827.
>
> On reboot, I (again) had a panic on the laptop that looked similar
> to the one from yesterday (r320869).
>
> On the build machine, however, I encountered the "mountroot" issue that
> O. Hartmann had described.
>
> I have again created screenshots; they may be found in
> .  For the
> laptop, the last of them shows the backtrace; the one previous shows
> the panic message.  For the build machine ("freebeast"), the last
> shows that when I asked for a list of "valid disk boot devices,"
> what was presented was an empty list.  (I found a working keyboard for
> it.)
>
> The most recent verbnose dmesg.boot from a successful boot of the
> laptop (running head) may still be found at
> .
> For the build machine, it is
> .
>
> I believe that each of the machines has an MMC slot, but I also believe
> that in each case, it is empty.
>
> Is there anything else I might be able to do to help resolve this?
>

Try building a kernel without sdhci in it.

It's looking like the scans for ata devices are returning errors on the
desktop machine you have, which shouldn't have been happening.

Also, can you try a 100% clean build of GENERIC to make sure there's not a
meta-mode bug?

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[David Wolfskill]

On Mon, Jul 10, 2017 at 04:51:09AM -0700, David Wolfskill wrote:
> Pnic occurred prior to mounting file systems

While O. Hartmann had written to indicate the he had identified r320844
as the culprit, and I had other reason to suspect it, I was a bit busy
at work yesterday, and unable to determine this for myself empirically.

I went ahead and updated my "head" sources to r320884 (without
attempting to revert r320844), while running head @r320827.

On reboot, I (again) had a panic on the laptop that looked similar
to the one from yesterday (r320869).

On the build machine, however, I encountered the "mountroot" issue that
O. Hartmann had described.

I have again created screenshots; they may be found in
.  For the
laptop, the last of them shows the backtrace; the one previous shows
the panic message.  For the build machine ("freebeast"), the last
shows that when I asked for a list of "valid disk boot devices,"
what was presented was an empty list.  (I found a working keyboard for
it.)

The most recent verbnose dmesg.boot from a successful boot of the
laptop (running head) may still be found at
.
For the build machine, it is
.

I believe that each of the machines has an MMC slot, but I also believe
that in each case, it is empty.

Is there anything else I might be able to do to help resolve this?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
POTUS impeachment requires Congress buy-in.  First, fix Congress, THEN impeach.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

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

[O. Hartmann]

Am Mon, 10 Jul 2017 04:51:09 -0700
David Wolfskill  schrieb:

> Pnic occurred prior to mounting file systems; I was able to boot
> from the r320827 (as "kernel.old") OK.  I was not able to get a
> dump.  Both the laptop and the build machine panicked, but the build
> machine's keyboard was unresponsive and its serial console isn't
> funtioning at the moment (because of unrelated issues involving the
> machine to which said console is connected).
> 
> The laptop doesn't have a serial console, but its keyboard was working.
> 
> I grabbed a few screenshots; for the build machine, there's just the
> one, but for the laptop, I managed to get a backtrace and 6 screenshots
> (including the backtrace).
> 
> Please see  for
> the screenshots:
> 
> Index of /~david/FreeBSD/head/r320869
> 
> Icon  NameLast modified  Size
> Description[PARENTDIR] Parent Directory -   
> [IMG] freebeast_1.jpg 2017-07-10 11:36  260K  
> [IMG] laptop_1.jpg2017-07-10 11:36  253K  
> [IMG] laptop_2.jpg2017-07-10 11:36  242K  
> [IMG] laptop_3.jpg2017-07-10 11:36  259K  
> [IMG] laptop_4.jpg2017-07-10 11:36  245K  
> [IMG] laptop_5.jpg2017-07-10 11:36  158K  
> [IMG] laptop_6.jpg2017-07-10 11:36  140K  
> 
> 
> Also, I have links to yesterday's verbose dmesg.boot files for each
> machine at .
> 
> I'm happy to experiment
> 
> Peace,
> david

Hello David.

I had the same with r320873. Either my box (a SSD/UFS2-off booting server 
running
CURRENT) ended up in a immediate panic and rebooted or it is stuck at 

[...]
mountroot: Waiting for device /dev/gpt/root ...
Mounting from ufs:/dev/gpt/root failed with error 19

mountroot >: ?

List of GEOM managed disk devices

mountroot >:
[...]

I went back to r320843 as I identified r320844 to be the culprit in my case.

I regret having not more information ...

Kind regards,

Oliver
-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpSjyUWrWreq.pgp
Description: OpenPGP digital signature

Panic on boot after upgrade from r320827 -> r320869

[David Wolfskill]

Pnic occurred prior to mounting file systems; I was able to boot
from the r320827 (as "kernel.old") OK.  I was not able to get a
dump.  Both the laptop and the build machine panicked, but the build
machine's keyboard was unresponsive and its serial console isn't
funtioning at the moment (because of unrelated issues involving the
machine to which said console is connected).

The laptop doesn't have a serial console, but its keyboard was working.

I grabbed a few screenshots; for the build machine, there's just the
one, but for the laptop, I managed to get a backtrace and 6 screenshots
(including the backtrace).

Please see  for
the screenshots:

Index of /~david/FreeBSD/head/r320869

Icon  NameLast modified  Size
Description[PARENTDIR] Parent Directory -   
[IMG] freebeast_1.jpg 2017-07-10 11:36  260K  
[IMG] laptop_1.jpg2017-07-10 11:36  253K  
[IMG] laptop_2.jpg2017-07-10 11:36  242K  
[IMG] laptop_3.jpg2017-07-10 11:36  259K  
[IMG] laptop_4.jpg2017-07-10 11:36  245K  
[IMG] laptop_5.jpg2017-07-10 11:36  158K  
[IMG] laptop_6.jpg2017-07-10 11:36  140K  


Also, I have links to yesterday's verbose dmesg.boot files for each
machine at .

I'm happy to experiment

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
POTUS impeachment requires Congress buy-in.  First, fix Congress, THEN impeach.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature