BXR.SU, Super User's BSD Cross Reference w/ OpenGrok, publicly private beta
Dear FreeBSD-{current,hackers}@,
It is my great pleasure to announce the immediate availability of a
publicly private IPv6-only beta test of BXR.SU -- Super User's BSD Cross
Reference.
BXR.SU is based on an OpenGrok fork, but it's more than just OpenGrok.
We've fixed a number of annoyances, eliminated features that just never
worked right from the outright, and provided integration with tools like
CVSweb (including awesome mirrors like allbsd.org), FreeBSD's ViewVC
(SVN), as well as Gitweb from git.freebsd.your.org, plus a tad of other
improvements, including a complete rewrite of an mdoc parser. Last, but
definitely not least, is an extensive set of nginx rewrite rules that
makes it a breeze to use BXR.SU as a deterministic URL compactor for
referencing BSD source code.
What's up with the publicly private beta test?
We're launching today in a publicly private beta. Participation in the
beta is invitation-only; everyone with IPv6 is invited.
We're cooperating with ISPs around the world, and in order to be able to
access BXR.SU during this beta phase, you must have a special token,
also known as a publicly routable IPv6-address, with proper
IPv6-connectivity and upstream peering. If you don't have IPv6 yet, but
want to participate in this beta test ASAP, then ask your ISP for IPv6
ASAP! Else, if your ISP is not part of our beta rollout, you could try
something like tunnelbroker.net from he.net.
What's the release schedule?
BXR.SU is available through IPv6 today, 2013-04-01. It is currently an
IPv6-only site, with an IPv6-only glue, too.
As an IPv6-only site, we hereby declare that 2013-04-04 is an IPv4 day.
On April 4, we will temporarily enable IPv4 connectivity, for one day,
to test the water. (We've heard that IPv4 has some connectivity issues
related to NAT, double-NAT, carrier-grade NAT and NAT64, and some small
percentage of users (but significant in absolute terms) might not be
able to access the site if an A record is published, due to the
plentiful of misconfigurations out there; so, we want to take things
slow, and ensure our users don't suffer from any inferior connectivity.)
If things do go well (we expect IPv6/IPv4-related improvements as time
goes by), we will permanently publish an A record for BXR.SU on 2013-04-14.
IPv4 glue records will be published shortly thereafter, on 2013-04-24
(we don't do this today, because we're afraid that the nameservers of
some ISPs are not configured correctly, and our IPv6 users won't be able
to access our site otherwise, so, we think it's a good idea to take
things slow and in steps).
But why another OpenGrok?
Over the years, there have been a number of OpenGrok installations that
have made it possible to study and grok BSD code, for which we are very
thankful to their maintainers. However, as a general rule, none of them
have been inclusive of all BSD flavours, all of them have had rather
long and hard-to-remember URLs, which also didn't really look permanent
at all, and, unfortunately, many of them no longer exist today, or some
new uber-inclusive services like code.metager.de have recently
flourished, with an astounding 8 second (yes, eight second) delay for
satisfying any single search query (hot queries are returned in as
little as just under 4 seconds by metager, yet everything is nonetheless
buffered, so, you get no rendering at all for those whole 4 or 8
seconds). So, we thought this had to change.
So, what's the deal?
It's simple.
Say, someone doesn't know who PHK is. You can point them to:
http://bxr.su/s?q=phk
Want to see if DragonFly keeps queue.h in sync? Take a look at:
http://bxr.su/d/sys/sys/queue.h
Want to look at FreeBSD's queue.h, to manually compare? Just change the
"d" from "/d/" (or select and replace the whole world "DragonFly" from
"/DragonFly/") to "f", and you're in FreeBSD:
http://bxr.su/f/sys/sys/queue.h
Too many /sys/sys/? We've still got you covered, thanks to nginx:
http://bxr.su/o/queue.h
Anyone uses TAILQ_SWAP? Is that a new thing? Check it out:
http://bxr.su/search?q=TAILQ_SWAP
Any mentions of "OpenBSD" or "NetBSD" in FreeBSD and DragonFly?
http://bxr.su/f,d/s?q=OpenBSD+OR+NetBSD
Who's this guy writing this email anyway? Is he BXR'able?
http://bxr.su/s?q=%22Constantine%20A.%20Murenin%22%20OR%20cnst
Etc.
Just how fast is BXR.SU?
We expect that most search requests should be fulfilled (search page
results generated) in well under 100ms. In my tests, and according to
OpenGrok metrics at the bottom of each search page, most search pages
are generated in about 30 to 50ms, so, it does seem like there's some
room to spare. In addition, of course we use nginx, so, once generated
at 40ms, a page should be available immediately in no time should a
subsequent identical request come along within a couple of seconds or so.
How does it compare with fxr.watson.org?
+ we're based on OpenGrok, instead
BXR.SU, Super User's BSD Cross Reference w/ OpenGrok, publicly private beta
Dear FreeBSD-{current,hackers}@,
It is my great pleasure to announce the immediate availability of a
publicly private IPv6-only beta test of BXR.SU -- Super User's BSD Cross
Reference.
BXR.SU is based on an OpenGrok fork, but it's more than just OpenGrok.
We've fixed a number of annoyances, eliminated features that just never
worked right from the outright, and provided integration with tools like
CVSweb (including awesome mirrors like allbsd.org), FreeBSD's ViewVC
(SVN), as well as Gitweb from git.freebsd.your.org, plus a tad of other
improvements, including a complete rewrite of an mdoc parser. Last, but
definitely not least, is an extensive set of nginx rewrite rules that
makes it a breeze to use BXR.SU as a deterministic URL compactor for
referencing BSD source code.
What's up with the publicly private beta test?
We're launching today in a publicly private beta. Participation in the
beta is invitation-only; everyone with IPv6 is invited.
We're cooperating with ISPs around the world, and in order to be able to
access BXR.SU during this beta phase, you must have a special token,
also known as a publicly routable IPv6-address, with proper
IPv6-connectivity and upstream peering. If you don't have IPv6 yet, but
want to participate in this beta test ASAP, then ask your ISP for IPv6
ASAP! Else, if your ISP is not part of our beta rollout, you could try
something like tunnelbroker.net from he.net.
What's the release schedule?
BXR.SU is available through IPv6 today, 2013-04-01. It is currently an
IPv6-only site, with an IPv6-only glue, too.
As an IPv6-only site, we hereby declare that 2013-04-04 is an IPv4 day.
On April 4, we will temporarily enable IPv4 connectivity, for one day,
to test the water. (We've heard that IPv4 has some connectivity issues
related to NAT, double-NAT, carrier-grade NAT and NAT64, and some small
percentage of users (but significant in absolute terms) might not be
able to access the site if an A record is published, due to the
plentiful of misconfigurations out there; so, we want to take things
slow, and ensure our users don't suffer from any inferior connectivity.)
If things do go well (we expect IPv6/IPv4-related improvements as time
goes by), we will permanently publish an A record for BXR.SU on 2013-04-14.
IPv4 glue records will be published shortly thereafter, on 2013-04-24
(we don't do this today, because we're afraid that the nameservers of
some ISPs are not configured correctly, and our IPv6 users won't be able
to access our site otherwise, so, we think it's a good idea to take
things slow and in steps).
But why another OpenGrok?
Over the years, there have been a number of OpenGrok installations that
have made it possible to study and grok BSD code, for which we are very
thankful to their maintainers. However, as a general rule, none of them
have been inclusive of all BSD flavours, all of them have had rather
long and hard-to-remember URLs, which also didn't really look permanent
at all, and, unfortunately, many of them no longer exist today, or some
new uber-inclusive services like code.metager.de have recently
flourished, with an astounding 8 second (yes, eight second) delay for
satisfying any single search query (hot queries are returned in as
little as just under 4 seconds by metager, yet everything is nonetheless
buffered, so, you get no rendering at all for those whole 4 or 8
seconds). So, we thought this had to change.
So, what's the deal?
It's simple.
Say, someone doesn't know who PHK is. You can point them to:
http://bxr.su/s?q=phk
Want to see if DragonFly keeps queue.h in sync? Take a look at:
http://bxr.su/d/sys/sys/queue.h
Want to look at FreeBSD's queue.h, to manually compare? Just change the
"d" from "/d/" (or select and replace the whole world "DragonFly" from
"/DragonFly/") to "f", and you're in FreeBSD:
http://bxr.su/f/sys/sys/queue.h
Too many /sys/sys/? We've still got you covered, thanks to nginx:
http://bxr.su/o/queue.h
Anyone uses TAILQ_SWAP? Is that a new thing? Check it out:
http://bxr.su/search?q=TAILQ_SWAP
Any mentions of "OpenBSD" or "NetBSD" in FreeBSD and DragonFly?
http://bxr.su/f,d/s?q=OpenBSD+OR+NetBSD
Who's this guy writing this email anyway? Is he BXR'able?
http://bxr.su/s?q=%22Constantine%20A.%20Murenin%22%20OR%20cnst
Etc.
Just how fast is BXR.SU?
We expect that most search requests should be fulfilled (search page
results generated) in well under 100ms. In my tests, and according to
OpenGrok metrics at the bottom of each search page, most search pages
are generated in about 30 to 50ms, so, it does seem like there's some
room to spare. In addition, of course we use nginx, so, once generated
at 40ms, a page should be available immediately in no time should a
subsequent identical request come along within a couple of seconds or so.
How does it compare with fxr.watson.org?
+ we're based on OpenGrok, instead
Re: ports/177488: qemu-1.4
2013-03-30 10:23, Juergen Lock wrote: disable some unneeded function, and make qemu 1.4 compilable on FreeBSD 9.1 I think you are building qemu git head as the hexdump function at least isn't in 1.4.0? Anyway I have meanwhile updated the qemu-devel port to 1.4.0 with some similar patches to yours and (among other things) preliminary bsd-user improvements mostly by ssson and cognet, will leave the PR open for when I need the hexdump patch for a future update. Doesn't build WITHOUT_CURL: block/qcow.o: In function `encrypt_sectors': /tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow.c:250: undefined reference to `AES_cbc_encrypt' block/qcow2-cluster.o: In function `qcow2_encrypt_sectors': /tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow2-cluster.c:309: undefined reference to `AES_cbc_encrypt' gmake: *** [qemu-nbd] Помилка 1 gmake: *** Очікування завершення завдань... block/qcow.o: In function `encrypt_sectors': /tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow.c:250: undefined reference to `AES_cbc_encrypt' block/qcow2-cluster.o: In function `qcow2_encrypt_sectors': /tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow2-cluster.c:309: undefined reference to `AES_cbc_encrypt' -- Sphinx of black quartz, judge my vow. ___ 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: Any objections/comments on axing out old ATA stack?
On Sun, Mar 31, 2013 at 03:02:09PM -0600, Scott Long wrote: > > On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz wrote: > > > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > >> Hi. > >> > >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > >> stack, using only some controller drivers of old ata(4) by having > >> `options ATA_CAM` enabled in all kernels by default. I have a wish to > >> drop non-ATA_CAM ata(4) code, unused since that time from the head > >> branch to allow further ATA code cleanup. > >> > >> Does any one here still uses legacy ATA stack (kernel explicitly built > >> without `options ATA_CAM`) for some reason, for example as workaround > >> for some regression? Does anybody have good ideas why we should not drop > >> it now? > > > > Hello, > > > > At my previous job we had troubles with NCQ on some controllers. It caused > > failures and silent data corruption. As old ata code didn't use NCQ we just > > used > > it. > > > > I reported some of the problems on 8.2[1] but the problem existed with 8.3. > > > > I no longer have access to those systems, so i don't know if the problem > > still exists or have been fixed on newer versions. > > > > Regards. > > Victor. > > > So what I hear you and Matthias saying, I believe, is that it should be > easier to > force disks to fall back to non-NCQ mode, and/or have a more responsive > black-list for problematic controllers. Would this help the situation? It's > hard to > justify holding back overall forward progress because of some bad controllers; > we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x, > enough to make up a sizable percentage of the internet's traffic, and we see > no > problems. How can we move forward but also take care of you guys with > problematic hardware? > > Scott Being able to configure quirks from loader.conf for disks AND controllers would be great and is not hard to do. If you want i can do a patch in two weeks and send it to you. That way it's easy to test disabling NCQ and/or other things in case of hitting a bug. Also being able to modify the configuration without a kernel recompile would be a big improvement because we could still use freebsd-update to keep systems updated. Anyway, my comment was not against dropping old ata code, but more on the "comments on regresssions on the new one". Regards. Victor. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ 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"
panic: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625
I got the following panic on 10.0-CURRENT from two days ago
while receiving an incremental snapshot to a certain pool:
(kgdb) where
#0 doadump (textdump=0) at pcpu.h:229
#1 0x8031a3ce in db_dump (dummy=, dummy2=0,
dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543
#2 0x80319eca in db_command (last_cmdp=,
cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:449
#3 0x80319c82 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:502
#4 0x8031c5d0 in db_trap (type=, code=0) at
/usr/src/sys/ddb/db_main.c:231
#5 0x805d0da3 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:654
#6 0x8087fdc3 in trap (frame=0xff80dc9d6520) at
/usr/src/sys/amd64/amd64/trap.c:579
#7 0x80869cb2 in calltrap () at exception.S:228
#8 0x805d058e in kdb_enter (why=0x80a47e7a "panic", msg=) at cpufunc.h:63
#9 0x80599216 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:747
#10 0x8130323f in assfail3 (a=, lv=, op=, rv=, f=, l=)
at
/usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:89
#11 0x8117924e in zfs_space_delta_cb (bonustype=,
data=0xff8015eeb8c0, userp=0xfe004261c640, groupp=0xfe004261c648)
at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:625
#12 0x8110003b in dmu_objset_userquota_get_ids (dn=0xfe004261c358,
before=0, tx=) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249
#13 0x811071b6 in dnode_sync (dn=0xfe004261c358,
tx=0xfe00186e1300) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c:554
#14 0x810ff98b in dmu_objset_sync_dnodes (list=0xfe00691a5250,
newlist=, tx=)
at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:910
#15 0x810ff825 in dmu_objset_sync (os=0xfe00691a5000, pio=, tx=0xfe00186e1300)
at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1027
#16 0x8110cb0d in dsl_dataset_sync (ds=0xfe001f3d0c00, zio=0x780,
tx=0xfe00186e1300) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:1411
#17 0x8111399a in dsl_pool_sync (dp=0xfe0069ec4000, txg=) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:409
#18 0x8112f0ee in spa_sync (spa=0xfe0050f0, txg=3292) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6328
#19 0x81137c45 in txg_sync_thread (arg=0xfe0069ec4000) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:493
#20 0x80569c1a in fork_exit (callout=0x811378d0
, arg=0xfe0069ec4000, frame=0xff80dc9d6c00) at
/usr/src/sys/kern/kern_fork.c:991
#21 0x8086a1ee in fork_trampoline () at exception.S:602
#22 0x in ?? ()
Current language: auto; currently minimal
(kgdb) f 12
#12 0x8110003b in dmu_objset_userquota_get_ids (dn=0xfe004261c358,
before=0, tx=) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249
1249error = used_cbs[os->os_phys->os_type](dn->dn_bonustype, data,
(kgdb) p *dn
$1 = {dn_struct_rwlock = {lock_object = {lo_name = 0x811da0a9
"dn->dn_struct_rwlock", lo_flags = 4096, lo_data = 0, lo_witness = 0x0},
sx_lock = 1}, dn_link = {list_next = 0xfe0042629020,
list_prev = 0xfe00691a5360}, dn_objset = 0xfe00691a5000, dn_object
= 55652, dn_dbuf = 0xfe00427ad0e0, dn_handle = 0xfe0069f70128, dn_phys
= 0xff8015eeb800,
dn_type = DMU_OT_PLAIN_FILE_CONTENTS, dn_bonuslen = 192, dn_bonustype = 44
',', dn_nblkptr = 1 '\001', dn_checksum = 0 '\0', dn_compress = 0 '\0',
dn_nlevels = 1 '\001', dn_indblkshift = 14 '\016',
dn_datablkshift = 0 '\0', dn_moved = 0 '\0', dn_datablkszsec = 10,
dn_datablksz = 5120, dn_maxblkid = 0, dn_next_nblkptr = "\000\000\000",
dn_next_nlevels = "\000\000\000",
dn_next_indblkshift = "\000\000\000", dn_next_bonustype = ",\000\000",
dn_rm_spillblk = "\000\000\000", dn_next_bonuslen = {192, 0, 0, 0},
dn_next_blksz = {0, 0, 0, 0}, dn_dbufs_count = 0, dn_dirty_link = {{
list_next = 0xfe00691a51f0, list_prev = 0xfe0042628ab0},
{list_next = 0x0, list_prev = 0x0}, {list_next = 0x0, list_prev = 0x0},
{list_next = 0x0, list_prev = 0x0}}, dn_mtx = {lock_object = {
lo_name = 0x811da0bf "dn->dn_mtx", lo_flags = 4096, lo_data =
0, lo_witness = 0x0}, sx_lock = 1}, dn_dirty_records = {{list_size = 208,
list_offset = 0, list_head = {
list_next = 0xfe004261c470, list_prev = 0xfe004261c470}},
{list_size = 208, list_offset = 0, list_head = {list_next = 0xfe004261c490,
list_prev = 0xfe004261c490}}, {list_size = 208,
updating ports to HEAD
Hello, I have a FreeBSD 10-CURRENT as of: $ uname -a FreeBSD aurora.Sisis.de 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r235646: Sat May 19 15:52:36 CEST 2012 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC i386 and I want to update /usr/ports with SVN to HEAD and compile the stuff I need; Is there something in the base system of r235646 which would not allow to do so, i.e. which is to old for HEAD of ports? Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: ports/177488: qemu-1.4
On Mon, Apr 01, 2013 at 03:20:25PM +0300, Volodymyr Kostyrko wrote: > [...] > > Doesn't build WITHOUT_CURL: > > block/qcow.o: In function `encrypt_sectors': > /tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow.c:250: > undefined reference to `AES_cbc_encrypt' > [...] Thanx, looks like --disable-curl is now broken upstream so I removed the knob. Juergen ___ 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: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625
on 01/04/2013 17:18 Fabian Keil said the following: > #10 0x8130323f in assfail3 (a=, lv= optimized out>, op=, rv=, f= optimized out>, l=) > at > /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:89 > #11 0x8117924e in zfs_space_delta_cb (bonustype= out>, data=0xff8015eeb8c0, userp=0xfe004261c640, > groupp=0xfe004261c648) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:625 > #12 0x8110003b in dmu_objset_userquota_get_ids > (dn=0xfe004261c358, before=0, tx=) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249 > #13 0x811071b6 in dnode_sync (dn=0xfe004261c358, > tx=0xfe00186e1300) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c:554 > #14 0x810ff98b in dmu_objset_sync_dnodes (list=0xfe00691a5250, > newlist=, tx=) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:910 > #15 0x810ff825 in dmu_objset_sync (os=0xfe00691a5000, pio= optimized out>, tx=0xfe00186e1300) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1027 > #16 0x8110cb0d in dsl_dataset_sync (ds=0xfe001f3d0c00, zio=0x780, > tx=0xfe00186e1300) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:1411 > #17 0x8111399a in dsl_pool_sync (dp=0xfe0069ec4000, txg= optimized out>) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:409 > #18 0x8112f0ee in spa_sync (spa=0xfe0050f0, txg=3292) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6328 > #19 0x81137c45 in txg_sync_thread (arg=0xfe0069ec4000) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:493 > #20 0x80569c1a in fork_exit (callout=0x811378d0 > , arg=0xfe0069ec4000, frame=0xff80dc9d6c00) at > /usr/src/sys/kern/kern_fork.c:991 > #21 0x8086a1ee in fork_trampoline () at exception.S:602 > #22 0x in ?? () > Current language: auto; currently minimal > (kgdb) f 12 > #12 0x8110003b in dmu_objset_userquota_get_ids > (dn=0xfe004261c358, before=0, tx=) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249 > 1249 error = used_cbs[os->os_phys->os_type](dn->dn_bonustype, data, > (kgdb) p *dn Could you please also provide *dn->dn_phys? > The offending sa_magic in the panic message is always the same. Which part, left side or right side? Right side is the _expected_ value. -- 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"
Re: call suspend_cpus() under smp_ipi_mtx
On Saturday, March 23, 2013 5:48:50 am Andriy Gapon wrote: > > Looks like this issue needs more thinking and discussing. > > The basic idea is that suspend_cpus() must be called with smp_ipi_mtx held (on > SMP systems). > This is for exactly the same reasons as to why we first take smp_ipi_mtx > before > calling stop_cpus() in the shutdown path. Essentially one CPU could be > holding > smp_ipi_mtx (and thus with interrupts disabled[*]) and waiting for an > acknowledgement from other CPUs (e.g. in smp_rendezvous or in a TLB > shootdown), > while another CPU could be with interrupts disabled (explicitly - like in the > shutdown or ACPI suspend paths) and trying to deliver an IPI to other CPUs. > > In my opinion, we must consistently use the same lock, smp_ipi_mtx, for all > regular (non-NMI) synchronous IPI-based communication between CPUs. > Otherwise a > deadlock is quite possible. > > Some obstacles for just going ahead and making the suggested change: > > - acpi_sleep_machdep() calls intr_suspend() with interrupts disabled; > currently > witness(9) is not aware of that, but if smp_ipi_mtx spin-lock is used, then we > would have to make intr_table_lock and msi_lock the spin-locks as well; > - AcpiLeaveSleepStatePrep() (from ACPICA) is called with interrupts disabled > and > currently it performs an action that requires memory allocation; again, with > interrupts disabled via intr_disable() this fact is not visible to witness, > etc, > but with smp_ipi_mtx it needs to be somehow handled. > > I talked to ACPICA guys about the last issue and they told me that what is > currently done in AcpiLeaveSleepStatePrep does not need to be with interrupts > disabled and can be moved to AcpiLeaveSleepState. This is after the _BFS and > _GTS support was removed. > > What do you think? > Thank you. Hmm, I think intr_table_lock used to be a spin lock at some point. I don't remember why we changed it to a regular mutex. It may be that there was a lock order reason for that. :( -- 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: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625
I can confirm this problem see the same.
- Martin
On Apr 1, 2013, at 10:18 PM, Fabian Keil wrote:
> I got the following panic on 10.0-CURRENT from two days ago
> while receiving an incremental snapshot to a certain pool:
>
> (kgdb) where
> #0 doadump (textdump=0) at pcpu.h:229
> #1 0x8031a3ce in db_dump (dummy=, dummy2=0,
> dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543
> #2 0x80319eca in db_command (last_cmdp=,
> cmd_table=, dopager=1) at
> /usr/src/sys/ddb/db_command.c:449
> #3 0x80319c82 in db_command_loop () at
> /usr/src/sys/ddb/db_command.c:502
> #4 0x8031c5d0 in db_trap (type=, code=0) at
> /usr/src/sys/ddb/db_main.c:231
> #5 0x805d0da3 in kdb_trap (type=3, code=0, tf=)
> at /usr/src/sys/kern/subr_kdb.c:654
> #6 0x8087fdc3 in trap (frame=0xff80dc9d6520) at
> /usr/src/sys/amd64/amd64/trap.c:579
> #7 0x80869cb2 in calltrap () at exception.S:228
> #8 0x805d058e in kdb_enter (why=0x80a47e7a "panic",
> msg=) at cpufunc.h:63
> #9 0x80599216 in panic (fmt=) at
> /usr/src/sys/kern/kern_shutdown.c:747
> #10 0x8130323f in assfail3 (a=, lv= optimized out>, op=, rv=, f= optimized out>, l=)
>at
> /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:89
> #11 0x8117924e in zfs_space_delta_cb (bonustype= out>, data=0xff8015eeb8c0, userp=0xfe004261c640,
> groupp=0xfe004261c648)
>at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:625
> #12 0x8110003b in dmu_objset_userquota_get_ids
> (dn=0xfe004261c358, before=0, tx=) at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249
> #13 0x811071b6 in dnode_sync (dn=0xfe004261c358,
> tx=0xfe00186e1300) at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c:554
> #14 0x810ff98b in dmu_objset_sync_dnodes (list=0xfe00691a5250,
> newlist=, tx=)
>at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:910
> #15 0x810ff825 in dmu_objset_sync (os=0xfe00691a5000, pio= optimized out>, tx=0xfe00186e1300)
>at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1027
> #16 0x8110cb0d in dsl_dataset_sync (ds=0xfe001f3d0c00, zio=0x780,
> tx=0xfe00186e1300) at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:1411
> #17 0x8111399a in dsl_pool_sync (dp=0xfe0069ec4000, txg= optimized out>) at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:409
> #18 0x8112f0ee in spa_sync (spa=0xfe0050f0, txg=3292) at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6328
> #19 0x81137c45 in txg_sync_thread (arg=0xfe0069ec4000) at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:493
> #20 0x80569c1a in fork_exit (callout=0x811378d0
> , arg=0xfe0069ec4000, frame=0xff80dc9d6c00) at
> /usr/src/sys/kern/kern_fork.c:991
> #21 0x8086a1ee in fork_trampoline () at exception.S:602
> #22 0x in ?? ()
> Current language: auto; currently minimal
> (kgdb) f 12
> #12 0x8110003b in dmu_objset_userquota_get_ids
> (dn=0xfe004261c358, before=0, tx=) at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249
> 1249 error = used_cbs[os->os_phys->os_type](dn->dn_bonustype, data,
> (kgdb) p *dn
> $1 = {dn_struct_rwlock = {lock_object = {lo_name = 0x811da0a9
> "dn->dn_struct_rwlock", lo_flags = 4096, lo_data = 0, lo_witness = 0x0},
> sx_lock = 1}, dn_link = {list_next = 0xfe0042629020,
>list_prev = 0xfe00691a5360}, dn_objset = 0xfe00691a5000, dn_object
> = 55652, dn_dbuf = 0xfe00427ad0e0, dn_handle = 0xfe0069f70128,
> dn_phys = 0xff8015eeb800,
> dn_type = DMU_OT_PLAIN_FILE_CONTENTS, dn_bonuslen = 192, dn_bonustype = 44
> ',', dn_nblkptr = 1 '\001', dn_checksum = 0 '\0', dn_compress = 0 '\0',
> dn_nlevels = 1 '\001', dn_indblkshift = 14 '\016',
> dn_datablkshift = 0 '\0', dn_moved = 0 '\0', dn_datablkszsec = 10,
> dn_datablksz = 5120, dn_maxblkid = 0, dn_next_nblkptr = "\000\000\000",
> dn_next_nlevels = "\000\000\000",
> dn_next_indblkshift = "\000\000\000", dn_next_bonustype = ",\000\000",
> dn_rm_spillblk = "\000\000\000", dn_next_bonuslen = {192, 0, 0, 0},
> dn_next_blksz = {0, 0, 0, 0}, dn_dbufs_count = 0, dn_dirty_link = {{
> list_next = 0xfe00691a51f0, list_prev = 0xfe0042628ab0},
> {list_next = 0x0, list_prev = 0x0}, {list_next = 0x0, list_prev = 0x0},
> {list_next = 0x0, list_prev = 0x0}}, dn_mtx = {lock_object = {
> lo_name = 0x811da0bf "dn->dn_mtx", lo_flags = 4096, lo_data
Re: panic: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625
Andriy Gapon wrote:
> on 01/04/2013 17:18 Fabian Keil said the following:
> > #10 0x8130323f in assfail3 (a=, lv= > optimized out>, op=, rv=,
> > f=, l=)
> > at
> > /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:89
> > #11 0x8117924e in zfs_space_delta_cb (bonustype= > out>, data=0xff8015eeb8c0, userp=0xfe004261c640,
> > groupp=0xfe004261c648)
> > at
> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:625
> > #12 0x8110003b in dmu_objset_userquota_get_ids
> > (dn=0xfe004261c358, before=0, tx=) at
> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249
> > #13 0x811071b6 in dnode_sync (dn=0xfe004261c358,
> > tx=0xfe00186e1300) at
> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c:554
> > #14 0x810ff98b in dmu_objset_sync_dnodes (list=0xfe00691a5250,
> > newlist=, tx=)
> > at
> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:910
> > #15 0x810ff825 in dmu_objset_sync (os=0xfe00691a5000,
> > pio=, tx=0xfe00186e1300)
> > at
> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1027
> > #16 0x8110cb0d in dsl_dataset_sync (ds=0xfe001f3d0c00,
> > zio=0x780, tx=0xfe00186e1300) at
> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:1411
> > #17 0x8111399a in dsl_pool_sync (dp=0xfe0069ec4000, txg= > optimized out>) at
> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:409
> > #18 0x8112f0ee in spa_sync (spa=0xfe0050f0, txg=3292) at
> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6328
> > #19 0x81137c45 in txg_sync_thread (arg=0xfe0069ec4000) at
> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:493
> > #20 0x80569c1a in fork_exit (callout=0x811378d0
> > , arg=0xfe0069ec4000, frame=0xff80dc9d6c00) at
> > /usr/src/sys/kern/kern_fork.c:991
> > #21 0x8086a1ee in fork_trampoline () at exception.S:602
> > #22 0x in ?? ()
> > Current language: auto; currently minimal
> > (kgdb) f 12
> > #12 0x8110003b in dmu_objset_userquota_get_ids
> > (dn=0xfe004261c358, before=0, tx=) at
> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249
> > 1249error =
> > used_cbs[os->os_phys->os_type](dn->dn_bonustype, data,
> > (kgdb) p *dn
>
> Could you please also provide *dn->dn_phys?
vmcore.12:
(kgdb) p *dn->dn_phys
Cannot access memory at address 0xff8019492800
(kgdb) p *dn->dn_dbuf
$1 = {db = {db_object = 0, db_offset = 28491776, db_size = 16384, db_data =
0xff8019492000}, db_objset = 0xfe002bc62400, db_dnode_handle =
0xfe002bc62420, db_parent = 0xfe005f1071c0,
db_hash_next = 0x0, db_blkid = 1739, db_blkptr = 0xff801936c580, db_level
= 0 '\0', db_mtx = {lock_object = {lo_name = 0x811d8696 "db->db_mtx",
lo_flags = 4096, lo_data = 0,
lo_witness = 0x0}, sx_lock = 1}, db_state = DB_CACHED, db_holds =
{rc_count = 2}, db_buf = 0xfe005f34c798, db_changed = {cv_description =
0x811d86a2 "db->db_changed", cv_waiters = 0},
db_data_pending = 0xfe004bcc0c00, db_last_dirty = 0xfe004bcc0c00,
db_link = {list_next = 0xfe005f3506d0, list_prev = 0xfe0030c392a0},
db_user_ptr = 0xfe005f269000,
db_user_data_ptr_ptr = 0x0, db_evict_func = 0x81105770
, db_immediate_evict = 0 '\0', db_freed_in_flight = 0 '\0',
db_dirtycnt = 1 '\001'}
vmcore.13:
(kgdb) p *dn->dn_phys
Cannot access memory at address 0xff8015eeb800
(kgdb) p *dn->dn_dbuf
$1 = {db = {db_object = 0, db_offset = 28491776, db_size = 16384, db_data =
0xff8015eeb000}, db_objset = 0xfe00691a5000, db_dnode_handle =
0xfe00691a5020, db_parent = 0xfe004254ab60,
db_hash_next = 0x0, db_blkid = 1739, db_blkptr = 0xff8015d65580, db_level
= 0 '\0', db_mtx = {lock_object = {lo_name = 0x811d8696 "db->db_mtx",
lo_flags = 4096, lo_data = 0,
lo_witness = 0x0}, sx_lock = 1}, db_state = DB_CACHED, db_holds =
{rc_count = 2}, db_buf = 0xfe0042bedcf0, db_changed = {cv_description =
0x811d86a2 "db->db_changed", cv_waiters = 0},
db_data_pending = 0xfe00406d6500, db_last_dirty = 0xfe00406d6500,
db_link = {list_next = 0xfe0042758c10, list_prev = 0xfe0069cab5f8},
db_user_ptr = 0xfe0069f7,
db_user_data_ptr_ptr = 0x0, db_evict_func = 0x81105770
, db_immediate_evict = 0 '\0', db_freed_in_flight = 0 '\0',
db_dirtycnt = 1 '\001'}
vmcore.14:
(kgdb) p *dn->dn_phys
Cannot access memory at address 0xff8014d21800
(kgdb) p *dn->dn_dbuf
$1 = {db = {db_ob
Re: panic: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625
on 01/04/2013 18:51 Fabian Keil said the following:
> vmcore.13:
>
> (kgdb) p *dn->dn_phys
> Cannot access memory at address 0xff8015eeb800
> (kgdb) p *dn->dn_dbuf
> $1 = {db = {db_object = 0, db_offset = 28491776, db_size = 16384, db_data =
> 0xff8015eeb000}, db_objset = 0xfe00691a5000, db_dnode_handle =
> 0xfe00691a5020, db_parent = 0xfe004254ab60,
> db_hash_next = 0x0, db_blkid = 1739, db_blkptr = 0xff8015d65580,
> db_level = 0 '\0', db_mtx = {lock_object = {lo_name = 0x811d8696
> "db->db_mtx", lo_flags = 4096, lo_data = 0,
> lo_witness = 0x0}, sx_lock = 1}, db_state = DB_CACHED, db_holds =
> {rc_count = 2}, db_buf = 0xfe0042bedcf0, db_changed = {cv_description =
> 0x811d86a2 "db->db_changed", cv_waiters = 0},
> db_data_pending = 0xfe00406d6500, db_last_dirty = 0xfe00406d6500,
> db_link = {list_next = 0xfe0042758c10, list_prev = 0xfe0069cab5f8},
> db_user_ptr = 0xfe0069f7,
> db_user_data_ptr_ptr = 0x0, db_evict_func = 0x81105770
> , db_immediate_evict = 0 '\0', db_freed_in_flight = 0
> '\0', db_dirtycnt = 1 '\001'}
That's interesting. So db.db_data has a bogus address.
Not sure how that could happen and what to make of it yet.
--
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"
Re: rc.subr: disabling globbing while processing devfs rules
On Saturday, March 23, 2013 4:41:41 am Andriy Gapon wrote:
>
> Any objections / concerns for the following change?
>
> An example.
> This rule in devfs.rules:
> add path da* mode 660 group operator
> and this directory:
> /data
> result in the following rule being actually installed:
> 100 path data group operator mode 660
>
> Of course, I could refine the pattern in the rule, but I shouldn't have to do
> it, because the pattern is for /dev/ entries, not arbitrary files in the
> filesystem namespace.
>
> commit 7ce5e9ca5c107e2669f18efa472c1ab14999247c
> Author: Andriy Gapon
> Date: Sat Mar 23 10:29:39 2013 +0200
>
> rc.subr: disabling globbing while processing devfs rules in
> devfs_rulesets_from_file()
>
> The rules themselves typically have shell-like patterns and it is
> incorrect
> when they get replaced with matching filesystem entries.
>
> Shell magic by: jilles
>
> diff --git a/etc/rc.subr b/etc/rc.subr
> index f37ede7..9952c82 100644
> --- a/etc/rc.subr
> +++ b/etc/rc.subr
> @@ -1301,7 +1301,7 @@ make_symlink()
> #
> devfs_rulesets_from_file()
> {
> - local file _err _me
> + local file _err _me _opts
> file="$1"
> _me="devfs_rulesets_from_file"
> _err=0
> @@ -1314,6 +1314,11 @@ devfs_rulesets_from_file()
> debug "$_me: no such file ($file)"
> return 0
> fi
> +
> + # Disable globbing so that the rule patterns are not expanded
> + # by accident with matching filesystem entries.
> + _opts=$-; set -f
> +
> debug "reading rulesets from file ($file)"
> { while read line
> do
> @@ -1360,6 +1365,7 @@ devfs_rulesets_from_file()
> break
> fi
> done } < $file
> + case $_opts in *f*) ;; *) set +f ;; esac
> return $_err
> }
Why not use 'local -' instead of the $- magic? That is:
devfs_rulesets_from_file()
{
local file _err _me -
...
set -f
...
}
That would seem to be simpler.
--
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: rc.subr: disabling globbing while processing devfs rules
On Mon, Apr 01, 2013 at 02:06:50PM -0400, John Baldwin wrote:
> Why not use 'local -' instead of the $- magic? That is:
> devfs_rulesets_from_file()
> {
>local file _err _me -
>
>...
>set -f
>...
> }
> That would seem to be simpler.
I had mentioned this possibility on IRC, but this feature is specific to
Almquist-derived shells (ash) and so something more portable was
selected. (It's still not standard because POSIX does not specify
"local" but it works on most shells in use.)
--
Jilles Tjoelker
___
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: DTrace of radeonkms on 9.1
On Wed, 27 Mar 2013 18:07:14 -0400 "J.R. Oldroyd" wrote: > Is there any known magic involved in getting DTrace to do its thing on > 9.1-release? > > I am trying to use it to debug a memory leak problem with the > radeonkms driver under 9.x. Can you check if you have the same dtrace-problem with -current? I would expect that 9.1 already has some dtrace-fixes regarding new probes in run-time loaded modules, this is just to verify this assumption. Assuming there is some kind of dead-lock in this module-load interaction with dtrace, you could modify the radeonkms module to do it's initialization magic once a sysctl is set to 1, instead of doing this magic at module-load time. This way you could load the module, start the dtrace script and then issue the magic sysctl. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: rc.subr: disabling globbing while processing devfs rules
On Monday, April 01, 2013 3:56:01 pm Jilles Tjoelker wrote:
> On Mon, Apr 01, 2013 at 02:06:50PM -0400, John Baldwin wrote:
> > Why not use 'local -' instead of the $- magic? That is:
>
> > devfs_rulesets_from_file()
> > {
> >local file _err _me -
> >
> >...
> >set -f
> >...
> > }
>
> > That would seem to be simpler.
>
> I had mentioned this possibility on IRC, but this feature is specific to
> Almquist-derived shells (ash) and so something more portable was
> selected. (It's still not standard because POSIX does not specify
> "local" but it works on most shells in use.)
rc.subr isn't meant to be portable, it's a script that is part of the FreeBSD
base system. I find the 'local -' syntax more readable (and used the feature
quite a bit in etcupdate).
--
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: rc.subr: disabling globbing while processing devfs rules
on 01/04/2013 23:16 John Baldwin said the following:
> On Monday, April 01, 2013 3:56:01 pm Jilles Tjoelker wrote:
>> On Mon, Apr 01, 2013 at 02:06:50PM -0400, John Baldwin wrote:
>>> Why not use 'local -' instead of the $- magic? That is:
>>
>>> devfs_rulesets_from_file()
>>> {
>>>local file _err _me -
>>>
>>>...
>>>set -f
>>>...
>>> }
>>
>>> That would seem to be simpler.
>>
>> I had mentioned this possibility on IRC, but this feature is specific to
>> Almquist-derived shells (ash) and so something more portable was
>> selected. (It's still not standard because POSIX does not specify
>> "local" but it works on most shells in use.)
>
> rc.subr isn't meant to be portable, it's a script that is part of the FreeBSD
> base system. I find the 'local -' syntax more readable (and used the feature
> quite a bit in etcupdate).
>
You have to set an example in etc/ :-)
I used a script in etc/rc.d as a starting point, Jilles guided me from there.
--
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"
Re: [CRASH] ZFS recv (fwd)/CURRENT
This error seems to be limited to sending deduplicated streams. Does sending without "-D" work ok? This might be a vendor error as well. On 1.4.2013 20:05, Larry Rosenman wrote: > Re-Sending. Any ideas, guys/gals? > > This really gets in my way. > -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ 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"
Patch ath3kfw to accept other device ids; blacklist ath bluetooth devices
Hi, Please find a patch which does two things: * it allows ath3kfw to be given a vendor/productid, in order to load firmware into other NICs that only have a very basic firmware (sflash); * it blacklists all the NICs that have this particular behaviour (sourced from linux-next btusb.c driver). I've tested this on: * AR9285 + bluetooth (WB195) * AR9287 + bluetooht (WB197) I haven't yet opened the NICs up to see _exactly_ which BT chip is in them; I'll do that soon. There's some future work to do to allow for ROM patching and HCI configuration of later atheros bluetooth NICs; check the linux ath3k driver for more information. I'm not going to try and address these in this commit. I'd like to commit this to -HEAD if there are no objections. Thanks, 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"
Re: updating ports to HEAD
On Mon, Apr 1, 2013 at 7:46 AM, Matthias Apitz wrote: > > Hello, > > I have a FreeBSD 10-CURRENT as of: > > $ uname -a > FreeBSD aurora.Sisis.de 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r235646: Sat > May 19 15:52:36 CEST 2012 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC > i386 > > and I want to update /usr/ports with SVN to HEAD and compile the stuff I > need; > > Is there something in the base system of r235646 which would not allow > to do so, i.e. which is to old for HEAD of ports? > I'm not quite sure what you mean by "update /usr/ports with SVN to HEAD", since ports does not branch, so any time you "svn up /usr/potrts", it is updated to head. Any version of FreeBSD 8 or newer should work fine with ports/head. Note that some ports will need to be compiled with gcc as not all will work with clang. Are you having a problem updating (or checking out) head or with some of the ports after the update? -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ 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: updating ports to HEAD
El día Monday, April 01, 2013 a las 08:54:59PM -0700, Kevin Oberman escribió: > > Is there something in the base system of r235646 which would not allow > > to do so, i.e. which is to old for HEAD of ports? > > > > I'm not quite sure what you mean by "update /usr/ports with SVN to HEAD", > since ports does not branch, so any time you "svn up /usr/potrts", it is > updated to head. I used the term 'HEAD' because the SVN command I have used was: # svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports > Any version of FreeBSD 8 or newer should work fine with > ports/head. Note that some ports will need to be compiled with gcc as not > all will work with clang. thanks; > > Are you having a problem updating (or checking out) head or with some of > the ports after the update? the system in question hast around 1200 ports compiled based on the CVS checkout of ports on May 19 last year; I want to check if I could compile Ekiga out of its GIT, wich needs gtk+3.4.x and other recent stuff; I will just for a test rename /usr/local and /var/db/pkg, update the ports to 'HEAD' and compile them again to see if this would solve the problem and make Ekiga happy. Thanks for your feedback matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: updating ports to HEAD
On Mon, Apr 1, 2013 at 10:03 PM, Matthias Apitz wrote: > El día Monday, April 01, 2013 a las 08:54:59PM -0700, Kevin Oberman > escribió: > > > > Is there something in the base system of r235646 which would not allow > > > to do so, i.e. which is to old for HEAD of ports? > > > > > > > I'm not quite sure what you mean by "update /usr/ports with SVN to > HEAD", > > since ports does not branch, so any time you "svn up /usr/potrts", it is > > updated to head. > > I used the term 'HEAD' because the SVN command I have used was: > > # svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports > Assuming you previously deleted /usr/ports/*, that should so it > > Any version of FreeBSD 8 or newer should work fine with > > ports/head. Note that some ports will need to be compiled with gcc as > not > > all will work with clang. > > thanks; > > > > > Are you having a problem updating (or checking out) head or with some of > > the ports after the update? > > the system in question hast around 1200 ports compiled based on the CVS > checkout of ports on May 19 last year; I want to check if I could > compile Ekiga out of its GIT, wich needs gtk+3.4.x and other recent > stuff; I will just for a test rename /usr/local and /var/db/pkg, update > the ports to 'HEAD' and compile them again to see if this would solve > the problem and make Ekiga happy. > > Thanks for your feedback > Good luck. I suspect a successful update of ptlib will be the real tricky part. At least it gave me headaches back when I was using Ekiga. Also, gtk-3 has well over 400 dependencies. You will probably need to update some of these, so check UPDATING for those that need special attention. Good luck! -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ 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: updating ports to HEAD
On Tue, Apr 2, 2013 at 8:03 AM, Matthias Apitz wrote: > El día Monday, April 01, 2013 a las 08:54:59PM -0700, Kevin Oberman escribió: > >> > Is there something in the base system of r235646 which would not allow >> > to do so, i.e. which is to old for HEAD of ports? >> > >> >> I'm not quite sure what you mean by "update /usr/ports with SVN to HEAD", >> since ports does not branch, so any time you "svn up /usr/potrts", it is >> updated to head. > > I used the term 'HEAD' because the SVN command I have used was: > > # svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports > >> Any version of FreeBSD 8 or newer should work fine with >> ports/head. Note that some ports will need to be compiled with gcc as not >> all will work with clang. > > thanks; > >> >> Are you having a problem updating (or checking out) head or with some of >> the ports after the update? > > the system in question hast around 1200 ports compiled based on the CVS > checkout of ports on May 19 last year; I want to check if I could > compile Ekiga out of its GIT, wich needs gtk+3.4.x and other recent > stuff; I will just for a test rename /usr/local and /var/db/pkg, update > the ports to 'HEAD' and compile them again to see if this would solve > the problem and make Ekiga happy. > I hope for your sake that this machine is not open to the net with many services, using year old ports/packages is a death wish in such systems. In any case it's a good idea to update everything at least every two months about. -Kimmo ___ 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: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625
on 01/04/2013 19:22 Andriy Gapon said the following:
> on 01/04/2013 18:51 Fabian Keil said the following:
>> vmcore.13:
>>
>> (kgdb) p *dn->dn_phys
>> Cannot access memory at address 0xff8015eeb800
>> (kgdb) p *dn->dn_dbuf
>> $1 = {db = {db_object = 0, db_offset = 28491776, db_size = 16384, db_data =
>> 0xff8015eeb000}, db_objset = 0xfe00691a5000, db_dnode_handle =
>> 0xfe00691a5020, db_parent = 0xfe004254ab60,
>> db_hash_next = 0x0, db_blkid = 1739, db_blkptr = 0xff8015d65580,
>> db_level = 0 '\0', db_mtx = {lock_object = {lo_name = 0x811d8696
>> "db->db_mtx", lo_flags = 4096, lo_data = 0,
>> lo_witness = 0x0}, sx_lock = 1}, db_state = DB_CACHED, db_holds =
>> {rc_count = 2}, db_buf = 0xfe0042bedcf0, db_changed = {cv_description =
>> 0x811d86a2 "db->db_changed", cv_waiters = 0},
>> db_data_pending = 0xfe00406d6500, db_last_dirty = 0xfe00406d6500,
>> db_link = {list_next = 0xfe0042758c10, list_prev = 0xfe0069cab5f8},
>> db_user_ptr = 0xfe0069f7,
>> db_user_data_ptr_ptr = 0x0, db_evict_func = 0x81105770
>> , db_immediate_evict = 0 '\0', db_freed_in_flight = 0
>> '\0', db_dirtycnt = 1 '\001'}
>
> That's interesting. So db.db_data has a bogus address.
> Not sure how that could happen and what to make of it yet.
>
In fact, this was a bogus comment :-)
I forgot that dn_phys points inside a ZFS data buffer and those do not get
dumped.
--
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"
