Re: zfs native encryption best practices on RELENG13

[Xin Li via freebsd-stable]

On 4/23/21 13:53, mike tancsa wrote:
> Starting to play around with RELENG_13 and wanted explore ZFS' built in
> encryption.  Is there a best practices doc on how to do full disk
> encryption anywhere thats not GELI based  ?  There are lots for 
> GELI,
> but nothing I could find for native OpenZFS encryption on FreeBSD
> 
> i.e box gets rebooted, enter in passphrase to allow it to boot kind of
> thing from the boot loader prompt ?

I think loader do not support the native OpenZFS encryption yet.
However, you can encrypt non-essential datasets on a boot pool (that is,
if com.datto:encryption is "active" AND the bootfs dataset is not
encrypted, you can still boot from it).

BTW instead of entering passphrase at loader prompt, if / is not
encrypted, it's also possible to do something like
https://lists.freebsd.org/pipermail/freebsd-security/2012-August/006547.html
.

Personally I'd probably go with GELI (or other kind of full disk
encryption) regardless if OpenZFS's native encryption is used because my
primary goal is to be able to just throw away bad disks when they are
removed from production [1].  If the pool is not fully encrypted, there
is always a chance that the sensitive data have landed some unencrypted
datasets and never gets fully overwritten.

[1] Also keep in mind: https://xkcd.com/538/

Cheers,



OpenPGP_signature
Description: OpenPGP digital signature

Re: [pf] stable/12: block by OS broken

[Xin Li via freebsd-stable]

On 2/17/21 22:57, Xin Li wrote:
> On 2/17/21 22:35, Kristof Provost wrote:
>> On 18 Feb 2021, at 6:01, Xin Li wrote:
>>
>> Hi,
>>
>> It appears that some change between 939430f2377 (December 31) and
>> b4bf7bdeb70 (today) on stable/12 have broken pf in a way that the
>> following rule:
>>
>> block in quick proto tcp from any os "Linux" to any port ssh
>>
>> would get interpreted as:
>>
>> block drop in quick proto tcp from any to any port = 22
>>
>> (and block all SSH connection instead of just the ones initiated from
>> Linux).
>>
>> Thanks for the report. I think I see the problem.
>>
>> Can you test this patch?
>>
>> |diff --git a/sys/netpfil/pf/pf_ioctl.c b/sys/netpfil/pf/pf_ioctl.c
>> index 593a38d4a360..458c6af3fa5e 100644 --- a/sys/netpfil/pf/pf_ioctl.c
>> +++ b/sys/netpfil/pf/pf_ioctl.c @@ -1623,7 +1623,7 @@
>> pf_rule_to_krule(const struct pf_rule *rule, struct pf_krule *krule) /*
>> Don't allow userspace to set evaulations, packets or bytes. */ /* kif,
>> anchor, overload_tbl are not copied over. */ - krule->os_fingerprint =
>> krule->os_fingerprint; + krule->os_fingerprint = rule->os_fingerprint;
>> krule->rtableid = rule->rtableid; bcopy(rule->timeout, krule->timeout,
>> sizeof(krule->timeout)); |
>>
>> With any luck we’ll be able to include the fix in 13.0.
> 
> Thanks, I'll try this on a -CURRENT box which is exhibiting the same
> issue and report back as soon as possible.

And I can confirm that this fixed the issue on -CURRENT, thanks for the
quick fix!

Cheers,



OpenPGP_signature
Description: OpenPGP digital signature

Re: [pf] stable/12: block by OS broken

[Xin Li via freebsd-stable]

On 2/17/21 22:35, Kristof Provost wrote:
> On 18 Feb 2021, at 6:01, Xin Li wrote:
> 
> Hi,
> 
> It appears that some change between 939430f2377 (December 31) and
> b4bf7bdeb70 (today) on stable/12 have broken pf in a way that the
> following rule:
> 
> block in quick proto tcp from any os "Linux" to any port ssh
> 
> would get interpreted as:
> 
> block drop in quick proto tcp from any to any port = 22
> 
> (and block all SSH connection instead of just the ones initiated from
> Linux).
> 
> Thanks for the report. I think I see the problem.
> 
> Can you test this patch?
> 
> |diff --git a/sys/netpfil/pf/pf_ioctl.c b/sys/netpfil/pf/pf_ioctl.c
> index 593a38d4a360..458c6af3fa5e 100644 --- a/sys/netpfil/pf/pf_ioctl.c
> +++ b/sys/netpfil/pf/pf_ioctl.c @@ -1623,7 +1623,7 @@
> pf_rule_to_krule(const struct pf_rule *rule, struct pf_krule *krule) /*
> Don't allow userspace to set evaulations, packets or bytes. */ /* kif,
> anchor, overload_tbl are not copied over. */ - krule->os_fingerprint =
> krule->os_fingerprint; + krule->os_fingerprint = rule->os_fingerprint;
> krule->rtableid = rule->rtableid; bcopy(rule->timeout, krule->timeout,
> sizeof(krule->timeout)); |
> 
> With any luck we’ll be able to include the fix in 13.0.

Thanks, I'll try this on a -CURRENT box which is exhibiting the same
issue and report back as soon as possible.

Cheers,




OpenPGP_signature
Description: OpenPGP digital signature

[pf] stable/12: block by OS broken

[Xin Li via freebsd-stable]

Hi,

It appears that some change between 939430f2377 (December 31) and
b4bf7bdeb70 (today) on stable/12 have broken pf in a way that the
following rule:

block in quick proto tcp from any os "Linux" to any port ssh

would get interpreted as:

block drop in quick proto tcp from any to any port = 22

(and block all SSH connection instead of just the ones initiated from
Linux).

Cheers,



OpenPGP_signature
Description: OpenPGP digital signature

Re: CFT: if_bridge performance improvements

[Xin Li via freebsd-stable]

On 4/24/20 06:42, Kristof Provost wrote:
> On 22 Apr 2020, at 18:15, Xin Li wrote:
>> On 4/22/20 01:45, Kristof Provost wrote:
>>> On 22 Apr 2020, at 10:20, Xin Li wrote:
>>>> Hi,
>>>>
>>>> On 4/14/20 02:51, Kristof Provost wrote:
>>>>> Hi,
>>>>>
>>>>> Thanks to support from The FreeBSD Foundation I’ve been able to
>>>>> work on
>>>>> improving the throughput of if_bridge.
>>>>> It changes the (data path) locking to use the NET_EPOCH
>>>>> infrastructure.
>>>>> Benchmarking shows substantial improvements (x5 in test setups).
>>>>>
>>>>> This work is ready for wider testing now.
>>>>>
>>>>> It’s under review here: https://reviews.freebsd.org/D24250
>>>>>
>>>>> Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true
>>>>> Patches for stable/12:
>>>>> https://people.freebsd.org/~kp/if_bridge/stable_12/
>>>>>
>>>>> I’m not currently aware of any panics or issues resulting from these
>>>>> patches.
>>>>
>>>> I have observed the following panic with latest stable/12 after
>>>> applying
>>>> the stable_12 patchset, it appears like a race condition related NULL
>>>> pointer deference, but I haven't took a deeper look yet.
>>>>
>>>> The box have 7 igb(4) NICs, with several bridge and VLAN configured
>>>> acting as a router.  Please let me know if you need additional
>>>> information; I can try -CURRENT as well, but it would take some time as
>>>> the box is relatively slow (it's a ZFS based system so I can create a
>>>> separate boot environment for -CURRENT if needed, but that would take
>>>> some time as I might have to upgrade the packages, should there be any
>>>> ABI breakages).
>>>>
>>> Thanks for the report. I don’t immediately see how this could happen.
>>>
>>> Are you running an L2 firewall on that bridge by any chance? An earlier
>>> version of the patch had issues with a stray unlock in that code path.
>>
>> I don't think I have a L2 firewall (I assume means filtering based on
>> MAC address like what can be done with e.g. ipfw?  The bridges were
>> created on vlan interfaces though, do they count as L2 firewall?), the
>> system is using pf with a few NAT rules:
>>
> 
> That backtrace looks identical to the one Peter reported, up to and
> including the offset in the bridge_input() function.
> Given that there’s no likely way to end up with a NULL mutex either I
> have to assume that it’s a case of trying to unlock a locked mutex, and
> the most likely reason is that you ran into the same problem Peter ran
> into.
> 
> The current version of the patch should resolve it.

Thanks, I'd like to report that after applying the patch from Peter the
system seems to survive without problem.

Cheers,




signature.asc
Description: OpenPGP digital signature

Re: CFT: if_bridge performance improvements

[Xin Li via freebsd-stable]

On 4/22/20 01:45, Kristof Provost wrote:
> On 22 Apr 2020, at 10:20, Xin Li wrote:
>> Hi,
>>
>> On 4/14/20 02:51, Kristof Provost wrote:
>>> Hi,
>>>
>>> Thanks to support from The FreeBSD Foundation I’ve been able to work on
>>> improving the throughput of if_bridge.
>>> It changes the (data path) locking to use the NET_EPOCH infrastructure.
>>> Benchmarking shows substantial improvements (x5 in test setups).
>>>
>>> This work is ready for wider testing now.
>>>
>>> It’s under review here: https://reviews.freebsd.org/D24250
>>>
>>> Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true
>>> Patches for stable/12:
>>> https://people.freebsd.org/~kp/if_bridge/stable_12/
>>>
>>> I’m not currently aware of any panics or issues resulting from these
>>> patches.
>>
>> I have observed the following panic with latest stable/12 after applying
>> the stable_12 patchset, it appears like a race condition related NULL
>> pointer deference, but I haven't took a deeper look yet.
>>
>> The box have 7 igb(4) NICs, with several bridge and VLAN configured
>> acting as a router.  Please let me know if you need additional
>> information; I can try -CURRENT as well, but it would take some time as
>> the box is relatively slow (it's a ZFS based system so I can create a
>> separate boot environment for -CURRENT if needed, but that would take
>> some time as I might have to upgrade the packages, should there be any
>> ABI breakages).
>>
> Thanks for the report. I don’t immediately see how this could happen.
> 
> Are you running an L2 firewall on that bridge by any chance? An earlier
> version of the patch had issues with a stray unlock in that code path.

I don't think I have a L2 firewall (I assume means filtering based on
MAC address like what can be done with e.g. ipfw?  The bridges were
created on vlan interfaces though, do they count as L2 firewall?), the
system is using pf with a few NAT rules:

$ sudo pfctl -s rules
anchor "miniupnpd" all
pass in quick inet6 proto tcp from  to any flags S/SA keep state
block drop in quick inet6 proto tcp from !  to  flags S/SA
block drop in quick proto tcp from any os "Linux" to any port = ssh
pass out on igb6 inet proto tcp from (igb6) to any port = domain flags
S/SA keep state queue dns
pass out on igb6 inet proto udp from (igb6) to any port = domain keep
state queue dns
pass in on igb6 proto tcp from any to (igb6) port = http flags S/SA
modulate state queue(web, ack)
pass in on igb6 proto tcp from any to (igb6) port = https flags S/SA
modulate state queue(web, ack)
pass out on igb6 inet proto tcp from (igb6) to any flags S/SA modulate
state queue bulk
block drop in quick on igb6 proto tcp from  to any port = ssh
label "ssh bruteforce"
block drop in on igb6 from  to any

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: CFT: if_bridge performance improvements

[Xin Li via freebsd-stable]

Hi,

On 4/14/20 02:51, Kristof Provost wrote:
> Hi,
> 
> Thanks to support from The FreeBSD Foundation I’ve been able to work on
> improving the throughput of if_bridge.
> It changes the (data path) locking to use the NET_EPOCH infrastructure.
> Benchmarking shows substantial improvements (x5 in test setups).
> 
> This work is ready for wider testing now.
> 
> It’s under review here: https://reviews.freebsd.org/D24250
> 
> Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true
> Patches for stable/12: https://people.freebsd.org/~kp/if_bridge/stable_12/
> 
> I’m not currently aware of any panics or issues resulting from these
> patches.

I have observed the following panic with latest stable/12 after applying
the stable_12 patchset, it appears like a race condition related NULL
pointer deference, but I haven't took a deeper look yet.

The box have 7 igb(4) NICs, with several bridge and VLAN configured
acting as a router.  Please let me know if you need additional
information; I can try -CURRENT as well, but it would take some time as
the box is relatively slow (it's a ZFS based system so I can create a
separate boot environment for -CURRENT if needed, but that would take
some time as I might have to upgrade the packages, should there be any
ABI breakages).

===

Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x20
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80c286d5
stack pointer   = 0x28:0x824cb840
frame pointer   = 0x28:0x824cb850
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 0 (if_io_tqg_0)
trap number = 12
panic: page fault
cpuid = 0
time = 1587541913
KDB: stack backtrace:
#0 0x80c117a5 at kdb_backtrace+0x65
#1 0x80bc588e at vpanic+0x17e
#2 0x80bc5703 at panic+0x43
#3 0x810d2310 at trap_pfault+0
#4 0x810d235f at trap_pfault+0x4f
#5 0x810d19b8 at trap+0x288
#6 0x810aae1c at calltrap+0x8
#7 0x80ba5c96 at __mtx_unlock_sleep+0xb6
#8 0x8248f4c7 at bridge_input+0x877
#9 0x80cd5c47 at ether_nh_input+0x207
#10 0x80cf1e4a at netisr_dispatch_src+0xca
#11 0x80cd4f0b at ether_input+0x4b
#12 0x80cdf1a3 at vlan_input+0x1f3
#13 0x80cd4ae1 at ether_demux+0x121
#14 0x80cd5d7b at ether_nh_input+0x33b
#15 0x80cf1e4a at netisr_dispatch_src+0xca
#16 0x80cd4f0b at ether_input+0x4b
#17 0x80cee41c at iflib_rxeof+0xadc
Uptime: 6m6s
Dumping 848 out of 16313
MB:..2%..12%..21%..31%..42%..51%..61%..72%..82%..91%


Backtrace:

(kgdb) #0  doadump () at src/sys/amd64/include/pcpu_aux.h:55
#1  0x80bc54a5 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:451
#2  0x80bc58e6 in vpanic (fmt=,
ap=) at /usr/src/sys/kern/kern_shutdown.c:880
#3  0x80bc5703 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:807
#4  0x810d2310 in trap_fatal (frame=,
eva=) at /usr/src/sys/amd64/amd64/trap.c:925
#5  0x810d235f in trap_pfault (frame=0x824cb780,
usermode=, signo=,
ucode=) at src/sys/amd64/include/pcpu_aux.h:55
#6  0x810d19b8 in trap (frame=0x824cb780)
at /usr/src/sys/amd64/amd64/trap.c:407
#7  0x810aae1c in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:289
#8  0x80c286d5 in turnstile_broadcast (ts=0x0, queue=0)
at /usr/src/sys/kern/subr_turnstile.c:880
#9  0x80ba5c96 in __mtx_unlock_sleep (c=0xf80013351430, v=0)
at /usr/src/sys/kern/kern_mutex.c:1041
#10 0x8248f4c7 in bridge_input (ifp=,
m=) at src/sys/amd64/include/atomic.h:221
#11 0x80cd5c47 in ether_nh_input (m=)
at /usr/src/sys/net/if_ethersubr.c:631
#12 0x80cf1e4a in netisr_dispatch_src (proto=5,
source=, m=)
at /usr/src/sys/net/netisr.c:1124
#13 0x80cd4f0b in ether_input (ifp=0xf800060dc000, m=0x0)
at /usr/src/sys/net/if_ethersubr.c:787
#14 0x80cdf1a3 in vlan_input (ifp=0xf800036d6800,
m=0xf8001d65fc00) at /usr/src/sys/net/if_vlan.c:1291
#15 0x80cd4ae1 in ether_demux (ifp=0xf800036d6800,
m=) at /usr/src/sys/net/if_ethersubr.c:832
#16 0x80cd5d7b in ether_nh_input (m=)
at /usr/src/sys/net/if_ethersubr.c:667
#17 0x80cf1e4a in netisr_dispatch_src (proto=5,
source=, m=)
at /usr/src/sys/net/netisr.c:1124
#18 0x80cd4f0b in ether_input (ifp=0xf800036d6800,
m=0xf80013939c00) at /usr/src/sys/net/if_ethersubr.c:787
#19 0x80cee41c in iflib_rxeof (rxq=,
budget=) at /usr/src/sys/net/iflib.c:2873
#20 0x80ce87b3 in _task_fn_rx (context=0xf800036d6000)
at 

Re: bhyve memory leak in stable/11

[Xin LI]

There are several leaks fixed recently, but not all of them were merged
back to stable/11 (e.g. r341705 which may or may not be related to your
issue).

Personally, I'd recommend updating to 12.x for new features as they are
being actively developed and would be supported for about 3 more years
compared to 11.x series.

On Thu, Nov 14, 2019 at 7:25 AM Eugene Grosbein  wrote:

> Hi!
>
> After 1 day and 11 hours of host's uptime I observe significant leak of
> bhyve instances RSS:
>
>   PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU
> COMMAND
> 8 root 34  200 60320M 58866M kqread 21  62.0H 692.35%
> bhyve: sappdev (bhyve)
>  5546 root 26  200 22573M 22088M kqread 12 310:39   6.41%
> bhyve: srdapp01 (bhyve)
>  3842 root 20  200 15946M 15862M kqread 13 340:36  14.03%
> bhyve: sdc01 (bhyve)
>  4729 root 20  200 13792M 13455M kqread  8  79:40   1.02%
> bhyve: skms01 (bhyve)
>  4283 root 28  200 12721M 12682M kqread 29  92:23   0.80%
> bhyve: sfile01 (bhyve)
>  8057 root 34  200  8512M  8183M kqread 25 186:52  17.02%
> bhyve: ssql01 (bhyve)
> 23336 root 34  200 16418M  7716M kqread 14 114:23  17.62%
> bhyve: solap (bhyve)
>
> The package vm-bhyve-1.2.3 is used here to manage bhyve instances
> and sappdev.conf has memory=40G limit. srdapp01 is limited to 12G,
> sdc01 to 4G, skms01 to 2G, sfile01 to 2G, ssql01 to 8G and solap to 16G.
>
> Most of are using much more memory than they should. All of them run
> different versions of Windows servers.
>
> The host is 11.3-STABLE/amd64 r354667 with 360G RAM and guest systems use
> ZFS ZVOLs and vfs.zfs.arc_max=160g.
>
> How do I debug this?
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS...

[Xin LI]

On Tue, Apr 30, 2019 at 5:08 PM Michelle Sullivan 
wrote:

> but in my recent experience 2 issues colliding at the same time results in
> disaster
>

Do we know exactly what kind of corruption happen to your pool?  If you see
it twice in a row, it might suggest a software bug that should be
investigated.

Note that ZFS stores multiple copies of its essential metadata, and in my
experience with my old, consumer grade crappy hardware (non-ECC RAM, with
several faulty, single hard drive pool: bad enough to crash almost monthly
and damages my data from time to time), I've never seen a corruption this
bad and I was always able to recover the pool.  At previous employer, the
only case that we had the pool corrupted enough to the point that mount was
not allowed was because two host nodes happen to import the pool at the
same time, which is a situation that can be avoided with SCSI reservation;
their hardware was of much better quality, though.

Speaking for a tool like 'fsck': I think I'm mostly convinced that it's
*not* necessary, because at the point ZFS says the metadata is corrupted,
it means that these metadata was really corrupted beyond repair (all
replicas were corrupted; otherwise it would recover by finding out the
right block and rewrite the bad ones).

An interactive tool may be useful (e.g. "I saw data structure version 1, 2,
3 available, and all with bad checksum, choose which one you would want to
try"), but I think they wouldn't be very practical for use with large data
pools -- unlike traditional filesystems, ZFS uses copy-on-write and heavily
depends on the metadata to find where the data is, and a regular "scan" is
not really useful.

I'd agree that you need a full backup anyway, regardless what storage
system is used, though.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Congratulations on the Silver Anniversery Edition of FreeBSD

[Xin LI]

On Tue, Dec 11, 2018 at 11:01 AM Rodney W. Grimes
 wrote:
>
> Glen,
> It is just a bit shy of 25 years and 1 month that I shipped
> the 1.0 Release.  Its been a long road, but we are here now!
>
> Good Job, hats off!

+1, keep up the great work!
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: /dev/crypto not being used in 12-STABLE

[Xin LI]

On Thu, Dec 6, 2018 at 3:24 PM John Nielsen  wrote:
>
> > On Dec 6, 2018, at 4:04 PM, Xin LI  wrote:
> >
> > On Thu, Dec 6, 2018 at 11:37 AM John Nielsen  wrote:
> >>
> >> I have upgraded two physical machines from 11-STABLE to 12-STABLE recently 
> >> (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). 
> >> I noticed today that neither machine seems to be utilizing /dev/crypto. 
> >> Typically I see at least ssh/sshd have the device open plus some programs 
> >> from ports. But 'fuser' doesn't list any processes on either machine:
> >>
> >> # fuser /dev/crypto
> >> /dev/crypto:
> >>
> >> Both machines are running custom kernels that include "device crypto" and 
> >> "device cryptodev". One of them additionally has "device aesni".
> >>
> >> Is anyone else seeing this? Any idea what would cause it?
> >
> > Your average OpenSSL applications should not use /dev/crypto, if your
> > goal is to utilize AES-NI (which does not require /dev/crypto).  On
> > capable systems, AES-NI would be used automatically (and it's faster
> > this way).
>
> Thanks for the response. Is there a way to verify that AES-NI is being used 
> for e.g. ssh? I'm also curious why/when/how the change to not use (or 
> support?) /dev/crypto from base openssl was made.

You can disable the use of AES by passing environment variable
OPENSSL_ia32cap and compare the speed, e.g.:

OPENSSL_ia32cap="~0x200" openssl speed -evp aes-128-cbc

(disabled bit 57, or ~0x200 means to disable the AES-NI
capability bit).

On most systems, using AES-NI is about twice fast, personally I don't
really see a reason why people would want to disable it in production
(even for security reasons), though, but yes there is an option.

Cheers,
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: /dev/crypto not being used in 12-STABLE

[Xin LI]

On Thu, Dec 6, 2018 at 11:37 AM John Nielsen  wrote:
>
> I have upgraded two physical machines from 11-STABLE to 12-STABLE recently 
> (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). I 
> noticed today that neither machine seems to be utilizing /dev/crypto. 
> Typically I see at least ssh/sshd have the device open plus some programs 
> from ports. But 'fuser' doesn't list any processes on either machine:
>
> # fuser /dev/crypto
> /dev/crypto:
>
> Both machines are running custom kernels that include "device crypto" and 
> "device cryptodev". One of them additionally has "device aesni".
>
> Is anyone else seeing this? Any idea what would cause it?

Your average OpenSSL applications should not use /dev/crypto, if your
goal is to utilize AES-NI (which does not require /dev/crypto).  On
capable systems, AES-NI would be used automatically (and it's faster
this way).

Cheers,
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 11.1-RELEASE-p5

[Xin Li]

On 11/28/17 22:07, Alexander Shitov wrote:
> Hello.
> 
> today #freebsd-update cron showed availability of 11.1-RELEASE-p5?
> however I see no SA or EN on www.freebsd.org. Are there any reasons
> why announce is missing? Is it safe to install 11.1-RELEASE-p5 update?

It is for FreeBSD-SA-17:11.openssl.

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: date -r {big number} results in segmentation fault

[Xin LI]

I think emaste@ have fixed it in r321293.  MFC?

Cheers,

On Tue, Aug 29, 2017 at 8:29 PM, Paul Koch  wrote:
>
> I had one of those in-a-hurry copy-n-paste errors...
>
>  date -r 15038137211503813721
>  Segmentation fault
>
> Haven't had a chance to look into it yet though.
> This was on 11.1-RELEASE-p1 #0 r322350
>
> Paul.
> --
> Paul Koch | Founder | CEO
> AKIPS Network Monitor | akips.com
> Brisbane, Australia
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 11.1-BETA2 builds and 11.1-RELEASE schedule reminder

[Xin LI]

On Mon, Jun 19, 2017 at 1:24 PM, Ed Schouten  wrote:
> Hi Glen,
>
> [ +stable ]
>
> - i386: When started in VirtualBox (5.0.30), it starts to print some
> kernel panic stack trace during boot, but ends up rebooting
> immediately, meaning I cannot capture the trace for you.

Sounds like https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219882 ?
 Could you please check if that's the case?

Cheers,
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: post ino64: lockd no runs?

[Xin LI]

On Mon, Jun 12, 2017 at 10:14 AM, John Baldwin  wrote:
> On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote:
>> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote:
>> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any
>> > of my systems after a full rebuild of src and ports. No log entries
>> > offer any insight as to why :-(
>> >
>> > imb
>>
>> I don't tend to use NFS on my systems that are running head, so I
>> haven't had occasion to test this as stated.
>>
>> However, I just completed my weekly update of the "prooduction" systems
>> here at home, running stable/11.  And I find that lockd seems to be ...
>> claiming that all is well, but declining to run (for long).
>>
>> To the best of my knowledge, that was not the case until this last
>> update, which was from:
>>
>> FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316  
>> r319566M/319569:1100514: Sun Jun  4 03:54:41 PDT 2017 
>> r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64
>>
>> to
>>
>> FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322  
>> r319823M/319823:1100514: Sun Jun 11 03:56:10 PDT 2017 
>> r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64
>>
>> The "glaringly obvious" symptom in my case is that I am now unable
>> to (directly) save an email message from within mutt(1) by appending
>> it to an NFS-resident file.  (Saving it to a local file, then using
>> cat(1) to append that to the NFS- resident file & removing the local
>> copy works)
>>
>> After a few variations on a theme of:
>>
>> albert(11.1)[5] sudo service lockd restart
>> lockd not running?
>> Starting lockd.
>> albert(11.1)[6] echo $?
>> 0
>> albert(11.1)[7] service lockd status
>> lockd is not running.
>>
>> I finally(!) thought to ask ktrace what's going on (as tailing
>> /var/log/messages was completely unproductive, even after enabling
>> rc_debug).
>>
>> So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of
>> the output of kdump(1), I see that the trace ends with:
>>
>>   ...
>>   2811 rpc.lockd NAMI  "/var/run/logpriv"
>>   2786 sh   CALL  read(0xa,0x627fc0,0x400)
>>   2786 sh   GIO   fd 10 read 0 bytes
>>""
>>   2811 rpc.lockd RET   connect 0
>>   2786 sh   RET   read 0
>>   2811 rpc.lockd CALL  sendto(0x3,0x7fffe2c0,0x27,0,0,0)
>>   2786 sh   CALL  exit(0)
>>   2811 rpc.lockd GIO   fd 3 wrote 39 bytes
>>"<30>Jun 11 15:43:10 rpc.lockd: Starting"
>>   2811 rpc.lockd RET   sendto 39/0x27
>>   2811 rpc.lockd CALL  sigaction(SIGALRM,0x7fffec20,0)
>>   2811 rpc.lockd RET   sigaction 0
>>   2811 rpc.lockd CALL  nlm_syscall(0,0x1e,0x4,0x801015040)
>>   2811 rpc.lockd RET   nlm_syscall -1 errno 14 Bad address
>
> This is a really good clue.  nlm_syscall is dying with EFAULT.  The last
> argument is a pointer to an array of char * pointers, and the only way
> I can see it dying is if it fails to copyin() one of the strings pointed
> to by those pointers.  You could try running rpc.lockd under gdb from
> ports and setting a breakpoint on 'nlm_syscall' and then printing out
> 'addr_count' and 'p addrs@(addr_count * 2)'.

Yes, I found that the kernel was trying to copyin() from NULL, and
then found that corresponds to 'uaddr'.  After some tracing I found
that the tightened condition for taddr2uaddr have enforced (correctly)
buffer length passed from caller, which was not set correctly since ~9
years ago (r177633, which sets the size to sizeof(pointer)) but never
gets noticed because there is no check on that, so the solution seems
to be to correctly set the length values to (allocated size), and that
have fixed the issue for me.

The code could use some cleanups and I plan to do it at some later time.

> Unfortunately I'm not able to reproduce the failure on a test machine
> I have running head post-ino64.

This should have been fixed by r319852 in -HEAD (
https://svnweb.freebsd.org/base?view=revision=319852 ), and
I'll MFC the change after 3 days' settle  assuming there is no
objections, as this is a regression.

Cheers,
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: post ino64: lockd no runs?

[Xin Li]

Thanks for Kostantin's hints, this is indeed related to my change (which
exposed an old bug with rpc.lockd).

Please try attached fix.

Cheers,
Index: usr.sbin/rpc.lockd/lockd.c
===
--- usr.sbin/rpc.lockd/lockd.c  (revision 319826)
+++ usr.sbin/rpc.lockd/lockd.c  (working copy)
@@ -902,8 +902,7 @@ lookup_addresses(struct netconfig *nconf)
sin->sin_port = htons(0);
sin->sin_addr.s_addr = 
htonl(INADDR_ANY);
res->ai_addr = (struct 
sockaddr*) sin;
-   res->ai_addrlen = (socklen_t)
-   sizeof(res->ai_addr);
+   res->ai_addrlen = sizeof(struct 
sockaddr_in);
break;
case AF_INET6:
sin6 = malloc(sizeof(struct 
sockaddr_in6));
@@ -913,7 +912,7 @@ lookup_addresses(struct netconfig *nconf)
sin6->sin6_port = htons(0);
sin6->sin6_addr = in6addr_any;
res->ai_addr = (struct 
sockaddr*) sin6;
-   res->ai_addrlen = (socklen_t) 
sizeof(res->ai_addr);
+   res->ai_addrlen = sizeof(struct 
sockaddr_in6);
break;
default:
break;
@@ -938,7 +937,7 @@ lookup_addresses(struct netconfig *nconf)
}
}
 
-   servaddr.len = servaddr.maxlen = res->ai_addr->sa_len;
+   servaddr.len = servaddr.maxlen = res->ai_addrlen;
servaddr.buf = res->ai_addr;
uaddr = taddr2uaddr(nconf, );
 


signature.asc
Description: OpenPGP digital signature

Re: 11.1-prerelease buildworld fails at libpcap

[Xin Li]

Should be fixed by r319297.

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: 11.1-prerelease buildworld fails at libpcap

[Xin Li]

On 5/31/17 00:25, Johan Hendriks wrote:
> I am on the following revision.
> 
> root@desk:/usr/src # uname -a
> FreeBSD desk.server.mylab.nl 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #89
> r319098: Mon May 29 10:55:56 CEST 2017
> r...@desk.server.mylab.nl:/usr/obj/usr/src/sys/KRNL  amd64
> 
> 
> I have updated to the following revision
> At revision 319292.
> 
> 
> When doing the buildworld it errors out with the following.
> 
> 
> ===> lib/libpcap (all)
> Building /usr/obj/usr/src/lib/libpcap/grammar.o
> /usr/src/contrib/libpcap/grammar.y:348:15: error: use of undeclared
> identifier 'cstate'; did you mean 'cstat'?
> finish_parse(cstate, yystack.l_mark[0].blk.b);
>  ^~
>  cstat
> grammar.c:1291:1: note: 'cstat' declared here
> YYPARSE_DECL()
> ^
> grammar.c:378:67: note: expanded from macro 'YYPARSE_DECL'
> # define YYPARSE_DECL() yyparse(void *yyscanne, compiler_state_t *cstat)
>   ^
> /usr/src/contrib/libpcap/grammar.y:365:28: error: use of undeclared
> identifier 'cstate'; did you mean 'cstat'?
> { yyval.blk.b = gen_ncode(cstate, NULL,
> (bpf_u_int32)yystack.l_mark[0].i,
>   ^~
>   cstat
> grammar.c:1291:1: note: 'cstat' declared here
> YYPARSE_DECL()
> ^
> grammar.c:378:67: note: expanded from macro 'YYPARSE_DECL'
> # define YYPARSE_DECL() yyparse(void *yyscanne, compiler_state_t *cstat)
>   ^
> /usr/src/contrib/libpcap/grammar.y:369:28: error: use of undeclared
> identifier 'cstate'; did you mean 'cstat'?
> { yyval.blk.b = gen_scode(cstate, yystack.l_mark[0].s,
> yyval.blk.q = yystack.l_mark[-1].blk.q); }
>   ^~
>   cstat
> grammar.c:1291:1: note: 'cstat' declared here
> YYPARSE_DECL()
> ^
> grammar.c:378:67: note: expanded from macro 'YYPARSE_DECL'
> # define YYPARSE_DECL() yyparse(void *yyscanne, compiler_state_t *cstat)
>   ^
> /usr/src/contrib/libpcap/grammar.y:370:28: error: use of undeclared
> identifier 'cstate'; did you mean 'cstat'?
> { yyval.blk.b = gen_mcode(cstate, yystack.l_mark[-2].s, NULL,
> yystack.l_mark[0].i,
>   ^~
>   cstat
> grammar.c:1291:1: note: 'cstat' declared here
> YYPARSE_DECL()
> ^
> grammar.c:378:67: note: expanded from macro 'YYPARSE_DECL'
> # define YYPARSE_DECL() yyparse(void *yyscanne, compiler_state_t *cstat)
>   ^
> /usr/src/contrib/libpcap/grammar.y:372:28: error: use of undeclared
> identifier 'cstate'; did you mean 'cstat'?
> { yyval.blk.b = gen_mcode(cstate, yystack.l_mark[-2].s,
> yystack.l_mark[0].s, 0,
>   ^~
>   cstat
> grammar.c:1291:1: note: 'cstat' declared here
> YYPARSE_DECL()
> ^
> grammar.c:378:67: note: expanded from macro 'YYPARSE_DECL'
> # define YYPARSE_DECL() yyparse(void *yyscanne, compiler_state_t *cstat)
>   ^
> /usr/src/contrib/libpcap/grammar.y:378:18: error: use of undeclared
> identifier 'cstate'; did you mean 'cstat'?
> bpf_error(cstate, "'port'
> modifier applied to ip host");
>   ^~
>   cstat
> grammar.c:1291:1: note: 'cstat' declared here
> YYPARSE_DECL()
> ^
> grammar.c:378:67: note: expanded from macro 'YYPARSE_DECL'
> # define YYPARSE_DECL() yyparse(void *yyscanne, compiler_state_t *cstat)
>   ^
> /usr/src/contrib/libpcap/grammar.y:380:18: error: use of undeclared
> identifier 'cstate'; did you mean 'cstat'?
> bpf_error(cstate, "'portrange'
> modifier applied to ip host");
>   ^~
>   cstat
> grammar.c:1291:1: note: 'cstat' declared here
> YYPARSE_DECL()
> ^
> grammar.c:378:67: note: expanded from macro 'YYPARSE_DECL'
> # define YYPARSE_DECL() yyparse(void *yyscanne, compiler_state_t *cstat)
>   ^
> /usr/src/contrib/libpcap/grammar.y:382:18: error: use of undeclared
> identifier 'cstate'; did you mean 'cstat'?
> bpf_error(cstate, "'proto'
> modifier applied to ip host");
>   ^~
>   cstat
> grammar.c:1291:1: note: 'cstat' declared here
> YYPARSE_DECL()
> ^
> grammar.c:378:67: note: expanded from macro 'YYPARSE_DECL'
> # define 

Re: CVE-2016-7434 NTP

[Xin LI]

We plan to issue an EN to update the base system ntp to 4.2.8p9.

The high impact issue is Windows only by the way.

Cheers,

On Mon, Dec 12, 2016 at 6:18 PM, Michelle Sullivan <miche...@sorbs.net> wrote:
> Dimitry Andric wrote:
>>
>> On 08 Dec 2016, at 06:08, Michelle Sullivan <miche...@sorbs.net> wrote:
>>>
>>> Are we going to get a patch for CVE-2016-7434 on FreeBSD 9.3?
>>
>> On Nov 22, in r309009, Xin Li merged ntp 4.2.8p9, which fixes this
>> issue, to stable/9:
>>
>> https://svnweb.freebsd.org/changeset/base/309009
>>
>> Unfortunately the commit message did not mention the CVE identifier.  I
>> can't find any corresponding security advisory either.
>>
>> -Dimitry
>>
> 
>
> No updates needed to update system to 9.3-RELEASE-p52.
> No updates are available to install.
> Run '/usr/sbin/freebsd-update fetch' first.
> [root@gauntlet /]# ntpd --version
> ntpd 4.2.8p8-a (1)
>
> So no then...
>
> 9.3 is still so-say supported so I'm not talking about -STABLE.
>
> Michelle
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: sshd whines & dies after releng/10 "freebsd-update" run

[Xin Li]

On 10/16/16 09:26, David Wolfskill wrote:
> And over the last year or so, it's worked pretty well:  I have the
> machine set up (as is usually my approach) to be able to boot from
> either of a couple of slices.  I use a "dump | restore" pipeline
> to copy the / and /usr file systems from the "active" slice to the
> "inactive" slice, adjust /etc/fstab on the inactive slice to reflect
> reality for when it's the boot slice, then (while the file systemms
> from the other slice are still mounted -- e.g., on /S2) run
> "freebsd-update -b /S2 fetch install", then reboot from the
> newly-updated slice.
> 
> In the past, that's Just Worked.

Your usage probably worked because you were lucky for a few times in the
past.  (details below)

> This weekend, though, I was planning to update my other systems tfrom
> stable/10 to stable/11, so I figured I'd try freebsd-update on this
> machine first.
> 
[...]
> root@sisboombah:/tmp # `which sshd` -d
> Undefined symbol "ssh_compat13" referenced from COPY relocation in 
> /usr/sbin/sshd
> 
> Any clues?

I think this is not going to work (stable/10 -> releng/10.3) due to ABI
incompatibility in a downgrade.

Basically, freebsd-update is treating your stable/10 as a 10.3-RELEASE
installation and will fetch only changes from 10.3-RELEASE to the latest
patchlevel.

Because of a SSH vulnerability that affects 10.3, freebsd-update would
patch libssh (shared library used by sshd and friends), however the
change does not affect the main binary.  This worked by replacing your
existing libssh with the one shipped by freebsd-update (effectively
downgraded the library) and that would break sshd.

I think upgrade -r 10.2-RELEASE (ideally, 11.0-RELEASE though as it
would eliminate the possibility of any potential incompatibility) would
work because that would result in a full rewrite of all files.

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: [FreeBSD-Stable] svn commit: r296462 - in stable/9: crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/doc/apps crypto/openssl/ssl secure/usr.bin/openssl/man

[Xin Li]

On 3/10/16 00:00, Eric Masson wrote:
> Dimitry Andric  writes:
> 
> Hi Dimitry,
> 
>> Can you please try the attached patch, which I also attached to PR
>> 207783?  I think this will solve the crashes.
> 
> Works as expected with patch applied, thanks a lot.
> Will it be pushed to releng/9.3/ please ?

It will.  The binary update is still compiling.

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: fetch(1) always dumps core - openssl issue?

[Xin Li]

On 3/9/16 19:09, Chris H wrote:
> Greetings,
> I just built/installed world/kernel on a fresh
> STABLE-9 box. Now building ports almost always results
> in fetch(1) dumping core. It appears that this happens
> on ssl enabled hosts. Resulting in fetch dropping to
> distcache.freebsd.org.
> I see a lot of noise on the lists regarding openssl
> issues recently. So thought I'd mention this, in hopes
> of finding a solution.

Please update to r296597+.

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r296317 - in stable/10: crypto/openssl crypto/openssl/apps crypto/openssl/crypto crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/crypto/bn/asm crypto/openssl/crypto/d

[Xin LI]

Hrm this is really weird!  Sorry I can't debug this right now, but
please do keep us posted if you have new findings.

One quick guess: Can you confirm if your system clock is correct?

Cheers,

On Wed, Mar 2, 2016 at 12:10 PM, Mike Tancsa <m...@sentex.net> wrote:
> On 3/2/2016 10:43 AM, Xin LI wrote:
>> Author: delphij
>> Date: Wed Mar  2 15:43:01 2016
>> New Revision: 296317
>> URL: https://svnweb.freebsd.org/changeset/base/296317
>>
>
>
> Hi,
> On installworld, I get
>
> ===> secure (install)
> ===> secure/lib (install)
> ===> secure/lib/libcrypto (install)
> install -C -o root -g wheel -m 444   libcrypto.a /usr/lib
> install -C -o root -g wheel -m 444   libcrypto_p.a /usr/lib
> install -s -o root -g wheel -m 444 libcrypto.so.7 /lib
> install -l s /lib/libcrypto.so.7  /usr/lib/libcrypto.so
> cp -f /usr/src/secure/lib/libcrypto/opensslconf-x86.h opensslconf.h
> make[6]: exec(cp) failed (No such file or directory)
> *** Error code 1
>
> Stop.
> make[6]: stopped in /usr/src/secure/lib/libcrypto
> *** Error code 1
>
> Stop.
> make[5]: stopped in /usr/src/secure/lib
> *** Error code 1
>
> Stop.
> make[4]: stopped in /usr/src/secure
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
>
>
>
> --
> ---
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications, m...@sentex.net
> Providing Internet services since 1994 www.sentex.net
> Cambridge, Ontario Canada   http://www.tancsa.com/



-- 
Xin LI <delp...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Error upgrading from 10.1-RELEASE to 10.2-RELEASE

[Xin Li]

Hi,

We believe this is because phttpget (the pipelined HTTP client that
freebsd-update and portsnap uses) was unable to get the right file(s)
from the server, that sometimes the client would get wrong file from the
server, and it's not reproducable when requesting again.  We have then
able to develop a test case to reliably provoke this on update2.FreeBSD.org.

Thanks for Peter's help, we have narrowed down the problem to a specific
version (1.4.36) of lighttpd (*), which update2.FreeBSD.org is using,
and the problem should have been resolved at this time after the web
server is replaced with nginx.

Please let us (security-officer@, clusteradm@) know if the problem still
persists.

Cheers,

(*) We are not yet certain if it was a bug with lighttpd itself, or a
bug with phttpget that made newer versions of lighttpd unhappy.  It's
worthy to find it out and maintainer is cc'ed.



signature.asc
Description: OpenPGP digital signature

Re: freebsd downgrade

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 7/24/15 00:20, Slawa Olhovchenkov wrote:
 On Thu, Jul 23, 2015 at 04:51:07PM -0700, Xin Li wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 07/23/15 16:21, Stari Karp wrote:
 Hi!
 
 I had a problems with FreeBSD 10.2-BETA2. I used
 freebsd-update ugrade and update FreeBSD 10.1-RELEASE. Is it
 possible to downgrade BETA2 to 10.1-RELEASE with freebsd-update
 upgrade -r 10.1-RELEASE, please?
 
 It's not supported (because you may be running binaries that
 depends on new kernel).
 
 What kind of problems did you have?  Please let re@ know so we
 can get them fixed.
 
 For me -- degradate network performance, about 30%. I am do
 verification now, by downgrading kernel.

What kind of workload and what NIC are you using?

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJVseyOAAoJEJW2GBstM+nsn5YP/jjX9IM2T7wQ8p5skZDvA5e+
e/dZ+IWKsqOIh612MyXfYbMdHbKakXdMP8K2rU6aNQmTinArSbC/xhUPXnA7029y
Xz4TLTyb2y/J1oNFTU7saSnv5CeB8n/oDGxCISDqJPZDK9rypBjO7r3kMP9OLc5R
c9Qtd38i2mdH3oWHbDeonBNaJ5YQ32zB5nGWEMpxFc2xQU2GK37dx4xjCJdx3L+1
WS+s2FJdWXCsclE12luHiGjD1hlIIS4yLZhSgLUy9i+rD4Zn6VOF7QvwCIAbjD8h
kpZDt9YcqJy7y/gZu2iFa12nIguY9Z6pmPHu8yy/lGztfmspUWnmDspYnBhDJyoi
GHrCji5O7St8w1MCUPYPsE/crvcel16FA3W1yCmYtmzX+HyEjcuqNY41vN3WqkCg
thYyJxS5IVSXHFR3wbfsNM3WlG6pREE0uzjqo4rbzxRNPGHzsmoD8ImOUa3pKjgP
XwgPSv8J7I4uskW6isDWuB5GBmsPk4PqZfUWvnCqYmG77HX5sl0ct+gxQQ+b6sAl
6I2FYflvrvexRhxDMc+gjoArNDOJhSVQY/fqswQXdsPYdIQnhmKLCX+G3ZOx0cho
uYN6Qf6bqcSAcwKZeRI5LAOEc1XpqEo8HhxkwKgmC7m3SWJs35m9+yom7PlPdyM7
vx/huCTRA26XXuNAxqJF
=Mhdf
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: freebsd downgrade

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/23/15 16:21, Stari Karp wrote:
 Hi!
 
 I had a problems with FreeBSD 10.2-BETA2. I used freebsd-update
 ugrade and update FreeBSD 10.1-RELEASE. Is it possible to downgrade
 BETA2 to 10.1-RELEASE with freebsd-update upgrade -r 10.1-RELEASE,
 please?

It's not supported (because you may be running binaries that depends
on new kernel).

What kind of problems did you have?  Please let re@ know so we can get
them fixed.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.6 (FreeBSD)

iQIcBAEBCgAGBQJVsX3rAAoJEJW2GBstM+nshTsP/1gkFDhlrzElnOPfxtQEc80H
6oocZG4Upn9UbrFIq9GKU4qU8XIC8fHtYtLyXAbjj5vebEMkOAJuhzE8HrN3eh+N
hZKtKRiK7fNSFWCkqmd2BY0G05IBEXgQXzbgRzc65OrRcrp5MSL109bxYjN7Ih1L
wMtulWxfxyqsCZ4h6qwjZehJTkPMwiaGfhjbxAUbghzJKEyCKVGmGCE5Wbz4q++W
9bkQXElu1777WlJ3X+6tvgRkBxpYdaXSzL2UAH5cZrM7b5T09KfcgKsl+x9o1CGN
PGRQZqNcdyxEebjMqJaE2BOuvtocIrlpEOtC0VT7f5pLp64pV8PYPQGzdi+01LZD
w/wNvkJFqhIT42h/DDuTj7kOsrJhDA5Q2Vho9KW4YZFbDO9eglCA2KhDgrLQejl3
9z0byDWq+my638CRQIjHcf0QBokdXceK/AVjnIx9Os59OD0dQkl3ISSRhSDQPmqe
urI96uQ582vo6h+Tiic119aPtmy7aTn6PqtsTEYLnb5YTFx8oF4XaBuP7a3RmcBm
JX3oX5vIzOiDWtnG27yhsy5Bido91xPznnCLoC24MKuO7YFJb9Pi4x4fy8jIQkpp
gZTz7AkGR8oFroisPb9DGkkhT5QcwQviEnyRA1pR0dk7Sv6mzckRRSxxMn6s1SrY
0oVGHIe54nF7T1MRZc15
=BS7Y
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Will 10.2 also ship with a very stale NTP?

[Xin LI]

I've spent some time on the MFC, the testing would still take some time
(likely a day or two) and once that's finished I'll ask re@ for approval.
On Sat, Jul 11, 2015 at 11:44 PM Tomoaki AOKI junch...@dec.sakura.ne.jp
wrote:

 As I already mentioned in another post, head has 4.2.8 p3 in-tree.

 So the answer should be MFC before creation of releng/10.2 is planned
 or not.


 On Sun, 12 Jul 2015 15:04:43 +1000
 Peter Jeremy pe...@rulingia.com wrote:

  On 2015-Jul-11 23:22:56 -0400, Chris Nehren 
 cnehren+freebsd-sta...@pobox.com wrote:
  On Sat, Jul 11, 2015 at 09:58:11 +1000, John Marshall wrote:
   It's me again with my annual NTP whinge.
  
  The answer to the perennial will release $foo ship with old / insecure
  / otherwise deficient $bar? is still install $bar from ports.
 
  That's a non-answer.  It just changes the question to why bother to
  include $bar in base when I need to install the port anyway.
 
  --
  Peter Jeremy


 --
 Tomoaki AOKIjunch...@dec.sakura.ne.jp
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: /lib/libzfs_core.so.2 obsolete?

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/09/15 17:41, Dan Allen wrote:
 I sync and build 10.1-stable almost daily.  I keep up with
 mergemaster as well as make delete-old-files, and even so, I found
 in my /lib directory that one library is from last Nov 2014 even
 though everything else is dated today (I built everything today).
 
 So, my assumption is that /lib/libzfs_core.so.2 should be added to
 the ObsoleteFiles.inc file.

No, it's required by ZFS.  This is a conditionally built/installed
file and on -HEAD it's correctly deleted if MK_ZFS is no.

Looking closer, it looks like Andrey (zont@) have committed a fix but
it was never merged:

===
r256710 | zont | 2013-10-17 15:00:35 -0700 (Thu, 17 Oct 2013) | 2 lines

Add lot of missed files and dirs
===

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.6 (FreeBSD)

iQIcBAEBCgAGBQJVnxt4AAoJEJW2GBstM+nsqCgP+QEj7ADsYoJInDHD3FdiE6ES
38jPC5uSlvM4KRotrBitUdDfIRiPG493Lu6SZORu9s+SzAGI1kq7fDRlrefXLJ2U
jUvGssbzmyhngCfIeUfvVzE/O7TMObQoHaZ325T0b6A4Zp38Bvr+syDkkMjQfiYY
c4ni1tFo+A5NkhTh2ZPp50H/EUDDhANn5/eNHrzWYd/tgVB9yTGaTlFkiH03jasl
DlKEg0ZxqVmDRJEtYcKkvLSUxxbsQkPjJ2yLYWvkx9++2kmeioDtVJHfQc2nZRn3
GIHuz2hLybR2cc/GrF8ueH/xr1VQo4/qASpJJFXgfYILdgP4rha7iV1w5RWJGWFF
XFLxwOd9hhrQlNr2ko6byBKYZANViIxlXR/3+DR95ON1ft4kR/DuTLp9/CJhHzh4
ywDeFE5cCScIWPV98R9PR9Am34USgYCRyCzxlFvJNg5vu+/7CeeHVslBcL/ZjAtt
0DHsY3OYcT6sq3Ucjj7TqKlWecXds0dpjpTiSyjlX7EUG1ihIC6wYsdn7o1Y3Fc0
El+kmI2UIe0ulC+tzgWR9YF808Xhrl8z09hq2WvPDUT3KIrFcwadh65R3ExFUZjp
VHvRRKTx0oSxXSPo0awTY1wyj5cNIvS5xobn9LC6mOrfJSwwuy9ztv0tPEFCDChd
YPJ+47GdNBbnomZS/Z8U
=YsLR
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: can the l2arc memory leak fix be pulled into 10.1-RELEASE ?

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/25/15 02:13, Slawa Olhovchenkov wrote:
 On Wed, Jun 24, 2015 at 01:05:58PM -0700, Xin Li wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 06/23/15 04:36, Reko Turja wrote:
 -Original Message- From: Willem Jan Withagen Sent:
 Monday, June 22, 2015 11:48 PM To: Daniel Genis ; 
 freebsd-stable@freebsd.org Subject: Re: can the l2arc memory
 leak fix be pulled into 10.1-RELEASE ?
 
 We are kind of new to FreeBSD, so we're wondering what are
 the plans to merge these fixes into the 10.1-RELEASE branch
 ?
 
 We'd love to get these fixes without having to rebuild the 
 kernel. Is there any chance for the merge to happen in the
 near future, or should we compile the kernel to get the
 fixes?
 
 The RELEASE branch is exactly what it says, RELEASE. And is
 only done once per version when the actual official RELEASE
 is. So the next one will be the upcoming 10.2-RELEASE. Which
 is schedules for August 2015 according to:
 
 There are actually 2 branches tracking release: RELEASE which
 is the original release itself and RELENG which is the 
 release+security and some errata fixes. In practice one should 
 always track and compile RELENG sources with production
 servers, unless there's a bugfix or added driver that's only
 available in STABLE.
 
 The release/X.Y.Z are actually tags and not branches (i.e. read
 only copy of whatever state is in the release engineering/errata
 branch, releng/X.Y, is at the time it's released), but
 technically in svn a tag is also a branch.  We do all efforts to
 avoid making any changes once a tag is laid, because it's a
 historical and reference point.
 
 Users who use -RELEASE should track releng/X.Y branch, or use 
 freebsd-update(1) to keep their system up-to-date.
 
 Our goal is to allow a majority of users to use binary releases 
 without having to compile and build themselves.  If you know
 some specific reasons that forces you to compile yourself, please
 consider sending re@ an email so we will see what we can improve
 this.
 
 You are some wrong. Tracking releng/X.Y for -RELEASE don't allow
 reproductable build of -RELEASE image: after existing errata `svn
 export releng/X.Y` give different result compared to original
 release build. This is wrong. Building release image must be also
 from `svn export release/X.Y.Z`. Last release (10.1) will be build
 from releng/10.1 and I can't find easy way to get source of
 releases form svn.

releng/* is a _branch_ and it's not intended for reproducible builds.
 In order to do so one will have to use a tag.

However, svn tag is different from CVS or other SCM's tag as they are
also a branch.  To make things worse, we are using $FreeBSD$ expansion
and that would result in different contents in the files, and these
strings would end up going into some binaries, and speaking for binary
update, you would never want an update to refresh all binaries just
because there is difference because one copy is built from tag and
another is from branch.

To solve this issue we (re@, although it's mostly Glen doing the hard
work for the last few releases) always build on releng/* branch, and
then lay down tag once the build is considered gold.  To reproduce
that build, what I can possibly think of would be something like this:

Assuming we have:

SVN_RELEASE_VERSION=10.1
FSVN=svn://svn.freebsd.org/base

Then one can reliably checkout the branch by doing:

svn export -r $(svn info ${FSVN}/release/${SVN_RELEASE_VERSION}.0 |
grep 'Last Changed Rev:' | cut -f2 -d:)
${FSVN}/releng/${SVN_RELEASE_VERSION} src

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.5 (FreeBSD)

iQIcBAEBCgAGBQJVjDmlAAoJEJW2GBstM+ns/Q8P/jvLJvSWvO9HENkUSF0hqKCd
cz8k53g9tCusNHGmN9j5FEERp1RiEEBLnIBd2yO2TnU6cgZUhq2IpA2+RMz2/RhE
XgVp8yrJRebTjstZzFMrYVEnQPKmYFQs8lrsC7sh6tQML2jRGXIDc1jL/rjD73+s
a+WoDQdcyqVZaeiLrpCB3Q5HZGDTk0mmHHlvo6kiKFcnGYe4FZ4Gqbt6jF0uj0qm
KXita7Ix23IiB0LBr9csV79AfuEe7ZqObj9vQxocHlrPQiwFCfwnDX2edpE2Slmz
4KIHRR4Ogv3KVdrdmopZDNiRcA3/DfC8wyNkOc5rCBtFrDUT4hKTZ2K48YSqKEbZ
TbRJutOf9lYpILEOOFS6ZE3QN1Dd2fZeSofoI1Xqt4vHEjxmYtK/pAWf2J44k8SR
bMkswHBEpBoqrp5+df6eQsV/mIKHPHYgamzHJHowRMCALOyLjLAtEIYnsRMrL9Je
jaHWrrlbrJ0F4yqW7Pm4BhYWZsu8lM5yHhmSQabHv0vUH22k9gAu2ohHGiTYmSu6
oANaYtv1ErIPWICckPQoI1LYTa9mKzLWmsLycTRk2UPDToQUjkzB4RG8l75d8/1n
pUxgmN+tn+A2/o/2/L/JHAiXf6dMxrdimOv71D8XgYzNR3WD1RJlciURMt8i1VMM
chfd7G6j1ey68TtD2PSD
=Ymad
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: can the l2arc memory leak fix be pulled into 10.1-RELEASE ?

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/23/15 04:36, Reko Turja wrote:
 -Original Message- From: Willem Jan Withagen Sent: Monday,
 June 22, 2015 11:48 PM To: Daniel Genis ;
 freebsd-stable@freebsd.org Subject: Re: can the l2arc memory leak
 fix be pulled into 10.1-RELEASE ?
 
 We are kind of new to FreeBSD, so we're wondering what are the
 plans to merge these fixes into the 10.1-RELEASE branch ?
 
 We'd love to get these fixes without having to rebuild the
 kernel. Is there any chance for the merge to happen in the near
 future, or should we compile the kernel to get the fixes?
 
 The RELEASE branch is exactly what it says, RELEASE. And is only
 done once per version when the actual official RELEASE is. So the
 next one will be the upcoming 10.2-RELEASE. Which is schedules
 for August 2015 according to:
 
 There are actually 2 branches tracking release: RELEASE which is
 the original release itself and RELENG which is the
 release+security and some errata fixes. In practice one should
 always track and compile RELENG sources with production servers,
 unless there's a bugfix or added driver that's only available in
 STABLE.

The release/X.Y.Z are actually tags and not branches (i.e. read only
copy of whatever state is in the release engineering/errata branch,
releng/X.Y, is at the time it's released), but technically in svn a
tag is also a branch.  We do all efforts to avoid making any changes
once a tag is laid, because it's a historical and reference point.

Users who use -RELEASE should track releng/X.Y branch, or use
freebsd-update(1) to keep their system up-to-date.

Our goal is to allow a majority of users to use binary releases
without having to compile and build themselves.  If you know some
specific reasons that forces you to compile yourself, please consider
sending re@ an email so we will see what we can improve this.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.5 (FreeBSD)

iQIcBAEBCgAGBQJViw2mAAoJEJW2GBstM+nsuKcP/A1cJupbolHtlbbIifahHxAA
VpV5/wzb4FZKLiUQX/E8A+iqSw5PPFrWozGkVEDx7xcziZcLTMTgfaZdWgFAoI67
VB1+1cm0cxpm9vVoQahSeCVcTtp/whK26jCnfeDVWnTUcBZTRO85Ni90T5Zyuc7P
Hr6E22z7WAFKXB2wP7tOjDS1ZwcUR9wqERWaxDy4V7fLhJh7QK0u6KxAoX/TSRaU
E3l5BOdSdfUBH49OkB2WMdB7n8jLWAmMNP0jkT5PxPtAX+3HaZk6xBbLSTSR2/Up
Ulw8WKHXhiwYg8lz/c/AZ0W2wJanzfM+tXTSmwgs/50mO+NUbZyPcpAibTp7ozNu
ukKzpMwrKEUQ2VdFBq8VuHpNEBnsz6kp3ZTR6qiFL9uJgghjcGuq88/hrS3oz2f8
Skr24McdbhDNJII9OLOZWelERkRyP1jCqqNuwEo4y4QzTCfHB3E+3XxEomkXLiK5
yVvQMwFD2SQSVT4kg/epDWvLu5vaVZgxyjxA8doYeXt1iaURPCt0IsOTeT3oAe7E
e2mOi6ub0aDYPox1RSqZ7ZbWpakpTuxtCSgC9u2Qz1ncwhesL+F6BDNcxOPdfeLC
x+5yV6K6DE3Xx38B4rxoSEgZlNgoZcKpkX/Tlo5gL9IxBPjRpBqqTPSzRgiyBRe4
9/5oGcFQEDlS4ekPGSR3
=DtFf
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: wrong patch number in releng/10.1?

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/10/15 02:20, Palle Girgensohn wrote:
 Also
 
 # uname -a FreeBSD pingpongdb 10.1-RELEASE-p10 FreeBSD
 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015
 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
 amd64 # uptime 2:18am  up 36 mins, 4 users, load averages: 0,08
 0,14 0,10 # ls -lrt /boot/kernel/kernel /boot/kernel/*zfs* 
 -r-xr-xr-x  2 root  wheel  21160449 10 Jun 01:36
 /boot/kernel/kernel -r-xr-xr-x  2 root  wheel   2320144 10 Jun
 01:36 /boot/kernel/zfs.ko -r-xr-xr-x  1 root  wheel  19103144 10
 Jun 01:36 /boot/kernel/zfs.ko.symbols # strings
 /boot/kernel/kernel|grep 10.1-RELEASE @(#)FreeBSD 10.1-RELEASE-p10
 #0: Wed May 13 06:54:13 UTC 2015 FreeBSD 10.1-RELEASE-p10 #0: Wed
 May 13 06:54:13 UTC 2015 10.1-RELEASE-p10
 
 It seems to me the verions numbering is not correct, but the patch
 *is* there, it should be 10.1-p11, right?

Assuming you are using freebsd-update, kernel version is only updated
when there is actual change in the kernel *itself*.

In this case we have made a few changes to ZFS but that only affected
the module, so kernel version is not changed.  This is expected behavior
.

The canonical way of determining system version is 'freebsd-version
- -ku' for 10.0 onwards.

Hope this helps.

Cheers,

 10 jun 2015 kl. 11:01 skrev Palle Girgensohn
 gir...@freebsd.org:
 
 Hi,
 
 It seems the patch level in the UPDATING document is bad in
 releng/10.1, it is p29 which is the patch level for 8.4?
 
 Palle
 
 -
- ---

 
r284193 | delphij | 2015-06-10 00:13:25 +0200 (Ons, 10 Jun 2015) | 8 lin
es
 
 Update base system file(1) to 5.22 to address multiple denial of 
 service issues. [EN-15:06]
 
 Improve reliability of ZFS when TRIM/UNMAP and/or L2ARC is used. 
 [EN-15:07]
 
 Approved by:so
 
 -
- ---


 
But the UPDATING says:
 
 20150609:   p29 FreeBSD-EN-15:06.file 
 FreeBSD-EN-15:07.zfs
 
 Updated base system file(1) to 5.22 to address multiple denial of
 service issues. [EN-15:06]
 
 Improved reliability of ZFS when TRIM/UNMAP and/or L2ARC is
 used. [EN-15:07]
 
 20150513:   p10 FreeBSD-EN-15:04.freebsd-update 
 FreeBSD-EN-15:05.ufs
 
 Fix bug with freebsd-update(8) that does not ensure the previous 
 upgrade was completed. [EN-15:04]
 
 Fix deadlock on reboot with UFS tuned with SU+J. [EN-15:05]
 
 
 
 
 


- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.4 (FreeBSD)

iQIcBAEBCgAGBQJVeIT1AAoJEJW2GBstM+nswC0QAJM5I6A52Lp9vAbMJTwauHGn
z8wKzR+P4CyNDgWCpBpyPO+CsRRZgpBEYVTIuj61cTgoK5r2PLoUIGpEwfGX+1L8
izTd25MitSi721+Toy5dFe/ndBb4D7dz8+naFp59TmJtO7ZuLNRCxYLPoou4bcOg
ZeX4af7alcEl93ADBE0T8gNDkcFmwxSNcciYxtMiad33TjqWkekNRN78ndpRi/5h
raAt9UD6//iT7V+/w7PcdwvXugUgoQMxdaivXA4SV1xXX2MlnaDAU67nrWlPhXDM
YbhS11SP1gptNWDlIz016oOblu4AV3dUIbPVjWbJ6KnLEiHg0KVn/PlsBpJ0wIcl
WseRSdCNeqMTE7ik1qjfiEzE/Y6A/BTVVQsL5jQ4idRPfRyKGtG9vHxtfyV8itls
kKCibaWVaBtUidRQHIyxpSHvSRp614iK3SO0ZR+yecDN0lUZvxCraYXgEXo+Ov4O
YQ3/nBTReBFYRtF7PEnk6qtcbJ3UL2EgwOFMkODbkvACdFK/XxByMW4f3H5A4TFm
nzDKXb+fmrtmf5e0XE6kZgOEFKBFZmLt4QbnPrAoa7WO/Eu43HE7/skYWNpJVLoz
3lZ16XTK39UKUA+/sniiHRW8m9SFxXv1E9GsLl/xO1HQDXuhiYN1nPkEx/PXYUjp
GRGXVDw84qS1kbYHifzu
=DXmN
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ssh install with freebsd-update

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi, Randy,

On 06/09/15 16:34, Randy Bush wrote:
 # uname -a FreeBSD foux.psg.com 10.1-RELEASE-p10 FreeBSD
 10.1-RELEASE-p10 #0: Tue May 12 19:33:13 UTC 2015
 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
 i386
 
 it's really p11 now
 
 if i run freebsd-update install of p11.  all looks well until the 
 reboot, when i get
 
 Performing sanity check on sshd configuration. Shared object
 libgssapi_krb5.so.10 not found, required by sshd /etc/rc:
 WARNING: failed precmd routine for sshd

This is VERY strange!  Did you ever have an incomplete upgrade from
older FreeBSD releases (9.x) on the affected systems?  What was the
version before you update/upgrade to the latest one?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.4 (FreeBSD)

iQIcBAEBCgAGBQJVd3tNAAoJEJW2GBstM+ns3JMP/2KdCIqb27+pSNeiWd4P74ip
vZkvMYGMS9+7yjqe3IfA+p+gYmHVHE0/Wo1dhQmDP3YpTsAwTUqnXk45iNnqAU4r
Xk8bYqwZ0dOQO3zsokJ4L0PIFriGtOJCTXHAlMbfywfqDFstrY/rau6wryc+9pvZ
mgLsTps4rtKZ9vUVw0i/sksr6bv9gE5T88W7wdO9MxKDDMj9v8V/PXOEj589BNec
XjlTo4f3dXBGIaBOmoWPbYzTcM35oMnHzIAiDdGliwa3MoP05MUMyYueXHpSgCP6
F3Ev1PwNyYWrnau9oLNEClb0lEddVFiGB9dabtUyQA8X9g8nP/kzPDn7fouJrxMK
Ak9DtLAeBY771YQzNFfRRW9zRKUOPJx/Ip8gSzFUdujnzhmtdPdSL0qBTOR0tjSS
gi3zrAPH0IfkI/r1RCKjbkZHc45lqMH79MprvjjRqHnUe4yUfbDyUtjFcAnP13HH
u9ytuMYyRzcRQulaukTMq2FgiOFtoag3g23gM1sfGSz7cd5qPGINAO4pZzWgSRhs
z9rVLUVS2pKkxxhVKOzv74dFjmIkYJxhkY/+sa3hzRxzx4lSzBTEk42WXuWcjO/J
OBuRpU9cyRrBrG7m+gg5pYaJjCGMrOQnihfa7MsllvhrXSYc7DGOFaNRKYRivHN9
wfqonQTEsja03Bb7Utme
=SqCG
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ssh install with freebsd-update

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/09/15 17:21, Randy Bush wrote:
 # uname -a FreeBSD foux.psg.com 10.1-RELEASE-p10 FreeBSD 
 10.1-RELEASE-p10 #0: Tue May 12 19:33:13 UTC 2015 
 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC

 
i386
 
 it's really p11 now
 
 if i run freebsd-update install of p11.  all looks well until
 the reboot, when i get
 
 Performing sanity check on sshd configuration. Shared object 
 libgssapi_krb5.so.10 not found, required by sshd /etc/rc: 
 WARNING: failed precmd routine for sshd
 
 This is VERY strange!  Did you ever have an incomplete upgrade
 from older FreeBSD releases (9.x) on the affected systems?  What
 was the version before you update/upgrade to the latest one?
 
 this is one of a dozen systems upgraded fom 9.3-stable to
 10.1-release p10 using a recipe in
 https://wiki.rg.net/wiki/FreeBSD9to10.  they all show the same
 symptom.

My guess is that there was some fetched 'freebsd-update' upgrade data
that was not applied, and the freebsd-update install have somehow
confused by that.

BTW. the supported errata branch is releng/10.1, not release/10.1,
which is probably why the svn co failed in step 1.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.4 (FreeBSD)

iQIcBAEBCgAGBQJVd4XpAAoJEJW2GBstM+ns1PkQAICofy0/pvNXSEVnYsHh4pdM
PP1XKj4PwzORlujwM1T3pjuyjxDgro7H1Hy+OTl2oU5da2c2pu3AoGGxIN9dkQii
0C4mvTQEv87Z5+AI2sGY3dTchk8QRB9EkUAp1wkENiu2Th/cM7Kgt0MA66UfAd6U
Gc4QxSFEu681gPBUQeTapUR4bC6NG4++0yBrFOtGZBiLA8IeSL+Y1uCcpupjMZJ5
qzYQsChFw0f47/WC05ZjfBbwB3ckuDJnN6G+GKRz7tWuQCRSRqGWqEMzrHTiOcvH
+dXW++4h8rb6nQFzPPCTaAJP9YvlvyHMumUDN52Lm4lNxMWFklHYe8AfF4f8kbU/
r7yZgmEjwBo2dN1hQnylvn9cwEaRpn/mNYYwjW3ih90HrINmMFXfrcQyD3I2WfLe
evLZoMdoJ1dJrq/9h3B0Ak7NAfoInXKVfEVHZ1arOGFmXhqbfIlVbzxrlfe5rxaT
3Vi5jL+3n4EgO/X3Fn3dWAH6Y4jf4a3OopA1h+peBEuCJWVFkR+loYsCr9g27s+R
PQBjrpiUnGYSa8WkFnK5XYTUcTVVdKJ+0XevTKnjZ44LaPJkj599fo92E5gqWUfe
eoqTaxPly/VTFqInpiR3ARG4Mmfot7UxdQv/rG6E4c3boWIV9P06JdQKocUnT2vO
gzSOOPm/aCsvq6TZju0q
=dsJf
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: FreeBSD Errata Notice FreeBSD-EN-15:06.file

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/09/15 17:55, Nick Frampton wrote:
 Pardon my ignorance, but why was this posted as an EN instead of a
 SA if it corrects security vulnerabilities?

We do not generally issue SA's for local DoS issues (historically
there were some, but in principal we don't do that).

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.4 (FreeBSD)

iQIcBAEBCgAGBQJVd5kRAAoJEJW2GBstM+ns//AP/2FjI1k6NnFuRWLkdRQLQPvK
gQr0ZwEZDnm/78gL/Sm3dR1bVt8VWmGHJyCfQrGEVISy7uvETaaodOoRNE4ZjAg+
RHoszk6s6ufXkjr2qwXI4VDUHvjZeru7WfguqKfGn2499WJOzRBbzWnTe/e59SFb
+K99Smci0cXCzehahO/WstM1McPg1LDsEo3/AVAZWrV56Xb/F7DOz1uxIiESprlp
xUoaeX5KhUKoME0m0RN48IpOW3tbWjyO6go5sX3PpTZg/CjFxktIN00vTKFOLs7z
MhogJD+mI8K4t8Pw5kcfTeAmcCtc77EMi/YtzpCKwzYhltGIsCQDZ2rLig4yDvOv
EAw/mwYh0NVXOQj/tUg9Uf0EwhxQ13jAfkhfOcNVGl+Qt3tbbH0QDXiMEOtLadZC
PRqb/IdwEyBQKxKrg82mqZmJ67ZWC22EbqcrW6Czie4q6lWk3qF4CeuBp4D1tIuJ
RDMO4A4iXAhM1A7h9zVn07SUC3Qv9b1JrcGUN1Pv8O0jn2KIALpF+fLqVBEtYEoX
//IUbQ1BYyfIO33SiqVPaB6hsKLvr5zdmKHdYwr2FHr6e03L66Z+GxIjn6OnIT1e
nMPDmphl27/St16c6PouuzS+WQbyDlVZrNogVzslGGSyNBwMFJjALrNjKfZTkSLD
slx1EYwywyX2omdCn89R
=ffrR
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ZFS out of swap space

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 3/27/15 05:26, armonia wrote:
 After importing I press ctrl + t and here's the conclusion:
 
 load: 0.20 cmd: zpool 725 [tx-tx_sync_done_cv] 32.50r 0.00y 5.59s
 0% 6432k

Have you ever enabled e.g. dedup on certain dataset(s) and have a lot
of files, and the pool don't have 'async destroy' feature enabled?  In
that case the fastest way to recover, if this took too long, would
probably import the pool read-only and copy data to another pool.

On -CURRENT you can use dtrace -qn 'zfs-dbgmsg{printf(%s\n,
stringof(arg0))}' to see more verbose information, they are not always
helpful but will give you better idea on what is going on under the hood
.

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJVGP0IAAoJEJW2GBstM+nsjRUP/11uzAQjAhQdOKTDMYt9gbTt
DsMn1C5x3X+btMuMyJ6JfxiOhm1qxolDEsjilodpj+i7m09a42N1GZrqEKBIY4PP
wvVwHHGuG1+zvpcQYfyWz50lKOgSIeLY3CUkyRRLHu3XsGrhj6uVEBjJRqLzRFof
oCTlAPeXFkZgs5wkufwJ9kx5JJT4UvZKyBbj3CNL7xMGmEIKffIMZWQv3SzIROdU
3QLjKSxTX969l6bNPEG/Fr262SZvXq9wPF2hbXs+AgLeDduz+ILhOMF1Za9+PTu+
U5zJM5MUEOimacAys0ldQ5kVarufFySCv1VXvmIyUPPsVu+WuBAWE7lC1c8tdNnh
vawMSfA2z5GtowxcpRVkl0CuVdO9AHZ2cHQzqrVh+rC/3HEdpCiUYakvoU3g1LhT
9Yo1s6dDUQcl6cfObDw5QU1eNc5dnCwENef5UnraH/GYbV4u8j4ClBPD7jw7zdlo
jgGVMcXORJEztYW3LCQNUU0phP0c3jNm9x84Do4AhLPMTPfxPrXiHJy/BtSrDw4B
BZlvqDRhaaOlTU/RPoAIdzFm1PztGLG2r5zrPR/ZKB3UquDctWSNz84jvgN3OK0d
XyTsJsAH3lRLO5RNIt/Km4z86vnmL0WZdiY919XsBWlVbh1db+qKHs/KeSpaJ1Fd
wqeqhWwU8l5yGKik19du
=Bm6L
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ZFS out of swap space

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/30/15 01:32, armonia wrote:
 Yes, my mistake was probably that I have included data
 deduplication to see how it works, but not turned it off at the
 right time. In this case, the machine memory of 4 GB 
 
 async_destroy - too enabled.
 
 That is the conclusion I have deduplication disabled.

Hrm, usually async_destroy should be enough to protect against this
situation.

Can you try if setting the sysctl variable vfs.zfs.free_max_blocks to
a limited number, like, 100,000, would make the pool import properly?
 You may have run out of memory because of too much data being free'ed
in one transaction group?

(I would recommend doing this after importing the pool read-only and
copy your data off, though).

 How to import a pool of read-only?

zpool import -o readonly poolname.

 Thank you for your response.
 
 zpool get all zroot NAME   PROPERTY   VALUE
 SOURCE zroot  size   230G
 - zroot  capacity   24%
 - zroot  altroot-
 default zroot  health ONLINE
 - zroot  guid   1229884058434432944
 default zroot  version-
 default zroot  bootfs zroot
 local zroot  delegation on
 default zroot  autoreplaceon
 local zroot  cachefile  -
 default zroot  failmode   wait
 default zroot  listsnapshots  on
 local zroot  autoexpand off
 default zroot  dedupditto 0
 default zroot  dedupratio 1.02x
 - zroot  free   174G
 - zroot  allocated  56.1G
 - zroot  readonly   off
 - zroot  commentZFS
 local zroot  expandsize 0
 - zroot  freeing0
 default zroot  feature@async_destroy  enabled
 local zroot  feature@empty_bpobjactive
 local zroot  feature@lz4_compress   active
 local zroot  feature@multi_vdev_crash_dump  enabled
 local zroot  feature@spacemap_histogram active
 local zroot  feature@enabled_txgactive
 local zroot  feature@hole_birth active
 local zroot  feature@extensible_dataset enabled
 local zroot  feature@bookmarks  enabled
 local zroot  feature@filesystem_limits  enabled
 local
 
 
 ???, 30 ? 2015, 0:36 -07:00 ?? Xin Li
 delp...@delphij.net:
 
 
 
 On 3/27/15 05:26, armonia wrote:
 After importing I press ctrl + t and here's the conclusion:
 
 load: 0.20 cmd: zpool 725 [tx-tx_sync_done_cv] 32.50r 0.00y
 5.59s 0% 6432k
 
 Have you ever enabled e.g. dedup on certain dataset(s) and have a
 lot of files, and the pool don't have 'async destroy' feature
 enabled? In that case the fastest way to recover, if this took too
 long, would probably import the pool read-only and copy data to
 another pool.
 
 On -CURRENT you can use dtrace -qn 'zfs-dbgmsg{printf(%s\n, 
 stringof(arg0))}' to see more verbose information, they are not
 always helpful but will give you better idea on what is going on
 under the hood .
 
 Cheers, ___ 
 freebsd-stable@freebsd.org 
 /compose?To=freebsd%2dsta...@freebsd.org mailing list 
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable To
 unsubscribe, send any mail to 
 freebsd-stable-unsubscr...@freebsd.org 
 /compose?To=freebsd%2dstable%2dunsubscr...@freebsd.org
 
 
 
 --

- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVGZPKAAoJEJW2GBstM+nsPIAP/2aX5MItnX/LiLII+xKp/Hnx
9TZWUdpEqwOpIWovjiF7N+Vp9Uz8RCCHl5yzMbd5p/cvaP6h7oQZiJYzBDLVRx61
Rk3Uz7/SyycWPXlD6lhNYPZ9QrptgO6hhX5y4YHxOlibhe7NLCmZYNxBqNsqR0HW
FoseCRP2+ima4Qu5P4dVKDCnKwMdifP7qvrbOZcyYWIVThVBH14Rp7w9zfiiAN6v
AYSY9JLMYQGILfexORo/LG+kYI3gT2CIhYVNpfCsQLo5GNOucAZNYM5oO4aCt/BQ
2DIzhp58F1z7JYUwZVJ0p7GSjuZ2peWqYYyGMqFkBU0cydskGj+wGwu154sx6Vyg
xAgzqH/jG95DqkC6yDRoy/bvJ0zam2z3N9jR+XRqgVsuwYbEG7dQp6TBByN5PWp+
UaRexsvknjNJA6Otqei5qQ5fcXfhaalTD+/3XB3eqExJa6sbONZ6qJdLeiDYe+3V
wNRnuDQwatLCkLhQoFbXIdXQJ16Da4evmMrHd+YsKrytx2F/wMoNZru7Ilv6X+5L
LhuGg26Kh2ohZQGvn4cWCus63wRWweEjpTpD4Ng2Ok+qIEgquC9kcveV1TSwxWi1
ZusD5hYqJXO2rA6iB2MyQqZi6t4fBK00CG7SkAegrNaKnH2e245s7qwsg6huKKUA
yMt5wuj4GXbRg9yjWs0j
=m5xz
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: SSH hung with an OpenSSH_6.6.1p1 -- OpenSSH_5.8p2_hpn13v11

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/26/15 17:30, Wu ShuKun wrote:
 Yep. I'm upgraded  via freebsd-update. and I have no idea where
 i'm wrong either.:-[ Is it likely I have no luck in other words?

Can you try specifying -o KexAlgorithms
diffie-hellman-group-exchange-sha1 when ssh'ing and see if that would
mitigate the problem?

My gut feeling is that somehow the HPN patch have broke certain key
exchange negotiation steps of OpenSSH, which was not exercised in
earlier versions of FreeBSD due to the lack of ECDH key exchange?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVFKndAAoJEJW2GBstM+ns83UQAIjsYGkaBJstCW1F/Rp1Q1mm
Hg63DSYteIhOfAJ/m3M4qpfWJq3vf9ID0QjN0oPkfpKvwK35P3hgkT0y/hleRjpG
YdcDqlW6Adm8ZmaI+9BdZSqga+plfXyjeyChgjXSfocT7Is+s0+zSS4km3rl91aR
Jhv1uVr/gMKUTnXlCaNSDajzHpEYxaKu1ipp1OTfdwnSdoK1VpVN1dcDHFK0stts
qdrFiOQWKaUXiXnfVTrGRowTBk46C429k+66YLKmYLfSj/0toiCGRlrwfCLTYFHM
Uc0oGWTJbqyhd9lpf5Q90B7pvJ7sBaatvEt0i9LgyuyfZQieAX6hidgnEV5cI4nC
CYfMwjXRSOChcvpBtjsC/Az+7FE0mOXN9NAmwPcQ5XO0JtipNrCKwN1oR6nG2Rk5
c1qBcc9fYZBYRwdnunEG3FlNgnzi5baoHszSoHGmkew4dbUZsTIYEknsMlP0B3BP
k0RHnl/083JTDP55WR/IEJF0O0LVGnrI4UQEDq66hfNSNoLLJkMkyC95EIZpNHVo
uo6TI9TP3QvJBp/iPIuIdQaux7DFD/ba1htXWwOsf4Sw2brHYyvLGfnHkFOBrFNt
LkiYZf9CCsawDU+BGSn2OJCndDidLuJV4H2jtZFbJ+vo13nq0t+ZmA7ZtEOz4EMr
v2DmLBOFU3jxsrAwmkhJ
=HsH2
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: RELENG_10 performance regression (was Re: 35-40% performance drop releng9 vs releng10 openvpn

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/20/15 17:15, Konstantin Belousov wrote:
 For the purpose of devfs, does it make sense to bump timestamps
 like normal filesystems for each read/write operation?  Looks
 like Mac OS X will bump timestamps for each operation but Debian
 don't.
 
 First question is, what timecounter hardware is used.  I would
 accept some slowdown from hardware like HPET, but it is indeed
 surprising if caused by TSC.

It was HPET (see earlier discussion where a FlameGraph is posted).

I've done a survey on a few other operating systems, including
OpenIndiana, Debian and OS X.  Neither OpenIndiana nor Debian update
timestamp for read/write events so I'd propose this change to make it
a runtime configurable behavior and disable by default:

https://reviews.freebsd.org/D2104

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVDLscAAoJEJW2GBstM+nsGtMQAKyh3kW6VWPnCd353KELqeoE
3n295iHqVjAF6vszt71cfiAqlz0oSH+5i2SfR1LKVXH4cb2gMbXYbMeJVQiV7L93
8xEsBNtPF4Z/fxwyEBfFb3WcXHo+TGjvaCEbsuJIFKhqa4GPY230/7JELN/LXuNd
HJlP7YECNPgeVWyYuCdZkLu/BMOPjL44/wcC/YuXSQP65TK54kx59KLg671o9Z2R
ffpljAmJSqpNjas41qyVN+SNxr9ga8oQA0LTf8lbn3r4o2mx+te8yzNcyIn/gCU8
jawDGfGNiEvCTr76ST6rvELy4jFbmZyNFrbu+TA6VDT2/CCh1x5qhDceXTnZKPtX
iJFpDKsl87R5aXdRQjwCZKkTdaJ7AuRAG0lrmumxIlblgDmaDsVbmaqR1CU0JzWI
rvGblL6iwm/4pL+O9Igkr6oN6+yd1/9KM2yCB5BZDokLnoj6INWOft4z6jGyOUWh
T3oNVfB48g/j5NKRyU/vFvJIUix2mbE5ziem+RyLU6x/UOdYQJsKRIlN6xPiIx73
/G7kpT1JbsoS47fyere5jeUV2UOurRuH5UfBHjJCJ0X44tzrsMhTm3Vs2cOzJP7K
6SNbyxyCbX3uJN1Aq9nhg2scIVieV1/BRLoeI6LEVVZKTTig4LA8ekzb0P6e1Fwg
f9rvXNwpdeZPmsDwdpff
=Uxnt
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: RELENG_10 performance regression (was Re: 35-40% performance drop releng9 vs releng10 openvpn

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/20/15 14:02, Mike Tancsa wrote:
 OK, I think I found where the RELENG_10 performance loss happened.
 It seems 
 https://lists.freebsd.org/pipermail/svn-src-stable-10/2015-March/004778.html

  is the issue.
 
 Testing with a kernel from r279796 I get 76-77Mb of throughput.
 With r279848 it drops to about 60Mb

Hrm, looking at 'diffgraph.svg', it suggest that writing through devfs
have incurred a tax on writev(2), which is basically this codepath, if
my reading is correct, in sys/fs/devfs/devfs.c:

   1676 static int
   1677 devfs_write_f(struct file *fp, struct uio *uio, struct ucred
*cred,
   1678 int flags, struct thread *td)
   1679 {
...
   1703 if (uio-uio_resid != resid || (error == 0  resid !=
0)) {
   1704 vfs_timestamp(dev-si_ctime);
   1705 dev-si_mtime = dev-si_ctime;
   1706 }

Further looking at the code, in devfs vfs_timestamp() is also called
when reading from a device node.  When the setting was 0, the code
would return time_second directly instead of attempting to read the
timestamp.

For the purpose of devfs, does it make sense to bump timestamps like
normal filesystems for each read/write operation?  Looks like Mac OS X
will bump timestamps for each operation but Debian don't.

Cheers,

 ---Mike
 
 
 
 On 3/20/2015 1:36 PM, Mike Tancsa wrote:
 OK, just to refocus,
 
 I had been tracking down what I thought was a regression between
 RELENG9 and RELENG10, but looks more like an issue that cropped
 up somewhere between the beginning of March and now.  For
 RELENG9, I was actually using a kernel from sources back on Jan
 29th by accident.  If I bring RELENG9 upto today, I get a similar
 performance loss.
 
 Again, I am testing a simple VPN router setup
 
 server1 --- apu --- server2
 
 where server1 connections to the apu via an OpenVPN tunnel and
 server1 sends packets via netblast across the tunnel to server2.
 
 I get the following throughput using netblast through the tunnel
 on 10
 
 Using # netblast 1.1.2.2 500 1200 15 (server1 to server2) on
 10.x
 
 KernelMb/s rev r277684  76.7563 r279978  59.3233
 
 All good at r278533, r278534, r279467
 
 But at r279978 its quite a bit slower.  So somewhere between
 r279467 and r279978.  I will keep trying to narrow it down...
 
 
 ---Mike
 
 
 
 
 
 On 3/19/2015 8:26 PM, Mike Tancsa wrote:
 On 3/18/2015 5:14 PM, John-Mark Gurney wrote:
 # dtrace -x stackframes=100 -n 'profile-997 /arg0/ {
 @[stack()] = count(); } tick-60s { exit(0); }' -o
 out.kern_stacks
 
 Also, another thing you can do is to compare the two using
 differential flame graphs: 
 http://www.brendangregg.com/blog/2014-11-09/differential-flame-graphs.html





 
Which will highlight where the performances differ...
 
 OK, some more data points.  It seems a performance regression
 happened in RELENG_10 somewhere between r277684 (late January
 2015) and now. Using r277684 on RELENG_10, I can get about
 75Mb/s of throughput on OpenVPN. Still not as good as the
 83-85Mb on RELENG_9, but much better than the 61Mb using
 RELENG_10 from the start of this week,
 
 For the differential graph, see
 
 http://tancsa.com/diffgraph.svg
 
 and
 
 http://tancsa.com/10-r277684.svg 
 http://tancsa.com/10-r277684-kern.svg
 
 ---Mike
 
 
 
 
 
 
 
 


- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVDLMDAAoJEJW2GBstM+nsmjgQAKGNdw70A2lfrVn8ngLympDM
HeJKVCRtjaZselJpVnkyy8igBU6TX0Ae66R4IPNBpi9aLcGb/xscDgYKNh2dZc4H
LjfyiXW62JwggXt+PCUjrLF3sbrlCI8ySTNLnILTs/CRFwdJXALFHWXDEtuMg+AT
Mto3HxKlRZlEbWHaKbWmR4uysks6KNYJXSCnw/VtSFvlVUSwpyNz+soygrajZPKC
PPOpjDqx2rvVxQwFaHF+ysTzKhvQSuJg+C5M9iKu4wgHd5QNuJ8IliAocVvPig9u
gushcc2MxGPyzG24Telc3Vc5T+pbCexiP3hRtFY0/okADG4O47tuoJOY09gp28Tq
5X3eXCXkBGfCtriv6aPf//jAQ6duDrGTDmYcI+FGIDp3/FG71adNTqZ6fcqFAL/+
JHO39qpytOruVVjFyjEvQBslYEKWUZJBGZ82q6kuE+811TZxdMGVLh3PICxiJw0l
SJcTR52UEYNp1kX+KhFXpz6cvV0Za5bJh/qHnC/1uzHvLYE7MDTinwDPb7LyK01G
fg+Kls6YCAv6rh4mDzWJCg8aTaWmbtfn2+ETwx74if6Z8LjTB1VdmZ4y336YRY2f
mFhV6eYAvvziIIMUvTQjAwyIcCtc65dvseOpgDdnWPFq/N+K4Jfg9Ast6mSHBYF2
FjvUzNg8OYvyfq5/TdPB
=djPp
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

HEADSUP -- issues with SA-15:06.openssl

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Please be advised that we have noticed some issues with
SA-15:06.openssl and are actively working on validating the fix.  A
copy of draft errata patches is attached.

My apologies for this mess.  Revised advisories would be announced
once we have made sure that everything is correct.

Cheers,
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVC3a5AAoJEJW2GBstM+ns+s4P/A+M1xdhycNvo0qsSTfLcah1
uAvZnWLo7gobBM8CxlrgtrXkRsYwGp7Q6bzW63PA+8qE4FIht7/fgMpXNHufK8bz
1b/h0KrnPs7rEBe3K13RJEI5ufVb/Xj1mOVY59GCJ76QuekN9nEGbYRE2Fbg8yhE
iOWLpNWKsQBPdDhMfqmayUZmuZf8pPhgIEwzEsSefnZhe1XrN5kX8s4T00aWieSz
MbEkLRfOlVn+qeXlZOp6R96vEoNYaGeTnX7AN16wKg+0Sipk9AJBDFUODjPQgzIr
4BbL8TpW3DvC0cOOpJnYb4KVy7o+54QMFoDr0Gt0R/HZQj3lzdtOBbTFfNs82KDl
wWPZB3G4CY5l2d1CYQjUQtXmuRnro3JrslBbx00RcLAs9deDtIoJVqHQv0wiLSlZ
jv1lWZbyUhVw/9cY4A8c1QRs01YWGGPZV4cuO0RN56zs6ipIK/0XkzYrY+b2yWku
U5slMwqhuREZ1ypLcfUwQHgnyX094wTXkuJQ2l+4dMiO8wV6gW5x3C2lOe/0OHYP
L0Atb84aYvMG9RlFCTF6CB2226tRjqxuFhI+x2d0choVJpMt5SJ2cfBi5E3e9Ooy
roPVTlOwB1tsYVi3fjYjwJZ5TiPDq3ekcByTmIrasrsFB5+9tBDBnRC5nERNITM4
o69NYExg60dSJ8p5RTeE
=wG30
-END PGP SIGNATURE-
Index: crypto/openssl/crypto/asn1/tasn_dec.c
===
--- crypto/openssl/crypto/asn1/tasn_dec.c   (revision 280272)
+++ crypto/openssl/crypto/asn1/tasn_dec.c   (working copy)
@@ -127,22 +127,16 @@ unsigned long ASN1_tag2bit(int tag)
 
 ASN1_VALUE *ASN1_item_d2i(ASN1_VALUE **pval,
const unsigned char **in, long len, const ASN1_ITEM *it)
-{
+   {
ASN1_TLC c;
ASN1_VALUE *ptmpval = NULL;
+   if (!pval)
+   pval = ptmpval;
asn1_tlc_clear_nc(c);
-   if (pval  *pval  it-itype == ASN1_ITYPE_PRIMITIVE)
-   ptmpval = *pval;
-   if (ASN1_item_ex_d2i(ptmpval, in, len, it, -1, 0, 0, c)  0) {
-   if (pval  it-itype != ASN1_ITYPE_PRIMITIVE) {
-   if (*pval)
-   ASN1_item_free(*pval, it);
-   *pval = ptmpval;
-   }
-   return ptmpval;
+   if (ASN1_item_ex_d2i(pval, in, len, it, -1, 0, 0, c)  0) 
+   return *pval;
+   return NULL;
}
-   return NULL;
-}
 
 int ASN1_template_d2i(ASN1_VALUE **pval,
const unsigned char **in, long len, const ASN1_TEMPLATE *tt)
Index: crypto/openssl/crypto/ec/ec_asn1.c
===
--- crypto/openssl/crypto/ec/ec_asn1.c  (revision 280272)
+++ crypto/openssl/crypto/ec/ec_asn1.c  (working copy)
@@ -1142,8 +1142,6 @@ EC_KEY *d2i_ECPrivateKey(EC_KEY **a, const unsigne
  ERR_R_MALLOC_FAILURE);
goto err;
}
-   if (a)
-   *a = ret;
}
else
ret = *a;
@@ -1225,11 +1223,13 @@ EC_KEY *d2i_ECPrivateKey(EC_KEY **a, const unsigne
ret-enc_flag |= EC_PKEY_NO_PUBKEY;
}
 
+   if (a)
+   *a = ret;
ok = 1;
 err:
if (!ok)
{
-   if (ret)
+   if (ret  (a == NULL || *a != ret))
EC_KEY_free(ret);
ret = NULL;
}
Index: crypto/openssl/crypto/x509/x509_req.c
===
--- crypto/openssl/crypto/x509/x509_req.c   (revision 280272)
+++ crypto/openssl/crypto/x509/x509_req.c   (working copy)
@@ -92,6 +92,8 @@ X509_REQ *X509_to_X509_REQ(X509 *x, EVP_PKEY *pkey
goto err;
 
pktmp = X509_get_pubkey(x);
+   if (pktmp == NULL)
+   goto err;
i=X509_REQ_set_pubkey(ret,pktmp);
EVP_PKEY_free(pktmp);
if (!i) goto err;
Index: crypto/openssl/crypto/asn1/tasn_dec.c
===
--- crypto/openssl/crypto/asn1/tasn_dec.c   (revision 280272)
+++ crypto/openssl/crypto/asn1/tasn_dec.c   (working copy)
@@ -125,23 +125,16 @@ unsigned long ASN1_tag2bit(int tag)
 
 ASN1_VALUE *ASN1_item_d2i(ASN1_VALUE **pval,
const unsigned char **in, long len, const ASN1_ITEM *it)
-{
+   {
ASN1_TLC c;
ASN1_VALUE *ptmpval = NULL;
+   if (!pval)
+   pval = ptmpval;
c.valid = 0;
-   if (pval  *pval  it-itype == ASN1_ITYPE_PRIMITIVE)
-   ptmpval = *pval;
-
-   if (ASN1_item_ex_d2i(ptmpval, in, len, it, -1, 0, 0, c)  0) {
-   if (pval  it-itype != ASN1_ITYPE_PRIMITIVE) {
-   if (*pval)
-   ASN1_item_free(*pval, it);
-   *pval = ptmpval;
-   }
-   return ptmpval;
+   if (ASN1_item_ex_d2i(pval, in, len, it, -1, 0, 0, c)  0) 
+   return *pval;
+   return NULL;
}
-

Re: Another bug in SSH in FreeBSD 8.4 (sftp cannot create relative symlinks)

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

FYI, Dag-Erling have committed the upstream fix to -HEAD today and we
will make sure that this gets merged before 9.2-RELEASE.

Author: des
Date: Tue Aug 13 09:06:18 2013
New Revision: 254278
URL: http://svnweb.freebsd.org/changeset/base/254278

Log:
  Apply upstream revision 1.151 (fix relative symlinks)

  MFC after:3 days

Modified:
  head/crypto/openssh/sftp.c
Directory Properties:
  head/crypto/openssh/   (props changed)

Modified: head/crypto/openssh/sftp.c
==
- --- head/crypto/openssh/sftp.cTue Aug 13 09:04:20 2013
(r254277)
+++ head/crypto/openssh/sftp.c  Tue Aug 13 09:06:18 2013(r254278)
@@ -1328,7 +1328,8 @@ parse_dispatch_command(struct sftp_conn
case I_SYMLINK:
sflag = 1;
case I_LINK:
- - path1 = make_absolute(path1, *pwd);
+   if (!sflag)
+   path1 = make_absolute(path1, *pwd);
path2 = make_absolute(path2, *pwd);
err = (sflag ? do_symlink : do_hardlink)(conn, path1, path2);
break;

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (FreeBSD)

iQEcBAEBCgAGBQJSCrEpAAoJEG80Jeu8UPuzOsMIALKkg0+g2IhX5dAxGL9UU6AT
7/f/iEfDIYmTv1QRwZQ1B544Mf02NmSztEmVz5pwQCsSmw+rmF27t6iBbN6q5ipM
XUB+A3VsAGRmI8j/2ixwzs3AXTAdC/uhgswVMQyiuS35cYaArGAirZWxUESGIiqk
K7Hnc8vYDWZ+hbNIpPFNNvsdunltq42BJ5kHh07X3elqR7lJaGC7qQM8IoHo90nG
R4GPagM6tbuXdB/UzrW0ozgRf4VqE+SFCC8UAnnE/E61h7Fb0/GkD0XlsdTFrl3f
0Aadhs+jfwxV7UJgyGvuep9RsFuM/mUMHXAw8K3vuPbF6KA9U7XI1KmS8ym5G3A=
=ERoe
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ZFS Panic after freebsd-update

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/01/13 09:10, Steven Hartland wrote:
[...]
 This says your running a 8.2-RELEASE-p3 kernel not an 8.4-RELEASE
 kernel.
 
 Did the upgrade fail or is that dmesg / uname from your old
 kernel?

Looking at the context, he used freebsd-update to update 8.2-RELEASE
to 8.4-RELEASE (which, the first step would be updating the kernel)
and booted with that panic, and reverted to old kernel.

It would be helpful if we have address of stack frame #6 as well as
the tuning you he have done (in loader.conf), plus the actual panic
message (looks like a kernel trap 12, but a glance at the code I
didn't find a candidate line where this happens).

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJR0e91AAoJEG80Jeu8UPuz05MIAK21VdKOkVNISzrd9ZDKTpml
EjKtrOUhXreI21XyuoVxGboIjNfBxbfPxu07Tj6ocY8LwwneMot9nW5d3xtsS71A
ap9Ho3KFUKGv5RTHWO7mhbKhSXnKBl/SmyIeLx//I7vCfxQb0MWUT7bdRF56Eojj
lUz6dnLDXt6q3p3TGC17mwETHbdvdrr4ptBANAXFaY763WFSW6pLWUr5KIxZ7f7i
DqNKpShTC4LsVr6OZjq70E+1XFCM7E//ZKVbJWBNrGJd7kmk7raq7ERx8tJqcWu6
sdxWcjbG6bOlCmONcozohNsqRvpTKu1VK6JsWVBUq9Et2nY/2rKvu5lKyIvxPBg=
=NmTM
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: [releng_9 tinderbox] failure on arm/arm

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/27/13 09:23, FreeBSD Tinderbox wrote:
 [...] cc -O -pipe  -I/src/usr.sbin/tcpdump/tcpdump
 -I/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump
 -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -DINET6 -DLBL_ALIGN
 -I/obj/arm.arm/src/tmp/usr/include/openssl -DHAVE_LIBCRYPTO
 -DHAVE_OPENSSL_EVP_H -DHAVE_NET_PFVAR_H -std=gnu99 -Wsystem-headers
 -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
 -Wno-uninitialized -Wno-pointer-sign -c
 /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-olsr.c

 
cc -O -pipe  -I/src/usr.sbin/tcpdump/tcpdump
- -I/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump -DHAVE_CONFIG_H
- -D_U_=__attribute__((unused)) -DINET6 -DLBL_ALIGN
- -I/obj/arm.arm/src/tmp/usr/include/openssl -DHAVE_LIBCRYPTO
- -DHAVE_OPENSSL_EVP_H -DHAVE_NET_PFVAR_H -std=gnu99 -Wsystem-headers
- -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
- -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
- -Wno-uninitialized -Wno-pointer-sign -c
/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ospf.c
 cc -O -pipe  -I/src/usr.sbin/tcpdump/tcpdump
 -I/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump
 -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -DINET6 -DLBL_ALIGN
 -I/obj/arm.arm/src/tmp/usr/include/openssl -DHAVE_LIBCRYPTO
 -DHAVE_OPENSSL_EVP_H -DHAVE_NET_PFVAR_H -std=gnu99 -Wsystem-headers
 -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
 -Wno-uninitialized -Wno-pointer-sign -c
 /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-otv.c 
 cc -O -pipe  -I/src/usr.sbin/tcpdump/tcpdump
 -I/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump
 -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -DINET6 -DLBL_ALIGN
 -I/obj/arm.arm/src/tmp/usr/include/openssl -DHAVE_LIBCRYPTO
 -DHAVE_OPENSSL_EVP_H -DHAVE_NET_PFVAR_H -std=gnu99 -Wsystem-headers
 -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
 -Wno-uninitialized -Wno-pointer-sign -c
 /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-pfsync.c

 
/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-pfsync.c:
In function 'print_src_dst':
 /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-pfsync.c:330:
 error: 'tcpstates' undeclared (first use in this function) 
 /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-pfsync.c:330:
 error: (Each undeclared identifier is reported only once 
 /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-pfsync.c:330:
 error: for each function it appears in.) *** Error code 1

This should have been fixed in r252307, sorry for the breakage.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRzHeLAAoJEG80Jeu8UPuzGGMH/RAInuTUXIHBsSdq72p5EOlf
3hYni/HE4FwNAo5nhmO6cgLse6Yomeq7lxHxaPZfz179RErZHY3fnSiat00hBMN6
vX76Zg5bOEQs/5omtiM94olJvz5VRCIIor70l0q+ld3ZVmzPnWoWz9YoEo3rN6hc
23Iy5wCTPO0mkzu+1dBrAHj8RfKJQEOo32d/SWF0WMkPt2Yec14yQ8Pl1N4thcu1
cOVwBN3ItoOvDPTYgi9769+BXn7kI1yfOj8eYW2+v5YROXdQrKciqKeGOwGglGHz
EFv1a65p1dBmGbRK8CHNQwDAgaKI0Si47NFzu7vMV2HLbvQMvqw77jDXuIxfivg=
=oPK0
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Another bug in SSH in FreeBSD 8.4 (sftp cannot create relative symlinks)

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/24/13 15:11, Miroslav Lachman wrote:
[...]
 The patch seems really simple and I know how to apply it, but I am
 not able to compile and install only fixed sftp command instead of
 the whole userland. Can you push me to the right direction?

I think you can go to /usr/src/secure/usr.bin/sftp and do:

make depend
make

Then, as root:

make install

I usually do a full world build to make sure that this doesn't break
something else but this change should only affect sftp(1).

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRyMnoAAoJEG80Jeu8UPuz+JwH/20g7SVtpA+sbNmmZD2NQI+U
e5/gj4sujz1H509V2w5shaJw2ScUoHnyURQSeDxe0sBvkcYVCn0jLg1cKfs5pyjn
yLV150XTR0Dv4VPlGiVkqGrgmH6gNkBN4sQoQeC/zgSttXPRnbpjuiLVQz3LcOs7
5g4H6fKBsQX/bWEHOgaKSw63CLY8RIKohtzL5OIUEHWyzVFWeX7U/Mreh5KgE9jY
C20kpDrqATJgFBphyQDOEAHC/RZLzX3xqM9JI+vYFse8ra6JttvLBBQ7drhefbrc
7OZgpb4+CTAYLtk8b80jFSALCfGs962+seMLHzghJ5F+NL4V0kW/jFODaodDQcc=
=e84l
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Another bug in SSH in FreeBSD 8.4 (sftp cannot create relative symlinks)

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/21/13 16:04, Miroslav Lachman wrote:
 1) Is there some way to create relative symlinks with OpenSSH 6.1?

No.  It seems like a regression and can not be worked around.  I do
have a patch (attached; against crypto/openssh/), and my test shows
that it would fix the problem.

 2) Was OpenSSH 6.1 tested before importing in to the base of
 FreeBSD 8.4 release? These two bugs seems serious to me.

This code is not new: it was in OpenBSD 3 years ago, and in FreeBSD
for more than 2 years (r221420 or 2011-05-04); OpenSSH 6.1 was
imported last September.  This issue you have just raised have been
there since FreeBSD 9.0-RELEASE.

So to me it seems like that the two issues are either rarely hit by
the general public (counting myself in: I have never used sftp to
create symbolic link remotely and have thus learned something new
today), or those who hit this have choose to keep silent about it.
Fortunately we have you noticed and reported the problem.

As a community effort, we really *need* people to grab in-development
snapshots and provide us the feedback.

 3) Is there any chance to fix these bugs in FreeBSD repository, or
 do we need to be bug to bug compatible with other systems using
 OpenSSH 6.x?

I can not make a promise as I am not the maintainer.  However, I have
already reported this issue to upstream OpenBSD developers, so if this
was accepted by the upstream, we will commit the change locally to fix
the issue.

Unfortunately, it is too late to fix this for 8.4-RELEASE, and unless
we see widespread complain, I don't think the problem would affect a
significant amount of users to warrant a errata for supported
release (8.4-RELEASE, 9.1-RELEASE), however, if it would be fixed, the
fix would be merged to 8-STABLE and 9-STABLE and will be shipped with
future releases, if the fix enters the development branch before them.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRxPXUAAoJEG80Jeu8UPuzzRAH/AnNKnmsb6vX9LCNRsLtb2SG
bk2J4lx5XLK3sCYEeSL/npBtpwShGLMRnfTeb7oAPBU0skzpppHDpvwp8aIZUAGB
uMwMrln2YPKYfUJvtkPdUC+5Jm8OHnxwoYepOXkZSQy8R3ii1Q2Kpk9uGbez1i2i
iFaP+bQoCJxX8NdTRE/WrPjpfgq8KvUOowBn21dGLZ+MGUL5RlffvrOgth8Py4rp
ByekHuvwNz0i5wxILmriPKg04MhI8Ljy6Y8KxjZhn6v3fjEO7D5FvVlJP8us9iu0
AsFbnkBOvaYxJFDCmlh7u4fumCcsvtwmsmNbiqFRdQVbDuyMdvf880kNrmgCb5k=
=vS/U
-END PGP SIGNATURE-
Index: usr.bin/ssh/sftp.c
===
RCS file: /home/openbsd/src/usr.bin/ssh/sftp.c,v
retrieving revision 1.143
diff -u -p -u -r1.143 sftp.c
--- usr.bin/ssh/sftp.c  18 Apr 2013 02:16:07 -  1.143
+++ usr.bin/ssh/sftp.c  22 Jun 2013 00:26:00 -
@@ -1313,7 +1313,6 @@ parse_dispatch_command(struct sftp_conn 
case I_SYMLINK:
sflag = 1;
case I_LINK:
-   path1 = make_absolute(path1, *pwd);
path2 = make_absolute(path2, *pwd);
err = (sflag ? do_symlink : do_hardlink)(conn, path1, path2);
break;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ZFS LZ4 Upgrade

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/03/13 11:52, Kenta Suzumoto wrote:
 Hi. I'm planning on doing a ZFS root installation on a remote
 server very soon. The company only offers a 9.0 and 9.1
 installation and rescue (nfs/pxe boot with ramdisk basically)
 system. I'd like to use LZ4 with the ZFS root pool, so I'm going to
 be upgrading to -STABLE once I have the initial system installed.
 Here's what I'll do:
 
 - install the 9.1 system - svn source, buildworld/kernel, install, 
 reboot - upon booting the -STABLE system, begin enabling LZ4 
 compression on /usr/ports /usr/src etc.
 
 Will this work, or do I need to find some way to initially create
 the zpool with a -STABLE system? Is it just a matter of running
 zfs upgrade and zpool upgrade before enabling LZ4, or am I
 missing something? Thanks

This should work, you don't have to have the pool created on a -STABLE
system and can always do 'zpool upgrade' when necessary.

Please note that if you want to upgrade the root pool, make sure that
you have a fresh bootblock before rebooting (zpool upgrade should
give you a reminder).  The FreeBSD ZFS boot code supports booting from
LZ4 compressed datasets.

I would recommend using a dedicated root pool by the way, it have a
lot of advantages, like you can use a separate ZIL device for the
non-root pool, etc. and have the flexibility of using different RAID-Z
layout for different purpose (e.g. mirror for boot pool and RAID-Z for
the rest), so your remote hands would be able to just remove one disk
and your system is bootable, in the case when the first disk's boot
partition is physically damaged.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRrSLoAAoJEG80Jeu8UPuzLW8IAMRJJHloskYlrikKGw/Iao8A
jlifL2sDpnztgqhGtfltXOIyfKJL7EDw8s8ccJq8Xy1vKy2pndOgCc7GRfuvYS64
07kGrEKQKAv0BcrD6uddtMFstDdrI7cnK3btyAavNJhXR/b2A8f8/jze13mPpdUJ
DS2PBJ0rwmHqU7VXxkCq/M8atZGT7pq2ednPcHXX3QaqPmpopUtX89x6D99S39U7
a1UKN2Ic78CAc5R01I80y6II85yBylwIlT5lRPE/SVYbtBFsidhQQ8/Hx/Fcz3qI
7ceK6CiAoQy7ntBvE+uBbQ2630Z3m6kOmInFJD/DnQnf1n6twmBxqwsFTjITbHw=
=pCl7
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Is there a library issue between 9.0 and 9.1 -ThreadRuneLocale ?

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 5/18/13 11:49 AM, Michael Gass wrote:
 Cannot update my ports.  Run portsnap followed by portmaster -a and
 various ports will not update. Keep getting error msg of Undefined
 symbol: _ThreadRuneLocale This happens for instance in updating
 to png-1.5.15 or to freetype2.
 
 Are there library issues between 9.0 and 9.1? I am running
 9.0-stable on an i386
 
 Last time I updated was in March and that went well.
 
 Do I need to uninstall all my ports and start over? Do I need to
 move up to 9.1?

You will have to move up to 9.1, running binaries compiled for newer
FreeBSD versions is not supported.

You don't have to start over though, running binaries compiled for
older FreeBSD versions is supported.

Cheers,

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRmGwCAAoJEG80Jeu8UPuzO+cH/R4ru4Br7zq0kMvIs7G3IJEZ
uKYUG1gmDrEFcHD67huPTGcS9YX56U5eb3EXuMiT/913WGgVVrcjxU/ui96Y3hEs
zJy5BIha9MEYzqv52fqWQtyCusJFcW+0aMHQrd9gDaCJuTmfpQ0ArcZ0yWoPu3UV
cubW0vHODkGBUx2MGPURqMLxow8FAFnUvCinymWhHTfPwnh7WwocqA5cR6/H40hg
RbOJoCDxvw2f/s9eeAKW1ebjpxQ1JfvEPNvq9Ss+pZvZk23aCUxEPfT6Mdlm27EY
VZJFNY2yTXCT+ZTMO00ytOjjd51hKo7C2/FJ41dtHICN4VQFbZD1pTnoDR1kCYs=
=uUhB
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 4/1/13 12:04 AM, Ryan McIntosh wrote:
 This has been brought up before for a different board, none
 specifically mentioned this one nor the if_em driver (it was if_igb
 before on a X8DTU-6+ board).
 
 References: 
 http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html

 
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113
 
 Panic image from H8DCl-iF: 
 http://nitemail.net/img/crash91-h8dcl-if.png
 
 Original image from X8DTU-6+: 
 http://www.grosbein.net/img/crash-91rc.png
 
 While I'd love to try out some fixes myself however I don't have a
 ton of time with this system in my hands to be developed on. Jack
 (as referenced in the kernel pr) felt that it was too few system
 specific to go further with the issue as per the last response.
 
 I would be more than happy to assist or even lend remote access to
 this machine to figure out just what's causing the problem if
 anyone is up for the task, but I will only have about 3-4 days with
 it. I have confirmed dumping msix on the boot loader will permit
 the system to boot up and function, however horridly slow (6gbps
 drives pushing 8mbyte/sec isnt even usable). Maybe there's a
 grander problem here.. with supermicro? Let me know, I'll happily
 test whatever if it benefits the community.

I tend to agree with John's patch (on Feb 21, 2013 on kern/172113),
will you have a chance to test it?

(My thought is that we should probably just initialize
adapter-rx_mbuf_sz = MCLBYTES; in _attach() right after adapter-dev
assignment?)

Cheers,
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRWTe/AAoJEG80Jeu8UPuzMf8IALPmOclwXEwLHSzVX8BEDbq7
YOgCsyNAa9Yi3aeSjDkH3Hvqi3XZzc5FtIeXODUMoU9+vTtI9KQSh4As3UsIYJG5
rGAS9dyT8hJ/VNVAzDNAPRmOTaeSRyXCughfCd5MCJXMTG/6KtVkJ2z/js9VpP4r
sqA3qD21p9q88wfPJIhCj7hHFRLa5emv5Ir76pnZHrQ7ORerwtHEbTosWBWQdG7+
9gREoMl0VB28Zoh8Ai1+TvB79MsUklB4F/XZ63sM2ccJ0Uk1Egn6shI9VMBqbh75
tkMSsjenxbM6/BgK86cyNS+NA8Nyh9hGrpNfab5qj79usJKFskSxUpP/iszHCJc=
=xUCH
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 4/1/13 12:34 AM, Ryan McIntosh wrote:
 I could try that patch, however that was intended for if_igb.c
 which for my system (and the panic's are almost identical except
 if_em for me) I'd have to apply that fix to if_em.c and I haven't
 looked at the source just yet. If you can give me a patch I'll do
 apply and test it shortly though.

Try this:
http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214r2=239304view=patch

Cheers,
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRWTu4AAoJEG80Jeu8UPuzPnkIAIMgnUYgzXTdEt93aQVpK38v
IKH54G8iU7xR98V5auokFqGAuy3wqnbT4GQGsQCZWl+Lu7lmrbvIVufuB04Zjmyp
YO7gRNHeBVThp53nkDaPBjwLsEeGrFR11zLLq0nHJCDOFf+SgvPROuBEEMIBvzUR
LeHWKZUOcMOHdkADfAm3T1QIZ6F/K5iJdr6OB+r86b+nxV9Z+whEO2Tzk87XodTD
39+9t4EdkM4BgMDBoheS74SWK+vHhsmXbX7PPFXJZ/Zrasp6GMYLk8AAcWDm0IZ4
7s7lmx0xqckzwhaJZzKfO+DWtlaIrE+LIQwQmg5QVeZBDxlDU0orsLGO55zSlAo=
=B1sL
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 4/1/13 5:25 AM, Jeremy Chadwick wrote:
 On Mon, Apr 01, 2013 at 05:45:48AM -0400, Ryan McIntosh wrote:
 I can confirm that works as intended. I appreciate the prompt
 response and it looks like there's a real fix.
 
 For google reference for anyone else searching..
 
 Motherboard: Supermicro H8DCL-iF OS: FreeBSD 9.1-RELEASE
 
 Boot message: panic: m_getzone: m_getjcl: invalid cluster type 
 cpuid = 0 KBD: stack backtrace: #0 0x809208a6 at
 kdb_backtrace+0x66 #1 0x808ea8be at panic+0x1ce #2
 0x804ad5a7 at em_refresh_mbufs+0x207 #3
 0x804adb7f at em_rxeof+0x47f #4 0x804adca4 at
 em_msix_rx+0x24 #5 0x808be8d4 at
 intr_event_execute_handlers+0x104 #6 0x808c0076 at
 ithread_loop+0xa6 #7 0x808bb9ef at fork_exit+0x11f #8
 0x80bc368e at fork_trampoline+0xe
 
 Panic image from H8DCl-iF: 
 http://nitemail.net/img/crash91-h8dcl-if.png
 
 Original image from X8DTU-6+: 
 http://www.grosbein.net/img/crash-91rc.png
 
 As per Xin Li, which seems to work: 
 http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214r2=239304view=patch


 
References:
 http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html

 
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113
 
 
 Thanks again,
 
 Ryan McIntosh e: rmcint...@nitemare.net
 
 
 On Mon, Apr 1, 2013 at 3:48 AM, Xin Li delp...@delphij.net
 wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 On 4/1/13 12:34 AM, Ryan McIntosh wrote:
 I could try that patch, however that was intended for
 if_igb.c which for my system (and the panic's are almost
 identical except if_em for me) I'd have to apply that fix to
 if_em.c and I haven't looked at the source just yet. If you
 can give me a patch I'll do apply and test it shortly
 though.
 
 Try this:
 
 http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214r2=239304view=patch

 
 Jack Vogel has stated it's not a real fix (your words) but rather
 a bandaid, for both igb(4) and em(4).  The commit messages (for
 r238214 and r239304) contain details:
 
 http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev238214

 
http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev239304

Hm why 238214 is related, or did you mean the change between 238214
and 239304?

Yes, this is a bandaid and the right fix should be refactor the code a
little bit to make sure that no interrupt handler is installed before
the driver have done other initializations but I don't have hardware
that can reproduce this issue handy to validate changes like that.

Cheers,

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRWbX6AAoJEG80Jeu8UPuzfR4IAID80wE0vCg+AyunRBLusue3
zBXNVwbAwxUFcJ2HcFRFLXVGj2kNsYnHGEp2KGJbYxX/zYJN6Kvv0nXhDIFM0IvJ
dsyC9f/vAay4EtKn9bSz6DmB57KUuhdy5v+40uGQIcoAaQ3/7My06RYcY2dm2PVM
XzLrEz3K5kEC+0dCRIRFi61yZAAPp4/FkHzrDud1AyQ+M03VnbXszzR7J6QIOYbQ
pN2I7RZfIMQXX9Qc+kqX6fFSCYrI7MzZmZkZPIQguWj/x+TUjk5pt5kyuNbum+YF
mqut0VyKAkwVRnsZMIJUXYEXfVtPorDlKRG4dlJdloF1Hz/xP02NpZoDzaK72GU=
=7Wll
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: rc.d/sysctl fails to parse sysctl.conf

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I have committed this change to 9-STABLE directly, the code gets
refactored in -HEAD and solved differently.  Thanks for your submission!

Cheers,
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRLxC+AAoJEG80Jeu8UPuzY3kH/2MmuE6bqRC2hnznPOTt+w9m
f+ojdHTQvPkx2c6S+ONv/rJuwIuJxH+4Lc6ZrMRpSnZMuq6RuGFuKG1+q+0uwLT4
bYh8YvcA5xGnomkCkCVll/BSlVQFtixsecGlW6HKUXZTc0ivUrkR1EUJP4A6ns3c
9Sg+ENL0swXRIdGWGKzDMoA3k50k4FB7EyxkKy1DIsk/XuUi7TpnU9abNo2uL0UW
jBfOBlGK7F4QothboBbm1RYTrGVfZKkqW6E3G/KMA795HWhmlObZh0lF6DBMR0mP
HoiHwbyuRC6tC/Y19kUiTMXvCtnsN5CADhQmn6ymvkdhrzQN1ZMbFN6UrPvAW2U=
=s0jR
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Mounting from zfs... failed with error 2, again

[Xin LI]

2 = ENOENT.  Were you booting from zfs:zdell/ROOT?

On Tue, Feb 19, 2013 at 2:15 PM, Zhihao Yuan lich...@gmail.com wrote:
 There is no problem with everything that I can think of, and I tried every
 thread in the mailing list/forum, and the only problem is, nothing works.

 http://twipic.com/c56lmz

 (taken from the shell on the install CD)

 --
 Zhihao Yuan, ID lichray
 The best way to predict the future is to invent it.
 ___
 4BSD -- http://4bsd.biz/
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org



--
Xin LI delp...@delphij.net https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Mounting from zfs... failed with error 2, again

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/19/13 16:57, Zhihao Yuan wrote:
 Yes, the real root which is mounted to /

Show the error message from root mount (plus what shows up after
?enter).  It's pretty likely that you have a bad zpool.cache or bad
fstab configuration.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRJC4gAAoJEG80Jeu8UPuz13MH/1zl/R4/JM6ofdomWjHNCAJK
lsvQcAsOVkiegSYlQprwqLNmymoNY6HJ2G4f2fYYGoyDwmYORJoxz8bkqpEveC39
CaSI9r2+cJbCu2YkMpCYP2N8LYz2f5puDe4mN+EyUGfWH1OZTVEsPuECgaZtj2D9
jkLVowDyS8qC05xWpYGJ4CQnteRzgr8YwYV4wtbgP5UDtJWoeFEqgHtvi4WQdm5W
SFIUDyTOOr5ziDd5roWuHQbl7CPCAEwV3T9usDNj447jic6+xSCMMfCFKzSyXLOJ
O0leZUXO8U3RzjelAHksb960DU7UBrpI9qhy373W3wJEJNkss3V3iMXlttTz0c0=
=y84X
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Mounting from zfs... failed with error 2, again

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2/19/13 6:21 PM, Zhihao Yuan wrote:
 On Feb 19, 2013 9:00 PM, Xin Li delp...@delphij.net wrote:
 Show the error message from root mount (plus what shows up after 
 ?enter).
 
 http://twitpic.com/c57t9b
 
 After ?enter, I see a list of gptids and names; nothing mentions
 'zfs'.

Did you loaded zfs.ko?

 It's pretty likely that you have a bad zpool.cache or bad fstab
 configuration.
 
 I suppose I don't need a fstab, since I used the non-legacy plan,
 as shown in the RootOnZFS/9.0-RELEASE wiki page.
 
 The (/mnt)/boot/zfs/zpool.cache is copied from /tmp/zpool.cache,
 which was created by -o cachefile.

This is not correct unless it's the first time and you have never
imported the pool again.  Some recent changes to ZFS mounting code may
have relieved the requirement of keeping zpool.cache but I have not
tested it myself.

Regenerate the zpool.cache with:

zpool set cachefile=/mnt/boot/zfs/zpool.cache zdell

Then sync; sleep 5; sync; then reboot.
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRJEe6AAoJEG80Jeu8UPuziI0H+gLLrpAtVyzZZglkBbuntFOJ
CRJJiqpYo1ogTSjIVRAQJKDqg95QTXJfmlCep31LZWGohcENuQLNzvkXyKlC5qVX
h0ROkvqXJ2yli8poH9bydXHfdvF9YuCUHxWnMDTEcRMk4ztLoCvi4DgGArPrdKSV
3cnIJaLXGcAKWqaD39DN+L61I/Db4C9hGANj9FYd4vkTQ9apmfunLEJDSkXOiFNA
hr3ttVaG/2ZdC3EgaNSKBZGNAE3IzcU1s2OpO2bNIemgT3qRkR9ZpPm8NmFujy+q
OSjzIy+MjQR0mIRSdXlZsjAZv39mkdzoflTNp1QDxJHj1h372mRFAFiVnxrj/ZI=
=Bv01
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: some issues with /usr/sbin/service

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2/16/13 10:24 AM, Chris Rees wrote:
 On 16 February 2013 18:08, Gary Palmer gpal...@freebsd.org
 wrote:
 On Sat, Feb 16, 2013 at 05:38:56PM +, Chris Rees wrote:
 On 16 February 2013 17:05, Paul Mather
 p...@gromit.dlib.vt.edu wrote:
 On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote:
 
 On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov
 wrote:
 16.02.2013 01:32, Jeremy Chadwick ??:
 
 Follow up -- I read Alfred's most recent mail.  Lo and
 behold, I find this in /var/log/messages (but such did
 not come to my terminal):
 
 Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING:
 $svnserve_enable is not set properly - see rc.conf(5). 
 Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING:
 $smartd_enable is not set properly - see rc.conf(5). 
 Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING:
 $rsyncd_enable is not set properly - see rc.conf(5). 
 Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING:
 $htcacheclean_enable is not set properly - see
 rc.conf(5). Feb 15 13:26:20 icarus jdc:
 /usr/sbin/service: WARNING: $fetchmail_enable is not
 set properly - see rc.conf(5).
 
 Cute.  Agreed -- this is unacceptable on two levels (as
 I see it):
 
 1) These messages should be going to stdout or stderr
 in some way, so honestly logger(8) should be called
 with the -s flag (IMO).
 
 Fully agreed here.
 
 It turns out logger -s has no effect, just like how the
 echo 12 statements in warn() and err() have no effect
 either (these should be outputting the warnings in question
 to stderr) -- see rc.subr's source for what I'm referring
 to.
 
 Gary and I have been discussing this off-list and the
 reason has been found: service(8) has this code in it:
 
 checkyesno $rcvar 2/dev/null  echo $file
 
 This explains why there's no warn() or err() output on the
 terminal -- it's being redirected to /dev/null prior.
 
 I do not know who maintains the rc(8) and rc.subr(8)
 framework, but they've got their work cut out for them.
 
 (Note: the echo statements in warn() and err() could be
 replaced with logger -s as I said; this would allow the
 echo 12 to be removed)
 
 2) These messages should not be displayed at all (i.e.
 lack of an xxx_enable variable should imply
 xxx_enable=no).
 
 I see this message as one more level of supervision.
 
 If undefined at /etc/make.conf the value of xxx_enable is
 no from the system's POV (i.e. the service is not
 strarted). From the admininstrators's POV the port was
 installed BUT is not used. It's up to admininstrator
 whether it's OK or not -- just let him remind.
 
 I believe the point you're trying to make is that the
 warning in question should 'act as a reminder to the
 administrator that they need to set xxx_enable=yes in
 rc.conf'.
 
 If not: please explain if you could what you mean, because
 I don't understand.
 
 If so: I strongly disagree with this method of approach, as
 what you've proposed is a borderline straw man argument.
 
 Reminding the admin to set xxx_enable is presently done
 inside most ports' pkg-message.  IMO, this should really be
 done inside bsd.port.mk when USE_RC_SUBR is used, emitting
 a message during install that says something like:
 
 To enable the xxx service, please add the following to
 /etc/rc.conf: xxx_enable=yes
 
 Of course, I don't know if this would work for packages.
 
 The current message for missing xxx_enable in rc.conf is
 this:
 
 WARNING: $xxx_enable is not set properly - see rc.conf(5).
 
 The message is entirely misleading for this specific
 situation; it isn't reminding an administrator -- if
 anything it's confusing them (thread is case in point).  If
 we're going to cater to ignorance, then the message should
 reflect the situation.
 
 Thus IMO, this is what ***should*** happen:
 
 Definition in rc.confBehaviour/result 
 ---
 --- 
 myprog_enable=yes  emit no warnings, service should
 run myprog_enable=no   emit no warnings, service
 should not run myprog_enable=abc123   emit a warning,
 service should not run no definition  emit no
 warnings, service should not run
 
 
 I think case 4 (no definition) is a case where a warning
 should be emitted because it is arguably not immediately
 apparent what will actually happen if no definition is
 present.  In the case of services in the base OS it is
 well-defined: every service should have an explicit default
 in /etc/defaults/rc.conf that you can easily consult to know
 definitively what will happen with that service.  (If it
 doesn't, that is a bug, IMHO.)
 
 For ports, the case is not so clear.  There is a general
 trend for the port rc.d script to default its respective
 xxx_enable explicitly to NO.  But it is not a universal
 rule that no definition = default to NO.  The
 net/avahi-app port, for example, doesn't default to NO if
 xxx_enable is not set: it defaults to whatever the
 gnome_enable setting is defined to be.
 
 

Re: patch which implements ZFS LZ4 compression

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/08/13 14:29, Dan Langille wrote:
 Here is a patch against FreeBSD 9.1 STABLE which implements ZFS LZ4
 compression.
 
 https://plus.google.com/106386350930626759085/posts/PLbkNfndPiM
 
 short link: http://bpaste.net/show/76095

Please DO NOT use this patch!  It will ruin your data silently.

As I already posted on Ivan's Google+ post, I'm doing final universe
builds to make sure that there is no regression and will merge my
changes to -HEAD later today.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRFYHJAAoJEG80Jeu8UPuz3e8IALAcbjZo063casLry/zyBjLe
jbat7AmmWTQ5ndBtfx5PxAV1of6ePCiQQS/RQVd001c5M32hzfoqb7524th3giyx
q4RRuVPIc6YswJOe3Gz/vRyHdBRfJlownxZy1Glv480qK9dzeUtd2ziZhoi+FZ1X
PfigRwg/9OtyDbmUhEqDvq2qeyAakuiE6yL9NVlGGKSe8GysYWPQFisVfDWn3WYH
a+Rt+O3P/QHK0mTWBYTs/r92AU9J0Sv4plhNNQZSZWpAlQLuWRhMit/2e2W/0TPx
XnXXuzdr01/cE/+ou3MMnq+uvO1FiqKBUXN6/oJzZnl/VkvvL795iT/C5KGq+2s=
=mVAM
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: patch which implements ZFS LZ4 compression

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

For those who are inpatient, here is an overlay for LZ4 for 9-STABLE.

http://people.freebsd.org/~delphij/misc/lz4.tar.xz

Overwrite /usr/src and recompile ZFS module.

Note: before using this in any serious environment, please be sure to
test if there is any data corruption by comparing the files copied to
a LZ4 dataset after export and re-import the pool, or reboot.  I have
only tested the code on amd64 and would like to see if it works on big
endian environment, etc.

Cheers,
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRFfwgAAoJEG80Jeu8UPuzjKgH/0i+PShTX3kyLvEjORHjmEp+
T0YxLiTEssmpz8IhUwbjN+FLoQZlV+DCL5MUBzIsA5kM3p1aUgffrNnO1RvZmbhT
y+pnKxEDay30QhMs48jWLO6oyHA07bb8q5xyut+noK6X1y4epqwrWid44nqlzPZQ
w6XKhCuz8DXm4TIKQpeB4ncFNfUv+rlImmn5XToC6DaKn/2XtYVLVE73pjP3qANL
mxZA/RqJNQy1cBp0gougDcw6AoNMBkjfxaNe0V073nEffyXgI/1BeCWsxKmWFNWb
VNGGjxLzmpP4MGz2SAABfaUvRb306pHJtfYWtoeIxpZLM0A9h9wnDGUWo9w+lLo=
=eVP8
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Seeking 6.4 make source for ports

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/20/12 11:56, Michael R. Wayne wrote:
 On Wed, Jun 20, 2012 at 10:26:02AM +0200, Ronald Klop wrote:
 On Wed, 20 Jun 2012 06:57:59 +0200, Michael R. Wayne 
 freebs...@wayne47.com wrote:
 
 Google is littered with messages from people who have 6.3
 systems and can no longer upgrade ports. It appears that a
 recent change requires the version of make from 6.4.
 
 While it would be ideal if freebsd.org would build a 6.4 make
 on a 6.3 system and pseudo-officially support it, a reasonable
 alternative would be a simple way to download just the files
 required to build the 6.4 version of make on 6.3.
 
 Any possibility to get this tossed on a site someplace?
 
 Do you have a problem yourself or did you just found some
 messages on google?
 
 Have the problem myself. There are ports with security
 vulnerabilities and the recent change broke make for ports. I went
 to Google and found lots of other people with the same problem. The
 suggested fix is to use the make from 6.4. Hence my request.
 
 I presume you are running 6.3 yourself. Why don't you upgrade the
 OS to 6.4 or 7+, but you do upgrade the ports on an unsupported
 OS?
 
 Upgrading a port can be done without rebooting the machine.
 Upgrading the O/S is a MUCH more major undertaking and is almost
 never a clean process. Plus the time investment multiplied by
 many machines is huge (and dreaded).

Well, not upgrading the OS means you could leave serious security
issues unpatched, which may be Ok for certain trusted environment
(e.g. where absolutely no untrusted local user will ever present) but
not a wise idea for production system facing the Internet.  The good,
old time, when everyone wants to be a good neighbor with you, has gone
forever.

 So, any chance of getting a 6.4 make compiled for 6.3?

Of course, it would compile (you can grab the source from CVS, CVSup,
or SVN and compile it with:

cd src/usr.bin/make
make cleandir
make cleandir   # yes, do it twice, this is not a typo
make obj
make depend
make
sudo make install # or run this command as root without sudo
)

Please note that FreeBSD 6.x was EoL'ed 2 years ago and we (secteam@)
no longer support it anymore, which means you don't get security
advisories, etc. for the base system.  You are advised to upgrade to a
more recent and supported FreeBSD release as listed at:

http://security.freebsd.org/#sup

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBCAAGBQJP4iSBAAoJEG80Jeu8UPuzAM0IAJOMi7zT930RSGUIETOZZQnY
63RKEmwydRV4Tx3urgrEDJM9/ebBECU5aQpejy+ztV1Fpgm8x9TrR4sIt2fGjPj+
JKdkrKUZX2Vc/wrnc7qtnTJOfWjOm2W0JH9NuKQrjFFZQSkptIr7Tj0iOOTG0Cb3
Z/pvVSTeVSDfTbS2kZprIbNHZnERUyJfQgN/o6NjduNOXnb9Nhgtd6PE/SpNrdfe
ZIJt4+FkAmDf4QtnUMnqOKCSQg/FUbvBnjHfv645Jpud/cPvQeEZvQMVB2qG76Ex
f2dyyb2wSZtbRL4Oe2YkTzB+dKlHbxvJfbl1fagN3KYVszzW6jMmFXbJsQQjyaU=
=rukn
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Heavy fs corruption with 9.0-RELEASE

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/05/12 14:12, Arnaud Lacombe wrote:
 Hi,
 
 I've been running a couple of system with 9.0-RELEASE since it is
 out. All the system were installed through the standard
 installation procedure. After unclean reboot, either crash or
 power-failure, I get a huge amount of really bad filesystem
 corruption (read: silent, fs-wide, corruptions). This happens
 with either i386 or amd64 build. Systems involved use compact flash
 as their system permanent storage medium.
[...]
 I do not see this behavior when running 9.0-RELEASE on top of a 
 7.4-RELEASE userland (including FS). I've seen this behavior on 
 various CF, so a single bad card is unlikely to be the culprit.

FWIW FS is part of kernel.  So technically you're running 9.0-RELEASE
UFS with 7.4-RELEASE userland.

 Here are the currently mounted filesystem on the machine, as well
 as mount options:
 
 # mount /dev/ada0p2 on / (ufs, local, journaled soft-updates) devfs
 on /dev (devfs, local, multilabel)
 
 Any hints appreciated.

My first step would be take out the journalling soft-updates to see if
things improves.  Could you test if this happens using brand new
9.0-RELEASE, but with journaled soft-updates disabled?

(Hint: tunefs -j disable /; tunefs -n enable /; reboot in single user
mode).

Note that since you say 7.4-RELEASE userland wouldn't have similar
issue, it might indicate a bug with the new journalled soft-updates's
fsck implementation.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJPVTyCAAoJEG80Jeu8UPuzTsgIALvLdbzoNrmE/xUqDEJwGtC8
zcfGl7tEVLU6BbE3i2ww2tUcMJmOMZwrAg1gZmFyyDhVQwEEQQ2zSTa1Uy3oiNRA
ts1X31VicEXIMam1Mt5K2G3lMbFES6TvyDrNOit6C2FeUrixHZ2C1JZmA7yzGlsg
7ZGco+3clwSy2yfKTf0ExjIibkC0Cgz60BgjpQKowpKjUCD5AzB/2EqmZk1pFz6S
/NYOlF+YG/Y72V3GW1K5DTDFao5znzkulhc5Q/RUoD08o6hmdiaqiRHHmqjIP6Rt
Gb8Dfggnm8XUBs+AzgUmssCSCvHMHYt9SEel2sB5gSVKzd5rIAXwLxaeKBco1Ws=
=Hi9P
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: minor regression after patching

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/26/11 07:06, Volodymyr Kostyrko wrote:
 Hi all.
 
 Am I the only one seeing this on RELENG_9?
 
 === libexec/ftpd (all) clang -O2 -pipe  -DSETPROCTITLE -DLOGIN_CAP
 -DVIRTUAL_HOSTING -I/usr/src/libexec/ftpd -Dmain=ls_main 
 -I/usr/src/libexec/ftpd/../../bin/ls -DINET6 -DUSE_PAM -std=gnu99 
 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
 -Wno-uninitialized -Wno-pointer-sign  -o ftpd ftpd.o ftpcmd.o
 logwtmp.o popen.o ls.o cmp.o print.o util.o -lutil -lcrypt -lopie
 -lmd -lm -lpam clang: warning: argument unused during compilation:
 '-std=gnu99' ftpd.o: In function `pass': 
 /usr/src/libexec/ftpd/ftpd.c:(.text+0x2676): undefined reference
 to `__FreeBSD_libc_enter_restricted_mode' clang: error: linker
 command failed with exit code 1 (use -v to see invocation) ***
 Error code 1

Ah sorry, you will need to do a 'make install' in /usr/src/include
before rebuilding ftpd.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk76OEsACgkQOfuToMruuMASqACfdPe9HtXnYemRZgyd0tYDMiWX
kwcAnA/ggg3Ed7yg1+PCXdvooR/TWLfL
=vZeD
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Low nfs write throughput

[Xin LI]

Hi,

 I don't know if it will help with your performance, but I have some patches
 to allow the NFS server to cluster writes.  You can try
 www.freebsd.org/~jhb/patches/nfs_server_cluster.patch.  I've tested it on 8,
 but it should probably apply fine to 9.

I think 9 would need some changes, I just made them with minimal
compile testing, though.

Cheers,
-- 
Xin LI delp...@delphij.net https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
Index: sys/fs/nfsserver/nfs_nfsdport.c
===
--- sys/fs/nfsserver/nfs_nfsdport.c	(revision 227689)
+++ sys/fs/nfsserver/nfs_nfsdport.c	(working copy)
@@ -90,20 +90,78 @@ SYSCTL_INT(_vfs_nfsd, OID_AUTO, issue_delegations,
 SYSCTL_INT(_vfs_nfsd, OID_AUTO, enable_locallocks, CTLFLAG_RW,
 nfsrv_dolocallocks, 0, Enable nfsd to acquire local locks on files);
 
-#define	NUM_HEURISTIC		1017
+#define	MAX_REORDERED_RPC	16
+#define	NUM_HEURISTIC		1031
 #define	NHUSE_INIT		64
 #define	NHUSE_INC		16
 #define	NHUSE_MAX		2048
 
 static struct nfsheur {
 	struct vnode *nh_vp;	/* vp to match (unreferenced pointer) */
-	off_t nh_nextr;		/* next offset for sequential detection */
+	off_t nh_nextoff;	/* next offset for sequential detection */
 	int nh_use;		/* use count for selection */
 	int nh_seqcount;	/* heuristic */
 } nfsheur[NUM_HEURISTIC];
 
 
 /*
+ * Heuristic to detect sequential operation.
+ */
+static struct nfsheur *
+nfsrv_sequential_heuristic(struct uio *uio, struct vnode *vp)
+{
+	struct nfsheur *nh;
+	int hi, try;
+
+	/* Locate best candidate. */
+	try = 32;
+	hi = ((int)(vm_offset_t)vp / sizeof(struct vnode)) % NUM_HEURISTIC;
+	nh = nfsheur[hi];
+	while (try--) {
+		if (nfsheur[hi].nh_vp == vp) {
+			nh = nfsheur[hi];
+			break;
+		}
+		if (nfsheur[hi].nh_use  0)
+			--nfsheur[hi].nh_use;
+		hi = (hi + 1) % NUM_HEURISTIC;
+		if (nfsheur[hi].nh_use  nh-nh_use)
+			nh = nfsheur[hi];
+	}
+
+	/* Initialize hint if this is a new file. */
+	if (nh-nh_vp != vp) {
+		nh-nh_vp = vp;
+		nh-nh_nextoff = uio-uio_offset;
+		nh-nh_use = NHUSE_INIT;
+		if (uio-uio_offset == 0)
+			nh-nh_seqcount = 4;
+		else
+			nh-nh_seqcount = 1;
+	}
+
+	/* Calculate heuristic. */
+	if ((uio-uio_offset == 0  nh-nh_seqcount  0) ||
+	uio-uio_offset == nh-nh_nextoff) {
+		/* See comments in vfs_vnops.c:sequential_heuristic(). */
+		nh-nh_seqcount += howmany(uio-uio_resid, 16384);
+		if (nh-nh_seqcount  IO_SEQMAX)
+			nh-nh_seqcount = IO_SEQMAX;
+	} else if (qabs(uio-uio_offset - nh-nh_nextoff) = MAX_REORDERED_RPC *
+	imax(vp-v_mount-mnt_stat.f_iosize, uio-uio_resid)) {
+		/* Probably a reordered RPC, leave seqcount alone. */
+	} else if (nh-nh_seqcount  1) {
+		nh-nh_seqcount /= 2;
+	} else {
+		nh-nh_seqcount = 0;
+	}
+	nh-nh_use += NHUSE_INC;
+	if (nh-nh_use  NHUSE_MAX)
+		nh-nh_use = NHUSE_MAX;
+	return (nh);
+}
+
+/*
  * Get attributes into nfsvattr structure.
  */
 int
@@ -567,58 +625,12 @@ nfsvno_read(struct vnode *vp, off_t off, int cnt,
 	int i;
 	struct iovec *iv;
 	struct iovec *iv2;
-	int error = 0, len, left, siz, tlen, ioflag = 0, hi, try = 32;
+	int error = 0, len, left, siz, tlen, ioflag = 0;
 	struct mbuf *m2 = NULL, *m3;
 	struct uio io, *uiop = io;
 	struct nfsheur *nh;
 
-	/*
-	 * Calculate seqcount for heuristic
-	 */
-	/*
-	 * Locate best candidate
-	 */
-
-	hi = ((int)(vm_offset_t)vp / sizeof(struct vnode)) % NUM_HEURISTIC;
-	nh = nfsheur[hi];
-
-	while (try--) {
-		if (nfsheur[hi].nh_vp == vp) {
-			nh = nfsheur[hi];
-			break;
-		}
-		if (nfsheur[hi].nh_use  0)
-			--nfsheur[hi].nh_use;
-		hi = (hi + 1) % NUM_HEURISTIC;
-		if (nfsheur[hi].nh_use  nh-nh_use)
-			nh = nfsheur[hi];
-	}
-
-	if (nh-nh_vp != vp) {
-		nh-nh_vp = vp;
-		nh-nh_nextr = off;
-		nh-nh_use = NHUSE_INIT;
-		if (off == 0)
-			nh-nh_seqcount = 4;
-		else
-			nh-nh_seqcount = 1;
-	}
-
-	/*
-	 * Calculate heuristic
-	 */
-
-	if ((off == 0  nh-nh_seqcount  0) || off == nh-nh_nextr) {
-		if (++nh-nh_seqcount  IO_SEQMAX)
-			nh-nh_seqcount = IO_SEQMAX;
-	} else if (nh-nh_seqcount  1) {
-		nh-nh_seqcount = 1;
-	} else {
-		nh-nh_seqcount = 0;
-	}
-	nh-nh_use += NHUSE_INC;
-	if (nh-nh_use  NHUSE_MAX)
-		nh-nh_use = NHUSE_MAX;
+	nh = nfsrv_sequential_heuristic(uiop, vp);
 	ioflag |= nh-nh_seqcount  IO_SEQSHIFT;
 
 	len = left = NFSM_RNDUP(cnt);
@@ -672,6 +684,7 @@ nfsvno_read(struct vnode *vp, off_t off, int cnt,
 		*mpp = NULL;
 		goto out;
 	}
+	nh-nh_nextoff = uiop-uio_offset;
 	tlen = len - uiop-uio_resid;
 	cnt = cnt  tlen ? cnt : tlen;
 	tlen = NFSM_RNDUP(cnt);
@@ -700,6 +713,7 @@ nfsvno_write(struct vnode *vp, off_t off, int retl
 	struct iovec *iv;
 	int ioflags, error;
 	struct uio io, *uiop = io;
+	struct nfsheur *nh;
 
 	MALLOC(ivp, struct iovec *, cnt * sizeof (struct iovec), M_TEMP,
 	M_WAITOK);
@@ -733,7 +747,11 @@ nfsvno_write(struct vnode *vp, off_t off, int retl
 	uiop-uio_segflg = UIO_SYSSPACE;
 	NFSUIOPROC(uiop, p);
 	uiop-uio_offset = off;
+	nh = nfsrv_sequential_heuristic(uiop, vp);
+	ioflags |= nh

Re: smartctl / mpt on 9.0-RC1

[Xin LI]

Hi,

On Wed, Nov 2, 2011 at 4:49 PM, Frank Razenberg fr...@zzattack.org wrote:
   Loaded symbols for /libexec/ld-elf.so.1
   #0  0x in ?? ()
   (gdb) bt
   #0  0x in ?? ()
   #1  0x in ?? ()

Your stack is mangled.  Can you recompile and install the port with
'WITH_DEBUG=' and try if you can regenerate the core and gdb to see if
there is any change?

Cheers,
-- 
Xin LI delp...@delphij.net https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: FreeBSD on IBM X3550 M3

[Xin LI]

On Mon, Oct 17, 2011 at 2:45 PM, Gót András and...@antiszoc.hu wrote:
 Dear All,

 I'd like to install FreeBSD onto az IBM X3550 M3 which looks like UEFI only.
 Is it possible to have FreeBSD amd64 get working on it or should I forget
 it? :(

Will it do traditional MBR boot by any chance?  As a last resort
workaround, it might be possible to take its hard drive to another
system and install grub which will boot FreeBSD but supports EFI.

(We should implement EFI on amd64 by the way).

Cheers,
-- 
Xin LI delp...@delphij.net https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: NFSD hang

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/25/11 23:14, Kirill Yelizarov wrote:
 Good Day! I'v got a problem with nfs share on zfs volume.
 Everything worked fine for a few month and now it hang. This share
 stores logs from 9 servers at night, about 1-2Gb from each server.
 ZFS is filled to 26% and it is v28
 
 last pid: 46573;  load averages: 195.82, 199.86, 200.12
 up 108+21:56:50 10:05:06 432 processes: 208 running, 224 sleeping 
 CPU:  0.0% user,  0.0% nice,  100% system,  0.0% interrupt,  0.0%
 idle Mem: 280M Active, 1469M Inact, 9584M Wired, 161M Cache, 1232M
 Buf, 311M Free Swap: 16G Total, 16G Free
 
 PID USERNAME  THR PRI NICE   SIZERES STATE   C   TIME
 WCPU COMMAND 1666 root  256  760  5788K  5120K RUN
 14 476.8H 1508.64% nfsd
 
 # zpool list NAME   SIZE  ALLOC   FREECAP  DEDUP  HEALTH
 ALTROOT data  3.62T   954G  2.69T25%  1.00x  ONLINE  -
 
 # zfs list NAME   USED  AVAIL  REFER  MOUNTPOINT data   954G  2.64T
 954G  /data
 
 # zfs mount data/data
 
 What should i look for to resolve it?

For starters maybe:

procstat -kk 1666

By the way what exact svn revision of FreeBSD are you running (and
what branch?)

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOgBzOAAoJEATO+BI/yjfBgJYIAIawKFqt2bD0o7L4JZxLS4Lu
pOfe9OQGWJT+GIFFTBjEQq8CsNOEN4PMjGifj318ZbqPrpNQUxsy5j01SZJCtUzS
WLXiBUMah6zkiquqE0WJEop88FC7CK4zop/nt64dNWbrF0MOM8uVVcMLyRNe7lK7
QhPKAhDa21vK1VxRDPWEucvJuSaUo84XHIAQbKRbzQTMSOI6Bjs/im2q1vYqM8oA
Ixh+r9SocJfgky0cU5/yFteseLTVGoUZcak7ygVQ4bHeEPvOGZVrWHD1UiKHUCSF
XKrFjtDzZmN7XMQLoGfiY9wyv/PnOTsgJKamaMpuZlFkysqxgO6Td7QxbB86/h0=
=k1bU
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: CARP up at boot

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/24/11 02:02, Daniel Kalchev wrote:
 I am trying to use a CARP/HAST setup for redundancy and reply on
 devd for the carp up/down events to trigger role switch for the
 nodes.

Is this something at least at, or newer than 8.2-RELEASE?  I think
it's actually important for the devd script to make sure (wait, then
check) that the state is stabilized before doing any action for use
with HAST by the way.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOVTViAAoJEATO+BI/yjfB4ekIANBDTmvCgh+I60ZSXmf0ut+/
OPcZfgKwGrp66QQQdp9t6uePRnmYDYcqsjvGj2FeihB33sKgIMz+Jrw2cgoTlPDs
VClE8kDkrxt3CH6B99SOnEY4oNI7Hepq+83PkQ5JDAqnqYCUq1ciWVbRLk8xXGZP
tnlo6fGRc9grZWbSFPE+zbqPw74q3yQ1H9kjU87pu61xR5Bmt+5CIRy9yRHXTmrg
O8fOIAlRoyqsTJhsV4acffD67llXlHeTv1wKFnvuuZ84ZIqMNmbuurlMYXBSrfxv
QmwJcSkLTFOqFUzQ7ZJTZi8R6+vIYaAAIrNRCW8hxoL6lrebs09SJ5VZIt5h6go=
=JqLT
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: WD Advanced Format: do I need to do something special?

[Xin LI]

Hi,

On Thu, Aug 18, 2011 at 1:47 AM, Yuri y...@rawbw.com wrote:
 WD has sectors of the size 4kB in their latest hard drives, which is
 different from the traditional 512B.
 http://www.wdc.com/advformat
 http://wdc.custhelp.com/app/answers/detail/a_id/5655

 These articles assert that something special should be done in OS to enable
 high performance of such drives. For ex. WD recommends to install some
 latest drivers of particular version.
 But what about FreeBSD? Should it be configured in some special way too for
 these drive to perform well?
 Is it aware of 4kB sector size?

The FreeBSD driver detects 4k drives.

At this time as far as I know all AF drives on market advertises
512-bytes sector rather than 4k (mostly for compatibility with BIOS,
etc).  If they advertise 4k sector natively, you don't have to do
anything special but currently you need to make sure:

 - FS Partitions starts at a 4k boundary;
 - FS is aware of 4k sector, e.g. through gnop -S 4k for ZFS, which
will remember this so you don't have to do that at later time.  For
UFS you may want to specify larger fragment size and block size
(4k/32k for example).

Some newly developed application like FreeNAS already detect this and
make adjustment for you by default.  We need to check and make sure
that our base system tools, especially installer, would do that
though.

Cheers,
-- 
Xin LI delp...@delphij.net https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: How to use unrecognized COM port card?

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/15/11 23:21, Yuri wrote:
 I have dual COM port pci card: none7@pci0:8:1:0:   class=0x070002
 card=0x32534348 chip=0x32534348 rev=0x10 hdr=0x00 class  = simple
 comms subclass   = UART bar   [10] = type I/O Port, range 32, base
 0xe880, size  8, enabled bar   [14] = type I/O Port, range 32, base
 0xe800, size  8, enabled
 
 Manufacturer 0x4348 isn't recognized by http://www.pcidatabase.com.
 It was purchased from China through ebay.
 
 How to make it to work in 8.2-STABLE?

A wild guess...  (You gotta to provide more details rather than just PCI
IDs).

My guess is that it's using these chips:

http://www.winchiphead.com/product/ch365detail.htm
http://www.winchiphead.com/product/ch353detail.htm

It didn't talked about possible cards' configuration so I used BAR0,
which could be 0x14, 0x18, etc.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOSiC9AAoJEATO+BI/yjfB5oAH/R0yt8Zx3HDVOXA5jUOXzlWl
A+XCmbaau4MNhOtiyVJ8sWERE1CukgQeIE7DWze1rJ6YU7bTXKAgoRbqVJsfiAbH
CEhLx+Y2T7HLow9ZojCGrqk6ydrGxheWIyf2AM7nTORZQdEUceEWGLE4GMXJghTp
Y4udsGfSRqa+1O7tTOpechDi5jtG/cW+dDFeyZqVo0AjfS78D10wEqoiudloIkBd
IAEyy7JGCU/R6AM+DhHHm0dIT68MkHxULOpTLy0GxxzJecWruknqd+h+V36Q3X+h
brg2isOawCGLhWgzCDXVZXwJWIXA28RaRmDPeZRNv5TKUESmZEenR8lEpH7ji+s=
=KUoE
-END PGP SIGNATURE-
Index: sys/dev/uart/uart_bus_pci.c
===
--- sys/dev/uart/uart_bus_pci.c (revision 224900)
+++ sys/dev/uart/uart_bus_pci.c (working copy)
@@ -111,6 +111,7 @@
 { 0x1415, 0x950b, 0x, 0, Oxford Semiconductor OXCB950 Cardbus 16950 UART,
0x10, 16384000 },
 { 0x151f, 0x, 0x, 0, TOPIC Semiconductor TP560 56k modem, 0x10 },
+{ 0x4348, 0x3253, 0x, 0, WinChipHead Dual Port RS-232, 0x10 },
 { 0x9710, 0x9820, 0x1000, 1, NetMos NM9820 Serial Port, 0x10 },
 { 0x9710, 0x9835, 0x1000, 1, NetMos NM9835 Serial Port, 0x10 },
 { 0x9710, 0x9865, 0xa000, 0x1000, NetMos NM9865 Serial Port, 0x10 },
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: How to use unrecognized COM port card?

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/16/11 12:53, Yuri wrote:
 On 08/16/2011 08:57, John Baldwin wrote:
 For multiport devices you will want to add an entry to 
 sys/dev/puc/pucdata.c and use the puc driver instead of patching
 uart directly.  Perhaps this:
 
 John,
 
 I did what you suggested: puc0: WinChipHead Dual Port RS-232 port
 0xe880-0xe887,0xe800-0xe807 irq 17 at device 1.0 on pci8
 
 But it doesn't show up as a serial device and tty.

I found a datasheet:

http://wch-ic.com/download/down.asp?id=116 (English)

and

http://winchiphead.com/download/CH352/CH352DS1.PDF (Chinese)

And I think John's patch is right, I've added a new PCI ID for it
though, found from the datasheet.  Did you have uart(4) in your kernel
(remove my old patch)?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOStUOAAoJEATO+BI/yjfBSw0IANPaoND+0Xa2QtueAxI8Qa42
V86MiUnaZopRb0coiWf8dQNk+nIlayVuFstC9+77zC9NEEu1O7Mp8T4n2Bx2N7WP
jtsevUnLJq6lIyo0jYRTf4x84eYd1VDBduHqsWbI0B7aMArgfNtHvPV0qUD9Emrn
4yR6I3/tmO3sX3+cWcggYC4s3DIm7XidiyT/6lcWilsmy2QkQlw00HoAkoKl0V4m
DBkKHkmOB2oTUYadpBOKCt6HvdI29xWYF+1zN/sE0B3XwTy+Q1pp4Uq5KiBUyJi3
tNF533Z7COh/mog/Z9cpGpLSRJpWQgI2uCY7gAHZRAMT2+7k1AqkdNPWTJPXoCk=
=CcI6
-END PGP SIGNATURE-
Index: sys/dev/puc/pucdata.c
===
--- sys/dev/puc/pucdata.c   (revision 224912)
+++ sys/dev/puc/pucdata.c   (working copy)
@@ -862,6 +862,20 @@ const struct puc_cfg puc_pci_devices[] = {
.config_function = puc_config_syba
},
 
+   {
+   0x4348, 0x3253, 0x4348, 0x3253,
+   WinChipHead Dual Port RS-232,
+   DEFAULT_RCLK,
+   PUC_PORT_2S, 0x10, 4, 0,
+   },
+
+   {
+   0x4348, 0x5053, 0x4348, 0x5053,
+   WinChipHead RS-232 and Printer port,
+   DEFAULT_RCLK,
+   PUC_PORT_1S1P, 0x10, 4, 0,
+   },
+
{   0x, 0x0001, 0x, 0,
Decision Computer Inc, PCCOM 4-port serial,
DEFAULT_RCLK,
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ZFS boot inside on the second partition inside a slice

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/15/11 17:42, Zhihao Yuan wrote:
 Hi,
 
 I configured my disk layout according to
 http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition
 
 But I swapped the order of the freebsd-zfs and freebsd-swap. The 4.0G
 freebsd-swap partition appears first inside the slice.
 After that, I write zfsboot on both ada0s2 and ada0s2b, but the boot0
 gives me a Read error.

Where did your second slice start?  There can be a lot of reasons why it
gives Read error.

I personally recommend using GPT scheme instead of MBR, as you have a
dedicated partition for gptzfsboot, which is much cleaner than this
approach.

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBCAAGBQJN+VUrAAoJEATO+BI/yjfBpksH/2ZswQ+ogdDpYwvhRIjJaqLs
NEl8FtC2Ua+c3F2sNwrLK5a/fn/LL+jPAXndvuQdxOaz41Iqtnt8w1i9Dz5ATkva
T+i0fnRVwXFqjrlRTWK+ODtNtrhI2/7ECAIfOOLNhaiJnPRrJJgvxJ6V5W+/N+l7
Lt4yMp6hGbhO/9Yp2UoaQuUThOTz+dKNZGECd1nLT+ooHbTPhBvjii080hHowNl6
Ef+JBaEng2NbRJPxYWrRwz6R7A44RDXvrKzn5w/TuUa+4fYrS25EZxygzIh3xjFX
2ILP25yabJ+Vw5o8bFCsJ3ExbEfq0PnfROHanRSdTjMDra27dGY9JZKyytE+Ykc=
=D5+X
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Unable to boot Lenovo T520

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/10/11 15:15, Kevin Oberman wrote:
 I am hitting the problem reported some time ago with atkbd and svn
 197392.
 
 It's not clear that this has ben finally resolved, but I am still
 hitting it with -stable on my new T520. I really want to get FreeBSD up
 on it, but I am dead in the water at this time. I guess I'll have to
 build a new kernel with any fix and replace the kernel in the ISO.
 
 Also, I am hoping to use it on an amd64 kernel and I am even less sure
 that any patch will work on that arch.
 
 The original thread was
 http://freebsd.1045724.n5.nabble.com/svn-rev-197392-hangs-during-boot-td3926276.html

The fix was not (yet) merged back to 8-STABLE.  You may use a
8.0-RELEASE kernel to boot the system temporarily and apply this patch:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/atkbdc/atkbd.c.diff?r1=1.63;r2=1.64

(If hunk #1 fails to apply, it's Ok to just ignore it).

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBCAAGBQJN8qWrAAoJEATO+BI/yjfBfNgH/1FBHJzQuRIkG1gIKrhAi2ES
tyvxsaBc/6e/htXSsRSLoXXZ+Ds427Yes6MVVjyMlVPne7QzF9HxRQVTzNv9sTmc
/Jx3pIbnIaugg/tVR+K49s+IU3UxtkSl4f7aKXG2eacWz52S/A8DzXFbe5WX41lE
xn47myobsiGEBv6wnss7Q9gW42CoVfAp753lrBlKUMqGpZR04cPIGMsxjgPGoBpg
QUTxoYbXj53ZdEMI3gYCF69m/Nf3lNY33nb7TI//I7qYBTspXdoCJ221MFJWYn04
hhxOdvo3xJ2shZOSJ4IH3waSk0G2hlOjPhud2m+t1KMtDt2e09A3ZD1xhmCxs0s=
=fDcF
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Unable to boot Lenovo T520

[Xin LI]

On Fri, Jun 10, 2011 at 4:42 PM, Jeremy Chadwick
free...@jdc.parodius.com wrote:
 On Fri, Jun 10, 2011 at 04:15:56PM -0700, Xin LI wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 06/10/11 15:15, Kevin Oberman wrote:
  I am hitting the problem reported some time ago with atkbd and svn
  197392.
 
  It's not clear that this has ben finally resolved, but I am still
  hitting it with -stable on my new T520. I really want to get FreeBSD up
  on it, but I am dead in the water at this time. I guess I'll have to
  build a new kernel with any fix and replace the kernel in the ISO.
 
  Also, I am hoping to use it on an amd64 kernel and I am even less sure
  that any patch will work on that arch.
 
  The original thread was
  http://freebsd.1045724.n5.nabble.com/svn-rev-197392-hangs-during-boot-td3926276.html

 The fix was not (yet) merged back to 8-STABLE.  You may use a
 8.0-RELEASE kernel to boot the system temporarily and apply this patch:

 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/atkbdc/atkbd.c.diff?r1=1.63;r2=1.64

 (If hunk #1 fails to apply, it's Ok to just ignore it).

 Specifically:

 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/atkbdc/atkbd.c#rev1.64

 -       if (x86bios_get_intr(0x15) == 0 || x86bios_get_intr(0x16) == 0)
 +       if (x86bios_get_intr(0x15) != 0xf000f859 ||
 +           x86bios_get_intr(0x16) != 0xf000e82e)

 What are these magic numbers?  Where did they come from?  What do they
 represent?  Why are they not documented in the source code/commit
 itself?  No offence, but this is an open-source project; anyone looking
 at this code isn't going to know what those vectors represent.  The
 commit message is also lacking (again: magic values not mentioned), and
 expecting a developer to dig through commits/annotations to determine
 what this piece of code is for is unreasonable.

 No I'm not in a bad mood (honest!), I just find this kind of thing
 infuriating the more I dig through kernel source code.

The commit log explicitly say:

Validate INT 15h and 16h vectors more strictly.  Traditionally these entry
points are fixed addresses and (U)EFI CSM specification also mandated that.
Unfortunately, (U)EFI CSM specification does not specifically mention this
is to call service routine via interrupt vector table or to jump directly
to the entry point.  As a result, some CSM seems to install two routines
and acts differently, depending on how it was executed, unfortunately.
When INT 15h is used, it calls a function pointer (which is probably a UEFI
service function).  When it jumps directly to the entry point, it executes
a simple and traditional INT 15h service routine.  Therefore, actually there
are two possible fixes, i. e., this fix or jumping directly to the fixed
entry point.  However, we chose this fix because a) keyboard typematic
support via BIOS is becoming extremely rarer and b) we cannot support random
service routine installed by a firmware or a boot loader.  This should fix
Lenovo X220 laptop, specifically.

Be reasonable, please.

Cheers,
-- 
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Unable to boot Lenovo T520

[Xin LI]

On Fri, Jun 10, 2011 at 5:59 PM, Jeremy Chadwick
free...@jdc.parodius.com wrote:
 On Fri, Jun 10, 2011 at 04:48:31PM -0700, Xin LI wrote:
 On Fri, Jun 10, 2011 at 4:42 PM, Jeremy Chadwick
 free...@jdc.parodius.com wrote:
  On Fri, Jun 10, 2011 at 04:15:56PM -0700, Xin LI wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 
  On 06/10/11 15:15, Kevin Oberman wrote:
   I am hitting the problem reported some time ago with atkbd and svn
   197392.
  
   It's not clear that this has ben finally resolved, but I am still
   hitting it with -stable on my new T520. I really want to get FreeBSD up
   on it, but I am dead in the water at this time. I guess I'll have to
   build a new kernel with any fix and replace the kernel in the ISO.
  
   Also, I am hoping to use it on an amd64 kernel and I am even less sure
   that any patch will work on that arch.
  
   The original thread was
   http://freebsd.1045724.n5.nabble.com/svn-rev-197392-hangs-during-boot-td3926276.html
 
  The fix was not (yet) merged back to 8-STABLE. ??You may use a
  8.0-RELEASE kernel to boot the system temporarily and apply this patch:
 
  http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/atkbdc/atkbd.c.diff?r1=1.63;r2=1.64
 
  (If hunk #1 fails to apply, it's Ok to just ignore it).
 
  Specifically:
 
  http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/atkbdc/atkbd.c#rev1.64
 
  - ?? ?? ?? if (x86bios_get_intr(0x15) == 0 || x86bios_get_intr(0x16) == 0)
  + ?? ?? ?? if (x86bios_get_intr(0x15) != 0xf000f859 ||
  + ?? ?? ?? ?? ?? x86bios_get_intr(0x16) != 0xf000e82e)
 
  What are these magic numbers? ??Where did they come from? ??What do they
  represent? ??Why are they not documented in the source code/commit
  itself? ??No offence, but this is an open-source project; anyone looking
  at this code isn't going to know what those vectors represent. ??The
  commit message is also lacking (again: magic values not mentioned), and
  expecting a developer to dig through commits/annotations to determine
  what this piece of code is for is unreasonable.
 
  No I'm not in a bad mood (honest!), I just find this kind of thing
  infuriating the more I dig through kernel source code.

 The commit log explicitly say:

 Validate INT 15h and 16h vectors more strictly.  Traditionally these entry
 points are fixed addresses and (U)EFI CSM specification also mandated that.
 Unfortunately, (U)EFI CSM specification does not specifically mention this
 is to call service routine via interrupt vector table or to jump directly
 to the entry point.  As a result, some CSM seems to install two routines
 and acts differently, depending on how it was executed, unfortunately.
 When INT 15h is used, it calls a function pointer (which is probably a UEFI
 service function).  When it jumps directly to the entry point, it executes
 a simple and traditional INT 15h service routine.  Therefore, actually there
 are two possible fixes, i. e., this fix or jumping directly to the fixed
 entry point.  However, we chose this fix because a) keyboard typematic
 support via BIOS is becoming extremely rarer and b) we cannot support random
 service routine installed by a firmware or a boot loader.  This should fix
 Lenovo X220 laptop, specifically.

 Be reasonable, please.

 I read the commit message -- sadly it also does not explain what the
 numbers mean.  0xf000f859 and 0xf000e82e appear to be 32-bit vector
 addresses (e.g. used for indirect JMP), except nobody explains where
 those values came from or what they actually point to.  Therefore, they
 are magic values until they can be defined otherwise.

 Someone digging through the source code is not going to see the commit
 message.  They're going to have to track it down by hand using cvsweb or
 SVN, just to look at annotations.  Don't worry, I don't mean for this to
 sound like I'm picking on this single commit -- this kind of craziness
 is all over the FreeBSD source tree, and as I said, it's infuriating
 when trying to look at the code (it is an open-source project, right?)
 and figure out what's going on/why something is the way it is.

I'm not in good mood and I find it a waste of my time, sorry for that.
 I have committed a fix (r222967).

Just want to say that Jung-uk have spend a lot of his time
investigating and fixing this issue, and I just don't see why people
typing that much doesn't want to submit a patch.  I think Open Source
projects expect everyone there to contribute rather than asking
someone else to do the work.

Cheers,
-- 
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ZFS V28

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Leon Meßner wrote:
| On Fri, Apr 15, 2011 at 06:28:07PM +0300, George Kontostanos wrote:
| I was wondering if ZFS v28 is going to be MFC to 8-Stable or not.
|
| On Fri, Apr 15, 2011 at 06:28:07PM +0300, George Kontostanos wrote:
| I was wondering if ZFS v28 is going to be MFC to 8-Stable or not.
|
| Is there a recent patch against stable sources ? I tried the following:
|
|
http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.patch.xz
|
| This patch failes at sys/cddl/compat/opensolaris/sys/sysmacros.h which i
| think should just be deleted. I tried deleting this file and then
| building produces some errors then walls of text and then aborts.
| The first errors look like this:

This file should be removed.  The rejection might be caused by SCM tag
from checkout, which depends on your configuration, and can be safely
ignored.

Cheers,
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAk2o4r0ACgkQOfuToMruuMCQkwCfZZtClSQmciKJt81t79NyyH1k
WgIAn0gJj075PeieFsg6gzpTmG7EDb9O
=CTU7
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: reboot halts on atom D525

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/28/10 23:28, Andrei Kolu wrote:
 Hi,
 
 trouble with rebooting on Intel Atom motherboard D525MWV.
 --
 ...
 All buffers synced.
 Uptime 4m 27s.
 Rebooting...
 CPU_reset: Stopping other CPUs
 _
 --
 System halts completely- no response to CTRL+ALT+DEL. Only way to
 restart is to press reset or power off. No error messages.

Will a sysctl hw.acpi.handle_reboot=1 before rebooting help?

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJM9BnWAAoJEATO+BI/yjfBDMgH/j3omd71w5hjqBt5VLia2Z2V
n1iTSABh9TUhYDrh9lMTkIBr/3S0A7g3JwzRJJZB4K2+J5M+1x/lsd4CgePoiLVB
X5+EIj9pIrk6nvTP7ERN0HeznmpKIQSUnIgrxTJTAk2qeVSXc2NW5H48eOEAuWsO
kngjJDe4FX1jw8U5Hn13jUwv5dS4IIJfk7zef6a2lPpuFsfNBiLKrV2aMy/iNRUs
XIL65VKVhqUg/qc9zFDnOoWNTYJoonkTKPkYPVn891vycwyuIaxcj8JjCNHYgARQ
5lE4SiDxzplqr1+dQe1HC2hi6V1+Vh/ICmMyRX/35sJ3cwpkbcSK1d17OQxghIA=
=pzIx
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Support for Areca ARC-1300-4X on 8-STABLE?

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/24/10 18:28, Paul Mather wrote:
 On Nov 24, 2010, at 7:06 PM, Xin LI wrote:
 
 On Wed, Nov 24, 2010 at 7:01 AM, Paul Mather p...@gromit.dlib.vt.edu wrote:
 Thanks for the link!  I'm not sure whether Fixed arcmsr driver prevent 
 arcsas support for Areca SAS HBA ARC13x0 in the Bug fixes list is good 
 news or bad news for me.  It suggests that the arcmsr driver has been fixed 
 to prevent it attaching to the ARC-13X0 cards, implying that it is not 
 supported.  This entry about OS support on the Areca official page for the 
 ARC-1300 product (http://www.areca.us/products/sasnoneraid.htm) is also not 
 inspiring: BSD/FreeBSD (will be available with 6Gb/s Host Adapter).  Does 
 this mean only their 6 Gb/s cards will be supported under FreeBSD, or that 
 support for the 3 Gb/s cards will appear alongside the 6 Gb/s cards, 
 whenever they are released?

 The 6Gb/s cards are not released yet.  The updated driver resolved a
 conflict with the newer ARC13x0 cards, without it one will have to
 update arcmsr(4) before installing the SAS card driver.
 
 So, to clarify, does this mean the 3 Gb/s ARC-1300 cards are not currently 
 supported under 8-STABLE?  Or, are they supported by a different driver to 
 arcmsr (if so, which one?), but arcmsr must be updated so it doesn't probe 
 and claim the card instead?

Looking at the code I believe Areca 1380 and 1381 are supported on
- -HEAD.  I'm heading off committing the MFC of latest driver to 8-STABLE
in a few minutes.

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJM7qgWAAoJEATO+BI/yjfBX2kIAKEaJFhUEKPzgxiOdch7EfQ4
HNctzFm0t+7UuRrZJwmikB8cgJSXwWutbDJnbLmhimzeoYJdvcVW+Z+Kp2ewEnCx
YvDE+v7MqNxOsb66RxJ70lY0SPCozKufRa1v9uHpeBEyGgeCGoS8+1vLCHX0tlKL
wv+kpM+u5BVCsCQOfDj6CAaJEl6UxEBpEG7fK1+BViQsilUff1NIHvMXvG0JV1lD
Dz+Wrt0sCMJb7VVrJ3BJkJ/Xnl9GsimwatKS9PxRe+I294JOxn3PHeJSX4kRbnyo
LaDWtKyDMj4z4D2QE5B97eORD/0md7RMtpo628U1QGwAyQ8rVPZUUzZP9hWuH+A=
=wAD1
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Support for Areca ARC-1300-4X on 8-STABLE?

[Xin LI]

On Wed, Nov 24, 2010 at 7:01 AM, Paul Mather p...@gromit.dlib.vt.edu wrote:
 Thanks for the link!  I'm not sure whether Fixed arcmsr driver prevent 
 arcsas support for Areca SAS HBA ARC13x0 in the Bug fixes list is good 
 news or bad news for me.  It suggests that the arcmsr driver has been fixed 
 to prevent it attaching to the ARC-13X0 cards, implying that it is not 
 supported.  This entry about OS support on the Areca official page for the 
 ARC-1300 product (http://www.areca.us/products/sasnoneraid.htm) is also not 
 inspiring: BSD/FreeBSD (will be available with 6Gb/s Host Adapter).  Does 
 this mean only their 6 Gb/s cards will be supported under FreeBSD, or that 
 support for the 3 Gb/s cards will appear alongside the 6 Gb/s cards, whenever 
 they are released?

The 6Gb/s cards are not released yet.  The updated driver resolved a
conflict with the newer ARC13x0 cards, without it one will have to
update arcmsr(4) before installing the SAS card driver.

Cheers,
-- 
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: [releng_7 tinderbox] failure on amd64/amd64

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/19/10 02:00, Jeremy Chadwick wrote:
 On Fri, Nov 19, 2010 at 10:44:59AM +, FreeBSD Tinderbox wrote:
 === usr.bin/nc (all)
 cc -O2 -fno-strict-aliasing -pipe  -DIPSEC  -c 
 /src/usr.bin/nc/../../contrib/netcat/netcat.c
 /src/usr.bin/nc/../../contrib/netcat/netcat.c: In function 'remote_connect':
 /src/usr.bin/nc/../../contrib/netcat/netcat.c:573: error: 'IP_BINDANY' 
 undeclared (first use in this function)
 /src/usr.bin/nc/../../contrib/netcat/netcat.c:573: error: (Each undeclared 
 identifier is reported only once
 /src/usr.bin/nc/../../contrib/netcat/netcat.c:573: error: for each function 
 it appears in.)
 *** Error code 1
 
 This has been broken for 24 hours, and only on RELENG_7 (for all
 architectures, not just amd64), which lacks IP_BINDANY capability:
 
 http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/netcat/netcat.c#rev1.6.2.2

Fixed in r215514.  Sorry for that.

 The committer and/or author needs to #ifdef IP_BINDANY the relevant
 setsockopt() call for the RELENG_7 branch, or even both RELENG_7 and
 RELENG_8 if they want.
 
 This original methodology was in the code (for SO_BINDANY), but was for
 some reason removed.
 
 http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/netcat/netcat.c.diff?r1=1.6.2.1;r2=1.6.2.2;f=h

The #ifdef's were to keep OpenBSD specific code out from build, but I
have realized later that we do have IP_BINDANY for ~ 1 year so I have
decided to utilize that feature but never realized that it was never
MFC'ed to RELENG_7 :(

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJM5k+RAAoJEATO+BI/yjfB9YMH/iax9sXZYM9ugbKgDWu25HZs
v96qI1xgD10LS8m9YL0dpHU7pgaXLmHUPxBGlhigvIEBfyQwAOBYTfppv+WNBuzK
1esYDn2muoh3PNdPApldYkN8beX2bc/l6CHHaI0yWJuR21DExmYlsSlZwulwU1r5
Xu/maQ2tKdV8AFr5jPDoDNybHp/wdQIinnppoUeZ3RUCPfXngp0afbC7r84B5yIa
8W+fZBIDFJIGva4GPt7x3w3QKRpGyvXlExVssTUyf6uZb/v9ulsakFiQaoBPh1u5
yf898QHlB++zoSH9oeTTAeoeQDpQjcouV++Z1S5ukcP2lkY/EXrM0Nnt2Wnc4kU=
=eszP
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Call for Area SATA II RAID controller testers [Fwd: svn commit: r215234 - head/sys/dev/arcmsr]

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, Mike,

On 11/19/10 12:15, Mike Tancsa wrote:
 Hi,
   All seems to work well with the ARC-1110 card in RAID 10.  Read and
 write speeds are about the same with the previous version of the driver
 on AMD64, RELENG_8.
 
 It also gets rid of a long standing bootup (cosmetic ?) error.  Web and
 CLI work properly as well

Thanks!

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJM5t3xAAoJEATO+BI/yjfBos0H/itrG+M8j3aE5KqTrFcaaJ0w
q0aBQQYv2ya3Y6wMt/MxHC7h3wkm61U6owoGHRAVCEUZXPBGRWUC3R4Gastae7R4
zcMc5K6aHeBM17qZQh0kds5nlSO6x0+hc1H3KpCCE2XJhHaRz8xPFlzFVkB3U5Fi
8uSXKq+KwJDar+7LloyFQqtf7Q22KaxmNoSI9bSwLK9OM02Si7hqk3W52pFxZGJJ
P1duhT5S45fg+/6gqCg3uzw8M1UpGLHqN92okXHhAvUZdK/g3dixDrwfavxiRCvb
ZTUfqeX58Pmgheh/+7I6XCpD1QTB2hgdiP64/Cqd4aHM5bsKdOkRD/XM+9RD72Y=
=/7CP
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Call for Area SATA II RAID controller testers [Fwd: svn commit: r215234 - head/sys/dev/arcmsr]

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I have just committed a new vendor release of arcmsr(4) driver.  This is
intended for 8.2-RELEASE so please test if you could.

Thanks in advance!

(Note: I have a tarball at
http://people.freebsd.org/~delphij/misc/arcmsr.tar.xz which can be used
for 8.x system, untar over /usr/src and rebuild the kernel or module
depending on your configuration).

-  Original Message 
Subject: svn commit: r215234 - head/sys/dev/arcmsr
Date: Sat, 13 Nov 2010 08:58:36 + (UTC)
From: Xin LI delp...@freebsd.org
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org

Author: delphij
Date: Sat Nov 13 08:58:36 2010
New Revision: 215234
URL: http://svn.freebsd.org/changeset/base/215234

Log:
  Update to vendor release 1.20.00.19.

  Bug fixes:
* Fixed inquiry data fails comparion at DV1 step
* Fixed bad range input in bus_alloc_resource for ADAPTER_TYPE_B
* Fixed arcmsr driver prevent arcsas support for Areca SAS HBA ARC13x0

  Many thanks to Areca for continuing to support FreeBSD.

  This commit is intended for MFC before 8.2-RELEASE.

  Submitted by:   Ching-Lung Huang ching2048 areca com tw

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJM3lRTAAoJEATO+BI/yjfBs3wH/24ViOUPwdDjr9lDsX6RaWCQ
Ux+9YsekrXLVks61zH8B1dW1rXmthk+aiXpE223UYkcb2M5sLgOQCBYlSDoSwJXu
q8iLLZ9Dg6hWpLiS1u6sCj3jjsQbsDVuW1BCrCTSr/eOp6AbXI19GEDouPxVKkt3
wc1amh3eo6ZQAWnxksk+6/HK4nGJOQhjuEC8llybSsImeqqzoEGhRyqJVGa3NO7q
fZfTX108QItRmx9Uavh3/2Sa4WA9RWWky+QUSg3hPZg1kNSYJOHuCHgEQIGEE+9R
qG38IjHP+NPw0jZVAE7Qap0rA/iMY5FOKeLTjH0PvRBsFeRiPP22KRvdf8eQBM8=
=X4q7
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: MFC of ZFSv15

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/09/15 11:30, Mike Tancsa wrote:
 At 02:07 PM 9/15/2010, Pascal Stumpf wrote:
 First of all, a great thanks to mm@ and pjd@ for the excellent work on
 ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago.
 
[...]
 here too.  RELENG_8 AMD64.  The tinderboxes havent hit that branch yet
 (http://tinderbox.freebsd.org/http://tinderbox.freebsd.org/), so it
 will be a few hrs before they get to test RELENG_8
[...]
 -lsbuf  -lm -lnvpair -luutil -lutil
 /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent'
 *** Error code 1

Sorry for that, it seems to be caused by a partial merge
(cddl/compat/opensolaris/misc/mnttab.c).  mm@ is going to fix that ASAP.

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMkRqwAAoJEATO+BI/yjfBUlEH/0oEST4976dZ4TKdawx8OWdJ
X81gQvH0rl29xS+pJkuELMGROgsFDp3bCsYREFItAOYYAk4hDWRCqghXH2TzpcgJ
N1VHjfe/nnZzvoJ1XTPuUcPH2F6okg7hfgb7zGHc120x/xDKOyW8urNEOrPKT/P4
edsyD/Ilp0S97GiVW6LjCmY05ieTS/IqnjMSFSPiWN9DkkcdccQfDRQL5v71RgBF
nCHwsqgEZjAsdtebmdAoFBtAR9Hm3+N7W6AhCMfM/mLF2xHzD1BxWPO1vQ+k1Mfx
huMVRlsZ4PK5JIqUNYzfUzGZqNfCcdafBbw0BsnPf/n7kMWXQVNCFM8iaFXPWUQ=
=EncA
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Watchdog not being disabled while dumping core

[Xin LI]

On Mon, Aug 23, 2010 at 3:34 AM, Jeremy Chadwick
free...@jdc.parodius.com wrote:
 PR bin/145183, opened in 2010 (not sure if this is the same):
 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/145183

Speaking for this I think we can do it by issuing an explicit
watchdog(8) command on shutdown (like, set the timeout to several
minutes) in /etc/rc.d/watchdog's shutdown section.  This would be
trivial to implement.  Additionally, I'd personally think init(8)
should be taught about watchdog facility.

For panics, I think we should have the disk driver to pat watchdog
rather than disabling it in their write success callback?  Another
thing is that ddb should be able to disable watchdog when it's waiting
for keyboard input (or received first user input) I think.

Cheers,
-- 
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: FreeBSD 8.1 make world FAILED!

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/08/09 08:55, James Chang wrote:
 install -C -o root -g wheel -m 444   libc.a /usr/lib
 install -C -o root -g wheel -m 444   libc_p.a /usr/lib
 install -s -o root -g wheel -m 444   -fschg -S  libc.so.7 /lib
 install: rename: /lib/i...@dhuu to /lib/libc.so.7: Operation not permitted
 *** Error code 71
 
 Stop in /usr/src/lib/libc.
 *** Error code 1
 
 Stop in /usr/src/lib.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 
 Are there smothing wrong?

Yes.  I think you must have securitylevel set to 1 or above.  Check your
/etc/rc.conf to see if that's the case or upgrade when in single user
mode...

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMYEPeAAoJEATO+BI/yjfBX+kH/RACoAFSz4gp7eZVTnLe6ScD
wUVMAaAgbUp+Wo9J2qh1yXlnsijKBfv8m5MsdesvpZZX3PFzU+8lSTdVOqpIp3aK
vbwuIkNOptO8iUVcC25KaT+FXjaVdL84hEeI74IyHCNdph2TaqfAona5zLR3gvrT
u+P7El56v0GlrnUH2Zq9ti2RutoLk1JvA0XJCg5JshwdJI+QS8Sg9+L9GTmUrJ6M
lNifYMyyba4kznzPZTEaa0qQsYQLGqJZyd/5vLk8/JKZPqIBc3dIAvu9ELd8aq/e
DbA0AvB/dz1c5FUhV1vGQv85BJQmNj/dFnVzk0TlB5lkayYDYVKP8H7AutrRUDk=
=vJFC
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
 Hi,
 
   I am getting more than 4 thousand of the following messages a day:
 
 WARNING pid 24509 (python2.6): ioctl sign-extension ioctl 8004667e
[...]

I think we may need to check the code and patch it.  Basically this
means that python (or some .so modules) passed an int or unsigned int as
parameter 'cmd', we need to change it  to unsigned long.

The warning itself should be harmless to my best of knowledge, one can
probably remove the printf in kernel source code as a workaround.

By the way it seems to be a POSIX violation and we didn't seem to really
use so wide cmd, but I have not yet verified everything myself.

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (FreeBSD)

iQEcBAEBCAAGBQJMIk58AAoJEATO+BI/yjfBvaAIALLZMVxTN8xMfutobstHHEvc
OMVlLcnNM4erbCpL7ThbwsyOBEc5gbNSGtK2jvE3Z82uIhM74NXoe5PwnMeN73Gy
r8ShMVdfE5hhJC6HmjGx9sV/zf88dySAQ8n0uHUsIUUL0DnvEOvS7pIEs73Ozm3u
Cm9+0k2re604pj3gyFOfaXnJBH8VwSk3VPtOBHGQJnpjNRoHDpT6hw0iRO4+O6UA
DoGZHIXpBvM0Qb6unisNogDL1Vsg1A208JCPk96YJegH023HE1oE/jmhgqNwiA/V
jZY4VcAJUG+Gpc86VGtZv+w3YIiObMTS4ohO+ktGxfxetPbF2QboIdRUnr28yyU=
=Pwmz
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/06/23 11:37, Jung-uk Kim wrote:
 On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
 Hi,

 On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
 Hi,

 I am getting more than 4 thousand of the following messages a
 day:

 WARNING pid 24509 (python2.6): ioctl sign-extension ioctl
 8004667e

 [...]

 I think we may need to check the code and patch it.  Basically this
 means that python (or some .so modules) passed an int or unsigned
 int as parameter 'cmd', we need to change it  to unsigned long.

 The warning itself should be harmless to my best of knowledge, one
 can probably remove the printf in kernel source code as a
 workaround.

 By the way it seems to be a POSIX violation and we didn't seem to
 really use so wide cmd, but I have not yet verified everything
 myself.
 
 Long time ago, I had a similar problem with termios TIOCGWINSZ and we 
 patched the port like this:
 
 http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/Attic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fplain
 
 I believe it was upstream patched at the time but I won't be surprised 
 if something similar was reintroduced.  It happens when a Python 
 internal integer type is converted to a native unsigned long.

Well, only *BSD have cmd a long value so it's likely that it would be
reintroduced.

I have checked the 4.4BSD archive and understood that our ioctl's cmd
parameter was made long around 1991 or 1992s but didn't see what it
actually buy us...

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (FreeBSD)

iQEcBAEBCAAGBQJMIlVyAAoJEATO+BI/yjfBLgcIAKXIekJTGptB51L3XJaJL0q4
I+3nAqDcexDiTIAZ3ExDW47MNeh89fR5Iun2kgYlaOYtEEz8iFdJkrH2dgjkRGpt
iBXcjuYw/rVINkvl03tovwIaDNmHjvD3NyvvTSOqmSsRnyR6Z7LACNqQr95nPzrF
jJFS+AWT0QeytzhJFSAHXniR9paTsktnHTIN4XEdnYlzNIIhP8BoDgfJ3RqGJRk9
QcvZtait5JWHaGJFhGvN/j30lGsHPabt9zWqNVSHLJ9pSzfwAtW7Ihwso55/blYA
JxkRUps2AfK9ZhvQ2B0eArVQLjA61HifVE1UNLrkh1KMeUPth4eIZvBZuWtJ7R8=
=ZCD9
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/06/23 12:10, Jung-uk Kim wrote:
 It is still a kludge and it won't be fixed. :-(

Another thought - what about just hiding the printf under #ifdef
DIAGNOSTIC...  I don't really see any reason why we must print it out if
we truncate it every time...

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (FreeBSD)

iQEcBAEBCAAGBQJMIl2QAAoJEATO+BI/yjfBpz0IAM88YOx5CVoYRCEW8EwCaW+N
5Ugks9hCvbsJgU2yLxeg5hGal0wOHKONLxaq9pXvQFybgRT9SLmna2FJLTJ6XYTu
pjtjeby40mpwRTwU5rZgJ//aYgHW48kK9N/CoE63zKycYQbjLFGnZmXbel9itZzL
Xnpj9kc0zlpqtk6yZd4XA+m90VrIgnMKmxeP0A5OzuWJKUBmvciqSMYEBQ0pkP03
sSiN5QIzW/gRMgYSJEsTGz5+q10ZDf0NOecuhOujLphWLzWxkq6UOqRi3JXvFaqo
ajRDpGEG65r2IDd8qo4y50U0FGeHmysTFUPU3aAOzjb10LbNbmT6zX+3G1rSMFY=
=A2pe
-END PGP SIGNATURE-
Index: sys/kern/sys_generic.c
===
--- sys/kern/sys_generic.c  (revision 209472)
+++ sys/kern/sys_generic.c  (working copy)
@@ -628,9 +628,11 @@
caddr_t data;
 
if (uap-com  0x) {
+#ifdef DIAGNOSTIC
printf(
WARNING pid %d (%s): ioctl sign-extension ioctl %lx\n,
td-td_proc-p_pid, td-td_name, uap-com);
+#endif
uap-com = 0x;
}
com = uap-com;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: [Stable 7] CPIO breakage/

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/06/18 10:51, Sean Bruno wrote:
 On Thu, 2010-06-17 at 15:13 -0700, Xin LI wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 2010/06/17 13:53, Peter Jeremy wrote:
 On 2010-Jun-15 17:22:50 -0700, Xin LI delp...@delphij.net wrote:
 On 2010/06/15 17:05, Sean Bruno wrote:
 A little more background.  It looks like symlinks are getting stripped
 of their '/' which sucks.  Ideas?
 ...
 e.g. /home/foo/bar - /opt/baz/blob

 becomes

 home/foo/bar - opt/baz/blob   

 Yuck.

 This is a security measurement I think.

 Can someone please explain how stripping a leading '/' off the
 destination of a symlink enhances security?  The destination is
 not being written to.

 --absolute-filenames disables this behavior.

 This definitely reduces security and would seem to be far more
 dangerous than being able to create symlinks to absolute pathnames.

 Sorry I have misunderstood the original issue.  It's the link target
 being mangled and doesn't seem right to me.  I'll ask the author about this.

 The attached patch should restore the old behavior.

 Cheers,
 - -- 
 Xin LI delp...@delphij.net http://www.delphij.net/
 FreeBSD - The Power to Serve!   Live free or die
 
 Yep, *this* patches seems to make things much happier.  I'll integrate
 cpio 2.8 back into the Yahoo tree when this is merged in.  

Thanks for testing, I have committed the patch as r209311 and sorry for
the breakage.

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBCAAGBQJMG7lxAAoJEATO+BI/yjfBBhEIAJRbR1ZniY+JQ4Ak+He+FWKw
jRXb/lTC1PfCDIi5Vm+j0NGAZP2hNBzt9k7uouDyguXcHKvPNXKFhjvaJtdDK40Y
e2Pr2PNeXzwBGaL27eDPdjt2gxZ16GbzQe47d2jyT3nQRUYBGehJcLzJl7chrLZn
0PJmztmZt8Uc6oeQo427PzhgqcCFG5Edrc7dtiFZ1rvdaXGXd64mu30oArLV3MCA
c//wgx+qK2wQ1AGeylZGOqbJmtgdxY3+g961a/G9c0Y/Bt+muWBY5xDK1LpA7IcN
/s8l39g6TMzjp4YYlRUG5flhv3xtFACZxxAnkDYA+02cR2euNpt1irjdxj7jwvI=
=V3yO
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: [Stable 7] CPIO breakage/

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/06/17 13:53, Peter Jeremy wrote:
 On 2010-Jun-15 17:22:50 -0700, Xin LI delp...@delphij.net wrote:
 On 2010/06/15 17:05, Sean Bruno wrote:
 A little more background.  It looks like symlinks are getting stripped
 of their '/' which sucks.  Ideas?
 ...
 e.g. /home/foo/bar - /opt/baz/blob

 becomes

 home/foo/bar - opt/baz/blob   

 Yuck.

 This is a security measurement I think.
 
 Can someone please explain how stripping a leading '/' off the
 destination of a symlink enhances security?  The destination is
 not being written to.
 
 --absolute-filenames disables this behavior.
 
 This definitely reduces security and would seem to be far more
 dangerous than being able to create symlinks to absolute pathnames.

Sorry I have misunderstood the original issue.  It's the link target
being mangled and doesn't seem right to me.  I'll ask the author about this.

The attached patch should restore the old behavior.

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBCAAGBQJMGp3tAAoJEATO+BI/yjfBIkIH/0buRkFHzuflR49XomlHNk4Q
uG8uY9/tlyBH6hNTnAqOfjGZLRM500nIifathpIeMd5BNvt2m6OLnuCHlX0Fu7LV
nc83dS4nL1URp1gZqDrRcXTYMlV+2mASslyz/HpqJSIYx/sfKgRujWoqQr6Qufmu
qAMt0324UYIABlPo/M4tsU9LQoPheQLBq+FozcUvxwdoQsy5H1fCaNI4efwTpGNR
CLvBypCRw8ALnoOQAYWQXQF6x/tEO33Y5DVloDh1B/5haSTFmKJK8rlRucY6A731
QysspgLtRMJ7NWJfCbJr7mA/4aqqDMzg3bIZzkgYmGUoV0EsHy5tQQKdkz1I1Mw=
=A705
-END PGP SIGNATURE-
Index: contrib/cpio/src/copyout.c
===
--- contrib/cpio/src/copyout.c  (revision 209216)
+++ contrib/cpio/src/copyout.c  (working copy)
@@ -836,9 +836,6 @@ process_copy_out ()
continue;
  }
link_name[link_size] = 0;
-   cpio_safer_name_suffix (link_name, false,
-   abs_paths_flag, true);
-   link_size = strlen (link_name);
file_hdr.c_filesize = link_size;
if (archive_format == arf_tar || archive_format == arf_ustar)
  {
Index: contrib/cpio/src/util.c
===
--- contrib/cpio/src/util.c (revision 209216)
+++ contrib/cpio/src/util.c (working copy)
@@ -1252,8 +1252,25 @@ stat_to_cpio (struct cpio_file_stat *hdr, struct s
   hdr-c_uid = CPIO_UID (st-st_uid);
   hdr-c_gid = CPIO_GID (st-st_gid);
   hdr-c_nlink = st-st_nlink;
-  hdr-c_rdev_maj = major (st-st_rdev);
-  hdr-c_rdev_min = minor (st-st_rdev);
+
+  switch (hdr-c_mode  CP_IFMT)
+  {
+case CP_IFBLK:
+case CP_IFCHR:
+#ifdef CP_IFIFO
+case CP_IFIFO:
+#endif
+#ifdef CP_IFSOCK
+case CP_IFSOCK:
+#endif
+  hdr-c_rdev_maj = major (st-st_rdev);
+  hdr-c_rdev_min = minor (st-st_rdev);
+  break;
+default:
+  hdr-c_rdev_maj = 0;
+  hdr-c_rdev_min = 0;
+  break;
+  }
   hdr-c_mtime = st-st_mtime;
   hdr-c_filesize = st-st_size;
   hdr-c_chksum = 0;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: [Stable 7] CPIO breakage/

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, Sean,

On 2010/06/15 15:10, Sean Bruno wrote:
 http://svn.freebsd.org/viewvc/base?limit_changes=0view=revisionrevision=208361
 
 I'm not sure what's up with this update, but it hosed up the default
 behavior of cpio.
[...]
 We've had to revert this change from our local tree, suggestions?

Could you please test the attached patch?

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBCAAGBQJMGAz/AAoJEATO+BI/yjfBoMsH/09y4W745hnblSDFM3J8zBaa
rQjXnN08vtitqu55uFz1dBwFrP9IvbIU0yCNqOOiYduBvhjQt4IMM/FY+sXDBbHo
U5jZ7jQvu+usw3mewRMrnc1weCQnehyQMC9u5ZCVZYXp2aK/MhOXTX6/faZpxseW
zStQYjAtXOzMQ7oEWV6DBFbwOXaCGybfqNKoygeqTlGDDrdh0RXbXBzeYDmh9FNt
lA4+utFRcDOgupZDP+bDe3tR7Tl/keBFCCOkuBjrYtZaMDePxSWFC9ES2zvOue1c
IekVMB71elpgnUsjv/ryqwLB4SanDB5c/QCCFHtr77FsxJh4muv2ecX2sNj2zvg=
=YFSQ
-END PGP SIGNATURE-
Index: contrib/cpio/src/util.c
===
--- contrib/cpio/src/util.c (revision 209216)
+++ contrib/cpio/src/util.c (working copy)
@@ -1252,8 +1252,25 @@ stat_to_cpio (struct cpio_file_stat *hdr, struct s
   hdr-c_uid = CPIO_UID (st-st_uid);
   hdr-c_gid = CPIO_GID (st-st_gid);
   hdr-c_nlink = st-st_nlink;
-  hdr-c_rdev_maj = major (st-st_rdev);
-  hdr-c_rdev_min = minor (st-st_rdev);
+
+  switch (hdr-c_mode  CP_IFMT)
+  {
+case CP_IFBLK:
+case CP_IFCHR:
+#ifdef CP_IFIFO
+case CP_IFIFO:
+#endif
+#ifdef CP_IFSOCK
+case CP_IFSOCK:
+#endif
+  hdr-c_rdev_maj = major (st-st_rdev);
+  hdr-c_rdev_min = minor (st-st_rdev);
+  break;
+default:
+  hdr-c_rdev_maj = 0;
+  hdr-c_rdev_min = 0;
+  break;
+  }
   hdr-c_mtime = st-st_mtime;
   hdr-c_filesize = st-st_size;
   hdr-c_chksum = 0;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: [Stable 7] CPIO breakage/

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/06/15 17:05, Sean Bruno wrote:
 On Tue, 2010-06-15 at 17:10 -0500, Sean Bruno wrote:
 http://svn.freebsd.org/viewvc/base?limit_changes=0view=revisionrevision=208361

 I'm not sure what's up with this update, but it hosed up the default
 behavior of cpio.

 It appears now that -o won't do the same things that it used to:

 + cd /
 + find -x .
 + egrep -v '^\.(/snap|/usr/sup|/boot/kernel/kernel
 \.[[:alpha:]_]+\.[[:digit:]]+|/boot/kernel/kernel
 \.old|/etc/start_if.*|/etc/ssh/ssh_host_.*key|/etc/hostid|/etc/(master.passwd|passwd|spwd.db|pwd.db))'
 + '[' -n '' ']'
 + '[' 7 = 4 ']'
 + '[' -n '' -a -z '' ']'
 + '[' -n /home/backup ']'
 + echo 'dumping / ...'
 dumping / ...
 + cpio -o --quiet --format crc -O /home/backup/root.amd64.cpio
 cpio: ./dev not dumped: minor number would be truncated
 cpio: Removing leading `/' from member names
 cpio: ./proc not dumped: minor number would be truncated
 cpio: Removing leading `../' from member names

 We've had to revert this change from our local tree, suggestions?

 Sean
 
 
 A little more background.  It looks like symlinks are getting stripped
 of their '/' which sucks.  Ideas?
 
 Sean
 
 e.g. /home/foo/bar - /opt/baz/blob
 
 becomes
 
 home/foo/bar - opt/baz/blob   
 
 Yuck.

This is a security measurement I think.

- --absolute-filenames disables this behavior.

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBCAAGBQJMGBlZAAoJEATO+BI/yjfBAekH/1F/g1JUZWricyMmy2hF5f5x
EvHnp6j5GClGRFm/llh5FdYhEMlS7gYEgcHhT96TSicetgy7Jzs3+Cq7aAcDAXCv
jyHlf0EMvTSDKHO8tDn8EXxlhxiBIRM1iMPvuzKAiH3HqPFufOvK41ozc4dpkXzS
YLtbKUE4heEXIDP6Pm3nMDupc1BAax0JHqCmU7a/Th3WMWBmllpCQmKqfRP8w11i
GLmrQ/nWwX/y7eSKlr9azB/uZr6cCdo4bB+VcuyWO9hyHf5QtLv5peHqAD8iO9Ph
VhyRUzcTlYhBtYHOvStIAyWh3c9WV/D0nsh3+NugajSRMoD9oAVKsLOWSlmtKCw=
=t5Tx
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Is crunchgen broken?

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/06/03 16:24, Thomas wrote:
 Hello
 
 I tryed to use crunchgen. It's not working for me. I always get a
 NFS4ACL error.
 
 r...@bert:/usr/src/release/i386# crunchgen boot_crunch.conf
 Run make -f boot_crunch.mk to build crunched binary.
 
 (cd /usr/src/sbin/tunefs   make -DRELEASE_CRUNCH -Dlint  depend 
 make -DRELEASE_CRUNCH -Dlint  tunefs.o)
 cc -mtune=native -O2 -fno-strict-aliasing -pipe -march=native -std=gnu99
 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
 -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/tunefs/tunefs.c
 /usr/src/sbin/tunefs/tunefs.c: In function 'main':
 /usr/src/sbin/tunefs/tunefs.c:274: error: 'FS_NFS4ACLS' undeclared
 (first use in this function)
 /usr/src/sbin/tunefs/tunefs.c:274: error: (Each undeclared identifier is
 reported only once
 /usr/src/sbin/tunefs/tunefs.c:274: error: for each function it appears in.)
 /usr/src/sbin/tunefs/tunefs.c: In function 'printfs':
 /usr/src/sbin/tunefs/tunefs.c:475: error: 'FS_NFS4ACLS' undeclared
 (first use in this function)
 *** Error code 1

Just a guess - did you have done a full build and 'make installworld'?

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBCAAGBQJMCEAGAAoJEATO+BI/yjfB7zUIANjCi6H25g9LOPBF0Fmj6EfU
WbcfdCohtnpnN7RLc8XozksKudakCyvL0Abefw0WMJlicdTHDm0sfl50BRGXjAVl
UV68fsFtZT+VLDZTZMuS6RNNmxuM8kPrNvO5AlDIaeDh7I8Kk8Q/vdpCXuDyxDqp
SjykzXHqsAvdKE8IiNWBbv2DDB65ozQV+ZLyJo9XlppQ/Rgbw9xZ9UkeH2TgsVS5
pHUBFiVpU7o0jEsQBHSgb5R2Oqt/HwWefFdUKktYh3PdZviXGggHPjJYDOVe/vvR
5nC78/WMxrCk0lmz5mOFdjt2OjdcNqi27wc9Ho7Ld+hdoftjtas0+e6+Y72aBj4=
=hALf
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Make ZFS auto-destroy snapshots when the out of space?

[Xin LI]

Hi, Kirk,

On Sat, May 29, 2010 at 1:07 PM, Kirk Strauser k...@strauser.com wrote:
 I found some nice scripts to regularly snapshot all the filesystems in my
 ZFS pool at
 http://www.neces.com/blog/technology/integrating-freebsd-zfs-and-periodic-snapshots-and-scrubs
 . One thing bothers me, though: I have to intentionally set how many months'
 worth of snapshots I want to keep. Too many and I run out of room. Too few
 and I lose some of the benefits of easy recovery of deleted data. My
 computer is better at bookkeeping than I am, so why not let it?

 I'd propose standardizing on an attribute like org.freebsd:allowautodestroy.
 Modify ZFS's disk full behavior to scan for snapshots with that attribute
 set and destroy the oldest one, and continue until there's enough free space
 to complete a write requests or until out of expendable snapshots to
 destroy (at which time the normal disk full handler would run). Also run a
 daily periodic script to ensure that the free space stays below a
 configurable threshold each day so that ZFS isn't constantly butting up
 against completely full drives.

 This would take all configuration guesswork out of the equation and would
 let me keep as many snapshots as I have space to maintain. If I want to
 extend my reach back in time, I can add another drive to the pool and the
 rest is handled automatically. At the same time, should I suddenly *want* to
 store massive amounts of new data, the snapshots can be easily and
 automatically cleared out to make room for the stuff I want to hold.

 What do you think? It seems like this should be pretty easy to implement
 without requiring any upstream changes or new FreeBSD-only data structures.
 The whole thing could possibly be implemented in userspace, but I don't know
 that ZFS has any exception handling callbacks that would make it easy.

 An unused resource is a wasted resource, right?

I think this sounds like a good idea but I think we may probably want
to explore a more general mechanism, e.g. a daemon that listens
system events like file system full, etc. and execute some user
defined actions.

One thing that we want to avoid is that by making the automatic
recycle we would open a new race between system and user backup
programs, i.e. if you remove an intermediate snapshot, 'zfs send' may
fail at receiving side, if incremental send is being used.  We would
need a way to notify that a 'zfs send' is underway.

Cheers,
-- 
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: lzma support in `stable' has potential issues

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/05/23 23:58, Garrett Cooper wrote:
 Hi Martin and Tim,
   I recently wiped off my Lenovo again to get a fresh install of FreeBSD 
 on it, and started out at 8.0-RELEASE (it's the media that I had on hand at 
 the time). Upgrading to 8-STABLE appears to be problematic though.
   On a few different occasions I ran into issues doing the following:

Are you using make buildworld?  Presumbly they should have been created
by mtree and I've verified that the corresponding change was merged
properly.

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBCAAGBQJL+iyzAAoJEATO+BI/yjfBlkEIAMeI3h5eHmkm8IUda3IgDHQH
w5nYRjO6Z/N+U2wjrjU6z2S2sS1bkHNAX+Ju4ERWRUHQg9K6OB9qJ6HEwVgAyYen
NMl1HK/vrUpl5PZrbAOchoTjzCVGl+dSoVsQ0TGWpzCKNfPVwFtwLewkPIrDQlNT
IpQHxNxaQhJKePQFwPuQlOEGNclxyeJSnB/hGO8//sKDHZBuVtVVIzD96JUabTUs
HGu1cXmseqSJgppweoo89ZLVCJ7y3Kmdqv716URLHiA7bC4cQcOb6630x1JlyOW8
9/fFLsE/GnnfsyIaJJBbVt3rA0VRj5rpxmivgke91zUBlXFhCidAUlQyxzxpkPk=
=U4N9
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: lzma support in `stable' has potential issues

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 2010/05/24 01:33, Garrett Cooper wrote:
 On Mon, May 24, 2010 at 12:37 AM, Xin LI delp...@delphij.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 2010/05/23 23:58, Garrett Cooper wrote:
 Hi Martin and Tim,
   I recently wiped off my Lenovo again to get a fresh install of 
 FreeBSD on it, and started out at 8.0-RELEASE (it's the media that I had on 
 hand at the time). Upgrading to 8-STABLE appears to be problematic though.
   On a few different occasions I ran into issues doing the following:

 Are you using make buildworld?  Presumbly they should have been created
 by mtree and I've verified that the corresponding change was merged
 properly.
 
 I've tried buildworld, as well as one one-off makes I showed above.

But how do you explain there is no tinderbox alert and there is no
reports about this?

 Only after I hacked things (just did simple mkdir(1)s and make
 installs) so that lzma could actually install and set WITHOUT_RESCUE
 (syscons was getting hung up on ncurses symbols), did buildworld
 actually go through.

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBCAAGBQJL+j8BAAoJEATO+BI/yjfBvZoH/juH0grqSoBNGNhNNFMiTq7+
ShyS1CxgDfSqJavQCPcFQJXGX8q2Rwv4ulJw/MTMhvID1MPVIlneD7DndefcVq4c
Cwe/oPlBShXRqT4KcgdZwzcVPCu1AFzuZ1bCbLnJdaHjRNxJx+0R4/c6MLCYy+U2
qLbCimHbLhxqwQ2PMbfmBO2HvM5Xx+c2uST2C7j+kvWWFcPxMoed4RPlVeBJOGXR
yGkEPmNMRKZu1neFei69BESdip8RjMsFh5zaousNdODW965Pe+m0c6RoF71P9oC/
WZjuWcUlbG2yKGLlMWT2N81fJQzyGDq2GIOwq29cMV68/kdZB+V+oI3HF2vEv1c=
=bKxr
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: lzma support in `stable' has potential issues

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/05/24 02:21, Jeremy Chadwick wrote:
 On Mon, May 24, 2010 at 01:55:29AM -0700, Xin LI wrote:
 On 2010/05/24 01:33, Garrett Cooper wrote:
 On Mon, May 24, 2010 at 12:37 AM, Xin LI delp...@delphij.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 2010/05/23 23:58, Garrett Cooper wrote:
 Hi Martin and Tim,
   I recently wiped off my Lenovo again to get a fresh install of 
 FreeBSD on it, and started out at 8.0-RELEASE (it's the media that I had 
 on hand at the time). Upgrading to 8-STABLE appears to be problematic 
 though.
   On a few different occasions I ran into issues doing the following:

 Are you using make buildworld?  Presumbly they should have been created
 by mtree and I've verified that the corresponding change was merged
 properly.

 I've tried buildworld, as well as one one-off makes I showed above.

 But how do you explain there is no tinderbox alert and there is no
 reports about this?
 
 Not to mention, I just did buildworld/installworld on one of our
 machines yesterday afternoon, after the lzma import, and didn't run into
 a single problem:
 
 $ ls -l /usr/include/lzma
 total 162
 -r--r--r--1 root  wheel 22112 23 May 12:10 base.h
 -r--r--r--1 root  wheel  2628 23 May 12:10 bcj.h
 -r--r--r--1 root  wheel 20032 23 May 12:10 block.h
 -r--r--r--1 root  wheel  4255 23 May 12:10 check.h
 -r--r--r--1 root  wheel 16341 23 May 12:10 container.h
 -r--r--r--1 root  wheel  1865 23 May 12:10 delta.h
 -r--r--r--1 root  wheel 16164 23 May 12:10 filter.h
 -r--r--r--1 root  wheel  2141 23 May 12:10 hardware.h
 -r--r--r--1 root  wheel 22807 23 May 12:10 index.h
 -r--r--r--1 root  wheel  3903 23 May 12:10 index_hash.h
 -r--r--r--1 root  wheel 13531 23 May 12:10 lzma.h
 -r--r--r--1 root  wheel  8357 23 May 12:10 stream_flags.h
 -r--r--r--1 root  wheel  6646 23 May 12:10 subblock.h
 -r--r--r--1 root  wheel  3497 23 May 12:10 version.h
 -r--r--r--1 root  wheel  6601 23 May 12:10 vli.h
 
 Could what Garrett is seeing be the result of one of the cvsup mirrors
 being out of date?

My guess would be src/etc/mtree tree not being populated properly...

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBCAAGBQJL+kZpAAoJEATO+BI/yjfBI9YIAKoERSJ00pbIFKMvOVgstoZn
ShauwpRwhHsCaUoxYfdTOGBe+3f5+GUXh5BhJJXTgkH7bOVkjocBVZImu4bVt37Y
XdBXjfOgD0DCdPcWuAHhGlHvatDhjtVAlhIj3LxSpcPmbXFJBMboBIkBcrX12tum
MHwD+OIiPtnLA89XwdefB4FX65mBdhvHA93+/vHzrbx7ixZnOMk+rWcb90hqWMUL
+4DxkPge8Rb5COW/9DMpQN7rdMz73r2XBOpumpCIDg5lV0aOJ7KminpIItaBB1IB
Vs4kW93n5BMhbKw2qwdtiz6BCZJAlDl7WYpMalg5Zw+3cXUynzcreL6xd20VmHk=
=7P4u
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Build world and zfs related commits

[Xin LI]

On Thu, May 20, 2010 at 12:12 AM, Matthias Gamsjager
mgamsja...@gmail.com wrote:
 Hello,

 Do I need to build world when a new ZFS related commit took place or
 is a build kernel enough?

 eg svn commit: r208334:

This one requires a full kernel+world build to fully benefit from the
improvement.

Most times if the change only covers sys/cdd/*/*.c, a kernel build is
sufficient, but to avoid mismatches we do advise a full build if you
are unsure.

Cheers,
-- 
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: [releng_6 tinderbox] failure on sparc64/sparc64

[Xin LI]

-prototypes -Wpointer-arith 
 -Winline -Wcast-qual  -fformat-extensions -std=c99  -nostdinc -I-  -I. 
 -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter 
 -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm 
 -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
 -include opt_global.h -fno-common -finline-limit=15000 --param 
 inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin 
 -mcmodel=medlow -msoft-float -ffreestanding -Werror  
 /src/sys/dev/ata/ata-all.c
 /src/sys/dev/ata/ata-all.c: In function `ata_device_ioctl':
 /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in 
 something not a structure or union
 /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in 
 something not a structure or union
 *** Error code 1

 Stop in /obj/sparc64/src/sys/LINT.
 *** Error code 1

 Stop in /src.
 *** Error code 1

 Stop in /src.
 TB --- 2010-05-04 03:36:09 - WARNING: /usr/bin/make returned exit code  1
 TB --- 2010-05-04 03:36:09 - ERROR: failed to build lint kernel
 TB --- 2010-05-04 03:36:09 - 2727.24 user 352.25 system 3272.16 real


 http://tinderbox.freebsd.org/tinderbox-releng_6-RELENG_6-sparc64-sparc64.full
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org




-- 
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ifconfig-i386 on 8-STABLE/amd64

[Xin LI]

Hi,

On Thu, Apr 15, 2010 at 2:59 PM, Jonathan Chen j...@chen.org.nz wrote:
    $ /compat/i386/sbin/ifconfig
    : flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST
        inet 192.168.1.10 netmask 0xff00 broadcast 192.168.1.255
        inet 192.168.1.11 netmask 0x broadcast 192.168.1.11
        inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255
        inet 192.168.2.10 netmask 0x broadcast 192.168.2.10
        inet 192.168.2.12 netmask 0x broadcast 192.168.2.12
        inet 127.0.0.1 netmask 0xff00
    ifconfig: ioctl(SIOCGIFINFO_IN6): Device not configured

 Why is the output from the 32-bit ifconfig severely mangled?

My understanding is that 32-bit management tools like ifconfig is not
supported on 64-bit FreeBSD.  Someone has to sit down and write a
compatibility layer for translating back and forth :(

Cheers,
--
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: DPMS broken on ThinkPad T43 since update for amd64 support

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 2010/03/18 08:33, Kevin Oberman wrote:
 Since the update of DPMS to support amd64 on March 2, it has broken
 rather badly on my ThinkPad T43 laptop. The problem showed up on
 8-stable built on March 3 and is still present after an update to stable
 of March 17.
 
 When in vty text mode, after the idle normal delay, the display blanks,
 but the backlight remains on, so the P in DPMS seems to be less than
 effective. At that point, the non-graphics display is dead. It never
 comes back when characters are entered. I can't get the display to come
 back without a reboot.
 
 I can, however, start X (and Gnome) and everything is fine. But
 switching back to any vty results in a blank screen.
 
 Any idea what happened and if there is a fix or workaround? Any data I
 can collect?
 
 The system is a uniprocessor Pentium-M:
 CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.01-MHz 686-class CPU)
   Origin = GenuineIntel  Id = 0x6d8  Stepping = 8
   
 Features=0xafe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,$
   Features2=0x180EST,TM2
   AMD Features=0x10NX
 
 My display is:
 vgap...@pci0:1:0:0: class=0x03 card=0x056e1014 chip=0x54601002 
 rev=0x00 hdr=0x00
 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
 device = 'Radeon X300 Mobility (M22) (RV370)'
 class  = display
 subclass   = VGA

Looks like that the CPU runs on i386 mode (doesn't support amd64?) and
when the screen was blank (with back light) the kernel is still alive
(as you can switch to X?

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBAgAGBQJLolx/AAoJEATO+BI/yjfB64UIAKxCMzcVfSoKugbL7xq5PkRC
Q7t8XwroLBbyk2R8RqDhxR6Cz4GgnEPvlhEBf0Rbvbo3mSDwhl1P1AXXVCq/NO83
dMuzZORRgjHBsWWn2PF+L+x6VmiNgJBtmhjW0lLo0f8nDbykKFmFWDCV5cE7QCfE
+6g1FxB3HVMpqyisWyOG6pZ2wAv1kSX6B+XXewrhXA/Zn3q/XUabFpzMXPHlGWZc
tlWqhY2TXSQULgCq9Be4ZCqrZnfmK1vf2JHxEfUHR8wNJMPIRxrypu40wgGZHiR7
4P5k8tjysF+ql5pqFyG/X8Y43TJAdK+mXatMp4HRnefjduBVkY1hd8lP/14/AB0=
=NVr/
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: I broke my SSH to jails after 7.2-8.0 src upgrade

[Xin LI]

Sounds like you have something wrong with devfs.rules in jail section?

On Mar 11, 2010 6:46 PM, Steve Bertrand st...@ibctech.ca wrote:

Hi all, please forgive the verbosity, but I wanted to include as much
detail as possible (without including config files) up front.

Summary: SSH works to the jail box host OS, but not to the jails themselves.

On a box that is dedicated to jails, I source upgraded from 7.2 to:

FreeBSD jail.eagle.ca 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Mar 11
13:22:59 EST 2010 r...@jail.eagle.ca:/usr/obj/usr/src/sys/JAIL  i386

I then proceeded to update each jail by `make installworld
DESTDIR=$JAILDIR', followed by (for most, but not quite all jails), a
`mergemaster -Uia'.

During the upgrade of the host OS, I know I rebooted here:

- after the `installkernel' phase of the host OS
- after the `installworld' phase of the host OS

...in between the above stages, I performed a `mergemaster -Uia'

Now, I can SSH into the host, but not the jails it contains. I have been
Googling for hours trying to figure this out. I've honestly exhausted
all of the possibilities I could find regarding the issue, even some
that dated back to the good ol' 4.x days.

It seemingly has something to do with tty/pts, but I just can't figure
it out.

When trying to SSH to a jail from the resident host OS:

%ssh acct.eagle.ca
Password:
PTY allocation request failed on channel 0
Warning: no access to tty (Bad file descriptor).
   Thus no job control in
this shell.

...and when I attempt SSH to a jail from a remote box, the connection
drops immediately after I enter the password. In both cases, the
following is logged into /var/log/messages within the jail host:

Mar 11 21:35:40 acct sshd[8175]: error: openpty: No such file or directory
Mar 11 21:35:40 acct sshd[8178]: error: session_pty_req: session 0 alloc
failed

A listing of the dev directory on the jail doesn't show pts (but it does
on the host OS):

%ll /usr/jails/acct/dev
total 1
dr-xr-xr-x  2 root  wheel   512 Mar 11 17:12 fd
lrwxr-xr-x  1 root  wheel14 Mar 11 17:12 log - ../var/run/log
crw-rw-rw-  1 root  wheel0,   7 Mar 11 21:11 null
crw-rw-rw-  1 root  wheel0,  12 Mar 11 12:10 random
lrwxr-xr-x  1 root  wheel 4 Mar 11 17:12 stderr - fd/2
lrwxr-xr-x  1 root  wheel 4 Mar 11 17:12 stdin - fd/0
lrwxr-xr-x  1 root  wheel 4 Mar 11 17:12 stdout - fd/1
lrwxr-xr-x  1 root  wheel 6 Mar 11 17:12 urandom - random
crw-rw-rw-  1 root  wheel0,   8 Mar 11 17:10 zero

...and I've tried to make Google-advised changes to the
/etc/defaults/devfs.rules file to no avail. ;)

All other services within the host OS and the jails are operating
perfectly. I'm just missing my tty's.

Can someone hit me with the cluebat, because I really feel that I've
missed something.

Thanks,

Steve
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org