Chris writes:
> >"make buildowrld" fails with:
> >
> > > c++ -O2 -pipe -fno-common
> > > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang
> > > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm
> > > -I/usr/src/contrib/llvm-project/clang/lib/Basic
> >
On Mon, Apr 27, 2020 at 4:51 AM Konstantin Belousov
wrote:
> On Mon, Apr 27, 2020 at 11:39:41AM +0200, Mateusz Piotrowski wrote:
> > Hi everyone!
> >
> > I'm experiencing panics every day. Apparently, they are caused by a bug
> in
> > our FUSE implementation.
> >
> > The panic occurs when I'm edi
Hi,
I would like to share the current state and the next steps for the
nhops/multipath project.
To recap: project is about modernising the current routing stack and
implementing scalable multipath routing.
Most changes are based on introduction of the concept of nexthops. Nexthops,
which are
[More details for a sshd failure. The other
examples are omitted. The sshd failure also shows
a all-zeros-up-to-a-page-boundary issue, just for
a different address range.]
On 2020-May-7, at 12:06, Mark Millard wrote:
>
> [mountd failure example: also at sz_size2index_lookup assert
> for the same
On Fri, May 08, 2020 at 11:22:51AM -0700, John Baldwin wrote:
> On 5/7/20 10:17 AM, Warner Losh wrote:
> > On Thu, May 7, 2020 at 10:38 AM Eric van Gyzen wrote:
> >
> >> If I were to clean up obsolete ${COMPILER_VERSION} tests in the tree,
> >> which ones should I keep? I would probably confine
On 5/8/20 1:22 PM, John Baldwin wrote:
I think Eric though was asking about and the like.
Actually, I was asking about makefile conditions, but this is still a
good discussion to have. I'm in a cleanup mood.
(BTW, it would be good to know if it's at all useful to keep any of the
icc bits
On 5/7/20 10:17 AM, Warner Losh wrote:
> On Thu, May 7, 2020 at 10:38 AM Eric van Gyzen wrote:
>
>> If I were to clean up obsolete ${COMPILER_VERSION} tests in the tree,
>> which ones should I keep? I would probably confine it to head, so I
>> could prune quite a few.
>>
>
> Anything in the boo
On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote:
>
> I have a reproducible panic with a custom kernel without option NUMA while
> using
> amdgpu driver from linuxkpi-based drm:
>
> panic: address 41ec0 beyond the last segment
>
> I did some quick debugging and the panic happens
I have a reproducible panic with a custom kernel without option NUMA while using
amdgpu driver from linuxkpi-based drm:
panic: address 41ec0 beyond the last segment
I did some quick debugging and the panic happens when Xorg server tries to
access a frame buffer (or something like that). The
