Re: snapshot boot fails with error "entry point at 0x1001000"
On Sun, Jul 05, 2020 at 09:32:47PM -0700, Kastus Shchuka wrote:
> On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote:
> > Kastus Shchuka wrote:
> > “I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able
> > to boot it.
> > Boot stops at the line
> >
> > entry point at 0x1001000
> >
> > If I try bsd.rd kernel, it boots just fine. After this failure with
> > snapshot I
> > installed 6.7-release, and it boots without any issues.”
> >
> >
> > I've experienced something similar, including the sensitivity to kernel
> > size. As best I can observe, the EFI bootloader is being handed a different
> > block of RAM than where the kernel is actually loaded (which is at a fixed
> > address defined in boot.c). Which block of memory gets returned, and
> > whether boot fails, seems to be dependent on the particular UEFI
> > ROM/chipset. In my case, debugging over serial, I observe a page fault
> > while the kernel is still being loaded into RAM.
> > “Are there any other solutions than compiling a custom smaller kernel?”
> >
> >
> > Patching efiboot.c as follows and recompiling bootia32/bootx64 resolved it
> > for me:
> > --- a/sys/arch/amd64/stand/efiboot/efiboot.c
> > +++ b/sys/arch/amd64/stand/efiboot/efiboot.c
> > @@ -303,9 +303,9 @@ efi_memprobe(void)
> > bios_memmap_t *bm;
> > EFI_STATUS status;
> > EFI_PHYSICAL_ADDRESS
> > -addr = 0x1000ULL; /* Below 256MB */
> > +addr = 0x100;
> >
> > - status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress,
> > EfiLoaderData,
> > + status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData,
> > EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), );
> > if (status != EFI_SUCCESS)
> > panic("BS->AllocatePages()");
> > Let me know if that helps. I can't guarantee that this is actually what is
> > causing your issue but it worked for me.
>
> I tried this patch and was able to boot kernel from snapshot 2007-07-03 with
> recompiled BOOTX64.EFI.
> It fixes the problem with EFI memory mapping on ASRock J4105M motherboard.
>
> I wonder what would it take for the patch to be accepted in -current?
>
As Mike Larkin pointed in
https://marc.info/?l=openbsd-misc=160377179930502=2, "mach mem"
output may shed some light on the problem.
So, for the ASRock J4105M motherboard, the output is this:
>> OpenBSD/amd64 BOOTX64 3.50
boot> mach mem
Region 0: type 1 at 0x0 for 248KB
Region 1: type 2 at 0x3e000 for 8KB
Region 2: type 1 at 0x4 for 376KB
Region 3: type 2 at 0x9e000 for 392KB
Region 4: type 1 at 0x10 for 261120KB
Region 5: type 1 at 0x12151000 for 1454584KB
Region 6: type 2 at 0x6adcf000 for 41480KB
Region 7: type 1 at 0x6d651000 for 324KB
Region 8: type 4 at 0x6d6a2000 for 160KB
Region 9: type 2 at 0x6d6ca000 for 3916KB
Region 10: type 1 at 0x6da9d000 for 10388KB
Region 11: type 2 at 0x6e4c2000 for 688KB
Region 12: type 1 at 0x6e56e000 for 6728KB
Region 13: type 1 at 0x1 for 6291456KB
Region 14: type 2 at 0x1000 for 34116KB
Region 15: type 2 at 0x6ec0 for 282624KB
Region 16: type 2 at 0xd000 for 16384KB
Region 17: type 2 at 0xd3709000 for 4KB
Region 18: type 2 at 0xe000 for 262144KB
Region 19: type 2 at 0xfe042000 for 12KB
Region 20: type 2 at 0xfe90 for 12KB
Region 21: type 2 at 0xfec0 for 4KB
Region 22: type 2 at 0xfed01000 for 4KB
Region 23: type 2 at 0xfee0 for 4KB
Region 24: type 2 at 0xff00 for 16384KB
Low ram: 1024KB High ram: 295236KB
With the patch, kernel is loaded in region 14 and it fits there.
Without patch, memory is allocated down from 0x1, and large kernel
overlaps with something and fails to boot.
There were reports on -misc that the patch does not help on some systems.
I wonder what can be tried differently to make it work on all systems?
Thanks,
Kastus
Re: 6.8 release crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
On Mon, Oct 26, 2020 at 07:48:32PM -0700, Alfred Morgan wrote: > I just wanted to report 6.8 release is having the same issue as > https://marc.info/?l=openbsd-misc=160224393101534=2 > except I have a CHUWI HeroBox Windows 10 Mini PC,Intel Gemini-Lake N4100 > Quad-Core Processor,8GB DDR4 256GB SSD,Expandable 2TB 2.5 Inch HDD,1TB SSD > with 2.4GHz/5GHz Dual WiFi 1000Mbps/BT4.2 > https://www.amazon.com/gp/product/B082VZP76P > > On a 6.7 release I did syspatch and then a sysupgrade and got the entry > point at: 0x1001000 error trying to boot after the upgrade was successful. > > -alfred A mach mem output from this machine might reveal something useful. boot> mach mem ... then send the output
Re: 6.8 release crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
On Mon, Oct 26, 2020 at 07:48:32PM -0700, Alfred Morgan wrote: > I just wanted to report 6.8 release is having the same issue as > https://marc.info/?l=openbsd-misc=160224393101534=2 > except I have a CHUWI HeroBox Windows 10 Mini PC,Intel Gemini-Lake N4100 > Quad-Core Processor,8GB DDR4 256GB SSD,Expandable 2TB 2.5 Inch HDD,1TB SSD > with 2.4GHz/5GHz Dual WiFi 1000Mbps/BT4.2 > https://www.amazon.com/gp/product/B082VZP76P > > On a 6.7 release I did syspatch and then a sysupgrade and got the entry > point at: 0x1001000 error trying to boot after the upgrade was successful. 6.8 kernel is larger and does not play well with EFI on your system. Can you try to patch efiboot.c as described in https://marc.info/?l=openbsd-misc=159401011632149=2 and see if it works on your system? It did help me on ASRock J4105M, but there are reports on the list that it does not work on some other systems, like Lenovo V130. Thanks, Kastus
6.8 release crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
I just wanted to report 6.8 release is having the same issue as https://marc.info/?l=openbsd-misc=160224393101534=2 except I have a CHUWI HeroBox Windows 10 Mini PC,Intel Gemini-Lake N4100 Quad-Core Processor,8GB DDR4 256GB SSD,Expandable 2TB 2.5 Inch HDD,1TB SSD with 2.4GHz/5GHz Dual WiFi 1000Mbps/BT4.2 https://www.amazon.com/gp/product/B082VZP76P On a 6.7 release I did syspatch and then a sysupgrade and got the entry point at: 0x1001000 error trying to boot after the upgrade was successful. -alfred
Re: OpenBSD UEFI on QEMU emulator
Kevin Shell wrote: > On Mon, Oct 26, 2020 at 08:46:55AM -0600, Theo de Raadt wrote: > > > > There are two versions of this code, for the small and large install media. > > > > /usr/src/distrib/amd64/ramdisk_cd > > > > /usr/src/distrib/amd64/iso > > > > Someone who wants this should do it. > > > I see the Makefile uses the GNU tool mkhybrid, > which does not support multiple el torito boot images, > why not use the BSD makefs that is in OpenBSD tree to create the iso file, > it supports multiple el torito boot images for both BIOS and UEFI, > FreeBSD does it this way. you are invited to make a diff, and then test your output file to ensure no regressions on a wide variety of machines.
Re: OpenBSD UEFI on QEMU emulator
On Mon, Oct 26, 2020 at 08:46:55AM -0600, Theo de Raadt wrote: > > There are two versions of this code, for the small and large install media. > > /usr/src/distrib/amd64/ramdisk_cd > > /usr/src/distrib/amd64/iso > > Someone who wants this should do it. > I see the Makefile uses the GNU tool mkhybrid, which does not support multiple el torito boot images, why not use the BSD makefs that is in OpenBSD tree to create the iso file, it supports multiple el torito boot images for both BIOS and UEFI, FreeBSD does it this way. -- kevin
acpidump: XSDT entry 24 is corrupt
6.8 GENERIC.MP#98 amd64 Just realized, I get an 'acpidump: XSDT entry 24 is corrupt' message before login prompt. This did not happen in 6.7. Attempted to do some searching and it left me confused. I flashed my bios to the latest version available. It did not help. Is this a firmware issue or acpi problem?
firefox-esr crashing on file save/upload
Hello, I'm having an issue with firefox. Every time I try and save an image or upload it to a website in firefox-esr, firefox crashes. I've found that waiting a bit before actually clicking "upload image" on a website or "save image" in the dialog that pops up when right clicking and saving and image helps sometimes, and when I save the image to quickly it definately crashes. I don't know if I need to allocate more resources to firefox or something, as I already added myself to staff and increased the allowed memory usage on login.conf . This happens on 6.8 release and on current (currently on 6.8-release), and has happened to me before on 6.7-release and 6.7-current. Thanks
for consideration: patch: feh(1) build without gtk, outside the ports tree
#?patch
#
# These patches, derived from the OpenBSD 6.6 ports tree (encumbered by
# their copyright!), enable installation of feh(1) 3.2.1 outside the
# ports tree, and without gtk.
#
# Me tried to make this a patch to ports, but some "clever" perl code in
# there decided that, since the feh tree contains an icon file, it must
# be dependent on gtk. grr.
#
# Built this way, feh(1) still requires the following prerequisites to
# run:
#
# graphics/imlib2
# graphics/libexif
# graphics/png
# net/curl
#
# To build: it also needs, at least:
#
# devel/gmake
#
# And finally, to test:
#
# devel/p5-Test-Command
#
# Take care,
#
# --zeurkous, Sat Oct 24 14:18:57 UTC 2020.
#
--- ..v/3.2.1/config.mk Mon Jul 22 18:26:34 2019
+++ config.mk Sat Oct 24 14:01:45 2020
@@ -4,9 +4,9 @@
app ?= 0
curl ?= 1
debug ?= 0
-exif ?= 0
+exif ?= 1
help ?= 0
-verscmp ?= 1
+verscmp ?= 0
xinerama ?= 1
# Prefix for all installed files
@@ -35,11 +35,7 @@
# default CFLAGS
CFLAGS ?= -g -O2
-CFLAGS += -Wall -Wextra -pedantic
-# Settings for glibc >= 2.19 - may need to be adjusted for other systems
-CFLAGS += -std=c11 -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700
-
ifeq (${curl},1)
CFLAGS += -DHAVE_LIBCURL
LDLIBS += -lcurl
@@ -102,3 +98,5 @@
-DPACKAGE=\"${PACKAGE}\" -DVERSION=\"${VERSION}\"
LDLIBS += -lm -lpng -lX11 -lImlib2
+
+LDFLAGS +=-L/usr/X11R6/lib/ -L/usr/local/lib/
--- src/..v/3.2.1/deps.mk Mon Jul 22 18:26:34 2019
+++ src/deps.mk Sat Oct 24 14:02:00 2020
@@ -6,7 +6,7 @@
filelist.o: filelist.c feh.h gib_hash.h gib_list.h gib_imlib.h \
gib_style.h structs.h menu.h utils.h getopt.h debug.h filelist.h \
signals.h options.h
-getopt.o: getopt.c
+getopt.o: getopt.c getopt.h
getopt1.o: getopt1.c getopt.h
gib_hash.o: gib_hash.c gib_hash.h gib_list.h utils.h debug.h
gib_imlib.o: gib_imlib.c gib_imlib.h gib_style.h gib_list.h utils.h \
--- src/..v/3.2.1/getopt.c Mon Jul 22 18:26:34 2019
+++ src/getopt.cSat Oct 24 13:57:06 2020
@@ -36,6 +36,7 @@
#endif
#include
+#include
/* Comment out all this code if we are using the GNU C Library, and are not
actually compiling the library itself. This code is part of the GNU C
Re: OpenBSD UEFI on QEMU emulator
Stuart Henderson wrote: > On 2020-10-24, Kevin Shell wrote: > > The OpenBSD .iso image file is not > > hybrid image(both BIOS/UEFI iso9660 and USB boot drive support), > > Linux, FreeBSD, NetBSD all produce hybrid iso images, > > OpenBSD produces a separate .img file, just choose the iso if you want an > iso, choose img if you want an image for a USB boot drive. > > Are you sure about NetBSD? I didn't check their ISO but they do provide > separate img files and there's no indication in the install guide that it > is hybrid. http://www.netbsd.org/docs/guide/en/chap-inst.html > > (Also, despite their hybrid iso, FreeBSD still sees the need to provide > a separate USB image). > > > I want to know why OpenBSD not do the same. :-) > > I guess nobody has seen enough benefit to changing things for it to be > worth spending the time A) implementing it (without using GPL tools) > and B) testing it on a wide variety of machines to make sure it doesn't > break something that currently works. > > B is the real problem of course. There are two versions of this code, for the small and large install media. /usr/src/distrib/amd64/ramdisk_cd /usr/src/distrib/amd64/iso Someone who wants this should do it.
Re: man netstart(8) OpenBSD-6.8
maybe a little less coffee ? :)
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Monday, 26 October 2020 10:16, Rachel Roch wrote:
> Re: submitting something. Theo has spoken and given his judgement. Theo
> decreed "no, it should not be there", thus I shall not be wasting my time
> submitting something that won't ever be accepted due to whatever weird reason
> Theo thinks a random half-baked description of what is going on with
> netstart(8) is acceptable.
>
> 25 Oct 2020, 13:44 by pi...@protonmail.com:
>
> > Rachel, you could submit something to be helpful if you like, fill the gap
> > that you see. Only 60 devs and most of the man page content is incredibly
> > up to date and valuable.
> > So I for one look forward to you adding your entry into the netstart man
> > page for community review.
> > Sent with ProtonMail Secure Email.
> > ‐‐‐ Original Message ‐‐‐
> > On Sunday, 25 October 2020 09:42, Rachel Roch rr...@tutanota.de wrote:
> >
> > > 25 Oct 2020, 01:25 by dera...@openbsd.org:
> > >
> > > > Rachel Roch rr...@tutanota.de wrote:
> > > >
> > > > > Is it just me or is the man entry for netstart(8) missing a reference
> > > > > to wg(4) ?
> > > >
> > > > ... and 300 other network interfaces.
> > > > In otherwords, no, it should not be there.
> > >
> > > OK smart alec, then why bother enumerating any of the non-physical
> > > interfaces on the man page ?
> > > Afterall, the man page does state at the head of the list "During the
> > > system boot, netstart is executed. netstart performs the following
> > > operations, in the sequence given".
> > > There is little point giving a half-assed description. Either you
> > > enumerate ALL the non-physical interfaces, or otherwise you treat them
> > > the same way as the physical ones ("Configure all the physical
> > > interfaces").
> > > Otherwise you are failing to explain what happens to any of your "300
> > > other interfaces". Enumerate or don't enumerate, I don't care ... but
> > > surely it is sensible to pay some reference to them.
> > > Sheesh !
Re: man netstart(8) OpenBSD-6.8
Re: submitting something. Theo has spoken and given his judgement. Theo
decreed "no, it should not be there", thus I shall not be wasting my time
submitting something that won't ever be accepted due to whatever weird reason
Theo thinks a random half-baked description of what is going on with
netstart(8) is acceptable.
25 Oct 2020, 13:44 by pi...@protonmail.com:
> Rachel, you could submit something to be helpful if you like, fill the gap
> that you see. Only 60 devs and most of the man page content is incredibly
> up to date and valuable.
> So I for one look forward to you adding your entry into the netstart man page
> for community review.
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Sunday, 25 October 2020 09:42, Rachel Roch wrote:
>
>> 25 Oct 2020, 01:25 by dera...@openbsd.org:
>>
>> > Rachel Roch rr...@tutanota.de wrote:
>> >
>> > > Is it just me or is the man entry for netstart(8) missing a reference to
>> > > wg(4) ?
>> >
>> > ... and 300 other network interfaces.
>> > In otherwords, no, it should not be there.
>>
>> OK smart alec, then why bother enumerating any of the non-physical
>> interfaces on the man page ?
>>
>> Afterall, the man page does state at the head of the list "During the system
>> boot, netstart is executed. netstart performs the following operations, in
>> the sequence given".
>>
>> There is little point giving a half-assed description. Either you enumerate
>> ALL the non-physical interfaces, or otherwise you treat them the same way as
>> the physical ones ("Configure all the physical interfaces").
>>
>> Otherwise you are failing to explain what happens to any of your "300 other
>> interfaces". Enumerate or don't enumerate, I don't care ... but surely it
>> is sensible to pay some reference to them.
>>
>> Sheesh !
>>
Re: man netstart(8) OpenBSD-6.8
In Sun we always got hammered for this especially among the 3rd party coops as the man pages never really had an real world examples, and if they were there they were poor, I would keep as many examples as you can as most learn from seeing-in-action, instead of being told how. I could explain process class priority configuration until my mind is numb but in the end without seeing the commands that would actually be used it is really making your life far harder. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, 25 October 2020 17:44, Theo de Raadt wrote: > Jason McIntyre j...@kerhand.co.uk wrote: > > > On Sun, Oct 25, 2020 at 10:16:54AM -0600, Theo de Raadt wrote: > > > > > Jason McIntyre j...@kerhand.co.uk wrote: > > > > > > > whereas /etc/netstart is actually doing: > > > > > > > > - configure non-physical: (1) > > > > aggr trunk svlan vlan carp pppoe > > > > > > > > - routing (2) > > > > - rest of non-physical: (3) > > > > tun tap gif etherip gre egre mobileip pflow wg > > > > > > > > > > > > we could try to keep this list up to date, but it may be easier to just > > > > generally describe what netstart is doing. > > > > > > I think we goes wrong by trying to maintain these as lists, and part of > > > where this goes wrong is weak definition of the reasons for the > > > ordering. (Meaning, the developers who tweak netstart to handle the > > > concerns I'm about to describe, don't tend to think about the manual > > > page). > > > The (1) list of non-physical can probably be called "link-layer control > > > interfaces". Or let's find a name for this. These devices mutate the > > > presentation of other devices. That's why their configuration needs to > > > be done before the physical device. > > > (2) The physical device is then brought up, including IP addressing. The > > > things in (1) need to be done beforehands, or the physical device is > > > participating in the wrong layer of network. > > > the (3) list of non-physical devices are layer-2 or layer-3 and operate > > > on devices which are already configured with some some sort of > > > "addressing" configured. > > > It would be nice to have our networking people come up with nice names > > > for group (1) and (2); words which succinctly describe the > > > classification like I've done above. We need to increase understanding > > > of this order, rather than just abstractly listing names of devices with > > > complicated behaviours. > > > Once that is done, I still think it is problematic for us to list all > > > devices in each catagory: > > > a) new subsystems will be forgotten > > > b) the order of instantiation will sometimes be listed wrong -- for some > > > of these the order is highly significant. > > > We can try to list as many as possible, but people who want the precise > > > list (and order) should look in the netstart code. The lists will get > > > long and wrong. If we find we cannot maintain the lists correctly > > > because it is duplicated information, man page wording like "such as" > > > could be used, also something which leads people to consider the script > > > source as authoritative, ie. have them go read the script > > > > ok, here is a start. > > i have left the description as "non-physical", because i think that is > > clear. we could easily amend it. ifconfig.8 create talks about "network > > pseudo-devices" - that could be a possibility. > > You've deleted all the interface names, so now there are no examples. > I disagree strongly. That creates a hurdle and people won't learn how > our network pieces are configured into a multi-layer stack.
Re: OpenBSD UEFI on QEMU emulator
On 2020-10-24, Kevin Shell wrote: > The OpenBSD .iso image file is not > hybrid image(both BIOS/UEFI iso9660 and USB boot drive support), > Linux, FreeBSD, NetBSD all produce hybrid iso images, OpenBSD produces a separate .img file, just choose the iso if you want an iso, choose img if you want an image for a USB boot drive. Are you sure about NetBSD? I didn't check their ISO but they do provide separate img files and there's no indication in the install guide that it is hybrid. http://www.netbsd.org/docs/guide/en/chap-inst.html (Also, despite their hybrid iso, FreeBSD still sees the need to provide a separate USB image). > I want to know why OpenBSD not do the same. :-) I guess nobody has seen enough benefit to changing things for it to be worth spending the time A) implementing it (without using GPL tools) and B) testing it on a wide variety of machines to make sure it doesn't break something that currently works. B is the real problem of course.
Re: Sound/audio onFirefox on 6.8
On Fri, Oct 23, 2020 at 03:58:55PM -0600, Duncan Patton a Campbell wrote:
>
> Hey Maurice. The audio works elsewhere and this looks to be
> a Zombie Bugzilla bug come back from the dead. Something
> about needing to directly link to sndio and skip the "cubeb" something...
>
> Dhu
>
> This is what shows up on the command line:
>
> dhu@gate:BSD $ firefox
>
Hi,
Could you check /dev permissions? they need to be as follows:
$ ls -al /dev/{audio,audioctl,rmidi}0
crw-rw 1 root _sndiop 42, 0 Oct 26 07:23 /dev/audio0
crw-rw 1 root _sndiop 42, 192 Oct 19 12:20 /dev/audioctl0
crw-rw 1 root _sndiop 52, 0 Oct 19 12:20 /dev/rmidi0
The /etc/firefox/unveil.* settings need to contain permission
to access ~/.sndio contents:
$ grep sndio /etc/firefox/*
/etc/firefox/unveil.content:~/.sndio rwc
/etc/firefox/unveil.main:~/.sndio rwc
If above are OK, then run firefox with SNDIO_DEBUG=1 environment
variable exported and show the resulting output, it will reveal why
firefox still can't use the device.
