SV: UEFI boot fail on higher resolutions (Re: Acer E3-112 and UEFI)
-Opprinnelig melding- Fra: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] På vegne av Jakob Alvermark Sendt: tirsdag 30. juni 2015 20.53 Til: freebsd-current@freebsd.org Emne: Re: UEFI boot fail on higher resolutions (Re: Acer E3-112 and UEFI) On Wed, February 4, 2015 15:04, Jakob Alvermark wrote: On 31 dec 2014, at 16:24, Jakob Alvermark wrote: On Tue, December 30, 2014 17:00, Nathan Whitehorn wrote: On 12/30/14 06:40, Jakob Alvermark wrote: Hi, Have been playing with this machine for a while now. It is a quad core Pentium N3540 (ValleyView/Bay Trail), 8 GB RAM. It came with a Broadcom WiFi card which I swapped for an Intel which is supported by FreeBSD. Also swapped the hard drive for an SSD. When first trying to boot FreeBSD with UEFI it would not boot. It stops after the loader is trying to start the kernel. My workaround now is using refind, http://www.rodsbooks.com/refind/ to set the screen resolution to 800x600. (Native is 1366x768) Only then will it boot using UEFI. I tried setting it to 1024x768, then it crashes. If it helps I can get the backtrace. [Not sure what's going on here] A follow up on this: I tried this on my desktop machine (AMD FX-8350, Radeon HD 5450) to see if it has the issue, and it has! I went on to try it on my desktop machine at work (Core i3-4130, Radeon HD 4350) and it boots! On the Acer, resolution set to 1024x768: FreeBSD EFI boot block Loader path: /boot/loader.efi Consoles: EFI console Image base: 0x7502f000 EFI version: 2.40 EFI Firmware: INSYDE Corp. (rev 21522.39) --- Start @ 0x802e1000 ... EFI framebuffer information: addr, size 0x8000, 0x30 dimensions 1024 x 768 stride 1024 masks 0x00ff, 0xff00, 0x00ff, 0xff00 --- kernel trap12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x13 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80a20834 stack pointer = 0x28:0x81604170 frame pointer = 0x28:0x81604290 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () [ thread pid 0 tid 0] Stopped at kvprintf+0xd4:movzbl (%r14),%eax On the home desktop resolution 1024x768: FreeBSD EFI boot block Loader path: /boot/loader.efi Consoles: EFI console Image base: 0xb08ac000 EFI version: 2.31 EFI Firmware: American Megatrends (rev 4.653) --- Start @ 0x802e1000 ... EFI framebuffer information: addr, size 0xc000, 0x30 dimensions 1024 x 768 stride 1024 masks 0x00ff, 0xff00, 0x00ff, 0xff00 --- kernel trap12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x13 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80a20654 stack pointer = 0x28:0x81603d70 frame pointer = 0x28:0x81603e90 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () [ thread pid 0 tid 0] Stopped at kvprintf+0xd4:movzbl (%r14),%eax On the work desktop: FreeBSD EFI boot block Loader path: /boot/loader.efi Consoles: EFI console Image base: 0xbb7aa000 EFI version: 2.31 EFI Firmware: American Megatrends (rev 4.654) --- Start @ 0x802e1000 ... EFI framebuffer information: addr, size 0xe000, 0x30 dimensions 1024 x 768 stride 1024 masks 0x00ff, 0xff00, 0x00ff, 0xff00 And then it boots normally. Does anyone have any clues on what's going on here? (This all typed manually from screenshots taken with my phone, there might be typos.) Another update! As I found out the EFI loader has the capability to change screen modes I dumped refind and started playing with this again. mode 5 gives me 1024x768 and a panic: --- kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1f2d0ec fault code = supervisor read data, page not present Instruction pointer= 0x20:0x8030003d stack pointer = 0x28:0x81616f70 frame pointer = 0x28:0x0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process= 0 () --- What struck me then was this line: instruction pointer= 0x20:0x8030003d and the fact that: EFI framebuffer information:
Segmentation fault running ntpd
Lousy timing (no pun intended -- it's early in the day for me), given the recent MFC, but as I was booting my laptop to yesterday's head: FreeBSD g1-245.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #127 r285652M/285652:1100077: Fri Jul 17 04:30:16 PDT 2015 r...@g1-245.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY amd64 to build today's head (@r285670; still in progress as I type), I happened to note [Oh, great -- we can no longer copy/paste from console now??!? Fine, I'll transcribe by hand :-(]: ... bound to 172.17.1.245 -- renewal in 43200 seconds. pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) Starting Network: lo0 em0 iwn0 lagg0. ... Trying to examine the /ntpd.core, I see: root@g1-245:/ # gdb `which ntpd` ntpd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... Core was generated by `ntpd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libcrypto.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.7 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0008011cd6a0 in sbrk () from /lib/libc.so.7 [New Thread 801c07400 (LWP 100122/unknown)] [New Thread 801c06400 (LWP 100120/unknown)] (gdb) bt #0 0x0008011cd6a0 in sbrk () from /lib/libc.so.7 #1 0x0008ccbd4f34 in ?? () #2 0x0005 in ?? () #3 0x000801800448 in ?? () #4 0x0008011ca888 in sbrk () from /lib/libc.so.7 #5 0x0008018000c8 in ?? () #6 0x0008018000c0 in ?? () #7 0x0208 in ?? () #8 0x000801c32fb0 in ?? () #9 0x0001 in ?? () #10 0x000801cc20c8 in ?? () #11 0x0030 in ?? () #12 0x000801cc20c8 in ?? () #13 0x7fffe480 in ?? () #14 0x0008011cd240 in sbrk () from /lib/libc.so.7 #15 0x0280 in ?? () #16 0x0008014bbc70 in malloc_message () from /lib/libc.so.7 #17 0x0008018000c0 in ?? () #18 0x000801800448 in ?? () #19 0x0032 in ?? () #20 0x000801800458 in ?? () #21 0x0008014bbc68 in malloc_message () from /lib/libc.so.7 #22 0x000801cc2000 in ?? () ---Type return to continue, or q return to quit--- #23 0x0008014bba60 in malloc_message () from /lib/libc.so.7 #24 0x000801cc20d8 in ?? () #25 0x00a0 in ?? () #26 0x0208 in ?? () #27 0x7fffe4d0 in ?? () #28 0x0008011bdd7a in _malloc_thread_cleanup () from /lib/libc.so.7 Previous frame inner to this frame (corrupt stack?) (gdb) which seems... well, not especially useful, as far as I can tell. This is (as mentioned above) on my laptop; as such, it is expected to wander from one network to another. Accordingly: * Since it could be connected to a network I do not control, I use a packet filter (IPFW, in my case) to reduce my exposure from a possibly-hostile network. * Rather than enabling ntpd in /etc/rc.conf, I use /etc/dhclient-exit-hooks to start ntpd after the laptop has a DHCP lease. (For networks I control, I also set up the DHCP server to advertise what NTP server the DHCP clients should use, but the code in dhclient-exit-hooks merely prefers that, rather han requiring it.) * In my world-view -- at least for networks I control -- DNS zone files are the Source of Truth with respect to hostname - IP address correspondence, and Dynamic DNS is Evil. I populate my zone files with appropriate A PTR records so that every assignable DHCP address has a PTR record, and the hostname to which it points has an A record that points back to that IP address. Accordingly, I also use /etc/dhclient-exit-hooks so the laptop can find out what its hostname is, and set it accordingly. Mind, I've been doing the above for well over a decade, so that doesn't qualify as new. And most of the time, it Just Works (which is a significant reason I keep doing it). A couple of other things that are more recent, and possibly of relevance: * As alluded to above, I have the em0 wlan0 (iwn(4)) NICs set up using Link Aggregation in failover mode. In practice, I rarely use the em0 (wired) NIC -- I had originally done that based on a misperception of how I thought things were set up at work, and then just left the configuration alone and
Re: -current broken when src is on NFS
O'Connor, Daniel dar...@dons.net.au wrote: However, Crochet _does_ build on the NFS client _and_ when the source tree isn't in /usr/src which makes this issue very strange :-/ I've seen similar errors in rescue... (no NFS) though I cannot quite recall the cause other than it seems very sensitive to MAKEOBJDIRPREFIX value. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
