On Tue, Aug 18, 2020 at 3:19 PM Michael Butler
wrote:
>
> Any thoughts as to why this is happening when I build a (custom) kernel?
>
> kldxref: /boot/kernel/kernel: too many segments
I'm seeing this too. I haven't tried actually booting the kernel
because of this.
-Dustin
__
After having had some near-death-experiences in Greece I'm back to my
screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-)
But this is the experience with my Dell Vostro on 13 current:
After finally recompiling the kernel with the drm-module inside and
the trick of injecting the
Any thoughts as to why this is happening when I build a (custom) kernel?
kldxref: /boot/kernel/kernel: too many segments
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
I fixed several issues in our handling of the process group job control
state, biggest of which was uncovered by the reaping facility. The bugs
demostrate itself and underflow (and probably overflow) of pgrp->pg_jobc,
that was reported as panics with added and then removed asserts.
Feel free to p
On Tue, Aug 18, 2020 at 03:37:50PM +0200, Mateusz Guzik wrote:
> So the previous patch should just print a warning.
>
> Does this take care of the problem in general? I don't have means to
> test the patch.
>
Sorry for the delay, but finished patching & rebuilding, and
(essentially), yes. (
On 8/18/20, Mark Johnston wrote:
> On Tue, Aug 18, 2020 at 03:55:15PM +0200, Mateusz Guzik wrote:
>> On 8/18/20, Mark Johnston wrote:
>> > On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote:
>> >> Try this:
>> >>
>> >> diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c
>> >>
On Tue, Aug 18, 2020 at 03:55:15PM +0200, Mateusz Guzik wrote:
> On 8/18/20, Mark Johnston wrote:
> > On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote:
> >> Try this:
> >>
> >> diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c
> >> index 46eb1c4347c..7b94ca7b880 100644
> >>
On 8/18/20, Mark Johnston wrote:
> On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote:
>> Try this:
>>
>> diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c
>> index 46eb1c4347c..7b94ca7b880 100644
>> --- a/sys/kern/kern_malloc.c
>> +++ b/sys/kern/kern_malloc.c
>> @@ -618,8 +6
On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote:
> Try this:
>
> diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c
> index 46eb1c4347c..7b94ca7b880 100644
> --- a/sys/kern/kern_malloc.c
> +++ b/sys/kern/kern_malloc.c
> @@ -618,8 +618,8 @@ void *
> unsigned long osi
So the previous patch should just print a warning.
Does this take care of the problem in general? I don't have means to
test the patch.
diff --git a/sys/cam/scsi/scsi_pass.c b/sys/cam/scsi/scsi_pass.c
index b299fbddd84..c6d6a5da403 100644
--- a/sys/cam/scsi/scsi_pass.c
+++ b/sys/cam/scsi/scsi_pas
Hello,
this sould take care of it (in that it will print the warning, but not
panic the box):
diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c
index 46eb1c4347c..7b94ca7b880 100644
--- a/sys/kern/kern_malloc.c
+++ b/sys/kern/kern_malloc.c
@@ -618,8 +618,8 @@ void *
unsigned lo
On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote:
> Try this:
> [replacing new KASSERT() with WITNESS_WARN()...]
>
Thanks; on it. Should take care of it, I think.
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Donald Trump is either ignor
Try this:
diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c
index 46eb1c4347c..7b94ca7b880 100644
--- a/sys/kern/kern_malloc.c
+++ b/sys/kern/kern_malloc.c
@@ -618,8 +618,8 @@ void *
unsigned long osize = size;
#endif
- KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP
On Tue, Aug 18, 2020 at 02:48:47PM +0200, Mateusz Guzik wrote:
> see https://reviews.freebsd.org/D26027
>
Right; I was just reviewing the list of updated files and noted
src/sys/kern/kern_malloc.c, and its svn log showed:
--
see https://reviews.freebsd.org/D26027
On 8/18/20, David Wolfskill wrote:
> Just did a src update from r364296 -> r364341 on amd64 on my bild
> machine (laptop is still working -- it built firefox earlier, which
> takes some time). On initial reboot, the build machine panicked:
>
> umass0: SCSI
Just did a src update from r364296 -> r364341 on amd64 on my bild
machine (laptop is still working -- it built firefox earlier, which
takes some time). On initial reboot, the build machine panicked:
umass0: SCSI over Bulk-Only; quirks = 0x4000
umass0:6:0: Attached to scbus6
(probe0:umass-sim0:0:
On Mon, 17 Aug 2020 21:49:52 +0200
Dimitry Andric wrote:
> On 17 Aug 2020, at 15:42, O. Hartmann wrote:
> >
> > On CURRENT 9not necessarily most recent with LLVM11, but since noon of
> > today it
> > is FreeBSD 13.0-CURRENT #15 r364297: Mon Aug 17 14:39:06 CEST 2020 amd64)
> > I'm
> > faced w
On Mon, 17 Aug 2020 21:49:52 +0200
Dimitry Andric wrote:
> On 17 Aug 2020, at 15:42, O. Hartmann wrote:
> >
> > On CURRENT 9not necessarily most recent with LLVM11, but since noon
> > of today it is FreeBSD 13.0-CURRENT #15 r364297: Mon Aug 17
> > 14:39:06 CEST 2020 amd64) I'm faced with some v
On Tue, 18 Aug 2020 10:25:10 +0200
Emmanuel Vadot wrote:
> On Mon, 17 Aug 2020 20:44:38 +0200
> Jan Beich wrote:
>
> > Emmanuel Vadot writes:
> >
> > > Hello,
> > >
> > > 5.4 was finilly reached !
> > > For AMD users it means that Navi12/14, Arctarus and Renoir should work.
> > > For Inte
In a aarch64 head -r363590 context with g++9 from ports
in use (so ffsl is only compiler-defined outside strict
ISO modes) . . .
I got a compile failure for using CPU_FFS because ffsl
"was not declared". My code was being compiled via
-std=c++17 . (Other than enabling one feature, it is
not system
On Mon, 17 Aug 2020 20:44:38 +0200
Jan Beich wrote:
> Emmanuel Vadot writes:
>
> > Hello,
> >
> > 5.4 was finilly reached !
> > For AMD users it means that Navi12/14, Arctarus and Renoir should work.
> > For Intel users it means that TigerLake should work too.
> >
> > No ports update for n
21 matches
Mail list logo
