Re: problem upgrading from 11.3 to 11.4 (loader init_state not found)
On Thu, 15 Oct 2020 16:10:17 +0200 Patrick Lamaiziere wrote: > Hello, > > We upgraded a virtual machine from 11.3-release-pX to 11.4-release via > freebsd-update. > > Since, the vm does not boot, the loader shows an incomplete menu with > an error : "Options: init_state(heart character) not found" > > I put a photo here : > https://filesender.renater.fr/?s=download=e17aa22f-bd1a-48a6-98d2-1aafdb4278ca > > Then if we type "boot" the machine boots properly. > > The menu looks like : > ---Welcome to FreeBSD > 1 <-[-11;6H. <-[-1107;8HYES > > Options: init_state not found > Error while including /boot/menu.rc on the line: menu-display > > Can't load 'kernel' > Type '?' for a list of commands, 'help' for more detailled help > --- > > /boot/loader.conf: > # divers > loader_logo=beastie > loader_color="YES" > > # modules > tcpmd5_load="YES" Well it boots fine if I comment loader_logo and loader_color. But I would love the return of Beastie :-) Regards, ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
problem upgrading from 11.3 to 11.4 (loader init_state not found)
Hello, We upgraded a virtual machine from 11.3-release-pX to 11.4-release via freebsd-update. Since, the vm does not boot, the loader shows an incomplete menu with an error : "Options: init_state(heart character) not found" I put a photo here : https://filesender.renater.fr/?s=download=e17aa22f-bd1a-48a6-98d2-1aafdb4278ca Then if we type "boot" the machine boots properly. The menu looks like : ---Welcome to FreeBSD 1 <-[-11;6H. <-[-1107;8HYES Options: init_state not found Error while including /boot/menu.rc on the line: menu-display Can't load 'kernel' Type '?' for a list of commands, 'help' for more detailled help --- /boot/loader.conf: # divers loader_logo=beastie loader_color="YES" # modules tcpmd5_load="YES" I read in /usr/src/UPDATING that there were some changes on the loader but /boot/loader is the same file as /boot/loader.4th so that looks good. Any clue ? Thanks regards. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PF problems with 11-stable
Le Thu, 26 Jul 2018 09:58:05 +0200, Patrick Lamaiziere a écrit : Hello, > > Hey, > > I am on > > 11.2-STABLE FreeBSD 11.2-STABLE #9 r336597 > > Sun Jul 22 14:08:38 CEST 2018 > > > > and I see 2 problems with PF that are still there: > > 1.) set skip on lo > > does not work even though ifconfig lo matches. > > SOLVED TEMPORARILY BY: set skip on lo0 > > I've seen this while upgrading from 10.3 to 11.2-RELEASE. I've added > lo0 to set skip too. > > When the problem occurs, lo is marked '(skip)' (pfctl -vs > Interfaces) but not lo0. > > But I can't reproduce this, this happened only one time. I don't know if this is related but there were some kernel logs about 'loopback' : Feb 15 17:11:48 fucop1 kernel: ifa_del_loopback_route: deletion failed: 47 Feb 15 17:11:48 fucop1 kernel: ifa_add_loopback_route: insertion failed: 47 Jul 16 13:50:36 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface ix2: 3 Jul 16 14:07:31 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface ix2: 3 Jul 16 14:07:31 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface igb1: 3 Jul 16 14:10:43 fucop1 kernel: ifa_maintain_loopback_route: insertion failed for interface igb0: 17 I've got two firewalls with carp and bird 2 (BGP). ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PF problems with 11-stable
Le Thu, 26 Jul 2018 09:58:05 +0200, Patrick Lamaiziere a écrit : Hello, > > Hey, > > I am on > > 11.2-STABLE FreeBSD 11.2-STABLE #9 r336597 > > Sun Jul 22 14:08:38 CEST 2018 > > > > and I see 2 problems with PF that are still there: > > 1.) set skip on lo > > does not work even though ifconfig lo matches. > > SOLVED TEMPORARILY BY: set skip on lo0 > > I've seen this while upgrading from 10.3 to 11.2-RELEASE. I've added > lo0 to set skip too. > > When the problem occurs, lo is marked '(skip)' (pfctl -vs > Interfaces) but not lo0. > > But I can't reproduce this, this happened only one time. I don't know if this is related but there were some kernel logs about 'loopback' : Feb 15 17:11:48 fucop1 kernel: ifa_del_loopback_route: deletion failed: 47 Feb 15 17:11:48 fucop1 kernel: ifa_add_loopback_route: insertion failed: 47 Jul 16 13:50:36 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface ix2: 3 Jul 16 14:07:31 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface ix2: 3 Jul 16 14:07:31 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface igb1: 3 Jul 16 14:10:43 fucop1 kernel: ifa_maintain_loopback_route: insertion failed for interface igb0: 17 I've got two firewalls with carp and bird 2 (BGP). ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PF problems with 11-stable
Le Sun, 22 Jul 2018 15:53:41 +0200, Lars Schotte a écrit : Hello, > Hey, > I am on > 11.2-STABLE FreeBSD 11.2-STABLE #9 r336597 > Sun Jul 22 14:08:38 CEST 2018 > > and I see 2 problems with PF that are still there: > 1.) set skip on lo > does not work even though ifconfig lo matches. > SOLVED TEMPORARILY BY: set skip on lo0 I've seen this while upgrading from 10.3 to 11.2-RELEASE. I've added lo0 to set skip too. When the problem occurs, lo is marked '(skip)' (pfctl -vs Interfaces) but not lo0. But I can't reproduce this, this happened only one time. While I'm here, another small change is that pfctl -n does not work any more without root credentials, I'm not sure if this is a bug or a feature : % pfctl -n -f /etc/pf.conf pfctl: pfi_get_ifaces: Bad file descriptor % ls -lah /etc/pf.conf -rw-r--r-- 1 root wheel97B Jul 26 09:37 /etc/pf.conf Regards, ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 10.3-RELEASE amd64 segmentation faults in wc, sh...
Le Thu, 30 Jun 2016 15:52:04 +0300, Konstantin Belousov <kostik...@gmail.com> a écrit : Hello, > On Thu, Jun 30, 2016 at 01:57:32PM +0200, Patrick Lamaiziere wrote: > > Hello, > > > > I'm building a pair of firewall with 10.3 and I see some rare > > segmentation faults (5 in a week) in processes like wc, sh or > > ifstated. ... > This is most likely the problems, reported and fixed in r300758, > PR 204764 r302063, and PR 204426 r302236. First and second commits > are already in stable/10, the third one will be merged in several > days. For the record, it looks like the first and second commits fixed this problem here. I've not yet tested the third one (don't know if it is already in 10/stable). Thanks again Konstantin. Regards, ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
10.3-RELEASE amd64 segmentation faults in wc, sh...
Hello, I'm building a pair of firewall with 10.3 and I see some rare segmentation faults (5 in a week) in processes like wc, sh or ifstated. wc, sh are used by some scripts who check the state of the interfaces and the state of bgp sessions. Ifstated called theses scripts too. I thought there was a bug in ifstated so I made a small program in perl to do the same thing but the problem is not in ifstated. The machines are some Dell R730, I've checked the memory with memtest86 for one week without error. The problem occurs on both firewalls so i don't think this is a hardware problem. Any idea? Thanks, regards. ifstated Core was generated by `ifstated'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libevent-2.0.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libevent-2.0.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800e23a67 in pthread_getspecific () from /lib/libthr.so.3 Cannot find new threads: generic error sh -- Core was generated by `sh'. Program terminated with signal 11, Segmentation fault. Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00080063351b in _rtld_atfork_post () from /libexec/ld-elf.so.1 wc -- Core was generated by `wc'. Program terminated with signal 11, Segmentation fault. Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800612524 in _rtld_atfork_post () from /libexec/ld-elf.so.1 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.2-RELEASE stability?
Le Mon, 30 Sep 2013 13:01:26 -0600, Brett Glass br...@lariat.net a écrit : Hello, How stable are folks finding FreeBSD 9.2-RELEASE to be? The improvements are welcome, but there have been a few troubling messages about kernel panics and VM issues on the various mailing lists. It's never clear until the release drops whether these are actual problems with the software or hardware defects in individual systems, so I am eager to hear how the new release is working for everyone. I've seen two problems if you use poudriere (on ZFS only?) which occur in some loads (ie desktop running gvfsd). One fix is in 9-STABLE and the other one should be mfced soon. May be there will be an errata for 9.2-RELEASE for this ? I think that would be nice because 9.2 is stable as a Windows 3.11 with my load :-) Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible kqueue related issue on STABLE/RC.
Le Wed, 25 Sep 2013 11:06:33 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: I'd like to understand why you think protecting these functions w/ the _DETACHED check is correct... In kern_event.c, all calls to f_detach are followed by knote_drop which will ensure that the knote is removed and free, so no more f_event calls will be called on that knote.. My current belief is that what happens is a glitch in the kqueue_register(). After a new knote is created and attached, the kq lock is dropped and then f_event() is called. If the vnode is reclaimed or possible freed meantime, f_event() seems to dereference freed memory, since kn_hook points to freed vnode. The issue as I see it is that vnode lifecycle is detached from the knote lifecycle. Might be, only the second patch, which acquires a hold reference on the vnode for each knote, is really needed. But before going into any conclusions, I want to see the testing results. Testing looks good with your latest patch. I was able to run a complete poudriere bulk (870 packages). I'm running another bulk to see.. I've made another bulk without problem (with complete patch) If you have other patches to test just ask, I have not updated my packages because there was a change to make gvfsd to ignore some poudriere activity. So I guess it will be harder to see this problem. Could you, please, test with the only patch http://people.freebsd.org/~kib/misc/vnode_filter.1.patch applied ? I wonder would it be enough. Looks good with this single patch too, one poudriere bulk is completed and I'm doing another just in case (but I think it would have already paniced, that's quite reproductible). Thanks, regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible kqueue related issue on STABLE/RC.
Le Wed, 25 Sep 2013 00:21:27 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: I'd like to understand why you think protecting these functions w/ the _DETACHED check is correct... In kern_event.c, all calls to f_detach are followed by knote_drop which will ensure that the knote is removed and free, so no more f_event calls will be called on that knote.. My current belief is that what happens is a glitch in the kqueue_register(). After a new knote is created and attached, the kq lock is dropped and then f_event() is called. If the vnode is reclaimed or possible freed meantime, f_event() seems to dereference freed memory, since kn_hook points to freed vnode. The issue as I see it is that vnode lifecycle is detached from the knote lifecycle. Might be, only the second patch, which acquires a hold reference on the vnode for each knote, is really needed. But before going into any conclusions, I want to see the testing results. Testing looks good with your latest patch. I was able to run a complete poudriere bulk (870 packages). I'm running another bulk to see. If you have other patches to test just ask, I have not updated my packages because there was a change to make gvfsd to ignore some poudriere activity. So I guess it will be harder to see this problem. Many thanks Konstantin, Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible kqueue related issue on STABLE/RC.
Le Mon, 23 Sep 2013 23:31:41 +0300,
Konstantin Belousov kostik...@gmail.com a écrit :
Hello,
...
Ok This has been mfced to 9.2-STABLE. But I still see this panic
with 9-2/STABLE of today (Revision : 255811). This may be better
because before the box paniced within minutes and now within hours
(still using poudriere).
panic:
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x808ebfcd
stack pointer = 0x28:0xff824c2e0630
frame pointer = 0x28:0xff824c2e06a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 54243 (gvfsd-trash)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x80939ad6 at kdb_backtrace+0x66
#1 0x808ffacd at panic+0x1cd
#2 0x80cdfbe9 at trap_fatal+0x289
#3 0x80cdff4f at trap_pfault+0x20f
#4 0x80ce0504 at trap+0x344
#5 0x80cc9b43 at calltrap+0x8
#6 0x8099d043 at filt_vfsvnode+0xf3
#7 0x808c4793 at kqueue_register+0x3e3
#8 0x808c4de8 at kern_kevent+0x108
#9 0x808c5950 at sys_kevent+0x90
#10 0x80cdf3a8 at amd64_syscall+0x5d8
#11 0x80cc9e27 at Xfast_syscall+0xf7
Full core.txt :
http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0
For start, please load the core into kgdb and for
frame 8
p *kn
(kgdb) frame 8
#8 0x8099d043 in filt_vfsvnode (kn=0xfe0147a7f000, hint=0)
at /usr/src/sys/kern/vfs_subr.c:4600
4600VI_LOCK(vp);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0},
kn_kq = 0xfe01079a6200, kn_kevent = {ident = 62, filter = -4,
flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status = 24,
kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp = 0xfe016949e190,
p_proc = 0xfe016949e190, p_aio = 0xfe016949e190,
p_lio = 0xfe016949e190}, kn_fop = 0x812fd440,
kn_hook = 0xfe0119d0b1f8, kn_hookid = 0}
Also, please follow
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
to recompile kernel with the debugging options and try to recreate
the panic.
It's building.
Thanks, regards
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible kqueue related issue on STABLE/RC.
Le Tue, 24 Sep 2013 11:29:09 +0300,
Konstantin Belousov kostik...@gmail.com a écrit :
Hello,
...
Ok This has been mfced to 9.2-STABLE. But I still see this panic
with 9-2/STABLE of today (Revision : 255811). This may be better
because before the box paniced within minutes and now within
hours (still using poudriere).
panic:
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x808ebfcd
stack pointer = 0x28:0xff824c2e0630
frame pointer = 0x28:0xff824c2e06a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 54243 (gvfsd-trash)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x80939ad6 at kdb_backtrace+0x66
#1 0x808ffacd at panic+0x1cd
#2 0x80cdfbe9 at trap_fatal+0x289
#3 0x80cdff4f at trap_pfault+0x20f
#4 0x80ce0504 at trap+0x344
#5 0x80cc9b43 at calltrap+0x8
#6 0x8099d043 at filt_vfsvnode+0xf3
#7 0x808c4793 at kqueue_register+0x3e3
#8 0x808c4de8 at kern_kevent+0x108
#9 0x808c5950 at sys_kevent+0x90
#10 0x80cdf3a8 at amd64_syscall+0x5d8
#11 0x80cc9e27 at Xfast_syscall+0xf7
Full core.txt :
http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0
For start, please load the core into kgdb and for
frame 8
p *kn
(kgdb) frame 8
#8 0x8099d043 in filt_vfsvnode (kn=0xfe0147a7f000,
hint=0) at /usr/src/sys/kern/vfs_subr.c:4600
4600VI_LOCK(vp);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0},
kn_kq = 0xfe01079a6200, kn_kevent = {ident = 62, filter = -4,
flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status =
24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp =
0xfe016949e190, p_proc = 0xfe016949e190, p_aio =
0xfe016949e190, p_lio = 0xfe016949e190}, kn_fop =
0x812f0, kn_hook = 0xfe0119d0b1f8, kn_hookid = 0}
From the kgdb, also please do
p *(struct vnode *)0xfe0119d0b1f8
With a kernel with debug info, this panic becomes mtx_lock() of
destroyed mutex
panic: mtx_lock() of destroyed mutex
http://user.lamaiziere.net/patrick/public/panic_mtx_lock.txt
@ /usr/src/sys/kern/vfs_subr.c:4600 cpuid = 2
KDB: stack backtrace:
#0 0x80920286 at kdb_backtrace+0x66
#1 0x808e738d at panic+0x1cd
#2 0x808d58d6 at _mtx_lock_flags+0x116
#3 0x8098143b at filt_vfsvnode+0x3b
#4 0x808b213a at kqueue_register+0x4ca
#5 0x808b2688 at kern_kevent+0x108
#6 0x808b3190 at sys_kevent+0x90
#7 0x80cbd975 at amd64_syscall+0x2f5
#8 0x80ca8557 at Xfast_syscall+0xf7
(kgdb) frame 5
#5 0x808b213a in kqueue_register (kq=0xfe00ddc98900,
kev=0xff824bb5f880, td=0xfe00b1e7f000, waitok=1) at
/usr/src/sys/kern/kern_event.c:1136
1136event = kn-kn_fop-f_event(kn, 0);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0xfe011c232b00},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0}, kn_kq =
0xfe00ddc98900,
kn_kevent = {ident = 62, filter = -4, flags = 32784, fflags = 0, data = 0,
udata = 0x0}, kn_status = 24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {
p_fp = 0xfe00ddd4d870, p_proc = 0xfe00ddd4d870, p_aio =
0xfe00ddd4d870, p_lio = 0xfe00ddd4d870}, kn_fop = 0x812fcca0,
kn_hook = 0xfe02064a6000, kn_hookid = 0}
(kgdb) p *(struct vnode *)0xfe02064a6000
$2 = {v_type = VBAD, v_tag = 0x80d89084 none, v_op = 0x0, v_data =
0x0, v_mount = 0x0, v_nmntvnodes = {tqe_next = 0xfe020d3e6000,
tqe_prev = 0xfe0086625a68}, v_un = {vu_mount = 0x0, vu_socket = 0x0,
vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0,
le_prev = 0xff8000de9698}, v_hash = 238022, v_cache_src = {lh_first =
0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfe02064a6060},
v_cache_dd = 0x0,
v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object =
{lo_name = 0x80f56e48 ufs, lo_flags = 91881472, lo_data = 0,
lo_witness = 0xff80006c3400}, lk_lock = 1, lk_exslpfail = 0, lk_timo
= 51, lk_pri = 96, lk_stack = {depth = 12, pcs = {18446744071571296822,
18446744071573768556, 18446744071576111075, 18446744071606114523,
18446744071576111075, 18446744071572113927, 18446744071572067653,
18446744071606111219,
18446744071572016126, 18446744071572018094, 18446744071575427445,
18446744071575340375, 0, 0, 0, 0, 0, 0}}}, v_interlock = {lock_object = {
lo_name = 0x80f6f8a3 vnode interlock, lo_flags
Re: Possible kqueue related issue on STABLE/RC.
Le Fri, 20 Sep 2013 15:17:05 +0200, Patrick Lamaiziere patf...@davenulle.org a écrit : Le Thu, 12 Sep 2013 10:36:43 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, Might be, your issue is that some filesystems do not care about proper locking mode for the fifos. UFS carefully disables shared locking for VFIFO, but it seems ZFS is not. I can propose the following band-aid, which could help you. I have no idea is it the same issue as the kqueue panic. diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index c53030a..00bd998 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -267,6 +267,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred *cred, return (error); } } + if (vp-v_type == VFIFO VOP_ISLOCKED(vp) != LK_EXCLUSIVE) + vn_lock(vp, LK_UPGRADE | LK_RETRY); if ((error = VOP_OPEN(vp, fmode, cred, td, fp)) != 0) return (error); @@ -358,7 +360,7 @@ vn_close(vp, flags, file_cred, td) struct mount *mp; int error, lock_flags; - if (!(flags FWRITE) vp-v_mount != NULL + if (vp-v_type != VFIFO !(flags FWRITE) vp-v_mount != NULL vp-v_mount-mnt_kern_flag MNTK_EXTENDED_SHARED) lock_flags = LK_SHARED; else Ok This has been mfced to 9.2-STABLE. But I still see this panic with 9-2/STABLE of today (Revision : 255811). This may be better because before the box paniced within minutes and now within hours (still using poudriere). panic: fault code = supervisor read data, page not present instruction pointer = 0x20:0x808ebfcd stack pointer = 0x28:0xff824c2e0630 frame pointer = 0x28:0xff824c2e06a0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 54243 (gvfsd-trash) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0x80939ad6 at kdb_backtrace+0x66 #1 0x808ffacd at panic+0x1cd #2 0x80cdfbe9 at trap_fatal+0x289 #3 0x80cdff4f at trap_pfault+0x20f #4 0x80ce0504 at trap+0x344 #5 0x80cc9b43 at calltrap+0x8 #6 0x8099d043 at filt_vfsvnode+0xf3 #7 0x808c4793 at kqueue_register+0x3e3 #8 0x808c4de8 at kern_kevent+0x108 #9 0x808c5950 at sys_kevent+0x90 #10 0x80cdf3a8 at amd64_syscall+0x5d8 #11 0x80cc9e27 at Xfast_syscall+0xf7 Full core.txt : http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0 Thanks, regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible kqueue related issue on STABLE/RC.
Le Thu, 12 Sep 2013 10:36:43 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, Might be, your issue is that some filesystems do not care about proper locking mode for the fifos. UFS carefully disables shared locking for VFIFO, but it seems ZFS is not. I can propose the following band-aid, which could help you. I have no idea is it the same issue as the kqueue panic. diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index c53030a..00bd998 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -267,6 +267,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred *cred, return (error); } } + if (vp-v_type == VFIFO VOP_ISLOCKED(vp) != LK_EXCLUSIVE) + vn_lock(vp, LK_UPGRADE | LK_RETRY); if ((error = VOP_OPEN(vp, fmode, cred, td, fp)) != 0) return (error); @@ -358,7 +360,7 @@ vn_close(vp, flags, file_cred, td) struct mount *mp; int error, lock_flags; - if (!(flags FWRITE) vp-v_mount != NULL + if (vp-v_type != VFIFO !(flags FWRITE) vp-v_mount != NULL vp-v_mount-mnt_kern_flag MNTK_EXTENDED_SHARED) lock_flags = LK_SHARED; else Hmmm, So what is the fix for 9.2-STABLE ? As far I can see there is no function vn_open_vnode() here and I don't see where I should patch. I see this panic too (with STABLE of today), while using poudriere + ZFS like Jimmy. Thanks, regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: java (openjdk6) segfaults when built with 9-stable clang
Le Fri, 26 Jul 2013 00:05:50 +0200, Baptiste Daroussin b...@freebsd.org a écrit : Hi all, Baptiste, Hi I recently upgraded my home NAS from 9.1-RELEASE to 9-stable (r253470 (9.2-BETA1)) I also upgraded my poudriere building jail. Since then, multimedia/xbmc port fails to build in configure stage : java segfaults (sig11). I use WITH_CLANG_IS_CC=YES, for world and build-jails. I found following workarounds: - use previously (with 9.1-RELEASE world and clang) build openjdk6 pkg (same version). - use USE_GCC=YES for java port. It's the only one place I use java (openjdk6-b27_4). So I cannot say if java works otherwise. Is this a java or clang bug ? Here is the bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636110 Fixed in b27_6 Hmm, Isn't Openjdk7 affected too ? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2219304 Someone complains on the FreeBSD forums for openjdk7, I think it needs to be patched too. http://forums.freebsd.org/showthread.php?t=41181 Thanks, regards, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Please remove Perl from ports
Le Thu, 1 Aug 2013 08:31:45 -0700 (PDT), Chris H bsd-li...@1command.com a écrit : Greetings, I currently manage several RELENG_8 servers. Recent changes in the manner in which base ports must be managed have resulted in more than a fair amount of grief. the migration from cv(sup) -- subversion required re-working long standing, carefully crafted management procedures to be pitched to the trash, and re-invented. A recent change to the Perl installation structure presents an entire new set of headaches, rendering up(grading|dating) near, if not completely impossible. that's not new. A perl upgrade was always painful. I suggest to use poudriere to build yours packages and pkgng to manage them. As poudriere produces a consistent set of packages, an upgrade is painless (pkg upgrade -f) and you can deploy them on several machines. In fact poudriere and pkg saved me :) Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: (9.2) panic under disk load (gam_server / knlist_remove_kq)
Le Wed, 17 Jul 2013 08:37:18 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, Thanks Konstantin. I'm trying your patch and that looks better. poudriere runs since 3 hours now (before the box paniced few minutes after I start a poudriere bulk) (I've removed the previous change to panic on the warning WARNING: destroying knlist w/ knotes on it! / I guess it is ok ?) As far I can see gamin still works (xfce sees changes and the testgam tool works fine : https://people.gnome.org/~veillard/gamin/debug.html) Does stopping the gamin server work as well ? Yes. $ export GAMIN_DEBUG_SERVER=/usr/pkg/usr/ports/devel/gamin/work/gamin-0.1.10/server/gam_server $ export GAM_CLIENT_ID=test $ export GAM_DEBUG= $ /usr/pkg/usr/ports/devel/gamin/work/gamin-0.1.10/tests/testgam - connect test FAMOpen() Reusing socket directory /tmp/fam-patrick Asking to launch /usr/pkg/usr/ports/devel/gamin/work/gamin-0.1.10/server/gam_server with client id test /// (ps shows this process) mondir /poudriere_data/build/9amd64-default ... (some events) ^C $ Then after the end of the client testgam, the gam_server disappears so that looks good. Thanks Konstantin and Mateusz. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: (9.2) panic under disk load (gam_server / knlist_remove_kq)
Le Tue, 16 Jul 2013 22:14:36 +0200, Patrick Lamaiziere patf...@davenulle.org a écrit : Hello, Thanks Konstantin. I'm trying your patch and that looks better. poudriere runs since 3 hours now (before the box paniced few minutes after I start a poudriere bulk) (I've removed the previous change to panic on the warning WARNING: destroying knlist w/ knotes on it! / I guess it is ok ?) As far I can see gamin still works (xfce sees changes and the testgam tool works fine : https://people.gnome.org/~veillard/gamin/debug.html) I will run few poudriere bulk tomorrow and report the result here. looks good :) Many thanks! Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: (9.2) panic under disk load (gam_server / knlist_remove_kq)
Le Tue, 16 Jul 2013 09:05:55 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, Thanks Konstantin. I'm trying your patch and that looks better. poudriere runs since 3 hours now (before the box paniced few minutes after I start a poudriere bulk) (I've removed the previous change to panic on the warning WARNING: destroying knlist w/ knotes on it! / I guess it is ok ?) As far I can see gamin still works (xfce sees changes and the testgam tool works fine : https://people.gnome.org/~veillard/gamin/debug.html) I will run few poudriere bulk tomorrow and report the result here. I've tried on my workstation at work which uses the same configuration as at home, but I was not able to reproduce this problem. The only big change is that it has 8 GB RAM versus 4 GB here. I don't know what can trigger this panic. If you have patch to test or idea, please let me know. Thanks, regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: (9.2) panic under disk load (gam_server / knlist_remove_kq)
Le Mon, 15 Jul 2013 16:26:47 +0200, Mateusz Guzik mjgu...@gmail.com a écrit : Hello, I'm seeing a panic while trying to build a poudriere repository. As far I can see it always happens when gam_server is started (ie xfce is running) and under disk load (poudriere bulk build) : (That is something new, the box was pretty stable) the complete crash dump (core.0.txt) is here: http://user.lamaiziere.net/patrick/panic_gam_server.txt With WITNESS and ASSERTION on, I see a warning that looks related : Jul 14 16:23:29 roxette kernel: WARNING: destroying knlist w/ knotes on it! and the box panics just after this. can you switch that printf to a panic and paste backtrace? Yes the full core.txt : http://user.lamaiziere.net/patrick/panic_knlist_wknotes.txt panic: WARNING: destroying knlist w/ knotes on it! Unread portion of the kernel message buffer: lock order reversal: 1st 0xfe00b678c098 ufs (ufs) @ /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:620 2nd 0x813ebda0 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:2822 KDB: stack backtrace: #0 0x8094bc26 at kdb_backtrace+0x66 #1 0x809603ae at _witness_debugger+0x2e #2 0x80961a85 at witness_checkorder+0x865 #3 0x8091b1ea at _sx_slock+0x5a #4 0x808d30ff at mountcheckdirs+0x3f #5 0x809a890f at dounmount+0x2df #6 0x809a913e at sys_unmount+0x3ce #7 0x80cec429 at amd64_syscall+0x2f9 #8 0x80cd6d47 at Xfast_syscall+0xf7 panic: WARNING: destroying knlist w/ knotes on it! cpuid = 3 KDB: stack backtrace: #0 0x8094bc26 at kdb_backtrace+0x66 #1 0x80912da8 at panic+0x1d8 #2 0x808db269 at knlist_destroy+0x39 #3 0x809afd7e at destroy_vpollinfo+0x1e #4 0x809b13ef at vdropl+0x18f #5 0x809b404c at vputx+0xac #6 0x8299ce13 at null_reclaim+0x103 #7 0x80d912eb at VOP_RECLAIM_APV+0xdb #8 0x809b20a2 at vgonel+0x112 #9 0x809b4cd9 at vflush+0x2b9 #10 0x8299bbb3 at nullfs_unmount+0x43 #11 0x809a8982 at dounmount+0x352 #12 0x809a913e at sys_unmount+0x3ce #13 0x80cec429 at amd64_syscall+0x2f9 #14 0x80cd6d47 at Xfast_syscall+0xf7 Uptime: 4m47s Dumping 915 out of 3544 MB:..2%..11%..21%..32%..41%..51%..62%..72%..81%..91% #0 doadump (textdump=value optimized out) at pcpu.h:234 234 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:234 #1 0x80913354 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0x80912d79 in panic (fmt=0x1 Address 0x1 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0x808db269 in knlist_destroy (knl=value optimized out) at /usr/src/sys/kern/kern_event.c:1961 #4 0x809afd7e in destroy_vpollinfo (vi=0xfe007ffec690) at /usr/src/sys/kern/vfs_subr.c:3583 #5 0x809b13ef in vdropl (vp=0xfe00b678c000) at /usr/src/sys/kern/vfs_subr.c:2530 #6 0x809b404c in vputx (vp=0xfe00b678c000, func=2) at /usr/src/sys/kern/vfs_subr.c:2358 #7 0x8299ce13 in ?? () #8 0x8299d510 in ?? () #9 0xfe0002ec in ?? () #10 0xff81090b8750 in ?? () #11 0x0246 in ?? () #12 0xfe002af55000 in ?? () #13 0x81576950 in w_locklistdata () #14 0x81322ce0 in pmc___lock_failed () #15 0x8299d8a0 in ?? () #16 0xff81090b87b0 in ?? () #17 0x in ?? () (kgdb) Thanks, regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
(9.2) panic under disk load (gam_server / knlist_remove_kq)
9.2 PRERELEASE (today) / amd64 Hello, I'm seeing a panic while trying to build a poudriere repository. As far I can see it always happens when gam_server is started (ie xfce is running) and under disk load (poudriere bulk build) : (That is something new, the box was pretty stable) the complete crash dump (core.0.txt) is here: http://user.lamaiziere.net/patrick/panic_gam_server.txt Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x58 fault code = supervisor read data, page not present Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x58 fault code = supervisor read data, page not present instruction pointer = 0x20:0x808f1bf1 stack pointer = 0x28:0xff8108e12a40 frame pointer = 0x28:0xff8108e12a70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 23557 (gam_server) trap number = 12 panic: page fault cpuid = 1 ... #0 doadump (textdump=value optimized out) at pcpu.h:234 234 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:234 #1 0x8092e4d6 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0x8092e9d7 in panic (fmt=0x1 Address 0x1 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0x80d13030 in trap_fatal (frame=0xc, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:879 #4 0x80d13391 in trap_pfault (frame=0xff8108e12990, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:795 #5 0x80d13944 in trap (frame=0xff8108e12990) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0x80cfcc73 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0x808f1bf1 in knlist_remove_kq (knl=0x30, kn=0xfe003b70b280, knlislocked=0, kqislocked=0) at /usr/src/sys/kern/kern_event.c:1847 #8 0x808f4a5b in knote_fdclose (td=0xfe0009a34490, fd=9924) at /usr/src/sys/kern/kern_event.c:2065 #9 0x808ea573 in kern_close (td=0xfe0009a34490, fd=9924) at /usr/src/sys/kern/kern_descrip.c:1250 #10 0x80d127da in amd64_syscall (td=0xfe0009a34490, traced=0) at subr_syscall.c:135 #11 0x80cfcf57 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #12 0x0008019e9a9c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Thanks, regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: (9.2) panic under disk load (gam_server / knlist_remove_kq)
Le Sun, 14 Jul 2013 11:59:53 +0200, Patrick Lamaiziere patf...@davenulle.org a écrit : Hello, 9.2 PRERELEASE (today) / amd64 Hello, I'm seeing a panic while trying to build a poudriere repository. As far I can see it always happens when gam_server is started (ie xfce is running) and under disk load (poudriere bulk build) : (That is something new, the box was pretty stable) the complete crash dump (core.0.txt) is here: http://user.lamaiziere.net/patrick/panic_gam_server.txt With WITNESS and ASSERTION on, I see a warning that looks related : Jul 14 16:23:29 roxette kernel: WARNING: destroying knlist w/ knotes on it! and the box panics just after this. Also there are too LOR just before the panic, I don't know it there are related or not : Jul 14 16:23:29 roxette kernel: lock order reversal: Jul 14 16:23:29 roxette kernel: 1st 0xfe0013335878 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1240 Jul 14 16:23:29 roxette kernel: 2nd 0xfe00495a5488 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2335 Jul 14 16:23:29 roxette kernel: KDB: stack backtrace: Jul 14 16:23:29 roxette kernel: #0 0x8094bc36 at kdb_backtrace+0x66 Jul 14 16:23:29 roxette kernel: #1 0x809603be at _witness_debugger+0x2e Jul 14 16:23:29 roxette kernel: #2 0x80961a95 at witness_checkorder+0x865 Jul 14 16:23:29 roxette kernel: #3 0x808f8e21 at __lockmgr_args+0x1161 Jul 14 16:23:29 roxette kernel: #4 0x8099f739 at vop_stdlock+0x39 Jul 14 16:23:29 roxette kernel: #5 0x80d93593 at VOP_LOCK1_APV+0xe3 Jul 14 16:23:29 roxette kernel: #6 0x809c0727 at _vn_lock+0x47 Jul 14 16:23:29 roxette kernel: #7 0x809b42d8 at vputx+0x328 Jul 14 16:23:29 roxette kernel: #8 0x809a88d4 at dounmount+0x294 Jul 14 16:23:29 roxette kernel: #9 0x809a914e at sys_unmount+0x3ce Jul 14 16:23:29 roxette kernel: #10 0x80cec439 at amd64_syscall+0x2f9 Jul 14 16:23:29 roxette kernel: #11 0x80cd6d57 at Xfast_syscall+0xf7 Jul 14 16:23:29 roxette kernel: lock order reversal: Jul 14 16:23:29 roxette kernel: 1st 0xfe006e1eac68 ufs (ufs) @ /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:620 Jul 14 16:23:29 roxette kernel: 2nd 0x813ebda0 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:2822 Jul 14 16:23:29 roxette kernel: KDB: stack backtrace: Jul 14 16:23:29 roxette kernel: #0 0x8094bc36 at kdb_backtrace+0x66 Jul 14 16:23:29 roxette kernel: #1 0x809603be at _witness_debugger+0x2e Jul 14 16:23:29 roxette kernel: #2 0x80961a95 at witness_checkorder+0x865 Jul 14 16:23:29 roxette kernel: #3 0x8091b1fa at _sx_slock+0x5a Jul 14 16:23:29 roxette kernel: #4 0x808d30ff at mountcheckdirs+0x3f Jul 14 16:23:29 roxette kernel: #5 0x809a891f at dounmount+0x2df Jul 14 16:23:29 roxette kernel: #6 0x809a914e at sys_unmount+0x3ce Jul 14 16:23:29 roxette kernel: #7 0x80cec439 at amd64_syscall+0x2f9 Jul 14 16:23:29 roxette kernel: #8 0x80cd6d57 at Xfast_syscall+0xf7 Jul 14 16:23:29 roxette kernel: WARNING: destroying knlist w/ knotes on it! Thanks, regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Some new hardware with 9.1 does not reboot easily
Le Mon, 26 Nov 2012 12:19:07 +0200, Andriy Gapon a...@freebsd.org a écrit : Hello, on 26/11/2012 12:10 Patrick Lamaiziere said the following: As far I can see it fails because there is no getnewvnode_reserve() / get_newvnode_drop_reserve() in 9.1. The patch is for stable/9. Ok, thanks. I've made a new diff because Willem's patch does not apply on 9.STABLE (fails on opensolaris_lookup.c) : This one is for 9-stable rev 243569: http://user.lamaiziere.net/patrick/9-STABLE-r243569-patch-zfs-reboot It solves the reboot problem on my server. I'm testing it on my workstation with few poudriere bulk. It looks to work. Thanks, regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Some new hardware with 9.1 does not reboot easily
Le Fri, 23 Nov 2012 23:41:32 +0100, Willem Jan Withagen w...@digiware.nl a écrit : Hello, I'm waiting for the system to come back up, and will put the svn diff on my webserver, unless it is oke to post a 1200 lines of diff?? I think that a webserver option would be better. Thanks again. Oke, Diff is at: http://www.tegenbosch28.nl/FreeBSD/Diffs/9.1-ZFS-reboot.diff And is against a checkout of this morning: r243433 Hope it works for others. Hmm, the patch does not apply on r243433. -- |Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c |=== |--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c (revision 243433) |+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c (working copy) -- Patching file sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c using Plan A... Hunk #1 succeeded at 1717 (offset -42 lines). Hunk #2 succeeded at 1809 (offset -42 lines). Hunk #3 succeeded at 1843 (offset -42 lines). Hunk #4 succeeded at 1880 (offset -42 lines). Hunk #5 succeeded at 1926 (offset -42 lines). Hunk #6 succeeded at 2080 (offset -42 lines). |Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c |=== |--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c (revision 243433) |+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c (working copy) -- Patching file sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c using Plan A... Hunk #1 succeeded at 135. Hunk #2 succeeded at 508. Hunk #3 succeeded at 746. Hunk #4 succeeded at 757. Hunk #5 failed at 1150. Hunk #6 succeeded at 1179 (offset -5 lines). Hunk #7 failed at 1192. Hunk #8 succeeded at 1250 (offset -1 lines). Hunk #9 succeeded at 1400 (offset -6 lines). Hunk #10 succeeded at 1417 (offset -1 lines). Hunk #11 succeeded at 1420 (offset -6 lines). Hunk #12 succeeded at 1440 (offset -1 lines). 2 out of 12 hunks failed--saving rejects to sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c.rej As far I can see it fails because there is no getnewvnode_reserve() / get_newvnode_drop_reserve() in 9.1. Thansk, Regards. -- Patrick Lamaizière Centre de Ressources Informatiques CRI Central Université de Rennes 1 Tél: 02 23 23 71 45 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Some new hardware with 9.1 does not reboot easily
Le Thu, 22 Nov 2012 11:41:54 +0200, Andriy Gapon a...@freebsd.org a écrit : Hello, I will definitely MFC it to stable/9, just not sure if I would be able to do it before New Year. It definitely won't be in 9.1. I'll send you a patch later. The patch: http://people.freebsd.org/~avg/zfs-vfs.4.diff It does not apply on 9.1 RC-3. I've got a similar problem. Regards. -- Patrick Lamaizière Centre de Ressources Informatiques CRI Central Université de Rennes 1 Tél: 02 23 23 71 45 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Some new hardware with 9.1 does not reboot easily
Le Fri, 23 Nov 2012 16:31:06 +0200, Andriy Gapon a...@freebsd.org a écrit : Hello, I will definitely MFC it to stable/9, just not sure if I would be able to do it before New Year. It definitely won't be in 9.1. I'll send you a patch later. The patch: http://people.freebsd.org/~avg/zfs-vfs.4.diff It does not apply on 9.1 RC-3. I've got a similar problem. With the same backtrace of init? I dont know, it's a remote server without KVM. I just can test if it improves the shutdown. Willem massaged the patch to apply to stable/9 and promised to share his patch. Cool, thanks. I've applied your previous patch (#3, I think) to 9.1 with few modifications but a quick test doing a poudriere bulk (lot of ZFS mount/rollback) shows that the system quickly becomes instable. I didn't find the time to dig into this. I will try the patch from Willem. Thanks, regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: superpages not solving PV entries limit warning
Le Thu, 10 May 2012 14:33:12 -0400, Charles Owens cow...@greatbaysoftware.com a écrit : Hello, Lastly, since we're talking about this (for the future) -- is enabling of superpages generally recommended for amd64? They are enabled by default (at least on 9.0) $ sysctl vm.pmap.pg_ps_enabled vm.pmap.pg_ps_enabled: 1 Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sysutils/pftop on 9.x+
Le Mon, 13 Feb 2012 14:09:25 -0600 (CST), Greg Rivers gcr+freebsd-sta...@tharned.org a écrit : sysutils/pftop was marked broken on 9.x and above last March[1]. Are there any plans to fix it soon? It's a really handy utility. [1] http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/pftop/Makefile?rev=1.17 Looks like there are some patches to make it works with DragonFlyBSD/NetBSD in pkgsrc. Don't have the time to try... http://pkgsrc.se/sysutils/pftop HTH Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[9.0-RC3] tar xf with zip archive is broken
Hello, Looks like tar -xf with zip archive is broken on 9.0. It creates the directories but files are empty. See with nagios-checker firefox plugin (.xpi which is a zip file) http://code.google.com/p/nagioschecker/downloads/detail?name=nagioschecker-0.16.xpican=2q= total 20 drwxr-xr-x 4 patrick patrick 6 20 déc 16:35 ./ drwxr-xr-x 43 patrick patrick 89 20 déc 16:34 ../ drwxr-xr-x 3 patrick patrick 3 20 déc 16:35 chrome/ -rwxr-xr-x 1 patrick patrick 0 15 déc 2010 chrome.manifest* drwxr-xr-x 3 patrick patrick 3 20 déc 16:35 defaults/ -rwxr-xr-x 1 patrick patrick 0 31 déc 2010 install.rdf* On 8.2 that works fine. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Some questions about jails on FreeBSD9.0-RC1
Le Tue, 25 Oct 2011 22:52:55 +0200, carlopmart carlopm...@gmail.com a écrit : Hello, I have installed one FreeBSD 9.0-RC1 host to run different services (dns, smtp and www only) using jails. This host has two physical nics: em0 and em1. em0 is assigned to pyhiscal host, and I would like to assign em1 to jails. But em0 and em1 are on different networks: em0 is on 192.168.1.0/24 and em1 in 192.168.2.0/29. I have setup one jail using ezjail. My first surprise is that ezjail only installs -RELEASE versions and not RC versions. Ok, I supouse that it is normal. But my first question is: can I install a FreeBSD 8.2 jail under a FreeBSD 9.0 host?? You may run 8.2 installed ports on 9.0 by using the port /usr/ports/misc/compat8x/ But I suggest to upgrade the port ASAP. And the real question: How do I need to configure network under this jail to access it? I have configured ifconfig param for em1 on host's rc.conf, but what about the default route under this jail?? I thought to use pf rules, but I am not sure. jail enforces the use of the jail IP address in the jail, but that's all. Just enable routing on the host. Also be sure that the host's daemons don't bind on the jail IP address, as explained in the man page of jail (Setting up the Host Environment). Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: valgrind on FreeBSD?
Le Sun, 9 Oct 2011 17:21:31 +0300, Kostik Belousov kostik...@gmail.com a écrit : If this isn't a known issue, please file a PR for the issue with nullfs(5). The issue is not within valgrind, so the PR should not be for that. I have filled a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=161424 Nullfs VNTOCNP implementation has a known deficiency. I've filled a PR for a similar issue with nullfs (can't get the path of a binary on a nullfs fs) with a suggestion to document this in the nullfs man page. http://www.freebsd.org/cgi/query-pr.cgi?pr=157234 Working on the item is in my TODO list. Thanks! Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CARP interfaces and mastership issue
Le Sat, 17 Sep 2011 23:40:06 -0400 (EDT), Brian Seklecki (Mobile) laval...@probikesllc.com a écrit : What would help here, is for a carp interface to wait a given delay (tunable through a sysctl ?) after creation or after being brought up I see now. The tunable sounds like a good idea; we should check OpenBSD, they probably already implemented something and we're behind. If not, a preempt dampener feature would be an awesome return feature. Might need to implment another state: MASTER-LISTENING (or LEARNING) ah a STP. OpenBSD uses a carp demote counter that prevents to become master (but it will become master anyway if there is not carp advertizement on the interface). There is a sysctl in FreeBSD but it's readonly. This is used to delay carp until pfsync synchronization is done and by daemons like bgpd. Anyway if carp becomes master when the interface is set up, it looks to be a bug on FreeBSD (and if you are sure that the problem does not come from the switch). That works fine on OpenBSD. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [poll] hyperthreading_allowed, hlt_logical_cpus, mp_watchdog
Le Tue, 24 May 2011 16:21:08 +0300, Andriy Gapon a...@freebsd.org a écrit : Hello, I am planning on some changes in head and would like to see if people use the following features: - machdep.hyperthreading_allowed tunable and sysctl If I remember well, these tunables were introduced because the paper of Colin Percival about the HTT security flaw on intel processors : http://www.daemonology.net/hyperthreading-considered-harmful/ http://security.freebsd.org/advisories/FreeBSD-SA-05:09.htt.asc I guess this is still a concern?. Best regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.2/7.4-RELEASEs Announced...
Le Thu, 24 Feb 2011 16:26:23 -0500, Ken Smith kensm...@buffalo.edu a écrit : Hello, 8.2-RELEASE and 7.4-RELEASE have been announced. The announcement messages are available here: http://www.freebsd.org/releases/8.2R/announce.html There is a small typo in the name of the usb image: « memstick This can be written to an USB memory stick (flash drive) and used to do an install on machines capable of booting off USB drives. It also supports booting into a livefs based rescue mode. The documentation packages are provided but no other packages. ... # dd if=8.2-RELEASE-amd64-memstick.img of=/dev/da0 bs=10240 conv=sync » should be FreeBSD-8.2-RELEASE-amd64-memstick.img Enjoy. :-) Thanks! Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
MFC for Easy Editor (ee)
Hello, Accentued and 8 bits characters are broken in ee(1) since 8.0. This is fixed in HEAD in rev 196750, is it possible to mfc the fix? http://svn.freebsd.org/viewvc/base/head/contrib/ee/?view=logpathrev=196750 The patch applies on 8.0 and works fine here. Thanks, regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD on MacBook Pro.
Le Sat, 24 Apr 2010 14:31:18 +0200, Peter Ankerstål pe...@pean.org a écrit : Actuall it seems to work with US ISO och US UNIX too but only with the fixit cd. In the FreeBSD boot-meny I also can use the keyboard properly, but when Im trying to log in on the booted system no keys work properly. It almost seems like the ctrl-key is constantly pressed. (pressing say F gives me ^F on the screen and L clears it like ctrl+L does) -- So I think it is a problem in the keyboard driver. Which Macbook pro model is it? I use a model 3,1 and it works fine. I suggest you to ask on the usb mailing list. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD on MacBook Pro.
Le Fri, 23 Apr 2010 23:42:37 +0200, Peter Ankerstål pe...@pean.org a écrit : Im trying to install FreeBSD on a macbook with dualboot. Everyting works out fine but the keymap doesnt work at all. I've tried alot of keymaps but everyting it produces is mumbojumbo. What keymap should I use to get the macbook working in console? -- There is a french keymap fr.macbook.acc.kbd. May be you can adapt it? This it not very hard to do. There is a new and small utility to get the scancode (use it in a console, not under X): http://hack.org/mc/hacks/kbdscan/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.3-RC2 Available...
Le Thu, 04 Mar 2010 07:41:17 -0700, Reed Loefgren rloefg...@forethought.net a écrit : Hi, Good news, certainly. Will 7.3R include the gmirror improvements that were missed by 8.0R but that are in 8-STABLE? This one? http://www.freshbsd.org/?branch=RELENG_7project=freebsdcommitter=module=q=gmirror Thanks also to the FreeBSD team for their continued hard work. +1 Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: various kde programs spin in a poll/read loop against their respective config files
Le Sat, 26 Sep 2009 15:25:17 +0200,
Christof Schulze christof.schu...@gmx.com a écrit :
Hello everyone,
Hi,
the discussion in -current and the behavior of my hard disk caused me
to investigate. Whenever kde programs are run on this system, the
hard disk will not spin down (even when excessive timeouts for syncs
are in effect) So I ran truss against kwallet and plasma-desktop to
find out they do the same thing:
stat(/home/erika/.kde4/share/apps/kwallet,{ mode=drwx--
,inode=56314,size=3,blksize=4096 }) = 0 (0x0)
Shouldn't this be handled by fam/gamin in order to avoid this
overhead? While it does not produce notable load it prevents my
processor from saving power as well as spinning down the disks.
KDE with fam is broken, according to
http://wiki.freebsd.org/KDE4
A work-around is to change the PollInterval in kdedrc
baby-jane:~$ less .kde4/share/config/kdedrc
[$Version]
update_info=kded.upd:kde3.0
[DirWatch]
PollInterval=6
(IMHO, for KDE issues you should ask on the kde-free...@kde.org mailing
list).
See also this thread :
http://mail.kde.org/pipermail/kde-freebsd/2009-September/006447.html
Regards.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problem booting FreeBSD 8-Beta4 on Soekris net5501
Le Sat, 12 Sep 2009 14:57:16 +1000, Graham Menhennitt gra...@menhennitt.com.au a écrit : I'm upgrading a Soekris net5501 from FreeBSD 7-Stable to 8-Beta4 (via source). I've done a buildworld, buildkernel, and installkernel. When I try to boot the new kernel, it stops very early on in the boot sequence. The serial console shows: ... Does anybody have any clues please? No. I can only say that it works for me (tm) The only change I remember was to change /etc/ttys with ttyu[0..3] instead ttyd[0..3] on 7.2 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-BETA-4: no mouse or keyboard in X.
Le Sun, 13 Sep 2009 15:29:58 +1000, Dave Hardman d...@hardman.name a écrit : I upgraded from 7.2 to 8.0-BETA4. Now X will not receive input from either the mouse or keyboard. When this has happened in 7.1 or 7.2 it was fixed by running hal. The keyboard, mouse and hal are all working. I did not configure X, the xorg.conf file was auto generated when X was first started. I have tried a few things; new xorg.conf with Xorg -configure, putting config files, which I found in a mailing list, in /usr/local/etc/hal/fdi/policy. Using a different window manager. Nothing worked. Theres nothing in the log files that I recognise. Xorg.log reported config/hal Adding input device AT Keyboard. You need to rebuild hal and to remove the old libusb port. libusb is now part of the base system in 8.X and you must use this version. You should rebuild all that depend on the old port libusb (at least). I also noticed the fuse.ko will not load, reporting Exec format error. Did you rebuild this module too? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Recommended wireless card (or is there a chance to get either iwi or ath fixed)?
On 2/24/09, SDH Support ad...@stardothosting.com wrote: I tried using my ath based D-Link DWL G650, which still seems to have some issues in regard to interrupt handling: I've been able to get /most/ wireless cards working with ndiswrapper. *BSD doesnt have ndiswrapper. There is the ndis driver in FreeBSD. I've used a lot ndis with an Intel 2200 BG card. iwi was not reliable. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[7.0 beta4] iwi : firmware stuck in state 4, resetting
Hi, I've got many deconnections with iwi on 7.0 with WPA, far more than on 6.2. iwi0: firmware error iwi0: link state changed to DOWN iwi0: link state changed to UP iwi0: firmware stuck in state 4, resetting [...] Then I have to make an /etc/rc.d/netif restart iwi0 to reconnect. With debug enable on iwi : Dec 15 01:12:03 roxette kernel: sending command idx=13 type=26 len=96 Dec 15 01:12:03 roxette kernel: Beacon miss: 26 = 24 Dec 15 01:12:03 roxette kernel: Beacon miss: 27 = 24 Dec 15 01:12:03 roxette kernel: Beacon miss: 28 = 24 Dec 15 01:12:04 roxette kernel: Beacon miss: 29 = 24 Dec 15 01:12:08 roxette kernel: iwi0: firmware stuck in state 4, resetting I put the complete log here : http://user.lamaiziere.net/patrick/messages.4.bz2 Any idea ? Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
