Re: SVN - r334189 breaks build
Fix going in in about 10
On Thu, May 24, 2018 at 3:45 PM, Michael Butler
wrote:
> On a GENERIC box ..
>
> --- bridgestp.o ---
> /usr/src/sys/net/bridgestp.c:2046:2: error: no member named 'cstqe_next'
> in 'struct ifnet::(anonymous at /usr/src/sys/net/if_var.h:241:2)'; did
> you mean 'stqe_next'?
> CK_STAILQ_FOREACH(ifp, &V_ifnet, if_link) {
> ^
> /usr/src/sys/contrib/ck/include/ck_queue.h:253:13: note: expanded from
> macro 'CK_STAILQ_FOREACH'
>(var) = CK_STAILQ_NEXT((var), field))
>^
> /usr/src/sys/contrib/ck/include/ck_queue.h:291:32: note: expanded from
> macro 'CK_STAILQ_NEXT'
> (ck_pr_load_ptr(&(elm)->field.cstqe_next))
> ^
> /usr/src/sys/net/if_var.h:241:2: note: 'stqe_next' declared here
> STAILQ_ENTRY(ifnet) if_link;/* all struct ifnets are chained
> (CK_) */
>
> And on a custom kernel ..
>
> --- hwpmc_mod.o ---
> /usr/src/sys/dev/hwpmc/hwpmc_mod.c:1727:2: error: no member named
> 'clh_first' in 'struct (anonymous at
> /usr/src/sys/dev/hwpmc/hwpmc_mod.c:178:8)'; did you mean 'lh_first'?
> CK_LIST_FOREACH(po, &pmc_ss_owners, po_ssnext)
> ^
> /usr/src/sys/contrib/ck/include/ck_queue.h:363:15: note: expanded from
> macro 'CK_LIST_FOREACH'
> for ((var) = CK_LIST_FIRST((head));
>\
> ^
> /usr/src/sys/contrib/ck/include/ck_queue.h:358:54: note: expanded from
> macro 'CK_LIST_FIRST'
> #define CK_LIST_FIRST(head) ck_pr_load_ptr(&(head)->clh_first)
> ^
> /usr/src/sys/dev/hwpmc/hwpmc_mod.c:178:8: note: 'lh_first' declared here
> static LIST_HEAD(, pmc_owner) pmc_ss_owners;
>^
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN - r334189 breaks build
On a GENERIC box ..
--- bridgestp.o ---
/usr/src/sys/net/bridgestp.c:2046:2: error: no member named 'cstqe_next'
in 'struct ifnet::(anonymous at /usr/src/sys/net/if_var.h:241:2)'; did
you mean 'stqe_next'?
CK_STAILQ_FOREACH(ifp, &V_ifnet, if_link) {
^
/usr/src/sys/contrib/ck/include/ck_queue.h:253:13: note: expanded from
macro 'CK_STAILQ_FOREACH'
(var) = CK_STAILQ_NEXT((var), field))
^
/usr/src/sys/contrib/ck/include/ck_queue.h:291:32: note: expanded from
macro 'CK_STAILQ_NEXT'
(ck_pr_load_ptr(&(elm)->field.cstqe_next))
^
/usr/src/sys/net/if_var.h:241:2: note: 'stqe_next' declared here
STAILQ_ENTRY(ifnet) if_link;/* all struct ifnets are chained
(CK_) */
And on a custom kernel ..
--- hwpmc_mod.o ---
/usr/src/sys/dev/hwpmc/hwpmc_mod.c:1727:2: error: no member named
'clh_first' in 'struct (anonymous at
/usr/src/sys/dev/hwpmc/hwpmc_mod.c:178:8)'; did you mean 'lh_first'?
CK_LIST_FOREACH(po, &pmc_ss_owners, po_ssnext)
^
/usr/src/sys/contrib/ck/include/ck_queue.h:363:15: note: expanded from
macro 'CK_LIST_FOREACH'
for ((var) = CK_LIST_FIRST((head));
\
^
/usr/src/sys/contrib/ck/include/ck_queue.h:358:54: note: expanded from
macro 'CK_LIST_FIRST'
#define CK_LIST_FIRST(head) ck_pr_load_ptr(&(head)->clh_first)
^
/usr/src/sys/dev/hwpmc/hwpmc_mod.c:178:8: note: 'lh_first' declared here
static LIST_HEAD(, pmc_owner) pmc_ss_owners;
^
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Another recent WITH_META_MODE= gotcha ": handling svn commit: r334008 - head/bin/sh
On 5/21/2018 10:17 PM, Mark Millard wrote:
> Attempting to build head -r334014 from -r333947 includes the code from
> -r334008,
> and for which I get:
>
> --- parser.o ---
> /usr/src/bin/sh/parser.c:1440:9: error: use of undeclared identifier 'CQNL'
> case CQNL:
> ^
> 1 error generated.
>
> for what was added in -r334008.
>
> # grep -r CQNL /usr/src/* | more
> /usr/src/bin/sh/mksyntax.c: { "CQNL", "newline character in quotes"
> },
> /usr/src/bin/sh/mksyntax.c: add("\n", "CQNL");
> /usr/src/bin/sh/mksyntax.c: add("\n", "CQNL");
> /usr/src/bin/sh/mksyntax.c: add("\n", "CQNL");
> /usr/src/bin/sh/parser.c: case CQNL:
> /usr/src/contrib/libarchive/libarchive/test/test_read_format_rar_binary_data.rar.uu:M+M7)?9;.A%CQNL-+4::&_UJQ*P"PPW:>)I5*8)7^>6(\]!Q"^9YCE>>`9OG8
>
> Apparently this is something WITH_META_MODE= does not deal with.
> Rebuilding after:
>
> rm -fr /usr/obj/amd64_clang/*
>
> (here I normally have the build materials) built fine.
>
> (The "Making top.local.h from /usr/src/contrib/top/top.local.hs"
> change to no longer have top.local.h or top.local.hs was another
> example: for a while top.local.h was still referenced and old ones
> would still be used if present.)
>
It was a bug with the rescue build with dependency handling. I've fixed
it in r334177.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: Intel Corporation Wireless 8265 / 8275 (rev 78) on FreeBSD 12
On 05/24/2018 05:55, Mateusz Piotrowski wrote: On Wed, 23 May 2018 09:46:13 -0700 Pete Wright wrote: On 05/23/2018 00:41, David Pan wrote: how config the Intel Corporation Wireless 8265 / 8275 (rev 78) on FreeBSD 12?I installed FreeBSD 12 on my thinkpad t470p ,and can not drive the Intel Wireless Card. please help me fix that, I have this working on my end under both 12-current and 11-stable. here's my configuration: output from "pciconf -lv" iwm0@pci0:3:0:0: class=0x028000 card=0x10108086 chip=0x24fd8086 rev=0x78 hdr=0x00 vendor = 'Intel Corporation' device = 'Wireless 8265 / 8275' class = network to bring up the card i have added this entry to /etc/rc.conf: kld_list="if_iwm" then configuring the interface is the same as any other wifi as per the handbook, the device will be available as "iwm0". Shouldn't you load some firmware as well? That's what the iwm(4) manual and WiFi/FAQ wiki page[1] say. on my system loading if_iwm via the above rc.conf entry pulls in the appropriate firmware kld: $ kldstat|grep iwm 6 1 0x82c21000 14af0 if_iwm.ko 7 1 0x82c36000 1ba76f iwm8265fw.ko -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
> On 23 May 2018 at 17:51, Philip Homburg wrote: > > I tried both FreeBSD-11.2-BETA2-amd64-bootonly.iso.xz and > > FreeBSD-11.2-BETA2-amd64-mini-memstick.img.xz on a Dell PowerEdge 2950 > > BIOS version 2.7.0. With both images, the USB stick is not recognized. > > Can you download the image from > https://people.freebsd.org/~emaste/mini-image.amd64.xz, uncompress and > write it to a USB stick and try on this system? This is a > MBR-partitioned dual-mode test image. It's not an installer - it > should just boot to a login prompt - but can be used to test this > scheme. Ed, I tested this here on my R710 that was failing to boot in Bios mode with the amd64-11.2-Beta2 disc1.iso, your mini-image boots fine in either Bios or UEFI mode on my Dell R710, so what ever you did fixed at least my one data point. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
On Thu, May 24, 2018 at 2:11 PM Ed Maste wrote: > On 23 May 2018 at 17:51, Philip Homburg wrote: > > I tried both FreeBSD-11.2-BETA2-amd64-bootonly.iso.xz and > > FreeBSD-11.2-BETA2-amd64-mini-memstick.img.xz on a Dell PowerEdge 2950 > > BIOS version 2.7.0. With both images, the USB stick is not recognized. > > Can you download the image from > https://people.freebsd.org/~emaste/mini-image.amd64.xz, uncompress and > write it to a USB stick and try on this system? This is a > MBR-partitioned dual-mode test image. It's not an installer - it > should just boot to a login prompt - but can be used to test this > scheme. > Tested successfully on Dell Latitude E7450 for both legacy BIOS and UEFI boot mode. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
-- Start of PGP signed section. > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote: > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote: > > > > >Also as the Moore's law curve flattens expect the life of these > > > > >older, but not so old, machines to live quiet some time. I > > > > >believe we are talking sandy bridge and earlier? If that is > > > > >corret Sandy bridge is still a very viable system. > > > > > > > > I noticed this lack of love for older systems recently. > > > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs. > > > > > > > > Turns out, you can't install FreeBSD using a USB stick image because the > > > > BIOS only support MBR. No idea why MBR support was dropped for the USB > > > > images. > > > > > > > > In the end I had to find a CD burner, and after a couple of tries > > > > managed to > > > > install from CD. > > > > > > > > After that, my ansible playbooks started failing because > > > > /boot/loader.conf > > > > is absent if you boot from zfs in combination with MBR. > > > > > > > > Pity. This older server hardware is great for trying out new releases, > > > > play > > > > with zfs, etc. > > > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now > > > built as hybrid images, supporting both MBR and GPT, as well as being > > > written to a flash drive (like memstick.img) as well as a CD. > > > > To clarify a minor point here, are the amd64 disc1.iso images or > > both the amd64 and i386 disk1.iso images being built as "hybrid"? > > > > Only amd64. i386 does not have UEFI-/GPT-related boot issues. Here is a data point: Test system is Dell R710, First attempt is with BIOS in Boot mode: Bios Second attempt is with BIOS in Boot mode: UEFI Attemtped to boot amd64 version: Screen goes white background, text appears (yes, way indented) BTX version is 1.02 Consoles: internal video/keyboard _ That last _ is a blinking cursor, system is hung, does repsond to C-A-del Second attempt: Works properly I am going after Ed Maste's posted build image in the other thread now... > > > As this is what I see on my system: > > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-* > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : > > ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, > > 1472695 sectors > > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data > > '11_2_BETA2_I386_CD' (bootable) > > > > > MBR support was initially removed from the memstick installer, as it is > > > not compatible with some UEFI implementations. (Or, at least that is my > > > understanding, based on my limited intimate knowledge of UEFI.) > > > > > Glen > -- End of PGP section, PGP failed! -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote: > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote: > > > >Also as the Moore's law curve flattens expect the life of these > > > >older, but not so old, machines to live quiet some time. I > > > >believe we are talking sandy bridge and earlier? If that is > > > >corret Sandy bridge is still a very viable system. > > > > > > I noticed this lack of love for older systems recently. > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs. > > > > > > Turns out, you can't install FreeBSD using a USB stick image because the > > > BIOS only support MBR. No idea why MBR support was dropped for the USB > > > images. > > > > > > In the end I had to find a CD burner, and after a couple of tries managed > > > to > > > install from CD. > > > > > > After that, my ansible playbooks started failing because > > > /boot/loader.conf > > > is absent if you boot from zfs in combination with MBR. > > > > > > Pity. This older server hardware is great for trying out new releases, > > > play > > > with zfs, etc. > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now > > built as hybrid images, supporting both MBR and GPT, as well as being > > written to a flash drive (like memstick.img) as well as a CD. > > To clarify a minor point here, are the amd64 disc1.iso images or > both the amd64 and i386 disk1.iso images being built as "hybrid"? > Only amd64. i386 does not have UEFI-/GPT-related boot issues. > As this is what I see on my system: > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-* > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : > ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 > sectors > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data > '11_2_BETA2_I386_CD' (bootable) > > > MBR support was initially removed from the memstick installer, as it is > > not compatible with some UEFI implementations. (Or, at least that is my > > understanding, based on my limited intimate knowledge of UEFI.) > > Glen signature.asc Description: PGP signature
Re: kernel -current build failures
On 05/23/18 22:39, Charlie Li wrote:
> On 23/05/2018 19:21, Michael Butler wrote:
>> On a device with bluetooth (as in GENERIC modules) ..
>>
>> --- ng_ether.o ---
>> /usr/src/sys/netgraph/ng_ether.c:871:2: error: no member named
>> 'tqh_first' in 'struct ifnethead'; did you mean 'stqh_first'?
>> TAILQ_FOREACH(ifp, &V_ifnet, if_link) {
>> ^
>> /usr/src/sys/sys/queue.h:724:15: note: expanded from macro 'TAILQ_FOREACH'
>> for ((var) = TAILQ_FIRST((head)); \
>> ^
>> /usr/src/sys/sys/queue.h:721:36: note: expanded from macro 'TAILQ_FIRST'
>> #define TAILQ_FIRST(head) ((head)->tqh_first)
>> ^
>>
> Looks like this is fixed in r334123.
Yes but this one isn't ..
On a system without IPSEC ..
--- kernel ---
linking kernel
ld: error: undefined symbol: vnet_entry_ipsec4stat
>>> referenced by key.c
>>> key.o:(key_allocsp)
ld: error: undefined symbol: vnet_entry_ipsec4stat
>>> referenced by key.c
>>> key.o:(key_allocsp)
*** [kernel] Error code 1
Michael
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
> On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote: > > >Also as the Moore's law curve flattens expect the life of these > > >older, but not so old, machines to live quiet some time. I > > >believe we are talking sandy bridge and earlier? If that is > > >corret Sandy bridge is still a very viable system. > > > > I noticed this lack of love for older systems recently. > > > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs. > > > > Turns out, you can't install FreeBSD using a USB stick image because the > > BIOS only support MBR. No idea why MBR support was dropped for the USB > > images. > > > > In the end I had to find a CD burner, and after a couple of tries managed to > > install from CD. > > > > After that, my ansible playbooks started failing because /boot/loader.conf > > is absent if you boot from zfs in combination with MBR. > > > > Pity. This older server hardware is great for trying out new releases, play > > with zfs, etc. > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now > built as hybrid images, supporting both MBR and GPT, as well as being > written to a flash drive (like memstick.img) as well as a CD. To clarify a minor point here, are the amd64 disc1.iso images or both the amd64 and i386 disk1.iso images being built as "hybrid"? As this is what I see on my system: root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-* FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 sectors FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data '11_2_BETA2_I386_CD' (bootable) > MBR support was initially removed from the memstick installer, as it is > not compatible with some UEFI implementations. (Or, at least that is my > understanding, based on my limited intimate knowledge of UEFI.) > > Glen > -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
On 23 May 2018 at 17:51, Philip Homburg wrote: > I tried both FreeBSD-11.2-BETA2-amd64-bootonly.iso.xz and > FreeBSD-11.2-BETA2-amd64-mini-memstick.img.xz on a Dell PowerEdge 2950 > BIOS version 2.7.0. With both images, the USB stick is not recognized. Can you download the image from https://people.freebsd.org/~emaste/mini-image.amd64.xz, uncompress and write it to a USB stick and try on this system? This is a MBR-partitioned dual-mode test image. It's not an installer - it should just boot to a login prompt - but can be used to test this scheme. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel Corporation Wireless 8265 / 8275 (rev 78) on FreeBSD 12
On Wed, 23 May 2018 09:46:13 -0700 Pete Wright wrote: >On 05/23/2018 00:41, David Pan wrote: >> how config the Intel Corporation Wireless 8265 / 8275 (rev 78) on >> FreeBSD 12?I installed FreeBSD 12 on my thinkpad t470p ,and can not >> drive the Intel Wireless Card. >> please help me fix that, > >I have this working on my end under both 12-current and 11-stable. >here's my configuration: > >output from "pciconf -lv" >iwm0@pci0:3:0:0: class=0x028000 card=0x10108086 chip=0x24fd8086 >rev=0x78 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Wireless 8265 / 8275' > class = network > > >to bring up the card i have added this entry to /etc/rc.conf: > >kld_list="if_iwm" > >then configuring the interface is the same as any other wifi as per the >handbook, the device will be available as "iwm0". Shouldn't you load some firmware as well? That's what the iwm(4) manual and WiFi/FAQ wiki page[1] say. [1]: https://wiki.freebsd.org/WiFi/FAQ#I.27ve_got_some_problems_with_the_iwm.284.29_driver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gcc/g++ 4.2.1 -r334125 is getting devd related build failures on ci.freebsd.org
On 24 May 2018 at 03:34, Mark Millard wrote: > [This submittal is in part an experiment with how Eitan's > MUA classifies the Email using an alternate yahoo.com > address. Eitan: the subject and this note are all unique > to this message.] > > Gmail still considers all your mails as spam :( > This message has a from address in yahoo.com but has failed yahoo.com's required tests for authentication. WBR, Timur Bakeyev ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
gcc/g++ 4.2.1 -r334125 is getting devd related build failures on ci.freebsd.org
[This submittal is in part an experiment with how Eitan's MUA classifies the Email using an alternate yahoo.com address. Eitan: the subject and this note are all unique to this message.] I've reported to Eitan that the gcc/g++ 4.2.1 architectures are failing for devd build failures. Examples include: --- all_subdir_sbin --- cc1plus: warnings being treated as errors /usr/obj/usr/src/sparc64.sparc64/tmp/usr/include/c++/4.2/bits/basic_string.h: In member function 'std::basic_string<_CharT, _Traits, _Alloc>::_Rep* std::basic_string<_CharT, _Traits, _Alloc>::_M_rep() const [with _CharT = char, _Traits = std::char_traits, _Alloc = std::allocator]': /usr/obj/usr/src/sparc64.sparc64/tmp/usr/include/c++/4.2/bits/basic_string.h:493: instantiated from 'std::basic_string<_CharT, _Traits, _Alloc>::~basic_string() [with _CharT = char, _Traits = std::char_traits, _Alloc = std::allocator]' /usr/src/sbin/devd/devd.hh:149: instantiated from here /usr/obj/usr/src/sparc64.sparc64/tmp/usr/include/c++/4.2/bits/basic_string.h:288: warning: cast from 'char*' to 'std::basic_string, std::allocator >::_Rep*' increases required alignment of target type mips64 and mips and sparc64 agree, for example. powerpc and powerpc64 report: --- all_subdir_sbin --- cc1plus: warnings being treated as errors /usr/src/sbin/devd/devd.hh: In function 'void __tcf_0(void*)': /usr/src/sbin/devd/devd.hh:150: warning: inlining failed in call to 'virtual config::~config()': --param max-inline-insns-single limit reached /usr/src/sbin/devd/devd.cc:175: warning: called from here but I expect the two sets of types of error message are related somehow and the "fix" fixes both types. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
