Re: Proposal: Disable compression of newsyslog by default

Xin Li wrote on 2023-12-22 at 23:18:23: > Inspired by D42961, I propose that we move forward with disabling the > compression by default in newsyslog, as implemented in > https://reviews.freebsd.org/D43169 [...] > Therefore I would propose that we change the default compression setting > to "n

Re: 1 year src-patch anniversary!

Mateusz Guzik wrote on 2023-01-29 at 23:29:48: > On 1/29/23, Jamie Landeg-Jones wrote: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix > > to an admittedly trivial issue, but it's soon going to hit one year old, > > and has not had any feedback. Not even "this is ru

Re: Ordering of files in zoneinfo

Xin LI wrote: > I have took a look at the change history, it seems that the find > operation was introduced in r245265 > (brooks@, > to support packaged base) and sort was initially implemented as find -s > in r289451 >

Re: ZFS - Abyssal slow on copying

"O. Hartmann" wrote: > Running 12-CURRENT (FreeBSD 12.0-CURRENT #32 r306579: Sun Oct 2 09:34:50 > CEST 2016 ), I > have a NanoBSD setup which creates an image for a router device. > > The problem I face is related to ZFS. The system has a system's SSD (Samsung > 850 Pro, > 256GB) which has an

Re: how to recycle Inact memory more aggressively?

Gary Jennejohn wrote: > In the course of the last year or so the behavior of the vm system > has changed in regard to how aggressively Inact memory is recycled. > > My box has 8GB of memory. At the moment I'm copying 100s of gigabytes > from one file system to another one. > > Looking at top I

Re: panic: devfs_fsync: vop_stdfsync failed.

Fabian Keil wrote: > I got the following panic by impatiently unplugging a device while a > msdosfs partition on it was in the process of getting unmounted: > > Unread portion of the kernel message buffer: > [368] Device IPOD went missing before all of the data could be written t

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

Fabian Keil wrote: > Konstantin Belousov wrote: > > > On Wed, Dec 16, 2015 at 04:09:17PM +0100, Fabian Keil wrote: > > > Thanks. I'm currently testing the patch on three systems but it may take > > > a while ... > > > > > > > Be

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

Konstantin Belousov wrote: > On Wed, Dec 16, 2015 at 04:09:17PM +0100, Fabian Keil wrote: > > Thanks. I'm currently testing the patch on three systems but it may take a > > while ... > > > > Better use mjg' patch with the small adjustmen

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

Konstantin Belousov wrote: > On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote: > > Konstantin Belousov wrote: > > > It is the values of *p and *(p->p_pgrp) that are needed, from the frame > > > 8. > > > > Unfortunately it's not

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

Oliver Pinter wrote: > Yes, it's a HardenedBSD commit. Currently only a workaround, because I have > now lesser time for the real fix in this month. > > Are you running on ZFS? Yes. Fabian pgpuOBy_BlV8u.pgp Description: OpenPGP digital signature

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

Oliver Pinter wrote: > Is this with latest 11-CURRENT or 10-STABLE? > > Or contains the ad578c311ef commit? The panic is from a system based on 11-CURRENT r290926. Is ad578c311ef a HardenedBSD commit? It doesn't seem to exist in https://github.com/freebsd/freebsd.git. Fabian pgpHRlok72ddQ.p

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

Konstantin Belousov wrote: > On Tue, Dec 15, 2015 at 05:42:38PM +0100, Fabian Keil wrote: > > I've seen the following panic a couple of times in the last three > > months, usually while poudriere was running and with sh being the > > current process. > > > &

fork_findpid() - Fatal trap 12: page fault while in kernel mode

I've seen the following panic a couple of times in the last three months, usually while poudriere was running and with sh being the current process. This one is from a system based on r290926 running with kern.randompid=9001 and forking frequently (>1000 forks/second) due to poudriere and afl-fuzz

panic: devfs_fsync: vop_stdfsync failed.

I got the following panic by impatiently unplugging a device while a msdosfs partition on it was in the process of getting unmounted: Unread portion of the kernel message buffer: [368] Device IPOD went missing before all of the data could be written to it; expect data loss. [368] fsync: giving up

Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

Konstantin Belousov wrote: > On Sun, Dec 06, 2015 at 06:51:36PM +0100, Fabian Keil wrote: > > > > #16 0x80877d5a in bcopy () at > > > > /usr/src/sys/amd64/amd64/support.S:118 > > > > #17 0x805f64e8 in uiomove_faultflag (cp=, >

Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

Konstantin Belousov wrote: > On Sun, Dec 06, 2015 at 11:45:32AM +0100, Fabian Keil wrote: > > I got the following panic while trying to import a ZFS pool from a > > geli-encrypted memory disk backed by a file located on a msdosfs partition: > > > I smiled. I occasi

panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

I got the following panic while trying to import a ZFS pool from a geli-encrypted memory disk backed by a file located on a msdosfs partition: (kgdb) where #0 doadump (textdump=0) at pcpu.h:221 #1 0x80314c1b in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_

Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock

Fabian Keil wrote: > Xin Li wrote: > > > On 9/7/14 11:23 PM, Fabian Keil wrote: > > > Xin Li wrote: > > > > > >> On 9/7/14 9:02 PM, Fabian Keil wrote: > > >>> Using a kernel built from FreeBSD 11.0-CU

Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock

Xin Li wrote: > On 9/7/14 11:23 PM, Fabian Keil wrote: > > Xin Li wrote: > > > >> On 9/7/14 9:02 PM, Fabian Keil wrote: > >>> Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got > >>> the following panic yesterday: > >>&

Re: panic: getblk: size(131072) > MAXBCACHEBUF(65536)

Mark Johnston wrote: > On Thu, Oct 01, 2015 at 03:23:56PM +0200, Fabian Keil wrote: > > Shortly after upgrading to a kernel based on r288437 I got the following > > panic: > > > > Unread portion of the kernel message buffer: > > [5112] panic: getblk:

panic: getblk: size(131072) > MAXBCACHEBUF(65536)

Shortly after upgrading to a kernel based on r288437 I got the following panic: Unread portion of the kernel message buffer: [5112] panic: getblk: size(131072) > MAXBCACHEBUF(65536) [...] (kgdb) where #0 doadump (textdump=0) at pcpu.h:221 #1 0x8030ca9e in db_dump (dummy=, dummy2=false,

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #388 - Still Failing

Warner Losh wrote: > On Fri, Aug 28, 2015 at 4:18 AM, wrote: > > > gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/boot/i386/gptboot/../../libstand32/libstand.a(qdivrem.o)' > > is incompatible with i386 output > > > > This might be due to my bsd.stand.mk stuff. However, since gcc 4.9 is > non-

Re: mount(1) at boot hangs in spa_namespace_lock

Andriy Gapon wrote: > On 20/08/2015 00:07, Jens Schweikhardt wrote: > > Gang, > > > > for a few weeks now I can't get a CURRENT system to boot. I am using the > > zfsloader and have root fs on ZFS. This has worked flawlessly for more > > than a year. > > > > The last message printed is "Mountin

geli AES-XTS provider attachment broken after r285336 (was: svn commit: r285336 - in head/sys: netipsec opencrypto)

"Matthew D. Fuller" wrote: > On Thu, Jul 09, 2015 at 06:16:36PM + I heard the voice of > George V. Neville-Neil, and lo! it spake thus: > > New Revision: 285336 > > URL: https://svnweb.freebsd.org/changeset/base/285336 > > > > Log: > > Add support for AES modes to IPSec. These modes work

Re: how do I downgrade from 11-current to 10-stable

Erich Dollansky wrote: > On Sat, 30 May 2015 05:52:56 -0400 > Aryeh Friedman wrote: > > > My desktop machine is 11-current and I want to down grade it to > > 10-stable how do I do this without needing a reinstall? > > > > I did this several times from sources. Be aware of one problem which >

Re: async pass(4) patches available

"Kenneth D. Merry" wrote: > On Tue, Apr 07, 2015 at 13:16:04 +0200, Fabian Keil wrote: > > "Kenneth D. Merry" wrote: > > > > > On Mon, Apr 06, 2015 at 15:39:56 +0200, Fabian Keil wrote: > > > > "Kenneth D. Merry" wrote: > &g

Re: async pass(4) patches available

"Kenneth D. Merry" wrote: > On Mon, Apr 06, 2015 at 15:39:56 +0200, Fabian Keil wrote: > > "Kenneth D. Merry" wrote: > > > > > I have put patches to add an asynchronous interface to the pass(4) > > > driver and add a new camdd(8) utili

Re: async pass(4) patches available

"Kenneth D. Merry" wrote: > I have put patches to add an asynchronous interface to the pass(4) driver > and add a new camdd(8) utility here: > > FreeBSD/head as of SVN revision 280857: > > http://people.freebsd.org/~ken/async_pass.head.20150330.1.txt [...] > Comments and testing are welcome! A

Re: URGENT: RNG broken for last 4 months

John-Mark Gurney wrote: > Oliver Pinter wrote this message on Tue, Feb 17, 2015 at 23:27 +0100: > > On Tue, Feb 17, 2015 at 11:19 PM, Fabian Keil > > wrote: > > > John-Mark Gurney wrote: > > > > > >> If you are running a current kernel r273872 o

Re: URGENT: RNG broken for last 4 months

John-Mark Gurney wrote: > If you are running a current kernel r273872 or later, please upgrade > your kernel to r278907 or later immediately and regenerate keys. I tried ... start_init: trying /sbin/init <118>[20] Setting hostuuid: [...] <118>[20] Setting hostid: [... [20] [20] [20] Fatal tra

Re: Devops question: unattended installs of FreeBSD?

Jamie Landeg-Jones wrote: > Craig Rodrigues wrote: > > > I had a devops person who is familiar with setting up hundreds of > > Linux nodes in cloud environment ask me what is the best way > > to do unattended installs in a cloud environment. > > Linux has kickstart installs, which are quite use

Re: Panic after USB deadlock followed by kldunload umass.ko

Fabian Keil wrote: > Hans Petter Selasky wrote: > > > On 10/23/14 16:28, Fabian Keil wrote: > > > > kldunload umass.ko lead to a panic, dumping didn't work. > > > > > > Screenshots are available at: > > > http://www.fabiankeil.de/bilder

Re: "geli: Wrong key" with a simple passphrase. Doesn't handle the keyboard input

Aurelien Martin <01aurel...@gmail.com> wrote: > Is there people that can try to geli an external USB disk with a simple > passphrase on CURRENT and tell me if the passphrase prompt shown the input, > and if it's possible to attach it ? > > # uname -a > FreeBSD 11.0-CURRENT FreeBSD 11.0-C

Re: sh: "local" assignment from command loses exit status

Eric van Gyzen wrote: > On 11/06/2014 12:30, Fabian Keil wrote: > > Eric van Gyzen wrote: > > > >> In sh, if I use a single statement to declare a local variable and > >> assign the output of a command to it, the exit status of that c

Re: sh: "local" assignment from command loses exit status

Eric van Gyzen wrote: > In sh, if I use a single statement to declare a local variable and > assign the output of a command to it, the exit status of that command is > lost. For example: > > should_return_false() { > local var1=`false` > } > > The function should return non-zer

Re: Order of geli "passphrase prompt" on boot

Kurt Jaeger wrote: > > If you don't need any USB devices to boot, you can delay their > > detection by loading the modules through /etc/rc.d/kld instead > > of the loader: > > > > fk@r500 ~ $grep kld /etc/rc.conf > > kld_list="usb.ko usb_quirk.ko ehci.ko umass.ko" > > Does this really help with

Re: Order of geli "passphrase prompt" on boot

Miguel Clara wrote: > Sorry to bring this one back but I see no changes have been made to this in > current. > > The issue is that USB devices are detected after the geli prompt and so the > "geli paraphrase" prompt becomes hidden, and the simple solution would be > to change the order the promp

Re: CTF: geom gate network patch

John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Fri, Oct 17, 2014 at 09:58 -0700: > > I did some work at this a while back... and if you're interested in > > improving performance and willing to do some testing... I can send you > > some patches.. > > > > There are a couple is

Re: Panic after USB deadlock followed by kldunload umass.ko

Hans Petter Selasky wrote: > On 10/23/14 16:28, Fabian Keil wrote: > > kldunload umass.ko lead to a panic, dumping didn't work. > > > > Screenshots are available at: > > http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r273434-usb/ > > > > I'

Panic after USB deadlock followed by kldunload umass.ko

A few days ago a couple of usbconfig processed did not exit: fk@r500 ~ $sudo procstat -kk $(pgrep usbconfig) PIDTID COMM TDNAME KSTACK 1624 100781 usbconfig-mi_switch+0xe1 sleepq_wait+0x3a _sx_xlock_hard+0x522 _sx_xlock+0

Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock

Xin Li wrote: > On 9/7/14 11:23 PM, Fabian Keil wrote: > > Xin Li wrote: > > > >> On 9/7/14 9:02 PM, Fabian Keil wrote: > >>> Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got > >>> the following panic yesterday: > >>> &g

Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock

Xin Li wrote: > On 9/7/14 9:02 PM, Fabian Keil wrote: > > Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got the > > following panic yesterday: > > > > [...] Unread portion of the kernel message buffer: [6880] panic: > > deadlkres: possible deadloc

ZFS-related panic: "possible" spa->spa_errlog_lock deadlock

Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got the following panic yesterday: [...] Unread portion of the kernel message buffer: [6880] panic: deadlkres: possible deadlock detected for 0xf80015289490, blocked for 1800503 ticks [6880] [6880] cpuid = 1 [6880] KDB: stack backtrace

Re: getenv("TZ") crashes triggered by tzset_basic()

Trond Endrestøl wrote: > On Thu, 3 Jul 2014 14:01+0200, Fabian Keil wrote: > > > Using HEAD, www/gatling reproducible crashes for me after receiving > > a single request if TZ isn't set: > > > > (gdb) where > > #0 strncmp (s1=, s2=, n=) at > &g

getenv("TZ") crashes triggered by tzset_basic()

Using HEAD, www/gatling reproducible crashes for me after receiving a single request if TZ isn't set: (gdb) where #0 strncmp (s1=, s2=, n=) at /usr/src/lib/libc/string/strncmp.c:46 #1 0x0008011a9ffe in strncmpeq (nameValue=0x7fffeb5e "LC_PAPER=de_DE.UTF-8", name=0x8011be49e "TZ", nameL

Re: Ordering for network-sensitive rc scripts

David Chisnall wrote: > On 11 May 2014, at 20:23, Adrian Chadd wrote: > > > On 11 May 2014 12:01, David Chisnall wrote: > >> On 17 Apr 2014, at 09:30, Adrian Chadd wrote: > >> > >>> Can't we add a devd hook to do that? > >> > >> I tried doing this, but it turns out that wlan devices don't a

Re: Fatal double fault in ZFS with yesterday's CURRENT [SOLVED]

"Steven Hartland" wrote: > Thanks for your help testing this Fabian, I've now committed the fix for > this for this: > http://svnweb.freebsd.org/changeset/base/265321 Thanks a lot, Steve. Fabian signature.asc Description: PGP signature

Re: Fatal double fault in ZFS with yesterday's CURRENT

"Steven Hartland" wrote: > > "Steven Hartland" wrote: > > > > > From: "Fabian Keil" > > > > > > > After updating my laptop to yesterday's CURRENT (r265216), > > > > I got the following fatal d

Re: Fatal double fault in ZFS with yesterday's CURRENT

"Steven Hartland" wrote: > From: "Fabian Keil" > > > After updating my laptop to yesterday's CURRENT (r265216), > > I got the following fatal double fault on boot: > > http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r265216/ > > &

Fatal double fault in ZFS with yesterday's CURRENT

After updating my laptop to yesterday's CURRENT (r265216), I got the following fatal double fault on boot: http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r265216/ My previous kernel was based on r264721. I'm using a couple of custom patches, some of them are ZFS-related and thus may be part

Re: claws-mail deadlocking in iconv

Fabian Keil wrote: > After the iconv import claws-mail started to deadlock in iconv every now > and then on my system, which prevented claws-mail from rendering windows > or reacting to input. [...] > Did anyone else run into this or can comment on the patch or > the backtraces?

claws-mail deadlocking in iconv

After the iconv import claws-mail started to deadlock in iconv every now and then on my system, which prevented claws-mail from rendering windows or reacting to input. So far I haven't been able to reproduce this intentionally and various rebuilds of ports, kernel and userland (mainly for other re

Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking

Alexander Motin wrote: > I would like to invite more people to review and test my patches for > improving CAM and GEOM scalability, that for last six months you could > see developing in project/camlock SVN branch. Full diff of that branch > against present head (r255131) can be found here: >

Re: Improved SYN Cookies: Looking for testers

Andre Oppermann wrote: > On 12.07.2013 12:56, Fabian Keil wrote: > > Andre Oppermann wrote: > > > >> On 10.07.2013 15:18, Fabian Keil wrote: > >>> Andre Oppermann wrote: > >> It will give a bit of debug log output which is it telling you mostly

Re: Improved SYN Cookies: Looking for testers

Andre Oppermann wrote: > On 10.07.2013 15:18, Fabian Keil wrote: > > Andre Oppermann wrote: > > > >> We have a SYN cookie implementation for quite some time now but it > >> has some limitations with current realities for window scaling and > >> S

Re: Improved SYN Cookies: Looking for testers

Andre Oppermann wrote: > We have a SYN cookie implementation for quite some time now but it > has some limitations with current realities for window scaling and > SACK encoding the in the few available bits. > > This patch updates and improves SYN cookies mainly by: > > a) encoding of MSS, WS

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

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 0x

Re: 7+ days of dogfood

Glen Barber wrote: > On Mon, Feb 11, 2013 at 02:56:47PM +0100, Fabian Keil wrote: > > > WITHOUT_GCC=yes in src.conf is > > > worthwhile. WITHOUT_GDB=yes is probably also sensible, as the gdb in > > > base is so old that it doesn&

Re: 7+ days of dogfood

David Chisnall wrote: > On 11 Feb 2013, at 13:56, Fabian Keil > wrote: > > > real350m42.363s > > user253m5.477s > > sys 50m0.024s > > These numbers look a bit wrong. You've got 300 minutes of CPU time, but > 350 minutes of real time. In

Re: 7+ days of dogfood

David Chisnall wrote: > On 11 Feb 2013, at 10:48, Fabian Keil > wrote: > > > It's unfortunate that the builworld time roughly trippled since > > 2010 but I guess that's progress and a more powerful system > > should fix it. I certainly welcome clang in gen

Re: 7+ days of dogfood

Erich Dollansky wrote: > On Mon, 11 Feb 2013 11:48:11 +0100 > Fabian Keil wrote: > > It's unfortunate that the builworld time roughly trippled since > > 2010 but I guess that's progress and a more powerful system > > should fix it. I certainly welcome clang i

Re: 7+ days of dogfood

Steve Kargl wrote: > In a long thread started by Peter Wemm on developers@, he described > the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10. A > part of his description included the need to test top-of-tree under > actual real-world conditions. In his words, FreeBSD should "eat i

Re: geli(8) breaks after a couple hours of uptime

Pawel Jakub Dawidek wrote: > On Sun, Feb 10, 2013 at 09:50:58AM +0200, Andriy Gapon wrote: > > I think that PAGE_SIZE (or at most a small multiple of it) should be > > sufficient. I don't think that we currently have (or expect to see in > > the near future) algorithms where keys with more than

Destroying ZFS snapshots "too quickly": xpt_scan_lun: can't allocate CCB, can't continue

Before the introduction of async_destroy I wrote a script to destroy ZFS snapshots in parallel to speed up the process. It's available at: http://www.fabiankeil.de/sourcecode/zfs-snapshot-destroyer/zsd.pl A couple of years ago the only downside seemed to be that it requires more memory and file de

Re: Physbio changes final call for tests and reviews

Konstantin Belousov wrote: > I finished the last (insignificant) missed bits in the Jeff' physbio > work. Now I am asking for the last round of testing and review, esp. for > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID > controllers which drivers are changed by the pa

Re: geli(8) breaks after a couple hours of uptime

Eitan Adler wrote: > On 8 February 2013 07:46, Andriy Gapon wrote: > > on 08/02/2013 13:48 Ulrich Spörlein said the following: > >> It looks like 128k as a limit is still too low for geli(8) to work, and > >> I've set it to 256k now, so that I can use "sudo geli". Can you maybe > >> revise the

Re: geli(8) breaks after a couple hours of uptime

Ulrich Spörlein wrote: > On Thu, 2013-02-07 at 15:33:22 +0100, Fabian Keil wrote: > > Ulrich Spörlein wrote: > > > > > Yes, it's pretty much as weird as it sounds. All new machine, forklifted > > > the image from on old i386 machine running 8.x to cur

Re: geli(8) breaks after a couple hours of uptime

Ulrich Spörlein wrote: > Yes, it's pretty much as weird as it sounds. All new machine, forklifted > the image from on old i386 machine running 8.x to current on amd64. > > Everything seemingly works fine, attaching geli volumes shortly after > boot is fine, attached devices continue to work fine

Re: Zpool surgery

Dan Nelson wrote: > In the last episode (Jan 28), Fabian Keil said: > > Ulrich Spörlein wrote: > > > On Mon, 2013-01-28 at 07:11:40 +1100, Peter Jeremy wrote: > > > > On 2013-Jan-27 14:31:56 -, Steven Hartland > > > > wrote: > > > >

Re: Zpool surgery

Ulrich Spörlein wrote: > On Mon, 2013-01-28 at 07:11:40 +1100, Peter Jeremy wrote: > > On 2013-Jan-27 14:31:56 -, Steven Hartland > > wrote: > > >- Original Message - > > >From: "Ulrich Spörlein" > > >> I want to transplant my old zpool tank from a 1TB drive to a new 2TB > > >> dr

Re: Zpool surgery

Ulrich Spörlein wrote: > I have a slight problem with transplanting a zpool, maybe this is not > possible the way I like to do it, maybe I need to fuzz some > identifiers... > > I want to transplant my old zpool tank from a 1TB drive to a new 2TB > drive, but *not* use dd(1) or any other cloning

Re: disk "flipped" - a known problem?

Andriy Gapon wrote: > Today something unusual happened on one of my machines: > kernel: (ada0:ahcich0:0:0:0): lost device > kernel: (aprobe1:ahcich0:0:15:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 > 00 > kernel: (aprobe1:ahcich0:0:15:0): CAM status: Command timeout > kernel: (aprobe1:ahcich0

Re: "make buildworld" failures with NO_KERBEROS=

Steve Kargl wrote: > On Fri, Jan 18, 2013 at 08:54:03PM +0100, Fabian Keil wrote: > > Recently "make buildworld" started failing for me: > > > > 8< > > ===> include/xlocale (installincludes) > > sh /usr/src/tools/install.sh -C -

"make buildworld" failures with NO_KERBEROS=

Recently "make buildworld" started failing for me: 8< ===> include/xlocale (installincludes) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 _ctype.h _inttypes.h _langinfo.h _locale.h _monetary.h _stdio.h _stdlib.h _string.h _time.h _wchar.h /usr/obj/usr/src/tmp/usr/incl

standards/173421: [patch] strptime() accepts formats that should be rejected

Anyone interested in a PR for a strptime() bug coming with a test case and a potential fix? > http://www.freebsd.org/cgi/query-pr.cgi?pr=173421 > > >Category: standards > >Responsible:freebsd-standards > >Synopsis: [patch] strptime() accepts formats that should be rejected > >Arri

Re: ZFS/RAIDZ and SAMBA: abyssimal performance

Garrett Cooper wrote: > On Fri, Jan 4, 2013 at 10:28 AM, Fabian Keil > wrote: > > While I agree that the values are system dependant the purpose of > > the tunables could still be documented together with a description > > of how to properly test that they have an

Re: ZFS/RAIDZ and SAMBA: abyssimal performance

Fleuriot Damien wrote: > > On Jan 4, 2013, at 4:19 PM, O. Hartmann wrote: > > > Am 01/04/13 15:45, schrieb Garrett Cooper: > >> On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien wrote: > >> > >> ... > >> > >>> And this is under [global] in /usr/local/etc/smb.conf: > >>> min receivefile size

Re: Unbreaking gdb's catch throw

Stefan Farfeleder wrote: > gdb's command 'catch throw' is broken on FreeBSD head. While it does set > a breakpoint on __cxa_throw, the function seems to be never entered when > an exception is thrown. Does someone know how to fix this? It used to > work a couple of months ago. My impression is t

Re: [RFC/RFT] calloutng

Fabian Keil wrote: > Alexander Motin wrote: > > > On 20.12.2012 15:26, Fabian Keil wrote: > > > Alexander Motin wrote: > > > > > >> On 20.12.2012 12:56, Fabian Keil wrote: > > >>> Alexander Motin wrote: > > >>> >

Re: [RFC/RFT] calloutng

Alexander Motin wrote: > On 20.12.2012 15:26, Fabian Keil wrote: > > Alexander Motin wrote: > > > >> On 20.12.2012 12:56, Fabian Keil wrote: > >>> Alexander Motin wrote: > >>> > >>>> Experiments with dummynet shown ineffective

Re: [RFC/RFT] calloutng

Alexander Motin wrote: > On 20.12.2012 12:56, Fabian Keil wrote: > > Alexander Motin wrote: > > > >> Experiments with dummynet shown ineffective support for very short > >> tick-based callouts. New version fixes that, allowing to get as many > >> tic

Re: [RFC/RFT] calloutng

Alexander Motin wrote: > Experiments with dummynet shown ineffective support for very short > tick-based callouts. New version fixes that, allowing to get as many > tick-based callout events as hz value permits, while still be able to > aggregate events and generating minimum of interrupts. >

cam-accessing programs locking up

Since a couple of weeks I occasionally notice that a command accessing cd0 hangs and once that happens I haven't found a way to get cd0 working again through software without rebooting. No kernel complaints are logged, but afterwards somewhat related commands hang as well. In this case I noticed

Re: manual page | zpool-features

Darrel wrote: > OpenBSD Packet Filter seems to have broken between 9.0 and 9.1, as it did > from 8.2 to 9.0. I built stable/9 and it was not fixed. Since I like to > run Packet Filter, I ran these commands: > > # cd /usr > # svn co svn://svn.freebsd.org/base/head src > > Then I checked /usr

Re: [HEADSUP] geli(4) weak master key generation on -CURRENT

"Simon L. B. Nielsen" wrote: > On Tue, Aug 21, 2012 at 1:05 PM, Ulrich Spörlein wrote: > > On Mon, 2012-08-20 at 22:24:56 +0100, Simon L. B. Nielsen wrote: > >> -CURRENT users of geli(4) should be advised that, a geli(4) device may > >> have weak master key, if the provider is created on -CURRE

Re: fetch(1) fails with https:// - Authentication error

Doug Barton wrote: > On 07/13/2012 21:21, Jan Beich wrote: > > It seems recent OpenSSL update broke fetch(1) for me. > > > > $ diff -u $SRC_BASE/crypto/openssl/apps/openssl.cnf /etc/ssl/openssl.cnf > > $ fetch https://foo/bar > > fetch: https://foo/bar: Authentication error > > > > Same e

Re: [RFT] llquantize for FreeBSD's dtrace

Pedro Giffuni wrote: > --- Mar 26/6/12, Mark Peek ha scritto: > > Try this, change the assert on line 1429 in file dt_cc.c > > from: > > > > assert(!(arg & (UINT16_MAX << args[i].shift))); > > > > to > > > > assert(!(arg & ((uint64_t)UINT16_MAX << > > args[i].shift))); > > > > This certain

Re: dtrace walltimestamp

Fabian Keil wrote: > At least on my system, timestamp offsets can only can be relied > on with either kern.timecounter.hardware=TSC or with C3 > states disabled, though. > > Measuring the elapsed time (in ms) between events that happen > in roughly 1 sec

Re: [RFT] llquantize for FreeBSD's dtrace

Pedro Giffuni wrote: > Hello Fabian; > > --- Sab 23/6/12, Fabian Keil ha scritto: > > > Pedro Giffuni wrote: > > > > > I am not a Dtrace user (yet) but I started to port the > > Log/linear > > > quantizations from Illumos: > > >

Re: [RFT] llquantize for FreeBSD's dtrace

Pedro Giffuni wrote: > I am not a Dtrace user (yet) but I started to port the Log/linear > quantizations from Illumos: > > http://dtrace.org/blogs/bmc/2011/02/08/llquantize/ > > Apparently this patch should do it: > > http://people.freebsd.org/~pfg/patches/patch-llquantize-complete > > Unfort

Re: DTrace broken on 9.0-Release?

Ryan Goodfellow wrote: > Today I downloaded and installed FreeBSD 9.0-RELEASE and followed the > directions from to get DTrace up and > running. The output of DTrace instrumenting a simple program, however, > is not correct. The program is as follows: > > // te

Re: svn commit: r235478 - head/cddl/contrib/opensolaris/cmd/zpool

Pawel Jakub Dawidek wrote: > On Tue, May 15, 2012 at 05:07:30PM +, Andriy Gapon wrote: > > Author: avg > > Date: Tue May 15 17:07:29 2012 > > New Revision: 235478 > > URL: http://svn.freebsd.org/changeset/base/235478 > > > > Log: > > zpool_do_import: use /dev instead of /dev/dsk as a defau

Re: Default directory used for 'zpool import' broken (/dev/dsk)?

It could have happened with the older version of the > code. I think that you could check that with zdb. I think that a fresh > import should fix it, though. The following patch seems to work for me: commit 7ec69700f2d6944a61f5c7a826e67f46fa160221 Author: Fabian Keil Date: Mon May

Re: Snapshot listing speedup.

Pawel Jakub Dawidek wrote: > If you have many snapshots and you were complaining that listing them > takes a lot of time, you may find the commit below useful. Indeed. > It only works if your listing is limited to snapshot names and you want > to sort also by snapshot name (by default snapshot

Re: Stop scheduler on panic

t;>> On 11/17/11 10:15, Kostik Belousov wrote: > >>>>> On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote: > >>>>>> On 17.11.2011 00:21, Andriy Gapon wrote: > >>>>>>> on 16/11/2011 21:27 Fabian Keil said the followin

Re: Stop scheduler on panic

Kostik Belousov wrote: > I was tricked into finishing the work by Andrey Gapon, who developed > the patch to reliably stop other processors on panic. The patch > greatly improves the chances of getting dump on panic on SMP host. I tested the patch trying to get a dump (from the debugger) for ke

Re: Fatal trap 12: page fault while in kernel mode -- Stopped at atomic_subtract_int+0x4

Fabian Keil wrote: > Fabian Keil wrote: > > > I pretty reproducible get the following (handtranscribed) panic > > when sending an zfs snapshot to geli provider based on an USB > > stick that disappears (due to a bug, or because it's unplugged): > > >

Re: Fatal trap 12: page fault while in kernel mode -- Stopped at atomic_subtract_int+0x4

Fabian Keil wrote: > I pretty reproducible get the following (handtranscribed) panic > when sending an zfs snapshot to geli provider based on an USB > stick that disappears (due to a bug, or because it's unplugged): > > Fatal trap 12: page fault while in kernel mode >

Re: A patch for a bug in the dtrace command...

George Neville-Neil wrote: > I have found that the dtrace command on FreeBSD, in both STABLE and HEAD, > does not print out > aggregations properly, likely due to the difference in how Solaris and > FreeBSD signals work. > For example, this one liner will give no output: > > sudo dtrace -n 'sy

  1   2   >