Re: FreeBSD 11.1,11-stable,12-current on Dell H740p raid

[Gary Palmer]

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"

annoying panic on boot

[Daniel Braniss]

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"

FreeBSD 11.1,11-stable,12-current on Dell H740p raid

[Albert Shih]

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"

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

[Rick Miller]

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=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
>
-- 
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: GEOM strange error

[Andriy Gapon]

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: GEOM strange error

[Eugene Grosbein]

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

[Pete French]

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

[Andriy Gapon]

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"

GEOM strange error

[Eugene Grosbein]

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

[rainer]

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"

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

[Steven Hartland]

Have you tried setting dumpdev to AUTO in rc.conf to see if you can obtain
a panic dump? You could also try disabling reboot on it panic using the
sysctl

On Mon, 12 Mar 2018 at 22:18, 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=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-g...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-geom
> To unsubscribe, send any mail to "freebsd-geom-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"