https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
Xin LI changed:
What|Removed |Added
Status|New |In Progress
Assignee|freebsd-bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #71 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kib
Date: Fri Mar 27 13:55:57 UTC 2015
New revision: 280760
URL: https://svnweb.freebsd.org/changeset/base/280760
Log:
Fix the hand after the immediat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #70 from elof...@hotmail.com ---
Glen, that sounds good.
Just an update from me too:
I counted the seconds once more today when I installed and upgraded a
10.1-machine, and I think that all my "20 seconds" above should actually
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #69 from Glen Barber ---
Just an update to note that this issue is not forgotten, and is being actively
(and heavily) investigated.
The underlying causes are not yet fully understood, and are quite complex by
nature.
--
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #68 from elof...@hotmail.com ---
Sorry. I was a bit fast with the copy-n-paste there.
Sections 2 and three should read:
"A normal upgrade, followed by"...
/Elof
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #67 from elof...@hotmail.com ---
Has anyone had any luck debugging this critical issue?
1)
A normal upgrade+reboot always freeze the machine permanently. :-(
2)
A normal upgrade+reboot, followed by 'shutdown now', entering sing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
Julien Cigar changed:
What|Removed |Added
CC||jci...@ulb.ac.be
--- Comment #66 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #56 from Glen Barber ---
Created attachment 154206
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=154206&action=edit
DIAGNOSTIC panic (1/2)
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #54 from elof...@hotmail.com ---
Install a VirtualBox VM via 10.1-RELEASE CD.
Reboot after installer: OK
Boot the installed system.
Reboot after doing nothing at all but logging in: OK
Boot again.
Run 'freebsd-update fetch inst
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #65 from Glen Barber ---
(In reply to Glen Barber from comment #59)
> (In reply to Glen Barber from comment #55)
> > The test machine now has INVARIANTS, INVARIANT_SUPPORT, WITNESS,
> > DEBUG_LOCKS, DEBUG_VFS_LOCKS, DIAGNOSTIC,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #64 from Glen Barber ---
(In reply to Konstantin Belousov from comment #63)
> (In reply to Glen Barber from comment #62)
> You should add WITNESS_SKIPSPIN kernel option, it is known that console
> spinlocks are not in order.
>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #63 from Konstantin Belousov ---
(In reply to Glen Barber from comment #62)
You should add WITNESS_SKIPSPIN kernel option, it is known that console
spinlocks are not in order.
So for the attachment id=154224, is it possible to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #62 from Glen Barber ---
Created attachment 154224
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=154224&action=edit
debugging session after freebsd-update and reboot
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #61 from Glen Barber ---
I've finally gotten the machine into a state where I can access the debugger
after it hangs. script(1) output of the debugging session will be attached.
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #60 from Glen Barber ---
Created attachment 154211
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=154211&action=edit
ddb transcript of panic-on-boot with debugging options enabled
--
You are receiving this mail beca
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #59 from Glen Barber ---
(In reply to Glen Barber from comment #55)
> The test machine now has INVARIANTS, INVARIANT_SUPPORT, WITNESS,
> DEBUG_LOCKS, DEBUG_VFS_LOCKS, DIAGNOSTIC, and ALT_BREAK_TO_DEBUGGER.
> Unfortunately, it p
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #58 from Glen Barber ---
Created attachment 154208
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=154208&action=edit
lock order reversal after kern_reboot()
--
You are receiving this mail because:
You are the assign
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #57 from Glen Barber ---
Created attachment 154207
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=154207&action=edit
DIAGNOSTIC panic (2/2)
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #55 from Glen Barber ---
(In reply to Konstantin Belousov from comment #53)
> (In reply to Glen Barber from comment #52)
> It is physically impossible to hang on a line which is not loop.
>
Yes, understood.
> I suspect that i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
Konstantin Belousov changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #52 from Glen Barber ---
(In reply to Glen Barber from comment #51)
> After editing sys/kern/kern_shutdown.c to be a bit more verbose, it appears
> kern_reboot() is getting stuck on line 429:
>
> 421 if (nbusy)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #51 from Glen Barber ---
After editing sys/kern/kern_shutdown.c to be a bit more verbose, it appears
kern_reboot() is getting stuck on line 429:
421 if (nbusy) {
422 /*
423
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #50 from Glen Barber ---
(In reply to Andrew Smith from comment #10)
> It seems that this at last effects all Kernels since 10.1-RELEASE through p3.
>
> If you have one of these Kernels with Softupdates active on the root
> fil
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #49 from rkober...@gmail.com ---
(In reply to Guy Helmer from comment #47)
I suspect that this is a different, though possibly related issue. In all cases
reported, while all filesystems were unclean on reboot, fsck never found a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #48 from Glen Barber ---
While continuing to look into this, I think I may have found a workaround.
Can someone test running 'freebsd-update install' twice *without* the
intermediate reboot between the kernel and userland updat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
Guy Helmer changed:
What|Removed |Added
CC||ghel...@freebsd.org
--- Comment #47 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #46 from Glen Barber ---
(In reply to rkoberman from comment #45)
> I have succeeded in working around the issue by:
> # shutdown now
> # sync
> wait a minute
> # reboot
>
> Since I started doing this I have not had my system h
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
rkober...@gmail.com changed:
What|Removed |Added
CC||rkober...@gmail.com
--- Comme
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #44 from Glen Barber ---
Thanks.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #43 from dan...@blodan.se ---
[root@www-04-portlane ~]# uname -a
FreeBSD www-04-portlane.p203.se 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401:
Tue Nov 11 21:02:49 UTC 2014
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GEN
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #42 from s...@gmx.us ---
/usr/home/dutch $ service -e | grep ^/etc
/etc/rc.d/hostid
/etc/rc.d/hostid_save
/etc/rc.d/cleanvar
/etc/rc.d/ip6addrctl
/etc/rc.d/devd
/etc/rc.d/pflog
/etc/rc.d/pf
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #41 from ncrog...@gmail.com ---
(In reply to Glen Barber from comment #40)
# uname -v
FreeBSD 10.1-RELEASE-p6 #8 r279296M: Wed Feb 25 16:15:37 EST 2015
root@fbsd_101_amd64_builder.rgnets.com:/usr/obj/usr/src/sys/RGNETS
# serv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #40 from Glen Barber ---
Can a few people please paste output from 'service -e | grep ^/etc' and 'sysctl
kern.shutdown' ?
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #39 from ncrog...@gmail.com ---
(In reply to Walter Hop from comment #38)
I concur. The problem is with unmounting the root filesystem, and not so much
the reboot itself. In my tests simply executing a "mount -r /" (which should
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #38 from Walter Hop ---
Please note that in my tests it's not the actual reboot that's the problem,
rather unmounting the root FS. Replacing /sbin/init binary on UFS+S and doing a
"mount -o ro /" afterwards also hangs the system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #37 from Glen Barber ---
(In reply to stoa from comment #36)
> I'm using "shutdown -r now" to reboot and "shutdown -p now" to shutdown.
Thank you.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #36 from s...@gmx.us ---
I'm using "shutdown -r now" to reboot and "shutdown -p now" to shutdown.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #35 from Glen Barber ---
(In reply to ncrogers from comment #34)
> In my cases shutdown(8) ("shutdown -r now") and reboot(8) exhibit the same
> behavior.
Ok, thank you.
--
You are receiving this mail because:
You are the assi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #34 from ncrog...@gmail.com ---
In my cases shutdown(8) ("shutdown -r now") and reboot(8) exhibit the same
behavior.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #33 from Glen Barber ---
For clarification, when you say "reboot", do you mean reboot(8), or shutdown(8)
with the '-r' flag?
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #32 from s...@gmx.us ---
I can refine my comments above. Apparently, while I can shutdown cleanly at
all times, I cannot reboot at anytime without hanging. I am presently on
10.1-RELEASE-p6 on both a "generally Intel" desktop a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #31 from ncrog...@gmail.com ---
+1 for this breaking upgrading to 10.1-RELEASE-p6 from p5. Not being able to
update to the latest patch level without having to physically reboot a
production server when it hangs during reboot rea
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #30 from elof...@hotmail.com ---
Thanks Jamie.
It was a long shot, but worth testing.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #29 from jamie.ma...@gmail.com ---
I just tried the following suggestion in a new stock 10.1R VM with UFS fs -
same hang on "All buffers synced." when trying to reboot after update:
1. 'sysctl hw.usb.no_shutdown_wait=1'
and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #28 from elof...@hotmail.com ---
That's what I was thinking...
Perhaps the more connected USB-stuff (such as KVM-keyboard, etc), the more
prone to freezing the machine gets?
Anyone have an old snapshot of a non-upgraded vm t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #27 from m...@tnpi.net ---
Re: elof...@hotmail.com
I needed a KVM to be put on two servers exactly *because* of this issue. So
maybe that's part of it, but it's certainly not all of it.
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
elof...@hotmail.com changed:
What|Removed |Added
CC||elof...@hotmail.com
--- Comme
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
jamie.ma...@gmail.com changed:
What|Removed |Added
CC||jamie.ma...@gmail.com
--- C
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #24 from ncrog...@gmail.com ---
I am in the same situation of having to do remote unattended upgrades of a few
hundred boxes... For a while now I've been using a custom rc.d script to run
tunefs before the filesystems are mounted
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #23 from Andrew Smith ---
It's a bit of an issue for me since I need to plan a series of unattended
upgrades. Thankfully those systems are on an unaffected 10.0 Kernel level but I
don;t have the option of disabling softupdates b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #22 from ncrog...@gmail.com ---
Disabling soft-updates journaling on just the root partition before the upgrade
alleviates the hanging issue for me as well. However, the filesystem still ends
up being dirty with an incorrect bloc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #21 from ncrog...@gmail.com ---
FWIW I've been having this problem as well, so far under VMWare Fusion and
ESXi. Happens when upgrading from 9.1-STABLE to 10.1-RELEASE during the last
reboot of the upgrade process (i.e., after th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
rmthomas1...@gmail.com changed:
What|Removed |Added
CC||rmthomas1...@gmail.com
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #19 from m...@tnpi.net ---
This seems related. On a server I upgraded to 10.1-RELEASE (via buildworld),
and then updated to the latest patch level, I get this in dmesg after boot:
Trying to mount root from ufs:/dev/mirror/root [
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
m...@tnpi.net changed:
What|Removed |Added
CC||m...@tnpi.net
--- Comment #18 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
Charley Sheets changed:
What|Removed |Added
CC||cshe...@nvidia.com
--- Comment #1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
Matt Kollross changed:
What|Removed |Added
CC||kollr...@illinois.edu
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #15 from Andrew Smith ---
To confirm, p4 seemed to appear as available today and the problem persists.
--
You are receiving this mail because:
You are the assignee for the bug.
___
f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #14 from s...@gmx.us ---
I was (concurrently) having many problems with the transition to
xorg-server-1.14. Long story short, I disabled hald (8) and have not had any
hangs since. I will note I have no real evidence of any conne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #13 from Andrew Smith ---
Have rebuilt the 10.1 Kernel using CLANG 3.3 on a FreeBSD 10.0 system and on a
10.1-RELEASE-p3 system from the current 10.1-RELEASE-p3 source tree delivered
via freebsd-update.
The problem is apparent
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #12 from Walter Hop ---
I have spent some hours bisecting -STABLE between 10.0 and 10.1, but I couldn't
pinpoint the revision, as the bug seems to depend on the clang build! So, the
bisecting procedure should probably involve bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #11 from Andrew Smith ---
Additionally it appears that if you leave soft updates on but disable soft
update journal (tunefs -j disable) the problem disappears so the problem may be
more focussed than generally soft updates.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
Andrew Smith changed:
What|Removed |Added
CC||iamasmith.h...@gmail.com
--- Commen
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
dan...@blodan.se changed:
What|Removed |Added
CC||dan...@blodan.se
--- Comment #9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
Davide Davini changed:
What|Removed |Added
CC||diotona...@gmail.com
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #7 from s...@gmx.us ---
I have the same problem, however, I noticed the issue after installing patch-1
to a 10.1-RELEASE box that had been previously (weeks before) upgraded from
10.0-RELEASE. I'm using UFS, not ZFS. More confo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #6 from Walter Hop ---
According to Jilles Tjoelker the LOR are false positives so please disregard
them.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #5 from quick...@abv.bg ---
I also experienced it. I freebsd-update upgraded two physical 10.0-RELEASE-p13
installs to 10.1-RELEASE-p1.
For the first, I didn't disable soft updates and it froze at "All buffers
synced." during th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #4 from Walter Hop ---
Sorry, I lied! r273635 was not the latest snapshot available, my apologies. I
retried with a snapshot from 7 Dec (r275582).
In r275582, the LOR when fiddling with /sbin/init is the same as in 10.1, but
th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #3 from Walter Hop ---
I’ve tried if the hang is apparent in a 11-CURRENT snapshot too, and it is.
(Tried the iso snapshot available today, which is r273635). WITNESS indicates a
lock order reversal, which looks related to me:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
Juan Ramón Molina Menor changed:
What|Removed |Added
CC||i...@juanmolina.eu
--- C
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #1 from Walter Hop ---
I noticed today that the same problem happens when upgrading from 10.1-RC3 to
10.1-RELEASE, and also on a clean install of 10.1-RELEASE.
I did some more digging. As a refresher, the hang didn't occur just
72 matches
Mail list logo
