I'm seeing this this morning on both 12.0-CURRENT systems
(running drm-next kernel), and I see 1 other report on IRC. As
presumably this will be fixed in due course, this is a heads up
to let other people searching that they are not alone in their
misery.
```
# pkg update
Updating FreeBSD
On Sun, 18 Dec 2016, at 10:07, blubee blubeeme wrote:
> Hi
>
> I am on a Macbook pro 11,3 and I wanted to start trying to help sort out
> some problems that might be too small for the overall team but might help
> others in the future.
\o/ there are a few of us about, I'm using a MacBookPro
On Wed, 21 Dec 2016, at 06:39, blubee blubeeme wrote:
> Can I bump this issue one more time?
>
> On Sun, Dec 18, 2016, 18:38 Dave Cottlehuber <d...@skunkwerks.at> wrote:
>
> > On Sun, 18 Dec 2016, at 10:07, blubee blubeeme wrote:
> > > Hi
> > >
>
oesn't get built afaict.
>
> Hi Pete,
> I submitted your patch as r324470.
> Take care!
> -Ngie
> _______
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>
I'm seeing this repeatedly in the last ~ 2 weeks, present in r326363
and typically panics 1-15m post boot since this weekend's update. I'm
currently bisecting my way back; it looks like its not in r325755, but I
can't be sure for a few more hours.
On Mon, 4 Dec 2017, at 01:24, Ryan Stone wrote:
> Please update to r326376 or later. That will likely fix you issue.
>
Indeed it does -- thanks!
A+
Dave
___
freebsd-current@freebsd.org mailing list
[cross-posting for advice on general debugging + network-specific thoughts]
TLDR since a week or so, probably around r335381 I can reliably get my machine
to hang*** by unloading pf, while there's network traffic (e.g. video streaming
or rsync) and waiting a minute or two I still see it with
On Mon, 25 Jun 2018, at 23:08, Dave Cottlehuber wrote:
> [cross-posting for advice on general debugging + network-specific thoughts]
The HPET NMI watchdog patch was very timely - works a treat:
https://reviews.freebsd.org/D15630
> However each time there's no crashdump, & the usual ct
f it's something the FreeBSD Foundation might consider jointly
supporting,
I would help with the paperwork & submission.
A+
Dave
—
Dave Cottlehuber
+43 67 67 22 44 78
Managing Director
Skunkwerks, GmbH
http://skunkwerks.at/
ATU70126204
Firmenbuch 410811i
_
# info
- 100% reproducible on starting a bhyve-based vm
- recent current r329611, also panics at r329531
- GENERIC + WITH_CTF=1 and DEBUG=-g
- built WITH_META_MODE=yes & CCACHE_BUILD=yes
# panic dmesg
[36984] panic: mtx_lock_spin: recursed on non-recursive mutex vcpu lock @
On Thu, 22 Feb 2018, at 14:41, tech-lists wrote:
> On Thu, Feb 22, 2018 at 03:10:17AM -0800, Jack L. wrote:
> >maybe try a clean buildworld, update /usr/src to the latest version, rm -rf
> >/usr/obj, then make buildworld && make installworld && make kernel and see
> >if that fixes the issue?
>
>
> On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen
> > > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote:
> > >> I've been personally using the new DRM bits since almost day one. I
> > >> haven't found it to be unstable in the slightest. Compared to not
> > >> having it and being forced to run 5+
On Tue, 17 Apr 2018, at 02:17, Wes wrote nothing.
Wes,
Can you share some info?
Which architecture
boot method uefi mbr …
Which iso / img specifically
Fresh install or upgrade?
Relevant loader.conf settings
Your dmesg on a prior snapshot
Expand on won’t boot - start at system POST and explain
On Fri, 19 Oct 2018, at 19:46, Mike Tancsa wrote:
> Feeding entropy: .
> lo0: link state changed to UP
> sendmsg on igb0: No buffer space available
> igb0: link state changed to UP
> cxl1: link state changed to UP
> Starting Network: lo0 igb0 cxl0 cxl1.
I’m reasonably sure that this occurs when
Manual root filesystem specification:
—
Dave Cottlehuber
+43 67 67 22 44 78
Managing Director
Skunkwerks, GmbH
http://skunkwerks.at/
ATU70126204
Firmenbuch 410811i
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/lis
On Wed, 2 Sep 2020, at 21:01, Navdeep Parhar wrote:
> Load cryptodev manually from the loader to boot and then add
> cryptodev_load="YES" to your loader.conf.
Hi Navdeep
that was it - thanks! crisis averted.
A+
Dave
—
O for a muse of fire, that would ascend the brightest heaven of invention!
On Thu, 3 Sep 2020, at 06:48, Andriy Gapon wrote:
> On 03/09/2020 00:01, Navdeep Parhar wrote:
> > Load cryptodev manually from the loader to boot and then add
> > cryptodev_load="YES" to your loader.conf.
>
> I think that this shouldn't be needed *if* zfs module has a dependency on
> cryptodev
On Wed, 17 Jun 2020, at 17:52, Rodney W. Grimes wrote:
> > Rodney W. Grimes wrote:
> > > > The "fake cd drive" is in the kernel, loader just copies the iso into
> > > > memory like any other module, and by the time that's done you just
> > > > reboot into the newly installed system, which again
On Wed, 31 Mar 2021, at 09:00, Mathieu Chouquet-Stringer wrote:
> On Tue, Mar 30, 2021 at 03:43:06PM +0200, Mathieu Chouquet-Stringer wrote:
> > Hello,
> >
> > TL;DR: we need kvmclock support in FreeBSD
>
> scan: scrub repaired 0B in 12:33:11 with 0 errors on Wed Mar 31 03:33:14
> 2021
>
On Tue, 7 Sep 2021, at 13:51, David Chisnall wrote:
> One of the things I'd love to prototype if I had time is a CMake-based
> build system for FreeBSD so that we could get all of the tooling
> integration from the compile_commands.json, reuse LLVM's (and any other
> contrib things that use
On Mon, 9 Aug 2021, at 15:54, Gary Jennejohn wrote:
> Maybe his problem arises from use of /dev/gpt/swap? That's a difference
> between his setup and your setup.
good point, after amending fstab and checking gpt labels carefully, it still
works ok for me:
root@a01 /u/h/dch# gpart show
=>
On Mon, 9 Aug 2021, at 06:54, Gary Jennejohn wrote:
> On Sun, 8 Aug 2021 18:01:18 -0400
> Daniel Morante via freebsd-current wrote:
> > It looks though that this issue might only happen on arm64? I tried
> > to reproduce on amd64 without any luck.
seems fine on arm64 14.0-CURRENT to me, this is
On Thu, 27 Jan 2022, at 21:34, Ed Maste wrote:
> The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA)
> which accepts mail from a local Mail User Agent (MUA) and delivers it
> locally or to a smarthost for delivery. dma does not accept inbound
> mail (i.e., it does not listen on
On Thu, 12 May 2022, at 07:12, Michael Schuster wrote:
> On Wed, May 11, 2022 at 11:38 PM Dave Cottlehuber wrote:
>> On Wed, 11 May 2022, at 14:58, Michael Schuster wrote:
>> > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only
>> > regular files and
On Mon, 9 May 2022, at 06:25, Michael Schuster wrote:
> On Fri, May 6, 2022 at 12:15 AM Wes Maag wrote:
>>
>>
>> On Thu, May 5, 2022 at 4:10 PM Michael Schuster
>> wrote:
>>> Hi all,
>>>
>>> while still working (slowly) on an answer to my own question on the
>>> right workflow to keep
On Wed, 11 May 2022, at 16:20, Cristian Cardoso wrote:
>
> But since the command doesn't support -y no -not-running-from-cron for
> the upgrade command, I believe everything is stalling on this question
> and the playbook has no proceeding and it stays on this question below:
>
> `The following
On Wed, 11 May 2022, at 14:58, Michael Schuster wrote:
> I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only
> regular files and empty directories). Booting into that BE didn't work
> either, I got errors about missing "/dev/" files (can't recall the
> exact names).
>
> What do
On Sat, 15 Oct 2022, at 20:57, Patrick Bowen wrote:
> On Sat, Oct 15, 2022, at 6:52 AM, Graham Perrin wrote:
>> On 14/10/2022 18:53, Pete Wright wrote:
>>>
>>> On 10/14/22 10:14, Patrick Bowen wrote:
Hello all,
I've just used reinstall.sh to add a CURRENT boot environment to a
On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:
> TL;DR: The implementation of system calls is moving to a seperate
> library (libsys). No changes are required to existing software (except
> to ensure that libsys is present when building custom disk images).
>
> Code:
29 matches
Mail list logo
