Re: #includes and #defined
On Fri, Aug 10, 2018 at 5:30 PM, Erich Dollansky < freebsd.ed.li...@sumeritec.com> wrote: > Hi, > > On Fri, 10 Aug 2018 07:53:19 -0600 > Warner Losh wrote: > > > On Thu, Aug 9, 2018 at 11:51 PM, Erich Dollansky < > > freebsd.ed.li...@sumeritec.com> wrote: > > > > > On Fri, 10 Aug 2018 12:40:48 +0800 > > > blubee blubeeme wrote: > > > > > > > > > > > What about the architecture name is it recommended to use x86_64 > > > > or amd64? > > > > > > my clang reports on an Intel CPU: > > > > > > #define __amd64 1 > > > #define __amd64__ 1 > > > #define __x86_64 1 > > > #define __x86_64__ 1 > > > > > > as defined. > > > > > > It reports > > > > > > #define __aarch64__ 1 > > > > > > on an 64 bit ARM CPU. > > > > > > > 'man 7 arch' will tell you these things: > > better late than never. > > I still trust a compiler more than the documentation. > The compiler confirms the documentation :) Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: #includes and #defined
Hi, On Fri, 10 Aug 2018 07:53:19 -0600 Warner Losh wrote: > On Thu, Aug 9, 2018 at 11:51 PM, Erich Dollansky < > freebsd.ed.li...@sumeritec.com> wrote: > > > On Fri, 10 Aug 2018 12:40:48 +0800 > > blubee blubeeme wrote: > > > > > > > > What about the architecture name is it recommended to use x86_64 > > > or amd64? > > > > my clang reports on an Intel CPU: > > > > #define __amd64 1 > > #define __amd64__ 1 > > #define __x86_64 1 > > #define __x86_64__ 1 > > > > as defined. > > > > It reports > > > > #define __aarch64__ 1 > > > > on an 64 bit ARM CPU. > > > > 'man 7 arch' will tell you these things: better late than never. I still trust a compiler more than the documentation. Erich ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ix SR-IOV working
Hello,
This is probably a driver issue. The only way I could get sr-iov
working with the ix driver is compiling the driver provided
by Intel and loading it before boot. [1] for more details and [2]
for the driver. Have not tested the latest version and only
tested this on CURRENT. Also, there were some options that
needed to be changed before compiling to enable sr-iov, it's
pretty straightforward though if I recall correctly.
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211062
[2]
https://downloadcenter.intel.com/download/14688/Intel-Network-Adapters-Driver-for-PCIe-10-Gigabit-Network-Connections-Under-FreeBSD
Best regards,
Richard Gallamore
On Fri, Aug 10, 2018 at 9:19 AM, Pete Wright wrote:
>
>
> On 8/10/18 8:30 AM, Ryan Stone wrote:
>
>> How many VFs are you trying to create? Getting ENOSPC either
>> indicates that you tried to allocate more VFs than the hardware
>> supports, or the system could not allocate enough MMIO space for the
>> VFs.
>>
>
> Hi Ryan,
> I was attempting to create a single VF. here's my iovct.conf:
>
> PF {
> num_vfs: 1;
> device : "ix0";
> }
>
> DEFAULT {
> passthrough : true;
> }
>
> my goal is to setup several bhyve instances on this server, and allocate
> one VF per instance. for now i'm attempting to create a single VF for
> testing purposes.
>
> Cheers!
>
> -pete
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ffs_truncate3 panics
On Thu, Aug 09, 2018 at 08:38:50PM +, Rick Macklem wrote:
> >BTW, does NFS server use extended attributes ? What for ? Can you, please,
> >point out the code which does this ?
> For the pNFS service, there are two system namespace extended attributes for
> each file stored on the service.
> pnfsd.dsfile - Stores where the data for the file is. Can be displayed by the
> pnfsdsfile(8) command.
>
> pnfsd.dsattr - Cached attributes that change when a file is written (size,
> mtime,
> change) so that the MDS doesn't have to do a Getattr on the data server for
> every client Getattr.
>
My reading of the nfsd code + ffs extattr handling reminds me that you
already reported this issue some time ago. I suspected ufs_balloc() at
that time.
Now I think that the situation with the stray buffers hanging on the
queue is legitimate, ffs_extread() might create such buffer and release
it to a clean queue, then removal of the file would see inode with no
allocated ext blocks but with the buffer.
I think the easiest way to handle it is to always flush buffers and pages
in the ext attr range, regardless of the number of allocated ext blocks.
Patch below was not tested.
diff --git a/sys/ufs/ffs/ffs_inode.c b/sys/ufs/ffs/ffs_inode.c
index 3cf58558c18..2ffd861f3b4 100644
--- a/sys/ufs/ffs/ffs_inode.c
+++ b/sys/ufs/ffs/ffs_inode.c
@@ -244,22 +244,19 @@ ffs_truncate(vp, length, flags, cred)
extblocks = btodb(fragroundup(fs, ip->i_din2->di_extsize));
datablocks -= extblocks;
}
- if ((flags & IO_EXT) && extblocks > 0) {
+ if ((flags & IO_EXT) != 0) {
if (length != 0)
panic("ffs_truncate: partial trunc of extdata");
if (softdeptrunc || journaltrunc) {
if ((flags & IO_NORMAL) == 0)
goto extclean;
needextclean = 1;
- } else {
- if ((error = ffs_syncvnode(vp, MNT_WAIT, 0)) != 0)
- return (error);
+ } else if ((error = ffs_syncvnode(vp, MNT_WAIT, 0)) != 0)
+ return (error);
+ if (extblocks > 0) {
#ifdef QUOTA
(void) chkdq(ip, -extblocks, NOCRED, 0);
#endif
- vinvalbuf(vp, V_ALT, 0, 0);
- vn_pages_remove(vp,
- OFF_TO_IDX(lblktosize(fs, -extblocks)), 0);
osize = ip->i_din2->di_extsize;
ip->i_din2->di_blocks -= extblocks;
ip->i_din2->di_extsize = 0;
@@ -278,6 +275,8 @@ ffs_truncate(vp, length, flags, cred)
vp->v_type, NULL, SINGLETON);
}
}
+ vinvalbuf(vp, V_ALT, 0, 0);
+ vn_pages_remove(vp, OFF_TO_IDX(lblktosize(fs, -UFS_NXADDR)), 0);
}
if ((flags & IO_NORMAL) == 0)
return (0);
@@ -631,7 +630,10 @@ ffs_truncate(vp, length, flags, cred)
softdep_journal_freeblocks(ip, cred, length, IO_EXT);
else
softdep_setup_freeblocks(ip, length, IO_EXT);
- return (ffs_update(vp, waitforupdate));
+ error = ffs_update(vp, waitforupdate);
+ vinvalbuf(vp, V_ALT, 0, 0);
+ vn_pages_remove(vp, OFF_TO_IDX(lblktosize(fs, -UFS_NXADDR)), 0);
+ return (error);
}
/*
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ix SR-IOV working
On 8/10/18 9:52 AM, Ultima wrote: Hello, This is probably a driver issue. The only way I could get sr-iov working with the ix driver is compiling the driver provided by Intel and loading it before boot. [1] for more details and [2] for the driver. Have not tested the latest version and only tested this on CURRENT. Also, there were some options that needed to be changed before compiling to enable sr-iov, it's pretty straightforward though if I recall correctly. awesome, thanks! i had downloaded the latest version from Intel and was thinking of giving it a spin, this seems to confirm this would worth my time testing out. thanks for the links for reference! -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ix SR-IOV working
On 8/10/18 8:30 AM, Ryan Stone wrote:
How many VFs are you trying to create? Getting ENOSPC either
indicates that you tried to allocate more VFs than the hardware
supports, or the system could not allocate enough MMIO space for the
VFs.
Hi Ryan,
I was attempting to create a single VF. here's my iovct.conf:
PF {
num_vfs: 1;
device : "ix0";
}
DEFAULT {
passthrough : true;
}
my goal is to setup several bhyve instances on this server, and allocate
one VF per instance. for now i'm attempting to create a single VF for
testing purposes.
Cheers!
-pete
--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ix SR-IOV working
How many VFs are you trying to create? Getting ENOSPC either indicates that you tried to allocate more VFs than the hardware supports, or the system could not allocate enough MMIO space for the VFs. On Thu, Aug 9, 2018 at 10:41 PM Pete Wright wrote: > > hello, > > i have a newly provisioned VPS system from Vultr which comes stock with > a 10Gbe ix interface: > > ix0@pci0:1:0:0: class=0x02 card=0x082315d9 chip=0x15578086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82599 10 Gigabit Network Connection' > class = network > subclass = ethernet > > > it is currently running 11-STABLE but was curious if there are any > reports of people successfully running SR-IOV under CURRENT with this > hardware and driver? On both 11.2-RELEASE and 11-STABLE, after running > iovctl to bring up the interface results in the NIC hanging - for > example like so: > > $ sudo iovctl -C -f /etc/iovctl.conf > iovctl: Failed to configure SR-IOV: No space left on device > > > > so if its working on CURRENT i'll go through the upgrade process, but if > no one is testing this I'll forgo SR-IOV for now. > > > thanks! > > -pete > > > > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: #includes and #defined
On Fri, Aug 10, 2018 at 9:53 PM Warner Losh wrote: > > > On Thu, Aug 9, 2018 at 11:51 PM, Erich Dollansky < > freebsd.ed.li...@sumeritec.com> wrote: > >> Hi, >> >> On Fri, 10 Aug 2018 12:40:48 +0800 >> blubee blubeeme wrote: >> >> > On Fri, Aug 10, 2018 at 8:28 AM Erich Dollansky < >> > freebsd.ed.li...@sumeritec.com> wrote: >> > >> > > Hi, >> > > >> > > On Fri, 10 Aug 2018 08:01:42 +0800 >> > > blubee blubeeme wrote: >> > > >> > > > What's the proper way to define and include FreeBSD amd64 in GNU >> > > > Makefiles >> > > > >> > > > Do we define FreeBSD as x86_64 or amd64 also is it __FreeBSD__, >> > > > FreeBSD__, or __FreeBSD >> > > > >> > > > I've seen all of the above looking through different projects. >> > > >> > > clang defines '__FreeBSD__' >> > > >> > > Erich >> > > >> > >> > What about the architecture name is it recommended to use x86_64 or >> > amd64? >> >> my clang reports on an Intel CPU: >> >> #define __amd64 1 >> #define __amd64__ 1 >> #define __x86_64 1 >> #define __x86_64__ 1 >> >> as defined. >> >> It reports >> >> #define __aarch64__ 1 >> >> on an 64 bit ARM CPU. >> > > 'man 7 arch' will tell you these things: > >amd64 __amd64__, __x86_64__ > This is what I was looking for, thank you for the man page and it's good to see that these things are starting to get documented. > > it contains the preferred list of macros to use. Ideally, you'd use the > first one listed, though all the ones listed are supported. Others might > not be. > > Warner > Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: #includes and #defined
On Thu, Aug 9, 2018 at 11:51 PM, Erich Dollansky < freebsd.ed.li...@sumeritec.com> wrote: > Hi, > > On Fri, 10 Aug 2018 12:40:48 +0800 > blubee blubeeme wrote: > > > On Fri, Aug 10, 2018 at 8:28 AM Erich Dollansky < > > freebsd.ed.li...@sumeritec.com> wrote: > > > > > Hi, > > > > > > On Fri, 10 Aug 2018 08:01:42 +0800 > > > blubee blubeeme wrote: > > > > > > > What's the proper way to define and include FreeBSD amd64 in GNU > > > > Makefiles > > > > > > > > Do we define FreeBSD as x86_64 or amd64 also is it __FreeBSD__, > > > > FreeBSD__, or __FreeBSD > > > > > > > > I've seen all of the above looking through different projects. > > > > > > clang defines '__FreeBSD__' > > > > > > Erich > > > > > > > What about the architecture name is it recommended to use x86_64 or > > amd64? > > my clang reports on an Intel CPU: > > #define __amd64 1 > #define __amd64__ 1 > #define __x86_64 1 > #define __x86_64__ 1 > > as defined. > > It reports > > #define __aarch64__ 1 > > on an 64 bit ARM CPU. > 'man 7 arch' will tell you these things: amd64 __amd64__, __x86_64__ it contains the preferred list of macros to use. Ideally, you'd use the first one listed, though all the ones listed are supported. Others might not be. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ffs_truncate3 panics
Konstantin Belousov wrote: >On Thu, Aug 09, 2018 at 08:38:50PM +, Rick Macklem wrote: >> I did notice that my code locks the vnode first and then calls >> vn_start_write() >> for the vn_extattr_set() calls, whereas the syscall code locks the vnode >> after the vn_start_write() call. >> >> Does that matter? > >Yes, it matter. It would cause deadlocks when corresponding filesystem >is suspended in parallel with NFSD activities. vn_start_write() is a lock, >and the correct lock order is vn_start_write()->vnode lock. Ok, thanks, I'll work on a patch to fix this LOR. rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ix SR-IOV working
On 10.08.18 04:38, Pete Wright wrote: > hello, > > i have a newly provisioned VPS system from Vultr which comes stock with > a 10Gbe ix interface: > > ix0@pci0:1:0:0: class=0x02 card=0x082315d9 chip=0x15578086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82599 10 Gigabit Network Connection' > class = network > subclass = ethernet > > > it is currently running 11-STABLE but was curious if there are any > reports of people successfully running SR-IOV under CURRENT with this > hardware and driver? On both 11.2-RELEASE and 11-STABLE, after running > iovctl to bring up the interface results in the NIC hanging - for > example like so: > > $ sudo iovctl -C -f /etc/iovctl.conf > iovctl: Failed to configure SR-IOV: No space left on device > > I got the same error from a X540-AT2, but it didn't hang afterward. The NIC physical function worked just fine, but I found no way to create virtual functions. In the end i grabbed two dual port 1Gb/s cards and passed those to bhyve. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
