On Thu, Nov 18, 2021 at 06:31:21AM -0300, André Pfeiffer wrote:
> Hello everyone,
>
> Some months ago I sent some messages about not being able to set up
> DragonflyBSD. With the new version launched I was able to boot the
> installer for the first time ever on my computer! This made me very
Yes indeed. Furthermore we'll commit it to the development version and
probably cherry-pick it to the latest release, too.
On 15/11/21 16:47, Krzysztof Piecuch wrote:
Hi Oleg,
is there any chance of getting this in the upcoming 6.1-RELEASE?
6.1 is our current developement version, we use
Hi Oleg,
> is there any chance of getting this in the upcoming 6.1-RELEASE?
6.1 is our current developement version, we use even numbers for
releases and odd for developement work.
I don't think there's 6.2 release date scheduled yet so probably
anything merged will make it to the 6.2 release.
Hi,
On Sat, Nov 13, 2021 at 1:21 AM Antonio Huete Jimenez
wrote:
> The sub-task specific for this request will be:
>
> https://bugs.dragonflybsd.org/issues/3306
>
> We'll check and see if we can add it soon!
Thanks for taking the time to take care of this! I have already tested
the current
Hi Oleg,
On 12/11/21 16:42, Oleg Ginzburg wrote:
Hi,
Aaron LI's recent work on 'NVMM' virtualization seemed very
interesting to me. I would like to port the CBSD[1] for QEMU/NVMM to
DragonFly but ran into a lack of functionality I needed:
Great, thanks!
# uname -a
DragonFly
Hello Mario,
For a GPT partition table you can use:
gpt -v show device_name
Cheers,
Martin
On 18.10.21 18:55, Mario Marietto wrote:
Hello.
I'm a new dragonfly bsd user. I'm looking for the commands which
replace the freebsd commands : geom disk list and gpart show. I'm
reading this part
It worked for me with 6.0.1:
root@:~ # uname -a
DragonFly 6.0-RELEASE DragonFly v6.0.1-RELEASE #3: Mon Oct 11
23:59:07 EDT 2021
r...@www.shiningsilence.com:/usr/obj/home/justin/release/6_0/sys/X86_64_GENERIC
x86_64
root@:~ # pkg update
Updating Avalon repository
Let me download the 6.0.1 image and try myself. Will let you know.
Quoting Mario Marietto :
Anyway,I'm pretty sure that I've installed d fly 6.0.1 but I've got that
error just the same.
Il giorno dom 17 ott 2021 alle ore 17:02 Mario Marietto <
marietto2...@gmail.com> ha scritto:
Since I'm a
Anyway,I'm pretty sure that I've installed d fly 6.0.1 but I've got that
error just the same.
Il giorno dom 17 ott 2021 alle ore 17:02 Mario Marietto <
marietto2...@gmail.com> ha scritto:
> Since I'm a new user,I don't know what to do at this point. It says Only a
> 'world' upgrade is needed :
Since I'm a new user,I don't know what to do at this point. It says Only a
'world' upgrade is needed : how can I make a world upgrade ?
Il giorno dom 17 ott 2021 alle ore 16:51 Antonio Huete Jiménez <
tuxi...@quantumachine.net> ha scritto:
> Hi,
>
> Please check:
>
Hi,
Please check:
https://lists.dragonflybsd.org/pipermail/users/2021-October/404826.html
If you're doing a new installation, please go with 6.0.1.
Cheers,
Antonio Huete
Quoting Mario Marietto :
Hello to everyone.
I'm a new dragonflybsd user. Just installed today.
The problem that I
The easy way to find out: can you upgrade dports? If you get an error,
upgrade your system.
On Thu, Oct 14, 2021 at 5:29 PM Antonio Olivares
wrote:
> On Wed, Oct 13, 2021 at 9:16 PM Justin Sherrill
> wrote:
> >
> > DragonFly 6.0.1 is released, and should be available at any mirror now.
> The
On Wed, Oct 13, 2021 at 9:16 PM Justin Sherrill
wrote:
>
> DragonFly 6.0.1 is released, and should be available at any mirror now. The
> big change in this bugfix release is updated certificate information to work
> around the Let's Encrypt expired certificate problem that's keeping people
>
On Thu, Oct 14, 2021 at 03:19:50AM -0400, Pierre Abbat wrote:
> On Wednesday, October 13, 2021 8:40:11 PM EDT James Cook wrote:
> > - If you upgrade to DragonflyBSD 6.0.1, the problem will go away. See
> >
> > https://www.dragonflydigest.com/2021/10/13/26267.html
>
> I'm running 6.1.0.3.
On Wednesday, October 13, 2021 8:40:11 PM EDT James Cook wrote:
> - If you upgrade to DragonflyBSD 6.0.1, the problem will go away. See
>
> https://www.dragonflydigest.com/2021/10/13/26267.html
I'm running 6.1.0.3. Should I upgrade to the latest master?
Pierre
--
li ze te'a ci vu'u ci bi'e
> I remain puzzled, however, why the mirror-master.dragonflybsd.org site
> could have had an expired Web certificate for the last two weeks
> without manual repair and reports on this list that first appeared on
> 30-Sep-2021, the day the certificate expired.
This sounds like a known issue with
t first appeared on
30-Sep-2021, the day the certificate expired.
194) 30-Sep Antonio Huete = Problems with sites using Let's Encrypt
certificates (9820 chars)
195) 30-Sep Antonio Huete = Re: Problems with sites using Let's Encrypt
certificates (10187 chars)
197) 1-Oct =?UTF-8?B?S
> Antonio reports about the certificate verification problem
> for the DragonFlyBSD package system:
>
> >> There is a fix already available, please check:
> >>
> >> https://lists.dragonflybsd.org/pipermail/users/2021-October/404826.html
Thanks for this, I overlooked this message. This worked.
Antonio reports about the certificate verification problem
for the DragonFlyBSD package system:
>> There is a fix already available, please check:
>>
>> https://lists.dragonflybsd.org/pipermail/users/2021-October/404826.html
I saw that response when it was originally posted, but I have a newly
There is a fix already available, please check:
https://lists.dragonflybsd.org/pipermail/users/2021-October/404826.html
Quoting Phansi :
Yes, just checked, I have a similar error on pkg update
#pkg update
Updating Avalon repository catalogue...
Certificate verification failed for
Yes, just checked, I have a similar error on pkg update
#pkg update
Updating Avalon repository catalogue...
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root
CA X3
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root
CA X3
Certificate
Earlier this week, it was reported that the expired Let's Encrypt
certificate problem has been resolved.
However, on two DragonFlyBSD 6.0 VMs at my site, one created from an
RC1 ISO image, and the other more recently from the official ISO image
dfly-x86_64-6.0.0_REL.iso dated 7-May-2021, I
Hi,
For "world upgrade" is the following correct? Actually this is what I
did and it worked. I couldn't find a definite description of the process.
```bash
cd/usr
make src-update
cd/usr/src
# Check the branch:
# git branch -r
# Do the checkout if needed:
# git checkout DragonFly_whatever_release
A fix is now available in branches: master, DragonFly_RELEASE_6_0 and
DragonFly_RELEASE_5_8.
Only a 'world' upgrade is needed, please proceed with the usual procedure.
- The DragonFly BSD team
Quoting Antonio Huete Jiménez :
Dear users,
As you may be already aware, a Let's Encrypt root
This sounds like DNS - the delay could be an initial query timing out and
then it's always the next server that responds. Check /etc/resolv.conf.
Does it list the DNS servers that your internet service provider actually
provides?
On Fri, Sep 24, 2021 at 10:41 AM Hunter wrote:
> Hello,
>
> I
Hello Antonio,
thank you for your explanations. I will follow your recommended way
and get in touch with the freebsd community.
With best regards,
Ajax
I'll go through the namecache changes between the two versions and see if I
can find something obvious.
-Matt
Just an FYI update - This issue kept recurring until I did an emergency
downgrade to 5.8 (from 6.0). This was about two months ago at the end
of July. Since the downgrade I've had no lookupdotdot failure messages
on the file server, and given the previous pattern I believe it would
have
Hi there!
Normally we try to avoid upgrading a port to a higher version than the
one in FreeBSD because it's more work for us there is a risk that we
forget about it and it's left in that version (we use something called
newport which overrides whatever comes from freebsd ports). However
The fix is already in ‘dports/master’ and in Avalon (as a binary
package). If you’re using a mirror you’ll probably have to wait a
couple days until it’s synced.
Remember you’ll have to ‘pkg install -f tmux’ because we have not done
any version bump.
Also, if you don’t want to wait for the
onsider installing it:
> >>
> >> Unsupported by upstream. Use GCC 10 or newer instead..
> >> -
> >>
> >>
> >> Cannot seem to remove gcc8 as blas and lapack depend on it.
> >>
> >> Did remove all the three and then found that (re)installing blas/lapack
> >> still requires gcc8.
> >>
> >> Any suggestions? I do not use dports.
> >>
> >> --
> >> cheers
> >> phansi
> >>
> >>
>
>
>
--
cheers
phansi
> NOTICE:
This port is deprecated; you may wish to reconsider installing it:
Unsupported by upstream. Use GCC 10 or newer instead..
-
Cannot seem to remove gcc8 as blas and lapack depend on it.
Did remove all the three and then found that (re)in
ted by upstream. Use GCC 10 or newer instead..
> -
>
>
> Cannot seem to remove gcc8 as blas and lapack depend on it.
>
> Did remove all the three and then found that (re)installing blas/lapack
> still requires gcc8.
>
> Any suggestions? I do not use dports.
>
> --
> cheers
> phansi
>
>
I was just re-looking at the acceleration disabled on my Radeon R5 240
thing again. It is still working fine for me on 6.0 with acceleration
on.
The specific commit that disabled acceleration is here:
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff
On Fri, 13 Aug 2021, 18:34 Aaron LI, wrote:
> I’ve created a bug to track this issue:
> https://bugs.dragonflybsd.org/issues/3294
>
Thanks!
Interesting… I confirmed the same issue on leaf, which running master as of Aug
4.
I’ve created a bug to track this issue:
https://bugs.dragonflybsd.org/issues/3294
Cheers,
Aaron
> On Aug 13, 2021, at 11:42, YONETANI Tomokazu wrote:
>
>
> Hi users,
>
> I'm not sure when it started, but
Yes, what we decided to do for this (and probably all the bounties that get
completed... Tuxillo is vetting the VALGRIND work next) is that they will
be paid out of the DragonFly paypal account, and then the individual
contributors to the bounty can pay into the DFly paypal account at their
Hi,
I’ve received the bounty money (1175 USD) via Paypal today and I’ve updated the
status on the bounty page.
Thank you guys for the kind offers :D
Regards,
Aaron
Guys remind me what the code bounty was for this?
-Original Message-
From: Users On Behalf Of Michael Neumann
Sent: Sunday, August 8, 2021 1:50 PM
To: Antonio Huete Jiménez
Cc: users@dragonflybsd.org
Subject: Re: [Code Bounty] NVMM hypervisor landed in DragonFly
On Sun, Aug 08, 2021
Hello Pierre,
regarding the version of Electrum available, it's the same story as for most
ports we offer, we're dependant on the version in FreeBSD ports.
>From
>https://github.com/DragonFlyBSD/DeltaPorts/commit/95f2bb679ffd575ff7bb54a8723afddb5520b775
> and
On Sun, Aug 08, 2021 at 11:36:27AM +, Antonio Huete Jiménez wrote:
> Sorry, I was not clear enough in the previous email. I mean an alternative
> paying method that might be easier, more convenient for us all.
Thanks for mentioning that. I already wrote to Aaron before I read your
email. Now
On Sun, Aug 08, 2021 at 12:25:02PM +0800, Aaron LI wrote:
> Hi DFlyers,
>
> As you might already know, the NVMM hypervisor has landed in DragonFly for a
> while and it's working quite well. So I think the hypervisor code bounty has
> been now accomplished.
Hi Aaron,
Great news! I am
> On Aug 8, 2021, at 19:08, Michael Neumann wrote:
>
> On Sun, Aug 08, 2021 at 12:25:02PM +0800, Aaron LI wrote:
>> Hi DFlyers,
>>
>> As you might already know, the NVMM hypervisor has landed in DragonFly for a
>> while and it's working quite well. So I think the hypervisor code bounty
>>
Sorry, I was not clear enough in the previous email. I mean an
alternative paying method that might be easier, more convenient for us
all.
Quoting Antonio Huete Jiménez :
For the bounty itself, please contact Matt as we have an alternative
that might be more convenient.
Quoting Michael
For the bounty itself, please contact Matt as we have an alternative
that might be more convenient.
Quoting Michael Neumann :
On Sun, Aug 08, 2021 at 12:25:02PM +0800, Aaron LI wrote:
Hi DFlyers,
As you might already know, the NVMM hypervisor has landed in
DragonFly for a while and it's
> On Jul 24, 2021, at 08:40, Jason Vas Dias wrote:
>
>
> I guess DragonFly does not yet support the virtio-gpu driver, like
> linux does, in : linux/drivers/gpu/drm/virtio ?
Right. I don’t see virtio-gpu is supported yet.
> Maybe not too difficult to port ?
Don’t know. I didn’t looked
I guess DragonFly does not yet support the virtio-gpu driver, like
linux does, in : linux/drivers/gpu/drm/virtio ?
Maybe not too difficult to port ?
On Fri, Jul 23, 2021 at 7:47 AM Aaron LI wrote:
> Hi Dan,
>
> We have interests in bringing DragonFly to other platforms, like RSIC-V
> and AArch64 (we even had a bounty for that for a long time). However, we’re
> really lacking developers to do that…
>
Yeah, I'm kind of suggesting that I take
Hi Dan,
We have interests in bringing DragonFly to other platforms, like RSIC-V and
AArch64 (we even had a bounty for that for a long time). However, we’re really
lacking developers to do that…
On the other hand, I think the current urgent task is to update the graphics
stack to support more
Well, I'm a bit at a loss at the moment. Try exporting the base filesystem
with NFS instead of exporting the nullfs mount. See if that works more
reliably.
-Matt
eleration was disabled. It appears it was disabled with commit
> e8de9e9.
>
> I rebuilt my kernel with acceleration re-enabled and it seems to be
> working fine. I'm using Xfce 4.16, Chrome 91 etc.
>
> Is it possible the underlying issue has been fixed incidentally? Is
> there a
On Thu, Jul 1, 2021 at 6:11 PM Dan Cross wrote:
> On Thu, Jul 1, 2021 at 3:00 PM Matthew Dillon
> wrote:
>
>> Upgrade to 6.0 for sure, as it fixes at least one bug in HAMMER2, to
>> eliminate that possibility.
>>
>
> Yes, both the previous installation and the one I put together yesterday
>
Yes, already in the "git head".
You can "git pull" and "make kernel" to have the changes.
Regards,
Bill
On Thu, 1 Jul 2021 at 23:47, James Hobson wrote:
> How do I get the fixed version?
> Is this a classic rebuild from git head?
>
> James
>
> On 21 Jun 2021, at 17:38, Bill Yuan wrote:
>
>
On Thu, Jul 1, 2021 at 3:00 PM Matthew Dillon wrote:
> Upgrade to 6.0 for sure, as it fixes at least one bug in HAMMER2, to
> eliminate that possibility.
>
Yes, both the previous installation and the one I put together yesterday
were running 6.0. The previous install had been upgraded to 6.0
Upgrade to 6.0 for sure, as it fixes at least one bug in HAMMER2, to
eliminate that possibility. RAM is a possibility, though unlikely. If
you are overclocking, turn off the overclocking. An ovewrclocked CPU can
introduce corruption more easily than overclocked ram can. And check the
dmesg
Thanks, Matt, this is very helpful. I pulled some metadata dumps and
started poking at them. But in the interest of getting the machine back
online as soon as possible, I popped in another NVMe (a brand new part),
reinstalled Dragonfly (from scratch) and restored user data (which I
managed to grab
How do I get the fixed version?
Is this a classic rebuild from git head?
James
On 21 Jun 2021, at 17:38, Bill Yuan wrote:
Hi James,
Thanks for pointing that issue out, it has been fixed.
Regards,
Bill Yuan
On Tue, 15 Jun 2021 at 15:06, James Hobson
mailto:james.hob...@jotron.com>> wrote:
It looks like several different blocks failed a CRC test in your logs. It
would make sense to try to track down exactly where. If you want to dive
the filesystem meta-data you can dump it with full CRC tests using:
hammer2 -vv show /dev/serno/S59ANMFNB34055E-1.s1d > (save to a file not on
the
On Thu, Jun 24, 2021 at 08:37:16PM +0200, Fritjof Bornebusch wrote:
> Hi,
>
> I just installed Dragonfly 6.0.0 with Lumina on a T460.
> One CPU core is always at 100%, even if top shows 0.0% for all processes. The
> remaining cores (3) are at 0%.
>
> Using a browser is increadible slow. Opening
Hi James,
Thanks for pointing that issue out, it has been fixed.
Regards,
Bill Yuan
On Tue, 15 Jun 2021 at 15:06, James Hobson wrote:
> Hello!
>
> I'm trying to test out the ipfw3 nat module and I can't seem to get
> anything to work! The example on the mailing list seems to be out of date
>
Yah, keep monitoring it. I kinda suspect what is happening is that one or
more processes on the clients are winding up CD'd into NFS directories that
then get renamed or deleted/replaced, or something like that. But it could
easily also have been a hash collision in the file handle calculation
FYI the server has been up with the patch applied for about 17 hours
now, so far without any dotdot failures (knock on wood). Of course last
time it took almost a month for this to become a serious problem, so
we'll see how it goes. So far it's been running smoothly, though.
Thanks for
On Wed, Jun 16, 2021 at 10:10:48PM PDT, Matthew Dillon wrote:
> Ok, you could try this kernel patch and see if it helps. If you know how
> to rebuild the system from sources. The client-side I/O errors would go
> hand-in-hand with the dotdot stuff, but only because this is a NFS mount.
> The
Oh, I forgot to mention... this patch changes the FSID for null mounts, so
any clients should umount, then reboot the server, then clients can
remount. or reboot the clients after rebooting the server.
-Matt
Ok, you could try this kernel patch and see if it helps. If you know how
to rebuild the system from sources. The client-side I/O errors would go
hand-in-hand with the dotdot stuff, but only because this is a NFS mount.
The server-side should not be having any I/O errors, and no filesystem data
I think this might be an issue with the filesystem id for the NULLFS
exports changing on reboot (or remount). I thought I had figured out a
solution for that but apparently not. I'll have to think about this a bit.
-Matt
hing in that hierarchy will continue to fail it reattempted.
Curiously, ssh'ing into the server and doing something like "find
$exported_mount >/dev/null" and just letting it sit there and traverse
the PFS on the server side seems to re-enable client access to the
affected hierarchy.
If you are not seeing any actual I/O errors in the dmesg output, then there
is probably no issue with the filesystem.
The dotdot warnings might be some edge-case being caused by the null-mounts
(because the null-mount has a mount point, but its being mounted on top of
a sub-directory in an
There are a lot of potential failure points, its a long chain of software
and hardware from the application's behavior all the way down to the
storage device's behavior in a failure. Failure paths tend to not be
well-tested. Reliability guarantees are... kinda just a pile of nonsense
really,
On Tue, Jun 15, 2021 at 03:25:12PM MDT, A Dog wrote:
> Lately I've been seeing this message repeated over and over again in my
> dmesg (I use HAMMER1, in case that isn't obvious from the message):
>
> Jun 15 14:05:22 badpuppy kernel: lookupdotdot failed 2 dvp 0xf800e95c7080
> Jun 15 14:05:25
On Mon, May 31, 2021 at 09:31:57AM +0800, Aaron LI wrote:
> Hi James,
>
> I knew this issue quite some time ago (> 1 year). It’s an issue in the
> golang’s net/route package. It was broken by the RTM_VERSION bump in
> DragonFly and first reported at:
>
>
On Sun, Jun 06, 2021 at 07:54:30PM -0400, Justin Sherrill wrote:
> On Sun, Jun 6, 2021 at 5:20 PM James Cook wrote:
>
> > Question, for anyone who knows: was there some time in the past when
> > opening /dev/tun0 would create the tun0 interface?
> >
>
> Going by the last note I have, it should
On Sun, Jun 6, 2021 at 5:20 PM James Cook wrote:
> Question, for anyone who knows: was there some time in the past when
> opening /dev/tun0 would create the tun0 interface?
>
Going by the last note I have, it should be autocreated when opening it, so
as of 2019, yes. And still now?
On Mon, May 31, 2021 at 09:31:57AM +0800, Aaron LI wrote:
> Hi James,
>
> I knew this issue quite some time ago (> 1 year). It’s an issue in the
> golang’s net/route package. It was broken by the RTM_VERSION bump in
> DragonFly and first reported at:
>
>
On 2021-05-31 00:26, karu.pruun wrote:
> I could not replicate the problem on my old i915 laptop.
>
> Can you open a bug on the bugs.dragonflybsd.org (if you don't have an
> account ask on irc) and attach the drm.debug=0x777 outputs of both 5.8
> and 6.0 there? Comparing them might help find the
I could not replicate the problem on my old i915 laptop.
Can you open a bug on the bugs.dragonflybsd.org (if you don't have an
account ask on irc) and attach the drm.debug=0x777 outputs of both 5.8
and 6.0 there? Comparing them might help find the problem.
Peeter
--
On Sat, May 29, 2021 at
Hi James,
I knew this issue quite some time ago (> 1 year). It’s an issue in the golang’s
net/route package. It was broken by the RTM_VERSION bump in DragonFly and first
reported at:
https://github.com/golang/go/issues/34368
Although the above issue has been resolved, I think it’s a partial
fb_info = { width = 1366, height = 768, stride = 5504, depth = 32 }
So at least the dimensions are the same.
Now that I know to use buildkernel, not quickkernel, I'll try putting
in some traces. One thing I noticed is that there are a number of calls
to set the framebuffer for a plane,
On 2021-05-28 01:05, karu.pruun wrote:
Hello
Can you see if the fb info has changed between 5.8 and 6.0? Insert
these lines
Doesn't look like it. I tried that debug trace in both 5.8 and 6.0
kernels and they both printed:
fb_info = { width = 1366, height = 768, stride = 5504, depth =
I worked on troubleshooting this, but didn't get very far.
For both 5.8 and 6.0, I set drm.debug to 0x777, booted the system, and
then kldloaded i915. I captured dmesg to a file in both cases for later
perusal. They are somewhat different: 6.0 does print more stuff and it
has couple warning
The patch only adds a timestamp. My hunch is that it's a malformed mail
file. At least, that is what it was every other time it happened.
On Sat, May 22, 2021 at 6:21 AM Antonio Huete Jiménez <
tuxi...@quantumachine.net> wrote:
> Yeah, it's an error in mailman somehow, we don't know why that
Yeah, it's an error in mailman somehow, we don't know why that happens
but it might be related to a custom patch we use to add timestamps to
the posts.
Quoting nacho Lariguet :
https://lists.dragonflybsd.org/pipermail/users/2021-May/thread.html
I just discovered it by accident looking up
The kern.kms_console is set to 1 by default, you can remove it from
loader.conf. There is a man page for drm (see 'man drm') and also for
the drivers, i915 and radeon.
I checked my intel (i7 skylake) machine, I get the same errors and
messages, but drm/i915 and xorg/xfce work fine.
Just to
https://man.dragonflybsd.org/?command=syscons=ANY
Heh, I never managed to stumble across that. Thanks!
On Thu, 20 May 2021 11:54:29 -0700
Chuck Musser wrote:
> That's correct: if the i915 module isn't loaded, then the console works
> normally. I tried loading the driver by hand after booting and the
> console becomes frozen: nothing new is displayed. But, yes, the system
> is still running. I've
That's correct: if the i915 module isn't loaded, then the console works
normally. I tried loading the driver by hand after booting and the
console becomes frozen: nothing new is displayed. But, yes, the system
is still running. I've always been able to SSH when the console is
frozen. The console
So I am I right to think that you can get the console fine but loading
i915 gives a frozen screen? To test this is true, remove automatic
loading of i915 from /etc/rc.conf and see if you get to the login
prompt. Then try manually loading i915 on console, as root do 'kldload
i915'. You can get more
I haven't read the book but since it's FreeBSD it should be mostly
relevant with caveats since DragonFly has diverged somewhat. So on my
rough understanding, the big picture and topics are relevant, but
beware of DragonFly differences here and there, e.g. kernel locking
routines (use lockmgr(9));
I tried the following, which did change things but did not result in a
working console at the end of the boot:
- added "gop set 2" in /boot/loader.conf. mode 2 was 1024x768 and seemed
to display fine in the loader prompt
- moved the i915_load="YES" to /etc/rc.conf and removed drm_load="YES"
Hello
You can try setting a different mode at the loader: get to the prompt
(press 9) and play with 'gop list', 'gop set ' and 'gop get'. Maybe
you can find a resolution that works fine?
If yes, try loading i915 in /etc/rc.conf, that's the recommended
procedure. Loading i915 too early may blow
Related (maybe) to this are these messages in dmesg:
vgapci0: port 0x5000-0x503f mem
0xe000-0xefff,0xf000-0xf03f irq 16 at device 2.0 on pci0
[drm] pdev: vendor=0x8086 device=0x0126 rev=0x09
[drm] svendor=0x17aa sdevice=0x21da irq=17
WARN_ON(domain->wake_count ==
On Mon, May 10, 2021 at 01:54:02PM -0400, Justin Sherrill wrote:
> DragonFly 6.0 is released - here's the release page:
> https://www.dragonflybsd.org/release60/
Thanks for all the great work!
Regards,
Michael
On Mon, May 10, 2021 at 12:54 PM Justin Sherrill
wrote:
>
> DragonFly 6.0 is released - here's the release page:
>
> https://www.dragonflybsd.org/release60/
>
> The normal ISO and IMG files are available for download and install,
> plus an uncompressed ISO image for those installing remotely.
>
>
If you are to continue using master, just upgrade to 6.1 (usual
procedure) and pkg will automatically pick the 6.2 ones.
Quoting Pierre Abbat :
On Tuesday, May 4, 2021 12:25:58 PM EDT Antonio Huete Jiménez wrote:
Yes, packages for 5.9 (old master) are 'dragonfly:5.10' because 5.10
was a
On Tuesday, May 4, 2021 12:25:58 PM EDT Antonio Huete Jiménez wrote:
> Yes, packages for 5.9 (old master) are 'dragonfly:5.10' because 5.10
> was a tentative version number for the next release. But as it turns
> out, we branched 6.0 so now the packages for current master (6.1) are
>
Yes, packages for 5.9 (old master) are 'dragonfly:5.10' because 5.10
was a tentative version number for the next release. But as it turns
out, we branched 6.0 so now the packages for current master (6.1) are
'dragonfly:6.2' and the 5.10 ones are removed.
Quoting Pierre Abbat :
On
On Wednesday, April 14, 2021 8:08:57 PM EDT Antonio Huete Jiménez wrote:
> Would it be possible for you to upgrade to latest master and retried?
I just got around to rebooting. Here's what happened when I tried to install:
# pkg ins dmalloc
Updating Avalon repository catalogue...
pkg:
On Sun, Apr 25, 2021 at 11:01:46AM -0300, andre almeida pfeiffer wrote:
> Hello,
Ola Andre,
> I'm new to this list so I would like to introduce myself. My name is
> Pfeiffer, I'm from Brazil and for some time now I have wanted to try
> Dragonflybsd out.
Welcome to DragonFly! Seems like you have
Thanks.
I have tried unloading bunch of modules to identify when power
management is disabled. And it happens exactly when loading when I issue
"kldload i915".
Apr 25 02:05:34 ThinkPad-X260 kernel: [drm] Initialized
Apr 25 02:05:35 ThinkPad-X260 kernel: [drm] pdev: vendor=0x8086
If it is GPU related we just might not have a working solution to the power
management. You could try adjusting the Xorg configuration to use the
"modesetting" driver with acceleration disabled but it's a long-shot. It
kinda feels like the GPU is defaulting to a consumption mode that is
forcing
101 - 200 of 3318 matches
Mail list logo
