Re: Call for Testing: 11.1-RELEASE Meltdown/Spectre mitigation merge

[Joseph Mulloy]

Thanks,

It did fail to patch that file. I changed the line with the svn tag to 
"/* $FreeBSD$ */" to match the patch and it applied successfully.


It now compiles successfully.


On 3/12/18 10:10 PM, J David wrote:

On Mon, Mar 12, 2018 at 10:00 PM, Joseph Mulloy
 wrote:

/usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete
type ‘struct pti_frame'

This might be the error you get if frame.h did not patch correctly.
It’s a known issue with the patch (the SVN tag doesn’t match).

Check for a /usr/src/sys/amd64/include/frame.h.rej file.

If so, just fix the SVN tag and re-apply and it should build correctly.

If that’s your issue, there should be an updated version available
soon, if not already.

Good luck!
___
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"


___
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: Call for Testing: 11.1-RELEASE Meltdown/Spectre mitigation merge

[J David]

On Mon, Mar 12, 2018 at 10:00 PM, Joseph Mulloy
 wrote:
> /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete
> type ‘struct pti_frame'

This might be the error you get if frame.h did not patch correctly.
It’s a known issue with the patch (the SVN tag doesn’t match).

Check for a /usr/src/sys/amd64/include/frame.h.rej file.

If so, just fix the SVN tag and re-apply and it should build correctly.

If that’s your issue, there should be an updated version available
soon, if not already.

Good luck!
___
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: Call for Testing: 11.1-RELEASE Meltdown/Spectre mitigation merge

[Joseph Mulloy]

Hi,

I'm trying to test the Meltdown mitigation by applying the patch at 
https://people.freebsd.org/~emaste/patches/amd64_11.1_meltdown.3.patch 
and I'm getting a ton of error when I try to build the kernel with "make 
buildkernel". I've tried applying the patch against release/11.1.0 and 
releng/11.1 and they both fail with the same compiler errors. I tried 
running make clean and that doesn't fix it. I'm probably doing something 
wrong, I couldn't find any instructions on how to apply the patch, it 
took me a while to figure it out even with the man page. Perhaps there's 
some step in the process that I don't know about. I haven't been able to 
find any docs about doing this sort of thing.


Thanks for any help you can provide. I would like to help with the testing.

I'm applying the patch with the following command and it seems to apply 
just fine.


patch < amd64_11.1_meltdown.3.patch

This is the output of svn info

root@server1:/usr/src # svnlite info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/release/11.1.0
Relative URL: ^/release/11.1.0
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 330824
Node Kind: directory
Schedule: normal
Last Changed Author: gjb
Last Changed Rev: 321354
Last Changed Date: 2017-07-21 20:55:38 + (Fri, 21 Jul 2017)

Below are the compiler errors I'm getting.

--
>>> stage 3.1: building everything
--
cd /usr/obj/usr/src/sys/GENERIC; COMPILER_VERSION=4 
COMPILER_FEATURES=c++11  COMPILER_TYPE=clang 
COMPILER_FREEBSD_VERSION=1100504 MAKEOBJDIRPREFIX=/usr/obj 
MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE= 
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/us
r/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font 
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc 
-target x86_64-unknown-freebsd11.1 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -targ
et x86_64-unknown-freebsd11.1 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target 
x86_64-unknown-freebsd11.1 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" NM=nm 
OBJDUMP=objdump OBJ
COPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"  INSTALL="sh 
/usr/src/tools/install.sh" 
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tm
p/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make  -m /usr/src/share/mk  
KERNEL=kernel all -DNO_MODULES_OBJ

machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
cc -target x86_64-unknown-freebsd11.1 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -g 
-nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_glob
al.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD 
-MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone 
-mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wre
dundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tau
tological-compare -Wno-error-empty-body -Wno-error-parentheses-equality 
-Wno-error-unused-function -Wno-error-pointer-sign 
-Wno-error-shift-negative-value -Wno-error-address-of-packed-member 
-mno-aes -mno-avx -std=iso9899:1999 /usr/src/sys/amd64/amd64/

genassym.c
/usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of 
incomplete type 'struct pti_frame'

ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx));
   ^~~
/usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof'
#define offsetof(type, field) __offsetof(type, field)
  ^  
/usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof'
#define __offsetof(type, field)  __builtin_offsetof(type, field)
 ^  
/usr/src/sys/sys/assym.h:38:21: note: expanded from macro 'ASSYM'
char name ## sign[((value) < 0 ? 1 : 0) + 
ASSYM_BIAS];\

^
/usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 
'struct pti_frame'

ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx));
   ^
/usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of 
incomplete type 'struct pti_frame'

ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx));
   ^~~
/usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof'
#define offsetof(type, field) 

FreeBSD 11.x fails to boot w/ SAS3 4Kn HDD and LSISAS3008 on SuperMicro X10DRH-iT

[Rick Miller]

Hi all,

Thanks in advance to anyone that might be able to help. I subscribed to
freebsd-geom@ so that the list did not need to "reply-all". Having trouble
getting FreeBSD 11-STABLE @ r329011 to boot from SAS3 4Kn HDDs via LSISAS
3008 HBA on a SuperMicro X10DRH-iT motherboard after an apparent
installation. All internal media (including all other disks attached to the
HBA) were removed to eliminate other storage being the reason the system
won't boot. This occurs specifically in CSM mode, but the preference is to
boot via UEFI mode instead.

Anyway...booting the machine via the memstick image demonstrates the LSISAS
3008 controller attaching via mpr(4) (whose manpage describes the
controller being supported[1]):

mpr0@pci0:3:0:0: class=0x010700 card=0x080815d9 chip=0x00971000 rev=0x02
hdr=0x00
  vendor   = 'LSI Logic / Symbios Logic'
  device   = 'SAS3008 PCI-Express Fusion-MPT SAS-3'
  class = mass storage
  subclass = SAS

The only inserted disk attaches as da0 as illustrated by dmesg:

ses0: pass0,da0: Elemne t descriptor: 'Slot00'
da0 at mpr0 bus 0 scbus0 target 8 lun 0
ses0: pass0,da0: SAS Device Slot Element: 1 Phys at Slot 0
ses0:  phy 0: SAS device type 1 id 0
ses0:  phy 0: protocols: initiator( None ) Target( SSP )
ses0:  phy 0: parent 500304801e870bff addr 5000c500a012814d
da0:   Fixed Direct Access SPC-4 SCSI device
da0:  Serial Number $serial_number
da0: 1200.000MB/s transfers
da0: Command queueing enabled
da0: 1907729MB (488378648 4096 byte sectors)

The original goal was to boot via zfs root, but when that failed,
subsequent installations used the "Auto (UFS) option" to partition the
disk. For example, the first installation gpart'd the disk as:

# gpart show da0
=>6  488378635  da0  GPT   (1.8T)
6  128  1  freebsd-boot  (512K)
134  487325568  2  freebsd-ufs  (1.8T)
487325702  1048576  3  freebsd-swap  (4.0G)
4883742784363  - free -   (17M)

The result was a reboot loop. When the system reached the point of reading
the disk, it just rebooted and continued doing so. There was no loader or
beastie menu. Thus, thinking that it could be the partition layout
requirements of the 4Kn disks, it was gpart'd like the below[2][3]. This
was done by exiting to the shell during the partition phase of bsdinstall
and manually gpart'ing the disk according to the below, mounting da0p2 at
/mnt and placing an fstab at /tmp/bsdinstall_etc/fstab that included mount
entries for /dev/da0p2 at / and /dev/da0p3 as swap.

# gpart show da0
=>6  488378635  da0  GPT   (1.8T)
634  - free -  (136K)
  40  512  1  freebsd-boot  (2.0M)
552  419430400  2  freebsd-ufs  (1.6T)
419430952  1048576  3  freebsd-swap  (4.0G)
42047952867899113  - free -   (259G)

When configured as such, the system rebooted at the completion of the
install and appeared to roll through the boot order, which specifies the
HDD first, then CD/DVD, then network. It did attempt to boot via network,
but is irrelevant here.

All the hardware is alleged to be supported by FreeBSD as best I can tell
and OS installation apparently works. I'm at a loss as to why the OS won't
boot. Does someone have feedback or input that may expose why it doesn't
boot?

FWIW, a RHEL7 install was also attempted, which also does not boot.

[1]
https://www.freebsd.org/cgi/man.cgi?query=mpr=0=4=FreeBSD+11.1-RELEASE=default=html
[2] https://lists.freebsd.org/pipermail/freebsd-hardware/
2013-September/007380.html
[3] http://www.wonkity.com/~wblock/docs/html/disksetup.html

-- 
Take care
Rick Miller
___
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: zfs problems after rebuilding system [SOLVED]

[Ian Lepore]

On Mon, 2018-03-12 at 17:21 +, Pete French wrote:
> 
> On 10/03/2018 23:48, Ian Lepore wrote:
> > 
> > I based my fix heavily on that patch from the PR, but I rewrote it
> > enough that I might've made any number of mistakes, so it needs fresh
> > testing.  The main change I made was to make it a lot less noisy while
> > waiting (it only mentions the wait once, unless bootverbose is set, in
> > which case it's once per second).  I also removed the logic that
> > limited the retries to nfs and zfs, because I think we can remove all
> > the old code related to waiting that only worked for ufs and let this
> > new retry be the way it waits for all filesystems.  But that's a bigger
> > change we can do separately; I didn't want to hold up this fix any
> > longer.
> TThansk for the patch, its is very much appercaited! I applied this 
> earlier today, and have been continuously rebooting the machine in Azure 
> ever since (every ten minutes). This has worked flawlessly, so I am very 
> happy that this fixes the issue for me. I am going to leave it running 
> though, just to see if anything happens. I havent examined dmesg, but I 
> thould be able to see the output from the patch there to verify that its 
> waiting, yes ?
> 
> cheers,
> 
> -pete.

Yes, if the root filesystem isn't available on the first attempt, it
should emit a single line saying it will wait for up to N seconds for
it to arrive, where N is the vfs.mountroot.timeout value (3 seconds if
not set in loader.conf).

-- Ian
___
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: zfs problems after rebuilding system [SOLVED]

[Pete French]

On 10/03/2018 23:48, Ian Lepore wrote:

I based my fix heavily on that patch from the PR, but I rewrote it
enough that I might've made any number of mistakes, so it needs fresh
testing.  The main change I made was to make it a lot less noisy while
waiting (it only mentions the wait once, unless bootverbose is set, in
which case it's once per second).  I also removed the logic that
limited the retries to nfs and zfs, because I think we can remove all
the old code related to waiting that only worked for ufs and let this
new retry be the way it waits for all filesystems.  But that's a bigger
change we can do separately; I didn't want to hold up this fix any
longer.


TThansk for the patch, its is very much appercaited! I applied this 
earlier today, and have been continuously rebooting the machine in Azure 
ever since (every ten minutes). This has worked flawlessly, so I am very 
happy that this fixes the issue for me. I am going to leave it running 
though, just to see if anything happens. I havent examined dmesg, but I 
thould be able to see the output from the patch there to verify that its 
waiting, yes ?


cheers,

-pete.
___
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"