So, the big list of unknown symbols was my fault! Whoops.
i've gotten further using gcc-6.4 by fixing some of the warnings/issues
that have crept up.
Here's a review for one of them:
https://reviews.freebsd.org/D26504
However, now I've hit:
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home
Hi Shawn,
Is it possible to reproduce the issue on FreeBSD? The excerpt you've
linked to is not on FreeBSD.
Conrad
On Sun, Sep 20, 2020 at 5:53 PM Shawn Webb wrote:
>
> From latest HEAD on a Dell Precision 7550 laptop:
>
> https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2
>
> Th
>From latest HEAD on a Dell Precision 7550 laptop:
https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2
The last working boot environment was 14 Aug 2020. If I get some time to
bisect commits, I'll try to figure out the culprit.
Thanks,
Shawn Webb
(Sorry for the brevity. Only parti
On Sun, 20 Sep 2020 at 15:37, Rick Macklem wrote:
> Christian Weisgerber wrote:
> > On 2020-09-19, Zaphod Beeblebrox wrote:
> >
> > > Hrm. Maybe what I hear others saying, tho, and not entirely being
> replied
> > > to is just a nice concise document of the why. What I hear you saying
> is
> >
Christian Weisgerber wrote:
> On 2020-09-19, Zaphod Beeblebrox wrote:
>
> > Hrm. Maybe what I hear others saying, tho, and not entirely being replied
> > to is just a nice concise document of the why. What I hear you saying is
> > that GIT has momentum and that it's popular... (and I accept tha
hi!
So mips32 and gcc9 is broken, and things have been broken with mips32+gcc
for months now.
I've been poking slowly at the various build failures and they're getting
slowly fixed, but this one deep in linker fun is stumping me:
===
/usr/local/bin/mips-unknown-freebsd13.0-gcc9
--sysroot=/usr/h
On 9/20/20 10:58 AM, Mark Murray wrote:
Hi *
I've been getting these build failures for a while (weeks/months). The machine is a MacchiatoBin
DoubleShot (arm64, Quad core). with SATA disks and zfs filesystem. If I empty out /usr/obj, then
the build works, but takes a few hours. If I do a no-cl
hi!
This code fails compilation on mips32 + gcc, as it assumes uint64_t and
pointer casts are the same underlying size.
===
/usr/local/bin/mips-unknown-freebsd13.0-gcc9
--sysroot=/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp
On 2020-09-20 12:28, Andriy Gapon wrote:
> Just my +100500 to this.
>
> On 20/09/2020 18:03, Christian Weisgerber wrote:
>> On 2020-09-19, Zaphod Beeblebrox wrote:
>>
>>> Hrm. Maybe what I hear others saying, tho, and not entirely being
replied
>>> to is just a nice concise document of the why.
On 20.09.20 22:07, Konstantin Belousov wrote:
> On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote:
>> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote:
>>> Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling
On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote:
> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote:
> > Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
> > > On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
> > >> Am 20.09.20 um 10:20 schrieb Hans
On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote:
> Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
> > On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
> >> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
> >>> On 2020-09-20 10:05, Rainer Hurling wrote:
> Hi m
Just my +100500 to this.
On 20/09/2020 18:03, Christian Weisgerber wrote:
> On 2020-09-19, Zaphod Beeblebrox wrote:
>
>> Hrm. Maybe what I hear others saying, tho, and not entirely being replied
>> to is just a nice concise document of the why. What I hear you saying is
>> that GIT has momentu
On 19.09.2020 19:05, Bakul Shah wrote:
>> These are the main ones. The three down sides are lack of $FreeBSD$ support
>> and tags in general.
>
> Can a git hook be used for this?
git filters could be used for that, problem is it should be local
configuration. You could not configure filters in
A couple of weeks for now it is impossible to compile nanoBSD (based on
12-STABLE, most recent r365925), compiled on a host running recent
CURRENT (FreeBSD 13.0-CURRENT #0 r365487: Fri Sep 18 16:31:04 CEST 2020
amd64). Since the introduction of LLVM 10 to 12-STABLE and LLVM 11 to
CURRENT, the (cros
On Sun, Sep 20, 2020 at 9:41 AM Pete Wright wrote:
>
> >> making quarterly reports about this for almost a years as well. We put
> out
> >> calls for people to help with the efforts about the same time. We have
> >> tried at every step of the way to be open and honest that this was
> going to
> >
On Sun, Sep 20, 2020 at 08:41:13AM -0700, Pete Wright wrote:
>
> > > making quarterly reports about this for almost a years as well. We put out
> > > calls for people to help with the efforts about the same time. We have
> > > tried at every step of the way to be open and honest that this was goin
making quarterly reports about this for almost a years as well. We put out
calls for people to help with the efforts about the same time. We have
tried at every step of the way to be open and honest that this was going to
happen.
All developer centric communications
I would argue that qua
On 2020-09-19, Zaphod Beeblebrox wrote:
> Hrm. Maybe what I hear others saying, tho, and not entirely being replied
> to is just a nice concise document of the why. What I hear you saying is
> that GIT has momentum and that it's popular... (and I accept that --- it is
> evidently true), but the
Hi *
I've been getting these build failures for a while (weeks/months). The machine
is a MacchiatoBin DoubleShot (arm64, Quad core). with SATA disks and zfs
filesystem. If I empty out /usr/obj, then the build works, but takes a few
hours. If I do a no-clean build with /obj/obj populated with he
> On Sat, Sep 19, 2020, 2:44 PM Lucas Nali de Magalh?es
> wrote:
>
> > Just My 2??
> >
> > On Sep 3, 2020, at 5:19 PM, Warner Losh wrote:
> >
> > ?On Thu, Sep 3, 2020 at 1:32 PM Chris wrote:
> >
> > On 2020-09-03 11:33, Kristof Provost wrote:
> >
> > On 3 Sep 2020, at 19:56, Chris wrote:
> >
>
Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
>>> On 2020-09-20 10:05, Rainer Hurling wrote:
Hi monochrome,
back to keyboard, it tried newest CURRENT (r365920) o
Forgot to mention here.
As I already mentioned on bugzilla, this problem is fixed at r365894.
Thanks again, Ryan and Matthew!
On Sun, 6 Sep 2020 18:02:40 +0900
Tomoaki AOKI wrote:
> Filed PR.
> Bug 249147 - [ZFS][Panic]Fatal trap 18 on boot after OpenZFS import
>
> https://bugs.freebsd.org/
On Thu, 17 Sep 2020 08:55:26 -0700
Cy Schubert wrote:
> In message <451538de-9427-4584-987b-8e4aa26c2...@freebsd.org>, Daniel
> Eischen w
> rites:
> >
> >
> > > On Sep 17, 2020, at 11:20 AM, Maxim Sobolev wrote:
> > >
> > > γγγRe: removing HTTP client please no!!! The current drive to "outlaw
Hi!
Thanks for clarification, Warner.
Focusing on downsides, I feel the second is fundamental.
Running (incremental) count is important especially for non-developers
like me (or developers not having commit bit) to report problems via ML.
It clarifies revision ranges in shorter and clearer form.
On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
> > On 2020-09-20 10:05, Rainer Hurling wrote:
> >> Hi monochrome,
> >>
> >> back to keyboard, it tried newest CURRENT (r365920) on my box and even
> >> with newest sources the error
Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
> On 2020-09-20 10:05, Rainer Hurling wrote:
>> Hi monochrome,
>>
>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
>> with newest sources the error occurs.
>>
>> After looking around somewhat more, I found some hints about V
On 2020-09-20 10:05, Rainer Hurling wrote:
Hi monochrome,
back to keyboard, it tried newest CURRENT (r365920) on my box and even
with newest sources the error occurs.
After looking around somewhat more, I found some hints about Virtualbox
kernel module having problems with r365488. Unfortunatel
Hi monochrome,
back to keyboard, it tried newest CURRENT (r365920) on my box and even
with newest sources the error occurs.
After looking around somewhat more, I found some hints about Virtualbox
kernel module having problems with r365488. Unfortunately, I am not able
to find the thread again :(
I also have the exact same panic on a Dell motherboard with a Haswell processor.
On Sat, Sep 19, 2020 at 11:05 PM monochrome wrote:
>
> I have confirmed that r365487 is the last kernel that will boot on my
> 2400G. These are the files changed between r365487 and r365488:
>
> Usys/vm/phys_page
30 matches
Mail list logo
