On Thu, Mar 14, 2019 at 8:06 PM Andrew Thompson wrote:
>
> On Fri, 15 Mar 2019 at 15:11, Chuck Tuffli wrote:
>> bzero(&pciecap, sizeof(pciecap));
...
>> + pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
>
> If the message you say 'set the bit' but you are overwriting the
Before all of the uuencoded files get decoded in the tree.. are we sure that
non-uuencoded binary files will be proper identified if the mime type is
nonexistent in svn? What about other VCSes like hg?
I’m asking, because not all downstream vendors have the newest versions of svn,
once upon a t
> On Mar 14, 2019, at 20:26, Warner Losh wrote:
>
>
>
>> On Thu, Mar 14, 2019 at 9:14 PM Ed Maste wrote:
>> On Thu, 14 Mar 2019 at 22:46, Warner Losh wrote:
>> >
>> > Libarchive tests and a few bzip2 files are all that is left in contrib.
>> > All can be converted without hassle from what
On Thu, Mar 14, 2019 at 9:36 PM Rodney W. Grimes
wrote:
> [ Charset UTF-8 unsupported, converting... ]
> > On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
> > wrote:
> > >
> > > 4. There is no easy way to show
> > >"changed byte at offset 0x432 from 0xef to 0xfe"
>
> How do we represent Copyr
On Thu, Mar 14, 2019 at 9:31 PM Ed Maste wrote:
> On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
> wrote:
> >
> > 4. There is no easy way to show
> >"changed byte at offset 0x432 from 0xef to 0xfe"
>
> But this is not that easy with uuencoded files, either - I'd just end
> up uudecoding both
[ Charset UTF-8 unsupported, converting... ]
> On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
> wrote:
> >
> > 4. There is no easy way to show
> >"changed byte at offset 0x432 from 0xef to 0xfe"
How do we represent Copyright and License in such objects?
This is an issue that is totally left o
On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
wrote:
>
> 4. There is no easy way to show
>"changed byte at offset 0x432 from 0xef to 0xfe"
But this is not that easy with uuencoded files, either - I'd just end
up uudecoding both files before running cmp -x. And for the case under
discussion h
On Thu, Mar 14, 2019 at 9:14 PM Ed Maste wrote:
> On Thu, 14 Mar 2019 at 22:46, Warner Losh wrote:
> >
> > Libarchive tests and a few bzip2 files are all that is left in contrib.
> All can be converted without hassle from what I can see.
>
> But these (libarchive at least) are uuencoded in the u
On Thu, 14 Mar 2019 at 22:46, Warner Losh wrote:
>
> Libarchive tests and a few bzip2 files are all that is left in contrib. All
> can be converted without hassle from what I can see.
But these (libarchive at least) are uuencoded in the upstream repo,
and we won't make a local change to undo tha
On Fri, 15 Mar 2019 at 15:11, Chuck Tuffli wrote:
> Author: chuck
> Date: Fri Mar 15 02:11:28 2019
> New Revision: 345171
> URL: https://svnweb.freebsd.org/changeset/base/345171
>
> Log:
> Fix bhyve PCIe capability emulation
>
> PCIe devices starting with version 1.1 must set the Role-Based E
On Thu, 14 Mar 2019 at 22:34, Rodney W. Grimes
wrote:
>
> > We definitely don't want to change files in contrib/ - that's up to
> > the upstreams.
>
> I think you miss understood, I belive in the paste, and possibly even
> still, that prep work was done to vendor code before import. We use
> to h
On Thu, Mar 14, 2019, 8:35 PM Rodney W. Grimes
wrote:
> > On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
> > wrote:
> > >
> > > Covered this in my reply to Warners reply. I think we also need to
> > > look at how this might affect vendor imported stuff, is there some if
> > > it that was .uu'ed
> On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
> wrote:
> >
> > > The reason not to do it is uuencoding adds about a 40% space penalty,
> > > adds to the build time (to uudecode), and makes changes harder to
> > > review. In my mind dropping the unnecessary uuencoding is similar to
> > > droppin
On Thu, 14 Mar 2019 at 22:05, Rodney W. Grimes
wrote:
>
> How do the tools today deal with taking a binary off the vendor branch?
> Isn't this still a for-ever night mare merge thing to deal with?
There isn't really the concept of taking a file off the vendor branch
in the same way as with CVS, a
> On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
> wrote:
> >
> > Covered this in my reply to Warners reply. I think we also need to
> > look at how this might affect vendor imported stuff, is there some if
> > it that was .uu'ed before import?
>
> We definitely don't want to change files in con
> Author: chuck
> Date: Fri Mar 15 02:11:28 2019
> New Revision: 345171
> URL: https://svnweb.freebsd.org/changeset/base/345171
>
> Log:
> Fix bhyve PCIe capability emulation
>
> PCIe devices starting with version 1.1 must set the Role-Based Error
> Reporting bit.
>
> And while we're
> Author: ygy (doc committer)
> Date: Fri Mar 15 00:20:28 2019
> New Revision: 345168
> URL: https://svnweb.freebsd.org/changeset/base/345168
>
> Log:
> Add myself to committers-doc.dot.
>
> Reminded by:rgrimes
Thank you
> Modified:
> head/share/misc/committers-doc.dot
>
> Modi
On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
wrote:
>
> > The reason not to do it is uuencoding adds about a 40% space penalty,
> > adds to the build time (to uudecode), and makes changes harder to
> > review. In my mind dropping the unnecessary uuencoding is similar to
> > dropping build-time p
On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
wrote:
>
> Covered this in my reply to Warners reply. I think we also need to
> look at how this might affect vendor imported stuff, is there some if
> it that was .uu'ed before import?
We definitely don't want to change files in contrib/ - that's u
Author: chuck
Date: Fri Mar 15 02:11:27 2019
New Revision: 345170
URL: https://svnweb.freebsd.org/changeset/base/345170
Log:
Fix bhyve's NVMe Identify Namespace data
The NVMe Identify Namespace data structure's Number of LBA Formats
(NLBAF) field is a 0's based value (i.e. 0x0 means 1). S
Author: chuck
Date: Fri Mar 15 02:11:28 2019
New Revision: 345171
URL: https://svnweb.freebsd.org/changeset/base/345171
Log:
Fix bhyve PCIe capability emulation
PCIe devices starting with version 1.1 must set the Role-Based Error
Reporting bit.
And while we're in the neighborhood, ge
On Thu, Mar 14, 2019, 7:38 PM Rodney W. Grimes
wrote:
> > I think maybe there was also a limitation on the
> (repo-replication-over-email?) mechanism that we used to use? That rings a
> very faint bell for me for some reason, even though I'm pretty sure it was
> dead long before I got my bit.
>
>
> On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> wrote:
> >
> > We should of documented what the decision process and criteria was
> > that lead to the decission to uuencode the files.
>
> Doing some archaeology, the first instance of a uuencoded file I can
> find is r1796, "Got rid of a couple
> On Thu, Mar 14, 2019 at 3:43 PM Ed Maste wrote:
>
> > On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> > wrote:
> > >
> > > We should of documented what the decision process and criteria was
> > > that lead to the decission to uuencode the files.
> >
> > Doing some archaeology, the first insta
On Thu, 14 Mar 2019 at 21:51, Marcelo Araujo wrote:
>
> So there is some license concern around this patch, core@ reverted my first
> attempt to import this patch from Illumos.
Conrad wrote the patch based on the description I posted on twitter,
it's not imported from anywhere.
However, I was n
>
> In message
>
> , Ed Maste writes:
> >On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
>
> >Doing some archaeology, the first instance of a uuencoded file I can
> >find is r1796, "Got rid of a couple of binary files by uuencoding. 49
> >more to go." There's no explanation of why the c
Em sex, 15 de mar de 2019 às 05:09, Conrad Meyer escreveu:
> Author: cem
> Date: Thu Mar 14 21:08:48 2019
> New Revision: 345158
> URL: https://svnweb.freebsd.org/changeset/base/345158
>
> Log:
> bhyve(8): Fix uart emulation bug
>
> THRE is always asserted in LSR reads, so REG_IER writes that
> Author: cem
> Date: Thu Mar 14 21:08:48 2019
> New Revision: 345158
> URL: https://svnweb.freebsd.org/changeset/base/345158
>
> Log:
> bhyve(8): Fix uart emulation bug
>
> THRE is always asserted in LSR reads, so REG_IER writes that raise
> IER_ETXRDY must also set thre_int_pending.
>
> I think maybe there was also a limitation on the
> (repo-replication-over-email?) mechanism that we used to use? That rings a
> very faint bell for me for some reason, even though I'm pretty sure it was
> dead long before I got my bit.
CTM is still in use today, in a recent action to depricat
Author: mmacy
Date: Fri Mar 15 01:26:10 2019
New Revision: 345169
URL: https://svnweb.freebsd.org/changeset/base/345169
Log:
bump version to reflect MFC of CCM for the benefit of the ZoF port
Sponsored by: iX Systems
Modified:
stable/12/sys/sys/param.h
Modified: stable/12/sys/sys/param.
Author: ygy (doc committer)
Date: Fri Mar 15 00:20:28 2019
New Revision: 345168
URL: https://svnweb.freebsd.org/changeset/base/345168
Log:
Add myself to committers-doc.dot.
Reminded by: rgrimes
Modified:
head/share/misc/committers-doc.dot
Modified: head/share/misc/committers-doc.dot
==
On Thu, Mar 14, 2019 at 3:43 PM Ed Maste wrote:
> On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> wrote:
> >
> > We should of documented what the decision process and criteria was
> > that lead to the decission to uuencode the files.
>
> Doing some archaeology, the first instance of a uuencoded
On Friday, April 6, 2018, Ed Schouten wrote:
> Author: ed
> Date: Fri Apr 6 13:00:45 2018
> New Revision: 332100
> URL: https://svnweb.freebsd.org/changeset/base/332100
>
> Log:
> Let syslog(3) use RFC 5424.
>
> With r332099 changing syslogd(8) to parse RFC 5424 formatted syslog
> messages
Author: glebius
Date: Thu Mar 14 22:52:16 2019
New Revision: 345166
URL: https://svnweb.freebsd.org/changeset/base/345166
Log:
PFIL_MEMPTR for ipfw link level hook
With new pfil(9) KPI it is possible to pass a void pointer with length
instead of mbuf pointer to a packet filter. Until this
In message
, Ed Maste writes:
>On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
>Doing some archaeology, the first instance of a uuencoded file I can
>find is r1796, "Got rid of a couple of binary files by uuencoding. 49
>more to go." There's no explanation of why the change was made.
I
Author: glebius
Date: Thu Mar 14 22:32:50 2019
New Revision: 345165
URL: https://svnweb.freebsd.org/changeset/base/345165
Log:
Remove 'dir' argument from dummynet_io(). This makes it possible to make
dn_dir flags private to dummynet. There is still some room for improvement.
Modified:
head/
Author: glebius
Date: Thu Mar 14 22:31:12 2019
New Revision: 345164
URL: https://svnweb.freebsd.org/changeset/base/345164
Log:
Reduce argument list to ipfw_divert(), as args holds the rule ref and
the direction. While here make 'tee' a bool.
Modified:
head/sys/netpfil/ipfw/ip_fw_pfil.c
Mod
Author: glebius
Date: Thu Mar 14 22:30:05 2019
New Revision: 345163
URL: https://svnweb.freebsd.org/changeset/base/345163
Log:
Remove 'dir' argument in ng_ipfw_input, since ip_fw_args now has this info.
While here make 'tee' boolean.
Modified:
head/sys/netgraph/ng_ipfw.c
head/sys/netinet/
Author: glebius
Date: Thu Mar 14 22:28:50 2019
New Revision: 345162
URL: https://svnweb.freebsd.org/changeset/base/345162
Log:
- Add more flags to ip_fw_args. At this changeset only IPFW_ARGS_IN and
IPFW_ARGS_OUT are utilized. They are intented to substitute the "dir"
parameter that is o
Author: glebius
Date: Thu Mar 14 22:23:09 2019
New Revision: 345161
URL: https://svnweb.freebsd.org/changeset/base/345161
Log:
Make second argument of ip_divert(), that specifies packet direction a bool.
This allows pf(4) to avoid including ipfw(4) private files.
Modified:
head/sys/netinet/
Author: glebius
Date: Thu Mar 14 22:20:48 2019
New Revision: 345160
URL: https://svnweb.freebsd.org/changeset/base/345160
Log:
Simplify ipfw_bpf_mtap2(). No functional change.
Modified:
head/sys/netpfil/ipfw/ip_fw_bpf.c
Modified: head/sys/netpfil/ipfw/ip_fw_bpf.c
Author: manu
Date: Thu Mar 14 22:08:09 2019
New Revision: 345159
URL: https://svnweb.freebsd.org/changeset/base/345159
Log:
pkgbase: Use uname as ABI_FILE
uname is always rebuild on FreeBSD so use this as ABI_FILE for pkg when
building pkg for pkgbase.
pkg uses uname too as default ABI_
On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
wrote:
>
> We should of documented what the decision process and criteria was
> that lead to the decission to uuencode the files.
Doing some archaeology, the first instance of a uuencoded file I can
find is r1796, "Got rid of a couple of binary files
Author: cem
Date: Thu Mar 14 21:08:48 2019
New Revision: 345158
URL: https://svnweb.freebsd.org/changeset/base/345158
Log:
bhyve(8): Fix uart emulation bug
THRE is always asserted in LSR reads, so REG_IER writes that raise
IER_ETXRDY must also set thre_int_pending.
Reported by: Illu
On 4/6/18 6:00 AM, Ed Schouten wrote:
> Author: ed
> Date: Fri Apr 6 13:00:45 2018
> New Revision: 332100
> URL: https://svnweb.freebsd.org/changeset/base/332100
>
> Log:
> Let syslog(3) use RFC 5424.
>
> With r332099 changing syslogd(8) to parse RFC 5424 formatted syslog
> messages, go
CTM was fixed years ago...
Warner
On Thu, Mar 14, 2019, 1:32 PM Ravi Pokala wrote:
> I think maybe there was also a limitation on the
> (repo-replication-over-email?) mechanism that we used to use? That rings a
> very faint bell for me for some reason, even though I'm pretty sure it was
> dead
Author: dim
Date: Thu Mar 14 20:32:46 2019
New Revision: 345156
URL: https://svnweb.freebsd.org/changeset/base/345156
Log:
Vendor import of LLVM openmp release_80 branch r356034:
https://llvm.org/svn/llvm-project/openmp/branches/release_80@356034
Modified:
vendor/llvm-openmp/dist-release_80
Author: dim
Date: Thu Mar 14 20:32:48 2019
New Revision: 345157
URL: https://svnweb.freebsd.org/changeset/base/345157
Log:
Tag LLVM openmp release_80 branch r356034.
Added:
vendor/llvm-openmp/openmp-release_80-r356034/
- copied from r345156, vendor/llvm-openmp/dist-release_80/
__
Author: dim
Date: Thu Mar 14 20:10:27 2019
New Revision: 345154
URL: https://svnweb.freebsd.org/changeset/base/345154
Log:
Tag LLVM openmp trunk r351319 (just before the release_80 branch point).
Added:
vendor/llvm-openmp/openmp-trunk-r351319/
- copied from r345153, vendor/llvm-openmp/di
On 14 Mar 2019, at 19:48, Kyle Evans wrote:
Author: kevans
Date: Thu Mar 14 19:48:43 2019
New Revision: 345151
URL: https://svnweb.freebsd.org/changeset/base/345151
Log:
ether_fakeaddr: Use 'b' 's' 'd' for the prefix
This has the advantage of being obvious to sniff out the designated
pref
Author: dim
Date: Thu Mar 14 20:11:46 2019
New Revision: 345155
URL: https://svnweb.freebsd.org/changeset/base/345155
Log:
Branch vendor/llvm-openmp/dist to vendor/llvm-openmp/dist-release_80, to
allow for independent merges of the upstream trunk and release_80
branches.
Added:
vendor/llv
Author: dim
Date: Thu Mar 14 20:09:10 2019
New Revision: 345153
URL: https://svnweb.freebsd.org/changeset/base/345153
Log:
Vendor import of LLVM openmp trunk r351319 (just before the release_80
branch point):
https://llvm.org/svn/llvm-project/openmp/trunk@351319
Added:
vendor/llvm-openmp/
Author: dim
Date: Thu Mar 14 19:52:12 2019
New Revision: 345152
URL: https://svnweb.freebsd.org/changeset/base/345152
Log:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, and lldb
release_80 branch r356034 (effectively, 8.0.0 rc5), resolve conflicts,
and bump version numbers.
PR
Author: kevans
Date: Thu Mar 14 19:48:43 2019
New Revision: 345151
URL: https://svnweb.freebsd.org/changeset/base/345151
Log:
ether_fakeaddr: Use 'b' 's' 'd' for the prefix
This has the advantage of being obvious to sniff out the designated prefix
by eye and it has all the right bits set.
Author: dim
Date: Thu Mar 14 19:41:20 2019
New Revision: 345145
URL: https://svnweb.freebsd.org/changeset/base/345145
Log:
Tag clang release_80 branch r356034.
Added:
vendor/clang/clang-release_80-r356034/
- copied from r345144, vendor/clang/dist-release_80/
_
Author: dim
Date: Thu Mar 14 19:41:34 2019
New Revision: 345150
URL: https://svnweb.freebsd.org/changeset/base/345150
Log:
Tag lldb release_80 branch r356034.
Added:
vendor/lldb/lldb-release_80-r356034/
- copied from r345149, vendor/lldb/dist-release_80/
_
Author: dim
Date: Thu Mar 14 19:41:31 2019
New Revision: 345149
URL: https://svnweb.freebsd.org/changeset/base/345149
Log:
Tag lld release_80 branch r356034.
Added:
vendor/lld/lld-release_80-r356034/
- copied from r345148, vendor/lld/dist-release_80/
_
Author: dim
Date: Thu Mar 14 19:41:10 2019
New Revision: 345142
URL: https://svnweb.freebsd.org/changeset/base/345142
Log:
Vendor import of llvm release_80 branch r356034:
https://llvm.org/svn/llvm-project/llvm/branches/release_80@356034
Modified:
vendor/llvm/dist-release_80/docs/ReleaseNot
Author: dim
Date: Thu Mar 14 19:41:26 2019
New Revision: 345147
URL: https://svnweb.freebsd.org/changeset/base/345147
Log:
Tag libc++ release_80 branch r356034.
Added:
vendor/libc++/libc++-release_80-r356034/
- copied from r345146, vendor/libc++/dist-release_80/
_
Author: dim
Date: Thu Mar 14 19:41:28 2019
New Revision: 345148
URL: https://svnweb.freebsd.org/changeset/base/345148
Log:
Tag LLVM libunwind release_80 branch r356034.
Added:
vendor/llvm-libunwind/libunwind-release_80-r356034/
- copied from r345147, vendor/llvm-libunwind/dist-release_80
Author: dim
Date: Thu Mar 14 19:41:16 2019
New Revision: 345144
URL: https://svnweb.freebsd.org/changeset/base/345144
Log:
Vendor import of clang release_80 branch r356034:
https://llvm.org/svn/llvm-project/cfe/branches/release_80@356034
Modified:
vendor/clang/dist-release_80/lib/AST/ExprCo
Author: dim
Date: Thu Mar 14 19:41:13 2019
New Revision: 345143
URL: https://svnweb.freebsd.org/changeset/base/345143
Log:
Tag llvm release_80 branch r356034.
Added:
vendor/llvm/llvm-release_80-r356034/
- copied from r345142, vendor/llvm/dist-release_80/
_
Author: dim
Date: Thu Mar 14 19:41:22 2019
New Revision: 345146
URL: https://svnweb.freebsd.org/changeset/base/345146
Log:
Tag compiler-rt release_80 branch r356034.
Added:
vendor/compiler-rt/compiler-rt-release_80-r356034/
- copied from r345145, vendor/compiler-rt/dist-release_80/
_
I think maybe there was also a limitation on the (repo-replication-over-email?)
mechanism that we used to use? That rings a very faint bell for me for some
reason, even though I'm pretty sure it was dead long before I got my bit.
-Ravi (rpokala@)
-Original Message-
From: on behalf of
On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
wrote:
>
> [ Charset UTF-8 unsupported, converting... ]
> > Author: emaste
> > Date: Thu Mar 14 17:09:07 2019
> > New Revision: 345138
> > URL: https://svnweb.freebsd.org/changeset/base/345138
> >
> > Log:
> > firmware(9): remove uuencoded example
>
Author: kib
Date: Thu Mar 14 19:07:41 2019
New Revision: 345141
URL: https://svnweb.freebsd.org/changeset/base/345141
Log:
mips: remove dead comment and definitions.
Reviewed by: brooks, jhb
Sponsored by: The FreeBSD Foundation
MFC after:3 days
Differential revision:https
[ Charset UTF-8 unsupported, converting... ]
> Author: emaste
> Date: Thu Mar 14 17:09:07 2019
> New Revision: 345138
> URL: https://svnweb.freebsd.org/changeset/base/345138
>
> Log:
> firmware(9): remove uuencoded example
>
> We can (should) just commit the binary files to the source tree.
Author: kevans
Date: Thu Mar 14 17:18:00 2019
New Revision: 345139
URL: https://svnweb.freebsd.org/changeset/base/345139
Log:
ether: centralize fake hwaddr generation
We currently have two places with identical fake hwaddr generation --
if_vxlan and if_bridge. Lift it into if_ethersubr fo
Author: emaste
Date: Thu Mar 14 17:09:07 2019
New Revision: 345138
URL: https://svnweb.freebsd.org/changeset/base/345138
Log:
firmware(9): remove uuencoded example
We can (should) just commit the binary files to the source tree.
Reviewed by: bz, imp, 0mp
Differential Revision:
Author: emaste
Date: Thu Mar 14 17:05:46 2019
New Revision: 345137
URL: https://svnweb.freebsd.org/changeset/base/345137
Log:
Remove radeonkmsfw firmware files
The drivers were removed in r344299 so there is no need to keep the
firmware files in the src tree.
Reviewed by: imp, jhibb
Author: brooks
Date: Thu Mar 14 15:56:34 2019
New Revision: 345136
URL: https://svnweb.freebsd.org/changeset/base/345136
Log:
Style(9): add a missing space between argument declerations.
Modified:
head/sys/mips/mips/vm_machdep.c
Modified: head/sys/mips/mips/vm_machdep.c
=
Author: brooks
Date: Thu Mar 14 15:55:30 2019
New Revision: 345135
URL: https://svnweb.freebsd.org/changeset/base/345135
Log:
Remove an unused struct proc *p1 in cpu_fork().
The only reference to p1 after a dead store was in a comment so update
the comment to refer to td1.
Submitted
Author: 0mp (ports committer)
Date: Thu Mar 14 14:34:36 2019
New Revision: 345132
URL: https://svnweb.freebsd.org/changeset/base/345132
Log:
chroot.8: Add examples & clean up
- Sort arguments in synopsis.
- Clarify that it is possible to specify arguments to the command (and that
they
Author: emaste
Date: Thu Mar 14 13:28:21 2019
New Revision: 345131
URL: https://svnweb.freebsd.org/changeset/base/345131
Log:
Remove npe microcode
The driver was removed in r336436.
Deleted:
head/sys/contrib/dev/npe/
___
svn-src-all@freebsd.org
Author: eugen
Date: Thu Mar 14 12:25:16 2019
New Revision: 345130
URL: https://svnweb.freebsd.org/changeset/base/345130
Log:
trim(8): add another safety net
It is quite easy make a mistake and run something like this:
trim -f /dev/da0 -r rfile
This would trim the whole devic
On Thu, Mar 14, 2019 at 12:04:30PM +, Johannes Lundberg wrote:
>
> On 3/14/19 11:45 AM, Konstantin Belousov wrote:
> > On Thu, Mar 14, 2019 at 11:07:50AM +, Johannes Lundberg wrote:
> >> On 3/13/19 11:39 PM, John Baldwin wrote:
> >>> On 3/13/19 1:36 PM, Conrad Meyer wrote:
> Hi,
> >>>
On 3/14/19 11:45 AM, Konstantin Belousov wrote:
> On Thu, Mar 14, 2019 at 11:07:50AM +, Johannes Lundberg wrote:
>> On 3/13/19 11:39 PM, John Baldwin wrote:
>>> On 3/13/19 1:36 PM, Conrad Meyer wrote:
Hi,
A lot of the information about PCIe devices is read by PCI probe and
On Thu, Mar 14, 2019 at 11:07:50AM +, Johannes Lundberg wrote:
>
> On 3/13/19 11:39 PM, John Baldwin wrote:
> > On 3/13/19 1:36 PM, Conrad Meyer wrote:
> >> Hi,
> >>
> >> A lot of the information about PCIe devices is read by PCI probe and
> >> cached on the (BSD) device. You could access it
On 3/13/19 11:39 PM, John Baldwin wrote:
> On 3/13/19 1:36 PM, Conrad Meyer wrote:
>> Hi,
>>
>> A lot of the information about PCIe devices is read by PCI probe and
>> cached on the (BSD) device. You could access it out of
>> device_get_ivars(bsddev)->cfg.pcie and avoid the MMIO latency.
> Agree
Author: smh
Date: Thu Mar 14 10:06:46 2019
New Revision: 345129
URL: https://svnweb.freebsd.org/changeset/base/345129
Log:
Revert zfsimpl.c accidentally committed in r345128
Revert an unrelated change to zfsimpl.c accidentally committed in r345128.
Sponsored by: Multiplay
Modified:
Author: smh
Date: Thu Mar 14 10:03:04 2019
New Revision: 345128
URL: https://svnweb.freebsd.org/changeset/base/345128
Log:
MFC r344701: Fix incorrect / unused sector_count for identify requests
Fix unused sector_count for identify requests from camcontrol by changing
to zero which is a mo
Author: hselasky
Date: Thu Mar 14 09:18:54 2019
New Revision: 345127
URL: https://svnweb.freebsd.org/changeset/base/345127
Log:
Revert r345102 until the DRM next port issues are resolved.
Requested by: Johannes Lundberg
MFC after:1 week
Sponsored by: Mellano
Author: ae
Date: Thu Mar 14 08:27:01 2019
New Revision: 345126
URL: https://svnweb.freebsd.org/changeset/base/345126
Log:
MFC r344873:
Fix typo.
Modified:
stable/11/sys/amd64/amd64/vm_machdep.c
stable/11/sys/i386/i386/vm_machdep.c
Directory Properties:
stable/11/ (props changed)
Mo
Author: ae
Date: Thu Mar 14 08:25:28 2019
New Revision: 345125
URL: https://svnweb.freebsd.org/changeset/base/345125
Log:
MFC r344873:
Fix typo.
Modified:
stable/12/sys/amd64/amd64/vm_machdep.c
stable/12/sys/i386/i386/vm_machdep.c
Directory Properties:
stable/12/ (props changed)
Mo
84 matches
Mail list logo
