Re: leapsecond file

[Andreas Ott]

On Sun, Aug 07, 2016 at 09:44:55PM -0700, Kevin Oberman wrote:
> On 11.0-BETA4 I have:
> > grep expires /var/db/ntpd.leap-seconds.list
> #File expires on:  1 Jun 2017
> 
> But I see what you do on 10.3-RELEASE.  Looks like the update has not made
> it into 10 (an I would guess 9).

The flaw is in the internal versioning of files, it does fetch the newer
file from IETF and puts it into /var/run/ntpd.leap-seconds.list, but
although the expiry is newer, the FreeBSD onboard source version claims
to be newer in the 'last update date in NTP timestamp format' line ...

FreeBSD 10.3-RELEASE-p7 onboard source is in /etc/ntp/leap-seconds,
which gets copied to /var/db/ntpd.leap-seconds.list. The fetch
IETF file downloads to /var/run/ntpd.leap-seconds.list .


[root@mon ~]# egrep -e Update\|expires\|^'#\$' /etc/ntp/leap-seconds
#   Last Update of leap second values:  31 Dec 2015
#$   3660508800
#   Updated through IERS Bulletin C 50
#   File expires on:  1 Jun 2016
[root@mon ~]# egrep -e Update\|expires\|^'#\$' /var/db/ntpd.leap-seconds.list
#   Last Update of leap second values:  31 Dec 2015
#$   3660508800
#   Updated through IERS Bulletin C 50
#   File expires on:  1 Jun 2016
[root@mon ~]# egrep -e Update\|expires\|^'#\$' /var/run/ntpd.leap-seconds.list
#   Last Update of leap second values:   5 January 2015
#$   3629404800
#   Updated through IERS Bulletin C51
#   File expires on:  28 December 2016
[root@mon ~]#

with the end result that the file from /var/run/ never gets moved to /var/db/ .
The 480.leapfile-ntpd used by periodic calls the same rc file fetch and
comparison.

-andreas
-- 
Andreas Ott   K6OTT   +1.408.431.8727   andr...@naund.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: FreeBSD 11 RC1 - no wifi

[Jan Kokemüller]

On 23.08.16 21:18, Stefan Wendler wrote:

Hi,

I have upgraded from FreeBSD 10.3 to 11 RC1 on my Lenovo W450 with Intel
Centrino Ultimate-N 6300

After upgrade and a last reboot the iwn driver gets loaded but no iwn0
interface pops up. Doing a 'service netif restart' crashes the machine
and a core is written.


It's probably this bug:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211689#c4

I've attached a patch there that fixes this issue for me.

-Jan
___
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: Benchmarks results for FreeBSD 11

[Erich Dollansky]

Hi,

On Tue, 23 Aug 2016 13:01:59 +0200
Lars Engels  wrote:

> On Mon, Aug 22, 2016 at 03:02:15PM +0300, Slawa Olhovchenkov wrote:
> > On Mon, Aug 22, 2016 at 12:14:23PM +0200, Lars Engels wrote:
> >   
> > > On Mon, Aug 22, 2016 at 11:48:46AM +0200, Andrea Brancatelli
> > > wrote:  
> > > > Il 2016-08-21 08:45 Erich Dollansky ha scritto:
> > > >   
> > > > > I am sure that some know of this site:
> > > > > 
> > > > > http://www.phoronix.com/scan.php?page=article=2bsd-7linux-bench=4
> > > > > 
> > > > > I wonder about the results for FreeBSD. As I do not have 11
> > > > > on my machines, a stupid question. Are there still some
> > > > > debugging aids enabled in 11?   
> > > > > They're off in those versions, but did note compiler (and
> > > > > compiler args) differences between within most tests (See
> > > > > attachments) as you mentioned.  
> > > >  the benchmark then compares the off-the-shelve distributions. 
> > > > 
> > > > Excuse me, as a casual reader of the list, I don't get this
> > > > "critique". 
> > > > 
> > > > I never recompile my installations, I just use them from the
> > > > installation CD (as probably 90% of the rest of the world), so
> > > > I don't get what is wrong with the approach of comparing an
> > > > out-of-the-box FreeBSD 11 with an out-of-the-box Ubuntu
> > > > whatever. 
> > > > 
> > > > If FreeBSD 11 "out-the-box" performs slow because the standard
> > > > compilers options aren't good it's not a problem with the
> > > > benchmarking platform but with the default CD compiling
> > > > options. 
> > > > 
> > > > Am I getting it wrong?   
> > > 
> > > The problem here is that Phoronix took a Beta version of FreeBSD
> > > 11. Beta versions have a lot of debugging (malloc, invariants,
> > > witness) options enabled which make it significantly slower than
> > > release versions. This is even obviously when you run a Beta as a
> > > desktop. It just feels much slower.  
> > 
> > No.
> > All debugs in amd64 is off at time of BETA.  
> 
> Ok, then FreeBSD is just slower...

you missed the main point. The test was done with applications compiled
with unknown options. If you want to find out the impact of an
operating system on you application you have to use the same compiler
with the same options on all platforms. Basically, it was a compiler
test named operating system benchmark.

Erich
___
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: FreeBSD 11 RC1 - no wifi

[Kurt Jaeger]

Hi!

> After upgrade and a last reboot the iwn driver gets loaded but no iwn0
> interface pops up.

In 11, the hardware interfaces no longer appear.

They still can be found with

sysctl net.wlan.devices

> Doing a 'service netif restart' crashes the machine
> and a core is written.

The crash should not happen.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: FreeBSD 11 RC1 - no wifi

[Stefan Wendler]

EDIT: It's a W 530, not a 540

On 08/23/2016 21:18, Stefan Wendler wrote:
> Hi,
> 
> I have upgraded from FreeBSD 10.3 to 11 RC1 on my Lenovo W450 with Intel
> Centrino Ultimate-N 6300
> 
> After upgrade and a last reboot the iwn driver gets loaded but no iwn0
> interface pops up. Doing a 'service netif restart' crashes the machine
> and a core is written.
> 
> I have attached the output of the dmesg command. If somebody needs the
> core, I can upload it somewhere and give you the download link.
> 
> Please tell me how I can help you guys.
> 
> Cheers,
> Stefan
> 
> 
> 
> ___
> freebsd-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-- 
Stefan Wendler
stefan.wend...@tngtech.com
+49 (0) 176 -  2438 3835
Senior Consultant

TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterföhring
Geschäftsführer: Henrik Klagges, Christoph Stock, Dr. Robert Dahlke
Sitz: Unterföhring * Amtsgericht München * HRB 135082
___
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 11 RC1 - no wifi

[Stefan Wendler]

Hi,

I have upgraded from FreeBSD 10.3 to 11 RC1 on my Lenovo W450 with Intel
Centrino Ultimate-N 6300

After upgrade and a last reboot the iwn driver gets loaded but no iwn0
interface pops up. Doing a 'service netif restart' crashes the machine
and a core is written.

I have attached the output of the dmesg command. If somebody needs the
core, I can upload it somewhere and give you the download link.

Please tell me how I can help you guys.

Cheers,
Stefan
tun0: link state changed to DOWN
wlan0: link state changed to DOWN
lagg0: link state changed to DOWN
wlan0: link state changed to UP
lagg0: link state changed to UP
pid 97228 (wine), uid 1001: exited on signal 10 (core dumped)
wlan0: link state changed to DOWN
lagg0: link state changed to DOWN
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 0 0 0 done
All buffers synced.
Uptime: 10h16m41s
GEOM_ELI: Device ada1p1.eli destroyed.
GEOM_ELI: Detached ada1p1.eli on last close.
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.3-RELEASE-p4 #0: Sat May 28 12:23:44 UTC 2016
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz (2394.61-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
  
Features=0xbfebfbff
  
Features2=0x7fbae3bf
  AMD Features=0x28100800
  AMD Features2=0x1
  Structured Extended Features=0x281
  XSAVE Features=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 34359738368 (32768 MB)
avail memory = 32887021568 (31363 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
 cpu4 (AP): APIC ID:  4
 cpu5 (AP): APIC ID:  5
 cpu6 (AP): APIC ID:  6
 cpu7 (AP): APIC ID:  7
random:  initialized
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
cryptosoft0:  on motherboard
aesni0:  on motherboard
acpi0:  on motherboard
acpi_ec0:  port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
cpu4:  on acpi0
cpu5:  on acpi0
cpu6:  on acpi0
cpu7:  on acpi0
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 550
atrtc0:  port 0x70-0x71 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
acpi_lid0:  on acpi0
acpi_button0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  irq 16 at device 1.0 on pci0
pci1:  on pcib1
vgapci0:  port 0x5000-0x507f mem 
0xf200-0xf2ff,0xe000-0xefff,0xf000-0xf1ff irq 16 at 
device 0.0 on pci1
nvidia0:  on vgapci0
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: Boot video device
hdac0:  mem 0xf300-0xf3003fff irq 17 at 
device 0.1 on pci1
xhci0:  mem 0xf532-0xf532 irq 
16 at device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
xhci0: Port routing mask set to 0x
usbus0 on xhci0
pci0:  at device 22.0 (no driver attached)
em0:  port 0x6040-0x605f mem 
0xf530-0xf531,0xf533b000-0xf533bfff irq 20 at device 25.0 on pci0
em0: Using an MSI interrupt
em0: Ethernet address: 3c:97:0e:c3:c9:d0
ehci0:  mem 0xf533a000-0xf533a3ff irq 
16 at device 26.0 on pci0
usbus1: EHCI version 1.0
usbus1 on ehci0
hdac1:  mem 0xf533-0xf5333fff irq 22 at 
device 27.0 on pci0
pcib2:  irq 16 at device 28.0 on pci0
pci2:  on pcib2
sdhci_pci0:  mem 0xf4a01000-0xf4a010ff irq 16 at device 0.0 
on pci2
sdhci_pci0: 1 slot(s) allocated
pci2:  at device 0.3 (no driver attached)
pcib3:  irq 17 at device 28.1 on pci0
pci3:  on pcib3
iwn0:  mem 0xf490-0xf4901fff irq 17 at 
device 0.0 on pci3
pcib4:  irq 18 

Re: kern.proc.pathname failure while booting from zfs

[Frederic Chardon]

2016-08-23 19:35 GMT+02:00 Frederic Chardon :
> 2016-08-23 9:35 GMT+02:00 Konstantin Belousov :
>> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote:
>>> Le 20 ao??t 2016 22:03, "Frederic Chardon"  a
>>> ??crit :
>>> >
>>> > Hi
>>> >
>>> > I see a strange interaction between zfs on root and kern.proc.pathname
>>> > on my laptop. Whenever I try to use gcore it fails with:
>>> > gcore 1023
>>> > gcore: kern.proc.pathname failure
>>> >
>>> > However, gcore /usr/local/bin/zsh 1023 is working properly.
>>> >
>>> > I made some tests booting from usb stick (fresh installworld, no
>>> > src.conf, no make.conf, GENERIC kernel)
>>> > What works: having / on ufs and importing a zfs pool later on.
>>> > What doesn't: having / on zfs, whatever the settings for checksum,
>>> > compression, or normalization.
>>> >
>>> > Both 11-stable and 12-current behave this way. Current from may-june
>>> > worked properly.
>>> > adb, chromium and virtualbox as well stopped working at approximately
>>> > the same time, however I don't know if it is linked ("truss -f adb
>>> > start-server" shows that garbage is passed to execl after forking).
>>> >
>>> > Any idea what's going on? Does anybody else see this?
>>> >
>>> > Thanks!
>>>
>>> Nobody else have this problem? I reinstalled the system from scratch and
>>> still gcore fails with the same error, even in single user mode.
>>
>> Do you have a property on your root fs which forces it to ignore case in
>> the file names ?
>
> No. I do have normalization set to formC though. I observed the same
> behavior with the property unset (in fact, with no property set to
> anything but default as well).
> If I boot from usb stick and import the pool afterwards it works properly.
>
> zpool get all zbase
> NAME   PROPERTY   VALUE  SOURCE
> zbase  size   9,94G  -
> zbase  capacity   43%-
> zbase  altroot-  default
> zbase  health ONLINE -
> zbase  guid   8964242380523899513default
> zbase  version-  default
> zbase  bootfs zbase/bootenv/11-STABLElocal
> zbase  delegation on default
> zbase  autoreplaceoffdefault
> zbase  cachefile  -  default
> zbase  failmode   wait   default
> zbase  listsnapshots  offdefault
> zbase  autoexpand offdefault
> zbase  dedupditto 0  default
> zbase  dedupratio 1.00x  -
> zbase  free   5,65G  -
> zbase  allocated  4,29G  -
> zbase  readonly   off-
> zbase  comment-  default
> zbase  expandsize -  -
> zbase  freeing0  default
> zbase  fragmentation  41%-
> zbase  leaked 0  default
> zbase  feature@async_destroy  enabledlocal
> zbase  feature@empty_bpobjactive local
> zbase  feature@lz4_compress   active local
> zbase  feature@multi_vdev_crash_dump  enabledlocal
> zbase  feature@spacemap_histogram active local
> zbase  feature@enabled_txgactive local
> zbase  feature@hole_birth active local
> zbase  feature@extensible_dataset enabledlocal
> zbase  feature@embedded_data  active local
> zbase  feature@bookmarks  enabledlocal
> zbase  feature@filesystem_limits  enabledlocal
> zbase  feature@large_blocks   enabledlocal
> zbase  feature@sha512 enabledlocal
> zbase  feature@skein  enabledlocal
>
>
> zfs get all zbase/bootenv/11-STABLE
> NAME PROPERTY  VALUE 
> SOURCE
> zbase/bootenv/11-STABLE  type  filesystem-
> zbase/bootenv/11-STABLE  creation

Re: FreeBSD 11.0-RC1 regression with regard to mouse integration in VirtualBox 5.1.4

[Karl Denninger]

On 8/23/2016 12:48, David Boyd wrote:
> Using FreeBSD 10.3-RELEASE-p6 with virtualbox-guest-additions 5.0.26 on
> VirtualBox 5.1.4 (CentOS EL7 host) as a baseline I didn't experience any
> difficulties.
>
> After fresh install of FreeBSD 11.0-RC1 with virtualbox-guest-additions
> 5.0.26 on VirtualBox 5.1.4 (CentOS EL7 host) mouse integration is
> missing.
>
> I have time and resources to test any changes you have to suggest.
>
> Thanks.
>
Does the mouse normally attach as what appears to be a USB port?  If so
the problem is likely here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211884

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

FreeBSD 11.0-RC1 regression with regard to mouse integration in VirtualBox 5.1.4

[David Boyd]

Using FreeBSD 10.3-RELEASE-p6 with virtualbox-guest-additions 5.0.26 on
VirtualBox 5.1.4 (CentOS EL7 host) as a baseline I didn't experience any
difficulties.

After fresh install of FreeBSD 11.0-RC1 with virtualbox-guest-additions
5.0.26 on VirtualBox 5.1.4 (CentOS EL7 host) mouse integration is
missing.

I have time and resources to test any changes you have to suggest.

Thanks.

___
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: upgrading from 10.0 to 10.3 problem

[Peter Lai]

> Hello. I tried to upgrade from 10.0-RELEASE: # freebsd-update -r 10.3-RELEASE 
> upgrade
> ...
> # freebsd-update install
> ...
> # reboot
> ...
> # freebsd-update install
> Installing updates...Segmentation fault (core dumped)
> Segmentation fault (core dumped)
> Segmentation fault (core dumped)
> Segmentation fault (core dumped)
> Segmentation fault (core dumped)
> Segmentation fault (core dumped)
> Segmentation fault (core dumped)
> Segmentation fault (core dumped) Now I have:
> # freebsd-version -ku
> 10.3-RELEASE-p4
> 10.0-RELEASE It's not looking good. How to fix? PS. In /var/log/messages I 
> see "(gunzip), uid 0: exited on signal 11"
> And yes:
> # gunzip
> Segmentation fault (core dumped)

Hi Sergey:

I ran into this problem the week before you did:
https://lists.freebsd.org/pipermail/freebsd-stable/2016-July/085115.html
Because just about all of the binaries were trashed (including /lib,
/[s]bin, /usr/lib, /usr/[s]bin files were truncated to 0), I had to
/rescue/nc > base.txz (where I fetched base.txz from the ftp site in
the 10.3-RELEASE distribution), then /rescue/tar -zxvf base.txz into a
directory, then tar | tar each of /lib and so on to get my binaries
back (apparently /rescue does not have a statically compiled cpio).

After sending the above to the mailing list I went ahead and replaced
the kernel that the broken freebsd-update install installed with the
one from 10.3-RELEASE (from the distribution base.txz:boot/kernel),
which made the system entirely binary 10.3-RELEASE then I was able to
freebsd-update to FreeBSD-10.3-RELEASE-p6 with no problems. Note that
the initial freebsd-update from 10.0 also severely trashed my /etc, I
had to restore master.passwd and friends! (many of /etc files were
also truncated to 0), even though the merge process seemed to complete
ok before the broken freebsd-update install.
___
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: kern.proc.pathname failure while booting from zfs

[Frederic Chardon]

2016-08-23 9:35 GMT+02:00 Konstantin Belousov :
> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote:
>> Le 20 ao??t 2016 22:03, "Frederic Chardon"  a
>> ??crit :
>> >
>> > Hi
>> >
>> > I see a strange interaction between zfs on root and kern.proc.pathname
>> > on my laptop. Whenever I try to use gcore it fails with:
>> > gcore 1023
>> > gcore: kern.proc.pathname failure
>> >
>> > However, gcore /usr/local/bin/zsh 1023 is working properly.
>> >
>> > I made some tests booting from usb stick (fresh installworld, no
>> > src.conf, no make.conf, GENERIC kernel)
>> > What works: having / on ufs and importing a zfs pool later on.
>> > What doesn't: having / on zfs, whatever the settings for checksum,
>> > compression, or normalization.
>> >
>> > Both 11-stable and 12-current behave this way. Current from may-june
>> > worked properly.
>> > adb, chromium and virtualbox as well stopped working at approximately
>> > the same time, however I don't know if it is linked ("truss -f adb
>> > start-server" shows that garbage is passed to execl after forking).
>> >
>> > Any idea what's going on? Does anybody else see this?
>> >
>> > Thanks!
>>
>> Nobody else have this problem? I reinstalled the system from scratch and
>> still gcore fails with the same error, even in single user mode.
>
> Do you have a property on your root fs which forces it to ignore case in
> the file names ?

No. I do have normalization set to formC though. I observed the same
behavior with the property unset (in fact, with no property set to
anything but default as well).
If I boot from usb stick and import the pool afterwards it works properly.

zpool get all zbase
NAME   PROPERTY   VALUE  SOURCE
zbase  size   9,94G  -
zbase  capacity   43%-
zbase  altroot-  default
zbase  health ONLINE -
zbase  guid   8964242380523899513default
zbase  version-  default
zbase  bootfs zbase/bootenv/11-STABLElocal
zbase  delegation on default
zbase  autoreplaceoffdefault
zbase  cachefile  -  default
zbase  failmode   wait   default
zbase  listsnapshots  offdefault
zbase  autoexpand offdefault
zbase  dedupditto 0  default
zbase  dedupratio 1.00x  -
zbase  free   5,65G  -
zbase  allocated  4,29G  -
zbase  readonly   off-
zbase  comment-  default
zbase  expandsize -  -
zbase  freeing0  default
zbase  fragmentation  41%-
zbase  leaked 0  default
zbase  feature@async_destroy  enabledlocal
zbase  feature@empty_bpobjactive local
zbase  feature@lz4_compress   active local
zbase  feature@multi_vdev_crash_dump  enabledlocal
zbase  feature@spacemap_histogram active local
zbase  feature@enabled_txgactive local
zbase  feature@hole_birth active local
zbase  feature@extensible_dataset enabledlocal
zbase  feature@embedded_data  active local
zbase  feature@bookmarks  enabledlocal
zbase  feature@filesystem_limits  enabledlocal
zbase  feature@large_blocks   enabledlocal
zbase  feature@sha512 enabledlocal
zbase  feature@skein  enabledlocal


zfs get all zbase/bootenv/11-STABLE
NAME PROPERTY  VALUE SOURCE
zbase/bootenv/11-STABLE  type  filesystem-
zbase/bootenv/11-STABLE  creation  sam. août 20 13:07 2016  -
zbase/bootenv/11-STABLE  used  4,23G -
zbase/bootenv/11-STABLE  available 5,34G -
zbase/bootenv/11-STABLE  

Re: Problems with piped tar

[Gary Palmer]

On Tue, Aug 23, 2016 at 02:27:46PM +0200, Gerhard Schmidt wrote:
> Am 23.08.2016 um 13:31 schrieb Gary Palmer:
> > On Tue, Aug 23, 2016 at 09:35:12AM +0200, Gerhard Schmidt wrote:
> >> Am 23.08.2016 um 09:18 schrieb Daniel Braniss:
> >>>
>  On 23 Aug 2016, at 10:06, Gerhard Schmidt  wrote:
> 
>  Hi,
> 
>  i'm quite often use tar to copy files using
> 
>  tar cf - /some/dir | (cd /dest/dir; tar xvvf - )
> >>> the ???new??? way:
> >>>   tar cf - /some/dir | tar xvvd - -C /dest/dir
> >>> which of course does not explain way your version hangs, but this one is 
> >>> cleaner, and btw, don???t
> >>> include /.
> >>
> >> that's very strange. It's working, but doesn't solve another related
> >> problem. When i pipe the tar thru nc a have the same problem as my
> >> version. And it's no difference if there is a tar c an the receiving end
> >> of nc or just a '> file.tar'
> > 
> > Is the sending side using nc -N ?  If not, the sending socket is not being
> > shut down.
> 
> Is that something new? Because it worked on freebsd9 without the -N option.

Yes.  It was introduced in 10.x for some reason.  It caught me out a few
times

> The problem seams to be that tar c doesn't terminate after the last File
> is send. I think it send the EOF (because nc -N terminates and therefor
> terminates the pipe) but the tar process doesn't terminate.

nc -N will terminate when the input pipe is closed AFAIK (i.e. the
process feeding into the pipe exits)

I presume you mean the tar process on the receiving side doesn't 
terminate?  Most odd.  I haven't tried tar across nc in a while,
I normally use dd or zfs send/receive

Regards,

Gary
___
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: Problems with piped tar

[Gerhard Schmidt]

Am 23.08.2016 um 13:31 schrieb Gary Palmer:
> On Tue, Aug 23, 2016 at 09:35:12AM +0200, Gerhard Schmidt wrote:
>> Am 23.08.2016 um 09:18 schrieb Daniel Braniss:
>>>
 On 23 Aug 2016, at 10:06, Gerhard Schmidt  wrote:

 Hi,

 i'm quite often use tar to copy files using

 tar cf - /some/dir | (cd /dest/dir; tar xvvf - )
>>> the ???new??? way:
>>> tar cf - /some/dir | tar xvvd - -C /dest/dir
>>> which of course does not explain way your version hangs, but this one is 
>>> cleaner, and btw, don???t
>>> include /.
>>
>> that's very strange. It's working, but doesn't solve another related
>> problem. When i pipe the tar thru nc a have the same problem as my
>> version. And it's no difference if there is a tar c an the receiving end
>> of nc or just a '> file.tar'
> 
> Is the sending side using nc -N ?  If not, the sending socket is not being
> shut down.

Is that something new? Because it worked on freebsd9 without the -N option.

The problem seams to be that tar c doesn't terminate after the last File
is send. I think it send the EOF (because nc -N terminates and therefor
terminates the pipe) but the tar process doesn't terminate.

Estartu

-- 
-
Gerhard Schmidt   | E-Mail: schm...@ze.tum.de
TU-München| Jabber: esta...@ze.tum.de
WWW & Online Services |
Tel: 089/289-25270|
Fax: 089/289-25257| PGP-Publickey auf Anfrage

___
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: Problems with piped tar

[Gary Palmer]

On Tue, Aug 23, 2016 at 09:35:12AM +0200, Gerhard Schmidt wrote:
> Am 23.08.2016 um 09:18 schrieb Daniel Braniss:
> > 
> >> On 23 Aug 2016, at 10:06, Gerhard Schmidt  wrote:
> >>
> >> Hi,
> >>
> >> i'm quite often use tar to copy files using
> >>
> >> tar cf - /some/dir | (cd /dest/dir; tar xvvf - )
> > the ???new??? way:
> > tar cf - /some/dir | tar xvvd - -C /dest/dir
> > which of course does not explain way your version hangs, but this one is 
> > cleaner, and btw, don???t
> > include /.
> 
> that's very strange. It's working, but doesn't solve another related
> problem. When i pipe the tar thru nc a have the same problem as my
> version. And it's no difference if there is a tar c an the receiving end
> of nc or just a '> file.tar'

Is the sending side using nc -N ?  If not, the sending socket is not being
shut down.

Regards,

Gary
___
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: Problems while reading from /dev/cd0

[Gerhard Schmidt]

Am 23.08.2016 um 13:12 schrieb Dimitry Andric:
> On 23 Aug 2016, at 08:50, Gerhard Schmidt  wrote:
>>
>> I'm having some very curios Problems while reading from an BD-R recorded
>> as a tar directly on the disk without a filesystem.
>>
>> When i try to read the Disk via 'tar tvvf /dev/cd0'
>>
>> i get the following output
>>
>> -rw-r--r--  0 root   wheel 5793264611  1 Jan  2015 file1.db
>> tar: Error reading '/dev/cd0'
>> Archive Format: POSIX ustar format,  Compression: none
>> tar: Error exit delayed from previous errors.
>>
>> reading the whole file via 'dd if=/dev/cd0 of=backup.tar bs=2048' and
>> than 'tar tvvf backup.tar' the file is read without a hitch. So the data
>> on the disk is OK but can't be read directly by tar.
>>
>> if i try the dd without the bs=2048 i get
>>
>> dd: /dev/cd0: Invalid argument
>> 0+0 records in
>> 0+0 records out
>> 0 bytes transferred in 0.000115 secs (0 bytes/sec)
>>
>> So there is a problem reading anything other than 2048 byte blocks from
>> a Disk.
> 
> Have you tried tar's -b option, to set the block size 2048?  Maybe that
> will help.

It does partially. extracting the files work but testing the archive
with tar t fails.

Estartu


-- 
--
Gerhard Schmidt| E-Mail: schm...@ze.tum.de
Technische Universität München | Jabber: esta...@ze.tum.de
WWW & Online Services  |
Tel: +49 89 289-25270  | PGP-PublicKey
Fax: +49 89 289-25257  | on request
___
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: Problems while reading from /dev/cd0

[Dimitry Andric]

On 23 Aug 2016, at 08:50, Gerhard Schmidt  wrote:
> 
> I'm having some very curios Problems while reading from an BD-R recorded
> as a tar directly on the disk without a filesystem.
> 
> When i try to read the Disk via 'tar tvvf /dev/cd0'
> 
> i get the following output
> 
> -rw-r--r--  0 root   wheel 5793264611  1 Jan  2015 file1.db
> tar: Error reading '/dev/cd0'
> Archive Format: POSIX ustar format,  Compression: none
> tar: Error exit delayed from previous errors.
> 
> reading the whole file via 'dd if=/dev/cd0 of=backup.tar bs=2048' and
> than 'tar tvvf backup.tar' the file is read without a hitch. So the data
> on the disk is OK but can't be read directly by tar.
> 
> if i try the dd without the bs=2048 i get
> 
> dd: /dev/cd0: Invalid argument
> 0+0 records in
> 0+0 records out
> 0 bytes transferred in 0.000115 secs (0 bytes/sec)
> 
> So there is a problem reading anything other than 2048 byte blocks from
> a Disk.

Have you tried tar's -b option, to set the block size 2048?  Maybe that
will help.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Problems with piped tar

[Arrigo Marchiori via freebsd-stable]

Hello,

On Tue, Aug 23, 2016 at 09:35:12AM +0200, Gerhard Schmidt wrote:

> Am 23.08.2016 um 09:18 schrieb Daniel Braniss:
> > 
> >> On 23 Aug 2016, at 10:06, Gerhard Schmidt  wrote:
> >>
> >> Hi,
> >>
> >> i'm quite often use tar to copy files using
> >>
> >> tar cf - /some/dir | (cd /dest/dir; tar xvvf - )
> > the ‘new’ way:
> > tar cf - /some/dir | tar xvvd - -C /dest/dir
> > which of course does not explain way your version hangs, but this one is 
> > cleaner, and btw, don’t
> > include /.
> 
> that's very strange. It's working, but doesn't solve another related
> problem. When i pipe the tar thru nc a have the same problem as my
> version. And it's no difference if there is a tar c an the receiving end
> of nc or just a '> file.tar'

Maybe you are not invoking nc(1) with the -N option?

From the manual page:

 -N  shutdown(2) the network socket after EOF on the input.  Some
 servers require this to finish their work.

I hope this helps.

Regards,
-- 
rigo

http://rigo.altervista.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: Benchmarks results for FreeBSD 11

[Lars Engels]

On Mon, Aug 22, 2016 at 03:02:15PM +0300, Slawa Olhovchenkov wrote:
> On Mon, Aug 22, 2016 at 12:14:23PM +0200, Lars Engels wrote:
> 
> > On Mon, Aug 22, 2016 at 11:48:46AM +0200, Andrea Brancatelli wrote:
> > > Il 2016-08-21 08:45 Erich Dollansky ha scritto:
> > > 
> > > > I am sure that some know of this site:
> > > > 
> > > > http://www.phoronix.com/scan.php?page=article=2bsd-7linux-bench=4
> > > > 
> > > > I wonder about the results for FreeBSD. As I do not have 11 on my 
> > > > machines, a stupid question. Are there still some debugging aids 
> > > > enabled in 11?   
> > > > They're off in those versions, but did note compiler (and compiler
> > > > args) differences between within most tests (See attachments) as you
> > > > mentioned.
> > >  the benchmark then compares the off-the-shelve distributions. 
> > > 
> > > Excuse me, as a casual reader of the list, I don't get this "critique". 
> > > 
> > > I never recompile my installations, I just use them from the
> > > installation CD (as probably 90% of the rest of the world), so I don't
> > > get what is wrong with the approach of comparing an out-of-the-box
> > > FreeBSD 11 with an out-of-the-box Ubuntu whatever. 
> > > 
> > > If FreeBSD 11 "out-the-box" performs slow because the standard compilers
> > > options aren't good it's not a problem with the benchmarking platform
> > > but with the default CD compiling options. 
> > > 
> > > Am I getting it wrong? 
> > 
> > The problem here is that Phoronix took a Beta version of FreeBSD 11.
> > Beta versions have a lot of debugging (malloc, invariants, witness)
> > options enabled which make it significantly slower than release
> > versions. This is even obviously when you run a Beta as a desktop. It
> > just feels much slower.
> 
> No.
> All debugs in amd64 is off at time of BETA.

Ok, then FreeBSD is just slower...


pgpHkCIbmimuX.pgp
Description: PGP signature

Re: Benchmarks results for FreeBSD 11

[George Mitchell]

On 08/23/16 02:32, Erich Dollansky wrote:
> Hi,
> 
> On Mon, 22 Aug 2016 03:22:35 +
> Kubilay Kocak  wrote:
> 
>> On Mon, 22 Aug 2016, 11:31 AM Mark Linimon 
>> wrote:
>>
>>> On Mon, Aug 22, 2016 at 09:57:24AM +1000, Dewayne Geraghty wrote:  
 unless knowledgable people respond publicly and/or in the phoronix
 forums [...] this interpretation of reality will be fixed in
 decision- makers' minds and consequently the uptake (and support)
 of FreeBSD.  
>>>
>>> IIRC this has been done before and hasn't really been productive.
>>> OTOH I don't recall the details.
>>>
>>> FreeBSD hasn't had a benchmarking guru since Kris Kennaway retired
>>> from working on FreeBSD.  
>>
>>
>> Michael has reached out off-list (thanks!) If anyone else is
>> interested, I'd be happy to create a dedicated IRC channel on
>> freenode to widen and focus the freebsd performance discussion net
>> and doc any outcomes/notes in the FreeBSD Wiki.
>>
> this is good. So, how can we help him to get things straight the next
> time?
> 
> Erich
> ___
> 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"
> 
Off-the-wall note: has anyone tried comparing SCHED_ULE to SCHED_BSD?
-- George
___
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: Problems with piped tar

[Daniel Braniss]

> On 23 Aug 2016, at 10:35, Gerhard Schmidt  wrote:
> 
> Am 23.08.2016 um 09:18 schrieb Daniel Braniss:
>> 
>>> On 23 Aug 2016, at 10:06, Gerhard Schmidt  wrote:
>>> 
>>> Hi,
>>> 
>>> i'm quite often use tar to copy files using
>>> 
>>> tar cf - /some/dir | (cd /dest/dir; tar xvvf - )
>> the ‘new’ way:
>>  tar cf - /some/dir | tar xvvd - -C /dest/dir
>> which of course does not explain way your version hangs, but this one is 
>> cleaner, and btw, don’t
>> include /.
> 
> that's very strange. It's working, but doesn't solve another related
> problem. When i pipe the tar thru nc a have the same problem as my
> version. And it's no difference if there is a tar c an the receiving end
> of nc or just a '> file.tar’
> 

try with different shells. (sh/bash/csh/zsh/…)


> Regards
>   Estartu
> 
> 
> 
> -- 
> -
> Gerhard Schmidt   | E-Mail: schm...@ze.tum.de 
> TU-München  | Jabber: esta...@ze.tum.de 
> WWW & Online Services |
> Tel: 089/289-25270|
> Fax: 089/289-25257| PGP-Publickey auf Anfrage

___
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: Problems with piped tar

[Gerhard Schmidt]

Am 23.08.2016 um 09:18 schrieb Daniel Braniss:
> 
>> On 23 Aug 2016, at 10:06, Gerhard Schmidt  wrote:
>>
>> Hi,
>>
>> i'm quite often use tar to copy files using
>>
>> tar cf - /some/dir | (cd /dest/dir; tar xvvf - )
> the ‘new’ way:
>   tar cf - /some/dir | tar xvvd - -C /dest/dir
> which of course does not explain way your version hangs, but this one is 
> cleaner, and btw, don’t
> include /.

that's very strange. It's working, but doesn't solve another related
problem. When i pipe the tar thru nc a have the same problem as my
version. And it's no difference if there is a tar c an the receiving end
of nc or just a '> file.tar'

Regards
   Estartu



-- 
-
Gerhard Schmidt   | E-Mail: schm...@ze.tum.de
TU-München| Jabber: esta...@ze.tum.de
WWW & Online Services |
Tel: 089/289-25270|
Fax: 089/289-25257| PGP-Publickey auf Anfrage

___
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: kern.proc.pathname failure while booting from zfs

[Konstantin Belousov]

On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote:
> Le 20 ao??t 2016 22:03, "Frederic Chardon"  a
> ??crit :
> >
> > Hi
> >
> > I see a strange interaction between zfs on root and kern.proc.pathname
> > on my laptop. Whenever I try to use gcore it fails with:
> > gcore 1023
> > gcore: kern.proc.pathname failure
> >
> > However, gcore /usr/local/bin/zsh 1023 is working properly.
> >
> > I made some tests booting from usb stick (fresh installworld, no
> > src.conf, no make.conf, GENERIC kernel)
> > What works: having / on ufs and importing a zfs pool later on.
> > What doesn't: having / on zfs, whatever the settings for checksum,
> > compression, or normalization.
> >
> > Both 11-stable and 12-current behave this way. Current from may-june
> > worked properly.
> > adb, chromium and virtualbox as well stopped working at approximately
> > the same time, however I don't know if it is linked ("truss -f adb
> > start-server" shows that garbage is passed to execl after forking).
> >
> > Any idea what's going on? Does anybody else see this?
> >
> > Thanks!
> 
> Nobody else have this problem? I reinstalled the system from scratch and
> still gcore fails with the same error, even in single user mode.

Do you have a property on your root fs which forces it to ignore case in
the file names ?
___
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: kern.proc.pathname failure while booting from zfs

[Frederic Chardon]

Le 20 août 2016 22:03, "Frederic Chardon"  a
écrit :
>
> Hi
>
> I see a strange interaction between zfs on root and kern.proc.pathname
> on my laptop. Whenever I try to use gcore it fails with:
> gcore 1023
> gcore: kern.proc.pathname failure
>
> However, gcore /usr/local/bin/zsh 1023 is working properly.
>
> I made some tests booting from usb stick (fresh installworld, no
> src.conf, no make.conf, GENERIC kernel)
> What works: having / on ufs and importing a zfs pool later on.
> What doesn't: having / on zfs, whatever the settings for checksum,
> compression, or normalization.
>
> Both 11-stable and 12-current behave this way. Current from may-june
> worked properly.
> adb, chromium and virtualbox as well stopped working at approximately
> the same time, however I don't know if it is linked ("truss -f adb
> start-server" shows that garbage is passed to execl after forking).
>
> Any idea what's going on? Does anybody else see this?
>
> Thanks!

Nobody else have this problem? I reinstalled the system from scratch and
still gcore fails with the same error, even in single user mode.
___
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: Problems with piped tar

[Daniel Braniss]

> On 23 Aug 2016, at 10:18, Daniel Braniss  wrote:
> 
>> 
>> On 23 Aug 2016, at 10:06, Gerhard Schmidt > > wrote:
>> 
>> Hi,
>> 
>> i'm quite often use tar to copy files using
>> 
>> tar cf - /some/dir | (cd /dest/dir; tar xvvf - )
> the ‘new’ way:
>   tar cf - /some/dir | tar xvvd - -C /dest/dir
s/xvvd/xvvf/

> which of course does not explain way your version hangs, but this one is 
> cleaner, and btw, don’t
> include /.
> 
>> 
>> the files are copied without a problem but the reading tar never
>> terminates and so the whole command never terminates.
>> 
>> This is new since FreeBSD 10.
>> 
>> Regards
>>  Estartu
>> 
>> 
>> -- 
>> --
>> Gerhard Schmidt| E-Mail: schm...@ze.tum.de
>> Technische Universität München | Jabber: esta...@ze.tum.de
>> WWW & Online Services  |
>> Tel: +49 89 289-25270  | PGP-PublicKey
>> Fax: +49 89 289-25257  | on request
>> ___
>> 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 
> "

___
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: Problems with piped tar

[Daniel Braniss]

> On 23 Aug 2016, at 10:06, Gerhard Schmidt  wrote:
> 
> Hi,
> 
> i'm quite often use tar to copy files using
> 
> tar cf - /some/dir | (cd /dest/dir; tar xvvf - )
the ‘new’ way:
tar cf - /some/dir | tar xvvd - -C /dest/dir
which of course does not explain way your version hangs, but this one is 
cleaner, and btw, don’t
include /.

> 
> the files are copied without a problem but the reading tar never
> terminates and so the whole command never terminates.
> 
> This is new since FreeBSD 10.
> 
> Regards
>   Estartu
> 
> 
> -- 
> --
> Gerhard Schmidt| E-Mail: schm...@ze.tum.de
> Technische Universität München | Jabber: esta...@ze.tum.de
> WWW & Online Services  |
> Tel: +49 89 289-25270  | PGP-PublicKey
> Fax: +49 89 289-25257  | on request
> ___
> 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: Delay with 11.0-RC2 builds

[Ultima]

Please consider taking a looking at PR211629. This currently affects 11 as
well as head. I'm not entirely sure it is a sane default. Changing the
default value as well appears broken as well. I'm sure this can affect
various ports, tho I have only found audio-teamspeak3-server to have an
issue with it thus far.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211629

On Tue, Aug 23, 2016 at 12:03 AM, Karl Denninger  wrote:

> On 8/22/2016 23:01, Glen Barber wrote:
> > On Mon, Aug 22, 2016 at 10:53:06PM -0500, Karl Denninger wrote:
> >> On 8/22/2016 22:43, Glen Barber wrote:
> >>> On Thu, Aug 18, 2016 at 11:30:24PM +, Glen Barber wrote:
>  Two issues have been brought to our attention, and as a result,
> 11.0-RC2
>  builds will be delayed a day or two while these are investigated.
> 
>   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211872
>   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211926
> 
>  An update will be sent if the delay is longer than anticipated.
> 
> >>> Just an update, the 11.0-RC2 will be delayed at least two days.  One of
> >>> the issues mentioned in the above PR URLs does not affect releng/11.0,
> >>> and is a non-issue, but we are awaiting one more change to the
> stable/11
> >>> and releng/11.0 branches that we hope will be the final major changes
> to
> >>> 11.0.
> >>>
> >>> If this is the case, we may be able to eliminate 11.0-RC3 entirely, and
> >>> still release on time (or, on time as the current schedule suggests).
> >>>
> >>> However, as you know, FreeBSD releases prioritize quality over
> schedule,
> >>> so we may still need to adjust the schedule appropriately.
> >>>
> >>> So, help with testing 11.0-RC1 (or the latest releng/11.0 from svn) is
> >>> greatly appreciated.
> >>>
> >>> Glen
> >>> On behalf of:   re@
> >>>
> >> Has any decision been made on this?
> >>
> >> It is not local to me (others have reported problems with combination
> >> devices) and rolling back the change in question eliminates the
> >> problem.  It remains un-triaged as of this point.
> >>
> >> Note that this impacts a system that is booting and needs manual
> >> intervention, which is not a good place to a have a problem
> >>
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211884
> >>
> > Well, it's an EN candidate if we cannot get it fixed before the release.
> > But, I've put it on our radar, which it was not on mine previously...
> >
> > Glen
> Thank you.
>
> As far as I can tell reverting that one commit (which results in just
> one file being rolled back with a handful of lines) fixes it.  The other
> PR (which is linked in this one) reporter also reported that reverting
> that same commit fixes the problem for him as well.
>
> --
> Karl Denninger
> k...@denninger.net 
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
>
___
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"

Problems with piped tar

[Gerhard Schmidt]

Hi,

i'm quite often use tar to copy files using

tar cf - /some/dir | (cd /dest/dir; tar xvvf - )

the files are copied without a problem but the reading tar never
terminates and so the whole command never terminates.

This is new since FreeBSD 10.

Regards
   Estartu


-- 
--
Gerhard Schmidt| E-Mail: schm...@ze.tum.de
Technische Universität München | Jabber: esta...@ze.tum.de
WWW & Online Services  |
Tel: +49 89 289-25270  | PGP-PublicKey
Fax: +49 89 289-25257  | on request
___
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"

Problems while reading from /dev/cd0

[Gerhard Schmidt]

Hi,

I'm having some very curios Problems while reading from an BD-R recorded
as a tar directly on the disk without a filesystem.

When i try to read the Disk via 'tar tvvf /dev/cd0'

i get the following output

-rw-r--r--  0 root   wheel 5793264611  1 Jan  2015 file1.db
tar: Error reading '/dev/cd0'
Archive Format: POSIX ustar format,  Compression: none
tar: Error exit delayed from previous errors.

reading the whole file via 'dd if=/dev/cd0 of=backup.tar bs=2048' and
than 'tar tvvf backup.tar' the file is read without a hitch. So the data
on the disk is OK but can't be read directly by tar.

if i try the dd without the bs=2048 i get

dd: /dev/cd0: Invalid argument
0+0 records in
0+0 records out
0 bytes transferred in 0.000115 secs (0 bytes/sec)

So there is a problem reading anything other than 2048 byte blocks from
a Disk.

Reading directly with tar worked in the past. I really don't know how
long it's there but i guess it's since i updated from FreeBSD 9 to
FreeBSD 10.

I running right now FreeBSD 10.3-RELEASE-p4

Here is the output from the kernel boot msg of the BRD Drive.
cd0 at ahcich7 bus 0 scbus7 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: Serial Number SIK9JFANE175
cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
- tray closed

Regards
   Estartu

-- 
--
Gerhard Schmidt| E-Mail: schm...@ze.tum.de
Technische Universität München | Jabber: esta...@ze.tum.de
WWW & Online Services  |
Tel: +49 89 289-25270  | PGP-PublicKey
Fax: +49 89 289-25257  | on request
___
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: Benchmarks results for FreeBSD 11

[Erich Dollansky]

Hi,

On Mon, 22 Aug 2016 03:22:35 +
Kubilay Kocak  wrote:

> On Mon, 22 Aug 2016, 11:31 AM Mark Linimon 
> wrote:
> 
> > On Mon, Aug 22, 2016 at 09:57:24AM +1000, Dewayne Geraghty wrote:  
> > > unless knowledgable people respond publicly and/or in the phoronix
> > > forums [...] this interpretation of reality will be fixed in
> > > decision- makers' minds and consequently the uptake (and support)
> > > of FreeBSD.  
> >
> > IIRC this has been done before and hasn't really been productive.
> > OTOH I don't recall the details.
> >
> > FreeBSD hasn't had a benchmarking guru since Kris Kennaway retired
> > from working on FreeBSD.  
> 
> 
> Michael has reached out off-list (thanks!) If anyone else is
> interested, I'd be happy to create a dedicated IRC channel on
> freenode to widen and focus the freebsd performance discussion net
> and doc any outcomes/notes in the FreeBSD Wiki.
> 
this is good. So, how can we help him to get things straight the next
time?

Erich
___
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"