[head tinderbox] failure on arm/arm
TB --- 2012-06-20 05:10:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-20 05:10:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-20 05:10:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-06-20 05:10:01 - cleaning the object tree TB --- 2012-06-20 05:12:38 - cvsupping the source tree TB --- 2012-06-20 05:12:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-06-20 05:15:22 - building world TB --- 2012-06-20 05:15:22 - CROSS_BUILD_TESTING=YES TB --- 2012-06-20 05:15:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-20 05:15:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-20 05:15:22 - SRCCONF=/dev/null TB --- 2012-06-20 05:15:22 - TARGET=arm TB --- 2012-06-20 05:15:22 - TARGET_ARCH=arm TB --- 2012-06-20 05:15:22 - TZ=UTC TB --- 2012-06-20 05:15:22 - __MAKE_CONF=/dev/null TB --- 2012-06-20 05:15:22 - cd /src TB --- 2012-06-20 05:15:22 - /usr/bin/make -B buildworld World build started on Wed Jun 20 05:15:24 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] === usr.sbin/mfiutil (all) cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfiutil.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_cmd.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_config.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_pd_inq_string': /src/usr.sbin/mfiutil/mfi_drive.c:337: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-20 06:12:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-20 06:12:26 - ERROR: failed to build world TB --- 2012-06-20 06:12:26 - 2312.11 user 545.12 system 3745.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on arm/arm
On 19 June 2012 23:12, FreeBSD Tinderbox tinder...@freebsd.org wrote: Stop in /src/usr.sbin/mfiutil. *** Error code 1 looks like this is my fault :( I've sent a patch to my mentor for approval which should fix this. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r232100: /usr/local/lib/libsasl2.so: undefined reference to `_ThreadRuneLocale@FBSD_1.3'
On Tue, Jun 19, 2012 at 09:13:19AM -0700, Steve Kargl wrote: On Tue, Jun 19, 2012 at 04:40:34PM +0100, Anton Shterenlikht wrote: I'm doing a binary search for another issue between r231193 and r233000. On r232100 I get: cc -O2 -pipe -I/usr/src/libexec/mail.local/../../contrib/sendmail/include -I. -I/usr/local/include -DSASL=2 -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -L/usr/local/lib -o mail.local mail.local.o /usr/obj/usr/src/libexec/mail.local/../../lib/libsm/libsm.a -lsasl2 /usr/local/lib/libsasl2.so: undefined reference to `_ThreadRuneLocale@FBSD_1.3' % svn blame /usr/src/lib/libc/locale/Symbol.map | grep Thread 232498 theraven _ThreadRuneLocale; You did actually provide enough detail about your binary search, sorry, did or didn't? It case it matters, I'm trying to find which revision broke csup on ia64: http://lists.freebsd.org/pipermail/freebsd-ia64/2012-June/003280.html but 232498 falls within your range of 231193:233000. You also forgot to tell us what is in your src.conf I don't use it and make.conf files, this was in the original mail: # cat /etc/make.conf SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 WITH_PKGNG=yes PERL_VERSION=5.14.2 # which is causing you to use something from /usr/local, which needs to be kept in sync with your binary search. Yes, I thought of this, which is why I rebuilt cyrus-sasl on r232100. Perhaps I need to rebuild some other port on r232100? Or maybe it's best to remove auth sendmail while I'm dealing with csup issue? Thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic with out of memory
On Tue, Jun 19, 2012 at 09:30:59PM -0400, Steve Wills wrote: Hi, I just got a panic out of my r237195 system. The panic looks like: Sleeping thread (tid 173153, pid 42034) owns a non-sleepable lock KDB: stack backtrace of thread 173153: sched_switch() at sched_switch+0x28a mi_switch() at mi_switch+0xdf sleepq_timedwait() at sleepq_timedwait+0x3a _sleep() at _sleep+0x266 swp_pager_meta_build() at swp_pager_meta_build+0x259 swap_pager_copy() at swap_pager_copy+0x17b vm_object_collapse() at vm_object_collapse+0x123 vm_object_deallocate() at vm_object_deallocate+0x457 vm_map_process_deferred() at vm_map_process_deferred+0x72 vm_pageout_oom() at vm_pageout_oom+0x180 swp_pager_meta_build() at swp_pager_meta_build+0x248 swap_pager_copy() at swap_pager_copy+0x17b vm_object_collapse() at vm_object_collapse+0x123 vm_object_deallocate() at vm_object_deallocate+0x457 vm_map_process_deferred() at vm_map_process_deferred+0x72 vm_map_remove() at vm_map_remove+0x116 exec_new_vmspace() at exec_new_vmspace+0x1bc exec_elf64_imgact() at exec_elf64_imgact+0x5f4 kern_execve() at kern_execve+0x6f0 sys_execve() at sys_execve+0x37 amd64_syscall() at amd64_syscall+0x351 Xfast_syscall() at Xfast_syscall+0xfb --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800d2eddc, rsp = 0x7fffd328, rbp = 0x7fffd470 --- panic: sleeping thread cpuid = 4 The system was very busy and using lots of swap, but I didn't expect a panic. If any more detail is needed or I should just get more RAM, let me know. :) John has patches for this case. pgpIs7AVHeAUM.pgp Description: PGP signature
Re: Intel XEON Phi: Linux only?
On Tue, Jun 19, 2012 at 09:51:35PM -0600, Scott Long wrote:
On Jun 19, 2012, at 4:31 PM, Adrian Chadd wrote:
I bet the answer is something like Get FreeBSD up on it or work with
someone who can help you do that.
It's a catch-22 just like GPU - unless ${COMPANY} has customers using
it, they're not likely to dedicate resources, and no users will use it
if it doesn't work, so .. who will break the cycle. :)
If I may be blunt here, there's no point in idle speculation when
there are several FreeBSD committers who work for Intel and write Intel
drivers for FreeBSD. Let's ask them!
Intel released a documentation set for MIC, which does not even contain
any references to the startup sequence and system management. The only
thing which is provided is patch for Linux kernel.
I will be very delighted and want to appear completely wrong, but my
suspect is that FreeBSD will be in the same position with MIC as it is
with Intel GPUs. I asked Intel representative about MIC programming
documentation some time ago, the answer was 'we do provide extensive
documentation for SDK'. After I noted that this is not what is needed
to support the hardware on !Linux, I only get a blank eye.
pgpdCZh9Q147P.pgp
Description: PGP signature
Re: r232100: /usr/local/lib/libsasl2.so: undefined reference to `_ThreadRuneLocale@FBSD_1.3'
On Wed, Jun 20, 2012 at 08:46:53AM +0100, Anton Shterenlikht wrote: On Tue, Jun 19, 2012 at 09:13:19AM -0700, Steve Kargl wrote: On Tue, Jun 19, 2012 at 04:40:34PM +0100, Anton Shterenlikht wrote: I'm doing a binary search for another issue between r231193 and r233000. On r232100 I get: cc -O2 -pipe -I/usr/src/libexec/mail.local/../../contrib/sendmail/include -I. -I/usr/local/include -DSASL=2 -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -L/usr/local/lib -o mail.local mail.local.o /usr/obj/usr/src/libexec/mail.local/../../lib/libsm/libsm.a -lsasl2 /usr/local/lib/libsasl2.so: undefined reference to `_ThreadRuneLocale@FBSD_1.3' % svn blame /usr/src/lib/libc/locale/Symbol.map | grep Thread 232498 theraven _ThreadRuneLocale; You did actually provide enough detail about your binary search, sorry, did or didn't? It case it matters, I'm trying to find which revision broke csup on ia64: http://lists.freebsd.org/pipermail/freebsd-ia64/2012-June/003280.html but 232498 falls within your range of 231193:233000. You also forgot to tell us what is in your src.conf I don't use it and make.conf files, this was in the original mail: # cat /etc/make.conf SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 WITH_PKGNG=yes PERL_VERSION=5.14.2 # which is causing you to use something from /usr/local, which needs to be kept in sync with your binary search. Yes, I thought of this, which is why I rebuilt cyrus-sasl on r232100. Perhaps I need to rebuild some other port on r232100? Or maybe it's best to remove auth sendmail while I'm dealing with csup issue? just to confirm, removing the 3 sendmail lines from make.conf makes r232100 world build fine. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic with out of memory
On Tuesday, June 19, 2012 9:30:59 pm Steve Wills wrote:
Hi,
I just got a panic out of my r237195 system. The panic looks like:
Sleeping thread (tid 173153, pid 42034) owns a non-sleepable lock
KDB: stack backtrace of thread 173153:
sched_switch() at sched_switch+0x28a
mi_switch() at mi_switch+0xdf
sleepq_timedwait() at sleepq_timedwait+0x3a
_sleep() at _sleep+0x266
swp_pager_meta_build() at swp_pager_meta_build+0x259
swap_pager_copy() at swap_pager_copy+0x17b
vm_object_collapse() at vm_object_collapse+0x123
vm_object_deallocate() at vm_object_deallocate+0x457
vm_map_process_deferred() at vm_map_process_deferred+0x72
vm_pageout_oom() at vm_pageout_oom+0x180
swp_pager_meta_build() at swp_pager_meta_build+0x248
swap_pager_copy() at swap_pager_copy+0x17b
vm_object_collapse() at vm_object_collapse+0x123
vm_object_deallocate() at vm_object_deallocate+0x457
vm_map_process_deferred() at vm_map_process_deferred+0x72
vm_map_remove() at vm_map_remove+0x116
exec_new_vmspace() at exec_new_vmspace+0x1bc
exec_elf64_imgact() at exec_elf64_imgact+0x5f4
kern_execve() at kern_execve+0x6f0
sys_execve() at sys_execve+0x37
amd64_syscall() at amd64_syscall+0x351
Xfast_syscall() at Xfast_syscall+0xfb
--- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800d2eddc, rsp =
0x7fffd328, rbp = 0x7fffd470 ---
panic: sleeping thread
cpuid = 4
The system was very busy and using lots of swap, but I didn't expect a
panic. If any more detail is needed or I should just get more RAM, let
me know. :)
Hmm, this is due to a bug I noticed recently as well. I had been talking
with Alan and Konstantin about the proper fix. Hmm, thinking abou this some
more, perhaps a simpler fix would be to have a 'I'm already in
vm_map_process_deferred()' flag. Or even better, just move the entire list
off into a static variable so that we don't get caught in recursion.
Something like this:
Index: vm_map.c
===
--- vm_map.c(revision 237227)
+++ vm_map.c(working copy)
@@ -475,12 +475,14 @@ static void
vm_map_process_deferred(void)
{
struct thread *td;
- vm_map_entry_t entry;
+ vm_map_entry_t entry, next;
vm_object_t object;
td = curthread;
- while ((entry = td-td_map_def_user) != NULL) {
- td-td_map_def_user = entry-next;
+ entry = td-td_map_def_user;
+ td-td_map_def_user = NULL;
+ while (entry != NULL) {
+ next = entry-next;
if ((entry-eflags MAP_ENTRY_VN_WRITECNT) != 0) {
/*
* Decrement the object's writemappings and
@@ -494,6 +496,7 @@ vm_map_process_deferred(void)
entry-end);
}
vm_map_entry_deallocate(entry, FALSE);
+ entry = next;
}
}
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -CURRENT Panic at boot at Revision: 237264 mutex gif softc not owned at /usr/src/sys/netinet/in_gif.c:105
On Tuesday, June 19, 2012 8:05:36 pm Vincent Hoffman wrote:
Full dump info at http://unsane.co.uk/crash
It seems to have popped up between r236905 (working kernel) and r237264
(this panic)
the gif config I have in rc.conf is for a HE ipv6 tunnel
Looks like this was broken in r236951 by Randall (cc'd).
I think this would fix it:
Index: if_gif.c
===
--- if_gif.c(revision 237227)
+++ if_gif.c(working copy)
@@ -366,11 +366,12 @@ gif_start(struct ifnet *ifp)
return;
}
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
- GIF_UNLOCK(sc);
keep_going:
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
+ GIF_UNLOCK(sc);
IFQ_DRV_DEQUEUE(ifp-if_snd, m);
+ GIF_LOCK(sc);
if (m == 0)
break;
@@ -424,14 +425,12 @@ keep_going:
ifp-if_oerrors++;
}
- GIF_LOCK(sc);
if (ifp-if_drv_flags IFF_GIF_WANTED) {
/* Someone did a start while
* we were unlocked and processing
* lets clear the flag and try again.
*/
ifp-if_drv_flags = ~IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
goto keep_going;
}
ifp-if_drv_flags = ~IFF_DRV_OACTIVE;
However, unless there is a known LOR, I would be inclined to
just hold the lock across IFQ_DRV_DEQUEUE() and dispense with
all the 'keep_going', etc. logic. Other NIC drivers tend to
just hold their transmit lock for the entire loop in their
start routines.
That would look like this:
Index: if.h
===
--- if.h(revision 237227)
+++ if.h(working copy)
@@ -153,7 +153,6 @@
#defineIFF_STATICARP 0x8 /* (n) static ARP */
#defineIFF_DYING 0x20/* (n) interface is winding
down */
#defineIFF_RENAMING0x40/* (n) interface is being
renamed */
-#define IFF_GIF_WANTED 0x100 /* (n) The gif tunnel is wanted */
/*
* Old names for driver flags so that user space tools can continue to use
* the old (portable) names.
Index: if_gif.c
===
--- if_gif.c(revision 237227)
+++ if_gif.c(working copy)
@@ -359,15 +359,7 @@
sc = ifp-if_softc;
GIF_LOCK(sc);
- if (ifp-if_drv_flags IFF_DRV_OACTIVE) {
- /* Already active */
- ifp-if_drv_flags |= IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
- return;
- }
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
- GIF_UNLOCK(sc);
-keep_going:
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
IFQ_DRV_DEQUEUE(ifp-if_snd, m);
@@ -424,16 +416,6 @@
ifp-if_oerrors++;
}
- GIF_LOCK(sc);
- if (ifp-if_drv_flags IFF_GIF_WANTED) {
- /* Someone did a start while
-* we were unlocked and processing
-* lets clear the flag and try again.
-*/
- ifp-if_drv_flags = ~IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
- goto keep_going;
- }
ifp-if_drv_flags = ~IFF_DRV_OACTIVE;
GIF_UNLOCK(sc);
return;
I would prefer this latter patch if it is ok as it makes the code simpler.
Also, IFF_GIF_WANTED as a new iff flag seems really hackish. IFF_* flags
are supposed to be interface independent. A flag like that should be in a
private field in the gif softc, not something exposed to the entire system.
cloned_interfaces=gif0
ifconfig_gif0=tunnel 85.233.185.162 216.66.80.26
ifconfig_gif0_ipv6=inet6 2001:470:1f08:110::2 2001:470:1f08:110::1
prefixlen 128 -accept_rtadv
src.conf only has
WITHOUT_IPFILTER=true
WITHOUT_KERBEROS=true
WITHOUT_PROFILE=yes
Happy to provide any more info as needed. any suggestions welcome, I'll
see if I can track it further with a binary search tomorrow.
From dump info file (at above URL)
#0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:266
266 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:266
#1 0x80314740 in db_dump (dummy=Variable dummy is not available.
)
at /usr/src/sys/ddb/db_command.c:538
#2 0x80313d31 in db_command (last_cmdp=0x80c52b40,
cmd_table=Variable cmd_table is not available.
) at /usr/src/sys/ddb/db_command.c:449
#3 0x80313f80 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:502
#4 0x803160d9 in db_trap (type=Variable type is not available.
) at /usr/src/sys/ddb/db_main.c:231
#5 0x80590918 in kdb_trap (type=3, code=0, tf=0xff80ea22ee20)
at /usr/src/sys/kern/subr_kdb.c:654
#6 0x80815c9d in trap (frame=0xff80ea22ee20)
at
Re: panic with out of memory
On Wed, Jun 20, 2012 at 08:19:39AM -0400, John Baldwin wrote:
On Tuesday, June 19, 2012 9:30:59 pm Steve Wills wrote:
Hi,
I just got a panic out of my r237195 system. The panic looks like:
Sleeping thread (tid 173153, pid 42034) owns a non-sleepable lock
KDB: stack backtrace of thread 173153:
sched_switch() at sched_switch+0x28a
mi_switch() at mi_switch+0xdf
sleepq_timedwait() at sleepq_timedwait+0x3a
_sleep() at _sleep+0x266
swp_pager_meta_build() at swp_pager_meta_build+0x259
swap_pager_copy() at swap_pager_copy+0x17b
vm_object_collapse() at vm_object_collapse+0x123
vm_object_deallocate() at vm_object_deallocate+0x457
vm_map_process_deferred() at vm_map_process_deferred+0x72
vm_pageout_oom() at vm_pageout_oom+0x180
swp_pager_meta_build() at swp_pager_meta_build+0x248
swap_pager_copy() at swap_pager_copy+0x17b
vm_object_collapse() at vm_object_collapse+0x123
vm_object_deallocate() at vm_object_deallocate+0x457
vm_map_process_deferred() at vm_map_process_deferred+0x72
vm_map_remove() at vm_map_remove+0x116
exec_new_vmspace() at exec_new_vmspace+0x1bc
exec_elf64_imgact() at exec_elf64_imgact+0x5f4
kern_execve() at kern_execve+0x6f0
sys_execve() at sys_execve+0x37
amd64_syscall() at amd64_syscall+0x351
Xfast_syscall() at Xfast_syscall+0xfb
--- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800d2eddc, rsp =
0x7fffd328, rbp = 0x7fffd470 ---
panic: sleeping thread
cpuid = 4
The system was very busy and using lots of swap, but I didn't expect a
panic. If any more detail is needed or I should just get more RAM, let
me know. :)
Hmm, this is due to a bug I noticed recently as well. I had been talking
with Alan and Konstantin about the proper fix. Hmm, thinking abou this some
more, perhaps a simpler fix would be to have a 'I'm already in
vm_map_process_deferred()' flag. Or even better, just move the entire list
off into a static variable so that we don't get caught in recursion.
Something like this:
Index: vm_map.c
===
--- vm_map.c (revision 237227)
+++ vm_map.c (working copy)
@@ -475,12 +475,14 @@ static void
vm_map_process_deferred(void)
{
struct thread *td;
- vm_map_entry_t entry;
+ vm_map_entry_t entry, next;
vm_object_t object;
td = curthread;
- while ((entry = td-td_map_def_user) != NULL) {
- td-td_map_def_user = entry-next;
+ entry = td-td_map_def_user;
+ td-td_map_def_user = NULL;
+ while (entry != NULL) {
+ next = entry-next;
if ((entry-eflags MAP_ENTRY_VN_WRITECNT) != 0) {
/*
* Decrement the object's writemappings and
@@ -494,6 +496,7 @@ vm_map_process_deferred(void)
entry-end);
}
vm_map_entry_deallocate(entry, FALSE);
+ entry = next;
}
}
Yes, looks like it should work.
pgppPtvmPfGvQ.pgp
Description: PGP signature
[PATCH] Trim some noise from the daily disk check
The daily periodic e-mails for my boxes always include useless output from dump -W. I think the daily e-mail should only do that if the sysadmin is actually using dump. The patch below skips the dump reporting it /etc/dumpdates doesn't exist or exists and is an empty file (the latter is what you get out-of-the-box): Index: 400.status-disks === --- 400.status-disks(revision 237227) +++ 400.status-disks(working copy) @@ -19,13 +19,16 @@ case $daily_status_disks_enable in df $daily_status_disks_df_flags rc=1 || rc=3 # display which filesystems need backing up - if ! [ -f /etc/fstab ]; then - export PATH_FSTAB=/dev/null + if [ -s /etc/dumpdates ]; then + if ! [ -f /etc/fstab ]; then + export PATH_FSTAB=/dev/null + fi + + echo + dump W || rc=3 fi + ;; - echo - dump W || rc=3;; - *) rc=0;; esac Thoughts? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic's in 10-CURRENT r235646 in VMware
On Tuesday, June 19, 2012 1:31:17 pm Matthias Apitz wrote:
El día Tuesday, June 19, 2012 a las 10:56:20AM -0400, John Baldwin escribió:
#11 0xc0d11340 in vm_page_free_toq (m=0xc23daf78)
at /usr/src/sys/vm/vm_page.c:2060
#12 0xc0d115b5 in vm_page_free (m=0xc23daf78) at
/usr/src/sys/vm/vm_page.c:741
#13 0xc68b01ba in OS_ReservedPageFree ()
from /usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko
Ah, so the bug is in here then. Which version of vmware-tools do you have
installed?
all the ports are from CVS of May, 19; the version is open-vm-tools-425873,1
Try this patch for the port. It uses vm_page_lock() instead of
vm_page_lock_queues() around vm_page_free() for 9.0 and later.
Index: files/patch-vmmemctl-os.c
===
RCS file: /scratchbsd/FreeBSD/cvs/ports/emulators/open-vm-tools/files/patch-
vmmemctl-os.c,v
retrieving revision 1.2
diff -u -r1.2 patch-vmmemctl-os.c
--- files/patch-vmmemctl-os.c 2 Jan 2010 16:29:44 - 1.2
+++ files/patch-vmmemctl-os.c 20 Jun 2012 13:45:11 -
@@ -1,6 +1,6 @@
modules/freebsd/vmmemctl/os.c.orig 2009-04-09 15:18:08.0 -0400
-+++ modules/freebsd/vmmemctl/os.c 2009-04-09 15:34:06.0 -0400
-@@ -413,12 +413,14 @@
+--- modules/freebsd/vmmemctl/os.c.orig 2011-09-21 14:25:15.0 -0400
modules/freebsd/vmmemctl/os.c 2012-06-20 09:44:40.434083000 -0400
+@@ -344,12 +344,22 @@
os_state *state = global_state;
os_pmap *pmap = state-pmap;
@@ -9,9 +9,17 @@
+ VM_OBJECT_LOCK(state-vmobject);
+ if ( vm_page_lookup(state-vmobject, page-pindex) ) {
+ os_pmap_putindex(pmap, page-pindex);
++#if __FreeBSD_version = 90
++ vm_page_lock(page);
++#else
+ vm_page_lock_queues();
++#endif
+ vm_page_free(page);
++#if __FreeBSD_version = 90
++ vm_page_unlock(page);
++#else
+ vm_page_unlock_queues();
++#endif
}
-
- os_pmap_putindex(pmap, page-pindex);
@@ -19,8 +27,8 @@
+ VM_OBJECT_UNLOCK(state-vmobject);
}
- static vm_page_t os_kmem_alloc(int alloc_normal_failed)
-@@ -430,8 +432,11 @@
+
+@@ -361,8 +371,11 @@
os_state *state = global_state;
os_pmap *pmap = state-pmap;
@@ -32,7 +40,7 @@
return NULL;
}
-@@ -452,6 +457,7 @@
+@@ -383,6 +396,7 @@
if (!page) {
os_pmap_putindex(pmap, pindex);
}
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: csup ends up in sigwai after Shutting down connection to server, never exits
Anton, Sorry for the delay, I was AFK over the last couple of days. On Tue, Jun 19, 2012 at 01:19:38PM +0100, Anton Shterenlikht wrote: On Tue, Jun 19, 2012 at 01:49:36PM +0200, Jeremie Le Hen wrote: I think recompiling the kernel and the libraries csup depends on will be enough. you mean # make cleandir make obj make make install for all these libs: # ldd /root/csup/csup /root/csup/csup: libz.so.6 = /lib/libz.so.6 (0x1200ca000) libthr.so.3 = /lib/libthr.so.3 (0x120102000) libmd.so.5 = /lib/libmd.so.5 (0x12014c000) libc.so.7 = /lib/libc.so.7 (0x120178000) Yes, right. And the kernel of course. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on arm/arm
TB --- 2012-06-20 14:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-20 14:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-20 14:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-06-20 14:20:00 - cleaning the object tree TB --- 2012-06-20 14:23:44 - cvsupping the source tree TB --- 2012-06-20 14:23:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-06-20 14:24:22 - building world TB --- 2012-06-20 14:24:22 - CROSS_BUILD_TESTING=YES TB --- 2012-06-20 14:24:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-20 14:24:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-20 14:24:22 - SRCCONF=/dev/null TB --- 2012-06-20 14:24:22 - TARGET=arm TB --- 2012-06-20 14:24:22 - TARGET_ARCH=arm TB --- 2012-06-20 14:24:22 - TZ=UTC TB --- 2012-06-20 14:24:22 - __MAKE_CONF=/dev/null TB --- 2012-06-20 14:24:22 - cd /src TB --- 2012-06-20 14:24:22 - /usr/bin/make -B buildworld World build started on Wed Jun 20 14:24:22 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] === usr.sbin/mfiutil (all) cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfiutil.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_cmd.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_config.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_pd_inq_string': /src/usr.sbin/mfiutil/mfi_drive.c:337: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-20 15:23:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-20 15:23:10 - ERROR: failed to build world TB --- 2012-06-20 15:23:10 - 2313.62 user 549.38 system 3789.82 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic with out of memory
On 06/20/2012 08:25, Konstantin Belousov wrote:
On Wed, Jun 20, 2012 at 08:19:39AM -0400, John Baldwin wrote:
On Tuesday, June 19, 2012 9:30:59 pm Steve Wills wrote:
Hi,
I just got a panic out of my r237195 system. The panic looks like:
Sleeping thread (tid 173153, pid 42034) owns a non-sleepable lock
KDB: stack backtrace of thread 173153:
sched_switch() at sched_switch+0x28a
mi_switch() at mi_switch+0xdf
sleepq_timedwait() at sleepq_timedwait+0x3a
_sleep() at _sleep+0x266
swp_pager_meta_build() at swp_pager_meta_build+0x259
swap_pager_copy() at swap_pager_copy+0x17b
vm_object_collapse() at vm_object_collapse+0x123
vm_object_deallocate() at vm_object_deallocate+0x457
vm_map_process_deferred() at vm_map_process_deferred+0x72
vm_pageout_oom() at vm_pageout_oom+0x180
swp_pager_meta_build() at swp_pager_meta_build+0x248
swap_pager_copy() at swap_pager_copy+0x17b
vm_object_collapse() at vm_object_collapse+0x123
vm_object_deallocate() at vm_object_deallocate+0x457
vm_map_process_deferred() at vm_map_process_deferred+0x72
vm_map_remove() at vm_map_remove+0x116
exec_new_vmspace() at exec_new_vmspace+0x1bc
exec_elf64_imgact() at exec_elf64_imgact+0x5f4
kern_execve() at kern_execve+0x6f0
sys_execve() at sys_execve+0x37
amd64_syscall() at amd64_syscall+0x351
Xfast_syscall() at Xfast_syscall+0xfb
--- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800d2eddc, rsp =
0x7fffd328, rbp = 0x7fffd470 ---
panic: sleeping thread
cpuid = 4
The system was very busy and using lots of swap, but I didn't expect a
panic. If any more detail is needed or I should just get more RAM, let
me know. :)
Hmm, this is due to a bug I noticed recently as well. I had been talking
with Alan and Konstantin about the proper fix. Hmm, thinking abou this some
more, perhaps a simpler fix would be to have a 'I'm already in
vm_map_process_deferred()' flag. Or even better, just move the entire list
off into a static variable so that we don't get caught in recursion.
Something like this:
Index: vm_map.c
===
--- vm_map.c(revision 237227)
+++ vm_map.c(working copy)
@@ -475,12 +475,14 @@ static void
vm_map_process_deferred(void)
{
struct thread *td;
- vm_map_entry_t entry;
+ vm_map_entry_t entry, next;
vm_object_t object;
td = curthread;
- while ((entry = td-td_map_def_user) != NULL) {
- td-td_map_def_user = entry-next;
+ entry = td-td_map_def_user;
+ td-td_map_def_user = NULL;
+ while (entry != NULL) {
+ next = entry-next;
if ((entry-eflags MAP_ENTRY_VN_WRITECNT) != 0) {
/*
* Decrement the object's writemappings and
@@ -494,6 +496,7 @@ vm_map_process_deferred(void)
entry-end);
}
vm_map_entry_deallocate(entry, FALSE);
+ entry = next;
}
}
Yes, looks like it should work.
I'll add, Me too. I'm much happier with this than the previous patch.
Alan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Trim some noise from the daily disk check
On Wed, Jun 20, 2012 at 09:35:27AM -0400, John Baldwin wrote: The daily periodic e-mails for my boxes always include useless output from dump -W. I think the daily e-mail should only do that if the sysadmin is actually using dump. The patch below skips the dump reporting it /etc/dumpdates doesn't exist or exists and is an empty file (the latter is what you get out-of-the-box): Index: 400.status-disks === --- 400.status-disks (revision 237227) +++ 400.status-disks (working copy) @@ -19,13 +19,16 @@ case $daily_status_disks_enable in df $daily_status_disks_df_flags rc=1 || rc=3 # display which filesystems need backing up - if ! [ -f /etc/fstab ]; then - export PATH_FSTAB=/dev/null + if [ -s /etc/dumpdates ]; then + if ! [ -f /etc/fstab ]; then + export PATH_FSTAB=/dev/null + fi + + echo + dump W || rc=3 fi + ;; - echo - dump W || rc=3;; - *) rc=0;; esac Thoughts? This seems sensible to me. -- Brooks pgp2wAGoA2duf.pgp Description: PGP signature
Re: [CFT] SMP/i386 suspend/resume
Hi developers. I want help you with your acpi work. I have thinkpad t61. Could you write a small to do. Step by step, how tests your patches? Which information is important for send. On Wed, 2012-05-16 at 11:31 +0900, Mitsuru IWASAKI wrote: Hi, First of all, thank you very much for your work! I wanted to do it for very long time but I had no time to actually implement it. :-) Welcome! I also wanted to do this for very long time but I had no time and test machines ;) Recently I got Core Duo (Thinkpad X60) and Core 2 Duo (X61) machines. I have some more ideas on wakecode but I'm not sure whether it is possible for now. I'll propose it when it is ready. I know for sure it is not related to your patches. In fact, we cannot resume most NVIDIA controllers without NVIDIA kernel driver + binary X.org driver + VT switching hack (i.e., Hmm, my knowledge on recent hardware is very poor, so your comments are very helpful to catch up. Thanks. We can improve video initialization on another opportunity. Linux have many video hacks while we have only hw.acpi.reset_video ;) FYI, we don't need hw.acpi.reset_video any more (and it is even harmful). It is done from vesa.ko now. Yeah, I thought that we need INT10 to set video mode again in realmode, but found it can be done in protected mode with x86bios_intr(), great! Anyway, thanks for many things! ___ freebsd-a...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -CURRENT Panic at boot at Revision: 237264 mutex gif softc not owned at /usr/src/sys/netinet/in_gif.c:105
The patch to gif.c does fix it.
I'll try the second patch later when I get a chance.
Thanks,
Vince
On 20/06/2012 13:12, John Baldwin wrote:
On Tuesday, June 19, 2012 8:05:36 pm Vincent Hoffman wrote:
Full dump info at http://unsane.co.uk/crash
It seems to have popped up between r236905 (working kernel) and r237264
(this panic)
the gif config I have in rc.conf is for a HE ipv6 tunnel
Looks like this was broken in r236951 by Randall (cc'd).
I think this would fix it:
Index: if_gif.c
===
--- if_gif.c (revision 237227)
+++ if_gif.c (working copy)
@@ -366,11 +366,12 @@ gif_start(struct ifnet *ifp)
return;
}
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
- GIF_UNLOCK(sc);
keep_going:
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
+ GIF_UNLOCK(sc);
IFQ_DRV_DEQUEUE(ifp-if_snd, m);
+ GIF_LOCK(sc);
if (m == 0)
break;
@@ -424,14 +425,12 @@ keep_going:
ifp-if_oerrors++;
}
- GIF_LOCK(sc);
if (ifp-if_drv_flags IFF_GIF_WANTED) {
/* Someone did a start while
* we were unlocked and processing
* lets clear the flag and try again.
*/
ifp-if_drv_flags = ~IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
goto keep_going;
}
ifp-if_drv_flags = ~IFF_DRV_OACTIVE;
However, unless there is a known LOR, I would be inclined to
just hold the lock across IFQ_DRV_DEQUEUE() and dispense with
all the 'keep_going', etc. logic. Other NIC drivers tend to
just hold their transmit lock for the entire loop in their
start routines.
That would look like this:
Index: if.h
===
--- if.h (revision 237227)
+++ if.h (working copy)
@@ -153,7 +153,6 @@
#define IFF_STATICARP 0x8 /* (n) static ARP */
#define IFF_DYING 0x20/* (n) interface is winding
down */
#define IFF_RENAMING0x40/* (n) interface is being
renamed */
-#define IFF_GIF_WANTED 0x100 /* (n) The gif tunnel is wanted
*/
/*
* Old names for driver flags so that user space tools can continue to use
* the old (portable) names.
Index: if_gif.c
===
--- if_gif.c (revision 237227)
+++ if_gif.c (working copy)
@@ -359,15 +359,7 @@
sc = ifp-if_softc;
GIF_LOCK(sc);
- if (ifp-if_drv_flags IFF_DRV_OACTIVE) {
- /* Already active */
- ifp-if_drv_flags |= IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
- return;
- }
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
- GIF_UNLOCK(sc);
-keep_going:
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
IFQ_DRV_DEQUEUE(ifp-if_snd, m);
@@ -424,16 +416,6 @@
ifp-if_oerrors++;
}
- GIF_LOCK(sc);
- if (ifp-if_drv_flags IFF_GIF_WANTED) {
- /* Someone did a start while
- * we were unlocked and processing
- * lets clear the flag and try again.
- */
- ifp-if_drv_flags = ~IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
- goto keep_going;
- }
ifp-if_drv_flags = ~IFF_DRV_OACTIVE;
GIF_UNLOCK(sc);
return;
I would prefer this latter patch if it is ok as it makes the code simpler.
Also, IFF_GIF_WANTED as a new iff flag seems really hackish. IFF_* flags
are supposed to be interface independent. A flag like that should be in a
private field in the gif softc, not something exposed to the entire system.
cloned_interfaces=gif0
ifconfig_gif0=tunnel 85.233.185.162 216.66.80.26
ifconfig_gif0_ipv6=inet6 2001:470:1f08:110::2 2001:470:1f08:110::1
prefixlen 128 -accept_rtadv
src.conf only has
WITHOUT_IPFILTER=true
WITHOUT_KERBEROS=true
WITHOUT_PROFILE=yes
Happy to provide any more info as needed. any suggestions welcome, I'll
see if I can track it further with a binary search tomorrow.
From dump info file (at above URL)
#0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:266
266 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:266
#1 0x80314740 in db_dump (dummy=Variable dummy is not available.
)
at /usr/src/sys/ddb/db_command.c:538
#2 0x80313d31 in db_command (last_cmdp=0x80c52b40,
cmd_table=Variable cmd_table is not available.
) at /usr/src/sys/ddb/db_command.c:449
#3 0x80313f80 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:502
#4 0x803160d9 in db_trap (type=Variable type is not available.
) at /usr/src/sys/ddb/db_main.c:231
#5 0x80590918 in kdb_trap (type=3, code=0, tf=0xff80ea22ee20)
Wireless: AzureWave 2100 supported?
Hi there I have a Gigabyte Motherboard here with the following wireless card: lspci 08:00.0 Network controller: Atheros Communications Inc. Device 0037 (rev 01) Subsystem: AzureWave Device 2100 or if you prefer pciconf: none12@pci0:8:0:0: class=0x028000 card=0x21001a3b chip=0x0037168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' class = network Is this card supported by FreeBSD? If yes, by which driver? mfg sam ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wireless: AzureWave 2100 supported?
Hi, On 20 June 2012 14:02, sam samira@gmail.com wrote: or if you prefer pciconf: none12@pci0:8:0:0: class=0x028000 card=0x21001a3b chip=0x0037168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' class = network 0x168c is Atheros. 0x0037 looks like some kind of AR93xx derivative. There's currently no support in ath(4) and ath_hal(4) for the AR93xx or later chips. I have some rough plans to start supporting that when I get some time but I'm very short on time right now and I'm mostly trying to focus on testing and tidying up the existing driver code before I bring over AR93xx support. Sorry, I can't give you any further help than that. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities
Hi Folks, This is a call for testing of the new sysutils/bsdconfig port. Back in February, Ron McDowell and myself together decided we were going to take-on the task of salvaging sysinstall(8)'s Configure menu while simultaneously rewriting it into a system of shell scripts (making it similar to bsdinstall) so that sysinstall(8) could be safely and quietly put to pasture (meanwhile contradictorily _increasing_ functionality due to several enhancements performed in the process). After talking with a lot of other developers and really helpful folks, we decided to shoot for the 9.1-R freeze to coincide with other new features like pkgng. Currently, bsdconfig cannot do what sysinstall is known most for (package installation), but that is because we have a plan to _start_ with pkgng (and it just works better if pkgng can mature before the integration). If the thought of losing sysinstall has ever made you uneasy because unique functionality not found elsewhere, please try the sysutils/bsdconfig port to help get it some testing. With ~25,000 lines of code, we really need to get some testing on this before adding this to HEAD and I've turned the source into a port to make the testing process easier and to widen the audience. If you have the time and/or energy, please test and report any issues that you experience. If things go well, we can get this MFC'd from HEAD before the 9.1 freeze. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities
Devin Teske devin.te...@fisglobal.com wrote: If you have the time and/or energy, please test and report any issues that you experience. Toggle Startup Services dialog shows sendmail_enable and sendmail_msp_queue_enable variables, but doesn't seem to show sendmail_submit_enable and sendmail_outbound_enable. Is this by design? It also hangs if I try to toggle sendmail_msp_queue_enable. (Tell me if you can't reproduce this easily, I'll provide more details). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities
On Jun 20, 2012, at 5:16 PM, Vitaly Magerya wrote: Devin Teske devin.te...@fisglobal.com wrote: If you have the time and/or energy, please test and report any issues that you experience. Toggle Startup Services dialog shows sendmail_enable and sendmail_msp_queue_enable variables, but doesn't seem to show sendmail_submit_enable and sendmail_outbound_enable. Is this by design? What does the following produce: service sendmail rcvar Now what does this say: grep sendmail /var/run/bsdconfig/startup_rcvar_map.cache Do they agree? The list is generated dynamically. If there's a variable that's missing, it's because it wasn't reported by the rc.d script. It also hangs if I try to toggle sendmail_msp_queue_enable. (Tell me if you can't reproduce this easily, I'll provide more details). Wow, that was an obscure bug! Thanks for finding that! The nature of this bug is that if the item that you select in the menu is evenly divisible by both 2 and 3 landing on a boundary, the item works as expected, otherwise you can only toggle the item ON (not off). Details are too boring to explain, I'll have to roll a new version. Thank you so very much for finding this bug. I'll try to have it fixed today in the next hour or so. Other areas should be unaffected. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities
On Jun 20, 2012, at 6:24 PM, Devin Teske wrote: On Jun 20, 2012, at 5:16 PM, Vitaly Magerya wrote: [snip] It also hangs if I try to toggle sendmail_msp_queue_enable. (Tell me if you can't reproduce this easily, I'll provide more details). Wow, that was an obscure bug! Thanks for finding that! [snip] I'll try to have it fixed today in the next hour or so. Other areas should be unaffected. Fixed, and I filed ports/169280. As soon as someone commits that, you'll be able to portupgrade to the fixed version. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
minor GEOM disk API change coming
Hi folks, I have attached some patches that fix an object lifetime issue between CAM and GEOM. Fixing the bug required adding a callback to the GEOM disk code, and adding a callback that a GEOM class can register to get notified when a provider is destroyed. The probable commit message is below. If I don't hear any objections, I will commit it on Friday, June 22nd. Fix a bug which causes a panic in daopen(). The panic is caused by a da(4) instance going away while GEOM is still probing it. In this case, the GEOM disk class instance has been created by disk_create(), and the taste of the disk is queued in the GEOM event queue. While that event is queued, the da(4) instance goes away. When the open call comes into the da(4) driver, it dereferences the freed (but non-NULL) peripheral pointer provided by GEOM, which results in a panic. The solution is to add a callback to the GEOM disk code that is called when all of its resources are cleaned up. This is implemented inside GEOM by adding an optional callback that is called when all consumers have detached from a provider, and the provider is about to be deleted. scsi_cd.c, scsi_da.c: In the register routine for the cd(4) and da(4) routines, acquire a reference to the CAM peripheral instance just before we call disk_create(). Use the new GEOM disk d_gone() callback to register a callback (dadiskgonecb()/cddiskgonecb()) that decrements the peripheral reference count once GEOM has finished cleaning up its resources. In the cd(4) driver, clean up open and close behavior slightly. GEOM makes sure we only get one open() and one close call, so there is no need to set an open flag and decrement the reference count if we are not the first open. In the cd(4) driver, use cam_periph_release_locked() in a couple of error scenarios to avoid extra mutex calls. geom.h: Add a new, optional, providergone callback that is called when a provider is about to be deleted. geom_disk.h:Add a new d_gone() callback to the GEOM disk interface. Bump the DISK_VERSION to version 2. This probably should have been done after a couple of previous changes, especially the addition of the d_getattr() callback. geom_disk.c:Add a providergone callback for the disk class, g_disk_providergone(), that calls the user's d_gone() callback if it exists. Bump the DISK_VERSION to 2. geom_subr.c:In g_destroy_provider(), call the providergone callback if it has been provided. In g_new_geomf(), propagate the class's providergone callback to the new geom instance. disk.9: Update the disk(9) man page to include information on the new d_gone() callback, as well as the previously added d_getattr() callback, d_descr field, and HBA PCI ID fields. Ken -- Kenneth Merry k...@freebsd.org //depot/users/kenm/FreeBSD-test/share/man/man9/disk.9#1 - /usr/home/kenm/perforce4/kenm/FreeBSD-test/share/man/man9/disk.9 *** /tmp/tmp.81866.21 Wed Jun 20 22:19:20 2012 --- /usr/home/kenm/perforce4/kenm/FreeBSD-test/share/man/man9/disk.9Wed Jun 20 21:30:45 2012 *** *** 145,150 --- 145,160 .Xr dumpon 8 , this function is invoked from a very restricted system state after a kernel panic to record a copy of the system RAM to the disk. + .It Vt disk_getattr_t * Va d_getattr + Optional: if this method is provided, it gives the disk driver the + opportunity to override the default GEOM response to BIO_GETATTR requests. + This function should return -1 if the attribute is not handled, 0 if the + attribute is handled, or an errno to be passed to g_io_deliver(). + .It Vt disk_gone_t * Va d_gone + Optional: if this method is provided, it will be called after disk_gone() + is called, once GEOM has finished its cleanup process. + Once this callback is called, it is safe for the disk driver to free all of + its resources, as it will not be receiving further calls from GEOM. .El .Ss Mandatory Media Properties The following fields identify the size
