I'm just getting back into FreeBSD development, and I'm trying to focus
on (U)EFI work.
It seems there are various things that people would like to have done,
some of which are listed on
https://wiki.freebsd.org/DevSummit/201806/HaveNeedWant12 - and some of
which I know are already being worked on
On 9/16/18 9:32 PM, Warner Losh wrote:
>
> What did you have in mind working on? I have a few things that are in
> various stages of completeness around this issue that I've not had
> time to polish off for the tree. Some I'd like to, but some may
> benefit from a fresh perspective. Also, there's
On 9/18/18 4:11 AM, Greg V wrote:
>
> I can confirm that the kernel already worked fine when booted from
> 32-bit EFI.
>
> I booted an old Mac into HardenedBSD using a 32-bit-EFI build of GRUB2 :)
Was that a 64-bit version of FreeBSD? My understanding is the 32-bit
FreeBSD boots fine, but 64-bit
On 9/19/18 9:06 AM, Rodney W. Grimes wrote:
Yes, that is one of the catagories of rare, a EFI-32 bit system that
was originally shipped with a 32 bit only CPU, that later got upgraded
in the field with a 64 bit CPU, that still runs a EFI-32 bios.
Are you sure the 2007 firmware is EFI32? I woul
On 9/19/18 3:53 AM, Greg V wrote:
Yes, of course it was 64-bit.
I don't think I ever downloaded the 32-bit one...
And are you sure it was booted via EFI and not the BIOS emulation CSM
(Compatibility Support Module)? I'm fairly sure we _don't_ support
booting a 64-bit kernel from 32-bit EF
On 9/19/18 5:13 PM, Ed Maste wrote:
The Minnowboard Turbot has an Atom E3826, and has four precompiled
Tianocore UEFI firmware releases available: 32 and 64 bit in release
and debug builds. It's probably the most approachable development
platform for UEFI work on FreeBSD.
Oh, that's a really
On 9/21/18 4:06 PM, Mark Johnston wrote:
>
> https://reviews.freebsd.org/D17279 for anyone else that would like to
> review.
Is that possibly related to the error I'm getting trying to build
-CURRENT on 11.2?
make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
amd64 libc req
On 9/21/18 9:09 PM, Warner Losh wrote:
> On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
> freebsd-toolch...@freebsd.org> wrote:
>
>> On 9/21/18 4:06 PM, Mark Johnston wrote:
>>> https://reviews.freebsd.org/D17279 for anyone else that would lik
On 9/21/18 9:35 PM, Warner Losh wrote:
>
> I meant to add, can you give a few lines before the error is spewed
> here in email? My IRC computer died before I could see any answers
> there...
>
> My 11.2-stable system has 6.0.1, so I can't test from there.
I've uploaded the full 'buildworld' outpu
On 9/21/18 9:34 PM, Warner Losh wrote:
> What does ld.lld say?
>
> However, it shouldn't matter: we don't build libc until *AFTER* we
> build ld.lld, so this error is bogusly triggering. I suspect that it
> needs to be limited to only building targets, since tree traversal
> ones, as well as inst
On 9/21/18 9:57 PM, Warner Losh wrote:
> Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
>
> They look good for me, but the only way you get this error is if they
> are wrong.
bcran@cube:~/workspace/freebsd % make -V LINKER_TYPE
bfd
bcran@cube:~/workspace/freebsd % make -V
On 9/21/18 10:00 PM, Warner Losh wrote:
> That may be the issue... Does the patch I included help? I'm building now
> on my stable system, but it's slow...
It does seem to have got further this time, so a cautious yes.
--
Rebecca
___
freebsd-curren
On 9/21/18 10:10 PM, Rebecca Cran wrote:
> On 9/21/18 10:00 PM, Warner Losh wrote:
>
>> That may be the issue... Does the patch I included help? I'm building now
>> on my stable system, but it's slow...
>
> It does seem to have got further this time, so a caut
tal, 4169M MFU, 497M MRU, 172K Anon, 97M Header, 471M Other
3479M Compressed, 5930M Uncompressed, 1.70:1 Ratio
Swap: 2048M Total, 2009M Used, 39M Free, 98% Inuse
I've not seen this happen before on ZFS systems, so is it a regression
in 12?
--
Rebecca Cran
___
On 9/27/18 9:00 PM, Allan Jude wrote:
>
> It doesn't appear like ZFS is dominating memory usage there. Using less
> than the 8GB you indicated that setting the max to solved the problem...
Yeah, I'm not sure how that works.
--
Rebecca
___
freebsd-cu
On 10/6/18 6:40 AM, Greg V wrote:
>
> BTW, this error message doesn't say much, but if cargo fails, you
> might be out of memory.
I was going to suggest being out of memory too. I've seen the rust build
cause my system to run out of all 32GB RAM and 2GB swap.
nal 11 (core dumped)
Oct 9 22:41:00 tau kernel: pid 62612 (firefox), uid 1001: exited on
signal 11 (core dumped)
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send a
I noticed a warning on a new AMD system running 12-BETA1:
non-PNP ISA device will be removed from GENERIC in FreeBSD 12.
It looks like it was introduced by Warner in r327120. Should those devices have
been removed already?
—
Rebecca
___
freebsd-
On 10/25/18 5:02 AM, Rodney W. Grimes wrote:
Can you please reply with the specific device.
If you have seen one it may be an issue to removing it,
especially if this is on a "new AMD" system.
This is a new Ryzen system. For me, I get warnings about atkbdc0 and uart0:
atkbdc0: at port 0x60
On 10/25/18 10:00 AM, Warner Losh wrote:
I suspect you can just lose those hints in the hints file and be fine. The
uart should attach via acpi. The keyboard won't, however, since it isn't
enabled. Can you try removing these lines from your hints file and see if
the problem persists? Note this
On 10/25/18 10:18 AM, Warner Losh wrote:
That seems incorrect. It looks like we're attaching too much. what does
devinfo -v | grep uart tell you?
uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0
uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR1
uart2 pnpinfo _HID=AMD
On 10/25/18 10:20 AM, Rebecca Cran wrote:
uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0
uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR1
uart2 pnpinfo _HID=AMDI0020 _UID=2 at handle=\_SB_.FUR2
uart3 pnpinfo _HID=AMDI0020 _UID=3 at handle=\_SB_.FUR3
Also, in
On 10/25/18 10:46 AM, Warner Losh wrote:
Oh! that looks mostly right, though IIRC the higher UIDs might be
something else. Harmless enough for now, though.
Thanks.
I also think you might be able to test if we can remove a special case
kludge we have for the AMDI0020 device since it look
After installing 12.0-BETA1, on the first boot I noticed a warning about
$local_unbound_tls not being set properly.
It looks like that flag was only added recently by Dag-Erling, in "Add
support for DNS-over-TLS to the local_unbound service."
--
Rebecca
_
On 10/26/18 10:48 AM, Dag-Erling Smørgrav wrote:
Rebecca Cran writes:
After installing 12.0-BETA1, on the first boot I noticed a warning
about $local_unbound_tls not being set properly.
Ah, I should probably have added it to /etc/defaults/rc.conf. Can you
do that (just set it to “no”) and
When booting a recent 13-CURRENT installation, I’m seeing the following:
Startup error in /boot/lua/loader.lua:
LUA ERROR: /boot/lua/loader.lua:45: error loading module ‘local’ from file
‘/usr/local/lib/lua/5.3/local.so’:
dynamic libraries not enabled: check your Lua installation.
I then ha
On 10/27/18 10:34 AM, Kyle Evans wrote:
Hmm... something's definitely amiss here- there's no reason this
should be munging through /usr/local/... at all- it's not in the
LUA_PATH. I'd be interested in knowing if there's anything funky about
your build or run setup- I have lua53 installed, but I
On a normal boot (not verbose) of -CURRENT from today's sources I'm
getting the following message printed once for each logical CPU:
arc4random: no preloaded entropy cache
Since other messages, including the same one in random_harvestq.c are
under bootverbose, should this one in arc4random.c
I'm currently working on creating and updating the ESP (EFI System Partition)
for UEFI booting during installation and installworld.
During installation, with my changes it gets mounted on /boot/efi and
loader.efi
copied into /boot/efi/EFI/FreeBSD and /boot/efi/EFI/BOOT. An entry gets added
t
On Sunday, 4 November 2018 14:25:26 MST Allan Jude wrote:
> I wouldn't depend on the /etc/fstab entry existing. I am not sure I want
> installworld randomly fobbing around in my EFI partition. Especially if,
> for example, my EFI/BOOT is not FreeBSD, but rEFInd or something.
I tend to agree. I ha
On Sunday, 4 November 2018 14:36:13 MST Toomas Soome wrote:
> it is reasonable to have efi/freebsd directory, the efi/boot/bootx64.efi is
> hard one of course. But then again, it is problem only when we can not
> setup EFI bootmanager variables ? the bootx64.efi is default when bootmgr
> is not se
On Sunday, 4 November 2018 15:56:25 MST Warner Losh wrote:
> I think that's a really really bad idea. We should *NEVER* create them by
> default. We are only sliding by on the coat-tails of compatibility by using
> efi/boot/boot*.efi. We shouldn't use those at all, unless there's a
> compelling re
On Sunday, 4 November 2018 16:07:17 MST Warner Losh wrote:
> Finally, I have a /dev/efi/esp pseudo label support coded up for geom
> (along with /dev/efi/boot for the putative root device). There's some
> issues with it, so I set it aside some time ago to work on other higher
> priority things. We
On Tuesday, 13 November 2018 18:57:25 MST Kyle Evans wrote:
> However, because loader-land is funny in a not-ha-ha kind of way, can
> you try replacing loader.efi on your guest VM with the Forth-flavored
> version to rule that out or narrow it down, please?
That didn't help.
As probably expected,
On Tuesday, 13 November 2018 16:20:22 MST Stefan Ehmann wrote:
> The 2700 has an offset of 0 though (2700X has 10).
> And I'm seeing a difference of more than 30 degrees. I guess something
> else must be happening here.
I had thought 54 was the right offset for my 2990WX system, but now it's unde
On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote:
> Maybe it should be -54 instead of +54? 183-(54*2) is the somewhat
> plausible 75?C (still pretty warm even for load). How good is your
> cooling solution?
D'oh, of course it's -54 instead of +54 (For some reason I presumed a positi
On Tuesday, 13 November 2018 21:41:58 MST Conrad Meyer wrote:
> You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL?
> I.e., sometimes the CPU chooses to report on a range from 0-225C and
> sometimes -49C-206C. I think someone else's 2990WX did the same
> thing. I guess that pa
On November 14, 2018 at 2:18:04 PM, Subbsd
(sub...@gmail.com(mailto:sub...@gmail.com)) wrote:
>
> My current host: FreeBSD 13.0-CURRENT r340319 and the problem is
> still present.
Rod was asking about the guest OS version, not the host though.
__
On Wednesday, 14 November 2018 19:56:56 MST Warner Losh wrote:
> What is the ConOut evifar look like? We set serial when the UEFI env says
> to do so.
Booting with:
sudo bhyve -A -P -c 2 -H -m 4G -s 0:0,hostbridge -s 31:0,lpc -s 2,ahci-
cd,FreeBSD-12.0-BETA4-amd64-disc1.iso -s
29,fbuf,tcp=0.0.
On Wednesday, 14 November 2018 12:41:53 MST Stefan Ehmann wrote:
> On 11/14/18 5:41 AM, Conrad Meyer wrote:
> > Ok I'll go ahead and commit that too.
>
> Applied to 12.0-BETA, Ryzen 7 2700 values are now in the 30-55C range.
> Looks reasonable.
Much better here, too:
dev.amdtemp.3.core0.sensor0
On Saturday, 17 November 2018 09:29:34 MST Subbsd wrote:
> Thus, perhaps the root of this problem should be sought in
> uefi-edk2-bhyve the package. Latest CBSD release (12.0.1) fixed this
> problem by disabling serial console. However, CBSD uses an alternative
> boot method for bhyve ( uefi-edk2
I know booting from the cd/dvd iso worked fairly recently, but today booting a
new build of -CURRENT in a Qemu VM resulted in a panic:
FreeBSD 13.0-CURRENT 19a6ceb89db(HEAD) GENERIC amd64
FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM
7.0.1)
WARNING: WITNESS option en
On Thursday, 20 December 2018 18:28:45 MST Kirk McKusick wrote:
> Thanks Rebecca for the report and Mark for the analysis of the problem.
> This should be fixed in -r342290.
Thanks! That did fix it.
--
Rebecca
___
freebsd-current@freebsd.org mailing
be added to loader to continue to parse it, or if loader.conf can be
considered the correct place and boot.config forgotten about?
—
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To
> Which change is that ?
The change is https://svnweb.freebsd.org/base?view=revision&revision=342283 .
--
Rebecca Cran
signature.asc
Description: This is a digitally signed message part.
On Thursday, 17 January 2019 20:02:46 MST David Wolfskill wrote:
> Does the above only apply to UEFI booting, or also to booting from
> BIOS/MBR?
It's only for UEFI booting.
--
Rebecca Cran
signature.asc
Description: This is a digitally signed message part.
On January 19, 2019 at 2:52:28 AM, Lev Serebryakov
(l...@freebsd.org(mailto:l...@freebsd.org)) wrote:
> I have never seen such item in BIOS Setup. I've checked two MoBos now (one is
> Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC
> like Intel NUK): both have one kno
UEFI doesn't care about disks and partitions: it only really knows
about ESPs -- FAT12/16/32 formatted partitions that contain the EFI directory
structure. For now, that means /EFI/BOOT/BOOT{x64,i386,aa64,arm}.efi, the
Microsoft boot loader in /EFI/Microsoft and GRUB/shim in /EFI/fedora, /E
I’ll take a look later today, since it’s likely related to my changes.
—
Rebecca
On January 26, 2019 at 6:43:49 PM, Yuri Pankov
(yur...@yuripv.net(mailto:yur...@yuripv.net)) wrote:
> Hi,
>
> Looks like installations from snapshot memstick images (tried all
> available ones for amd64 from
photon kernel: uhub0: <0x1022 XHCI root HUB, class 9/0, rev
3.00/1.00, addr 1> on usbus0
Feb 12 01:00:26 photon kernel: uhub0: 22 ports with 22 removable, self powered
Feb 12 01:00:28 photon kernel: xhci0: Resetting controller
—
Rebecca Cran
___
fre
That works, thanks.
Rebecca
On February 12, 2019 at 1:24:15 AM, Hans Petter Selasky
(h...@selasky.org(mailto:h...@selasky.org)) wrote:
> The USB timeout error might indicate an IRQ issue.
>
> Can you try setting:
>
> hw.usb.xhci.use_polling=1
>
> In /boot/loader.conf and reboot.
>
> --HPS
On 2/11/19 12:18 PM, Rebecca Cran wrote:
I’ll take a look later today, since it’s likely related to my changes.
On January 26, 2019 at 6:43:49 PM, Yuri Pankov
(yur...@yuripv.net(mailto:yur...@yuripv.net)) wrote:
Looks like installations from snapshot memstick images (tried all
available
this time
with a mapkey whose value is zero since it never attempts to fetch the
memory map. I'm guessing that subsequently causes the exec to fail.
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailm
c()
trap_fatal()
trap_pfault()
trap()
calltrap()
--- trap 0xc
_thread_lock()
pmap_delayed_invl_start_u()
pmap_remove()
kmem_bootstrap_free()
preload_delete_name()
linker_file_unload()
linker_preload()
mi_startup()
btext()
Uptime: 1s
--
c()
trap_fatal()
trap_pfault()
trap()
calltrap()
--- trap 0xc
_thread_lock()
pmap_delayed_invl_start_u()
pmap_remove()
kmem_bootstrap_free()
preload_delete_name()
linker_file_unload()
linker_preload()
mi_startup()
btext()
Uptime: 1s
--
On 2019-05-18 02:55, Konstantin Belousov wrote:
> Try this instead. I will revert r347931 after this landed, or could keep
> it alone.
That works - thanks!
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freeb
tches can be found at:
https://reviews.freebsd.org/D20642
https://reviews.freebsd.org/D20643
There's a good guide to setting up the DHCP and HTTP servers at
https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup .
--
Rebecca Cran
signature.asc
Description: OpenPGP digital signature
hing to be added
as a boot option by default? I plan to import the shim into the tree
sometime so that we too can automatically recreate boot manager entries
if they're deleted.
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https:
7;t damage anything but did require that I go reset the UEFI default
> to boot the Refind EFI loader instead of the Windows one.
I do like that rEFInd knows about FreeBSD, and it's one of the "UEFI OS"
entries that remains. But I'd prefer it if a
x27;m talking
about systems without rEFInd, using only the default OEM supplied system
firmware, since we can't rely on everyone having rEFInd installed.
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mai
On 2019-06-25 13:57, Guido Falsi wrote:
>
> I'm having thee same issue. UEFI system, ZFS on root, two mirrored disks.
>
> Reverting 349349 fixes it.
Sorry, that was my commit. I'm debugging it now.
--
Rebecca Cran
___
freeb
KDB: stack backtrace:
db_trace_self_wrapper()
...
--- trap 0xc, rip = 0x811bc664, rsp = 0x8441faa0, rbp =
0x8441fae0 ---
native_start_all_aps()
cpu_mp_start()
mp_start()
mi_startup()
--
Rebecca Cran
___
freebsd-current@freebsd.or
On 2019-08-24 14:33, Konstantin Belousov wrote:
> On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote:
>> instruction pointer = 0x20: 0x811bc664
> So what is the source line for this address ?
I built a new kernel and got a new panic instruction pointe
dress=0x0001
Length=0x000f8000
Proximity Domain=0
Type=Memory
Flags={ENABLED}
Base Address=0x00108000
Length=0x0010
Proximity Domain=2
--
Rebecca Cran
___
freebsd-current@freebsd.org mai
not. In order
to go from one of these cores to main memory, it requires an extra hop,
which adds latency. When all the cores are requesting access, this
causes congestion."
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists
/src/sys/vm/vm_domainset.c" starts at address
0x80f10267
and ends at 0x80f1027f .
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
_iter_page_init()
vm_page_grab_pages()
vm_thread_stack_create()
kstack_import()
uma_zalloc_arg()
vm_thread_new()
thread_alloc()
kthread_add()
vm_pageout()
fork_exit()
fork_trampoline()
--
Rebecca Cran
___
freebsd-current@freebsd.org mai
On 2019-08-25 10:55, Mark Johnston wrote:
>
> Can you please try applying this patch as well?
Thanks, that fixed the panic and allows the system to fully boot again.
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
use us to reconsider.
--
Rebecca Cran
___
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"
7;m not convinced this is something that's about older systems, and that
will go away.
--
Rebecca Cran
___
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"
> On Aug 26, 2019, at 11:43 PM, Toomas Soome wrote:
>
> For me it is still confusing if this is path versus upper-lower capital
> chars.
>
> If that vendor is using suggestion from UEFI Spec 2.7A section 3.5.1.1 (page
> 91), then the file name should also end with .EFI. (and yes, I know, th
imer "LAPIC" quality 600
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 64 CPUs
FreeBSD/SMP: 1 package(s) x 4 groups x 2 cache groups x 4 core(s) x 2
hardware threads
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing
On 2019-08-28 13:50, Konstantin Belousov wrote:
>
> Try https://reviews.freebsd.org/D21418
Thanks! That fixed it.
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsub
^~~
jemalloc_malloc_io.c:410:2: error: case label value exceeds maximum
value for type [-Werror]
410 | case 'z' | 0x80: \
| ^~~~
jemalloc_malloc_io.c:595:5: note: in expansion of macro 'GET_ARG_NUMERIC'
595 | GET_ARG_NUMERIC(val, 'p');
| ^~~
cc
.
Thanks. I kept running into build errors with gcc 8 and 9 (even with
WERROR= in src.conf), but building with gcc 6 from the amd64-gcc port
worked.
--
Rebecca Cran
___
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"
On 2019-09-18 09:01, Yuri Pankov wrote:
>
> Any hints on debugging this further?
Are you running ESXi 6.7 Update 2? Or, what version of ESXi are you
using that has the problem?
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
Map/ExitBootServices
loop in bi_load_efi_data.
--
Rebecca Cran
___
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"
On 2019-09-18 18:36, Rebecca Cran wrote:
>
> So far, it looks to be a problem with the GetMemoryMap/ExitBootServices
> loop in bi_load_efi_data.
So, it's crashing when we call BS->ExitBootServices. Of course, the
problem isn't really _in_ that code (it hasn't changed si
hat point. I've
found it gets to the point of executing the kernel and then crashes.
I've had it booting a couple of times by setting console=comconsole, but
I'm not sure if that's relevant.
--
Rebecca Cran
___
freebsd-curren
0/14_0_CURRENT_AMD64_CD MBR (1.0G)
17 544157 - free - (1.0G)
--
Rebecca Cran
only thing that's changed recently is installing Windows
Server 2022 on a different disk.
If I disable the mrsas controller, installation proceeds.
--
Rebecca Cran
On 5/4/23 19:02, Rebecca Cran wrote:
I'm seeing a panic during install during the zfs probing on the
14-CURRENT 20230504
ed to boot FreeBSD from the BOSS-1 drive (NVMe) so I
worked around it by disabling the mrsas controller during install then
re-enabling it later.
I'll open a bug report so the details don't get lost.
--
Rebecca Cran
On 5/15/23 07:17, Rebecca Cran wrote:
I'll open a bug report so the details don't get lost.
I've created https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271438 .
--
Rebecca Cran
ed
Sanitize NDI: Not Supported
Sanitize NODMMAS: Undefined
Controller ID: 0x0041
Version: 1.3.0
--
Rebecca Cran
On 6/8/23 00:24, Warner Losh wrote:
PCIe 3 or PCIe 4?
PCIe 4.
nda0 at nvme0 bus 0 scbus0 target 0 lun 1
nda0:
nda0: Serial Number S55KNC0TC00168
nda0: nvme version 1.3 x8 (max x8) lanes PCIe Gen4 (max Gen4) link
nda0: 6104710MB (12502446768 512 byte sectors)
--
Rebecca Cran
It's ZFS, using the default options when creating it via the FreeBSD
installer so I presume TRIM is enabled. Without a reliable way to
reproduce the error I'm not sure disabling TRIM will help at the moment.
I don't think there's any newer firmware for it.
--
Rebecca Cr
On 6/8/23 05:48, Warner Losh wrote:
On Thu, Jun 8, 2023, 4:35 AM Rebecca Cran wrote:
It's ZFS, using the default options when creating it via the FreeBSD
installer so I presume TRIM is enabled. Without a reliable way to
reproduce the error I'm not sure disabling TRIM wi
This also happens on Qemu with UEFI.
—
Rebecca
(Apologies for top posting, I’m replying on my phone)
On August 14, 2018 at 10:04:53 AM, Michael Tuexen
(tue...@freebsd.org(mailto:tue...@freebsd.org)) wrote:
> Dear all,
>
> r337761 panics on boot with a GENERIC kernel on a EPYC system:
>
>
led
moused, Xorg found and used it.
--
Rebecca Cran
___
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"
directory.
You most likely have a USB mouse, while the default is (still! why?) for
a PS/2 style mouse. So you probably need to set moused_port="/dev/ums0"
in /etc/rc.conf .
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing
t.
Perhaps I just need to come up with a proof of concept or demo to show
that it is possible without breaking other OSes.
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To un
to embed a better version string to determine that it's
our bootx64.efi _and_ for a version of FreeBSD that we're wanting to update.
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/fre
do users mount the ESP and update loader.efi on it?
So it seems it rarely _needs_ to be updated at the moment.
—
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, s
der fetches and runs the kernel over HTTP -- and then
you need to use NFS to mount the filesystem (or have a local root
filesystem).
UEFI also has RamDisk support, but I don't think that's for remote
ISO/disk files, just local files.
--
Rebecca Cran
__
> On Jun 17, 2020, at 11:40 AM, Rodney W. Grimes
> wrote:
>
> Does FreeBSD kernel have a driver that can talk to the UEFI ramdisk?
I’m fairly sure UEFI generates it as a standard CD drive.
—
Rebecca Cran
___
freebsd-current@freebsd
Virtual Disk and Virtual CD (ISO image) in persistent or
volatile memory”
—
Rebecca Cran
___
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"
p under FreeBSD. I'm not sure if there's a way to access them via
UEFI Runtime Services or if it's designed purely as a boot-time thing.
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/
dk2/commit/f159102a130fac9b416418eb9b6fa35b63426ca5),
but still need to get CSM support working again before we can switch
everyone over from the UDK2014.SP1 build to the newer code.
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.o
On 6/22/2020 10:12 AM, Warner Losh wrote:
I believe so. However, I've not dived deeply enough into this problem to
understand if it is a bug in our code or theirs.freebsd.org"
As I've said before, at least under bhyve it's a bug in the UEFI
firmware that we currently use.
On 6/22/2020 6:18 PM, Warner Losh wrote:
On Mon, Jun 22, 2020 at 6:18 PM Rebecca Cran <mailto:rebe...@bsdio.com>> wrote:
On 6/22/2020 10:12 AM, Warner Losh wrote:
> I believe so. However, I've not dived deeply enough into this
problem to
> understand i
1 - 100 of 111 matches
Mail list logo
