Re: EFI booting from external USB pen drive

[Warner Losh]

On Thu, Jul 5, 2018 at 7:11 PM, Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On 5 Jul 2018, at 18:18, Rodney W. Grimes wrote:
> >
> > > [ Charset UTF-8 unsupported, converting... ]
> > >> On 5 Jul 2018, at 17:19, Warner Losh wrote:
> > >>
> > >>> FAT12 isn't good for UEFI. Use FAT16 or FAT32.
> > >>
> > >> We use it for the default image we built and the wiki suggests it as
> > >> well at https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI
> > >
> > > IIRC FreeBSD recently cnahged to FAT16 or 32 on these
> > > as the size got pushed up to be larger than what FAT12
> > > can access.
> >
> > https://svnweb.freebsd.org/base/head/stand/efi/boot1/
> generate-fat.sh?annotate=332561#l45
> >
> > nope.
>
> That is not the code we build release images with,
> that is Warners tests for the boot loader.
>

No, that's the actual code that generates boot1.efiffat.

Warner
___
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: atomic changes break drm-next-kmod?

[Pete Wright]

On 07/05/2018 12:12, Hans Petter Selasky wrote:

On 07/05/18 20:59, Hans Petter Selasky wrote:

On 07/05/18 19:48, Pete Wright wrote:



On 07/05/2018 10:10, John Baldwin wrote:

On 7/3/18 5:10 PM, Pete Wright wrote:


On 07/03/2018 15:56, John Baldwin wrote:

On 7/3/18 3:34 PM, Pete Wright wrote:

On 07/03/2018 15:29, John Baldwin wrote:

That seems like kgdb is looking at the wrong CPU.  Can you use
'info threads' and look for threads not stopped in 'sched_switch'
and get their backtraces?  You could also just do 'thread apply
all bt' and put that file at a URL if that is easiest.


sure thing John - here's a gist of "thread apply all bt"

https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed

That doesn't look right at all.  Are you sure the kernel matches the
vmcore?  Also, which kgdb version are you using?


yea i agree that doesn't look right at all.  here is my setup:

$ which kgdb
/usr/bin/kgdb
$ kgdb
GNU gdb 6.1.1 [FreeBSD]
$ ls -lh /var/crash/vmcore.1
-rw---  1 root  wheel   1.6G Jul  3 15:03 /var/crash/vmcore.1
$ ls -l /usr/lib/debug/boot/kernel/kernel.debug
-r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
/usr/lib/debug/boot/kernel/kernel.debug

and i invoke kgdb like so:
$ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug 
/var/crash/vmcore.1


here's a gist of my full gdb session:
http://termbin.com/krsn

dunno - maybe i have a bad core dump?  regardless, more than happy to
help so let me know if i should try anything else or patches etc..

Can you try installing gdb from ports and using /usr/local/bin/kgdb?



that seems to have done the trick, at least the output looks more 
encouraging.


  --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

__curthread () at ./machine/pcpu.h:231
231        __asm("movq %%gs:%1,%0" : "=r" (td)


here's my full kgdb session:
http://termbin.com/qa4f

i don't see any threads not in "sched_switch" though :(


Hi,

The problem may be that the patch to enable atomic inlining of all 
macros forgot to set the SMP keyword which means SMP is not defined 
at all for KLD's so all non-kernel atomic usage is with MPLOCKED empty!


/*
  * For userland, always use lock prefixes so that the binaries will run
  * on both SMP and !SMP systems.
  */
#if defined(SMP) || !defined(_KERNEL)
#define MPLOCKED    "lock ; "
#else
#define MPLOCKED
#endif

Can you try to recompile the LinuxKPI /sys/modules/linuxkpi with 
DEBUG_FLAGS="-DSMP" ?


and similarly the drm-next package?



Also please find attached a patch for amd64.



i have been running this patch for about 4hours.  previous uptime before 
this patch was under 1hr.  i've attached and detached HDMI displays and 
gone through several suspend/resume cycles as well without any issues.


to be clear - since i'm not sure this is was your intent - i applied the 
patch, rebuilt/installed a new kernel.  i did *not* use the "-DSMP" 
flags for linuxkpi or the drm-next module.


cheers,
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: EFI booting from external USB pen drive

[Rodney W. Grimes]

> On 5 Jul 2018, at 18:18, Rodney W. Grimes wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> >> On 5 Jul 2018, at 17:19, Warner Losh wrote:
> >>
> >>> FAT12 isn't good for UEFI. Use FAT16 or FAT32.
> >>
> >> We use it for the default image we built and the wiki suggests it as
> >> well at https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI
> >
> > IIRC FreeBSD recently cnahged to FAT16 or 32 on these
> > as the size got pushed up to be larger than what FAT12
> > can access.
> 
> https://svnweb.freebsd.org/base/head/stand/efi/boot1/generate-fat.sh?annotate=332561#l45
> 
> nope.

That is not the code we build release images with,
that is Warners tests for the boot loader.


-- 
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"

ci.freebsd.org's FreeBSD-head-i386-testvm fails for: pkg: No packages available to install matching 'scapy' have been found in the repositories

[Mark Millard]

https://ci.freebsd.org/job/FreeBSD-head-i386-testvm/6978/console shows:

22:34:39 All repositories are up to date.
22:34:39 + sudo chroot ufs pkg install -y kyua perl5 scapy ksh93 python
22:34:39 Updating FreeBSD repository catalogue...
22:34:39 FreeBSD repository is up to date.
22:34:39 All repositories are up to date.
22:34:39 Updating database digests format: . done
22:34:39 pkg: No packages available to install matching 'scapy' have been found 
in the repositories
22:34:39 Build step 'Execute shell' marked build as failure
22:34:39 FTP: Current build result is [FAILURE], not going to run.

There is a:

https://svnweb.freebsd.org/ports/head/net/scapy/



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: atomic changes break drm-next-kmod?

[Warner Losh]

On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin  wrote:

> On 7/5/18 12:36 PM, Konstantin Belousov wrote:
> > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
> >> On 07/05/18 20:59, Hans Petter Selasky wrote:
> >>> On 07/05/18 19:48, Pete Wright wrote:
> 
> 
>  On 07/05/2018 10:10, John Baldwin wrote:
> > On 7/3/18 5:10 PM, Pete Wright wrote:
> >>
> >> On 07/03/2018 15:56, John Baldwin wrote:
> >>> On 7/3/18 3:34 PM, Pete Wright wrote:
>  On 07/03/2018 15:29, John Baldwin wrote:
> > That seems like kgdb is looking at the wrong CPU.  Can you use
> > 'info threads' and look for threads not stopped in 'sched_switch'
> > and get their backtraces?  You could also just do 'thread apply
> > all bt' and put that file at a URL if that is easiest.
> >
>  sure thing John - here's a gist of "thread apply all bt"
> 
>  https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
> >>> That doesn't look right at all.  Are you sure the kernel matches
> the
> >>> vmcore?  Also, which kgdb version are you using?
> >>>
> >> yea i agree that doesn't look right at all.  here is my setup:
> >>
> >> $ which kgdb
> >> /usr/bin/kgdb
> >> $ kgdb
> >> GNU gdb 6.1.1 [FreeBSD]
> >> $ ls -lh /var/crash/vmcore.1
> >> -rw---  1 root  wheel   1.6G Jul  3 15:03 /var/crash/vmcore.1
> >> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
> >> -r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
> >> /usr/lib/debug/boot/kernel/kernel.debug
> >>
> >> and i invoke kgdb like so:
> >> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug
> /var/crash/vmcore.1
> >>
> >> here's a gist of my full gdb session:
> >> http://termbin.com/krsn
> >>
> >> dunno - maybe i have a bad core dump?  regardless, more than happy
> to
> >> help so let me know if i should try anything else or patches etc..
> > Can you try installing gdb from ports and using /usr/local/bin/kgdb?
> >
> 
>  that seems to have done the trick, at least the output looks more
>  encouraging.
> 
>    --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>  KDB: enter: panic
> 
>  __curthread () at ./machine/pcpu.h:231
>  231__asm("movq %%gs:%1,%0" : "=r" (td)
> 
> 
>  here's my full kgdb session:
>  http://termbin.com/qa4f
> 
>  i don't see any threads not in "sched_switch" though :(
> >>>
> >>> Hi,
> >>>
> >>> The problem may be that the patch to enable atomic inlining of all
> >>> macros forgot to set the SMP keyword which means SMP is not defined at
> >>> all for KLD's so all non-kernel atomic usage is with MPLOCKED empty!
> > Problem is that out-of-tree modules build does not have opt*.h files
> > from the kernel.  UP config is a valid one, flipping some option's
> > default value does not solve the problem.
>
> Yes, but using the lock prefix in a generic module is ok (it will still
> work, just not quite as fast) whereas the lack of lock is fatal on
> SMP.  I would amend Hans' patch slightly to honor the opt_* setting
> for KLD_TIED (but that is only true if KLD_TIED means "built as part of
> a kernel build, so has valid opt_foo.h headers" and not
> 'a standalone module where someone put MODULES_TIED=1 on the command line
> to make').
>

I agree with this default. It's sensible to default to (a) the most popular
thing and (b) thing that always works, especially when (a) and (b) are
identical.

Don't make me start the "Do we really need an SMP option, why not make it
always on" thread :) The number of relevant uniprocessor x86 boxes that
benefit from omitting SMP is so small as to be irrelevant, IMHO. A MP
kernel runs just fine on them...

Warner
___
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: EFI booting from external USB pen drive

[Warner Losh]

On Thu, Jul 5, 2018 at 3:31 PM, Bjoern A. Zeeb <
bzeeb-li...@lists.zabbadoz.net> wrote:

> On 5 Jul 2018, at 18:18, Rodney W. Grimes wrote:
>
> [ Charset UTF-8 unsupported, converting... ]
>>
>>> On 5 Jul 2018, at 17:19, Warner Losh wrote:
>>>
>>> FAT12 isn't good for UEFI. Use FAT16 or FAT32.

>>>
>>> We use it for the default image we built and the wiki suggests it as
>>> well at https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI
>>>
>>
>> IIRC FreeBSD recently cnahged to FAT16 or 32 on these
>> as the size got pushed up to be larger than what FAT12
>> can access.
>>
>
> https://svnweb.freebsd.org/base/head/stand/efi/boot1/generat
> e-fat.sh?annotate=332561#l45
>
> nope.
>

Yea, this should die a firey death in a fire, burned with flames, and the
ashes stirred into a paste that's tossed overboard into the ocean :)

But before that glorious day, I have a few last niggles to fix in
loader.efi.

Warner
___
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: EFI booting from external USB pen drive

[Bjoern A. Zeeb]

On 5 Jul 2018, at 18:18, Rodney W. Grimes wrote:


[ Charset UTF-8 unsupported, converting... ]

On 5 Jul 2018, at 17:19, Warner Losh wrote:


FAT12 isn't good for UEFI. Use FAT16 or FAT32.


We use it for the default image we built and the wiki suggests it as
well at https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI


IIRC FreeBSD recently cnahged to FAT16 or 32 on these
as the size got pushed up to be larger than what FAT12
can access.


https://svnweb.freebsd.org/base/head/stand/efi/boot1/generate-fat.sh?annotate=332561#l45

nope.
___
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: r336002 - in head: usr.bin/netstat usr.sbin/tcpdrop [ as-of -r336013: still broken: ci.freebsd.org FreeBSD-head-{mips,powerpc,powerpcspe}-build

[Mark Millard]

> Author: brooks
> Date: Thu Jul  5 17:02:10 2018
> New Revision: 336002
> URL: 
> https://svnweb.freebsd.org/changeset/base/336002
> 
> 
> Log:
>   Work around lame warnings in ancient gcc on 32-bit platforms.
>   
>   Fixes r335979.


[The below are the gcc 4.2.1 based 32-bit architectures.]

https://ci.freebsd.org/job/FreeBSD-head-mips-build/3192/consoleText shows
(as an example):

--- kern_descrip.o ---
cc1: warnings being treated as errors
/usr/src/sys/kern/kern_descrip.c: In function 'sysctl_kern_file':
/usr/src/sys/kern/kern_descrip.c:3365: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
/usr/src/sys/kern/kern_descrip.c:3366: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
/usr/src/sys/kern/kern_descrip.c:3367: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]

powerpc and powerpcspe agree.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: atomic changes break drm-next-kmod?

[John Baldwin]

On 7/5/18 12:36 PM, Konstantin Belousov wrote:
> On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
>> On 07/05/18 20:59, Hans Petter Selasky wrote:
>>> On 07/05/18 19:48, Pete Wright wrote:


 On 07/05/2018 10:10, John Baldwin wrote:
> On 7/3/18 5:10 PM, Pete Wright wrote:
>>
>> On 07/03/2018 15:56, John Baldwin wrote:
>>> On 7/3/18 3:34 PM, Pete Wright wrote:
 On 07/03/2018 15:29, John Baldwin wrote:
> That seems like kgdb is looking at the wrong CPU.  Can you use
> 'info threads' and look for threads not stopped in 'sched_switch'
> and get their backtraces?  You could also just do 'thread apply
> all bt' and put that file at a URL if that is easiest.
>
 sure thing John - here's a gist of "thread apply all bt"

 https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
>>> That doesn't look right at all.  Are you sure the kernel matches the
>>> vmcore?  Also, which kgdb version are you using?
>>>
>> yea i agree that doesn't look right at all.  here is my setup:
>>
>> $ which kgdb
>> /usr/bin/kgdb
>> $ kgdb
>> GNU gdb 6.1.1 [FreeBSD]
>> $ ls -lh /var/crash/vmcore.1
>> -rw---  1 root  wheel   1.6G Jul  3 15:03 /var/crash/vmcore.1
>> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
>> -r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
>> /usr/lib/debug/boot/kernel/kernel.debug
>>
>> and i invoke kgdb like so:
>> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1
>>
>> here's a gist of my full gdb session:
>> http://termbin.com/krsn
>>
>> dunno - maybe i have a bad core dump?  regardless, more than happy to
>> help so let me know if i should try anything else or patches etc..
> Can you try installing gdb from ports and using /usr/local/bin/kgdb?
>

 that seems to have done the trick, at least the output looks more 
 encouraging.

   --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
 KDB: enter: panic

 __curthread () at ./machine/pcpu.h:231
 231        __asm("movq %%gs:%1,%0" : "=r" (td)


 here's my full kgdb session:
 http://termbin.com/qa4f

 i don't see any threads not in "sched_switch" though :(
>>>
>>> Hi,
>>>
>>> The problem may be that the patch to enable atomic inlining of all 
>>> macros forgot to set the SMP keyword which means SMP is not defined at 
>>> all for KLD's so all non-kernel atomic usage is with MPLOCKED empty!
> Problem is that out-of-tree modules build does not have opt*.h files
> from the kernel.  UP config is a valid one, flipping some option's
> default value does not solve the problem.

Yes, but using the lock prefix in a generic module is ok (it will still
work, just not quite as fast) whereas the lack of lock is fatal on 
SMP.  I would amend Hans' patch slightly to honor the opt_* setting
for KLD_TIED (but that is only true if KLD_TIED means "built as part of
a kernel build, so has valid opt_foo.h headers" and not
'a standalone module where someone put MODULES_TIED=1 on the command line
to make').

-- 
John Baldwin
___
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: atomic changes break drm-next-kmod?

[Konstantin Belousov]

On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
> On 07/05/18 20:59, Hans Petter Selasky wrote:
> > On 07/05/18 19:48, Pete Wright wrote:
> >>
> >>
> >> On 07/05/2018 10:10, John Baldwin wrote:
> >>> On 7/3/18 5:10 PM, Pete Wright wrote:
> 
>  On 07/03/2018 15:56, John Baldwin wrote:
> > On 7/3/18 3:34 PM, Pete Wright wrote:
> >> On 07/03/2018 15:29, John Baldwin wrote:
> >>> That seems like kgdb is looking at the wrong CPU.  Can you use
> >>> 'info threads' and look for threads not stopped in 'sched_switch'
> >>> and get their backtraces?  You could also just do 'thread apply
> >>> all bt' and put that file at a URL if that is easiest.
> >>>
> >> sure thing John - here's a gist of "thread apply all bt"
> >>
> >> https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
> > That doesn't look right at all.  Are you sure the kernel matches the
> > vmcore?  Also, which kgdb version are you using?
> >
>  yea i agree that doesn't look right at all.  here is my setup:
> 
>  $ which kgdb
>  /usr/bin/kgdb
>  $ kgdb
>  GNU gdb 6.1.1 [FreeBSD]
>  $ ls -lh /var/crash/vmcore.1
>  -rw---  1 root  wheel   1.6G Jul  3 15:03 /var/crash/vmcore.1
>  $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
>  -r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
>  /usr/lib/debug/boot/kernel/kernel.debug
> 
>  and i invoke kgdb like so:
>  $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1
> 
>  here's a gist of my full gdb session:
>  http://termbin.com/krsn
> 
>  dunno - maybe i have a bad core dump?  regardless, more than happy to
>  help so let me know if i should try anything else or patches etc..
> >>> Can you try installing gdb from ports and using /usr/local/bin/kgdb?
> >>>
> >>
> >> that seems to have done the trick, at least the output looks more 
> >> encouraging.
> >>
> >>   --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> >> KDB: enter: panic
> >>
> >> __curthread () at ./machine/pcpu.h:231
> >> 231        __asm("movq %%gs:%1,%0" : "=r" (td)
> >>
> >>
> >> here's my full kgdb session:
> >> http://termbin.com/qa4f
> >>
> >> i don't see any threads not in "sched_switch" though :(
> > 
> > Hi,
> > 
> > The problem may be that the patch to enable atomic inlining of all 
> > macros forgot to set the SMP keyword which means SMP is not defined at 
> > all for KLD's so all non-kernel atomic usage is with MPLOCKED empty!
Problem is that out-of-tree modules build does not have opt*.h files
from the kernel.  UP config is a valid one, flipping some option's
default value does not solve the problem.

The build invocation for such modules needs to provide KERNBUILDDIR
variable pointing to the kernel build directory, where all opt*.h files
are located.

> > 
> > /*
> >   * For userland, always use lock prefixes so that the binaries will run
> >   * on both SMP and !SMP systems.
> >   */
> > #if defined(SMP) || !defined(_KERNEL)
> > #define MPLOCKED    "lock ; "
> > #else
> > #define MPLOCKED
> > #endif
> > 
> > Can you try to recompile the LinuxKPI /sys/modules/linuxkpi with 
> > DEBUG_FLAGS="-DSMP" ?
> > 
> > and similarly the drm-next package?
> > 
> 
> Also please find attached a patch for amd64.
> 
> --HPS
> 

> Index: sys/amd64/include/atomic.h
> ===
> --- sys/amd64/include/atomic.h(revision 335974)
> +++ sys/amd64/include/atomic.h(working copy)
> @@ -132,7 +132,7 @@
>   * For userland, always use lock prefixes so that the binaries will run
>   * on both SMP and !SMP systems.
>   */
> -#if defined(SMP) || !defined(_KERNEL)
> +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
>  #define  MPLOCKED"lock ; "
>  #else
>  #define  MPLOCKED
> @@ -354,7 +354,7 @@
>   */
>  #define  OFFSETOF_MONITORBUF 0x100
>  
> -#if defined(SMP)
> +#if defined(SMP) || defined(KLD_MODULE)
>  static __inline void
>  __storeload_barrier(void)
>  {

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

___
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: atomic changes break drm-next-kmod?

[Hans Petter Selasky]

On 07/05/18 20:59, Hans Petter Selasky wrote:

On 07/05/18 19:48, Pete Wright wrote:



On 07/05/2018 10:10, John Baldwin wrote:

On 7/3/18 5:10 PM, Pete Wright wrote:


On 07/03/2018 15:56, John Baldwin wrote:

On 7/3/18 3:34 PM, Pete Wright wrote:

On 07/03/2018 15:29, John Baldwin wrote:

That seems like kgdb is looking at the wrong CPU.  Can you use
'info threads' and look for threads not stopped in 'sched_switch'
and get their backtraces?  You could also just do 'thread apply
all bt' and put that file at a URL if that is easiest.


sure thing John - here's a gist of "thread apply all bt"

https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed

That doesn't look right at all.  Are you sure the kernel matches the
vmcore?  Also, which kgdb version are you using?


yea i agree that doesn't look right at all.  here is my setup:

$ which kgdb
/usr/bin/kgdb
$ kgdb
GNU gdb 6.1.1 [FreeBSD]
$ ls -lh /var/crash/vmcore.1
-rw---  1 root  wheel   1.6G Jul  3 15:03 /var/crash/vmcore.1
$ ls -l /usr/lib/debug/boot/kernel/kernel.debug
-r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
/usr/lib/debug/boot/kernel/kernel.debug

and i invoke kgdb like so:
$ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1

here's a gist of my full gdb session:
http://termbin.com/krsn

dunno - maybe i have a bad core dump?  regardless, more than happy to
help so let me know if i should try anything else or patches etc..

Can you try installing gdb from ports and using /usr/local/bin/kgdb?



that seems to have done the trick, at least the output looks more 
encouraging.


  --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

__curthread () at ./machine/pcpu.h:231
231        __asm("movq %%gs:%1,%0" : "=r" (td)


here's my full kgdb session:
http://termbin.com/qa4f

i don't see any threads not in "sched_switch" though :(


Hi,

The problem may be that the patch to enable atomic inlining of all 
macros forgot to set the SMP keyword which means SMP is not defined at 
all for KLD's so all non-kernel atomic usage is with MPLOCKED empty!


/*
  * For userland, always use lock prefixes so that the binaries will run
  * on both SMP and !SMP systems.
  */
#if defined(SMP) || !defined(_KERNEL)
#define MPLOCKED    "lock ; "
#else
#define MPLOCKED
#endif

Can you try to recompile the LinuxKPI /sys/modules/linuxkpi with 
DEBUG_FLAGS="-DSMP" ?


and similarly the drm-next package?



Also please find attached a patch for amd64.

--HPS

Index: sys/amd64/include/atomic.h
===
--- sys/amd64/include/atomic.h	(revision 335974)
+++ sys/amd64/include/atomic.h	(working copy)
@@ -132,7 +132,7 @@
  * For userland, always use lock prefixes so that the binaries will run
  * on both SMP and !SMP systems.
  */
-#if defined(SMP) || !defined(_KERNEL)
+#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
 #define	MPLOCKED	"lock ; "
 #else
 #define	MPLOCKED
@@ -354,7 +354,7 @@
  */
 #define	OFFSETOF_MONITORBUF	0x100
 
-#if defined(SMP)
+#if defined(SMP) || defined(KLD_MODULE)
 static __inline void
 __storeload_barrier(void)
 {
___
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: r336012 - in head: . usr.sbin/config [ broken for ci.freebsd.org's FreeBSD-head-{sparc64,powerpcspe,powerpc,i386,armv7}-build

[Mark Millard]

Examples:

https://ci.freebsd.org/job/FreeBSD-head-armv7-build/568/console shows:

18:54:11 
--- _bootstrap-tools-usr.sbin/config ---

18:54:11 
mkmakefile.o: In function `dump_nvlist':

18:54:11 
/usr/src/usr.sbin/config/mkmakefile.c:287: undefined reference to 
`cnvlist_get_string'

18:54:11 
/usr/src/usr.sbin/config/mkmakefile.c:289: undefined reference to 
`cnvlist_free_string'

18:54:11 
cc: error: linker command failed with exit code 1 (use -v to see invocation)

18:54:11 
*** [config.full] Error code 1

(i386 agrees.)


As for gcc 4.2.1 (32-bit and 64-bit targets), an example:

https://ci.freebsd.org/job/FreeBSD-head-powerpcspe-build/ shows:

--
>>> stage 1: configuring the kernel
--
cd /usr/src/sys/powerpc/conf;  
PATH=/usr/obj/usr/src/powerpc.powerpcspe/tmp/legacy/usr/sbin:/usr/obj/usr/src/powerpc.powerpcspe/tmp/legacy/usr/bin:/usr/obj/usr/src/powerpc.powerpcspe/tmp/legacy/bin:/usr/obj/usr/src/powerpc.powerpcspe/tmp/usr/sbin:/usr/obj/usr/src/powerpc.powerpcspe/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
  config  -d /usr/obj/usr/src/powerpc.powerpcspe/sys/MPC85XXSPE  -I 
'/usr/src/sys/powerpc/conf' '/usr/src/sys/powerpc/conf/MPC85XXSPE'
config: /usr/src/sys/powerpc/conf/MPC85XXSPE: No error: 0
*** [buildkernel] Error code 2



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: atomic changes break drm-next-kmod?

[Hans Petter Selasky]

On 07/05/18 19:48, Pete Wright wrote:



On 07/05/2018 10:10, John Baldwin wrote:

On 7/3/18 5:10 PM, Pete Wright wrote:


On 07/03/2018 15:56, John Baldwin wrote:

On 7/3/18 3:34 PM, Pete Wright wrote:

On 07/03/2018 15:29, John Baldwin wrote:

That seems like kgdb is looking at the wrong CPU.  Can you use
'info threads' and look for threads not stopped in 'sched_switch'
and get their backtraces?  You could also just do 'thread apply
all bt' and put that file at a URL if that is easiest.


sure thing John - here's a gist of "thread apply all bt"

https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed

That doesn't look right at all.  Are you sure the kernel matches the
vmcore?  Also, which kgdb version are you using?


yea i agree that doesn't look right at all.  here is my setup:

$ which kgdb
/usr/bin/kgdb
$ kgdb
GNU gdb 6.1.1 [FreeBSD]
$ ls -lh /var/crash/vmcore.1
-rw---  1 root  wheel   1.6G Jul  3 15:03 /var/crash/vmcore.1
$ ls -l /usr/lib/debug/boot/kernel/kernel.debug
-r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
/usr/lib/debug/boot/kernel/kernel.debug

and i invoke kgdb like so:
$ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1

here's a gist of my full gdb session:
http://termbin.com/krsn

dunno - maybe i have a bad core dump?  regardless, more than happy to
help so let me know if i should try anything else or patches etc..

Can you try installing gdb from ports and using /usr/local/bin/kgdb?



that seems to have done the trick, at least the output looks more 
encouraging.


  --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

__curthread () at ./machine/pcpu.h:231
231        __asm("movq %%gs:%1,%0" : "=r" (td)


here's my full kgdb session:
http://termbin.com/qa4f

i don't see any threads not in "sched_switch" though :(


Hi,

The problem may be that the patch to enable atomic inlining of all 
macros forgot to set the SMP keyword which means SMP is not defined at 
all for KLD's so all non-kernel atomic usage is with MPLOCKED empty!


/*
 * For userland, always use lock prefixes so that the binaries will run
 * on both SMP and !SMP systems.
 */
#if defined(SMP) || !defined(_KERNEL)
#define MPLOCKED"lock ; "
#else
#define MPLOCKED
#endif

Can you try to recompile the LinuxKPI /sys/modules/linuxkpi with 
DEBUG_FLAGS="-DSMP" ?


and similarly the drm-next package?

--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: Unable to UEFI boot 11.2 ISO (latest 12.0 as well)

[Warner Losh]

I think I know what is going on... I may have some changes that fixes this.

Warner

On Thu, Jul 5, 2018, 9:12 AM Linus Sundqvist 
wrote:

> I have no idea how to do that or where to begin, but if anyone would like
> to assist with those steps I'll gladly run commands or a test ISO on one of
> our Dell servers.
>
> Med vänlig hälsning/Best Regards
> Linus Sundqvist
> System Engineer, Loopia AB
>
> On 05/07/18 10:23, Toomas Soome wrote:
> >
> >
> >> On 5 Jul 2018, at 10:28, Linus Sundqvist 
> wrote:
> >>
> >> Here's the output, variable 'currdev' not found:
> >> https://imgur.com/LlBygfr 
> >
> >
> > Yes indeed, as you got the error, so the variable was not set at all. My
> suggestion would be to walk over the code in main.c, and to try to get more
> debug printouts from that dell system… Im myself mostly offline till next
> week.
> >
> > rgds,
> > toomas
> >
> >>
> >> And to answer Rodneys question from before, this is the emulated CD
> drive from a Dell iDRAC (remote console thingy).
> >>
> >> Med vänlig hälsning/Best Regards
> >> Linus Sundqvist
> >> System Engineer, Loopia AB
> >>
> >> On 05/07/18 09:17, Toomas Soome wrote:
> >>> Could you check, show currdev from OK prompt before setting it.
> >>>
> >>> Somehow the boot device path is shown but we fail to recognize it (as
> seen by error message). However, the lsdev -v does show the path, so the
> efipart.c seems to do its work correctly. I feel, there should be some
> corner case in efi/loader/main.c where we detect the boot device.
> >>>
> >>> Rgds,
> >>> Toomas
> >>>
> >>> Sent from my iPhone
> >>>
>  On 5 Jul 2018, at 09:32, Linus Sundqvist 
> wrote:
> 
>  Running these commands makes the boot menu show up, and then takes me
> to the BSD installer!
> 
>  Med vänlig hälsning/Best Regards
>  Linus Sundqvist
>  System Engineer, Loopia AB
> 
> > On 04/07/18 16:50, Toomas Soome wrote:
> > set currdev=cd1:
> > include /boot/loader.rc
> >
> > This should give menu/boot.
> >
> > Rgds,
> > Toomas
> >
> > Sent from my iPhone
> >
> >> On 4 Jul 2018, at 16:25, Linus Sundqvist 
> wrote:
> >>
> >> Hi,
> >>
> >> Sure, while using the 12.0 ISO here is lsdev -v and ls cd0:
> >> https://imgur.com/RmYpg7u
> >>
> >> and here is ls cd1:
> >> https://imgur.com/FPsixOw
> >>
> >> Med vänlig hälsning/Best Regards
> >> Linus Sundqvist
> >> System Engineer, Loopia AB
> >>
> >>> On 04/07/18 15:08, Toomas Soome wrote:
> >>> Can you post lsdev -v output?
> >>>
> >>> Also, could you try ls command? Like, ls cd0:
> >>>
> >>> Rgds,
> >>> Toomas
> >>>
> >>> Sent from my iPhone
> >>>
>  On 4 Jul 2018, at 12:28, Linus Sundqvist <
> linus.sundqv...@loopia.se> wrote:
> 
>  Hi,
> 
>  I'm unable to boot up the amd64 11.2 disk1 ISO as well as the
> latest amd64 12.0 disk1 ISO (20180628) using UEFI on a Dell PowerEdge R430
> by getting this error:
>  https://imgur.com/a/Idljfhm
> 
>  The bootonly ISOs seems to show the same error message.
> 
>  Changing the server to boot via BIOS loads the setup correctly,
> however, I want to use UEFI on all our servers, which I have done before.
> 
>  The 11.1 ISO boots without any trouble at all using both UEFI and
> BIOS.
> 
>  I was helped by koobs in #freebsd @ Freenode who asked me to send
> an e-mail this way and linking to these commits as a reference:
> 
>  https://reviews.freebsd.org/D13784
>  https://svnweb.freebsd.org/base?view=revision=332416
> 
>  So far I've tried to UEFI boot the 11.2 ISO and 12.0 ISO with the
> following Dell PowerEdge models without success:
> 
>  R440
>  R630
>  R430
>  FC430
>  R330
>  R620
>  R420
>  R610
> 
>  --
>  Med vänlig hälsning/Best Regards
>  Linus Sundqvist
>  System Engineer, Loopia AB
> 
> >>> ___
> >>> 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"
> >>>
> >>
> > ___
> > 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"
> >
> 
> >>> ___
> >>> 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: EFI booting from external USB pen drive

[Warner Losh]

On Thu, Jul 5, 2018, 12:55 PM Bjoern A. Zeeb 
wrote:

> On 5 Jul 2018, at 17:19, Warner Losh wrote:
>
> > FAT12 isn't good for UEFI. Use FAT16 or FAT32.
>
> We use it for the default image we built and the wiki suggests it as
> well at https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI
>
> I wonder where this “default” came from?
>

The original UEFI port... they didn't check the standard's recommendations.
It worked then, but experience has shown FAT12 doesn't work everywhere.

Warner

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

SVN r336011 breaks build

[Michael Butler]

As below:

Building /usr/obj/usr/src/amd64.amd64/usr.sbin/config/config.c
Building /usr/obj/usr/src/amd64.amd64/usr.sbin/config/lang.c
Building /usr/obj/usr/src/amd64.amd64/usr.sbin/config/kernconf.c
Building /usr/obj/usr/src/amd64.amd64/usr.sbin/config/config.o
Building /usr/obj/usr/src/amd64.amd64/usr.sbin/config/main.o
Building /usr/obj/usr/src/amd64.amd64/usr.sbin/config/lang.o
Building /usr/obj/usr/src/amd64.amd64/usr.sbin/config/mkmakefile.o
/usr/src/usr.sbin/config/mkmakefile.c:289:28: error: too many arguments
to function call, expected single argument 'cookie', have 2 arguments
cnvlist_free_string(nvl, cookie);
~~~  ^~
/usr/include/sys/cnv.h:106:1: note: 'cnvlist_free_string' declared here
voidcnvlist_free_string(void *cookie);
^
1 error generated.
*** Error code 1

Stop.
make: stopped in /usr/src/usr.sbin/config

imb
___
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: EFI booting from external USB pen drive

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On 5 Jul 2018, at 17:19, Warner Losh wrote:
> 
> > FAT12 isn't good for UEFI. Use FAT16 or FAT32.
> 
> We use it for the default image we built and the wiki suggests it as 
> well at https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI

IIRC FreeBSD recently cnahged to FAT16 or 32 on these
as the size got pushed up to be larger than what FAT12
can access.

> I wonder where this ?default? came from?
> 
> /bz

-- 
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: EFI booting from external USB pen drive

[Bjoern A. Zeeb]

On 5 Jul 2018, at 17:19, Warner Losh wrote:


FAT12 isn't good for UEFI. Use FAT16 or FAT32.


We use it for the default image we built and the wiki suggests it as 
well at https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI


I wonder where this “default” came from?

/bz


___
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: atomic changes break drm-next-kmod?

[Pete Wright]

On 07/05/2018 10:10, John Baldwin wrote:

On 7/3/18 5:10 PM, Pete Wright wrote:


On 07/03/2018 15:56, John Baldwin wrote:

On 7/3/18 3:34 PM, Pete Wright wrote:

On 07/03/2018 15:29, John Baldwin wrote:

That seems like kgdb is looking at the wrong CPU.  Can you use
'info threads' and look for threads not stopped in 'sched_switch'
and get their backtraces?  You could also just do 'thread apply
all bt' and put that file at a URL if that is easiest.


sure thing John - here's a gist of "thread apply all bt"

https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed

That doesn't look right at all.  Are you sure the kernel matches the
vmcore?  Also, which kgdb version are you using?


yea i agree that doesn't look right at all.  here is my setup:

$ which kgdb
/usr/bin/kgdb
$ kgdb
GNU gdb 6.1.1 [FreeBSD]
$ ls -lh /var/crash/vmcore.1
-rw---  1 root  wheel   1.6G Jul  3 15:03 /var/crash/vmcore.1
$ ls -l /usr/lib/debug/boot/kernel/kernel.debug
-r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
/usr/lib/debug/boot/kernel/kernel.debug

and i invoke kgdb like so:
$ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1

here's a gist of my full gdb session:
http://termbin.com/krsn

dunno - maybe i have a bad core dump?  regardless, more than happy to
help so let me know if i should try anything else or patches etc..

Can you try installing gdb from ports and using /usr/local/bin/kgdb?



that seems to have done the trick, at least the output looks more 
encouraging.


 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

__curthread () at ./machine/pcpu.h:231
231        __asm("movq %%gs:%1,%0" : "=r" (td)


here's my full kgdb session:
http://termbin.com/qa4f

i don't see any threads not in "sched_switch" though :(

-pete


--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: Unable to UEFI boot 11.2 ISO (latest 12.0 as well)

[Rodney W. Grimes]

> Here's the output, variable 'currdev' not found:
> https://imgur.com/LlBygfr

Hum, currdev didnt get set, but I see the loaddevice looks to be
cd1:  Toomas is right, we have an edge case here that is failing
to set currdev properly.

> 
> And to answer Rodneys question from before, this is the emulated CD drive 
> from a Dell iDRAC (remote console thingy).

Thanks, that helps.  I'll try to duplicate this failure mode since I have Dells,
IIRC this virtual emulated CD drive shows up as a USB device.

> Med v?nlig h?lsning/Best Regards
> Linus Sundqvist
> System Engineer, Loopia AB
> 
> On 05/07/18 09:17, Toomas Soome wrote:
> > Could you check, show currdev from OK prompt before setting it.
> > 
> > Somehow the boot device path is shown but we fail to recognize it (as seen 
> > by error message). However, the lsdev -v does show the path, so the 
> > efipart.c seems to do its work correctly. I feel, there should be some 
> > corner case in efi/loader/main.c where we detect the boot device.
> > 
> > Rgds,
> > Toomas
> > 
> > Sent from my iPhone
> > 
> >> On 5 Jul 2018, at 09:32, Linus Sundqvist  wrote:
> >>
> >> Running these commands makes the boot menu show up, and then takes me to 
> >> the BSD installer!

Good, so there is a work around


> >> Med v?nlig h?lsning/Best Regards
> >> Linus Sundqvist
> >> System Engineer, Loopia AB
> >>
> >>> On 04/07/18 16:50, Toomas Soome wrote:
> >>> set currdev=cd1:
> >>> include /boot/loader.rc
> >>>
> >>> This should give menu/boot.
> >>>
> >>> Rgds,
> >>> Toomas
> >>>
> >>> Sent from my iPhone
> >>>
>  On 4 Jul 2018, at 16:25, Linus Sundqvist  
>  wrote:
> 
>  Hi,
> 
>  Sure, while using the 12.0 ISO here is lsdev -v and ls cd0:
>  https://imgur.com/RmYpg7u
> 
>  and here is ls cd1:
>  https://imgur.com/FPsixOw
> 
>  Med v?nlig h?lsning/Best Regards
>  Linus Sundqvist
>  System Engineer, Loopia AB
> 
> > On 04/07/18 15:08, Toomas Soome wrote:
> > Can you post lsdev -v output?
> >
> > Also, could you try ls command? Like, ls cd0:   
> >
> > Rgds,
> > Toomas
> >
> > Sent from my iPhone
> >
> >> On 4 Jul 2018, at 12:28, Linus Sundqvist  
> >> wrote:
> >>
> >> Hi,
> >>
> >> I'm unable to boot up the amd64 11.2 disk1 ISO as well as the latest 
> >> amd64 12.0 disk1 ISO (20180628) using UEFI on a Dell PowerEdge R430 by 
> >> getting this error:
> >> https://imgur.com/a/Idljfhm
> >>
> >> The bootonly ISOs seems to show the same error message.
> >>
> >> Changing the server to boot via BIOS loads the setup correctly, 
> >> however, I want to use UEFI on all our servers, which I have done 
> >> before.
> >>
> >> The 11.1 ISO boots without any trouble at all using both UEFI and BIOS.
> >>
> >> I was helped by koobs in #freebsd @ Freenode who asked me to send an 
> >> e-mail this way and linking to these commits as a reference:
> >>
> >> https://reviews.freebsd.org/D13784
> >> https://svnweb.freebsd.org/base?view=revision=332416
> >>
> >> So far I've tried to UEFI boot the 11.2 ISO and 12.0 ISO with the 
> >> following Dell PowerEdge models without success:
> >>
> >> R440
> >> R630
> >> R430
> >> FC430
> >> R330
> >> R620
> >> R420
> >> R610
> >>
> >> -- 
> >> Med v?nlig h?lsning/Best Regards
> >> Linus Sundqvist
> >> System Engineer, Loopia AB
> >>
> > ___
> > 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"
> >
> 
> >>> ___
> >>> 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"
> >>>
> >>
> > ___
> > 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"
> > 
> 
-- End of PGP section, PGP failed!

-- 
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: EFI booting from external USB pen drive

[Warner Losh]

FAT12 isn't good for UEFI. Use FAT16 or FAT32.

Warner

On Thu, Jul 5, 2018, 9:32 AM Bjoern A. Zeeb 
wrote:

> Hi,
>
> while I can boot memstick images just fine (which are created using
> makefs/mkimg), doing the same thing using gpart/newfs_msdos -F 12/.. I
> am not able to get anything that boots.
>
> On a Thinkpad (secure boot is off) from the “boot device chooser from
> ‘BIOS’” I get a quick blank screen and am back at the chooser.
> I’ve tried the gpart “thinkpad hack” as well as trying an MBR (why
> that should work I don’t know but the memstick one does) and GPT
> options of various kinds.
>
>
> Anyone successfully done this lately?
>
>
> /bz
> ___
> 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"
>
___
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: atomic changes break drm-next-kmod?

[John Baldwin]

On 7/3/18 5:10 PM, Pete Wright wrote:
> 
> 
> On 07/03/2018 15:56, John Baldwin wrote:
>> On 7/3/18 3:34 PM, Pete Wright wrote:
>>>
>>> On 07/03/2018 15:29, John Baldwin wrote:
 That seems like kgdb is looking at the wrong CPU.  Can you use
 'info threads' and look for threads not stopped in 'sched_switch'
 and get their backtraces?  You could also just do 'thread apply
 all bt' and put that file at a URL if that is easiest.

>>>
>>> sure thing John - here's a gist of "thread apply all bt"
>>>
>>> https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
>> That doesn't look right at all.  Are you sure the kernel matches the
>> vmcore?  Also, which kgdb version are you using?
>>
> 
> yea i agree that doesn't look right at all.  here is my setup:
> 
> $ which kgdb
> /usr/bin/kgdb
> $ kgdb
> GNU gdb 6.1.1 [FreeBSD]
> $ ls -lh /var/crash/vmcore.1
> -rw---  1 root  wheel   1.6G Jul  3 15:03 /var/crash/vmcore.1
> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
> -r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54 
> /usr/lib/debug/boot/kernel/kernel.debug
> 
> and i invoke kgdb like so:
> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1
> 
> here's a gist of my full gdb session:
> http://termbin.com/krsn
> 
> dunno - maybe i have a bad core dump?  regardless, more than happy to 
> help so let me know if i should try anything else or patches etc..

Can you try installing gdb from ports and using /usr/local/bin/kgdb?

-- 
John Baldwin
___
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: EFI booting from external USB pen drive

[David Mimms]

Bjoern,

I had this problem earlier this week while using 
FreeBSD-12.0-CURRENT-amd64-20180628-r335760-memstick.img on my ThinkPad P50.

I had used `dd` to place the img file on a partition (e.g. /dev/sdb1) of the 
USB pen drive and it wouldn't boot properly.

After I used `dd` to place the img on the entire device (e.g. /dev/sdb), I 
noticed that it had its own partition scheme with three partitions, and that 
booted just fine.

DM


On Thursday, July 5, 2018 10:30:51 AM -04 Bjoern A. Zeeb wrote:
> Hi,
> 
> while I can boot memstick images just fine (which are created using 
> makefs/mkimg), doing the same thing using gpart/newfs_msdos -F 12/.. I 
> am not able to get anything that boots.
> 
> On a Thinkpad (secure boot is off) from the “boot device chooser from 
> ‘BIOS’” I get a quick blank screen and am back at the chooser.  
> I’ve tried the gpart “thinkpad hack” as well as trying an MBR (why 
> that should work I don’t know but the memstick one does) and GPT 
> options of various kinds.
> 
> 
> Anyone successfully done this lately?
> 
> 
> /bz
> ___
> 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"
> 




___
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: EFI booting from external USB pen drive

[Emmanuel Vadot]

On 2018-07-05 16:30, Bjoern A. Zeeb wrote:

Hi,

while I can boot memstick images just fine (which are created using
makefs/mkimg), doing the same thing using gpart/newfs_msdos -F 12/.. I
am not able to get anything that boots.


 What is the size for the fat12 partition ? Everything over ~30MB will 
fail.

 Go to fat16/fat32 with a size of 150MB just to be sure.


On a Thinkpad (secure boot is off) from the “boot device chooser from
‘BIOS’” I get a quick blank screen and am back at the chooser.  I’ve
tried the gpart “thinkpad hack” as well as trying an MBR (why that
should work I don’t know but the memstick one does) and GPT options of
various kinds.


Anyone successfully done this lately?


/bz
___
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"


--
Emmanuel Vadot  
___
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"

EFI booting from external USB pen drive

[Bjoern A. Zeeb]

Hi,

while I can boot memstick images just fine (which are created using 
makefs/mkimg), doing the same thing using gpart/newfs_msdos -F 12/.. I 
am not able to get anything that boots.


On a Thinkpad (secure boot is off) from the “boot device chooser from 
‘BIOS’” I get a quick blank screen and am back at the chooser.  
I’ve tried the gpart “thinkpad hack” as well as trying an MBR (why 
that should work I don’t know but the memstick one does) and GPT 
options of various kinds.



Anyone successfully done this lately?


/bz
___
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: Unable to UEFI boot 11.2 ISO (latest 12.0 as well)

[Linus Sundqvist]

I have no idea how to do that or where to begin, but if anyone would like to 
assist with those steps I'll gladly run commands or a test ISO on one of our 
Dell servers.

Med vänlig hälsning/Best Regards
Linus Sundqvist
System Engineer, Loopia AB

On 05/07/18 10:23, Toomas Soome wrote:
> 
> 
>> On 5 Jul 2018, at 10:28, Linus Sundqvist  wrote:
>>
>> Here's the output, variable 'currdev' not found:
>> https://imgur.com/LlBygfr 
> 
> 
> Yes indeed, as you got the error, so the variable was not set at all. My 
> suggestion would be to walk over the code in main.c, and to try to get more 
> debug printouts from that dell system… Im myself mostly offline till next 
> week.
> 
> rgds,
> toomas
> 
>>
>> And to answer Rodneys question from before, this is the emulated CD drive 
>> from a Dell iDRAC (remote console thingy).
>>
>> Med vänlig hälsning/Best Regards
>> Linus Sundqvist
>> System Engineer, Loopia AB
>>
>> On 05/07/18 09:17, Toomas Soome wrote:
>>> Could you check, show currdev from OK prompt before setting it.
>>>
>>> Somehow the boot device path is shown but we fail to recognize it (as seen 
>>> by error message). However, the lsdev -v does show the path, so the 
>>> efipart.c seems to do its work correctly. I feel, there should be some 
>>> corner case in efi/loader/main.c where we detect the boot device.
>>>
>>> Rgds,
>>> Toomas
>>>
>>> Sent from my iPhone
>>>
 On 5 Jul 2018, at 09:32, Linus Sundqvist  wrote:

 Running these commands makes the boot menu show up, and then takes me to 
 the BSD installer!

 Med vänlig hälsning/Best Regards
 Linus Sundqvist
 System Engineer, Loopia AB

> On 04/07/18 16:50, Toomas Soome wrote:
> set currdev=cd1:
> include /boot/loader.rc
>
> This should give menu/boot.
>
> Rgds,
> Toomas
>
> Sent from my iPhone
>
>> On 4 Jul 2018, at 16:25, Linus Sundqvist  
>> wrote:
>>
>> Hi,
>>
>> Sure, while using the 12.0 ISO here is lsdev -v and ls cd0:
>> https://imgur.com/RmYpg7u
>>
>> and here is ls cd1:
>> https://imgur.com/FPsixOw
>>
>> Med vänlig hälsning/Best Regards
>> Linus Sundqvist
>> System Engineer, Loopia AB
>>
>>> On 04/07/18 15:08, Toomas Soome wrote:
>>> Can you post lsdev -v output?
>>>
>>> Also, could you try ls command? Like, ls cd0:   
>>>
>>> Rgds,
>>> Toomas
>>>
>>> Sent from my iPhone
>>>
 On 4 Jul 2018, at 12:28, Linus Sundqvist  
 wrote:

 Hi,

 I'm unable to boot up the amd64 11.2 disk1 ISO as well as the latest 
 amd64 12.0 disk1 ISO (20180628) using UEFI on a Dell PowerEdge R430 by 
 getting this error:
 https://imgur.com/a/Idljfhm

 The bootonly ISOs seems to show the same error message.

 Changing the server to boot via BIOS loads the setup correctly, 
 however, I want to use UEFI on all our servers, which I have done 
 before.

 The 11.1 ISO boots without any trouble at all using both UEFI and BIOS.

 I was helped by koobs in #freebsd @ Freenode who asked me to send an 
 e-mail this way and linking to these commits as a reference:

 https://reviews.freebsd.org/D13784
 https://svnweb.freebsd.org/base?view=revision=332416

 So far I've tried to UEFI boot the 11.2 ISO and 12.0 ISO with the 
 following Dell PowerEdge models without success:

 R440
 R630
 R430
 FC430
 R330
 R620
 R420
 R610

 -- 
 Med vänlig hälsning/Best Regards
 Linus Sundqvist
 System Engineer, Loopia AB

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

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



signature.asc
Description: OpenPGP digital signature

Re: em0 link fail

[Michael Butler]

On 07/05/18 09:27, tech-lists wrote:
> On 03/07/2018 19:47, Michael Butler wrote:
>> That would've been ..
>>
>> Jun  1 09:56:15 toshi kernel: FreeBSD 12.0-CURRENT #35 r334484: Fri Jun
>> 1 08:25:58 EDT 2018
>>
>> I'm going to build one with SVN r334862 reverted to see if that works,
> 
> Hi,
> 
> Is it working now? Am asking because a system I'd like to take from
> 11-stable to 12 uses the em driver.

No :-( I haven't had the chance yet to revisit it,

imb

___
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: em0 link fail

[tech-lists]

On 03/07/2018 19:47, Michael Butler wrote:

That would've been ..

Jun  1 09:56:15 toshi kernel: FreeBSD 12.0-CURRENT #35 r334484: Fri Jun
1 08:25:58 EDT 2018

I'm going to build one with SVN r334862 reverted to see if that works,


Hi,

Is it working now? Am asking because a system I'd like to take from 
11-stable to 12 uses the em driver.


thanks,

--
J.
___
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: Unable to UEFI boot 11.2 ISO (latest 12.0 as well)

[Toomas Soome]

> On 5 Jul 2018, at 10:28, Linus Sundqvist  wrote:
> 
> Here's the output, variable 'currdev' not found:
> https://imgur.com/LlBygfr 


Yes indeed, as you got the error, so the variable was not set at all. My 
suggestion would be to walk over the code in main.c, and to try to get more 
debug printouts from that dell system… Im myself mostly offline till next week.

rgds,
toomas

> 
> And to answer Rodneys question from before, this is the emulated CD drive 
> from a Dell iDRAC (remote console thingy).
> 
> Med vänlig hälsning/Best Regards
> Linus Sundqvist
> System Engineer, Loopia AB
> 
> On 05/07/18 09:17, Toomas Soome wrote:
>> Could you check, show currdev from OK prompt before setting it.
>> 
>> Somehow the boot device path is shown but we fail to recognize it (as seen 
>> by error message). However, the lsdev -v does show the path, so the 
>> efipart.c seems to do its work correctly. I feel, there should be some 
>> corner case in efi/loader/main.c where we detect the boot device.
>> 
>> Rgds,
>> Toomas
>> 
>> Sent from my iPhone
>> 
>>> On 5 Jul 2018, at 09:32, Linus Sundqvist  wrote:
>>> 
>>> Running these commands makes the boot menu show up, and then takes me to 
>>> the BSD installer!
>>> 
>>> Med vänlig hälsning/Best Regards
>>> Linus Sundqvist
>>> System Engineer, Loopia AB
>>> 
 On 04/07/18 16:50, Toomas Soome wrote:
 set currdev=cd1:
 include /boot/loader.rc
 
 This should give menu/boot.
 
 Rgds,
 Toomas
 
 Sent from my iPhone
 
> On 4 Jul 2018, at 16:25, Linus Sundqvist  
> wrote:
> 
> Hi,
> 
> Sure, while using the 12.0 ISO here is lsdev -v and ls cd0:
> https://imgur.com/RmYpg7u
> 
> and here is ls cd1:
> https://imgur.com/FPsixOw
> 
> Med vänlig hälsning/Best Regards
> Linus Sundqvist
> System Engineer, Loopia AB
> 
>> On 04/07/18 15:08, Toomas Soome wrote:
>> Can you post lsdev -v output?
>> 
>> Also, could you try ls command? Like, ls cd0:   
>> 
>> Rgds,
>> Toomas
>> 
>> Sent from my iPhone
>> 
>>> On 4 Jul 2018, at 12:28, Linus Sundqvist  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> I'm unable to boot up the amd64 11.2 disk1 ISO as well as the latest 
>>> amd64 12.0 disk1 ISO (20180628) using UEFI on a Dell PowerEdge R430 by 
>>> getting this error:
>>> https://imgur.com/a/Idljfhm
>>> 
>>> The bootonly ISOs seems to show the same error message.
>>> 
>>> Changing the server to boot via BIOS loads the setup correctly, 
>>> however, I want to use UEFI on all our servers, which I have done 
>>> before.
>>> 
>>> The 11.1 ISO boots without any trouble at all using both UEFI and BIOS.
>>> 
>>> I was helped by koobs in #freebsd @ Freenode who asked me to send an 
>>> e-mail this way and linking to these commits as a reference:
>>> 
>>> https://reviews.freebsd.org/D13784
>>> https://svnweb.freebsd.org/base?view=revision=332416
>>> 
>>> So far I've tried to UEFI boot the 11.2 ISO and 12.0 ISO with the 
>>> following Dell PowerEdge models without success:
>>> 
>>> R440
>>> R630
>>> R430
>>> FC430
>>> R330
>>> R620
>>> R420
>>> R610
>>> 
>>> -- 
>>> Med vänlig hälsning/Best Regards
>>> Linus Sundqvist
>>> System Engineer, Loopia AB
>>> 
>> ___
>> 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"
>> 
> 
 ___
 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"
 
>>> 
>> ___
>> 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"
>> 
> 

___
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: Unable to UEFI boot 11.2 ISO (latest 12.0 as well)

[Linus Sundqvist]

Here's the output, variable 'currdev' not found:
https://imgur.com/LlBygfr

And to answer Rodneys question from before, this is the emulated CD drive from 
a Dell iDRAC (remote console thingy).

Med vänlig hälsning/Best Regards
Linus Sundqvist
System Engineer, Loopia AB

On 05/07/18 09:17, Toomas Soome wrote:
> Could you check, show currdev from OK prompt before setting it.
> 
> Somehow the boot device path is shown but we fail to recognize it (as seen by 
> error message). However, the lsdev -v does show the path, so the efipart.c 
> seems to do its work correctly. I feel, there should be some corner case in 
> efi/loader/main.c where we detect the boot device.
> 
> Rgds,
> Toomas
> 
> Sent from my iPhone
> 
>> On 5 Jul 2018, at 09:32, Linus Sundqvist  wrote:
>>
>> Running these commands makes the boot menu show up, and then takes me to the 
>> BSD installer!
>>
>> Med vänlig hälsning/Best Regards
>> Linus Sundqvist
>> System Engineer, Loopia AB
>>
>>> On 04/07/18 16:50, Toomas Soome wrote:
>>> set currdev=cd1:
>>> include /boot/loader.rc
>>>
>>> This should give menu/boot.
>>>
>>> Rgds,
>>> Toomas
>>>
>>> Sent from my iPhone
>>>
 On 4 Jul 2018, at 16:25, Linus Sundqvist  wrote:

 Hi,

 Sure, while using the 12.0 ISO here is lsdev -v and ls cd0:
 https://imgur.com/RmYpg7u

 and here is ls cd1:
 https://imgur.com/FPsixOw

 Med vänlig hälsning/Best Regards
 Linus Sundqvist
 System Engineer, Loopia AB

> On 04/07/18 15:08, Toomas Soome wrote:
> Can you post lsdev -v output?
>
> Also, could you try ls command? Like, ls cd0:   
>
> Rgds,
> Toomas
>
> Sent from my iPhone
>
>> On 4 Jul 2018, at 12:28, Linus Sundqvist  
>> wrote:
>>
>> Hi,
>>
>> I'm unable to boot up the amd64 11.2 disk1 ISO as well as the latest 
>> amd64 12.0 disk1 ISO (20180628) using UEFI on a Dell PowerEdge R430 by 
>> getting this error:
>> https://imgur.com/a/Idljfhm
>>
>> The bootonly ISOs seems to show the same error message.
>>
>> Changing the server to boot via BIOS loads the setup correctly, however, 
>> I want to use UEFI on all our servers, which I have done before.
>>
>> The 11.1 ISO boots without any trouble at all using both UEFI and BIOS.
>>
>> I was helped by koobs in #freebsd @ Freenode who asked me to send an 
>> e-mail this way and linking to these commits as a reference:
>>
>> https://reviews.freebsd.org/D13784
>> https://svnweb.freebsd.org/base?view=revision=332416
>>
>> So far I've tried to UEFI boot the 11.2 ISO and 12.0 ISO with the 
>> following Dell PowerEdge models without success:
>>
>> R440
>> R630
>> R430
>> FC430
>> R330
>> R620
>> R420
>> R610
>>
>> -- 
>> Med vänlig hälsning/Best Regards
>> Linus Sundqvist
>> System Engineer, Loopia AB
>>
> ___
> 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"
>

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



signature.asc
Description: OpenPGP digital signature

Re: Unable to UEFI boot 11.2 ISO (latest 12.0 as well)

[Toomas Soome]

Could you check, show currdev from OK prompt before setting it.

Somehow the boot device path is shown but we fail to recognize it (as seen by 
error message). However, the lsdev -v does show the path, so the efipart.c 
seems to do its work correctly. I feel, there should be some corner case in 
efi/loader/main.c where we detect the boot device.

Rgds,
Toomas

Sent from my iPhone

> On 5 Jul 2018, at 09:32, Linus Sundqvist  wrote:
> 
> Running these commands makes the boot menu show up, and then takes me to the 
> BSD installer!
> 
> Med vänlig hälsning/Best Regards
> Linus Sundqvist
> System Engineer, Loopia AB
> 
>> On 04/07/18 16:50, Toomas Soome wrote:
>> set currdev=cd1:
>> include /boot/loader.rc
>> 
>> This should give menu/boot.
>> 
>> Rgds,
>> Toomas
>> 
>> Sent from my iPhone
>> 
>>> On 4 Jul 2018, at 16:25, Linus Sundqvist  wrote:
>>> 
>>> Hi,
>>> 
>>> Sure, while using the 12.0 ISO here is lsdev -v and ls cd0:
>>> https://imgur.com/RmYpg7u
>>> 
>>> and here is ls cd1:
>>> https://imgur.com/FPsixOw
>>> 
>>> Med vänlig hälsning/Best Regards
>>> Linus Sundqvist
>>> System Engineer, Loopia AB
>>> 
 On 04/07/18 15:08, Toomas Soome wrote:
 Can you post lsdev -v output?
 
 Also, could you try ls command? Like, ls cd0:   
 
 Rgds,
 Toomas
 
 Sent from my iPhone
 
> On 4 Jul 2018, at 12:28, Linus Sundqvist  
> wrote:
> 
> Hi,
> 
> I'm unable to boot up the amd64 11.2 disk1 ISO as well as the latest 
> amd64 12.0 disk1 ISO (20180628) using UEFI on a Dell PowerEdge R430 by 
> getting this error:
> https://imgur.com/a/Idljfhm
> 
> The bootonly ISOs seems to show the same error message.
> 
> Changing the server to boot via BIOS loads the setup correctly, however, 
> I want to use UEFI on all our servers, which I have done before.
> 
> The 11.1 ISO boots without any trouble at all using both UEFI and BIOS.
> 
> I was helped by koobs in #freebsd @ Freenode who asked me to send an 
> e-mail this way and linking to these commits as a reference:
> 
> https://reviews.freebsd.org/D13784
> https://svnweb.freebsd.org/base?view=revision=332416
> 
> So far I've tried to UEFI boot the 11.2 ISO and 12.0 ISO with the 
> following Dell PowerEdge models without success:
> 
> R440
> R630
> R430
> FC430
> R330
> R620
> R420
> R610
> 
> -- 
> Med vänlig hälsning/Best Regards
> Linus Sundqvist
> System Engineer, Loopia AB
> 
 ___
 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"
 
>>> 
>> ___
>> 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"
>> 
> 
___
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: Unable to UEFI boot 11.2 ISO (latest 12.0 as well)

[Linus Sundqvist]

Running these commands makes the boot menu show up, and then takes me to the 
BSD installer!

Med vänlig hälsning/Best Regards
Linus Sundqvist
System Engineer, Loopia AB

On 04/07/18 16:50, Toomas Soome wrote:
> set currdev=cd1:
> include /boot/loader.rc
> 
> This should give menu/boot.
> 
> Rgds,
> Toomas
> 
> Sent from my iPhone
> 
>> On 4 Jul 2018, at 16:25, Linus Sundqvist  wrote:
>>
>> Hi,
>>
>> Sure, while using the 12.0 ISO here is lsdev -v and ls cd0:
>> https://imgur.com/RmYpg7u
>>
>> and here is ls cd1:
>> https://imgur.com/FPsixOw
>>
>> Med vänlig hälsning/Best Regards
>> Linus Sundqvist
>> System Engineer, Loopia AB
>>
>>> On 04/07/18 15:08, Toomas Soome wrote:
>>> Can you post lsdev -v output?
>>>
>>> Also, could you try ls command? Like, ls cd0:   
>>>
>>> Rgds,
>>> Toomas
>>>
>>> Sent from my iPhone
>>>
 On 4 Jul 2018, at 12:28, Linus Sundqvist  wrote:

 Hi,

 I'm unable to boot up the amd64 11.2 disk1 ISO as well as the latest amd64 
 12.0 disk1 ISO (20180628) using UEFI on a Dell PowerEdge R430 by getting 
 this error:
 https://imgur.com/a/Idljfhm

 The bootonly ISOs seems to show the same error message.

 Changing the server to boot via BIOS loads the setup correctly, however, I 
 want to use UEFI on all our servers, which I have done before.

 The 11.1 ISO boots without any trouble at all using both UEFI and BIOS.

 I was helped by koobs in #freebsd @ Freenode who asked me to send an 
 e-mail this way and linking to these commits as a reference:

 https://reviews.freebsd.org/D13784
 https://svnweb.freebsd.org/base?view=revision=332416

 So far I've tried to UEFI boot the 11.2 ISO and 12.0 ISO with the 
 following Dell PowerEdge models without success:

 R440
 R630
 R430
 FC430
 R330
 R620
 R420
 R610

 -- 
 Med vänlig hälsning/Best Regards
 Linus Sundqvist
 System Engineer, Loopia AB

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



signature.asc
Description: OpenPGP digital signature