Re: Boot failure - svn up from this morning
On Thu, 2 Mar 2017 21:32:39 -0800 "Ngie Cooper (yaneurabeya)" wrote > > On Mar 2, 2017, at 21:16, Chris H wrote: > > > > On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN wrote > > > >> Hi: > >> > >> I'm having a major problem after updating a 12-current machine today. > >> After buildworld/kernel/install cycle on reboot I'm getting the following > >> failure: > >> > >> "/boot/kernel/kernel text=0xb7716f data=0x100548+0x398358 > >> elf64_loadimage: read failed > >> can't load file '/boot/kernel/kernel': input/output error > >> can't load file '/boot/kernel/kernel': input/output error > >> > >> OK boot kernel.old > >> elf64_loadimage: read failed > >> can't load file '/boot/kernel.old/kernel': input/output error > >> can't load file '/boot/kernel.old/kernel': input/output error" > >> > >> I have never experienced this failure before, and don't know how to > >> proceed. Any help recovering from this would be greatly appreciated. > >> Thanks in advance. > > > > I don't suppose you could post the output of > > uname -a > > > > and maybe a copy of dmesg(8) could you? > > That would be good, but I don’t know if it’s possible (the OP is noting > that the boot is broken when executing loader(8)..). -Ngie Indeed. But that doesn't stop the OP from booting from the install media. ;-) :-) --Chris ___ 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 failure - svn up from this morning
> On Mar 2, 2017, at 21:16, Chris H wrote: > > On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN wrote > >> Hi: >> >> I'm having a major problem after updating a 12-current machine today. >> After buildworld/kernel/install cycle on reboot I'm getting the following >> failure: >> >> "/boot/kernel/kernel text=0xb7716f data=0x100548+0x398358 >> elf64_loadimage: read failed >> can't load file '/boot/kernel/kernel': input/output error >> can't load file '/boot/kernel/kernel': input/output error >> >> OK boot kernel.old >> elf64_loadimage: read failed >> can't load file '/boot/kernel.old/kernel': input/output error >> can't load file '/boot/kernel.old/kernel': input/output error" >> >> I have never experienced this failure before, and don't know how to >> proceed. Any help recovering from this would be greatly appreciated. >> Thanks in advance. > > I don't suppose you could post the output of > uname -a > > and maybe a copy of dmesg(8) could you? That would be good, but I don’t know if it’s possible (the OP is noting that the boot is broken when executing loader(8)..). -Ngie signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Boot failure - svn up from this morning
On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN wrote > Hi: > > I'm having a major problem after updating a 12-current machine today. > After buildworld/kernel/install cycle on reboot I'm getting the following > failure: > > "/boot/kernel/kernel text=0xb7716f data=0x100548+0x398358 > elf64_loadimage: read failed > can't load file '/boot/kernel/kernel': input/output error > can't load file '/boot/kernel/kernel': input/output error > > OK boot kernel.old > elf64_loadimage: read failed > can't load file '/boot/kernel.old/kernel': input/output error > can't load file '/boot/kernel.old/kernel': input/output error" > > I have never experienced this failure before, and don't know how to > proceed. Any help recovering from this would be greatly appreciated. > Thanks in advance. I don't suppose you could post the output of uname -a and maybe a copy of dmesg(8) could you? --Chris ___ 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"
Boot failure - svn up from this morning
Hi: I'm having a major problem after updating a 12-current machine today. After buildworld/kernel/install cycle on reboot I'm getting the following failure: "/boot/kernel/kernel text=0xb7716f data=0x100548+0x398358 elf64_loadimage: read failed can't load file '/boot/kernel/kernel': input/output error can't load file '/boot/kernel/kernel': input/output error OK boot kernel.old elf64_loadimage: read failed can't load file '/boot/kernel.old/kernel': input/output error can't load file '/boot/kernel.old/kernel': input/output error" I have never experienced this failure before, and don't know how to proceed. Any help recovering from this would be greatly appreciated. Thanks in advance. ___ 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: effect of strip(1) on du(1)
On Thu, Mar 2, 2017 at 6:12 PM, Ngie Cooper wrote: > On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes > wrote: > ... >> Even if that is the case file system cache effects should NOT be >> visible to a userland process. This is NOT as if your running >> 2 different processing beating on a file. Your test cases are >> serialially syncronous shell invoked commands seperated with >> && the results should be exact and predictable. >> >> When strip returns the operation from the userland perspecive >> is completed and any and all processeses started after that >> should have the view of the completed strip command. >> >> This IS a bug. > > Would the same statement necessarily apply if the filesystem was > writing things asynchronously to the backing storage? > Thanks, > -Ngie du(1) is using fts_read(3), which is based on the stat(2) information. The OpenGroup defines st_blocksize as "Number of blocks allocated for this object." In the case of ZFS, a write(2) may return before any blocks are actually allocated. And thanks to compression, gang blocks, and deduplication, at this point it's not even possible for ZFS to know how many blocks it will need to allocate. I think st_blocksize should be interpreted as a "best effort" output. Just like df(1), you can't rely on du's output to be mathematically precise in any way. I certainly don't see any way to fix it besides doing something like an fsync(2) before getting stat information, and we certainly don't want to do that. -Alan ___ 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: effect of strip(1) on du(1)
On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes wrote: ... > Even if that is the case file system cache effects should NOT be > visible to a userland process. This is NOT as if your running > 2 different processing beating on a file. Your test cases are > serialially syncronous shell invoked commands seperated with > && the results should be exact and predictable. > > When strip returns the operation from the userland perspecive > is completed and any and all processeses started after that > should have the view of the completed strip command. > > This IS a bug. Would the same statement necessarily apply if the filesystem was writing things asynchronously to the backing storage? Thanks, -Ngie ___ 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: effect of strip(1) on du(1)
> On Fri, Mar 3, 2017 at 2:04 AM, Peter Jeremy wrote: > > On 2017-Mar-02 22:29:46 +0300, Subbsd wrote: > >>During some interval after strip call, du will show 512B for any file. > >>If execute du(1) after strip(1) without delay, this behavior is reproduced > >>100%: > > > > What filesystem are you using? strip(1) rewrites the target file and du(1) > > reports the number of blocks reported by stat(2). It seems that you are > > hitting a situation where the file metadata isn't immediately updated. > > > > -- > > Peter Jeremy > > > Got it. My filesystem is ZFS. Looks like when ZFS open and write data > to file, we get wrong number of blocks during a small interval after > writing. Thanks for pointing this out! Even if that is the case file system cache effects should NOT be visible to a userland process. This is NOT as if your running 2 different processing beating on a file. Your test cases are serialially syncronous shell invoked commands seperated with && the results should be exact and predictable. When strip returns the operation from the userland perspecive is completed and any and all processeses started after that should have the view of the completed strip command. This IS a bug. -- 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: effect of strip(1) on du(1)
On Fri, Mar 3, 2017 at 2:04 AM, Peter Jeremy wrote: > On 2017-Mar-02 22:29:46 +0300, Subbsd wrote: >>During some interval after strip call, du will show 512B for any file. >>If execute du(1) after strip(1) without delay, this behavior is reproduced >>100%: > > What filesystem are you using? strip(1) rewrites the target file and du(1) > reports the number of blocks reported by stat(2). It seems that you are > hitting a situation where the file metadata isn't immediately updated. > > -- > Peter Jeremy Got it. My filesystem is ZFS. Looks like when ZFS open and write data to file, we get wrong number of blocks during a small interval after writing. Thanks for pointing this out! ___ 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: effect of strip(1) on du(1)
On 2017-Mar-02 22:29:46 +0300, Subbsd wrote: >During some interval after strip call, du will show 512B for any file. >If execute du(1) after strip(1) without delay, this behavior is reproduced >100%: What filesystem are you using? strip(1) rewrites the target file and du(1) reports the number of blocks reported by stat(2). It seems that you are hitting a situation where the file metadata isn't immediately updated. -- Peter Jeremy signature.asc Description: PGP signature
Re: Buildworld fails if WITHOUT_INET6=YES defined
On Thu, Mar 2, 2017 at 11:40 AM, Alex Deiter wrote: > Hello, > > Please apply patch from upstream: > > https://github.com/the-tcpdump-group/libpcap/pull/541 > > Fix compilation if INET6 isn't defined. > Addresses GitHub issue #541, but differently from the pull request (it > defines gen_gateway() with a function prototype rather than using a > pre-prototype-style definition). > > https://github.com/the-tcpdump-group/libpcap/commit/470df104c6f55f6d6f390df7448d8eb65c7642b9#diff-021c0dd9e9ed7100b9e31d8d95c930f2 Hi Dieter, Could you please open a bug and CC glebius@ and myself on it? Thanks! -Ngie ___ 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: PowerMac G5 and KMS
On 2017-Mar-2, at 9:37 AM, Justin Hibbits wrote: > On Thu, Mar 2, 2017 at 5:42 AM, Hiroo Ono (小野寛生) > wrote: >> I recently installed 12-current powerpc64 r313561 to a PowerMac G5 >> (it is dual processor, but I do not know its detail). >> >> When I try to load drm2.ko and radeonkms.ko, >> the screen turns into black and recovers, then the system locks. >> kldload command does not return, no response to keyboard input, etc. >> >> Is it possible to use KMS on FreeBSD/powerpc64? >> >> The log in /var/log/messages is >> >> after "kldload drm2", >> >> kernel: info: [drm] Initialized drm 1.1.0 20060810 >> >> and then, after "kldload radeonkms", >> >> kernel: iic0: on iicbus0 >> kernel: iic1: on iicbus1 >> kernel: drmn0: on vgapci0 >> kernel: info: [drm] RADEON_IS_AGP >> kernel: info: [drm] initializing kernel modesetting (RV350 0x1002:0x4150 >> 0x1002:0x4150). >> kernel: info: [drm] register mmio base: 0x9000 >> kernel: info: [drm] register mmio size: 65536 >> kernel: info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... >> kernel: info: [drm] igp_read_bios_from_vram: VRAM base address: 0x9800 >> kernel: info: [drm] igp_read_bios_from_vram: Map address: >> 0xc00061412000 (262144 bytes) >> kernel: info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: >> 0x >> kernel: info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... >> kernel: info: [drm] radeon_read_bios: Map address: 0xc00061412000 >> (131072 bytes) >> kernel: info: [drm] radeon_read_bios: Incorrect BIOS signature: 0x2AFF >> kernel: info: [drm] legacy_read_disabled_bios: ===> Try disabled BIOS >> (legacy)... >> kernel: info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... >> kernel: info: [drm] radeon_read_bios: Map address: 0xc00061412000 >> (131072 bytes) >> >> As the system locks up here, I have to power it off forcibly. > > Congratulations (?) you are quite possibly the first person to report > even attempting to use radeonkms on powerpc64. Frankly, I'm not > surprised that it doesn't work for you. Unfortunately, I don't have a > solution, or even a means to track it down. Looking at the log > snippet, my first guess is there may need to be a provision added to > the driver for non-x86. Do you know what card this is? > > Adding a couple other lists with people who might have more insight. > > If it can be made to work, I'd definitely want to get a Radeon card for my > G5(s) > > - Justin Back on 2014-Nov-21 I wrote the following in one of my messages on the lists on that day: > FYI: I've been building and trying Jean-Sébastien Pédron's kms-drm-update-38 > branch when Jean requested (sometimes with patches that Jean provided). This > was to give Jean some (indirect) access to a powerpc64 (PowerMac G5) Radeon > context for some radeonkms development. (Jean had been hoping to get my card > going in that context.) We got to the point that a kldload for radeonkms did > not complain/refuse but the display was then munged up and the driver could > not find the Video BIOS. The fact that it is a Radeon X1950 for the video > hardware may make it odder than usual for PowerMac G5 Radeons. But it is the > only Radeon that I have access to for G5's. (The card works in Mac OS X > 10.5.) (As I remember this was a PowerMac G5 so-called "Quad Core" as the G5 context. I do not currently have access to the X1950 card.) I'm not sure from what I read if things are about the same vs. if things are worse now. I do not remember the details from back then, such as console vs. X11 that I was not explicit about in the quoted material. I eventually gave up on using X11 "for a time" --and have not tried again so far. I've no clue about the current status for X11 on PowerMacs of any kind --or what I'd need to do to try it for the Radeon X1950 or any NVIDIA cards. (Currently an NVIDIA card is installed.) I will eventually have access to the X1950 again, but not soon. === Mark Millard markmi at dsl-only.net ___ 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: Buildworld fails if WITHOUT_INET6=YES defined
Hello,
Please apply patch from upstream:
https://github.com/the-tcpdump-group/libpcap/pull/541
Fix compilation if INET6 isn't defined.
Addresses GitHub issue #541, but differently from the pull request (it
defines gen_gateway() with a function prototype rather than using a
pre-prototype-style definition).
https://github.com/the-tcpdump-group/libpcap/commit/470df104c6f55f6d6f390df7448d8eb65c7642b9#diff-021c0dd9e9ed7100b9e31d8d95c930f2
Thank you!
Alex Deiter
alex.dei...@gmail.com
> On 18 Feb 2017, at 00:09, Bryan Drewery wrote:
>
> On 2/17/2017 1:03 PM, Bryan Drewery wrote:
>> On 2/16/2017 10:07 AM, Ngie Cooper (yaneurabeya) wrote:
>>>
On Feb 16, 2017, at 07:30, Oleg V. Nauman wrote:
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -march=core2 -DHAVE_CONFIG_H -
I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD -
MF.depend.fad-getad.o -MTfad-getad.o -std=gnu99 -fstack-protector-strong
-Wno-
pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -
Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch
-
Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-
arguments -c /usr/src/contrib/libpcap/fad-getad.c -o fad-getad.o
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -march=core2 -DHAVE_CONFIG_H -
I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD -
MF.depend.gencode.o -MTgencode.o -std=gnu99 -fstack-protector-strong -Wno-
pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -
Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch
-
Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-
arguments -c /usr/src/contrib/libpcap/gencode.c -o gencode.o
/usr/src/contrib/libpcap/gencode.c:695:9: error: no member named 'ai' in
'struct _compiler_state'
cstate.ai = NULL;
~~ ^
/usr/src/contrib/libpcap/gencode.c:4916:13: error: use of undeclared
identifier 'cstate'
bpf_error(cstate, "direction applied to 'gateway'");
^
/usr/src/contrib/libpcap/gencode.c:4923:11: error: use of undeclared
identifier 'cstate'
switch (cstate->linktype) {
^
/usr/src/contrib/libpcap/gencode.c:4961:17: error: use of undeclared
identifier 'cstate'
b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR,
Q_HOST);
^
/usr/src/contrib/libpcap/gencode.c:4963:19: error: use of undeclared
identifier 'cstate'
tmp = gen_host(cstate, **alist++, 0x, proto,
Q_OR,
^
/usr/src/contrib/libpcap/gencode.c:4972:12: error: use of undeclared
identifier 'cstate'
bpf_error(cstate, "illegal modifier of 'gateway'");
^
6 errors generated.
*** Error code 1
Stop.
make[5]: stopped in /usr/src/lib/libpcap
*** Error code 1
>>>
>>> CCing Xin, who did the libpcap upgrade.
>>> -Ngie
>>>
>>
>> I get an error even with INET6 building grammar.o:
>>
>>> /root/git/freebsd/contrib/libpcap/grammar.y:348:15: error: use of
>>> undeclared identifier 'cstate'; did you mean 'cstat'?
>>>finish_parse(cstate, yystack.l_mark[0].blk.b);
>>>
>>> ^~
>>>
>>> cstat
>>>
>>> grammar.c:1291:1: note: 'cstat' declared here
>>>
>>> YYPARSE_DECL()
>>>
>>> ^
>>>
>>
>
> Ignore me, my yacc is just outdated.
>
> --
> Regards,
> Bryan Drewery
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any
effect of strip(1) on du(1)
Hi, Not sure for FreeBSD < 12, but i found interesting behavior strip effect(1) on du(1) command: -- % strip /bin/pax && sleep 4 && du -sh /bin/pax 65K/bin/pax % strip /bin/pax && sleep 3 && du -sh /bin/pax 65K/bin/pax % strip /bin/pax && sleep 2 && du -sh /bin/pax 512B/bin/pax % strip /bin/pax && sleep 3 && du -sh /bin/pax 65K/bin/pax -- During some interval after strip call, du will show 512B for any file. If execute du(1) after strip(1) without delay, this behavior is reproduced 100%: % strip /bin/sh && du /bin/sh 1 /bin/sh What such behavior is connected with? ___ 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: PowerMac G5 and KMS
On 02/03/17 11:37, Justin Hibbits wrote: > On Thu, Mar 2, 2017 at 5:42 AM, Hiroo Ono (小野寛生) > wrote: >> kernel: drmn0: on vgapci0 >> kernel: info: [drm] RADEON_IS_AGP >> kernel: info: [drm] initializing kernel modesetting (RV350 0x1002:0x4150 >> 0x1002:0x4150). > > Congratulations (?) you are quite possibly the first person to report > even attempting to use radeonkms on powerpc64. It works fine on Debian Jessie for me, so I would assume that it should be at least possible to do the same on FreeBSD with some tweaking. The only FreeBSD install I have on a PPC is serial console only so I haven't really used graphics on it. > Do you know what card this is? It looks like a Radeon 9600 RV350 from the pasted kernel log, which is consistent with the Radeons that Apple shipped with the early G5 DPs. Note to OP: if you can manage to get it to work, the framebuffer works great, but Mesa still has some endianness issues. There are a few of us in the Linux and BSD world that are doing what we can to fix it, but there's not a whole lot of us, so progress is slow going. You'll have a lot more luck with NV30/NV40/NV50 cards if you want OpenGL for now. As I have a PowerBook G4 with a RV350, which obviously cannot be replaced as it is a laptop, that should change soon hopefully. Best, --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: PowerMac G5 and KMS
On Thu, Mar 2, 2017 at 5:42 AM, Hiroo Ono (小野寛生) wrote: > I recently installed 12-current powerpc64 r313561 to a PowerMac G5 > (it is dual processor, but I do not know its detail). > > When I try to load drm2.ko and radeonkms.ko, > the screen turns into black and recovers, then the system locks. > kldload command does not return, no response to keyboard input, etc. > > Is it possible to use KMS on FreeBSD/powerpc64? > > The log in /var/log/messages is > > after "kldload drm2", > > kernel: info: [drm] Initialized drm 1.1.0 20060810 > > and then, after "kldload radeonkms", > > kernel: iic0: on iicbus0 > kernel: iic1: on iicbus1 > kernel: drmn0: on vgapci0 > kernel: info: [drm] RADEON_IS_AGP > kernel: info: [drm] initializing kernel modesetting (RV350 0x1002:0x4150 > 0x1002:0x4150). > kernel: info: [drm] register mmio base: 0x9000 > kernel: info: [drm] register mmio size: 65536 > kernel: info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... > kernel: info: [drm] igp_read_bios_from_vram: VRAM base address: 0x9800 > kernel: info: [drm] igp_read_bios_from_vram: Map address: > 0xc00061412000 (262144 bytes) > kernel: info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: > 0x > kernel: info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... > kernel: info: [drm] radeon_read_bios: Map address: 0xc00061412000 > (131072 bytes) > kernel: info: [drm] radeon_read_bios: Incorrect BIOS signature: 0x2AFF > kernel: info: [drm] legacy_read_disabled_bios: ===> Try disabled BIOS > (legacy)... > kernel: info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... > kernel: info: [drm] radeon_read_bios: Map address: 0xc00061412000 > (131072 bytes) > > As the system locks up here, I have to power it off forcibly. Congratulations (?) you are quite possibly the first person to report even attempting to use radeonkms on powerpc64. Frankly, I'm not surprised that it doesn't work for you. Unfortunately, I don't have a solution, or even a means to track it down. Looking at the log snippet, my first guess is there may need to be a provision added to the driver for non-x86. Do you know what card this is? Adding a couple other lists with people who might have more insight. If it can be made to work, I'd definitely want to get a Radeon card for my G5(s) - Justin ___ 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: CFLAGS for certain ports
On Thu, Mar 2, 2017 at 5:58 AM, Dimitry Andric wrote:
> On 2 Mar 2017, at 12:02, Mingo Rrubioer wrote:
>>
>> I would like to see how well FreeBSD does as a workstation OS in the
>> HPC world due to its stability and reliability, as well as LLVM/clang.
>> I would like to know if FreeBSD has something similar to Gentoo's
>> /etc/portage/make.conf file and /etc/portage/package.use/* files in
>> order to compile certain ports with certain compiler flags.
>
> It doesn't, though it would certainly be nice to have something like it
> at some point. The current idiom is to put something similar to the
> following in your /etc/make.conf:
>
> .if ${.CURDIR:M/usr/ports/foo/bar}
> CFLAGS+= [... flags for the foo/bar port ...]
> .endif
>
> .if ${.CURDIR:M/usr/ports/what/ever}
> CFLAGS+= [... flags for the what/ever port ...]
> .endif
Actually, you can enable options on a per-port basis by creating a
file named /var/db/ports/_/options. Those are the
files that get created whenever you do "make config" in a port
directory. It's usually easiest to create them interactively just by
doing "make config" though.
>
>
>> Regarding LLVM/clang, I've been reading the documentation and found
>> these flags: -arch=, -march=, -mcpu=,
>> --target=, target-cpu . I'm not quite sure which
>> one would be the one to use. In case someone wants to know, my initial
>> play/test machine has this processor:
>>
>> CPU: Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz (3600.11-MHz K8-class CPU)
>> Origin="GenuineIntel" Id=0x206d7 Family=0x6 Model=0x2d Stepping=7
>>
>> And I'm currently running: 11.0-RELEASE-p8.
>>
>> So I imagine I should use something like CFLAGS+= -march=corei7-avx
>> -march=sandybridge -target-cpu. Is that correct?
>
> Don't specify -march or -mcpu directly, but add the following line to
> /etc/make.conf:
>
> CPUTYPE?= native
>
> This will take care of everything automatically. See also make.conf(5).
>
> -Dimitry
>
___
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: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]
On Thu, Mar 02, 2017 at 01:10:21PM +0100, Mateusz Guzik wrote: > On Wed, Mar 01, 2017 at 09:45:07AM -0800, Mark Millard wrote: > > > > Summary of the transition interval: > > > > So for powerpc64 (and powerpc?) It is a good > > idea to avoid anything that is after -r313254 > > and before -r314474 in head. (Would this be > > appropriate for a UPDATING notice given its > > span?) > > > > There may be other architectures that might have > > a similar status(?): the last fixes involved were > > not in Machine Dependent code. (Some architectures > > are apparently insensitive to the errors, such as > > amd64). > > > > When following current you are expected to be on the newest revision, > so I don't think mentioning interim broken releases makes much sense. > Documenting the range may aid those bisecting src/ to find a bug. How is one to know that anything in the range that Mark points out should be skipped on powerpc64? -- Steve ___ 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: CFLAGS for certain ports
On 2 Mar 2017, at 12:02, Mingo Rrubioer wrote:
>
> I would like to see how well FreeBSD does as a workstation OS in the
> HPC world due to its stability and reliability, as well as LLVM/clang.
> I would like to know if FreeBSD has something similar to Gentoo's
> /etc/portage/make.conf file and /etc/portage/package.use/* files in
> order to compile certain ports with certain compiler flags.
It doesn't, though it would certainly be nice to have something like it
at some point. The current idiom is to put something similar to the
following in your /etc/make.conf:
.if ${.CURDIR:M/usr/ports/foo/bar}
CFLAGS+= [... flags for the foo/bar port ...]
.endif
.if ${.CURDIR:M/usr/ports/what/ever}
CFLAGS+= [... flags for the what/ever port ...]
.endif
> Regarding LLVM/clang, I've been reading the documentation and found
> these flags: -arch=, -march=, -mcpu=,
> --target=, target-cpu . I'm not quite sure which
> one would be the one to use. In case someone wants to know, my initial
> play/test machine has this processor:
>
> CPU: Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz (3600.11-MHz K8-class CPU)
> Origin="GenuineIntel" Id=0x206d7 Family=0x6 Model=0x2d Stepping=7
>
> And I'm currently running: 11.0-RELEASE-p8.
>
> So I imagine I should use something like CFLAGS+= -march=corei7-avx
> -march=sandybridge -target-cpu. Is that correct?
Don't specify -march or -mcpu directly, but add the following line to
/etc/make.conf:
CPUTYPE?= native
This will take care of everything automatically. See also make.conf(5).
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]
On Wed, Mar 01, 2017 at 09:45:07AM -0800, Mark Millard wrote: > > On 2017-Feb-28, at 10:13 PM, Mateusz Guzik wrote: > > On Sat, Feb 25, 2017 at 08:31:04PM +0100, Mateusz Guzik wrote: > >> On Sat, Feb 25, 2017 at 09:58:39AM -0800, Mark Millard wrote: > >>> Thus the PowerMac G5 so-called "Quad Core" is back to > >>> -r313254 without your patches. (The "Quad Core" really has > >>> two processors, each with 2 cores.) > >>> > >> > >> > >> Thanks a lot for testing. I'll have to think what to do with it, worst > >> case I'll #ifdef changes with powerpc. > >> > > > > Should be fixed with r314474. Got a real powerpc to test on (60 cores), > > was able to lock it up in seconds. Now it is perfectly stablle. > > > > -- > > Mateusz Guzik > > The updated so-called "Quad Core" PowerMac G5 used for > TARGET_ARCH=powerpc64 was able to do a self hosted > buildworld buildkernel for -r314479 just fine. > Cool. > Thanks much for the fixes: Now I can track head again > for powerpc64. > Well it was my breakage to begin with. > > Summary of the transition interval: > > So for powerpc64 (and powerpc?) It is a good > idea to avoid anything that is after -r313254 > and before -r314474 in head. (Would this be > appropriate for a UPDATING notice given its > span?) > > There may be other architectures that might have > a similar status(?): the last fixes involved were > not in Machine Dependent code. (Some architectures > are apparently insensitive to the errors, such as > amd64). > When following current you are expected to be on the newest revision, so I don't think mentioning interim broken releases makes much sense. -- Mateusz Guzik ___ 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"
CFLAGS for certain ports
Hello, New to FreeBSD and first post. If I got the wrong mailing list, just let me know where to ask my questions. I would like to see how well FreeBSD does as a workstation OS in the HPC world due to its stability and reliability, as well as LLVM/clang. I would like to know if FreeBSD has something similar to Gentoo's /etc/portage/make.conf file and /etc/portage/package.use/* files in order to compile certain ports with certain compiler flags. Currently I mainly use CFLAGS="-O2 -pipe -mtune=native" for most of the applications, so nothing really aggressive (in general). I've been reading through some FreeBSD docs (Handbook and ports documentation) but haven't found the answer (maybe looking in the wrong place). Regarding LLVM/clang, I've been reading the documentation and found these flags: -arch=, -march=, -mcpu=, --target=, target-cpu . I'm not quite sure which one would be the one to use. In case someone wants to know, my initial play/test machine has this processor: CPU: Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz (3600.11-MHz K8-class CPU) Origin="GenuineIntel" Id=0x206d7 Family=0x6 Model=0x2d Stepping=7 And I'm currently running: 11.0-RELEASE-p8. So I imagine I should use something like CFLAGS+= -march=corei7-avx -march=sandybridge -target-cpu. Is that correct? Currently all our deployed workstations are Intel with NVIDIA Quadro graphics cards. My target is not to migrate everything, I just want to know if FreeBSD would be suitable and where. As I mentioned, this would be for specific scientific applications, not system wide. Thanks !! ___ 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: panic: invalid bcd xxx
On Thursday, 2 March 2017 00:37:35 CET, Michael Gmelin wrote: On 2 Mar 2017, at 00:35, Adrian Chadd wrote: This is an emulated BIOS though, right? I don't know if we're going to get the RTC 'bugfixed'... It's SeaBIOS, yes. I feel like this might end up in another quirk/workaround solution. I'm one of the C720 owners and apart of Michael, I only know two users more running FreeBSD. The SeaBIOS in our devices. is outdated, mine from 2013 IIRC. I dont know if there is an easy way to update this. matthias -- Sent from my Ubuntu phone http://www.unixarea.de/ ___ 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"
