Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"

On 10/02/2012 11:15 PM, John Baldwin wrote: > You could try adding a different WITNESS check (using WITNESS_WARN) to see > which NFS proc returns with a lock held so you can catch this when it first > occurs rather than much later after the fact. Do you have the start of the > log messages? Yep

Re: ahcich reset -> cannot mount zfs root in 9.1-PRE

On 10/02/2012 17:40, Alexander Motin wrote: > On 02.10.2012 16:51, Andriy Gapon wrote: >> on 02/10/2012 16:16 geoffroy desvernay said the following: >>> Hi all, >>> >>> Trying to upgrade a system from 9.0-RELEASE to 9.1-PRE from yesterday on >>> my machine (GEOM+ZFS mirror setup on ada[01]p3), the

Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"

On 10/03/2012 09:21 AM, Norbert Aschendorff wrote: > So I just have to compile a kernel including "option WITNESS_WARN" and Well, obviously doesn't work, so only WITNESS_SKIPSPIN... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mai

[releng_8 tinderbox] failure on mips/mips

TB --- 2012-10-03 08:48:12 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-03 08:48:12 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-03 08

Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"

Another logs - even with a /var/crash crash report :) Please note: The /var/crash files stem from another crash than the big syslog does! The syslog file inside the tarball is about 4.7 MB; it contains everything since the start of the crash. New /var/crash files: http://lbo.spheniscida.de/Files

lang/gcc fails building on old processor

Hello. It seems that lang/gcc starts producing incorrect binaries after some point. Right now it stops building with: checking whether to build static libraries... yes libtool.m4: error: problem compiling FC test program checking for /tmp/ports/usr/ports/lang/gcc/work/build/./gcc/gfortran -B/

[releng_8 tinderbox] failure on mips/mips

TB --- 2012-10-03 12:43:16 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-03 12:43:16 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-03 12

Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"

Norbert Aschendorff wrote: > Another logs - even with a /var/crash crash report :) > > Please note: The /var/crash files stem from another crash than the big > syslog does! > > The syslog file inside the tarball is about 4.7 MB; it contains > everything since the start of the crash. > > New /var

Re: laptop keeps crashing, any ideas....

On 27 September 2012 19:29, Jason Helfman wrote: > Turns out that there was some either corrupt file under /tmp that was X > related, or had wrong permissions. I had to clear out tmp manually, then run > startx to get into X windows. At this point, I remove the bit from > /etc/rc.conf that I had p

Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"

On Wed, Oct 03, 2012 at 09:24:11AM -0400, Rick Macklem wrote: > Norbert Aschendorff wrote: > > Another logs - even with a /var/crash crash report :) > > > > Please note: The /var/crash files stem from another crash than the big > > syslog does! > > > > The syslog file inside the tarball is about

Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"

On 10/03/2012 05:54 PM, Konstantin Belousov wrote: > So do you use nullfs exported mounts ? And stable ? > Can you try to remove nullfs from the set up ? Yes, I am using nullfs for the exports (mounting the exported directories to subdirectories of /srv). In the FreeBSD man pages and the documenta

Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"

On Wed, Oct 03, 2012 at 07:26:47PM +0200, Norbert Aschendorff wrote: > On 10/03/2012 05:54 PM, Konstantin Belousov wrote: > > So do you use nullfs exported mounts ? And stable ? > > Can you try to remove nullfs from the set up ? > > Yes, I am using nullfs for the exports (mounting the exported > d

Re: daily run output misses zpool errors

On Tue, 25 Sep 2012 14:56:49 +0200 "Ronald Klop" wrote: > Hi, > > Below my daily report. And here my zpool status -x. It would be nice > to see this error in my daily info. I am running with > daily_show_info="NO", but this looks more severe than info. Just to make sure: you verified that you h

Re: stable/9 panic Bad tailq NEXT(0xffffffff80e52660->tqh_last) != NULL

On Tuesday, October 02, 2012 7:12:59 pm Sean Bruno wrote: > On Tue, 2012-10-02 at 14:06 -0700, John Baldwin wrote: > > On Tuesday, October 02, 2012 3:05:30 pm Sean Bruno wrote: > > > On Mon, 2012-10-01 at 05:47 -0700, John Baldwin wrote: > > > > Can you add extra printfs to see where exactly attach

[releng_8 tinderbox] failure on mips/mips

TB --- 2012-10-03 20:42:28 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-03 20:42:28 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-03 20

Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"

Konstantin Belousov wrote: > On Wed, Oct 03, 2012 at 07:26:47PM +0200, Norbert Aschendorff wrote: > > On 10/03/2012 05:54 PM, Konstantin Belousov wrote: > > > So do you use nullfs exported mounts ? And stable ? > > > Can you try to remove nullfs from the set up ? > > > > Yes, I am using nullfs for

Re: CAM Target Layer and Linux (continued)

On Tue, Oct 2, 2012 at 3:03 AM, Nikolay Denev wrote: > > On Sep 27, 2012, at 6:33 PM, Nikolay Denev wrote: > >> Hi All, >> >> With the help of Chuck Tuffli, I'm now able to use CTL to export a zvol over >> FC to a Linux host: >> >> LUN Backend Size (Blocks) BS Serial NumberDevice ID

[releng_8 tinderbox] failure on mips/mips

TB --- 2012-10-04 00:32:23 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-04 00:32:23 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-04 00

Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"

On 10/03/2012 07:39 PM, Konstantin Belousov wrote: > Can you try HEAD kernel ? Theoretically, yes. But it's a network machine, so... if something goes wrong, it'd be rather bad :| And I'm afraid of HEAD ;) I'll try it nevertheless... Fortunately, I even have Screen&Keyboard at the machine (if som

Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"

I exported the NFSv4 shares via nullfs, booted the 10.0-CURRENT kernel and the machine does not crash. Running 9.1-PRERELEASE, it still crashes (as it should ;). I just applied the numeric-uidgid patch to CURRENT (worked so far) and compile the kernel with the patch and try it another time, just t

[releng_8 tinderbox] failure on mips/mips

TB --- 2012-10-04 04:28:32 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-04 04:28:32 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-04 04