Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build
On 2011-12-07 05:56, O. Hartmann wrote:
On FreeBSD 10.0-CURRENT/amd64 I run into the error shown below when
updating the installation of the gcc46 compiler suite.
If you report port compilation errors, always use DISABLE_MAKE_JOBS,
otherwise the actual error message will drown in multithreaded spam. :)
(And even if you would save and post the full build log, it is sometimes
still impossible to see which exact command failed and why.)
That said, you are most likely running into an issue with the fix for
FreeBSD 10-CURRENT in bsd.port.mk, causing the lto-plugin stage
configure script to fail.
This is because the gcc ports unpack their source code into
${WRKDIR}/gcc-${VERSIONSTRING}, and then override WRKSRC to
${WRKDIR}/build. Since bsd.port.mk only applies the run-autotools-fixup
to ${WRKSRC}, the gcc source itself is not properly fixed up.
You can try the attached patch, which fixes this (and fixes it for all
other ports that override WKRSRC).
Index: Mk/bsd.port.mk
===
RCS file: /home/mirror/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.699
diff -u -r1.699 bsd.port.mk
--- Mk/bsd.port.mk 9 Nov 2011 08:53:12 - 1.699
+++ Mk/bsd.port.mk 7 Dec 2011 08:16:56 -
@@ -3663,7 +3663,7 @@
run-autotools-fixup:
# Work around an issue where FreeBSD 10.0 is detected as FreeBSD 1.x.
.if ${OSVERSION} = 100 !defined(WITHOUT_FBSD10_FIX)
- -@for f in `${FIND} ${WRKSRC} -type f \( -name config.libpath -o \
+ -@for f in `${FIND} ${WRKDIR} -type f \( -name config.libpath -o \
-name config.rpath -o -name configure -o -name libtool.m4 -o \
-name ltconfig -o -name libtool -o -name aclocal.m4 -o \
-name acinclude.m4 \)` ; do \
___
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
Extend search range of FreeBSD-10 libtools/configure fixup (was: Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build)
Am 07.12.2011 09:32, schrieb Dimitry Andric:
That said, you are most likely running into an issue with the fix for
FreeBSD 10-CURRENT in bsd.port.mk, causing the lto-plugin stage
configure script to fail.
This is because the gcc ports unpack their source code into
${WRKDIR}/gcc-${VERSIONSTRING}, and then override WRKSRC to
${WRKDIR}/build. Since bsd.port.mk only applies the run-autotools-fixup
to ${WRKSRC}, the gcc source itself is not properly fixed up.
You can try the attached patch, which fixes this (and fixes it for all
other ports that override WKRSRC).
I had solved a similar problem for BDB a few weeks back and made the
same modification (start searching in WRKDIR instead of in WRKSRC).
This leads to (minimally) higher run time for the fixup, but it should
make a number of ports currently broken on FBSD10 automagically build
again ...
And the pattern for libtool/configure type files should sufficiently
prevent patching of files not touched by the current invocation of find.
SO I'd vote to get that patch into SVN ...
Regards, STefan
___
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: [RFC] winbond watchdog driver for FreeBSD/i386 and FreeBSD/amd64
On Tue, Jun 28, 2011 at 03:32:41PM -0700, Xin LI wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I'd like to request for comments on the attached driver, which supports
watchdogs on several Winbond super I/O chip models and have been tested
on a few of recent Supermicro motherboards.
Is there any reason this is not yet committed? Please commit, pretty
please.
One minor problem I found is described below. Other than that it works
for me, thanks!
[...]
+static void
+winbondwd_event(void *arg, unsigned int cmd, int *error)
+{
+ struct winbondwd_softc *sc = arg;
+ unsigned char rtimeout;
+ uint64_t timeout;
+
+ if (cmd == 0)
+ winbondwd_set_timeout(sc, 0);
+ else {
+ timeout = (uint64_t)1 (cmd WD_INTERVAL);
+ if (timeout (uint64_t)0xff * 1000 * 1000 * 1000) {
+ rtimeout = timeout / (1000 * 1000 * 1000);
+ if (rtimeout == 0)
+ rtimeout = 0xff;
+ winbondwd_set_timeout(sc, rtimeout);
+ } else {
+ device_printf(sc-device,
+ Value %u too big, disabling\n, cmd WD_INTERVAL);
+ /* Proposed timeout can not be satisified */
+ winbondwd_set_timeout(sc, 0);
+ }
You should add '*error = 0;' right here. Without it we return some
random error, in my case watchdgod is able to arm the watchdog but exits
when trying to pat it, as it gets an error, which leads to a reset short
aferwards.
+ }
+}
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com
pgpOBGKr7YKAI.pgp
Description: PGP signature
Re: [RFC] winbond watchdog driver for FreeBSD/i386 and FreeBSD/amd64
On 7. Dec 2011, at 09:29 , Pawel Jakub Dawidek wrote: On Tue, Jun 28, 2011 at 03:32:41PM -0700, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I'd like to request for comments on the attached driver, which supports watchdogs on several Winbond super I/O chip models and have been tested on a few of recent Supermicro motherboards. Is there any reason this is not yet committed? Please commit, pretty please. Yes we have 2+ of them and are trying to merge. The other one sits here and allows you even longer timeouts as well as time setting the timeout independent of watchdogd in case you have two watchdogs and want to do tricks like NMI/reset with the other one... but is lacking the man page yet. I have added another one or two IC revisions I think that I had found and tested privately. http://people.freebsd.org/~bz/patch-20110710-03-wbwd.diff /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build
O. Hartmann ohart...@zedat.fu-berlin.de writes: .././../gcc-4.6-20111202/libcpp/charset.c:1371:1: error: conflicting types for 'cpp_interpret_string' cpp_interpret_string (cpp_reader *pfile, const cpp_string *from, size_t count, ^ .././../gcc-4.6-20111202/libcpp/include/cpplib.h:742:13: note: previous declaration is here extern bool cpp_interpret_string (cpp_reader *, ^ Have you built world WITH_ICONV= ? Try the 2nd patch in ports/161417. ports/163103 confirms the issue is not related to clang, nor 10-CURRENT. ___ 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: datapoints on 10G throughput with TCP ?
On 06.12.2011 22:06, Luigi Rizzo wrote: On Tue, Dec 06, 2011 at 07:40:21PM +0200, Daniel Kalchev wrote: I see significant difference between number of interrupts on the Intel and the AMD blades. When performing a test between the Intel and AMD blades, the Intel blade generates 20,000-35,000 interrupts, while the AMD blade generates under 1,000 interrupts. Even in my experiments there is a lot of instability in the results. I don't know exactly where the problem is, but the high number of read syscalls, and the huge impact of setting interrupt_rate=0 (defaults at 16us on the ixgbe) makes me think that there is something that needs investigation in the protocol stack. Of course we don't want to optimize specifically for the one-flow-at-10G case, but devising something that makes the system less affected by short timing variations, and can pass upstream interrupt mitigation delays would help. I'm not sure the variance is only coming from the network card and driver side of things. The TCP processing and interactions with scheduler and locking probably play a big role as well. There have been many changes to TCP recently and maybe an inefficiency that affects high-speed single sessions throughput has crept in. That's difficult to debug though. -- Andre ___ 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: Extend search range of FreeBSD-10 libtools/configure fixup (was: Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build)
Am 07.12.2011 09:32, schrieb Dimitry Andric:
That said, you are most likely running into an issue with the fix for
FreeBSD 10-CURRENT in bsd.port.mk, causing the lto-plugin stage
configure script to fail.
This is because the gcc ports unpack their source code into
${WRKDIR}/gcc-${VERSIONSTRING}, and then override WRKSRC to
${WRKDIR}/build. Since bsd.port.mk only applies the run-autotools-fixup
to ${WRKSRC}, the gcc source itself is not properly fixed up.
You can try the attached patch, which fixes this (and fixes it for all
other ports that override WKRSRC).
I had solved a similar problem for BDB a few weeks back and made the
same modification (start searching in WRKDIR instead of in WRKSRC).
This leads to (minimally) higher run time for the fixup, but it should
make a number of ports currently broken on FBSD10 automagically build
again ...
And the pattern for libtool/configure type files should sufficiently
prevent patching of files not touched by the current invocation of find.
SO I'd vote to get that patch into SVN ...
We've had a patch to do this, and make a few other related changes,
for about a month now. I'm not sure why it hasn't gone into
bsd.port.mk yet -- perhaps Martin had some other work to do -- but I
think that it will appear soon.
b.
___
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: virtualbox r0 memory management update
on 06/12/2011 22:22 Andriy Gapon said the following: Could you please change that line as follows? vm_page_t pPage = pPages +iPage; Additionally the patch has another bug. Here is a patch on top of the previous patch: --- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.orig2 2011-12-07 18:15:48.695189924 +0200 +++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2011-12-07 18:17:35.359192030 +0200 @@ -251,7 +251,7 @@ static int FreeBSDPhysAllocHelper(vm_obj vm_page_free(pPage); vm_page_unlock_queues(); } -VM_OBJECT_LOCK(pObject); +VM_OBJECT_UNLOCK(pObject); return VERR_NO_MEMORY; } } -- Andriy Gapon ___ 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
zfs-related(?) panic in cache_enter: wrong vnode type
(kgdb) bt
#0 doadump (textdump=1) at pcpu.h:224
#1 0x804f6d3b in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:447
#2 0x804f63e9 in panic (fmt=0x104 Address 0x104 out of bounds) at
/usr/src/sys/kern/kern_shutdown.c:635
#3 0x80585f46 in cache_enter (dvp=0xfe003d4763c0,
vp=0xfe0142517000, cnp=0xff82393b3708) at
/usr/src/sys/kern/vfs_cache.c:726
#4 0x81a90900 in zfs_lookup (dvp=0xfe003d4763c0,
nm=0xff82393b3140 .., vpp=0xff82393b36e0, cnp=0xff82393b3708,
nameiop=0, cr=0xfe0042e88100, td=0xfe000fdfa480,
flags=0) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1470
#5 0x81a91570 in zfs_freebsd_lookup (ap=0xff82393b32c0) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5858
#6 0x8073f054 in VOP_CACHEDLOOKUP_APV (vop=0x81b05a20,
a=0xff82393b32c0) at vnode_if.c:187
#7 0x80586bf4 in vfs_cache_lookup (ap=Variable ap is not available.
) at vnode_if.h:80
#8 0x80740a5c in VOP_LOOKUP_APV (vop=0x81b05a20,
a=0xff82393b33a0) at vnode_if.c:123
#9 0x8058e42c in lookup (ndp=0xff82393b36a0) at vnode_if.h:54
#10 0x8058f17e in namei (ndp=0xff82393b36a0) at
/usr/src/sys/kern/vfs_lookup.c:312
#11 0x805a890d in vn_open_cred (ndp=0xff82393b36a0,
flagp=0xff82393b3918, cmode=0, vn_open_flags=Variable vn_open_flags is not
available.
) at /usr/src/sys/kern/vfs_vnops.c:195
#12 0x80589e7e in vop_stdvptocnp (ap=Variable ap is not available.
) at /usr/src/sys/kern/vfs_default.c:774
#13 0x8073b012 in VOP_VPTOCNP_APV (vop=0x80a99140,
a=0xff82393b39b0) at vnode_if.c:3479
#14 0x80584665 in vn_vptocnp_locked (vp=0xff82393b3a50,
cred=0xfe0042e88100,
buf=0xfe000ca06000
��...,
buflen=0xff82393b3a4c) at vnode_if.h:1564
#15 0x80584bab in vn_fullpath1 (td=0xfe000fdfa480,
vp=0xfe003d4763c0, rdir=0xfe000cd4d000,
buf=0xfe000ca06000
��...,
retbuf=0xff82393b3ab0, buflen=1023) at /usr/src/sys/kern/vfs_cache.c:1218
#16 0x8058526a in kern___getcwd (td=0xfe000fdfa480, buf=0x80880a000
Address 0x80880a000 out of bounds, bufseg=UIO_USERSPACE, buflen=1024) at
/usr/src/sys/kern/vfs_cache.c:960
#17 0x805853f4 in sys___getcwd (td=Variable td is not available.
) at /usr/src/sys/kern/vfs_cache.c:934
#18 0x806d2069 in amd64_syscall (td=0xfe000fdfa480, traced=0) at
subr_syscall.c:131
#19 0x806bb4e7 in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:387
#20 0x0008031adb2c in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) fr 3
#3 0x80585f46 in cache_enter (dvp=0xfe003d4763c0,
vp=0xfe0142517000, cnp=0xff82393b3708) at
/usr/src/sys/kern/vfs_cache.c:726
726 KASSERT(vp == NULL || vp-v_type == VDIR,
(kgdb) list
721 if (dvp-v_cache_dd != NULL) {
722 CACHE_WUNLOCK();
723 cache_free(ncp);
724 return;
725 }
726 KASSERT(vp == NULL || vp-v_type == VDIR,
727 (wrong vnode type %p, vp));
728 dvp-v_cache_dd = ncp;
729 }
730
(kgdb) p *vp
$1 = {v_type = VREG, v_tag = 0x81afe449 zfs, v_op =
0x81b05a20,
v_data = 0xfe020d9a8320, v_mount = 0xfe001a283600, v_nmntvnodes =
{tqe_next = 0xfe00347c6d20,
tqe_prev = 0xfe013b0575c8}, v_un = {vu_mount = 0x0, vu_socket = 0x0,
vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0},
v_hash = 0, v_cache_src = {
lh_first = 0x0}, v_cache_dst = {tqh_first = 0xfe003dfcf690, tqh_last =
0xfe003dfcf6b0}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0,
v_clen = 0, v_lock = {lock_object = {
lo_name = 0x81afe449 zfs, lo_flags = 91947008, lo_data = 0,
lo_witness = 0xff800066e380}, lk_lock = 18446741874952610944, lk_exslpfail =
0, lk_timo = 51, lk_pri = 96},
v_interlock = {lock_object = {lo_name = 0x807e610a vnode interlock,
lo_flags = 16973824, lo_data = 0, lo_witness = 0xff8000665600}, mtx_lock =
4},
v_vnlock = 0xfe0142517098,
v_holdcnt = 2, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0,
v_freelist = {tqe_next = 0xfe00347c6d20, tqe_prev = 0xfe02110d3e30},
v_bufobj = {bo_mtx = {lock_object = {
lo_name = 0x807efdfa bufobj interlock, lo_flags = 16973824,
lo_data = 0, lo_witness = 0xff800066c300}, mtx_lock = 4}, bo_clean = {bv_hd
=
{tqh_first = 0x0,
Re: Stop scheduler on panic
2011/12/7 Andriy Gapon a...@freebsd.org:
on 07/12/2011 00:11 Attilio Rao said the following:
I'd just change this check on panicstr:
@@ -606,9 +603,13 @@ kdb_trap(int type, int code, struct trapframe *tf)
intr = intr_disable();
#ifdef SMP
- other_cpus = all_cpus;
- CPU_CLR(PCPU_GET(cpuid), other_cpus);
- stop_cpus_hard(other_cpus);
+ if (panicstr == NULL) {
+ other_cpus = all_cpus;
+ CPU_CLR(PCPU_GET(cpuid), other_cpus);
+ stop_cpus_hard(other_cpus);
+ did_stop_cpus = 1;
+ } else
+ did_stop_cpus = 0;
to be SCHEDULER_STOPPED().
Makes sense. I will do this.
If you agree I can fix the kern_mutex, kern_sx and kern_rwlock parts
and it should be done.
Since I am not very familiar with the details of that code, I can not be
against
such a proposal :-) What Kostik did seemed quite reasonable to me, but if
that
can be further improved, then I am all for it.
The following patch is a further add-on on Kostik's:
http://www.freebsd.org/~attilio/scheduler_stopped.patch
- Rework of mutex, rwlock and sxlock for a correct dealing of hard and
fast paths
- Protection of LOCK_PROFILING bits (missed also in my review)
- Protection of WITNESS_SAVE/RESTORE because of Giant handling (missed
also in my review)
- Removal of gratuitous whitelines
- Usage of SCHEDULER_STOPPED() in kdb check
What do you think about it?
I just test-compiled it with several combinations of LOCK_PROFILING
and LOCK_DEBUG, but I didn't change the bulk of it thus it should be
perfectly fine.
If you like it I'd say to go for the commit asap.
I wonder if someone tried to simulate a livelock and panic and thus
verify that stoppcbs is correctly populated as expected (to be honest,
this is one of the best features I'm interested into for this patch).
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
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
[RFC] VIA south bridge watchdog support
Hi, If someone want to look at I've added support for VIA south bridge watchdog. It has been tested on VX900 but should works with VX800, VX855, CX700. http://people.freebsd.org/~fabient/patch-watchdog-via-rev1 Fabien ___ 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: zfs-related(?) panic in cache_enter: wrong vnode type
A detail that may or may not be useful.
It seems that the panic happened when tried to resume a vim process. The
process
was suspended, its current directory and a file being edited/viewed may have
been
already removed.
on 07/12/2011 18:50 Andriy Gapon said the following:
(kgdb) bt
#0 doadump (textdump=1) at pcpu.h:224
#1 0x804f6d3b in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:447
#2 0x804f63e9 in panic (fmt=0x104 Address 0x104 out of bounds) at
/usr/src/sys/kern/kern_shutdown.c:635
#3 0x80585f46 in cache_enter (dvp=0xfe003d4763c0,
vp=0xfe0142517000, cnp=0xff82393b3708) at
/usr/src/sys/kern/vfs_cache.c:726
#4 0x81a90900 in zfs_lookup (dvp=0xfe003d4763c0,
nm=0xff82393b3140 .., vpp=0xff82393b36e0, cnp=0xff82393b3708,
nameiop=0, cr=0xfe0042e88100, td=0xfe000fdfa480,
flags=0) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1470
#5 0x81a91570 in zfs_freebsd_lookup (ap=0xff82393b32c0) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5858
#6 0x8073f054 in VOP_CACHEDLOOKUP_APV (vop=0x81b05a20,
a=0xff82393b32c0) at vnode_if.c:187
#7 0x80586bf4 in vfs_cache_lookup (ap=Variable ap is not available.
) at vnode_if.h:80
#8 0x80740a5c in VOP_LOOKUP_APV (vop=0x81b05a20,
a=0xff82393b33a0) at vnode_if.c:123
#9 0x8058e42c in lookup (ndp=0xff82393b36a0) at vnode_if.h:54
#10 0x8058f17e in namei (ndp=0xff82393b36a0) at
/usr/src/sys/kern/vfs_lookup.c:312
#11 0x805a890d in vn_open_cred (ndp=0xff82393b36a0,
flagp=0xff82393b3918, cmode=0, vn_open_flags=Variable vn_open_flags is
not
available.
) at /usr/src/sys/kern/vfs_vnops.c:195
#12 0x80589e7e in vop_stdvptocnp (ap=Variable ap is not available.
) at /usr/src/sys/kern/vfs_default.c:774
#13 0x8073b012 in VOP_VPTOCNP_APV (vop=0x80a99140,
a=0xff82393b39b0) at vnode_if.c:3479
#14 0x80584665 in vn_vptocnp_locked (vp=0xff82393b3a50,
cred=0xfe0042e88100,
buf=0xfe000ca06000
��...,
buflen=0xff82393b3a4c) at vnode_if.h:1564
#15 0x80584bab in vn_fullpath1 (td=0xfe000fdfa480,
vp=0xfe003d4763c0, rdir=0xfe000cd4d000,
buf=0xfe000ca06000
��...,
retbuf=0xff82393b3ab0, buflen=1023) at /usr/src/sys/kern/vfs_cache.c:1218
#16 0x8058526a in kern___getcwd (td=0xfe000fdfa480,
buf=0x80880a000
Address 0x80880a000 out of bounds, bufseg=UIO_USERSPACE, buflen=1024) at
/usr/src/sys/kern/vfs_cache.c:960
#17 0x805853f4 in sys___getcwd (td=Variable td is not available.
) at /usr/src/sys/kern/vfs_cache.c:934
#18 0x806d2069 in amd64_syscall (td=0xfe000fdfa480, traced=0) at
subr_syscall.c:131
#19 0x806bb4e7 in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:387
#20 0x0008031adb2c in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) fr 3
#3 0x80585f46 in cache_enter (dvp=0xfe003d4763c0,
vp=0xfe0142517000, cnp=0xff82393b3708) at
/usr/src/sys/kern/vfs_cache.c:726
726 KASSERT(vp == NULL || vp-v_type == VDIR,
(kgdb) list
721 if (dvp-v_cache_dd != NULL) {
722 CACHE_WUNLOCK();
723 cache_free(ncp);
724 return;
725 }
726 KASSERT(vp == NULL || vp-v_type == VDIR,
727 (wrong vnode type %p, vp));
728 dvp-v_cache_dd = ncp;
729 }
730
(kgdb) p *vp
$1 = {v_type = VREG, v_tag = 0x81afe449 zfs, v_op =
0x81b05a20,
v_data = 0xfe020d9a8320, v_mount = 0xfe001a283600, v_nmntvnodes =
{tqe_next = 0xfe00347c6d20,
tqe_prev = 0xfe013b0575c8}, v_un = {vu_mount = 0x0, vu_socket = 0x0,
vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev =
0x0},
v_hash = 0, v_cache_src = {
lh_first = 0x0}, v_cache_dst = {tqh_first = 0xfe003dfcf690, tqh_last =
0xfe003dfcf6b0}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0,
v_clen = 0, v_lock = {lock_object = {
lo_name = 0x81afe449 zfs, lo_flags = 91947008, lo_data = 0,
lo_witness = 0xff800066e380}, lk_lock = 18446741874952610944,
lk_exslpfail =
0, lk_timo = 51, lk_pri = 96},
v_interlock = {lock_object = {lo_name = 0x807e610a vnode
interlock,
lo_flags = 16973824, lo_data = 0, lo_witness = 0xff8000665600}, mtx_lock
= 4},
v_vnlock = 0xfe0142517098,
quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ?
On Wed, Dec 07, 2011 at 11:59:43AM +0100, Andre Oppermann wrote: On 06.12.2011 22:06, Luigi Rizzo wrote: ... Even in my experiments there is a lot of instability in the results. I don't know exactly where the problem is, but the high number of read syscalls, and the huge impact of setting interrupt_rate=0 (defaults at 16us on the ixgbe) makes me think that there is something that needs investigation in the protocol stack. Of course we don't want to optimize specifically for the one-flow-at-10G case, but devising something that makes the system less affected by short timing variations, and can pass upstream interrupt mitigation delays would help. I'm not sure the variance is only coming from the network card and driver side of things. The TCP processing and interactions with scheduler and locking probably play a big role as well. There have been many changes to TCP recently and maybe an inefficiency that affects high-speed single sessions throughput has crept in. That's difficult to debug though. I ran a bunch of tests on the ixgbe (82599) using RELENG_8 (which seems slightly faster than HEAD) using MTU=1500 and various combinations of card capabilities (hwcsum,tso,lro), different window sizes and interrupt mitigation configurations. default latency is 16us, l=0 means no interrupt mitigation. lro is the software implementation of lro (tcp_lro.c) hwlro is the hardware one (on 82599). Using a window of 100 Kbytes seems to give the best results. Summary: - with default interrupt mitigation, the fastest configuration is with checksums enabled on both sender and receiver, lro enabled on the receiver. This gets about 8.0 Gbit/s - lro is especially good because it packs data packets together, passing mitigation upstream and removing duplicate work in the ip and tcp stack. - disabling LRO on the receiver brings performance to 6.5 Gbit/s. Also it increases the CPU load (also in userspace). - disabling checksums on the sender reduces transmit speed to 5.5 Gbit/s - checksums disabled on both sides (and no LRO on the receiver) go down to 4.8 Gbit/s - I could not try the receive side without checksum but with lro - with default interrupt mitigation, setting both HWCSUM and TSO on the sender is really disruptive. Depending on lro settings on the receiver i get 1.5 to 3.2 Gbit/s and huge variance - Using both hwcsum and tso seems to work fine if you disable interrupt mitigation (reaching a peak of 9.4 Gbit/s). - enabling software lro on the transmit side actually slows down the throughput (4-5Gbit/s instead of 8.0). I am not sure why (perhaps acks are delayed too much) ? Adding a couple of lines in tcp_lro to reject pure acks seems to have much better effect. The tcp_lro patch below might actually be useful also for other cards. --- tcp_lro.c (revision 228284) +++ tcp_lro.c (working copy) @@ -245,6 +250,8 @@ ip_len = ntohs(ip-ip_len); tcp_data_len = ip_len - (tcp-th_off 2) - sizeof (*ip); + if (tcp_data_len == 0) + return -1; /* not on ack */ /* cheers luigi ___ 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: zfs-related(?) panic in cache_enter: wrong vnode type
on 07/12/2011 19:33 Andriy Gapon said the following:
A detail that may or may not be useful.
It seems that the panic happened when tried to resume a vim process. The
process
was suspended, its current directory and a file being edited/viewed may have
been
already removed.
And another data point:
(kgdb) p ((znode_t *)dvp-v_data)-z_unlinked
Perhaps lookup in unlinked directories should just fail?
I am not sufficiently familiar with VFS, so just guessing.
on 07/12/2011 18:50 Andriy Gapon said the following:
(kgdb) bt
#0 doadump (textdump=1) at pcpu.h:224
#1 0x804f6d3b in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:447
#2 0x804f63e9 in panic (fmt=0x104 Address 0x104 out of bounds) at
/usr/src/sys/kern/kern_shutdown.c:635
#3 0x80585f46 in cache_enter (dvp=0xfe003d4763c0,
vp=0xfe0142517000, cnp=0xff82393b3708) at
/usr/src/sys/kern/vfs_cache.c:726
#4 0x81a90900 in zfs_lookup (dvp=0xfe003d4763c0,
nm=0xff82393b3140 .., vpp=0xff82393b36e0, cnp=0xff82393b3708,
nameiop=0, cr=0xfe0042e88100, td=0xfe000fdfa480,
flags=0) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1470
#5 0x81a91570 in zfs_freebsd_lookup (ap=0xff82393b32c0) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5858
#6 0x8073f054 in VOP_CACHEDLOOKUP_APV (vop=0x81b05a20,
a=0xff82393b32c0) at vnode_if.c:187
#7 0x80586bf4 in vfs_cache_lookup (ap=Variable ap is not
available.
) at vnode_if.h:80
#8 0x80740a5c in VOP_LOOKUP_APV (vop=0x81b05a20,
a=0xff82393b33a0) at vnode_if.c:123
#9 0x8058e42c in lookup (ndp=0xff82393b36a0) at vnode_if.h:54
#10 0x8058f17e in namei (ndp=0xff82393b36a0) at
/usr/src/sys/kern/vfs_lookup.c:312
#11 0x805a890d in vn_open_cred (ndp=0xff82393b36a0,
flagp=0xff82393b3918, cmode=0, vn_open_flags=Variable vn_open_flags is
not
available.
) at /usr/src/sys/kern/vfs_vnops.c:195
#12 0x80589e7e in vop_stdvptocnp (ap=Variable ap is not available.
) at /usr/src/sys/kern/vfs_default.c:774
#13 0x8073b012 in VOP_VPTOCNP_APV (vop=0x80a99140,
a=0xff82393b39b0) at vnode_if.c:3479
#14 0x80584665 in vn_vptocnp_locked (vp=0xff82393b3a50,
cred=0xfe0042e88100,
buf=0xfe000ca06000
��...,
buflen=0xff82393b3a4c) at vnode_if.h:1564
#15 0x80584bab in vn_fullpath1 (td=0xfe000fdfa480,
vp=0xfe003d4763c0, rdir=0xfe000cd4d000,
buf=0xfe000ca06000
��...,
retbuf=0xff82393b3ab0, buflen=1023) at /usr/src/sys/kern/vfs_cache.c:1218
#16 0x8058526a in kern___getcwd (td=0xfe000fdfa480,
buf=0x80880a000
Address 0x80880a000 out of bounds, bufseg=UIO_USERSPACE, buflen=1024) at
/usr/src/sys/kern/vfs_cache.c:960
#17 0x805853f4 in sys___getcwd (td=Variable td is not available.
) at /usr/src/sys/kern/vfs_cache.c:934
#18 0x806d2069 in amd64_syscall (td=0xfe000fdfa480, traced=0) at
subr_syscall.c:131
#19 0x806bb4e7 in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:387
#20 0x0008031adb2c in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) fr 3
#3 0x80585f46 in cache_enter (dvp=0xfe003d4763c0,
vp=0xfe0142517000, cnp=0xff82393b3708) at
/usr/src/sys/kern/vfs_cache.c:726
726 KASSERT(vp == NULL || vp-v_type == VDIR,
(kgdb) list
721 if (dvp-v_cache_dd != NULL) {
722 CACHE_WUNLOCK();
723 cache_free(ncp);
724 return;
725 }
726 KASSERT(vp == NULL || vp-v_type == VDIR,
727 (wrong vnode type %p, vp));
728 dvp-v_cache_dd = ncp;
729 }
730
(kgdb) p *vp
$1 = {v_type = VREG, v_tag = 0x81afe449 zfs, v_op =
0x81b05a20,
v_data = 0xfe020d9a8320, v_mount = 0xfe001a283600, v_nmntvnodes =
{tqe_next = 0xfe00347c6d20,
tqe_prev = 0xfe013b0575c8}, v_un = {vu_mount = 0x0, vu_socket = 0x0,
vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev =
0x0},
v_hash = 0, v_cache_src = {
lh_first = 0x0}, v_cache_dst = {tqh_first = 0xfe003dfcf690, tqh_last
=
0xfe003dfcf6b0}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw =
0,
v_clen = 0, v_lock = {lock_object = {
lo_name = 0x81afe449 zfs, lo_flags = 91947008, lo_data = 0,
lo_witness = 0xff800066e380}, lk_lock = 18446741874952610944,
Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ?
On Dec 7, 2011, at 8:08 PM, Luigi Rizzo wrote: Summary: - with default interrupt mitigation, the fastest configuration is with checksums enabled on both sender and receiver, lro enabled on the receiver. This gets about 8.0 Gbit/s I do not observe this. With defaults: # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.053 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1857.4978 MB in 5.02 real seconds = 378856.02 KB/sec = 3103.5885 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 29720 I/O calls, msec/call = 0.17, calls/sec = 5919.63 nuttcp-t: 0.0user 2.5sys 0:05real 52% 115i+1544d 630maxrss 0+2pf 107264+1csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1857.4978 MB in 5.15 real seconds = 369617.39 KB/sec = 3027.9057 Mbps nuttcp-r: 543991 I/O calls, msec/call = 0.01, calls/sec = 105709.95 nuttcp-r: 0.1user 4.1sys 0:05real 83% 110i+1482d 618maxrss 0+15pf 158432+0csw On receiver: ifconfig ix1 lro # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.068 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1673.3125 MB in 5.02 real seconds = 341312.36 KB/sec = 2796.0308 Mbps nuttcp-t: host-retrans = 1 nuttcp-t: 26773 I/O calls, msec/call = 0.19, calls/sec = 5333.01 nuttcp-t: 0.0user 1.0sys 0:05real 21% 113i+1518d 630maxrss 0+2pf 12772+1csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1673.3125 MB in 5.15 real seconds = 332975.19 KB/sec = 2727.7327 Mbps nuttcp-r: 106268 I/O calls, msec/call = 0.05, calls/sec = 20650.82 nuttcp-r: 0.0user 1.3sys 0:05real 28% 101i+1354d 618maxrss 0+15pf 64567+0csw On sender: ifconfig ix1 lro (now both receiver and sender have LRO enabled) # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.063 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1611.7805 MB in 5.02 real seconds = 328716.18 KB/sec = 2692.8430 Mbps nuttcp-t: host-retrans = 1 nuttcp-t: 25789 I/O calls, msec/call = 0.20, calls/sec = 5136.29 nuttcp-t: 0.0user 1.0sys 0:05real 21% 109i+1465d 630maxrss 0+2pf 12697+0csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1611.7805 MB in 5.15 real seconds = 320694.82 KB/sec = 2627.1319 Mbps nuttcp-r: 104346 I/O calls, msec/call = 0.05, calls/sec = 20275.05 nuttcp-r: 0.0user 1.3sys 0:05real 27% 113i+1516d 618maxrss 0+15pf 63510+0csw remove LRO from receiver (only sender has LRO): # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.065 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1884.8702 MB in 5.02 real seconds = 384464.57 KB/sec = 3149.5338 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 30158 I/O calls, msec/call = 0.17, calls/sec = 6007.27 nuttcp-t: 0.0user 2.7sys 0:05real 55% 104i+1403d 630maxrss 0+2pf 106046+0csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1884.8702 MB in 5.15 real seconds = 375093.52 KB/sec = 3072.7661 Mbps nuttcp-r: 540237 I/O calls, msec/call = 0.01, calls/sec = 104988.68 nuttcp-r: 0.1user 4.2sys 0:05real 84% 110i+1483d 618maxrss 0+15pf 156340+0csw Strange enough, setting hw.ixgbe.max_interrupt_rate=0 does not have any effect.. Daniel ___ 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: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ?
On Wed, Dec 07, 2011 at 09:58:31PM +0200, Daniel Kalchev wrote: On Dec 7, 2011, at 8:08 PM, Luigi Rizzo wrote: Summary: - with default interrupt mitigation, the fastest configuration is with checksums enabled on both sender and receiver, lro enabled on the receiver. This gets about 8.0 Gbit/s I do not observe this. With defaults: ... Sorry, forgot to mention that the above is with TSO DISABLED (which is not the default). TSO seems to have a very bad interaction with HWCSUM and non-zero mitigation. also remember that hw.ixgbe.max_interrupt_rate has only effect at module load -- i.e. you set it with the bootloader, or with kenv before loading the module. Please retry the measurements disabling tso (on both sides, but it really matters only on the sender). Also, LRO requires HWCSUM. cheers luigi # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.053 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1857.4978 MB in 5.02 real seconds = 378856.02 KB/sec = 3103.5885 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 29720 I/O calls, msec/call = 0.17, calls/sec = 5919.63 nuttcp-t: 0.0user 2.5sys 0:05real 52% 115i+1544d 630maxrss 0+2pf 107264+1csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1857.4978 MB in 5.15 real seconds = 369617.39 KB/sec = 3027.9057 Mbps nuttcp-r: 543991 I/O calls, msec/call = 0.01, calls/sec = 105709.95 nuttcp-r: 0.1user 4.1sys 0:05real 83% 110i+1482d 618maxrss 0+15pf 158432+0csw On receiver: ifconfig ix1 lro # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.068 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1673.3125 MB in 5.02 real seconds = 341312.36 KB/sec = 2796.0308 Mbps nuttcp-t: host-retrans = 1 nuttcp-t: 26773 I/O calls, msec/call = 0.19, calls/sec = 5333.01 nuttcp-t: 0.0user 1.0sys 0:05real 21% 113i+1518d 630maxrss 0+2pf 12772+1csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1673.3125 MB in 5.15 real seconds = 332975.19 KB/sec = 2727.7327 Mbps nuttcp-r: 106268 I/O calls, msec/call = 0.05, calls/sec = 20650.82 nuttcp-r: 0.0user 1.3sys 0:05real 28% 101i+1354d 618maxrss 0+15pf 64567+0csw On sender: ifconfig ix1 lro (now both receiver and sender have LRO enabled) # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.063 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1611.7805 MB in 5.02 real seconds = 328716.18 KB/sec = 2692.8430 Mbps nuttcp-t: host-retrans = 1 nuttcp-t: 25789 I/O calls, msec/call = 0.20, calls/sec = 5136.29 nuttcp-t: 0.0user 1.0sys 0:05real 21% 109i+1465d 630maxrss 0+2pf 12697+0csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1611.7805 MB in 5.15 real seconds = 320694.82 KB/sec = 2627.1319 Mbps nuttcp-r: 104346 I/O calls, msec/call = 0.05, calls/sec = 20275.05 nuttcp-r: 0.0user 1.3sys 0:05real 27% 113i+1516d 618maxrss 0+15pf 63510+0csw remove LRO from receiver (only sender has LRO): # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.065 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1884.8702 MB in 5.02 real seconds = 384464.57 KB/sec = 3149.5338 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 30158 I/O calls, msec/call = 0.17, calls/sec = 6007.27 nuttcp-t: 0.0user 2.7sys 0:05real 55% 104i+1403d 630maxrss 0+2pf 106046+0csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1884.8702 MB in 5.15 real seconds = 375093.52 KB/sec = 3072.7661 Mbps nuttcp-r: 540237 I/O calls, msec/call = 0.01, calls/sec = 104988.68 nuttcp-r: 0.1user 4.2sys 0:05real 84% 110i+1483d 618maxrss 0+15pf 156340+0csw Strange enough, setting hw.ixgbe.max_interrupt_rate=0 does not have any effect.. Daniel ___
Burning CDs and DVDs on SATA drive in FreeBSD 9.0
I can't get cdrtools (cdrecord or readcd) to work on FreeBSD 9.0-RC2, and now I see RC3 is available. I tried options ATA_CAM in kernel config, removing device atapicam, but still readcd -scanbus or cdrecord -scanbus refuses to work, running as root. camcontrol devlist shows my DVD drive, and I am able to mount and read /dev/cd0. Is cdrtools buggy, or maybe the FreeBSD port is buggy? I see from the Makefile that sysutils/cdrdao is broken on FreeBSD 9.x, does not link. I downloaded cdrkit-1.1.11.tar.gz so as to extract and have a look at it, and possibly build it on my own, outside the ports system. I see the version in ports system is 1.1.9, maybe 1.1.11 could do better? Maybe the FreeBSD developers were too hasty to deprecate burncd? Tom ___ 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: Burning CDs and DVDs on SATA drive in FreeBSD 9.0
On 08/12/2011, at 10:55, Thomas Mueller wrote: I can't get cdrtools (cdrecord or readcd) to work on FreeBSD 9.0-RC2, and now I see RC3 is available. I tried options ATA_CAM in kernel config, removing device atapicam, but still readcd -scanbus or cdrecord -scanbus refuses to work, running as root. Define refuses to work.. I have an oldish 9.0-CURRENT which works with cdrecord.. [titus 1:16] ~ cdrecord -scanbus Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 J?rg Schilling Using libscg version 'schily-0.9'. scsibus1: 1,0,0 100) 'PIONEER ' 'DVD-RW DVR-112D' '1.09' Removable CD-ROM 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) * 1,6,0 106) * 1,7,0 107) * I have a newer system but it doesn't have a DVD drive in it, however cdrecord does seem to work (it sees the AHCI connected disks).. mdtest:~cdrecord -scanbus Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 J?rg Schilling Using libscg version 'schily-0.9'. scsibus0: 0,0,0 0) '' '' '' NON CCS Disk 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * mdtest:~camcontrol devlist WDC WD5002ABYS-02B1B0 02.03B03 at scbus0 target 0 lun 0 (pass0,ada0) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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
Burning CDs and DVDs on SATA drive in FreeBSD 9.0
In the past, I've used the ftp cdrtools pkg (made from the port of course) and it failed to work. It's a popular tool so my machine was probably out of sync. Same with burncd. However, compiling the current cdrtools source worked fine. So I'd try that first, compare, and send up a bug if need be. Try to skip the scan by specifying the BTL or devpath on the command line. The scan is a big part of the port and might have breakage, at least for the app below. Also, if you're doing audio, someone over on ports has said they're doing an update to cdparanoia. It's minor, but useful for that crowd. makefs and burncd are part of the base, at least on RELENG_8. And makefs is used in the official releases. So they should just work. Good luck. ___ 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: CVS removal from the base
On 12/3/11 5:45 PM, Garrett Cooper wrote: Just to back up that point: until CVS is completely unused by releng (docs, ports are still done via CVS), Ah - I am indeed mistaken. Not all that surprising. it really shouldn't be removed from base (no matter how broken or undeveloped it is). I agree. Please forgive the noise coming from my (grey) bikeshed. -- Sean M. Collins ___ 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
