Re: Booting native 4K SSD disk from FreeBSD ?
> On 4 Oct 2017, at 00:18, Hans Petter Selaskywrote: > > Hi, > > I accidentially ordered a Sata SSD disk which diskinfo reports a sector-size > 4K instead of 512 bytes. Trying to get it to boot under FreeBSD appeared > impossible. Then I started looking into the boot0,1,2 and loader and the > assumptions they make about 512 byte sector size LBA :-( > > Anyone has any recommendations or experience about how to use native 4K disks > with FreeBSD? > The fastest way right now is via UEFI boot, it should be able to cope with 4k, but as Allan noted, there may be some corners. The BIOS version is totally out right now, it only is supporting 512B sectors. I have been working to fix it starting with loader libi386 biosdisk interface (for loader itself), but due to lack of time it has been delayed somewhat. The plain loader bits are done, but the +GELI needs more work (the code has to cope with 512/4k sector and GELI is only doing 4k logical IO). The hard part is about the boot1 code (boot1,gptboot etc) and thats due to boot block area size limits (in existing setups). We are struggling to fit into UFS boot block area, and freebsd-boot and ESP sizes are also very small, making all this pain in the … rgds, toomas ___ 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: Booting native 4K SSD disk from FreeBSD ?
On 10/03/2017 17:18, Hans Petter Selasky wrote: > Hi, > > I accidentially ordered a Sata SSD disk which diskinfo reports a > sector-size 4K instead of 512 bytes. Trying to get it to boot under > FreeBSD appeared impossible. Then I started looking into the boot0,1,2 > and loader and the assumptions they make about 512 byte sector size LBA :-( > > Anyone has any recommendations or experience about how to use native 4K > disks with FreeBSD? > > --HPS > ___ > 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" It is not possible in legacy/BIOS mode, because the BIOS calls do not let you specify a sector size. However, you SHOULD be able to boot from the 4k device using UEFI. I am trying to debug a problem I am having with this on my new Mac, which has a 4k NVMe disk. -- Allan Jude ___ 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"
Booting native 4K SSD disk from FreeBSD ?
Hi, I accidentially ordered a Sata SSD disk which diskinfo reports a sector-size 4K instead of 512 bytes. Trying to get it to boot under FreeBSD appeared impossible. Then I started looking into the boot0,1,2 and loader and the assumptions they make about 512 byte sector size LBA :-( Anyone has any recommendations or experience about how to use native 4K disks with FreeBSD? --HPS ___ 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: anyone know how to get rid of this error? (10.4/Gcc vs binutils port)
On 4/10/17 12:56 am, Ian Lepore wrote: On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote: Our 10.4 system is using gcc (for now). when we compile the devel/binutils port, we get a failure with a bunch of these errors: `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section `.rodata' of aarch64.o: defined in discarded section `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__ N_110Stub_tableILi64ELb1EEE]' of aarch64.o `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section `.rodata' of aarch64.o: defined in discarded section `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__ N_110Stub_tableILi64ELb0EEE]' of aarch64.o I managed to defeat these one before but I forget how. possibly the answer is to use clang/clang++ for this item but I tried defining CC and CXX to clang/clang++ in the Makefile but that didn't seem to help there's probably a USE_CLANG option or something that I haven't seen. We ran into the same thing recently at $work. The root cause for us involved having same-named classes in anonymous namespaces in different compilation units. The classes made reference to something that was declared extern "C", bringing into play some rules about how C things in anon namespaces really refer to the same global C object outside of any namespace. Then link-time optimization led to discarding the object from one compilation unit, and that somehow resulted in discarding the referenced extern "C" thing completely, even though it was still referenced from the non-discarded instance of an object from a different compilation unit. Phew. The same code has no problems with clang on freebsd 11, just with gcc on 10.3. So, for us the fix was a bit heavy-handed: we just renamed one of the classes involved in the problem so that there were no longer any same- named classes in anon namespaces in separate compilation units. Probably not a good option for you. A fix involving compile options might result in not discarding unreferenced segments at all, and with templated code that might result in huge binaries. Mixing clang-compiled and gcc-compiled c++ may give you grief with exceptions and other things (it would on ARM on 10.x, but maybe not on x86 arches). -- Ian thanks the issue comes up in the binutils port which is a dependency of gdb. I don't think we actually need to install the binutils port on our appliance, (and we only install gdb to generate backtraces on debug reports) I just added CC=clang and CXX=clang++ in the makefile that called it and the problem seemed to go away. All i wanted to do is get gdb compiled and I end up with gcc6, llvm and binutils (plus a whole lot more) as a bonus (plus an extra 30 minutes of compile time) ___ 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: anyone know how to get rid of this error? (10.4/Gcc vs binutils port)
On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote: > Our 10.4 system is using gcc (for now). > > when we compile the devel/binutils port, we get a failure with a > bunch > of these errors: > > > `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section > `.rodata' of aarch64.o: defined in discarded section > `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__ > N_110Stub_tableILi64ELb1EEE]' > of aarch64.o > `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section > `.rodata' of aarch64.o: defined in discarded section > `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__ > N_110Stub_tableILi64ELb0EEE]' > of aarch64.o > > > I managed to defeat these one before but I forget how. > > possibly the answer is to use clang/clang++ for this item but I > tried > defining CC and CXX to clang/clang++ in the Makefile but that > didn't > seem to help > > there's probably a USE_CLANG option or something that I haven't seen. We ran into the same thing recently at $work. The root cause for us involved having same-named classes in anonymous namespaces in different compilation units. The classes made reference to something that was declared extern "C", bringing into play some rules about how C things in anon namespaces really refer to the same global C object outside of any namespace. Then link-time optimization led to discarding the object from one compilation unit, and that somehow resulted in discarding the referenced extern "C" thing completely, even though it was still referenced from the non-discarded instance of an object from a different compilation unit. Phew. The same code has no problems with clang on freebsd 11, just with gcc on 10.3. So, for us the fix was a bit heavy-handed: we just renamed one of the classes involved in the problem so that there were no longer any same- named classes in anon namespaces in separate compilation units. Probably not a good option for you. A fix involving compile options might result in not discarding unreferenced segments at all, and with templated code that might result in huge binaries. Mixing clang-compiled and gcc-compiled c++ may give you grief with exceptions and other things (it would on ARM on 10.x, but maybe not on x86 arches). -- Ian ___ 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"
anyone know how to get rid of this error? (10.4/Gcc vs binutils port)
Our 10.4 system is using gcc (for now). when we compile the devel/binutils port, we get a failure with a bunch of these errors: `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section `.rodata' of aarch64.o: defined in discarded section `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE]' of aarch64.o `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section `.rodata' of aarch64.o: defined in discarded section `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE]' of aarch64.o I managed to defeat these one before but I forget how. possibly the answer is to use clang/clang++ for this item but I tried defining CC and CXX to clang/clang++ in the Makefile but that didn't seem to help there's probably a USE_CLANG option or something that I haven't seen. ___ 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: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?
Am Tue, 3 Oct 2017 13:08:53 +0200 Kurt Jaegerschrieb: > Hi! > > > When using "poudriere", it seems ABI is freebsd:12:x86:64. As I wrote: poudriere repo. > > Where do you get that value from ? If I access a repo, > I access e.g. > > https://repo.opsec.eu/${ABI} > > and ABI maps to > > FreeBSD:12:amd64 > -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpcewSS0GN14.pgp Description: OpenPGP digital signature
Re: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?
Hi! > When using "poudriere", it seems ABI is freebsd:12:x86:64. Where do you get that value from ? If I access a repo, I access e.g. https://repo.opsec.eu/${ABI} and ABI maps to FreeBSD:12:amd64 -- p...@opsec.eu+49 171 3101372 3 years to go ! ___ 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: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?
On Tue, 3 Oct 2017 10:51:24 +0200, "O. Hartmann"wrote: > When using "poudriere", it seems ABI is freebsd:12:x86:64. When using FreeBSD > base, it > seems always to be referred to FreeBSD:12:amd64. What now? All non-BSD world > uses x86:64, > FreeBSD is using amd64, but why is this used inconsistently all over the > places? > > I run into trouble setting up some package- and base-servers and ran into the > problem > when deleting - not thinking of this discovered inconsistency - some links on > the servers > regarding FreeBSD:12:x86:64 (the same is for 11-STABLE). > > Can someone shed some light onto this? > > What am I supposed to use now? The handbook referes to amd64, so I thought > poudriere > would, too. > > Thanks in advance, > > oh > -- > O. Hartmann > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). [ not using poudriere yet ] /me too I think three places [ etc/pkg, /usr/local/etc/pkg/repos, 2nd place in base, ] fourth: hard coded DESPITE the above in the current DB in var/db/pkg? fifth: derived somehow from uname -a? here: freebsd:12:x86:32 ... when this issue resolved, could it please be added to 'man pkg|poudriere|syntch|portmaster?|portupgrade? [ the latter two when developed further ]' ___ 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"
ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?
When using "poudriere", it seems ABI is freebsd:12:x86:64. When using FreeBSD base, it seems always to be referred to FreeBSD:12:amd64. What now? All non-BSD world uses x86:64, FreeBSD is using amd64, but why is this used inconsistently all over the places? I run into trouble setting up some package- and base-servers and ran into the problem when deleting - not thinking of this discovered inconsistency - some links on the servers regarding FreeBSD:12:x86:64 (the same is for 11-STABLE). Can someone shed some light onto this? What am I supposed to use now? The handbook referes to amd64, so I thought poudriere would, too. Thanks in advance, oh -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpnBI5iRcECp.pgp Description: OpenPGP digital signature