Re: ZFS secondarycache on SSD problem on r255173
on 18/10/2013 17:57 Steven Hartland said the following:
I think we we may well need the following patch to set the minblock
size based on the vdev ashift and not SPA_MINBLOCKSIZE.
svn diff -x -p sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
===
--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c(revision
256554)
+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c(working copy)
@@ -5147,7 +5147,7 @@ l2arc_compress_buf(l2arc_buf_hdr_t *l2hdr)
len = l2hdr-b_asize;
cdata = zio_data_buf_alloc(len);
csize = zio_compress_data(ZIO_COMPRESS_LZ4, l2hdr-b_tmp_cdata,
- cdata, l2hdr-b_asize, (size_t)SPA_MINBLOCKSIZE);
+ cdata, l2hdr-b_asize, (size_t)(1ULL
l2hdr-b_dev-l2ad_vdev-vdev_ashift));
if (csize == 0) {
/* zero block, indicate that there's nothing to write */
This is a rather old thread and change, but I think that I have identified
another problem with 4KB cache devices.
I noticed that on some of our systems we were getting a clearly abnormal number
of l2arc checksum errors accounted in l2_cksum_bad. The hardware appeared to be
in good health. Using DTrace I noticed that the data seemed to be overwritten
with other data. After more DTrace analysis I observed that sometimes
l2arc_write_buffers() would advance l2ad_hand by more than target_sz.
This meant that l2arc_write_buffers() would write beyond a region cleared by
l2arc_evict() and thus overwrite data belonging to non-evicted buffers. Havoc
ensues.
The cache devices in question are all SSDs with logical sector size of 4KB.
I am not sure about other ZFS platforms, but on FreeBSD this fact is detected
and ashift of 12 is used for the cache vdevs.
Looking at l2arc_write_buffers() code you can see that it properly accounts for
ashift when actually writing buffers and advancing l2ad_hand:
/*
* Keep the clock hand suitably device-aligned.
*/
buf_p_sz = vdev_psize_to_asize(dev-l2ad_vdev, buf_sz);
write_psize += buf_p_sz;
dev-l2ad_hand += buf_p_sz;
But the same is not done when selecting buffers to be written and checking that
target_sz is not exceeded.
So, if ARC contains a lot of buffers smaller than 4K that means that an aligned
on-disk size of the L2ARC buffers could be quite larger than their non-aligned
size.
I propose the following patch which has been tested and seems to fix the problem
without introducing any side effects:
https://github.com/avg-I/freebsd/compare/review;l2arc-write-target-size.diff
https://github.com/avg-I/freebsd/compare/review;l2arc-write-target-size
--
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: IXP700 AHCI fails to initialize
On 01/03/14 19:00, Yuriy Taraday wrote: Hello. I currently have FreeBSD 8.3 on my home server and it works fine but it's time to upgrade at last (new ath and new ipfw especially allure me). I've decided to go straight to 10.0 and reinstall system from scratch to purge all legacy unrelated configs and other stuff. The problem I faced is as follows. I have a (rather old) motherboard with integrated SATA controller that presents in the OS as IXP700. In 8.3 it works fine. I have 2 disks attached to it: one with all my data and another one destined to be new system disk. I also have one IDE disk installed that is currently used as system disk. When I booted from USB stick with 10.0, I couldn't see any SATA disks in the system. I dug into dmesg and found this: http://pastebin.com/wv2A0MUE As it seems AHCI controller or disks are not responding to commands and timeouts eventually. A friend suggested to try CURRENT image. I went with FreeBSD-11.0-CURRENT-amd64-VT-20140222-r262336-mini-memstick.img and got almost the same error: http://pastebin.com/0iGaSWUD The error repeats and never stops (looks like CURRENT images have different config) but it is essentially the same. I've googled the problem but found only notes about how IXP700 is really bad and pointers that cabling might be the problem. But I have absolutely no problems with 8.3, so it looks like some regression during further development (shift to CAM, maybe?). Please help me to identify and fix the problem. This is just a shot in the dark, I'm not familiar with the AHCI driver, but since you seem to be loosing interrupts (or I would say so based on the timeout messages), you could try to disable MSI/MSI-X and fallback to PCI intline IRQs. Could you try to boot with hw.pci.enable_msix=0,hw.pci.enable_msi=0? Roger. ___ 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: IXP700 AHCI fails to initialize
Hi, ok, I do not know of a working solution. But something like this happened to me too. I simply could not get newer FreeBSD versions working on old hardware. I have had to stick then with 7 until a lightning put an end to the affected machine. You still have one other chance. Try 9. My strategy in upgrading is also very simple. When I get a new machine, I install CURRENT and stick with the branch it will become later until this branch is not supported anymore. It saved me a lot of hassles as I normally have to do just one big version jump if the machine gets real old I have have to switch version. Erich On Sat, 1 Mar 2014 22:00:52 +0400 Yuriy Taraday yorik@gmail.com wrote: Hello. I currently have FreeBSD 8.3 on my home server and it works fine but it's time to upgrade at last (new ath and new ipfw especially allure me). I've decided to go straight to 10.0 and reinstall system from scratch to purge all legacy unrelated configs and other stuff. The problem I faced is as follows. I have a (rather old) motherboard with integrated SATA controller that presents in the OS as IXP700. In 8.3 it works fine. I have 2 disks attached to it: one with all my data and another one destined to be new system disk. I also have one IDE disk installed that is currently used as system disk. When I booted from USB stick with 10.0, I couldn't see any SATA disks in the system. I dug into dmesg and found this: http://pastebin.com/wv2A0MUE As it seems AHCI controller or disks are not responding to commands and timeouts eventually. A friend suggested to try CURRENT image. I went with FreeBSD-11.0-CURRENT-amd64-VT-20140222-r262336-mini-memstick.img and got almost the same error: http://pastebin.com/0iGaSWUD The error repeats and never stops (looks like CURRENT images have different config) but it is essentially the same. I've googled the problem but found only notes about how IXP700 is really bad and pointers that cabling might be the problem. But I have absolutely no problems with 8.3, so it looks like some regression during further development (shift to CAM, maybe?). Please help me to identify and fix the problem. ___ 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 secondarycache on SSD problem on r255173
- Original Message -
From: Andriy Gapon a...@freebsd.org
on 18/10/2013 17:57 Steven Hartland said the following:
I think we we may well need the following patch to set the minblock
size based on the vdev ashift and not SPA_MINBLOCKSIZE.
svn diff -x -p sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
===
--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c(revision
256554)
+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c(working copy)
@@ -5147,7 +5147,7 @@ l2arc_compress_buf(l2arc_buf_hdr_t *l2hdr)
len = l2hdr-b_asize;
cdata = zio_data_buf_alloc(len);
csize = zio_compress_data(ZIO_COMPRESS_LZ4, l2hdr-b_tmp_cdata,
- cdata, l2hdr-b_asize, (size_t)SPA_MINBLOCKSIZE);
+ cdata, l2hdr-b_asize, (size_t)(1ULL
l2hdr-b_dev-l2ad_vdev-vdev_ashift));
if (csize == 0) {
/* zero block, indicate that there's nothing to write */
This is a rather old thread and change, but I think that I have identified
another problem with 4KB cache devices.
I noticed that on some of our systems we were getting a clearly abnormal number
of l2arc checksum errors accounted in l2_cksum_bad. The hardware appeared to be
in good health. Using DTrace I noticed that the data seemed to be overwritten
with other data. After more DTrace analysis I observed that sometimes
l2arc_write_buffers() would advance l2ad_hand by more than target_sz.
This meant that l2arc_write_buffers() would write beyond a region cleared by
l2arc_evict() and thus overwrite data belonging to non-evicted buffers. Havoc
ensues.
The cache devices in question are all SSDs with logical sector size of 4KB.
I am not sure about other ZFS platforms, but on FreeBSD this fact is detected
and ashift of 12 is used for the cache vdevs.
Looking at l2arc_write_buffers() code you can see that it properly accounts for
ashift when actually writing buffers and advancing l2ad_hand:
/*
* Keep the clock hand suitably device-aligned.
*/
buf_p_sz = vdev_psize_to_asize(dev-l2ad_vdev, buf_sz);
write_psize += buf_p_sz;
dev-l2ad_hand += buf_p_sz;
But the same is not done when selecting buffers to be written and checking that
target_sz is not exceeded.
So, if ARC contains a lot of buffers smaller than 4K that means that an aligned
on-disk size of the L2ARC buffers could be quite larger than their non-aligned
size.
I propose the following patch which has been tested and seems to fix the problem
without introducing any side effects:
https://github.com/avg-I/freebsd/compare/review;l2arc-write-target-size.diff
https://github.com/avg-I/freebsd/compare/review;l2arc-write-target-size
Looks good to me.
Regards
Steve
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.
___
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: nvi: tab can't be used in the context of substitute
On Sun, Mar 2, 2014 at 1:45 PM, Don Lewis truck...@freebsd.org wrote: On 2 Mar, Zhihao Yuan wrote: Currently, to input tab in last line, you can either C-vC-vtab Hmm, it seems that I have to type C-v twice just because the combination of my zh_CN.GB18030 locale and xterm. In other cases you should be able to just use C-v to escape. I'll email xterm developers for details... Thanks. I've been meaning to whine about this for a while. I just dropped :se filec= in ~/.nexrc and I'm happy again. Actually, the filec functionality has been greatly improved 1. it completes paths level by level, no longer try to find the longest match; 2. it recognizes escaped partial results, and gives escaped results. For example, when completing a filename nice boat, the old filec gives you :e nice boat , then you are going to open two files, which makes this feature useless. Now we give :e nice^V boat which is the working answer. I hope you can get accustomed to this feature :) -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ 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: signal 8 (floating point exception) upon resume
On Friday, February 28, 2014 9:00:57 pm Adrian Chadd wrote: On 28 February 2014 15:35, Adrian Chadd adr...@freebsd.org wrote: ... how'd this ever work in the past then? .. and I've submitted it as a PR: kern/187152 Complete stab in the dark (not compile tested) here: http://www.FreeBSD.org/~jhb/patches/i386_fpu_suspend.patch -- 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: Feature Proposal: Transparent upgrade of crypt() algorithms
On Friday, February 28, 2014 4:58:29 pm Eitan Adler wrote: On 27 February 2014 20:14, Allan Jude free...@allanjude.com wrote: With r262501 (http://svnweb.freebsd.org/base?view=revisionrevision=262501) importing the upgraded bcrypt from OpenBSD and eventually changing the default identifier for bcrypt to $2b$ it reminded me of a feature that is often seen in Forum software and other web apps. Transparent algorithm upgrade. ... I would strongly support this I think Nick's point is you do want passwords using the old hash to expire are some point if they haven't been auto-converted. Password expiry is an orthogonal issue and should be up to administrator policy. Yes, but if you are moving to a different algorithm to improve security, not coupling it with an eventual expiration of non-migrated accounts gives a false sense of security. Any admin worth his/her salt is going to want the option of enforcing that sort of policy along with the transparent update. They should really be implemented together is all. -- 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: lockmgr still held [tmpfs] [vm_map_remove()-vdropl()] (r262186: Thu Feb 20)
On Sunday, March 02, 2014 10:58:45 am Bryan Drewery wrote:
On 2/28/2014 3:18 PM, John Baldwin wrote:
On Friday, February 28, 2014 9:18:51 am Bryan Drewery wrote:
While using poudriere:
Unread portion of the kernel message buffer:
panic: lockmgr still held
cpuid = 12
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe124804f7a0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124804f850
vpanic() at vpanic+0x126/frame 0xfe124804f890
kassert_panic() at kassert_panic+0x139/frame 0xfe124804f900
lockdestroy() at lockdestroy+0x3b/frame 0xfe124804f920
vdropl() at vdropl+0x1c8/frame 0xfe124804f960
vm_object_deallocate() at vm_object_deallocate+0x10b/frame
0xfe124804f9c0
vm_map_process_deferred() at vm_map_process_deferred+0x89/frame
0xfe124804f9f0
vm_map_remove() at vm_map_remove+0xc8/frame 0xfe124804fa20
vmspace_exit() at vmspace_exit+0xc9/frame 0xfe124804fa60
exit1() at exit1+0x541/frame 0xfe124804fad0
sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe124804fae0
ia32_syscall() at ia32_syscall+0x270/frame 0xfe124804fbf0
Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe124804fbf0
--- syscall (1, FreeBSD ELF32, sys_sys_exit), rip = 0x281014df, rsp =
0xc45c, rbp = 0xc468 ---
#4 0x808c00db in lockdestroy (lk=0xf80a88a285f0) at
/usr/src/sys/kern/kern_lock.c:440
440 KASSERT(lk-lk_lock == LK_UNLOCKED, (lockmgr still
held));
(kgdb) print *lk
$1 = {lock_object = {lo_name = 0x8201a1bd tmpfs, lo_flags =
116588552, lo_data = 0, lo_witness = 0xfe6fec00}, lk_lock =
18446735288132049184, lk_exslpfail = 0,
lk_timo = 51, lk_pri = 96}
Can you please grab people.freebsd.org/~jhb/gdb/*
and then do 'cd /path/to/files', 'source gdb6', 'frame 4', 'lockmgr_owner
lk'?
(kgdb) lockmgr_owner lk
td: 0xf80272c61920
pid: 55040, p_comm: testprog
Can you get a stack trace of that program? ('proc 55040', 'bt')
--
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: ia64 r260914 GENERIC kernel: /usr/src/sys/dev/vt/vt_core.c:261: undefined reference to kbd_get_keyboard and so on
On Sunday, March 02, 2014 10:56:34 am Anton Shterenlikht wrote: From j...@freebsd.org Fri Feb 28 20:57:59 2014 On Friday, February 28, 2014 9:23:28 am Anton Shterenlikht wrote: ia64 r260914 GENERIC kernel contains: device kbdmux # keyboard multiplexer device vt # Virtual terminals device vt_vga # VGA terminal device Trying to build it, I get: Try this: Index: conf/files.ia64 === --- conf/files.ia64 (revision 262614) +++ conf/files.ia64 (working copy) @@ -52,7 +52,7 @@ dev/fb/vga.c optionalvga dev/hwpmc/hwpmc_ia64.c optionalhwpmc dev/io/iodev.c optionalio -dev/kbd/kbd.c optionalatkbd | sc | ukbd +dev/kbd/kbd.c optionalatkbd | sc | ukbd | vt dev/syscons/scterm-teken.c optionalsc dev/syscons/scvgarndr.coptionalsc vga dev/syscons/scvtb.coptionalsc yes, I can build and install kernel with patch. On reboot, the booting information is no longer shown on serial console, just: Booting [/boot/kernel/kernel]... Entering /boot/kernel/kernel at 0x9ffc00010500... FreeBSD/ia64 (mech-as221.men.bris.ac.uk) (ttyu1) login: This is probably the default vt behaviour? I need to be able to see thing progressing in the serial console. How can I do this? Or do I need to disable vt for this? This sounds normal for the console being on the VGA console and not serial. I've no idea how close ia64's boot loader is to x86's in that regard. Marcel is probably the right person to ask. Anyway, I can find neither vt nor vt_vga man pages on r260914 system. Is this expected? Yes, there are no manpages for that yet. -- 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
vm.pmap.pcid_enabled=1 causes Java to coredump in FBSD 10
[Resending] Hi, As part of the Jenkins deployment in the FreeBSD cluster the jenkins-admin team observed that when running Jenkins on FreeBSD 10, the Java virtual machine from the openjdk6 or openjdk7 port would coredump regularly. See item #10 here: https://wiki.freebsd.org/Jenkins On the advice of Jung-uk Kim, I put the following in /boot/loader.conf: vm.pmap.pcid_enabled=0 and rebooted. After that, the Java coredumping problems went away. Can someone with VM expertise look into this problem and suggest a fix? There are many reports of Java coredumping on FreeBSD 10, such as this one: http://lists.freebsd.org/pipermail/freebsd-java/2014-March/010606.html It would be good to fix this, so that Java works out of the box on FreeBSD 10. It's not good when kernel tunables need to be set so that Java can work. :( Thanks. -- Craig ___ 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: signal 8 (floating point exception) upon resume
I'll try this soon. I had it fail back to newcons, rather than Xorg normally dying without restoring state. It wouldn't let me spawn a shell. Logging in worked fine, but normal shell exec would eventually and quickly lead to failure, dropping me back to the login prompt. -a On 3 March 2014 11:11, John Baldwin j...@freebsd.org wrote: On Friday, February 28, 2014 9:00:57 pm Adrian Chadd wrote: On 28 February 2014 15:35, Adrian Chadd adr...@freebsd.org wrote: ... how'd this ever work in the past then? .. and I've submitted it as a PR: kern/187152 Complete stab in the dark (not compile tested) here: http://www.FreeBSD.org/~jhb/patches/i386_fpu_suspend.patch -- 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: vm.pmap.pcid_enabled=1 causes Java to coredump in FBSD 10
Have you filed a PR? :-P -a On 3 March 2014 14:09, Craig Rodrigues rodr...@freebsd.org wrote: [Resending] Hi, As part of the Jenkins deployment in the FreeBSD cluster the jenkins-admin team observed that when running Jenkins on FreeBSD 10, the Java virtual machine from the openjdk6 or openjdk7 port would coredump regularly. See item #10 here: https://wiki.freebsd.org/Jenkins On the advice of Jung-uk Kim, I put the following in /boot/loader.conf: vm.pmap.pcid_enabled=0 and rebooted. After that, the Java coredumping problems went away. Can someone with VM expertise look into this problem and suggest a fix? There are many reports of Java coredumping on FreeBSD 10, such as this one: http://lists.freebsd.org/pipermail/freebsd-java/2014-March/010606.html It would be good to fix this, so that Java works out of the box on FreeBSD 10. It's not good when kernel tunables need to be set so that Java can work. :( Thanks. -- Craig ___ 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 ___ 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: vm.pmap.pcid_enabled=1 causes Java to coredump in FBSD 10
Hi, http://www.freebsd.org/cgi/query-pr.cgi?pr=187238 -- Craig On Mon, Mar 3, 2014 at 3:49 PM, Adrian Chadd adr...@freebsd.org wrote: Have you filed a PR? :-P -a On 3 March 2014 14:09, Craig Rodrigues rodr...@freebsd.org wrote: [Resending] Hi, As part of the Jenkins deployment in the FreeBSD cluster the jenkins-admin team observed that when running Jenkins on FreeBSD 10, the Java virtual machine from the openjdk6 or openjdk7 port would coredump regularly. See item #10 here: https://wiki.freebsd.org/Jenkins On the advice of Jung-uk Kim, I put the following in /boot/loader.conf: vm.pmap.pcid_enabled=0 and rebooted. After that, the Java coredumping problems went away. Can someone with VM expertise look into this problem and suggest a fix? There are many reports of Java coredumping on FreeBSD 10, such as this one: http://lists.freebsd.org/pipermail/freebsd-java/2014-March/010606.html It would be good to fix this, so that Java works out of the box on FreeBSD 10. It's not good when kernel tunables need to be set so that Java can work. :( Thanks. -- Craig ___ 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 ___ 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: vm.pmap.pcid_enabled=1 causes Java to coredump in FBSD 10
Cool. DOn't be afraid to poke alc (cc'ed); he may have some insights. :) -a On 3 March 2014 17:02, Craig Rodrigues rodr...@freebsd.org wrote: Hi, http://www.freebsd.org/cgi/query-pr.cgi?pr=187238 -- Craig On Mon, Mar 3, 2014 at 3:49 PM, Adrian Chadd adr...@freebsd.org wrote: Have you filed a PR? :-P -a On 3 March 2014 14:09, Craig Rodrigues rodr...@freebsd.org wrote: [Resending] Hi, As part of the Jenkins deployment in the FreeBSD cluster the jenkins-admin team observed that when running Jenkins on FreeBSD 10, the Java virtual machine from the openjdk6 or openjdk7 port would coredump regularly. See item #10 here: https://wiki.freebsd.org/Jenkins On the advice of Jung-uk Kim, I put the following in /boot/loader.conf: vm.pmap.pcid_enabled=0 and rebooted. After that, the Java coredumping problems went away. Can someone with VM expertise look into this problem and suggest a fix? There are many reports of Java coredumping on FreeBSD 10, such as this one: http://lists.freebsd.org/pipermail/freebsd-java/2014-March/010606.html It would be good to fix this, so that Java works out of the box on FreeBSD 10. It's not good when kernel tunables need to be set so that Java can work. :( Thanks. -- Craig ___ 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 ___ 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: vm.pmap.pcid_enabled=1 causes Java to coredump in FBSD 10
I previously sent the same e-mail and CC'd it to kib, pho, alc, jkim, davidxu, delphij, attilio,, freebsd-current, freebsd-java but for some reason that e-mail ended up in moderation, and the list-owner rejected the e-mail from going through. -- Craig On Mon, Mar 3, 2014 at 5:03 PM, Adrian Chadd adr...@freebsd.org wrote: Cool. DOn't be afraid to poke alc (cc'ed); he may have some insights. :) -a On 3 March 2014 17:02, Craig Rodrigues rodr...@freebsd.org wrote: Hi, http://www.freebsd.org/cgi/query-pr.cgi?pr=187238 -- Craig On Mon, Mar 3, 2014 at 3:49 PM, Adrian Chadd adr...@freebsd.org wrote: Have you filed a PR? :-P -a On 3 March 2014 14:09, Craig Rodrigues rodr...@freebsd.org wrote: [Resending] Hi, As part of the Jenkins deployment in the FreeBSD cluster the jenkins-admin team observed that when running Jenkins on FreeBSD 10, the Java virtual machine from the openjdk6 or openjdk7 port would coredump regularly. See item #10 here: https://wiki.freebsd.org/Jenkins On the advice of Jung-uk Kim, I put the following in /boot/loader.conf: vm.pmap.pcid_enabled=0 and rebooted. After that, the Java coredumping problems went away. Can someone with VM expertise look into this problem and suggest a fix? There are many reports of Java coredumping on FreeBSD 10, such as this one: http://lists.freebsd.org/pipermail/freebsd-java/2014-March/010606.html It would be good to fix this, so that Java works out of the box on FreeBSD 10. It's not good when kernel tunables need to be set so that Java can work. :( Thanks. -- Craig ___ 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 ___ 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: lockmgr still held [tmpfs] [vm_map_remove()-vdropl()] (r262186: Thu Feb 20)
On 3/3/2014 12:06 PM, John Baldwin wrote:
On Sunday, March 02, 2014 10:58:45 am Bryan Drewery wrote:
On 2/28/2014 3:18 PM, John Baldwin wrote:
On Friday, February 28, 2014 9:18:51 am Bryan Drewery wrote:
While using poudriere:
Unread portion of the kernel message buffer:
panic: lockmgr still held
cpuid = 12
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe124804f7a0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124804f850
vpanic() at vpanic+0x126/frame 0xfe124804f890
kassert_panic() at kassert_panic+0x139/frame 0xfe124804f900
lockdestroy() at lockdestroy+0x3b/frame 0xfe124804f920
vdropl() at vdropl+0x1c8/frame 0xfe124804f960
vm_object_deallocate() at vm_object_deallocate+0x10b/frame
0xfe124804f9c0
vm_map_process_deferred() at vm_map_process_deferred+0x89/frame
0xfe124804f9f0
vm_map_remove() at vm_map_remove+0xc8/frame 0xfe124804fa20
vmspace_exit() at vmspace_exit+0xc9/frame 0xfe124804fa60
exit1() at exit1+0x541/frame 0xfe124804fad0
sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe124804fae0
ia32_syscall() at ia32_syscall+0x270/frame 0xfe124804fbf0
Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe124804fbf0
--- syscall (1, FreeBSD ELF32, sys_sys_exit), rip = 0x281014df, rsp =
0xc45c, rbp = 0xc468 ---
#4 0x808c00db in lockdestroy (lk=0xf80a88a285f0) at
/usr/src/sys/kern/kern_lock.c:440
440 KASSERT(lk-lk_lock == LK_UNLOCKED, (lockmgr still
held));
(kgdb) print *lk
$1 = {lock_object = {lo_name = 0x8201a1bd tmpfs, lo_flags =
116588552, lo_data = 0, lo_witness = 0xfe6fec00}, lk_lock =
18446735288132049184, lk_exslpfail = 0,
lk_timo = 51, lk_pri = 96}
Can you please grab people.freebsd.org/~jhb/gdb/*
and then do 'cd /path/to/files', 'source gdb6', 'frame 4', 'lockmgr_owner
lk'?
(kgdb) lockmgr_owner lk
td: 0xf80272c61920
pid: 55040, p_comm: testprog
Can you get a stack trace of that program? ('proc 55040', 'bt')
It's the same as original:
Loaded symbols for /boot/kernel/sem.ko.symbols
#0 doadump (textdump=1) at pcpu.h:219
219 __asm(movq %%gs:%1,%0 : =r (td)
(kgdb) bt
#0 doadump (textdump=1) at pcpu.h:219
#1 0x808e33a7 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:452
#2 0x808e38b5 in vpanic (fmt=value optimized out, ap=value
optimized out) at /usr/src/sys/kern/kern_shutdown.c:759
#3 0x808e3749 in kassert_panic (fmt=value optimized out) at
/usr/src/sys/kern/kern_shutdown.c:647
#4 0x808c00db in lockdestroy (lk=0xf80a88a285f0) at
/usr/src/sys/kern/kern_lock.c:440
#5 0x80990d38 in vdropl (vp=0xf80a88a28588) at
/usr/src/sys/kern/vfs_subr.c:2417
#6 0x80b73cbb in vm_object_deallocate (object=value optimized out)
at /usr/src/sys/vm/vm_object.c:539
#7 0x80b6a3a9 in vm_map_process_deferred () at
/usr/src/sys/vm/vm_map.c:2763
#8 0x80b6e9c8 in vm_map_remove (map=value optimized out,
start=value optimized out, end=value optimized out) at
/usr/src/sys/vm/vm_map.c:488
#9 0x80b6a179 in vmspace_exit (td=0xf80272c61920) at
/usr/src/sys/vm/vm_map.c:327
#10 0x808a7411 in exit1 (td=0xf80272c61920, rv=value optimized
out) at /usr/src/sys/kern/kern_exit.c:319
#11 0x808a6ece in sys_sys_exit (td=0x0, uap=value optimized out) at
/usr/src/sys/kern/kern_exit.c:119
#12 0x80dd2720 in ia32_syscall (frame=0xfe124804fc00) at
subr_syscall.c:133
#13 0x80cd6325 in Xint0x80_syscall () at ia32_exception.S:73
#14 0x281014df in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language: auto; currently minimal
(kgdb) proc 55040
[Switching to thread 668 (Thread 100898)]#0 doadump (textdump=1) at
pcpu.h:219
219 __asm(movq %%gs:%1,%0 : =r (td)
(kgdb) bt
#0 doadump (textdump=1) at pcpu.h:219
#1 0x808e33a7 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:452
#2 0x808e38b5 in vpanic (fmt=value optimized out, ap=value
optimized out) at /usr/src/sys/kern/kern_shutdown.c:759
#3 0x808e3749 in kassert_panic (fmt=value optimized out) at
/usr/src/sys/kern/kern_shutdown.c:647
#4 0x808c00db in lockdestroy (lk=0xf80a88a285f0) at
/usr/src/sys/kern/kern_lock.c:440
#5 0x80990d38 in vdropl (vp=0xf80a88a28588) at
/usr/src/sys/kern/vfs_subr.c:2417
#6 0x80b73cbb in vm_object_deallocate (object=value optimized out)
at /usr/src/sys/vm/vm_object.c:539
#7 0x80b6a3a9 in vm_map_process_deferred () at
/usr/src/sys/vm/vm_map.c:2763
#8 0x80b6e9c8 in vm_map_remove (map=value optimized out,
start=value optimized out, end=value optimized out) at
/usr/src/sys/vm/vm_map.c:488
#9 0x80b6a179 in vmspace_exit (td=0xf80272c61920) at
/usr/src/sys/vm/vm_map.c:327
#10 0x808a7411 in exit1
Re: vm.pmap.pcid_enabled=1 causes Java to coredump in FBSD 10
... likely too many CC's. -a On 3 March 2014 17:18, Craig Rodrigues rodr...@freebsd.org wrote: I previously sent the same e-mail and CC'd it to kib, pho, alc, jkim, davidxu, delphij, attilio,, freebsd-current, freebsd-java but for some reason that e-mail ended up in moderation, and the list-owner rejected the e-mail from going through. -- Craig On Mon, Mar 3, 2014 at 5:03 PM, Adrian Chadd adr...@freebsd.org wrote: Cool. DOn't be afraid to poke alc (cc'ed); he may have some insights. :) -a On 3 March 2014 17:02, Craig Rodrigues rodr...@freebsd.org wrote: Hi, http://www.freebsd.org/cgi/query-pr.cgi?pr=187238 -- Craig On Mon, Mar 3, 2014 at 3:49 PM, Adrian Chadd adr...@freebsd.org wrote: Have you filed a PR? :-P -a On 3 March 2014 14:09, Craig Rodrigues rodr...@freebsd.org wrote: [Resending] Hi, As part of the Jenkins deployment in the FreeBSD cluster the jenkins-admin team observed that when running Jenkins on FreeBSD 10, the Java virtual machine from the openjdk6 or openjdk7 port would coredump regularly. See item #10 here: https://wiki.freebsd.org/Jenkins On the advice of Jung-uk Kim, I put the following in /boot/loader.conf: vm.pmap.pcid_enabled=0 and rebooted. After that, the Java coredumping problems went away. Can someone with VM expertise look into this problem and suggest a fix? There are many reports of Java coredumping on FreeBSD 10, such as this one: http://lists.freebsd.org/pipermail/freebsd-java/2014-March/010606.html It would be good to fix this, so that Java works out of the box on FreeBSD 10. It's not good when kernel tunables need to be set so that Java can work. :( Thanks. -- Craig ___ 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 ___ 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: UDP Lite support
On Sun, Mar 2, 2014 at 4:23 PM, Joe Nosay superbisq...@gmail.com wrote: On Sun, Mar 2, 2014 at 4:04 PM, Joe Nosay superbisq...@gmail.com wrote: On Sun, Mar 2, 2014 at 3:20 PM, Joe Nosay superbisq...@gmail.com wrote: On Sun, Mar 2, 2014 at 3:19 PM, Joe Nosay superbisq...@gmail.comwrote: On Sun, Mar 2, 2014 at 3:08 PM, Xin Li delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 3/2/14, 10:42 AM, Joe Nosay wrote: On Thu, Feb 27, 2014 at 3:22 AM, Joe Nosay superbisq...@gmail.com wrote: On Wed, Feb 26, 2014 at 11:19 PM, Xin Li delp...@delphij.net wrote: On 02/26/14 18:52, Joe Nosay wrote: On Wed, Feb 26, 2014 at 9:19 PM, Brooks Davis bro...@freebsd.org wrote: On Wed, Feb 26, 2014 at 07:36:29PM -0500, Joe Nosay wrote: The last thread on this was in 2006. Has it ever been reconsidered or is the likelihood of too many damaged packets the reason for not supporting? I'm not sure where to put this question. Apologies for the noise. You've provided next to no context. What is the question? What thread are you referring to? If this is the usual UDP then freebsd-net would be vastly more appropriate than -current. -- Brooks Thanks. I will ask kevlo and maybe bring it up on freebsd-net. It has to do with an implementation of the JACK server using UDP Lite for transferring data. http://freebsd.1045724.n5.nabble.com/UDP-lite-for-FreeBSD-td4010236.html Looks like nobody proposed a patch? I think the concern was that this is not very useful in real-world scenarios due to link layer error detection mechanism but that doesn't raise a red flag to me assuming this is sufficiently self contained feature as it would improve compatibility with other operating systems. Cheers, https://github.com/torelizer/jack_trauma Not my project; but, I want to port it to FreeBSD. First is to get it to build from source. Use your raspberry pi with FreeBSD to broadcast your tunes and all. Thanks for all of the input. The project is being reworked to improve the code. Kevin Lo have a patchset but needs someone to do performance testing (its impact on non-UDPLite applications), test with vimage, etc: http://people.freebsd.org/~kevlo/udplite.diff http://people.freebsd.org/~kevlo/udp-v.diff Are you interested in working on these and report back? Cheers, -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTE4+mAAoJEJW2GBstM+nsthoQAIW67l7yDfIPvxDsNIWWJcRd 8brFYCAOPYE4LpuLGjtSgy370aBe9JmwAm41tE4qF0WhGpcu6TLsKjgMGWa/lHCc JId8+WBfbbQT8XJj/d+3oOETn5/rglvlRhJbnNIwaQpTXxuMC5oz2nGW7rIpIkaA OHo0D20DzGj4nxrQvijZ7DsMkk3F+KJu/4p7M6lpsIPCakknW1WD7IHRfbZ4Oldz 2xH4HfIk7cAdA7i/YUNjlpSgWFQ5OU03J5HAYfC6W37wiGbjdBYf/PKVhJ8hz7+D OCl+yCV00u4fCjlY6zXFea9pGr7Cl1P+sapwKDZ4g+NpNHxBUVY+ahbjQUHYON2W sdzAsLpMMqavCr1o8mcXdm7IPRlLUK9QZUySC9DitPvoF8G2llTAz1mWa4/Oj7/S JMiUERcaL5gdFN8EgEKkamFgLJguYquAjGtiowa51EMbnZG0Q2yWUcrEBFHWBEZT RW1u6r4ChIrPE9X5ljfFpQyKG6jFhYFXG+iVlgTB7F2ZWhjPAXi/tLbBnvIcci1m Md4XFm/bBJj/yNXdPuCi+CtvvdpZ/d4LQn4B7By5bIo1QjCb4Zx5n2Tq5xnYZUOI CnSVnNSkwLbbrAVtYOVWnrSuwR33JQnqeGHdM+XYBBwKBRhrx+ZgFWD7N6Gm95PU xXSxkgYVXI4sgi7Lh3Ia =2Vmc -END PGP SIGNATURE- I have on patch file that Lo sent. Three different files are on it with the assumption that the patch-root is /usr/src. I'm thinking about snipping it twice and then applying each subpatch within the proper subdirectory. Now, this would not when Index:reference is at the header of each, right? One not one in first sentence. Insert hurt between not when in last sentence. I'm doing patch -p *.diff and the process is taking some time. What am I doing wrong? Syntax. Rebuild reinstall the source portions in common then find an application that uses udplite, right? Du. Thanks. Yuhhh There is x264 and wireshark as my available options for testing if udp lite works. Give me a moment because I have a single machine and need to setup a virtual graphics card. ___ 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
