Re: Release notes and handbook changes for identifying wireless adapters

[Lars Engels]

On Tue, Aug 02, 2016 at 07:31:34AM +0200, Lars Engels wrote:
> On Tue, Aug 02, 2016 at 07:02:05AM +0800, Ben Woods wrote:
> > Hi,
> > 
> > FreeBSD wireless users who are upgrading to FreeBSD 11.0 will likely get a
> > surprise when they try and identify which wireless adapters are available
> > in their computer by using ifconfig. Neither the FreeBSD 11 release notes
> > or the FreeBSD handbook currently explain this change.
> > 
> > For example, if you have an atheros wireless driver, you would
> > previously be able to see it using ifconfig, even before configuring the
> > wlan0 clone device.
> > 
> > % ifconfig | grep -B3 -i wireless
> > 
> > 
> > That was changed with commit r287197:
> > https://svnweb.freebsd.org/base?view=revision=287197
> > 
> > The new way to show which wireless adapter is available is:
> > % sysctl net.wlan.devices
> > 
> > Whilst the configuration in /etc/rc.conf required to activate a wireless
> > adapter has not changed, people may run into the hurdle of not even finding
> > which wireless adapter to configure in the first place. This can be seen
> > here:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203271
> > 
> 
> rc.conf behaviour has changed in regard of creating lagg interaces.
> 
> 10.x needs this (copied from the handbook [1]):
> 
> ifconfig_bge0="up"
> ifconfig_iwn0="ether 00:21:70:da:ae:37"
> wlans_iwn0="wlan0"
> ifconfig_wlan0="WPA"
> cloned_interfaces="lagg0"
> ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 DHCP"
> 
> 
> 11.x needs this:
> 
> ifconfig_bge0="up"
> wlans_iwn0="wlan0"
> create_args_wlan0="ether 00:21:70:da:ae:37" # new

Small correction:


create_args_wlan0="wlanaddr 00:21:70:da:ae:37"


pgpbdIo4IMb6v.pgp
Description: PGP signature

Re: Release notes and handbook changes for identifying wireless adapters

[Lars Engels]

On Tue, Aug 02, 2016 at 07:02:05AM +0800, Ben Woods wrote:
> Hi,
> 
> FreeBSD wireless users who are upgrading to FreeBSD 11.0 will likely get a
> surprise when they try and identify which wireless adapters are available
> in their computer by using ifconfig. Neither the FreeBSD 11 release notes
> or the FreeBSD handbook currently explain this change.
> 
> For example, if you have an atheros wireless driver, you would
> previously be able to see it using ifconfig, even before configuring the
> wlan0 clone device.
> 
> % ifconfig | grep -B3 -i wireless
> 
> 
> That was changed with commit r287197:
> https://svnweb.freebsd.org/base?view=revision=287197
> 
> The new way to show which wireless adapter is available is:
> % sysctl net.wlan.devices
> 
> Whilst the configuration in /etc/rc.conf required to activate a wireless
> adapter has not changed, people may run into the hurdle of not even finding
> which wireless adapter to configure in the first place. This can be seen
> here:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203271
> 

rc.conf behaviour has changed in regard of creating lagg interaces.

10.x needs this (copied from the handbook [1]):

ifconfig_bge0="up"
ifconfig_iwn0="ether 00:21:70:da:ae:37"
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 DHCP"


11.x needs this:

ifconfig_bge0="up"
wlans_iwn0="wlan0"
create_args_wlan0="ether 00:21:70:da:ae:37" # new
ifconfig_wlan0="WPA"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 DHCP"



[1] 
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html


pgpS2_JRdcT8k.pgp
Description: PGP signature

Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i

[Ultima]

If anyone is interested, as Michelle Sullivan just mentioned. One problem I
found when looking for an HBA is that they are not so easy to find. Scoured
the internet for a backup HBA I came across these -
http://www.avagotech.com/products/server-storage/host-bus-adapters/#tab-12Gb1

Can only speak for sas-9305-24i. All 24 bays are occupied and quite pleased
with the performance compared to its predecessor. It was originally going
to be a backup unit, however that changed after running a scrub and the
amount of hours to complete cut in half (around 30ish to 15 for 35T). And
of course, the reason for this post, it replaced a raid card in passthrough
mode.

Another note, because it is an HBA, the ability to flash firmware is once
again possible! (yay!)

+1 to HBA's + ZFS, if possible replace it for an HBA.

On Mon, Aug 1, 2016 at 1:30 PM, Michelle Sullivan 
wrote:

> Borja Marcos wrote:
>
>> On 01 Aug 2016, at 15:12, O. Hartmann 
>>> wrote:
>>>
>>> First, thanks for responding so quickly.
>>>
>>> - The third option is to make the driver expose the SAS devices like a
 HBA
 would do, so that they are visible to the CAM layer, and disks are
 handled by
 the stock “da” driver, which is the ideal solution.

>>> I didn't find any switch which offers me the opportunity to put the PRAID
>>> CP400i into a simple HBA mode.
>>>
>> The switch is in the FreeBSD mfi driver, the loader tunable I mentioned,
>> regardless of what the card
>> firmware does or pretends to do.
>>
>> It’s not visible doing a "sysctl -a”, but it exists and it’s unique even.
>> It’s defined here:
>>
>>
>> https://svnweb.freebsd.org/base/stable/10/sys/dev/mfi/mfi_cam.c?revision=267084=markup
>> (line 93)
>>
>> In order to do it you need a couple of things. You need to set the
 variable
 hw.mfi.allow_cam_disk_passthrough=1 and to load the mfip.ko module.

 When booting installation media, enter command mode and use these
 commands:

 -
 set hw.mfi.allow_cam_disk_passthrough=1
 load mfip
 boot
 ———

>>> Well, I'm truly aware of this problemacy and solution (now), but I run
>>> into a
>>> henn-egg-problem, literally. As long as I can boot off of the
>>> installation
>>> medium, I have a kernel which deals with the setting. But the boot
>>> medium is
>>> supposed to be a SSD sitting with the PRAID CP400i controller itself!
>>> So, I
>>> never be able to boot off the system without crippling the ability to
>>> have a
>>> fullspeed ZFS configuration which I suppose to have with HBA mode, but
>>> not
>>> with any of the forced RAID modes offered by the controller.
>>>
>> Been there plenty of times, even argued quite strongly about the
>> advantages of ZFS against hardware based RAID
>> 5 cards. :) I remember when the Dell salesmen couldn’t possibly
>> understand why I wanted a “software based RAID rather than a
>> robust, hardware based solution” :D
>>
>
> There are reasons for using either...
>
> Nowadays its seems the conversations have degenerated into those like
> Windows vs Linux vs Mac where everyone thinks their answer is the right one
> (just as you suggested you (Borja Marcos) did with the Dell salesman),
> where in reality each has its own advantages and disadvantages.  Eg: I'm
> running 2 zfs servers on 'LSI 9260-16i's... big mistake! (the ZFS, not
> LSI's)... one is a 'movie server' the other a 'postgresql database'
> server...  The latter most would agree is a bad use of zfs, the die-hards
> won't but then they don't understand database servers and how they work on
> disk.  The former has mixed views, some argue that zfs is the only way to
> ensure the movies will always work, personally I think of all the years
> before zfs when my data on disk worked without failure until the disks
> themselves failed... and RAID stopped that happening...  what suddenly
> changed, are disks and ram suddenly not reliable at transferring data? ..
> anyhow back to the issue there is another part with this particular
> hardware that people just throw away...
>
> The LSI 9260-* controllers have been designed to provide on hardware
> RAID.  The caching whether using the Cachecade SSD or just oneboard ECC
> memory is *ONLY* used when running some sort of RAID set and LVs... this is
> why LSI recommend 'MegaCli -CfgEachDskRaid0' because it does enable
> caching..  A good read on how to setup something similar is here:
> https://calomel.org/megacli_lsi_commands.html (disclaimer, I haven't
> parsed it all so the author could be clueless, but it seems to give
> generally good advice.)  Going the way of 'JBOD' is a bad thing to do, just
> don't, performance sucks. As for the recommended command above, can't
> comment because currently I don't use it nor will I need to in the near
> future... but...
>
> If you (O Hartmann) want to use or need to use ZFS with any OS including
> FreeBSD don't go with the LSI 92xx series controllers, its just the wrong
> 

Re: Release notes and handbook changes for identifying wireless adapters

[Warren Block]

On Mon, 1 Aug 2016, Shawn Webb wrote:


The discussion on this is too late for code changes to 11.0-RELEASE, but this 
should be documented loud and clear.


The difficulty here is that now we have to document different methods 
for different versions, which makes it harder for new users *and* the 
people trying to document it.  Too bad net.wlan.devices doesn't exist on 
10.X.  Maybe it could.

___
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: Release notes and handbook changes for identifying wireless adapters

[Shawn Webb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On August 1, 2016 7:02:05 PM EDT, Ben Woods  wrote:
>Hi,
>
>FreeBSD wireless users who are upgrading to FreeBSD 11.0 will likely
>get a
>surprise when they try and identify which wireless adapters are
>available
>in their computer by using ifconfig. Neither the FreeBSD 11 release
>notes
>or the FreeBSD handbook currently explain this change.
>
>For example, if you have an atheros wireless driver, you would
>previously be able to see it using ifconfig, even before configuring
>the
>wlan0 clone device.
>
>% ifconfig | grep -B3 -i wireless
>
>
>That was changed with commit r287197:
>https://svnweb.freebsd.org/base?view=revision=287197
>
>The new way to show which wireless adapter is available is:
>% sysctl net.wlan.devices
>
>Whilst the configuration in /etc/rc.conf required to activate a
>wireless
>adapter has not changed, people may run into the hurdle of not even
>finding
>which wireless adapter to configure in the first place. This can be
>seen
>here:
>https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203271
>
>Regards,
>Ben

Hey Ben,

I completely agree. It also seems like a POLA violation. I dislike that I can't 
get information like MAC address prior to creating the clone. Instead of simply 
'ifconfig ath0 ether', now it's 'ifconfig wlan0 create wlandev ath0; ifconfig 
wlan0 ether'. Some networks use MAC address whitelisting. It's also not 
possible to easily tell which adapter is which, in case of multiple of the same 
adapters.

The discussion on this is too late for code changes to 11.0-RELEASE, but this 
should be documented loud and clear.

Thanks,

Shawn

- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQI/BAEBCgApBQJXn9cFIhxTaGF3biBXZWJiIDxzaGF3bkBzaGF3bndlYmIuaW5m
bz4ACgkQaoRlj1JFbu6JeQ/5Adjqi8Mdsk6zNNAZkaBMQzzg32OrdIR9kU5iKZIx
45tx0AIPkeZEoMJT03vrnyTcE39p3y/ThVydWLnjqbQFAZYehY0fGjbf6spF2mxM
88CDGnZjHXS9EYE0tgHJQmtzhKgxBal2BmYUEIKiEQfafU+TetF3bo/nwr4+1T3C
Qc0P/gwWC50oNvKEc+/Oc6/wO2zcyKwcjD7bMR0BBUpNMJE/1XJEe3S3NgpqOmgD
8xxRS64vamAaYkSXttZ0twAUDowZmDVnPQrRvB6HCvTGOFoowF4Zoka7wZE8V4EH
PfslEN3UWY95KEdS8+LMOx57ValKctm2A4uCqZ2RQrvVt3Li+9srjzyJomXjJgw/
+FgcGdVisJi5MqbdCSU7ke+F0a3oSYPG4ur5Z3UZZgYhs2B65iZagtQyRv8VsmSQ
P9ysbMnrh+HSTANy6kI4RCwbkjhk2ZMT0d+mSPy3FAmGfxFkJJUCMcGpPUjZNkO6
a/VsV6qi00hcngV1e3z0SuaPEu/08Cu8IwfilRu5fsSt74X5iOCqBlqSDvdQq580
KJzfLMbwdNtjnLvgREHKikTVF1xaZqrx4Pr3m5Jxfk5USsfvdd2UKh+G0KdkWoFa
ewVaNz26K1K8yMPkDx5meuC7MXvTiUIgn+YY6MudPxPFT7eOC5/kFZ5pfHXjCvUj
W3w=
=WibE
-END PGP SIGNATURE-

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

Release notes and handbook changes for identifying wireless adapters

[Ben Woods]

Hi,

FreeBSD wireless users who are upgrading to FreeBSD 11.0 will likely get a
surprise when they try and identify which wireless adapters are available
in their computer by using ifconfig. Neither the FreeBSD 11 release notes
or the FreeBSD handbook currently explain this change.

For example, if you have an atheros wireless driver, you would
previously be able to see it using ifconfig, even before configuring the
wlan0 clone device.

% ifconfig | grep -B3 -i wireless


That was changed with commit r287197:
https://svnweb.freebsd.org/base?view=revision=287197

The new way to show which wireless adapter is available is:
% sysctl net.wlan.devices

Whilst the configuration in /etc/rc.conf required to activate a wireless
adapter has not changed, people may run into the hurdle of not even finding
which wireless adapter to configure in the first place. This can be seen
here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203271

Regards,
Ben


-- 

--
From: Benjamin Woods
woods...@gmail.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: Significant missing item in 11.0 release notes

[Kevin Oberman]

Thanks for the quick fix, Andrey! Now that this is taken care of, time to
start playing with the cool new features... especially naming tables.

Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

On Mon, Aug 1, 2016 at 10:02 AM, Ian Smith  wrote:

> On Mon, 1 Aug 2016 18:47:37 +0300, Andrey V. Elsukov wrote:
>  > On 01.08.16 18:43, Ian Smith wrote:
>  > > Fast work Andrey, and sorry for rushing in.  I ASSumed, after reading
>  > > the new tables section in 11.0-R ipfw(8), that Kevin had run into:
>  > >
>  > >Tables require explicit creation via create before use.
>  > >
>  > > but diving - not too deeply - into the log of /head/sbin/ipfw/tables.c
>  > > from your commit, I think that statement must be out of date, at least
>  > > regarding existing ruleset table configuration?  Is that right?
>  >
>  > If you want to use some new specific feature you need to create table
>  > explicitly. But for old rules generic tables will be created
>  > automatically (with warning).
>
> Exactly how I was hoped it would work, thankyou ..
>
> cheers, Ian
>
___
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"

Build failed in Jenkins: FreeBSD_stable_10 #346

[jenkins-admin]

See 

--
[...truncated 206492 lines...]
--- _ashldi3.So ---
--- _ashrdi3.So ---
--- _negdi2.So ---
cc -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem 
/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/include/
  
-L/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
  
-B/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
 -c -O2 -pipe  -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
-DHAVE_GTHR_DEFAULT  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/config
 
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc 
-I.  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
 -std=gnu99 -Qunused-arguments -fpic -DSHARED  -DL_negdi2 -o _negdi2.So 
/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c
--- _lshrdi3.So ---
cc -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem 
/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/include/
  
-L/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
  
-B/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
 -c -O2 -pipe  -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
-DHAVE_GTHR_DEFAULT  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/config
 
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc 
-I.  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
 -std=gnu99 -Qunused-arguments -fpic -DSHARED  -DL_lshrdi3 -o _lshrdi3.So 
/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c
--- _ashldi3.So ---
cc -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem 
/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/include/
  
-L/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
  
-B/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
 -c -O2 -pipe  -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
-DHAVE_GTHR_DEFAULT  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/config
 
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc 
-I.  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
 -std=gnu99 -Qunused-arguments -fpic -DSHARED  -DL_ashldi3 -o _ashldi3.So 
/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c
--- _ashrdi3.So ---
cc -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem 
/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/include/
  
-L/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
  
-B/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
 -c -O2 -pipe  -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
-DHAVE_GTHR_DEFAULT  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/config
 
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc 
-I.  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
 -std=gnu99 -Qunused-arguments -fpic -DSHARED  -DL_ashrdi3 -o _ashrdi3.So 
/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c
--- _cmpdi2.So ---
--- _ucmpdi2.So ---
--- _enable_execute_stack.So ---
--- _cmpdi2.So ---
cc -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem 
/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/include/
  
-L/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
  
-B/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
 -c -O2 -pipe  -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
-DHAVE_GTHR_DEFAULT  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/config
 

Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i

[Michelle Sullivan]

Borja Marcos wrote:

On 01 Aug 2016, at 15:12, O. Hartmann  wrote:

First, thanks for responding so quickly.


- The third option is to make the driver expose the SAS devices like a HBA
would do, so that they are visible to the CAM layer, and disks are handled by
the stock “da” driver, which is the ideal solution.

I didn't find any switch which offers me the opportunity to put the PRAID
CP400i into a simple HBA mode.

The switch is in the FreeBSD mfi driver, the loader tunable I mentioned, 
regardless of what the card
firmware does or pretends to do.

It’s not visible doing a "sysctl -a”, but it exists and it’s unique even. It’s 
defined here:

https://svnweb.freebsd.org/base/stable/10/sys/dev/mfi/mfi_cam.c?revision=267084=markup
(line 93)


In order to do it you need a couple of things. You need to set the variable
hw.mfi.allow_cam_disk_passthrough=1 and to load the mfip.ko module.

When booting installation media, enter command mode and use these commands:

-
set hw.mfi.allow_cam_disk_passthrough=1
load mfip
boot
———

Well, I'm truly aware of this problemacy and solution (now), but I run into a
henn-egg-problem, literally. As long as I can boot off of the installation
medium, I have a kernel which deals with the setting. But the boot medium is
supposed to be a SSD sitting with the PRAID CP400i controller itself! So, I
never be able to boot off the system without crippling the ability to have a
fullspeed ZFS configuration which I suppose to have with HBA mode, but not
with any of the forced RAID modes offered by the controller.

Been there plenty of times, even argued quite strongly about the advantages of 
ZFS against hardware based RAID
5 cards. :) I remember when the Dell salesmen couldn’t possibly understand why 
I wanted a “software based RAID rather than a
robust, hardware based solution” :D


There are reasons for using either...

Nowadays its seems the conversations have degenerated into those like 
Windows vs Linux vs Mac where everyone thinks their answer is the right 
one (just as you suggested you (Borja Marcos) did with the Dell 
salesman), where in reality each has its own advantages and 
disadvantages.  Eg: I'm running 2 zfs servers on 'LSI 9260-16i's... big 
mistake! (the ZFS, not LSI's)... one is a 'movie server' the other a 
'postgresql database' server...  The latter most would agree is a bad 
use of zfs, the die-hards won't but then they don't understand database 
servers and how they work on disk.  The former has mixed views, some 
argue that zfs is the only way to ensure the movies will always work, 
personally I think of all the years before zfs when my data on disk 
worked without failure until the disks themselves failed... and RAID 
stopped that happening...  what suddenly changed, are disks and ram 
suddenly not reliable at transferring data? .. anyhow back to the issue 
there is another part with this particular hardware that people just 
throw away...


The LSI 9260-* controllers have been designed to provide on hardware 
RAID.  The caching whether using the Cachecade SSD or just oneboard ECC 
memory is *ONLY* used when running some sort of RAID set and LVs... this 
is why LSI recommend 'MegaCli -CfgEachDskRaid0' because it does enable 
caching..  A good read on how to setup something similar is here: 
https://calomel.org/megacli_lsi_commands.html (disclaimer, I haven't 
parsed it all so the author could be clueless, but it seems to give 
generally good advice.)  Going the way of 'JBOD' is a bad thing to do, 
just don't, performance sucks. As for the recommended command above, 
can't comment because currently I don't use it nor will I need to in the 
near future... but...


If you (O Hartmann) want to use or need to use ZFS with any OS including 
FreeBSD don't go with the LSI 92xx series controllers, its just the 
wrong thing to do..  Pick an HBA that is designed to give you direct 
access to the drives not one you have to kludge and cajole.. Including 
LSI controllers with caches that use the mfi driver, just not those that 
are not designed to work in a non RAID mode (with or without the 
passthru command/mode above.)






At worst, you can set up a simple boot from a thumb drive or, even better, a 
SATADOM installed inside the server. I guess it will
have SATA ports on the mainboard. That’s what I use to do. FreeNAS uses a 
similar approach as well. And some modern servers
also can boot from a SD card which you can use just to load the kernel.

Depending on the number of disks you have, you can also sacrifice two to set up 
a mirror with a “nomal” boot system, and using
the rest of the disks for ZFS. Actually I’ve got an old server I set up in 
2012. It has 16 disks, and I created a logical volume (mirror)
with 2 disks for boot, the other 14 disks for ZFS.

If I installed this server now I would do it different, booting off a thumb 
drive. But I was younger and naiver :)




If I installed mine now I would do them differently as well... 

FreeBSD_STABLE_11-arm64 - Build #65 - Fixed

[jenkins-admin]

FreeBSD_STABLE_11-arm64 - Build #65 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_11-arm64/65/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_11-arm64/65/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_11-arm64/65/console

Change summaries:

303628 by sbruno:
MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by:re (gjb)

___
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: Intel NVMe troubles?

[Jim Harris]

On Mon, Aug 1, 2016 at 7:38 AM, Borja Marcos  wrote:

>
> > On 29 Jul 2016, at 17:44, Jim Harris  wrote:
> >
> >
> >
> > On Fri, Jul 29, 2016 at 1:10 AM, Borja Marcos  wrote:
> >
> > > On 28 Jul 2016, at 19:25, Jim Harris  wrote:
> > >
> > > Yes, you should worry.
> > >
> > > Normally we could use the dump_debug sysctls to help debug this - these
> > > sysctls will dump the NVMe I/O submission and completion queues.  But
> in
> > > this case the LBA data is in the payload, not the NVMe submission
> entries,
> > > so dump_debug will not help as much as dumping the NVMe DSM payload
> > > directly.
> > >
> > > Could you try the attached patch and send output after recreating your
> pool?
> >
> > Just in case the evil anti-spam ate my answer, sent the results to your
> Gmail account.
> >
> >
> > Thanks Borja.
> >
> > It looks like all of the TRIM commands are formatted properly.  The
> failures do not happen until about 10 seconds after the last TRIM to each
> drive was submitted, and immediately before TRIMs start to the next drive,
> so I'm assuming the failures are for the the last few TRIM commands but
> cannot say for sure.  Could you apply patch v2 (attached) which will dump
> the TRIM payload contents inline with the failure messages?
>
> Sure, this is the complete /var/log/messages starting with the system
> boot. Before booting I destroyed the pool
> so that you could capture what happens when booting, zpool create, etc.
>
> Remember that the drives are in LBA format #3 (4 KB blocks). As far as I
> know that’s preferred to the old 512 byte blocks.
>
> Thank you very much and sorry about the belated response.


Hi Borja,

Thanks for the additional testing.  This has all of the detail that I need
for now.

-Jim
___
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: Significant missing item in 11.0 release notes

[Ian Smith]

On Mon, 1 Aug 2016 18:47:37 +0300, Andrey V. Elsukov wrote:
 > On 01.08.16 18:43, Ian Smith wrote:
 > > Fast work Andrey, and sorry for rushing in.  I ASSumed, after reading 
 > > the new tables section in 11.0-R ipfw(8), that Kevin had run into:
 > > 
 > >Tables require explicit creation via create before use.
 > > 
 > > but diving - not too deeply - into the log of /head/sbin/ipfw/tables.c 
 > > from your commit, I think that statement must be out of date, at least 
 > > regarding existing ruleset table configuration?  Is that right?
 > 
 > If you want to use some new specific feature you need to create table
 > explicitly. But for old rules generic tables will be created
 > automatically (with warning).

Exactly how I was hoped it would work, thankyou ..

cheers, Ian
___
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: Significant missing item in 11.0 release notes

[Andrey V. Elsukov]

On 01.08.16 18:43, Ian Smith wrote:
> Fast work Andrey, and sorry for rushing in.  I ASSumed, after reading 
> the new tables section in 11.0-R ipfw(8), that Kevin had run into:
> 
>   Tables require explicit creation via create before use.
> 
> but diving - not too deeply - into the log of /head/sbin/ipfw/tables.c 
> from your commit, I think that statement must be out of date, at least 
> regarding existing ruleset table configuration?  Is that right?

If you want to use some new specific feature you need to create table
explicitly. But for old rules generic tables will be created
automatically (with warning).

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: Significant missing item in 11.0 release notes

[Ian Smith]

On Mon, 1 Aug 2016 16:39:45 +0300, Andrey V. Elsukov wrote:
 > On 31.07.16 22:28, Kevin Oberman wrote:
 > > I assumed that I had missed this in the release notes, but I can find no
 > > reference to this significant change that simultaneously greatly enhanced
 > > ipfw table functionality, but also broke my configuration. While the fix
 > > was trivial, if the Release Notes had addressed this, I would not have had
 > > the problem in the first place.
 > 
 > I fixed this in r303615. Thanks for the report!

Fast work Andrey, and sorry for rushing in.  I ASSumed, after reading 
the new tables section in 11.0-R ipfw(8), that Kevin had run into:

Tables require explicit creation via create before use.

but diving - not too deeply - into the log of /head/sbin/ipfw/tables.c 
from your commit, I think that statement must be out of date, at least 
regarding existing ruleset table configuration?  Is that right?

cheers, Ian
___
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: Intel NVMe troubles?

[Michael Loftis]

FWIW I've had similar issues with Intel 750 PCIe NVMe drives when
attempting to use 4K blocks on Linux with EXT4 on top of MD RAID1 (software
mirror). I didn't dig much into because too many layers to reduce at the
time but it looked like the drive misreported the number of blocks and a
subsequent TRIM command or write of the last sector then errored. I mention
it because despite the differences the similarities (Intel NVMe, LBA#3/4K)
and error writing to a nonexistent block. Might give someone enough info to
figure it out fully.

On Monday, August 1, 2016, Borja Marcos  wrote:

>
> > On 29 Jul 2016, at 17:44, Jim Harris  > wrote:
> >
> >
> >
> > On Fri, Jul 29, 2016 at 1:10 AM, Borja Marcos  > wrote:
> >
> > > On 28 Jul 2016, at 19:25, Jim Harris  > wrote:
> > >
> > > Yes, you should worry.
> > >
> > > Normally we could use the dump_debug sysctls to help debug this - these
> > > sysctls will dump the NVMe I/O submission and completion queues.  But
> in
> > > this case the LBA data is in the payload, not the NVMe submission
> entries,
> > > so dump_debug will not help as much as dumping the NVMe DSM payload
> > > directly.
> > >
> > > Could you try the attached patch and send output after recreating your
> pool?
> >
> > Just in case the evil anti-spam ate my answer, sent the results to your
> Gmail account.
> >
> >
> > Thanks Borja.
> >
> > It looks like all of the TRIM commands are formatted properly.  The
> failures do not happen until about 10 seconds after the last TRIM to each
> drive was submitted, and immediately before TRIMs start to the next drive,
> so I'm assuming the failures are for the the last few TRIM commands but
> cannot say for sure.  Could you apply patch v2 (attached) which will dump
> the TRIM payload contents inline with the failure messages?
>
> Sure, this is the complete /var/log/messages starting with the system
> boot. Before booting I destroyed the pool
> so that you could capture what happens when booting, zpool create, etc.
>
> Remember that the drives are in LBA format #3 (4 KB blocks). As far as I
> know that’s preferred to the old 512 byte blocks.
>
> Thank you very much and sorry about the belated response.
>
>
>
>
>
> Borja.
>
>
>
> ___
> 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
> "



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
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: Intel NVMe troubles?

[Borja Marcos]

> On 29 Jul 2016, at 17:44, Jim Harris  wrote:
> 
> 
> 
> On Fri, Jul 29, 2016 at 1:10 AM, Borja Marcos  wrote:
> 
> > On 28 Jul 2016, at 19:25, Jim Harris  wrote:
> >
> > Yes, you should worry.
> >
> > Normally we could use the dump_debug sysctls to help debug this - these
> > sysctls will dump the NVMe I/O submission and completion queues.  But in
> > this case the LBA data is in the payload, not the NVMe submission entries,
> > so dump_debug will not help as much as dumping the NVMe DSM payload
> > directly.
> >
> > Could you try the attached patch and send output after recreating your pool?
> 
> Just in case the evil anti-spam ate my answer, sent the results to your Gmail 
> account.
> 
> 
> Thanks Borja.
> 
> It looks like all of the TRIM commands are formatted properly.  The failures 
> do not happen until about 10 seconds after the last TRIM to each drive was 
> submitted, and immediately before TRIMs start to the next drive, so I'm 
> assuming the failures are for the the last few TRIM commands but cannot say 
> for sure.  Could you apply patch v2 (attached) which will dump the TRIM 
> payload contents inline with the failure messages?

Sure, this is the complete /var/log/messages starting with the system boot. 
Before booting I destroyed the pool
so that you could capture what happens when booting, zpool create, etc.

Remember that the drives are in LBA format #3 (4 KB blocks). As far as I know 
that’s preferred to the old 512 byte blocks.

Thank you very much and sorry about the belated response.





Borja.



___
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: Significant missing item in 11.0 release notes

[Andrey V. Elsukov]

On 31.07.16 22:28, Kevin Oberman wrote:
> I assumed that I had missed this in the release notes, but I can find no
> reference to this significant change that simultaneously greatly enhanced
> ipfw table functionality, but also broke my configuration. While the fix
> was trivial, if the Release Notes had addressed this, I would not have had
> the problem in the first place.

I fixed this in r303615. Thanks for the report!

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i

[Borja Marcos]

> On 01 Aug 2016, at 15:12, O. Hartmann  wrote:
> 
> First, thanks for responding so quickly.
> 
>> - The third option is to make the driver expose the SAS devices like a HBA
>> would do, so that they are visible to the CAM layer, and disks are handled by
>> the stock “da” driver, which is the ideal solution. 
> 
> I didn't find any switch which offers me the opportunity to put the PRAID
> CP400i into a simple HBA mode.

The switch is in the FreeBSD mfi driver, the loader tunable I mentioned, 
regardless of what the card
firmware does or pretends to do.

It’s not visible doing a "sysctl -a”, but it exists and it’s unique even. It’s 
defined here:

https://svnweb.freebsd.org/base/stable/10/sys/dev/mfi/mfi_cam.c?revision=267084=markup
(line 93)

>> In order to do it you need a couple of things. You need to set the variable
>> hw.mfi.allow_cam_disk_passthrough=1 and to load the mfip.ko module.
>> 
>> When booting installation media, enter command mode and use these commands:
>> 
>> -
>> set hw.mfi.allow_cam_disk_passthrough=1
>> load mfip
>> boot
>> ———
> 
> Well, I'm truly aware of this problemacy and solution (now), but I run into a
> henn-egg-problem, literally. As long as I can boot off of the installation
> medium, I have a kernel which deals with the setting. But the boot medium is
> supposed to be a SSD sitting with the PRAID CP400i controller itself! So, I
> never be able to boot off the system without crippling the ability to have a
> fullspeed ZFS configuration which I suppose to have with HBA mode, but not
> with any of the forced RAID modes offered by the controller. 

Been there plenty of times, even argued quite strongly about the advantages of 
ZFS against hardware based RAID
5 cards. :) I remember when the Dell salesmen couldn’t possibly understand why 
I wanted a “software based RAID rather than a
robust, hardware based solution” :D 

At worst, you can set up a simple boot from a thumb drive or, even better, a 
SATADOM installed inside the server. I guess it will
have SATA ports on the mainboard. That’s what I use to do. FreeNAS uses a 
similar approach as well. And some modern servers
also can boot from a SD card which you can use just to load the kernel.

Depending on the number of disks you have, you can also sacrifice two to set up 
a mirror with a “nomal” boot system, and using
the rest of the disks for ZFS. Actually I’ve got an old server I set up in 
2012. It has 16 disks, and I created a logical volume (mirror)
with 2 disks for boot, the other 14 disks for ZFS.

If I installed this server now I would do it different, booting off a thumb 
drive. But I was younger and naiver :)






Borja.

___
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: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i

[O. Hartmann]

On Mon, 1 Aug 2016 11:48:30 +0200
Borja Marcos  wrote:

Hello.

First, thanks for responding so quickly.

> > On 01 Aug 2016, at 08:45, O. Hartmann  wrote:
> > 
> > On Wed, 22 Jun 2016 08:58:08 +0200
> > Borja Marcos  wrote:
> >   
> >> There is an option you can use (I do it all the time!) to make the card
> >> behave as a plain HBA so that the disks are handled by the “da” driver. 
> >> 
> >> Add this to /boot/loader.conf
> >> 
> >> hw.mfi.allow_cam_disk_passthrough=1
> >> mfip_load=“YES"
> >> 
> >> And do the tests accessing the disks as “da”. To avoid confusions, it’s
> >> better to make sure the disks are not part of a “jbod” or logical volume
> >> configuration.
> >> 
> >> 
> >> 
> >> 
> >> Borja.  
> > [...]
> > 
> > How is this supposed to work when ALL disks (including boot device) are
> > settled with the mfi (in our case, it is a Fujitsu CP400i, based upon
> > LSI3008 and detected within FreeBSD 11-BETA and 12-CURRENT) controller
> > itself?
> > 
> > I did not find any solution to force the CP400i into a mode making itself
> > acting as a HBA (we intend to use all drives with ZFS and let FreeBSD
> > kernel/ZFS control everything).  
> 
> Have you tried that particular option? 

I have, indeed, used the "JBOD" function of the PRAID CP400i controller and the
intention of my posting regards to the suspicion, that this is, as mentioned in
many posts concerning RAID controllers and ZFS, the reason for the worse
performance. And as I can see, it has been confirmed, sadly.

> 
> With kinda recent LSI based cards you have three options:
> 
> - The most usual and definitely NOT RECOMMENDED option is to define a logical
> volume per disk which actually LSI Logic called before JBOD mode. It’s not
> recommended at all if you want to run ZFS.

This is the only way to expose each disk as it is to the OS with the PRAID
CP400i built-in into our RX1330-M2 server (XEON Skylake based). I ordered that
specific box with a HBA capable controller. Searching the net reveals that
there is another one, called PSAS CP400i, which is also based on LSI/Avago
SAS3008 and the possibility to expose drives as-is is explicitely mentioned. I
do not know whether this is a software feature - as I suspect - or something
which has been hardwired to the controller.

> 
> - Recent cards, I think I saw this first on the LSI3008, have a JBOD mode
> that exposes the drives as “mfisyspd” devices. I don’t recommend it either,
> because the syspd drives are a sort of limited version of a disk device. With
> SSDs, especially, you don’t have access to the TRIM command.

They expose the drives as "mfidX" if setup as JBOD.

> 
> - The third option is to make the driver expose the SAS devices like a HBA
> would do, so that they are visible to the CAM layer, and disks are handled by
> the stock “da” driver, which is the ideal solution. 

I didn't find any switch which offers me the opportunity to put the PRAID
CP400i into a simple HBA mode.
 
> 
> However, this third option might not be available in some custom firmware
> versions for certain manufacturers? I don´t know. And I would hesitate to
> make the conversion on a production machine unless you have a complete and
> reliable full backup of all the data in case you need to rebuild it.

The boxes are empty and ready-for-installation, so I do not worry. It is more
worrying about this stupid software-based strangulations of options by Fujitsu
- if any. i do not want to blame them before I haven't double-checked.
> 
> In order to do it you need a couple of things. You need to set the variable
> hw.mfi.allow_cam_disk_passthrough=1 and to load the mfip.ko module.
> 
> When booting installation media, enter command mode and use these commands:
> 
> -
> set hw.mfi.allow_cam_disk_passthrough=1
> load mfip
> boot
> ———

Well, I'm truly aware of this problemacy and solution (now), but I run into a
henn-egg-problem, literally. As long as I can boot off of the installation
medium, I have a kernel which deals with the setting. But the boot medium is
supposed to be a SSD sitting with the PRAID CP400i controller itself! So, I
never be able to boot off the system without crippling the ability to have a
fullspeed ZFS configuration which I suppose to have with HBA mode, but not
with any of the forced RAID modes offered by the controller. 


I will check with Fujitsu for a solution. Maybe the PRAID CP400i is capable
somehow of being a PSAS CP400i also, even if not exposed by the
recent/installed firmware.

Kind regards,
Oliver 
 
> 
> 
> Remember that after installation you need to update /boot/loader.conf in the
> system you just installed with the following contents:
> 
>  hw.mfi.allow_cam_disk_passthrough=1
>  mfip_load=“YES”
> 
> 
> A note regarding CAM and MFI visibility: On some old firmware versions for
> the LSI2008 I’ve even seen the disks available both as “mfi” and “da”
> drivers. If possible, you should try to set them up 

Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i

[Borja Marcos]

> On 01 Aug 2016, at 08:45, O. Hartmann  wrote:
> 
> On Wed, 22 Jun 2016 08:58:08 +0200
> Borja Marcos  wrote:
> 
>> There is an option you can use (I do it all the time!) to make the card
>> behave as a plain HBA so that the disks are handled by the “da” driver. 
>> 
>> Add this to /boot/loader.conf
>> 
>> hw.mfi.allow_cam_disk_passthrough=1
>> mfip_load=“YES"
>> 
>> And do the tests accessing the disks as “da”. To avoid confusions, it’s
>> better to make sure the disks are not part of a “jbod” or logical volume
>> configuration.
>> 
>> 
>> 
>> 
>> Borja.
> [...]
> 
> How is this supposed to work when ALL disks (including boot device) are 
> settled
> with the mfi (in our case, it is a Fujitsu CP400i, based upon LSI3008 and
> detected within FreeBSD 11-BETA and 12-CURRENT) controller itself?
> 
> I did not find any solution to force the CP400i into a mode making itself
> acting as a HBA (we intend to use all drives with ZFS and let FreeBSD
> kernel/ZFS control everything).

Have you tried that particular option? 

With kinda recent LSI based cards you have three options:

- The most usual and definitely NOT RECOMMENDED option is to define a logical 
volume per disk
which actually LSI Logic called before JBOD mode. It’s not recommended at all 
if you want to run ZFS.

- Recent cards, I think I saw this first on the LSI3008, have a JBOD mode that 
exposes the drives as “mfisyspd” devices.
I don’t recommend it either, because the syspd drives are a sort of limited 
version of a disk device. With SSDs, especially, you
don’t have access to the TRIM command.

- The third option is to make the driver expose the SAS devices like a HBA 
would do, so that they are visible to the
CAM layer, and disks are handled by the stock “da” driver, which is the ideal 
solution. 

However, this third option might not be available in some custom firmware 
versions for certain manufacturers? I don´t
know. And I would hesitate to make the conversion on a production machine 
unless you have a complete and reliable
full backup of all the data in case you need to rebuild it.

In order to do it you need a couple of things. You need to set the variable 
hw.mfi.allow_cam_disk_passthrough=1
and to load the mfip.ko module.

When booting installation media, enter command mode and use these commands:

-
set hw.mfi.allow_cam_disk_passthrough=1
load mfip
boot
———


Remember that after installation you need to update /boot/loader.conf in the 
system you just installed with the
following contents:

 hw.mfi.allow_cam_disk_passthrough=1
 mfip_load=“YES”


A note regarding CAM and MFI visibility: On some old firmware versions for the 
LSI2008 I’ve even seen the disks
available both as “mfi” and “da” drivers. If possible, you should try to set 
them up as “unconfigured good” on the RAID
firmware. Use the RAID firmware set up or maybe mfiutil(8)

Also, make sure you don’t create any logical volumes on the disks you want 
exposed to CAM. You should delete
the logical volumes so that the MFI firmware doesn’t do anything with them. 

AND BEWARE: Doing these changes to a system in production with valuable data is 
dangerous. Make sure you have a full
and sound backup before making these changes.

As a worst case, the card could expose the devices both as “syspd” and CAM 
(i.e., “da” drives) but as long as you don’t
touch the syspd devices the card won’t do anything to them as far as I know. It 
could be a serious problem, however, if you 
access a drive part of a logical volume through CAM, as RAID cards tend do to 
“patrol reads” and other stuff on them. 

Provided it’s safe to do what I recommended, try it and follow up by email. 





Borja.




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

Build failed in Jenkins: FreeBSD_stable_10 #344

[jenkins-admin]

See 

--
[...truncated 206517 lines...]
--- _negdi2.So ---
--- _lshrdi3.So ---
--- _ashldi3.So ---
--- _ashrdi3.So ---
--- _negdi2.So ---
cc -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem 
/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/include/
  
-L/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
  
-B/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
 -c -O2 -pipe  -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
-DHAVE_GTHR_DEFAULT  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/config
 
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc 
-I.  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
 -std=gnu99 -Qunused-arguments -fpic -DSHARED  -DL_negdi2 -o _negdi2.So 
/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c
--- _lshrdi3.So ---
cc -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem 
/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/include/
  
-L/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
  
-B/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
 -c -O2 -pipe  -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
-DHAVE_GTHR_DEFAULT  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/config
 
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc 
-I.  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
 -std=gnu99 -Qunused-arguments -fpic -DSHARED  -DL_lshrdi3 -o _lshrdi3.So 
/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c
--- _ashldi3.So ---
cc -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem 
/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/include/
  
-L/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
  
-B/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
 -c -O2 -pipe  -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
-DHAVE_GTHR_DEFAULT  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/config
 
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc 
-I.  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
 -std=gnu99 -Qunused-arguments -fpic -DSHARED  -DL_ashldi3 -o _ashldi3.So 
/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c
--- _ashrdi3.So ---
cc -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem 
/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/include/
  
-L/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
  
-B/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
 -c -O2 -pipe  -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
-DHAVE_GTHR_DEFAULT  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/config
 
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc 
-I.  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
 -std=gnu99 -Qunused-arguments -fpic -DSHARED  -DL_ashrdi3 -o _ashrdi3.So 
/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c
--- _cmpdi2.So ---
cc -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem 
/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/include/
  
-L/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
  
-B/builds/workspace/FreeBSD_stable_10@2/obj/builds/workspace/FreeBSD_stable_10@2/src/lib32/usr/lib32
 -c -O2 -pipe  -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
-DHAVE_GTHR_DEFAULT  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc/config
 
-I/builds/workspace/FreeBSD_stable_10@2/src/gnu/lib/libgcc/../../../contrib/gcc 
-I.  

Re: Significant missing item in 11.0 release notes

[Ian Smith]

On Sun, 31 Jul 2016 12:28:06 -0700, Kevin Oberman wrote:

 > This morning I updated my min user system from 10.3-Stable to 11.0-BETA3.
 > In general, things went well, but I had two issues that prevented the
 > network from operating. the first is a lack of documentation in the Release
 > Notes and the second is a driver issue. Since they are in no way related,
 > I'll send the report of the driver issue later.
 > 
 > I use ipfw(8) tables in my firewall configuration. Unfortunately, 11.0 has
 > introduced a totally re-worked tables structure. The new structure is
 > awesome and I read about it at the time the changes were being planned and
 > implemented, but had forgotten. As a result the very first line in my
 > configuration, "table 1 flush" was no longer valid and the remainder of the
 > file was ignored.
 > 
 > I assumed that I had missed this in the release notes, but I can find no
 > reference to this significant change that simultaneously greatly enhanced
 > ipfw table functionality, but also broke my configuration. While the fix
 > was trivial, if the Release Notes had addressed this, I would not have had
 > the problem in the first place.

I don't see this as a Release Notes issue - though I guess it will be if 
it cannot be quickly fixed before 11.0-RELEASE - but as a very serious 
and -  as far as I know - unreported regression in ipfw(8).

In 18 years I cannot recall any addition of features, or additional 
options for existing features, that caused any breakage of existing 
rulesets.  What on earth could be invalid about "table 1 flush"?

cc'ing ipfw@, which is most likely where this should be discussed ..

cheers, Ian
___
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: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i

[O. Hartmann]

On Wed, 22 Jun 2016 08:58:08 +0200
Borja Marcos  wrote:

> > On 22 Jun 2016, at 04:08, Jason Zhang  wrote:
> > 
> > Mark,
> > 
> > Thanks
> > 
> > We have same RAID setting both on FreeBSD and CentOS including cache
> > setting.  In FreeBSD, I enabled the write cache but the performance is the
> > same.  
> > 
> > We don’t use ZFS or UFS, and test the performance on the RAW GEOM disk
> > “mfidx” exported by mfi driver.  We observed the “gstat” result and found
> > that the write latency is too high.  When we “dd" the disk with 8k, it is
> > lower than 1ms, but it is 6ms on 64kb write.  It seems that each single
> > write operation is very slow. But I don’t know whether it is a driver
> > problem or not.  
> 
> There is an option you can use (I do it all the time!) to make the card
> behave as a plain HBA so that the disks are handled by the “da” driver. 
> 
> Add this to /boot/loader.conf
> 
> hw.mfi.allow_cam_disk_passthrough=1
> mfip_load=“YES"
> 
> And do the tests accessing the disks as “da”. To avoid confusions, it’s
> better to make sure the disks are not part of a “jbod” or logical volume
> configuration.
> 
> 
> 
> 
> Borja.
[...]

How is this supposed to work when ALL disks (including boot device) are settled
with the mfi (in our case, it is a Fujitsu CP400i, based upon LSI3008 and
detected within FreeBSD 11-BETA and 12-CURRENT) controller itself?

I did not find any solution to force the CP400i into a mode making itself
acting as a HBA (we intend to use all drives with ZFS and let FreeBSD
kernel/ZFS control everything).

The boot device is a 256 GB Samsung SSD for enterprise use and putting the UEFI
load onto a EFI partition from 11-CURRENT-ALPHA4 is worse: dd takes up to
almost a minute to put the image onto the SSD. The SSD active LED is blinking
alle the time indicating activity. Caches are off. I tried to enable the cache
via the mfiutil command by 'mfiutil cache mfid0 enable', but it failed ... It
failed also on all other attached drives.

I didn't further go into more investigations right now, since the experience
with the EFI boot loader makes me suspect bad performance and that is harsh so
to speak. Glad to have found this thread anyway.

I cross post this also to CURRENT as it might be an issue with CURRENT ...

Kind regards,

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

11-BETA3 Panic: Memory modified after free

[Harald Schmalzbauer]

 Hello,

11-BETA3 crashes spontaniously with this:

Unread portion of the kernel message buffer:
panic: Memory modified after free 0xf8000709f400(1024) val=dedeadc0
@ 0xf8000709f400

cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe007a2e8540
vpanic() at vpanic+0x182/frame 0xfe007a2e85c0
panic() at panic+0x43/frame 0xfe007a2e8620
trash_ctor() at trash_ctor+0x4b/frame 0xfe007a2e8630
uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfe007a2e8690
namei() at namei+0xe4/frame 0xfe007a2e8750
kern_statat() at kern_statat+0xa8/frame 0xfe007a2e8900
sys_stat() at sys_stat+0x2d/frame 0xfe007a2e89a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe007a2e8ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe007a2e8ab0
--- syscall (188, FreeBSD ELF64, sys_stat), rip = 0x800e4f48a, rsp =
0x7fffde58, rbp = 0x7fffdfb0 ---
KDB: enter: panic

#0  doadump (textdump=2049867776) at pcpu.h:221
221 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) tr
trace command requires an argument
(kgdb) backtrace
#0  doadump (textdump=2049867776) at pcpu.h:221
#1  0x80393346 in db_fncall (dummy1=,
dummy2=, dummy3=,
dummy4=)
at /usr/local/share/deploy-tools/RELENG_11/src/sys/ddb/db_command.c:568
#2  0x80392de9 in db_command (cmd_table=)
at /usr/local/share/deploy-tools/RELENG_11/src/sys/ddb/db_command.c:440
#3  0x80392b44 in db_command_loop () at
/usr/local/share/deploy-tools/RELENG_11/src/sys/ddb/db_command.c:493
#4  0x80395a7b in db_trap (type=,
code=) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/ddb/db_main.c:251
#5  0x80a96133 in kdb_trap (type=,
code=, tf=)
at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/subr_kdb.c:654
#6  0x80ec5a4d in trap (frame=0xfe007a2e8470) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/trap.c:556
#7  0x80ea6161 in calltrap () at
/usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/exception.S:236
#8  0x80a957db in kdb_enter (why=0x813f055e "panic",
msg=0x80 ) at cpufunc.h:63
#9  0x80a562df in vpanic (fmt=,
ap=0xfe007a2e8600) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:752
#10 0x80a56343 in panic (fmt=0x82890250 "\004") at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:690
#11 0x80d349eb in trash_ctor (mem=,
size=, arg=, flags=)
at /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/uma_dbg.c:80
#12 0x80d308f4 in uma_zalloc_arg (zone=,
udata=0x0, flags=)
at /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/uma_core.c:2156
#13 0x80b09384 in namei (ndp=0xfe007a2e8810) at uma.h:336
#14 0x80b20168 in kern_statat (td=0xf800078ee000,
flag=, fd=-100, path=0x1a1e ,
pathseg=, sbp=,
hook=0x8014161e0) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/vfs_syscalls.c:2160
#15 0x80b2009d in sys_stat (td=0x82890250,
uap=0xfe007a2e8a40) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/vfs_syscalls.c:2115
#16 0x80ec6b2b in amd64_syscall (td=0xf800078ee000,
traced=0) at subr_syscall.c:135
#17 0x80ea644b in Xfast_syscall () at
/usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/exception.S:396
#18 0x000800e4f48a in ?? ()
Previous frame inner to this frame (corrupt stack?)

Thanks for any help, tell me if I can help narrow it down. A wild guess is it's 
related to unionfs?

-Harry




signature.asc
Description: OpenPGP digital signature

11-BETA3 Panic with ip6+ESP, Fatal trap 12, severe outage

[Harry Schmalzbauer]

 Hello,

unfortunately my upgrade from 10.3 to 11-BETA3 caused machine outage.
ESP encrypted IPv6-traffic acauses a immediate crash.
Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211486
whereI provided this info:

Unread portion of the kernel message buffer:
Kernel page fault with the following non-sleepable locks held:
exclusive rw tcpinp (tcpinp) r = 0 (0xf80007b1fe18) locked @ 
/usr/local/share/deploy-tools/RELENG_11/src/sys/netinet6/in6_pcb.c:1172
shared rw tcp (tcp) r = 0 (0x82ad2bd8) locked @ 
/usr/local/share/deploy-tools/RELENG_11/src/sys/netinet/tcp_input.c:802
stack backtrace:
#0 0x80ab4d30 at witness_debugger+0x70
#1 0x80ab6017 at witness_warn+0x3d7
#2 0x80ec63d7 at trap_pfault+0x57
#3 0x80ec5a64 at trap+0x284
#4 0x80ea6161 at calltrap+0x8
#5 0x80c43c51 at tcp_twrespond+0x231
#6 0x80c436f5 at tcp_twstart+0x1f5
#7 0x80c34078 at tcp_do_segment+0x23c8
#8 0x80c310b4 at tcp_input+0xe44
#9 0x80c30221 at tcp6_input+0xf1
#10 0x80c82799 at ipsec6_common_input_cb+0x4c9
#11 0x80c97101 at esp_input_cb+0x671
#12 0x80ca9e69 at swcr_process+0xd69
#13 0x80ca6c2f at crypto_dispatch+0x7f
#14 0x80c9605a at esp_input+0x4fa
#15 0x80c8179b at ipsec_common_input+0x40b
#16 0x80c8222d at ipsec6_common_input+0xcd
#17 0x80c64070 at ip6_input+0xc70


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0x1a
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80c65afc
stack pointer   = 0x28:0xfe0091f1e5f0
frame pointer   = 0x28:0xfe0091f1e850
code segment= base r 
x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (em0 que)


Thanks,

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