Re: LSI SAS 3108 RAID Controller

[Zara Kanaeva]

Thank you for all responds.

set hw.mfi.mrsas_enable=1
in Loader prompt did the work. The useful information for this problem  
can be found here:

http://lists.dragonflybsd.org/pipermail/users/2014-July/128703.html

Regards, Z.K.

Zitat von Zara Kanaeva :


Dear list,

I have one Fujitsu server with LSI SAS 3108 RAID Controller. These  
LSI SAS 3108 RAID Controller is supported by the mpr driver  
(https://www.freebsd.org/relnotes/CURRENT/hardware/support.html).
If I try to install the FreeBSD-stable 10.0 or FreeBSD-current 11.0  
on this server I can make partitions, but I can not write install  
files on the disks (better to say RAID5 virtual drive) without errors.

The erorrs are:
mfi0 failed to get command
mfi0: COMMAND ... TIMEOUT AFTER  ... SECONDS

By the installations I see my virtual drive as device with mfi0 as  
identifier.


My questions are:
1) Why I see the virtual drive as device with mfi0 as identifier. I  
would expect that my virtual drive has identifier mpr0 or something  
like this.
2) Why I can install FreeBSD on one of the disks connected to LSI  
SAS 3108 RAID Controller, if the disks do not build any virtual  
drive (no matter which RAID level). Is that possible because mpr  
driver supports the LSI SAS 3108 RAID Controller as SCSI Controller  
and not as RAID Controller (see Kernel configuration)?


Thanks in advance, Z. Kanaeva.

--
Dipl.-Inf. Zara Kanaeva
Heidelberger Akademie der Wissenschaften
Forschungsstelle "The role of culture in early expansions of humans"
an der Universität Tübingen
Geographisches Institut
Universität Tübingen
Ruemelinstr. 19-23
72070 Tuebingen

Tel.: +49-(0)7071-2972132
e-mail: zara.kana...@geographie.uni-tuebingen.de
---
- Theory is when you know something but it doesn't work.
- Practice is when something works but you don't know why.
- Usually we combine theory and practice:
Nothing works and we don't know why.




--
Dipl.-Inf. Zara Kanaeva
Heidelberger Akademie der Wissenschaften
Forschungsstelle "The role of culture in early expansions of humans"
an der Universität Tübingen
Geographisches Institut
Universität Tübingen
Ruemelinstr. 19-23
72070 Tuebingen

Tel.: +49-(0)7071-2972132
e-mail: zara.kana...@geographie.uni-tuebingen.de
---
- Theory is when you know something but it doesn't work.
- Practice is when something works but you don't know why.
- Usually we combine theory and practice:
Nothing works and we don't know why.

___
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: LSI SAS 3108 RAID Controller

[krad]

Just a sanity check 1st.

Are you going to be using zfs or ufs?

If zfs you probably want the reflash the card the the relevant HBA firmware
rather the the raid firmware. This will expose the disks nativly which is
best for zfs.

Sorry if this isn't appropriate for you but I would thought I would check
as it might save you a whole load of pain going in a direction you don't
need to.

On 2 February 2016 at 17:06, Zara Kanaeva  wrote:

> Dear list,
>
> I have one Fujitsu server with LSI SAS 3108 RAID Controller. These LSI SAS
> 3108 RAID Controller is supported by the mpr driver (
> https://www.freebsd.org/relnotes/CURRENT/hardware/support.html).
> If I try to install the FreeBSD-stable 10.0 or FreeBSD-current 11.0 on
> this server I can make partitions, but I can not write install files on the
> disks (better to say RAID5 virtual drive) without errors.
> The erorrs are:
> mfi0 failed to get command
> mfi0: COMMAND ... TIMEOUT AFTER  ... SECONDS
>
> By the installations I see my virtual drive as device with mfi0 as
> identifier.
>
> My questions are:
> 1) Why I see the virtual drive as device with mfi0 as identifier. I would
> expect that my virtual drive has identifier mpr0 or something like this.
> 2) Why I can install FreeBSD on one of the disks connected to LSI SAS 3108
> RAID Controller, if the disks do not build any virtual drive (no matter
> which RAID level). Is that possible because mpr driver supports the LSI SAS
> 3108 RAID Controller as SCSI Controller and not as RAID Controller (see
> Kernel configuration)?
>
> Thanks in advance, Z. Kanaeva.
>
> --
> Dipl.-Inf. Zara Kanaeva
> Heidelberger Akademie der Wissenschaften
> Forschungsstelle "The role of culture in early expansions of humans"
> an der Universität Tübingen
> Geographisches Institut
> Universität Tübingen
> Ruemelinstr. 19-23
> 72070 Tuebingen
>
> Tel.: +49-(0)7071-2972132
> e-mail: zara.kana...@geographie.uni-tuebingen.de
> ---
> - Theory is when you know something but it doesn't work.
> - Practice is when something works but you don't know why.
> - Usually we combine theory and practice:
> Nothing works and we don't know why.
>
> ___
> 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: 10.2-RELEASE-p12 pf+GRE crashing

[Matthew Grooms]

On 2/3/2016 4:56 PM, Matthew Grooms wrote:

All,

I recently upgraded a pair of 10.0-RELEASE firewalls in the hope that 
I could avoid the local patching required to keep it up and running. 
Unfortunately, it crashes whenever I reload my pf firewall rule set. 
If I remove the GRE tunnel configurations from rc.conf, it happily 
reloads the rule set all day long. The kernel config is mostly GENERIC 
with the following additions ...


# Packet Filter
device  pf  # PF OpenBSD packet-filter firewall
device  pflog   # Logging support interface for PF
device  pfsync  # Synchronization interface for PF
device  carp# Common Address Redundancy Protocol

# IPsec
device  crypto
device  enc
options IPSEC

The crash is easy to reproduce as pfctl -f /etc/pf.conf does it every 
time. I should also mention that I tried with and without the 
following additional commits applied, but get the same result ...


https://svnweb.freebsd.org/base?view=revision=272695
https://svnweb.freebsd.org/base?view=revision=288529

I'm also a bit confused as to why these patches haven't made it into 
10 STABLE yet. The former doesn't mention an MFC and the latter has an 
MFC of 1 week, but was never done. In any case, here is the output 
from kgdb ...


This turned out to be another issue that was patched in head but not 
back ported to stable. I can't explain why it didn't get tripped when 
GRE tunnels were disabled. With the patch applied, I can reload my rule 
sets again without crashing ...


https://svnweb.freebsd.org/base?view=revision=264689

(kgdb) bt
#0  doadump (textdump=) at pcpu.h:219
#1  0x807c81f2 in kern_reboot (howto=260) at 
../../../kern/kern_shutdown.c:451
#2  0x807c85d5 in vpanic (fmt=, ap=optimized out>)

at ../../../kern/kern_shutdown.c:758
#3  0x807c8463 in panic (fmt=0x0) at 
../../../kern/kern_shutdown.c:687

#4  0x80bdc10b in trap_fatal (frame=,
eva=) at ../../../amd64/amd64/trap.c:851
#5  0x80bdc40d in trap_pfault (frame=0xfe233a80,
usermode=) at ../../../amd64/amd64/trap.c:674
#6  0x80bdbaaa in trap (frame=0xfe233a80)
at ../../../amd64/amd64/trap.c:440
#7  0x80bc1fa2 in calltrap () at 
../../../amd64/amd64/exception.S:236
#8  0x809c07f4 in pfr_detach_table (kt=0x0) at 
../../../netpfil/pf/pf_table.c:2047

#9  0x809a91f4 in pf_empty_pool (poola=0x813c3d68)
at ../../../netpfil/pf/pf_ioctl.c:354
#10 0x809ab3e5 in pfioctl (dev=, cmd=optimized out>,
addr=0xf8005eaf6800 "", flags=, td=optimized out>)

at ../../../netpfil/pf/pf_ioctl.c:2189
#11 0x806b5659 in devfs_ioctl_f (fp=0xf8000a2927d0, 
com=3295691827,
data=0xf8005eaf6800, cred=, 
td=0xf8000a25f000)

at ../../../fs/devfs/devfs_vnops.c:785
#12 0x8081b805 in kern_ioctl (td=0xf8000a25f000, fd=optimized out>,

com=2) at file.h:320
#13 0x8081b500 in sys_ioctl (td=0xf8000a25f000, 
uap=0xfe234b40)

at ../../../kern/sys_generic.c:718
#14 0x80bdca27 in amd64_syscall (td=0xf8000a25f000, traced=0)
at subr_syscall.c:134
#15 0x80bc228b in Xfast_syscall () at 
../../../amd64/amd64/exception.S:396

#16 0x000800dd9fda in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal

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

10.2-RELEASE-p12 pf+GRE crashing

[Matthew Grooms]

All,

I recently upgraded a pair of 10.0-RELEASE firewalls in the hope that I 
could avoid the local patching required to keep it up and running. 
Unfortunately, it crashes whenever I reload my pf firewall rule set. If 
I remove the GRE tunnel configurations from rc.conf, it happily reloads 
the rule set all day long. The kernel config is mostly GENERIC with the 
following additions ...


# Packet Filter
device  pf  # PF OpenBSD packet-filter firewall
device  pflog   # Logging support interface for PF
device  pfsync  # Synchronization interface for PF
device  carp# Common Address Redundancy Protocol

# IPsec
device  crypto
device  enc
options IPSEC

The crash is easy to reproduce as pfctl -f /etc/pf.conf does it every 
time. I should also mention that I tried with and without the following 
additional commits applied, but get the same result ...


https://svnweb.freebsd.org/base?view=revision=272695
https://svnweb.freebsd.org/base?view=revision=288529

I'm also a bit confused as to why these patches haven't made it into 10 
STABLE yet. The former doesn't mention an MFC and the latter has an MFC 
of 1 week, but was never done. In any case, here is the output from kgdb ...


[root@fw2 /var/crash]# kgdb /boot/kernel/kernel vmcore.3
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x4a4
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x809c07f4
stack pointer   = 0x28:0xfe233b30
frame pointer   = 0x28:0xfe233b40
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1990 (pfctl)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
#0 0x808048c0 at kdb_backtrace+0x60
#1 0x807c8596 at vpanic+0x126
#2 0x807c8463 at panic+0x43
#3 0x80bdc10b at trap_fatal+0x36b
#4 0x80bdc40d at trap_pfault+0x2ed
#5 0x80bdbaaa at trap+0x47a
#6 0x80bc1fa2 at calltrap+0x8
#7 0x809a91f4 at pf_empty_pool+0x44
#8 0x809ab3e5 at pfioctl+0x805
#9 0x806b5659 at devfs_ioctl_f+0x139
#10 0x8081b805 at kern_ioctl+0x255
#11 0x8081b500 at sys_ioctl+0x140
#12 0x80bdca27 at amd64_syscall+0x357
#13 0x80bc228b at Xfast_syscall+0xfb
Uptime: 1m1s
Dumping 156 out of 2025 MB:..11%..21%..31%..42%..52%..62%..72%..83%..93%

Reading symbols from /boot/kernel/if_lagg.ko.symbols...done.
Loaded symbols for /boot/kernel/if_lagg.ko.symbols
Reading symbols from /boot/kernel/if_gre.ko.symbols...done.
Loaded symbols for /boot/kernel/if_gre.ko.symbols
#0  doadump (textdump=) at pcpu.h:219
219 pcpu.h: No such file or directory.
in pcpu.h

Any help in resolving this would be greatly appreciated.

-Matthew
___
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: 10-STABLE hangups frequently

[Shane Ambler]

On 04/02/2016 05:33, Peter Jeremy wrote:

On 2016-Feb-03 18:23:13 +1030, Shane Ambler  wrote:

Any chance you get high wired allocations?


A high wired allocation is normal for ZFS - ARC shows up as "wired"
memory.


Sometimes several times in a day I see the wired amount shown in top
rise to over 6GB (of 8GB) bringing the system to a crawl. When wired
gets over 7GB the system rarely recovers.


The ARC limit defaults to 1GB less than physical RAM so 6GB wired on
an 8GB system isn't unexpected (my home system currently has 30GB
wired out of 32GB).  If this is causing problems for your workload, it
sounds like you may need to explicitly reduce vfs.zfs.arc_max (note
that this is a soft limit).


I have vfs.zfs.arc_max=2G - and now realise I also had set
vfs.zfs.arc_min=500M some time ago. Don't recall where I got it but I
also have vfs.zfs.dirty_data_max=200M

Going by figures shown in top, ARC is usually in the 1500M to 2000M
range but when wired gets over 6GB I often see ARC drop to 500MB which
I now realise matches arc_min.

When wired gets over 6GB apps start to stop responding, I then try to
push out some wired by running a script that allocates 4G, 9 times out
of 10 this drops wired to under 4GB and everything keeps working.

If I notice wired over 7GB there's usually no recover. I don't always
get to see the figures before it totally locks up.

On desktop1 I leave a terminal running top and another ready to run my
script to allocate some ram. When an app stops responding I go to
desktop1 and depending on what I see I manually allocate some ram to
flush things out.

Currently I have an uptime of 9 days 9 hours - I have manually allocated
4GB 30 times in that time.


--
FreeBSD - the place to B...Software Developing

Shane Ambler

___
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: 10-STABLE hangups frequently

[Thierry Thomas]

Le mer  3 fév 16 à  8:53:13 +0100, Shane Ambler 
 écrivait :

> Any chance you get high wired allocations?
> 
> Sometimes several times in a day I see the wired amount shown in top
> rise to over 6GB (of 8GB) bringing the system to a crawl. When wired
> gets over 7GB the system rarely recovers.
> 
> I am now running 10.2-STABLE r292646 on corei7 with 8GB and ZFS FS
> This is my everyday desktop running xfce and a variety of gui apps.
> 
> I use a small script to allocate several GB of ram that gives the
> pressure needed to start releasing some wired, provided I can get in
> early enough.
> 
> Not sure how to gather any helpful info for this.

I don't think so: this box has 16 GB of RAM, and everything is usually
fine, even during high activity (e.g. poudriere build). The problem
occurs only at daily periodic time.

It's not repetable on demand, that's why I've not yet identified the
task...
-- 
Th. Thomas.


pgp1GfzJKJHyC.pgp
Description: PGP signature

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

[Mike Tancsa]

On 2/1/2016 5:27 PM, Marius Strobl wrote:
> On Mon, Feb 01, 2016 at 05:11:29PM -0500, Mike Tancsa wrote:
>> On 1/30/2016 12:26 PM, Marius Strobl wrote:
>>>
>>> Ah, okay, that at least makes sense. Can you please verify that with
>>> the attached patch applied, you have a setup that works out of the
> by e-mail. I've put it online:
> https://people.freebsd.org/~marius/em_tso_gig_only_10.diff


So far so good. I have been running it on a couple of boxes and no
watchdog resets

# ifconfig em0
em0: flags=8943 metric 0
mtu 1500

options=4219b
media: Ethernet autoselect (100baseTX )
status: active

# pciconf -lvcb em0
em0@pci0:5:0:0: class=0x02 card=0x348d8086 chip=0x108c8086 rev=0x03
hdr=0x00
vendor = 'Intel Corporation'
device = '82573E Gigabit Ethernet Controller (Copper)'
class  = network
subclass   = ethernet
bar   [10] = type Memory, range 32, base 0xea18, size 131072,
enabled
bar   [14] = type Memory, range 32, base 0xea10, size 524288,
enabled
bar   [18] = type I/O Port, range 32, base 0x2000, size 32, enabled
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[e0] = PCI-Express 1 endpoint max data 128(256) RO NS link x1(x1)
 speed 2.5(2.5) ASPM disabled(L0s/L1)
ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected
ecap 0003[140] = Serial 1 0015172e31ad

and

# ifconfig em0
em0: flags=8843 metric 0 mtu 1500

options=4219b
  media: Ethernet autoselect (100baseTX )
status: active

# pciconf -lcvb em0
em0@pci0:13:0:0:class=0x02 card=0x108c15d9 chip=0x108c8086
rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = '82573E Gigabit Ethernet Controller (Copper)'
class  = network
subclass   = ethernet
bar   [10] = type Memory, range 32, base 0xe8a0, size 131072,
enabled
bar   [18] = type I/O Port, range 32, base 0x5000, size 32, enabled
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[e0] = PCI-Express 1 endpoint max data 128(256) RO NS link x1(x1)
 speed 2.5(2.5)
ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected
ecap 0003[140] = Serial 1 0030489c59f0




---Mike



-- 
---
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/
___
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: 10-STABLE hangups frequently

[Karl Denninger]

(Whistling.)

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

(see if that helps you)

On 2/3/2016 10:47, Thierry Thomas wrote:
> Le mer  3 fév 16 à  8:53:13 +0100, Shane Ambler 
>  écrivait :
>
>> Any chance you get high wired allocations?
>>
>> Sometimes several times in a day I see the wired amount shown in top
>> rise to over 6GB (of 8GB) bringing the system to a crawl. When wired
>> gets over 7GB the system rarely recovers.
>>
>> I am now running 10.2-STABLE r292646 on corei7 with 8GB and ZFS FS
>> This is my everyday desktop running xfce and a variety of gui apps.
>>
>> I use a small script to allocate several GB of ram that gives the
>> pressure needed to start releasing some wired, provided I can get in
>> early enough.
>>
>> Not sure how to gather any helpful info for this.
> I don't think so: this box has 16 GB of RAM, and everything is usually
> fine, even during high activity (e.g. poudriere build). The problem
> occurs only at daily periodic time.
>
> It's not repetable on demand, that's why I've not yet identified the
> task...

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


smime.p7s
Description: S/MIME Cryptographic Signature

FreeBSD Quarterly Status Report - Fourth Quarter 2015

[Benjamin Kaduk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

FreeBSD Project Quarterly Status Report: October - December 2015

   The fourth quarter of 2015 saw a great deal of activity for FreeBSD.
   This is now the third quarter running for which I can say that this is
   the largest report yet published! Many thanks to everyone who
   proactively submitted topics and entries -- it is great to have more
   complete coverage of ongoing development for the community to learn
   about in these reports.

   An experimental new Triage Team was formed this quarter to create a new
   way for community members to participate, and to improve issue
   management and productivity in general. Making more effective use of
   automation and tooling can help to increase developer productivity and
   the quality of FreeBSD, just as the adoption of Jenkins and continual
   integration tooling catches regressions quickly and maintains the high
   standards for the system.

   Efforts to bring our BSD high standards to new architectures continue,
   with impressive work on arm64 leading to its promotion to Tier-2 status
   and a flurry of work bringing up the new RISC-V hardware architecture.
   Software architecture is also under active development, including
   system startup and service management. A handful of potential init
   system replacements are mentioned in this report: launchd, relaunchd,
   and nosh. Architectural changes originating both from academic research
   (multipath TCP) and from the realities of industry (sendfile(2)
   improvements) are also under way. It is heartening to see how FreeBSD
   provides a welcoming platform for contributions from both research and
   industry.

   To all the readers, whether from academia or industry, hobbyist or
   professional: I hope you are as excited as I am to read about all of
   the progress and projects covered in this report, and the future of
   FreeBSD!

   --Ben Kaduk
 __

   The deadline for submissions covering the period from January to March
   2016 is April 7, 2016.
 __

FreeBSD Team Reports

 * FreeBSD Release Engineering Team
 * Issue Tracking (Bugzilla)
 * The FreeBSD Core Team
 * The FreeBSD Issue Triage Team

Projects

 * CAM I/O Scheduler
 * Encrypted Kernel Crash Dumps
 * Jenkins Continuous Integration for FreeBSD
 * Mellanox iSCSI Extensions for RDMA (iSER) Support
 * MIPS: Ralink/Mediatek Support
 * Multipath TCP for FreeBSD
 * OpenBSM
 * Raspberry Pi: VideoCore Userland Application Packaging
 * RCTL Disk IO Limits
 * Root Remount
 * Routing Stack Update
 * The Graphics Stack on FreeBSD
 * The nosh Project
 * UEFI Boot and Framebuffer Support

Kernel

 * Chelsio iSCSI Offload Driver (Initiator and Target)
 * FreeBSD Integration Services (BIS)
 * FreeBSD Xen
 * Improvements to the QLogic HBA Driver
 * iMX.6 Video Output Support
 * ioat(4) Driver Enhancements
 * Kernel Vnode Cache Tuning
 * Mellanox Drivers
 * Minimal Kernel with PNP-Based Autoloading
 * MMC Stack Under CAM Framework
 * ntb_hw(4)/if_ntb(4) Driver Synced up to Linux
 * Out of Memory Handler Rewrite
 * sendfile(2) Improvements
 * sysctl Enhancements
 * Touchscreen Support for Raspberry Pi and Beaglebone Black

Architectures

 * armv6 Hard Float Default ABI
 * FreeBSD on Marvell Armada38x
 * FreeBSD on Newer ARM Boards
 * FreeBSD on SoftIron Overdrive 3000
 * FreeBSD/arm64
 * FreeBSD/RISC-V
 * Improvements for ARMv6/v7 Support

Userland Programs

 * Base System Build Improvements
 * ELF Tool Chain Tools
 * The LLDB Debugger
 * Updates to GDB

Ports

 * Bringing GitLab into the Ports Collection
 * GNOME on FreeBSD
 * IPv6 Promotion Campaign
 * KDE on FreeBSD
 * Linux Kernel as a Library Added to the Ports Collection
 * LXQt on FreeBSD
 * New Tools to Enhance the Porting Experience
 * Node.js Modules
 * Ports Collection
 * Supporting Variants in the Ports Framework
 * Xfce on FreeBSD

Documentation

 * "FreeBSD Mastery: Specialty Filesystems" Early Access Version Now
   Available
 * style(9) Enhanced to Allow C99 bool

Miscellaneous

 * HardenedBSD
 * NanoBSD Modernization
 * relaunchd
 * System Initialization and Service Management
 * The FreeBSD Foundation
 __

FreeBSD Release Engineering Team

   Links
   FreeBSD 10.3-RELEASE schedule
URL: https://www.freebsd.org/releases/10.3R/schedule.html
   FreeBSD Development Snapshots
URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/

   Contact: FreeBSD Release Engineering Team 

   The FreeBSD Release Engineering Team is responsible for setting and
   publishing 

Re: 10-STABLE hangups frequently

[Peter Jeremy]

On 2016-Feb-03 18:23:13 +1030, Shane Ambler  wrote:
>Any chance you get high wired allocations?

A high wired allocation is normal for ZFS - ARC shows up as "wired"
memory.

>Sometimes several times in a day I see the wired amount shown in top
>rise to over 6GB (of 8GB) bringing the system to a crawl. When wired
>gets over 7GB the system rarely recovers.

The ARC limit defaults to 1GB less than physical RAM so 6GB wired on
an 8GB system isn't unexpected (my home system currently has 30GB
wired out of 32GB).  If this is causing problems for your workload, it
sounds like you may need to explicitly reduce vfs.zfs.arc_max (note
that this is a soft limit).

You might like to install sysutils/zfs-stats and do some ZFS tunung.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: LSI SAS 3108 RAID Controller

[Mike Tancsa]

On 2/3/2016 9:20 AM, krad wrote:
> 
> If zfs you probably want the reflash the card the the relevant HBA firmware
> rather the the raid firmware. This will expose the disks nativly which is
> best for zfs.

The version of card I have allows you to expose the individual disks as
JBODs out of the box.

---Mike


-- 
---
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/
___
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: Sanity check: FreeBSD 9.3 binaries on FreeBSD 9.1?

[Alan Amesbury]

Alfred Perlstein  said:

> It's possible they may work, but that is not guaranteed.
> 
> Packages built on 9.1 should work on 9.3.
> 
> Packages built on 9.3 may work on 9.1, but that would only be by chance.

OK, it sounds like testing is in order to make sure, but the probability is 
greater than zero.  It also sounds like I may be at least partially sane.

Thanks!


-- 
Alan Amesbury
University Information Security
http://umn.edu/lookup/amesbury

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