Re: Call for Testing: 11.1-RELEASE Meltdown/Spectre mitigation merge
Am 2018-03-06 17:41, schrieb Ed Maste: Background -- A number of issues relating to speculative execution were found last year and publicly announced January 3rd. A variety of techniques used to mitigate these issues have been committed to FreeBSD-CURRENT and have been merged to the stable/11 branch. The changes will be merged and released as an update to FreeBSD 11.1-RELEASE in the near future, but the candidate patch is now available for broader testing. Hi, would it be possible to provide a) patched binaries b) an installer for these binaries c) a simple tool to backup the original binaries and restore them ? Ever since binary patches became available, I've not bothered building FreeBSD any more. None of my systems have the source, nor do I want to install it anywhere. I'm also not bothering to install this in a VM - you guys have probably done this a few times. Regards Rainer ___ 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"
GEOM strange error
Hi! Let's create a stripe and GPT over it using test files as backing store: truncate -s 1G d0 truncate -s 1G d1 mdconfig -af d0 # gives md0 mdconfig -af d1 # gives md1 gpart create -s GPT md0 gpart create -s GPT md1 gpart destroy -F md1 gpart destroy -F md0# no errors still gstripe label -s $((128*1024)) st0 md0 md1 gpart create -s GPT /dev/stripe/st0 dmesg -a GEOM_STRIPE: Device st0 created (id=4000112224). GEOM_STRIPE: Disk md0 attached to st0. GEOM_STRIPE: Disk md1 attached to st0. GEOM_STRIPE: Device stripe/st0 activated. GEOM: md0: corrupt or invalid GPT detected. GEOM: md0: GPT rejected -- may not be recoverable. Why does it emit such md0-related error? ___ 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: GEOM strange error
On 13/03/2018 11:37, Eugene Grosbein wrote: > Hi! > > Let's create a stripe and GPT over it using test files as backing store: > > truncate -s 1G d0 > truncate -s 1G d1 > mdconfig -af d0 # gives md0 > mdconfig -af d1 # gives md1 > > gpart create -s GPT md0 > gpart create -s GPT md1 > gpart destroy -F md1 > gpart destroy -F md0 # no errors still > > gstripe label -s $((128*1024)) st0 md0 md1 > gpart create -s GPT /dev/stripe/st0 > dmesg -a > > GEOM_STRIPE: Device st0 created (id=4000112224). > GEOM_STRIPE: Disk md0 attached to st0. > GEOM_STRIPE: Disk md1 attached to st0. > GEOM_STRIPE: Device stripe/st0 activated. > GEOM: md0: corrupt or invalid GPT detected. > GEOM: md0: GPT rejected -- may not be recoverable. > > Why does it emit such md0-related error? When GPT is placed on st0 it's opened for writing and, thus, md0 and md1 are open for writing too. Afterwards, the write access count is cleared from three of them and that triggers re-tasting. I guess that g_part code tries to taste md0 and md1 and sees the GPT label at the start of md0 and the label is correctly rejected because it's inconsistent with md0's parameters. -- Andriy Gapon ___ 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]
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. Ok, have been rebooting with the patch eery ten minutes for 24 hours now, and it comes back up perfectly every time, so as far as I am concerned thats sufficient testing for me to say its fixed and I would be very happy to have it merged into STABLE (and I;ll then roll it out everywhere). Thanks! -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"
Re: GEOM strange error
On 13.03.2018 17:39, Andriy Gapon wrote: > On 13/03/2018 11:37, Eugene Grosbein wrote: >> Hi! >> >> Let's create a stripe and GPT over it using test files as backing store: >> >> truncate -s 1G d0 >> truncate -s 1G d1 >> mdconfig -af d0 # gives md0 >> mdconfig -af d1 # gives md1 >> >> gpart create -s GPT md0 >> gpart create -s GPT md1 >> gpart destroy -F md1 >> gpart destroy -F md0 # no errors still >> >> gstripe label -s $((128*1024)) st0 md0 md1 >> gpart create -s GPT /dev/stripe/st0 >> dmesg -a >> >> GEOM_STRIPE: Device st0 created (id=4000112224). >> GEOM_STRIPE: Disk md0 attached to st0. >> GEOM_STRIPE: Disk md1 attached to st0. >> GEOM_STRIPE: Device stripe/st0 activated. >> GEOM: md0: corrupt or invalid GPT detected. >> GEOM: md0: GPT rejected -- may not be recoverable. >> >> Why does it emit such md0-related error? > > When GPT is placed on st0 it's opened for writing and, thus, md0 and md1 are > open for writing too. Afterwards, the write access count is cleared from > three > of them and that triggers re-tasting. I guess that g_part code tries to taste > md0 and md1 and sees the GPT label at the start of md0 and the label is > correctly rejected because it's inconsistent with md0's parameters. Shouldn't gstripe grab its components for exclusive access? So that GEOM does not even try to treat md[01] as targets for re-tasting. ___ 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: GEOM strange error
On 13/03/2018 13:52, Eugene Grosbein wrote: > On 13.03.2018 17:39, Andriy Gapon wrote: >> On 13/03/2018 11:37, Eugene Grosbein wrote: >>> Hi! >>> >>> Let's create a stripe and GPT over it using test files as backing store: >>> >>> truncate -s 1G d0 >>> truncate -s 1G d1 >>> mdconfig -af d0 # gives md0 >>> mdconfig -af d1 # gives md1 >>> >>> gpart create -s GPT md0 >>> gpart create -s GPT md1 >>> gpart destroy -F md1 >>> gpart destroy -F md0# no errors still >>> >>> gstripe label -s $((128*1024)) st0 md0 md1 >>> gpart create -s GPT /dev/stripe/st0 >>> dmesg -a >>> >>> GEOM_STRIPE: Device st0 created (id=4000112224). >>> GEOM_STRIPE: Disk md0 attached to st0. >>> GEOM_STRIPE: Disk md1 attached to st0. >>> GEOM_STRIPE: Device stripe/st0 activated. >>> GEOM: md0: corrupt or invalid GPT detected. >>> GEOM: md0: GPT rejected -- may not be recoverable. >>> >>> Why does it emit such md0-related error? >> >> When GPT is placed on st0 it's opened for writing and, thus, md0 and md1 are >> open for writing too. Afterwards, the write access count is cleared from >> three >> of them and that triggers re-tasting. I guess that g_part code tries to >> taste >> md0 and md1 and sees the GPT label at the start of md0 and the label is >> correctly rejected because it's inconsistent with md0's parameters. > > Shouldn't gstripe grab its components for exclusive access? > So that GEOM does not even try to treat md[01] as targets for re-tasting. I don't know what it should do, but I see that it doesn't do it in the "idle" state. However, when the stripe itself is opened / accessed, then it does add the exclusive bit to requested access counts. See g_stripe_access(). I think that what you expected makes more sense for me than what the code actually does. -- Andriy Gapon ___ 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 11.x fails to boot w/ SAS3 4Kn HDD and LSISAS3008 on SuperMicro X10DRH-iT
As it turns out, it seems EFI must be specified as the boot environment as opposed to legacy or BIOS+EFI. Setting the boot environment to EFI only resulted in successful system boot. Thanks for the replies. The answer came from Allan Jude on Twitter. On Mon, Mar 12, 2018 at 6:18 PM Rick Miller wrote: > 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&apropos=0&sektion=4&manpath=FreeBSD+11.1-RELEASE&arch=default&format=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 > -- 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"
FreeBSD 11.1,11-stable,12-current on Dell H740p raid
Hi, I got issue with Dell PowerEdge R740/R640 server with H740p and FreeBSD 11.1-Release, 11-stable, 12-current In all version I don't able to find the raid controler, so no disk...so of course impossible to install anything. I don't know if it's the right mailing-list, but if they are someone can help In other way, I can do « any » test for making thing work and help the freebsd team. Because Dell are still a large provider for hardware, and that would be very sad if FreeBSD cannot run on Dell. I still got some time (~ 1 month) before the server go in to production. For information Debian with Linux kernel prio to 4.14 don't work either. Currently only RedHat 7 work out of the box. Regards. -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France xmpp: j...@obspm.fr Heure local/Local time: Tue Mar 13 17:10:42 CET 2018 ___ 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"
annoying panic on boot
Stopped at vga_bitblt_one_text_pixels_block+0x13e: movl(%rax,%r13,4),%d db> bt Tracing pid 4 tid 100090 td 0xf8000c522620 vga_bitblt_one_text_pixels_block() at vga_bitblt_one_text_pixels_block+0x13e/fr0 vga_bitblt_text() at vga_bitblt_text+0xc0/frame 0xfe2d5160 vt_flush() at vt_flush+0x38f/frame 0xfe2d51b0 termcn_cnputc() at termcn_cnputc+0xbe/frame 0xfe2d51e0 cnputc() at cnputc+0x181/frame 0xfe2d5210 cnputs() at cnputs+0x78/frame 0xfe2d5230 putchar() at putchar+0x14d/frame 0xfe2d52b0 kvprintf() at kvprintf+0x113d/frame 0xfe2d53b0 vprintf() at vprintf+0x84/frame 0xfe2d5500 printf() at printf+0x43/frame 0xfe2d5560 cddone() at cddone+0x210/frame 0xfe2d5b20 xpt_done_process() at xpt_done_process+0x697/frame 0xfe2d5b60 xpt_done_td() at xpt_done_td+0x196/frame 0xfe2d5bb0 fork_exit() at fork_exit+0x82/frame 0xfe2d5bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe2d5bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 — the above happens on boot, sometimes, the host is a dell PowerEdge R710 running very resent stable, any help? thanks, danny ___ 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 11.1,11-stable,12-current on Dell H740p raid
On Tue, Mar 13, 2018 at 05:15:53PM +0100, Albert Shih wrote: > Hi, > > > I got issue with Dell PowerEdge R740/R640 server with H740p and FreeBSD > 11.1-Release, 11-stable, 12-current > > In all version I don't able to find the raid controler, so no disk...so of > course impossible to install anything. > > I don't know if it's the right mailing-list, but if they are someone can > help > > In other way, I can do ? any ? test for making thing work and help the > freebsd team. Because Dell are still a large provider for hardware, and that > would > be very sad if FreeBSD cannot run on Dell. > > I still got some time (~ 1 month) before the server go in to production. > > For information Debian with Linux kernel prio to 4.14 don't work either. > Currently only > RedHat 7 work out of the box. Download the driver from https://www.broadcom.com/products/storage/raid-controllers/megaraid-9460-8i#downloads and try that. Regards, Gary ___ 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"