Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

[Andrey Fesenko]

Fixed

On Thu, Nov 28, 2019 at 11:18 PM Toomas Soome  wrote:
>
>
>
> On 28. Nov 2019, at 22:16, Andrey Fesenko  wrote:
>
> On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome  wrote:
>
>
> hi!
>
> I did try to reach you, but mail did bounce back…
>
> unicast ping me:)
>
> rgds,
> toomas
>
> On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
>
> Hello,
>
> Around starting 20191114 r354699 (memstick tested), my desktop not
> boot normally. Boot only loader menu (black and white mode) after
> start i'm see load modules, after this monitor gray, and 15-20s
> disabled, system block not disable but run silently. system not boot.
>
> If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
> release, system boot normally
>
>
>
> This video boot second version (Name: "loader.efi") 545 KB
> https://bsdnir.info/files/efi_fail.mp4
>
>
> 403 Forbidden
>
> :=)
>
> rgds,
> toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

[Toomas Soome]

> On 28. Nov 2019, at 22:16, Andrey Fesenko  wrote:
> 
> On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome  > wrote:
>> 
>> hi!
>> 
>> I did try to reach you, but mail did bounce back…
>> 
>> unicast ping me:)
>> 
>> rgds,
>> toomas
>> 
>>> On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
>>> 
>>> Hello,
>>> 
>>> Around starting 20191114 r354699 (memstick tested), my desktop not
>>> boot normally. Boot only loader menu (black and white mode) after
>>> start i'm see load modules, after this monitor gray, and 15-20s
>>> disabled, system block not disable but run silently. system not boot.
>>> 
>>> If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
>>> release, system boot normally
>>> 
>> 
> 
> This video boot second version (Name: "loader.efi") 545 KB
> https://bsdnir.info/files/efi_fail.mp4 
> 

403 Forbidden

:=)

rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

[Andrey Fesenko]

On Thu, Nov 28, 2019 at 9:20 PM Andrey Fesenko  wrote:
>
> On Thu, Nov 28, 2019 at 1:24 PM Eugene Grosbein  wrote:
> >
> > 28.11.2019 16:43, Andrey Fesenko wrote:
> >
> > > Hello,
> > >
> > > Around starting 20191114 r354699 (memstick tested), my desktop not
> > > boot normally. Boot only loader menu (black and white mode) after
> > > start i'm see load modules, after this monitor gray, and 15-20s
> > > disabled, system block not disable but run silently. system not boot.
> >
> > So loader works. Try breaking to loader prompt and do:
> >
> > set hw.vga.acpi_ignore_no_vga=1
> > boot
> >
>
> Hm new test, new problems. Old and new efi, if breaking to loader
> prompt work only alphabet keys, nums not work :) (on notebook loader
> work fine)
> If make
> echo 'hw.vga.acpi_ignore_no_vga=1' > /boot/loader.conf
>
> on flash, and reboot, not fix boot.

Correction number and underline work, but set
hw.vga.acpi_ignore_no_vga not fix boot
___
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"

Best way to print something from the kernel at 1s intervals?

[Peter Eriksson]

I’ve been looking into the “kernel looks to be hung at reboot” problem at bit. 
Adding a lot of printf() calls to the relevant parts it looks like it actually 
isn’t hung but busy unmounting filesystems (which we have thousands of), 
flushing disk caches, calling registered callbacks and stuff and sometimes it 
takes a bit longer than usual - probably due to ZFS having stuff queued up that 
needs to be written to disk before it finishes…

Anyway, I’d like to propose that we add some kind of counter/printf() calls in 
that code area so we can see that things are indeed progressing. However, I’d 
probably prefer not to print _every_ filesystem (or registered callbacks - a 
lot of those...) - that generates a lot of output (tried that :-) but something 
like:

Unmounting filesystems:
1234 done
(With the "1234 done” updated something like once per second).

What’s the right/best way to do that from the kernel? In user space I’d just 
call time() at some convenient points and only print something if “t” has 
changed. :-)

- Peter

___
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 loader failure, after 20191114-r354699 Z87MX-D3H

[Andrey Fesenko]

On Thu, Nov 28, 2019 at 11:31 PM Toomas Soome  wrote:
>
>
>
> > On 28. Nov 2019, at 22:20, Andrey Fesenko  wrote:
> >
> > Fixed
> >
>
> Thanks. And yea, that one is nasty. I have some guess but nothing too solid… 
> it may take time to get figured out.
>
> Have you tested BIOS boot?
>
> rgds,
> toomas
>
> > On Thu, Nov 28, 2019 at 11:18 PM Toomas Soome  wrote:
> >>
> >>
> >>
> >> On 28. Nov 2019, at 22:16, Andrey Fesenko  wrote:
> >>
> >> On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome  wrote:
> >>
> >>
> >> hi!
> >>
> >> I did try to reach you, but mail did bounce back…
> >>
> >> unicast ping me:)
> >>
> >> rgds,
> >> toomas
> >>
> >> On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
> >>
> >> Hello,
> >>
> >> Around starting 20191114 r354699 (memstick tested), my desktop not
> >> boot normally. Boot only loader menu (black and white mode) after
> >> start i'm see load modules, after this monitor gray, and 15-20s
> >> disabled, system block not disable but run silently. system not boot.
> >>
> >> If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
> >> release, system boot normally
> >>
> >>
> >>
> >> This video boot second version (Name: "loader.efi") 545 KB
> >> https://bsdnir.info/files/efi_fail.mp4
> >>
> >>
> >> 403 Forbidden
> >>
> >> :=)
> >>
> >> rgds,
> >> toomas
>

BIOS boot fine, loader colored, installer start normal.
___
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 loader failure, after 20191114-r354699 Z87MX-D3H

[Andrey Fesenko]

On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome  wrote:
>
> hi!
>
> I did try to reach you, but mail did bounce back…
>
> unicast ping me:)
>
> rgds,
> toomas
>
> > On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
> >
> > Hello,
> >
> > Around starting 20191114 r354699 (memstick tested), my desktop not
> > boot normally. Boot only loader menu (black and white mode) after
> > start i'm see load modules, after this monitor gray, and 15-20s
> > disabled, system block not disable but run silently. system not boot.
> >
> > If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
> > release, system boot normally
> >
>

This video boot second version (Name: "loader.efi") 545 KB
https://bsdnir.info/files/efi_fail.mp4
___
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: r352558 - head/usr.bin/top

[Mark Millard]

> Author: daichi
> Date: Fri Sep 20 17:37:23 2019
> New Revision: 352558
> URL: 
> https://svnweb.freebsd.org/changeset/base/352558
> 
> 
> Log:
>   top(1): support multibyte characters in command names (ARGV array)
>   depending on locale.
>   
>- add setlocale()
>- remove printable() function
>- add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
>  non-printable characters that do not use C-style backslash sequences
>  in three digit octal sequence, or remove it
>   
>   This change allows multibyte characters to be displayed according to
>   locale. If it is recognized as a non-display character according to the
>   locale, it is displayed in three digit octal sequence.
> 

Initially picking on tab characters as an example of what is
probably a somewhat broader issue . . .

Ever since this change, characters like tabs that do not fit
in the next character cell when output, but for which they
are !isprintable(...), now mess up the top display. Again
using tab as an example: line wrapping from the text having
been shifted over by more than one character cell. top does
not track the line wrapping result in how it decides what
to output for the following display updates.

As stands I type "hh" to referesh the display when I care
about clearing up the messy display.

The removed !isprintable handling functionality had its uses
and an alternative is needed for some types of characters if
the display is not to be messed up by what some command lines
that are echoed have in them.

I picked on tab because it was obviously involved in some
examples that I watched update. I'm not claiming tab is the
only character that ends up with e cursor in an unexpected
place now. In fact . . .

Looking around I found:

 VIS_SAFEOnly encode "unsafe" characters.  Unsafe means control char-
 acters which may cause common terminals to perform unexpected
 functions.  Currently this form allows space, tab, newline,
 backspace, bell, and return - in addition to all graphic
 characters - unencoded.

So tab, newline, backspace, bell, and return are not encoded
or replaced now but do not have top's expected cursor position
result.


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

various VM panics (arm64) / hangs after init (arm64/x86)

[Bjoern A. Zeeb]

Hi,

over the last days both on x86 as well as on arm64 I had various strange 
“hangs” or panics.  I’ll try to find svn revisions which do 
compile and try and see if I can do a bit of bisect (the first two 
attempts did not compile; should try the CI system).  Given it is all 
new setups from the last week, I do not have previous behaviour (or 12.x 
one only).



(a) on x86 and arm64 I have “hangs” after starting init around the 
re-mount;  one of the later “hangs” on arm64 was:


Initially I thought it was related to USB as not compiling that in made 
the problem go away on x86 (where the console was frozen in a 1 VCPU VM 
so I couldn’t debug).
On Arm64 I can now press ^T and see that it actually is waiting hard .. 
(and removing USB from the kernel did move the problem slightly but not 
make it go away).


(notice real time)
load: 0.45  cmd: sysctl 27 [objtrm] 1711.61r 0.00u 0.00s 0% 0k



(b) The quickest I found so far was on arm64/head from an hour ago; this 
is with and without an md_image or other modules loaded and GENERIC 
rather than GENERIC-NODEBUG (reproduced in two consecutive boots);  it 
seems to sometimes matter whether I boot with hw.ncpu=4 or hw.ncpu=1:


---<>---
KDB: debugger backends: ddb
KDB: current backend: ddb
   Type Physical  Virtual   #Pages Attr
 ConventionalMemory 0020   20 7eea WB
RuntimeServicesData 080ea000  80ea000 002c WB RUNTIME
 ConventionalMemory 08116000  8116000 000e46e9 WB
 LoaderData ec7ff000 ec7ff000 8696 WB
 LoaderCode f4e95000 f4e95000 008d WB
RuntimeServicesData f4f22000 f4f22000 0001 WB RUNTIME
   Reserved f4f23000 f4f15000 0006 WB
RuntimeServicesData f4f29000 f4f29000 0001 WB RUNTIME
   Reserved f4f2a000 f4f2a000 0002 WB
 LoaderData f4f2c000 f4f2c000 3014 WB
RuntimeServicesCode f7f4 f7f4 0010 WB RUNTIME
 LoaderData f7f5 f4f2c000 00b0 WB
Physical memory chunk(s):
  0x0020 - 0xf4f22fff,  3917 MB (1002787 pages)
  0xf4f29000 - 0xf4f29fff, 0 MB (  1 pages)
  0xf4f2c000 - 0xf7f3,48 MB (  12308 pages)
  0xf7f5 - 0xf7ff, 0 MB (176 pages)
Excluded memory regions:
  0x080ea000 - 0x08115fff, 0 MB ( 44 pages) NoAlloc
  0xec80 - 0xf0f38fff,71 MB (  18233 pages) NoAlloc
  0xf4f22000 - 0xf4f2bfff, 0 MB ( 10 pages) NoAlloc
  0xf7f4 - 0xf7f4, 0 MB ( 16 pages) NoAlloc
Found 6 CPUs in the device tree
Copyright (c) 1992-2019 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights 
reserved.

FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-arm64-base13-nanopct4 #1 r355193M 
11d01e051405-c509697(master): Fri Nov 29 00:31:57 UTC 2019

..
FreeBSD clang version 9.0.0 (tags/RELEASE_900/final 372316) (based on 
LLVM 9.0.0)

WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
Preloaded elf kernel "/boot/kernel/kernel" at 0x0450c000.
Preloaded md_image "/base13-nanopct4-r355193" at 0x04514e80.
Preloaded elf module "/boot/kernel/nullfs.ko" at 0x04514ee0.
Preloaded elf module "/boot/kernel/geom_eli.ko" at 0x04515638.
module firmware already present!
panic: page 0xfd00ec54c170 has object
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
 pc = 0x006dee8c  lr = 0x001066c8
 sp = 0x000103f0  fp = 0x00010600

db_trace_self_wrapper() at vpanic+0x18c
 pc = 0x001066c8  lr = 0x003b563c
 sp = 0x00010610  fp = 0x000106c0

vpanic() at panic+0x44
 pc = 0x003b563c  lr = 0x003b53ec
 sp = 0x000106d0  fp = 0x00010750

panic() at vm_page_alloc_check+0x78
 pc = 0x003b53ec  lr = 0x00692b2c
 sp = 0x00010760  fp = 0x00010760

vm_page_alloc_check() at vm_page_alloc_domain_after+0x2a4
 pc = 0x00692b2c  lr = 0x00692298
 sp = 0x00010770  fp = 0x000107f0

vm_page_alloc_domain_after() at kmem_back_domain+0xec
 pc = 0x00692298  lr = 0x0067de6c
 sp = 0x00010800  fp = 0x00010850

kmem_back_domain() at kmem_malloc_domainset+0xc0
 pc = 0x0067de6c  lr = 0x0067dd48
 sp = 0x00010860  fp = 0x000108d0

kmem_malloc_domainset() at vm_ksubmap_init+0x54
 pc = 0x0067dd48  lr = 0x0067d1d8
 sp = 0x000108e0  fp = 0x00010920

vm_ksubmap_init() at cpu_startup+0x1c
 pc = 0x0067d1d8  lr = 0x006ea77c
 sp = 0x00010930  fp = 0x00010930

Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

[Toomas Soome]

> On 28. Nov 2019, at 22:20, Andrey Fesenko  wrote:
> 
> Fixed
> 

Thanks. And yea, that one is nasty. I have some guess but nothing too solid… it 
may take time to get figured out.

Have you tested BIOS boot?

rgds,
toomas

> On Thu, Nov 28, 2019 at 11:18 PM Toomas Soome  wrote:
>> 
>> 
>> 
>> On 28. Nov 2019, at 22:16, Andrey Fesenko  wrote:
>> 
>> On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome  wrote:
>> 
>> 
>> hi!
>> 
>> I did try to reach you, but mail did bounce back…
>> 
>> unicast ping me:)
>> 
>> rgds,
>> toomas
>> 
>> On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
>> 
>> Hello,
>> 
>> Around starting 20191114 r354699 (memstick tested), my desktop not
>> boot normally. Boot only loader menu (black and white mode) after
>> start i'm see load modules, after this monitor gray, and 15-20s
>> disabled, system block not disable but run silently. system not boot.
>> 
>> If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
>> release, system boot normally
>> 
>> 
>> 
>> This video boot second version (Name: "loader.efi") 545 KB
>> https://bsdnir.info/files/efi_fail.mp4
>> 
>> 
>> 403 Forbidden
>> 
>> :=)
>> 
>> rgds,
>> toomas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

13.0-CURRENT r355121 snapshot .img Works Great!

[Clay Daniels]

drmn0: successfully loaded firmware image with name: amdgpu/polaris~

AMD Ryzen 7 3700x cpu with MSI 570 series Motherboard & Video Card
[Home built machine]

Able to make drm-kmod from ports

Third week in a row with no problems!

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

WifI support missing: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

for over two years we have a small router project based on FreeBSD. The 
hardware is equipted
with a WiFi mPCIe card and reports itself to 12-STABLE/13-CURRENT as:

[...]
none2@pci0:1:0:0:   class=0x028000 card=0x chip=0x003c168c rev=0x00 
hdr=0x00
vendor = 'Qualcomm Atheros'
device = 'QCA986x/988x 802.11ac Wireless Network Adapter'
class  = network
bar   [10] = type Memory, range 64, base 0xf760, size 2097152, enabled
[...]

The ath-driver found in recent 12-STABLE/13-CURRENT do not support this chip 
although it seems
very common and well supported by several Linux distributions including the 
OpenWRT router
project (I think that is the ath10k driver suite as far as I recall).

Thanks in adavnce,

oh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXd/BBgAKCRA4N1ZZPba5
R7NuAQCt+4xXyLHzQnV1+nEwZQOE9xGG8AVLxKYzlbaasxf3CgD+N3MxDvqxPUp3
Cw/osKMq3VUy2StmdXOL26PR+U4vHAE=
=Vd2O
-END PGP SIGNATURE-
___
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 loader failure, after 20191114-r354699 Z87MX-D3H

[Andrey Fesenko]

Hello,

Around starting 20191114 r354699 (memstick tested), my desktop not
boot normally. Boot only loader menu (black and white mode) after
start i'm see load modules, after this monitor gray, and 15-20s
disabled, system block not disable but run silently. system not boot.

If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
release, system boot normally

My notebook x220 work fine any loaders.

desktop
BIOS Information
Vendor: American Megatrends Inc.
Version: F2
Release Date: 05/03/2013
Address: 0xF
Runtime Size: 64 kB
ROM Size: 16 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: Z87MX-D3H
Version: To be filled by O.E.M.
Serial Number: To be filled by O.E.M.
UUID: 03de0294-0480-057d-0c06-7a0700080009
Wake-up Type: Power Switch
SKU Number: To be filled by O.E.M.
Family: To be filled by O.E.M.
___
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"

unsub

[André Glória]

___
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 loader failure, after 20191114-r354699 Z87MX-D3H

[Toomas Soome]

hi!

I did try to reach you, but mail did bounce back…

unicast ping me:)

rgds,
toomas

> On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
> 
> Hello,
> 
> Around starting 20191114 r354699 (memstick tested), my desktop not
> boot normally. Boot only loader menu (black and white mode) after
> start i'm see load modules, after this monitor gray, and 15-20s
> disabled, system block not disable but run silently. system not boot.
> 
> If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
> release, system boot normally
> 
> My notebook x220 work fine any loaders.
> 
> desktop
> BIOS Information
>Vendor: American Megatrends Inc.
>Version: F2
>Release Date: 05/03/2013
>Address: 0xF
>Runtime Size: 64 kB
>ROM Size: 16 MB
>Characteristics:
>PCI is supported
>BIOS is upgradeable
>BIOS shadowing is allowed
>Boot from CD is supported
>Selectable boot is supported
>BIOS ROM is socketed
>EDD is supported
>5.25"/1.2 MB floppy services are supported (int 13h)
>3.5"/720 kB floppy services are supported (int 13h)
>3.5"/2.88 MB floppy services are supported (int 13h)
>Print screen service is supported (int 5h)
>8042 keyboard services are supported (int 9h)
>Serial services are supported (int 14h)
>Printer services are supported (int 17h)
>ACPI is supported
>USB legacy is supported
>BIOS boot specification is supported
>Targeted content distribution is supported
>UEFI is supported
>BIOS Revision: 4.6
> 
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
>Manufacturer: Gigabyte Technology Co., Ltd.
>Product Name: Z87MX-D3H
>Version: To be filled by O.E.M.
>Serial Number: To be filled by O.E.M.
>UUID: 03de0294-0480-057d-0c06-7a0700080009
>Wake-up Type: Power Switch
>SKU Number: To be filled by O.E.M.
>Family: To be filled by O.E.M.
> ___
> 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 loader failure, after 20191114-r354699 Z87MX-D3H

[Andrey Fesenko]

On Thu, Nov 28, 2019 at 1:24 PM Eugene Grosbein  wrote:
>
> 28.11.2019 16:43, Andrey Fesenko wrote:
>
> > Hello,
> >
> > Around starting 20191114 r354699 (memstick tested), my desktop not
> > boot normally. Boot only loader menu (black and white mode) after
> > start i'm see load modules, after this monitor gray, and 15-20s
> > disabled, system block not disable but run silently. system not boot.
>
> So loader works. Try breaking to loader prompt and do:
>
> set hw.vga.acpi_ignore_no_vga=1
> boot
>

Hm new test, new problems. Old and new efi, if breaking to loader
prompt work only alphabet keys, nums not work :) (on notebook loader
work fine)
If make
echo 'hw.vga.acpi_ignore_no_vga=1' > /boot/loader.conf

on flash, and reboot, not fix boot.
___
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"