Re: FreeBSD 12 and Nocona

2019-01-08 Thread Marek Zarychta


W dniu 03.01.2019 o 14:13, Stefan Bethke pisze:
>> I have under supervision a few old servers running 11.2-STABLE. The
>> hardware is almost for retirement, but still in working condition. It's
>> all old Nocona NetBurst microarchitecture. I have recently tried do
>> upgrade OS two of them to 12.0-STABLE, but failed. When I use old
>> bootloader the boot freezes on blue highlighted "Booting" stage, when I
>> tried to use 12 loader, it freezes earlier, on loading kernel modules.
>> The kernel was compiled from fresh sources for CPUTYPE?=nocona.
>> 11.2-STABLE is fine with this optimization and the same kernel boots
>> fine on newer hardware.
>>
>> It is fair, that 11 EOL is expected September 30, 2021 and these servers
>> will likely be retired before this date, but some questions arise:
>>
>> Is such old hardware still supported? Is it possible (how to) debug the
>> booting process?
> 
> The first step is to try with known-good bits: can you boot these machines 
> off the 12.0 ISO or memstick images? Can you load your kernel and modules 
> with the loader from the ISO/memstick? Does GENERIC built without any flags 
> work?
> 
> If any of these don’t work, try to be as specific as possible when reporting 
> problems. For example, the exact make of mainboard (kenv output) and the BIOS 
> version, and any relevant BIOS settings are likely important for problems 
> regarding the loader. If the kernel and modules load, you can try a verbose 
> boot to see better how far the kernel gets.
> 
> I’d be really surprised if the CPUs themselves would cause trouble.


The first step is done. The affected hardware doesn't boot from official
12.0-RELEASE CD either. Loader also freezes at the stage of loading
kernel modules. These servers are old Maxdata Platinum 500 and 3200.
Some time ago I have submitted dmesgs to NYC BUG dmesg repository[1][2].

Both configurations are fine with 11-STABLE, so I am not going to
upgrade them and I am replying only FYI.


[1] https://dmesgd.nycbug.org/index.cgi?do=view&id=3790
[2] https://dmesgd.nycbug.org/index.cgi?do=view&id=4111

Regards,

-- 
Marek Zarychta



signature.asc
Description: OpenPGP digital signature


Re: x86intrin.h not found after 10.4->11.2 upgrade

2019-01-08 Thread Morgan Reed
Just did a find across /usr for the file and it's definitely there so I'm
not sure why the compiler can't find it :/

# find /usr -name x86intrin.h
/usr/include/x86intrin.h
/usr/src/contrib/llvm/tools/clang/lib/Headers/x86intrin.h
/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd11.2/7.4.0/include/x86intrin.h
/usr/local/llvm60/lib/clang/6.0.1/include/x86intrin.h
/usr/lib/clang/6.0.0/include/x86intrin.h

This system's been around the block (started out as 9.3 I think, had a few
upgrades over the years) which would explain the gcc7 stuff.


On Tue, Jan 8, 2019 at 6:52 PM Morgan Reed  wrote:

> Hi All,
>
>   Finally got around to upgrading my NAS which was running FreeBSD
> 10.4 to a supported version (11.2).
>
> Ran into an issue when I came to do a portupgrade -a to update all my
> installed ports, a number of the ports are failing with "x86intrin.h No
> such file or directory", not sure what's going on there.
>
> I've updated my src tree just in case it was something that only got added
> in 11, no change.
>
> All the similar reports I found online were related to OLD versions of gcc
> (e.g. 4.3), which is not relevant since we're using clang (I assume
> anyway), but I reinstalled llvm60 from package just in case, no change
> again.
>
> An pointers would be greatly appreciated, thanks.
>
> Morgan
>
>
>
>

-- 
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-- Benjamin Franklin, 1759
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: FreeBSD 12 and Nocona

2019-01-08 Thread Stefan Bethke
Am 08.01.2019 um 10:34 schrieb Marek Zarychta :
> W dniu 03.01.2019 o 14:13, Stefan Bethke pisze:
>>> I have under supervision a few old servers running 11.2-STABLE. The
>>> hardware is almost for retirement, but still in working condition. It's
>>> all old Nocona NetBurst microarchitecture. I have recently tried do
>>> upgrade OS two of them to 12.0-STABLE, but failed. When I use old
>>> bootloader the boot freezes on blue highlighted "Booting" stage, when I
>>> tried to use 12 loader, it freezes earlier, on loading kernel modules.
>>> The kernel was compiled from fresh sources for CPUTYPE?=nocona.
>>> 11.2-STABLE is fine with this optimization and the same kernel boots
>>> fine on newer hardware.
>>> 
>>> It is fair, that 11 EOL is expected September 30, 2021 and these servers
>>> will likely be retired before this date, but some questions arise:
>>> 
>>> Is such old hardware still supported? Is it possible (how to) debug the
>>> booting process?
>> 
>> The first step is to try with known-good bits: can you boot these machines 
>> off the 12.0 ISO or memstick images? Can you load your kernel and modules 
>> with the loader from the ISO/memstick? Does GENERIC built without any flags 
>> work?
>> 
>> If any of these don’t work, try to be as specific as possible when reporting 
>> problems. For example, the exact make of mainboard (kenv output) and the 
>> BIOS version, and any relevant BIOS settings are likely important for 
>> problems regarding the loader. If the kernel and modules load, you can try a 
>> verbose boot to see better how far the kernel gets.
>> 
>> I’d be really surprised if the CPUs themselves would cause trouble.
> 
> 
> The first step is done. The affected hardware doesn't boot from official
> 12.0-RELEASE CD either. Loader also freezes at the stage of loading
> kernel modules. These servers are old Maxdata Platinum 500 and 3200.
> Some time ago I have submitted dmesgs to NYC BUG dmesg repository[1][2].
> 
> Both configurations are fine with 11-STABLE, so I am not going to
> upgrade them and I am replying only FYI.
> 
> 
> [1] https://dmesgd.nycbug.org/index.cgi?do=view&id=3790 
> 
> [2] https://dmesgd.nycbug.org/index.cgi?do=view&id=4111 
> 
I think it would be great to get some input from someone familiar with the new 
loader. I’ve cc’ed Warner, Kyle and Toomas, as they were listed in the 
quarterly status report.


Stefan

-- 
Stefan BethkeFon +49 151 14070811

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: x86intrin.h not found after 10.4->11.2 upgrade

2019-01-08 Thread Dimitry Andric
On 8 Jan 2019, at 12:50, Morgan Reed  wrote:
> 
> Just did a find across /usr for the file and it's definitely there so I'm
> not sure why the compiler can't find it :/

Please post the output of:

cc -v -x c -c /dev/null -o /dev/null


> 
> # find /usr -name x86intrin.h
> /usr/include/x86intrin.h

This copy should not exist.  Any idea where it came from, and what is
its contents?


> /usr/src/contrib/llvm/tools/clang/lib/Headers/x86intrin.h
> /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd11.2/7.4.0/include/x86intrin.h
> /usr/local/llvm60/lib/clang/6.0.1/include/x86intrin.h
> /usr/lib/clang/6.0.0/include/x86intrin.h

If your /usr/bin/cc reports being clang 6.0.0, then the latter one is
correct.

My guess would be that something (/etc/make.conf, for instance) is
messing with your CFLAGS, causing the internal headers to not be found.

-Dimitry



signature.asc
Description: Message signed with OpenPGP


Re: x86intrin.h not found after 10.4->11.2 upgrade

2019-01-08 Thread Morgan Reed
Ah, that's the problem, /usr/include/x86intrin.h was a symlink to an old
clang 3.4.1 version of that header which doesn't exist on the filesystem
any more, I've deleted it and now things are much happier.

Really ought to do a clean rebuild on this box one of these days...

Thanks,

Morgan

On Wed, Jan 9, 2019 at 5:47 AM Dimitry Andric  wrote:

> On 8 Jan 2019, at 12:50, Morgan Reed  wrote:
> >
> > Just did a find across /usr for the file and it's definitely there so I'm
> > not sure why the compiler can't find it :/
>
> Please post the output of:
>
> cc -v -x c -c /dev/null -o /dev/null
>
>
> >
> > # find /usr -name x86intrin.h
> > /usr/include/x86intrin.h
>
> This copy should not exist.  Any idea where it came from, and what is
> its contents?
>
>
> > /usr/src/contrib/llvm/tools/clang/lib/Headers/x86intrin.h
> >
> /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd11.2/7.4.0/include/x86intrin.h
> > /usr/local/llvm60/lib/clang/6.0.1/include/x86intrin.h
> > /usr/lib/clang/6.0.0/include/x86intrin.h
>
> If your /usr/bin/cc reports being clang 6.0.0, then the latter one is
> correct.
>
> My guess would be that something (/etc/make.conf, for instance) is
> messing with your CFLAGS, causing the internal headers to not be found.
>
> -Dimitry
>
>

-- 
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-- Benjamin Franklin, 1759
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


grep(1) documents bsdgrep, but GNU grep is installed as 'grep'

2019-01-08 Thread Rebecca Cran via freebsd-stable
grep(1) documents the "--exclude-dir" option, but running "grep" complains 
it's unknown. Also, 'rgrep' doesn't exist.
It turns out that the grep binary is GNU grep 2.5.1, while bsdgrep supports 
the option.

Is WITH_BSD_GREP supposed to be defaulted to on for 12.0 and newer, or was the 
man page switched over too soon?

-- 
Rebecca Cran
bc...@freebsd.org


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: grep(1) documents bsdgrep, but GNU grep is installed as 'grep'

2019-01-08 Thread Kyle Evans
On Tue, Jan 8, 2019 at 7:36 PM Rebecca Cran via freebsd-stable
 wrote:
>
> grep(1) documents the "--exclude-dir" option, but running "grep" complains
> it's unknown. Also, 'rgrep' doesn't exist.
> It turns out that the grep binary is GNU grep 2.5.1, while bsdgrep supports
> the option.
>
> Is WITH_BSD_GREP supposed to be defaulted to on for 12.0 and newer, or was the
> man page switched over too soon?
>

Yeah, I think we botched that -- maybe we'll call it optimism. =(
https://svnweb.freebsd.org/base/head/usr.bin/grep/Makefile?view=markup#l13
should read "MAN1= bsdgrep.1 zgrep.1" rather than grep.1 zgrep.1, I
believe. (CC bapt@ for a second eye, since this was during zgrep
stuff)

Thanks,

Kyle Evans
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: grep(1) documents bsdgrep, but GNU grep is installed as 'grep'

2019-01-08 Thread Kyle Evans
On Tue, Jan 8, 2019 at 7:44 PM Kyle Evans  wrote:
>
> On Tue, Jan 8, 2019 at 7:36 PM Rebecca Cran via freebsd-stable
>  wrote:
> >
> > grep(1) documents the "--exclude-dir" option, but running "grep" complains
> > it's unknown. Also, 'rgrep' doesn't exist.
> > It turns out that the grep binary is GNU grep 2.5.1, while bsdgrep supports
> > the option.
> >
> > Is WITH_BSD_GREP supposed to be defaulted to on for 12.0 and newer, or was 
> > the
> > man page switched over too soon?
> >
>
> Yeah, I think we botched that -- maybe we'll call it optimism. =(
> https://svnweb.freebsd.org/base/head/usr.bin/grep/Makefile?view=markup#l13
> should read "MAN1= bsdgrep.1 zgrep.1" rather than grep.1 zgrep.1, I
> believe. (CC bapt@ for a second eye, since this was during zgrep
> stuff)
>

It's a trivial enough fix that I verified it and just went ahead to
commit it as r342874; sorry for that!
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"