Re: git non-time-sequential logs

[Theron]

On 1/5/21 2:36 PM, John Baldwin wrote:

On 1/4/21 8:52 AM, John Kennedy wrote:

On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote:

The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
I'm going to repull all the sources and recompile, just in case.  I might
have initiall pulled it during the git conversion and maybe it is confused.

This might be perfectly natural and just new to me, but when I look at the
git logs this morning I see things like this (editing by me):

commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, 
freebsd/main, freebsd/HEAD)
Author: Emmanuel Vadot 
Date:   Mon Jan 4 17:30:00 2021 +0100

commit f61a3898bb989edef7ca308043224e495ed78f64
Author: Emmanuel Vadot 
Date:   Mon Dec 14 18:56:56 2020 +0100

commit b6cc69322a77fa778b00db873781be04f26bd2ee
Author: Emmanuel Vadot 
Date:   Tue Dec 15 13:50:00 2020 +0100

commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
Author: Emmanuel Vadot 
Date:   Mon Jan 4 16:23:10 2021 +0100

   This is a fresh clone+pull off of anon...@git.freebsd.org:src.git.

   I've always assumed that the "Date:" there was when the commit happened,
so they'd be increasing (most recent on top), but I suppose that you might
have developers in branches that are committing to their branch at one
point in time and it's getting merged into current (main) later, but the
original date is preserved?

   I guess I only care because I was trying to use time to bisect the
time I thought the problem might have been introduced.

For commits to gdb (which uses git), the project asks that all series be
rebased via 'git rebase --ignore-date' prior to pushing to master to give
monotonically increasing commit dates.  We could do something similar in
FreeBSD either by asking folks to do that explicitly (though I know I
sometimes forget when pushing to gdb myself), or we could avoid direct
pushes to main.  One option some folks mentioned on IRC was to have a
separate "staging" branch that developers push to and then have a bot that
does a rebase --ignore-date of that branch to main periodically, though
that opens the question of how to deal with cherry-picks to stable (for
which asking developers to do a rebase --ignore-date prior to pushing is
probably the simpler approach).

If we did want monotonically increasing dates without having a staging
branch, we could perhaps use a server-side push hook to reject them and
developers would just have to do a rebase --ignore-date before pushing
again.

In the example above, the commit dates *are* monotonically increasing.  
The author dates aren't however, and that's what the log shows.


Commit dates for direct changes to HEAD (seen in 'git log --first-parent 
--pretty=fuller' among other methods) seem like a direct replacement for 
SVN revisions and their timestamps.  Maybe I'm not understanding the 
problem?


To be extra sure commit dates remain monotonic, it would make sense to 
enforce by rule:

- The commit date must not be earlier than the date of the commit's parent.
- The commit date must not be in the future.
Is there any nonnegligible reason not to impose that as a protection 
against accidental system time misconfigurations?  In any other 
circumstance, it would not come into effect anyway?

___
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"

Re: src: continued use of Subversion for getting updates

[Theron]

On 1/3/21 12:02 AM, Theron wrote:

On 12/23/20 3:49 AM, Warner Losh wrote:

I'm all ears on ways to make the docs better
I think a heads-up on the Git move and how to stay up to date in 
/usr/src/UPDATING is needed.  I was surprised to find no mention there.


Oops, I did mean to say "UPDATING in subversion".

20201223:
    The FreeBSD project has migrated from Subversion to Git. Temporary
    instructions can be found at
    https://github.com/bsdimp/freebsd-git-docs/blob/main/src-cvt.md
    and other documents in that repo.

So it's there in Git.  In that case I think this should be copied to 
https://svn.freebsd.org/base/head/UPDATING ASAP (unless that completely 
breaks future migration in some way).

___
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"

Re: src: continued use of Subversion for getting updates

[Theron]

On 12/23/20 3:49 AM, Warner Losh wrote:

I'm all ears on ways to make the docs better
I think a heads-up on the Git move and how to stay up to date in 
/usr/src/UPDATING is needed.  I was surprised to find no mention there.

___
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"

Re: src: continued use of Subversion for getting updates

[Theron]

On 12/23/20 2:01 AM, Warner Losh wrote:

On Tue, Dec 22, 2020, 11:47 PM Graham Perrin  wrote:


On 23/12/2020 00:10, Paul Mather wrote:

… continue to get src updates via Subversion. …

As far as I can tell:

* for stable/12 alone


stable/11 as well as the releng branches for as long as the project has
them under support. I wrote the code to replay commits into subversion for
the convenience of our users on those branches.



Current has moved entirely to git. New commits have started up again.
Stable/11 and stable/12 are there as well, but there are a couple of last
minute snags that are being sorted out so it will be an additional day,
maybe two before those start.


What's the projection for when or how the subversion mirroring of new 
current and stable commits will start up?  Can users trust that such 
updates will continue until a git client is adopted into base?


(Or will there be a long-term disruption to the ability to track current 
using tools found in base?)

___
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"

Re: Plans for git (was: Please check the current beta git conversions)

[Theron]

On 2020-09-02 12:47, Steve Kargl wrote:

Checking out /usr/src as u...@freebsd.org

   svn checkout svn+ssh://u...@svn.freebsd.org/base/head /usr/src

   git ...

Checking out /usr/src without freebsd.org account

   svn checkout https://svn.freebsd.org/base/head ${HOME}/freebsd/src

   git ...


"which svnlite" -> /usr/bin/svnlite
(from /usr/src/usr.bin/svn)

"which git" -> /usr/local/bin/git
(from /usr/ports/devel/git)

After the transition, will FreeBSD base contain the tool for the cloning 
the FreeBSD repository (not one of the mirrors?)


Is there a plan to have 'git' or one of its clones added to the base system?

Surprisingly, I can't seem to find any prominent discussion / debate on 
"git in base" (the tool itself).


Theron
___
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"

Re: USB microphones with FreeBSD-CURRENT: bug 194727, r358629

[Theron]

On 2020-03-30 20:08, Graham Perrin wrote:
Theron, thank you! That might explain a recent sense of randomness 
with the symptoms. I've been testing in three different boot 
environments, only one of which is above the 358629 at 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727#c22>:


I don't know what would be attaching to mixer before login.  For me the 
problem is predictable: suspending after I've opened a player reliably 
hangs kernel, and killing every user of /dev/dsp* /dev/mixer* before 
sleep reliably avoids the problem.  Maybe something is attaching on startup.


(In retrospect, most remarkable to me was that the bug could bite 
before logging in; taking the 'Sleep' option in sddm did not lead to a 
suspend of the system. Hopefully fixed for FreeBSD-CURRENT by r358629; 
I'll not test now, maybe later in the week.)


As I understand it, r358629 adds a mechanism that applications can use 
to "do the right thing" but does not fix the underlying kernel 
vulnerability.


Theron
___
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"

Re: USB microphones with FreeBSD-CURRENT

[Theron]

On 2020-03-30 15:06, Graham Perrin wrote:
Worth noting: if I attempt to suspend the system whilst the device at 
3 (SteelSeries Siberia 350 headphones with integral microphone 
) is physically 
connected, suspend sometimes fails; it becomes necessary to force off 
the computer.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727

___
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"

Re: System clock is slow

[Theron]

On 2020-03-10 01:38, Peter Jeremy wrote:

Are you running NTP?  If so, is NTP maintaining lock and what is the
reported PLL frequency (ntpq -c kerni)?


Didn't show any useful difference, "kernel status: pll unsync" when I 
tested this.



What does "sysctl kern.timecounter" report and have you tried using
any of the alternative timecounters listed in kern.timecounter.choice?


Indeed that reveals the problem:
    kern.timecounter.hardware: TSC-low
(before regression)
    kern.timecounter.tc.TSC-low.frequency: 1296053807
(after regression)
    kern.timecounter.tc.TSC-low.frequency: 13

(why are these tsc_freq divided by two?)

Through some printf's in tsc.c I've determined that the 2.6e9 value is 
from 0x16 CPUID which Intel says is only a nominal value not to be used, 
whereas 2.592e9 value is from calibration.


/*
 * Calculate TSC frequency using information from the CPUID leaf 0x15
 * 'Time Stamp Counter and Nominal Core Crystal Clock'.  If leaf 0x15
 * is not functional, as it is on Skylake/Kabylake, try 0x16 'Processor
 * Frequency Information'.  Leaf 0x16 is described in the SDM as
 * informational only, but if 0x15 did not work, and TSC calibration
 * is disabled, it is the best we can get at all.  It should still be
 * an improvement over the parsing of the CPU model name in
 * tsc_freq_intel(), when available.
 */

The implementation logic for when to use tsc_freq_cpuid() looks wrong to 
me; it doesn't match what this comment implies.  Fallback to calibration 
when calibration is unspecified should proceed when 0x15 fails 
regardless of what 0x16 does.  (CC'd the authors).


Switching to HPET or ACPI-fast gives the expected results.  Would there 
be any reason to not use HPET provided I can cope with the performance 
implications?
The name of the ACPI option varies haphazardly between "ACPI-fast" and 
"ACPI-safe" between reboots, I guess it is sensitive to some buggy 
vendor firmware.



Are you overclocking your CPU (or doing anything else non-standard)?


I had previously used powerd to let the CPU underclock to 700MHz when 
idle.  Now, I've lost all control over CPU frequency (either by powerd 
or by sysctl) since there is some in-kernel cpufreq driver which I can't 
figure out how to disable.  It's very much an annoyance, but I think 
unrelated to the timecounter problem.


Theron
___
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"

System clock is slow

[Theron]

Hi All,

Since switching from 12.1-RELEASE to CURRENT I've noticed timing 
problems with audio applications.  It turns out that the problem is not 
with the audio drivers, but with the system clock driver, which now 
reports passage of time 0.3% too slow.  Although I discovered this only 
recently, it's been broken since r352684 made on Sept. 25.  Has anyone 
else noticed?


I suppose it might only affect a specific processor: Intel(R) Core(TM) 
i7-6700HQ CPU @ 2.60GHz.


Bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244705

Theron
___
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"

Re: Pkg repository is broken...

[Theron]

On 2020-03-06 20:02, Theron wrote:

On 2020-03-06 19:42, k...@denninger.net wrote:

Strange.  Mine cleared up automatically the following day.

It's also strange how few replies I have received.  Two private
messages (why?), yours, and that was it.  You'd think that people
would be screaming.

Maybe because not everyone knows this is affecting all 
releases/branches simultaneously, the reports of this have been a bit 
scattered about.  Bug here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244549
Looks like this has already been linked in this thread (but it was sent 
to multiple lists so I didn't see it at first).

Sorry for noise!
___
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"

Re: Pkg repository is broken...

[Theron]

On 2020-03-06 19:42, k...@denninger.net wrote:

Strange.  Mine cleared up automatically the following day.

It's also strange how few replies I have received.  Two private
messages (why?), yours, and that was it.  You'd think that people
would be screaming.

Maybe because not everyone knows this is affecting all releases/branches 
simultaneously, the reports of this have been a bit scattered about.  
Bug here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244549

Theron
___
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"

Re: 2 things; a cool crash log of my grandmother-laptop, that's plasma's now bricked; vmn0 not X -configuring

[Theron]

On 2019-10-09 19:46, Miranda van den Breukelingen wrote:

2. Radeon R7 240 firmware error:

did hw.syscons.disable=1 in /boot/loader.conf --- nothing, no boot 
with none of the kernels.


Really no boot with that line in loader.conf, whereas it could boot 
previously?  Possibly it is booting, but you can't see because the 
console is gone?


The console should come back once amdgpu is loaded.  If not, try 
debugging over ssh.

___
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"

Re: HEADSUP: drm-current-kmod now installs sources

[Theron]

On 2019-08-14 11:04, Ian Lepore wrote:

I can't understand what you guys are not-understanding.  New machinery
has been added that says "if some module source code exists in this
absolute fixed location on the build machine, then whenever you do any
kernel build for any OS version or any arch, rebuild that module source
code so that the the build machine's video drivers stay in sync with
the build machine's kernel."

Do you not see that for some of us, only a tiny fraction of the builds
done (maybe none of them at all) involve the kernel for the build host
machine or the video drivers for the build host machine?  And yet, for
us, every build we do will now inapppropriately rebuild this video
driver module which has nothing to do with the machine the build is
targeting.
Most of the kernel builds I do _are_ for the host machine, yet I don't 
want the new behavior either.  Why?  The build logic of the source tree 
should be self-contained and easily understandable. Looking all over the 
system and trying to automate fixes is what ports are for.


Automated hacks for this sort of situation, that do the right thing 90% 
of the time but inevitably break down on other perfectly reasonable use 
cases, are one of the factors that pushed me away from the operating 
systems I used before FreeBSD.


Managing the host's kernel and needed modules from source from a single 
tool certainly is useful, but I think it should be just that: a tool, 
used when appropriate, not a default behavior.
This tool can be recommended to kmod port users/developers for local 
system work while everyone else may continue using source tree as expected.


On 2019-08-14 11:06, Kyle Evans wrote:

LOCAL_MODULES="" does seem like a sensible default when we're not
building a native kernel.
More generally there should be a switch for defeating any and all 
attempts to use anything "local" (non /usr/src).


___
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"

Re: HEADSUP: drm-current-kmod now installs sources

[Theron]

CC @current, as I had originally intended.

On 2019-08-14 09:08, John Baldwin wrote:

1) You can set LOCALBASE to a different path either in a kernel config
(via makeoptions) or when invoking buildkernel.

For example, I mount my rpi's sdcard at /mnt on my amd64 laptop and
then cross-build into it, so I could set LOCALBASE to /mnt/usr/local when
building the rpi's kernel to honor any kmod packages installed on the rpi.


Normally LOCALBASE is interpreted by ports as the default for PREFIX, 
meaning it should be a path _within_ the target system, not the path to 
where it is mounted.  There is DESTDIR for that. Now for kernel build 
this is not a problem for the reason that LOCALBASE is being used just 
to find sources, not to build ports. However, given how that variable is 
normally used, it seems like a problem waiting to happen.  It would be 
better to use a variable specific to the purpose at hand.



How about when I'm doing a build of 11-stable for testing, but what's
in my /usr/local is sources for a 13-current driver?

Given that the kmod's are supposed to be portable across branches,
the build really shouldn't be breaking. But the same ability is still
there to as above to disable builds either in general or for
specific kernel configs or buildkernel invocations.


The concern appears to be that there is no longer a clear way to 
separate what base source tree does from what is in the local system's 
configuration.  Is there any one single knob to tell /usr/src not to use 
any configuration from /usr/local?


___
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"

Re: linux-c7 and opengl apps?

[Theron]

On 10/3/18 5:36 AM, Johannes Lundberg wrote:

Hi

Have anyone successfully run opengl apps with linux-c7?

Linux opengl apps works great with linux-c6 on gpu < kabylake but
linux-c6-dri does not include support for kabylake gpus.
Linux glxinfo in c7 show support for hardware rendering on kabylake but any
attempt to run an opengl app results in application seg fault or other
crash (I believe this is also the case with skylake gpus on linux-c7).

Is there any way to run gdb on linux apps/core dumps?

/Johannes
___

On an Intel Skylake graphics system it has never worked:
% /compat/linux/opt/VirtualGL/bin/glxinfo | grep OpenGL
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: Version 4 or later of flush extension not found
libGL error: failed to load driver: i915
libGL error: MESA-LOADER: failed to retrieve device information
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Unknown Intel Chipset
OpenGL version string: 1.3 Mesa 17.0.1

Running any Linux OpenGL app which attempts to do actual rendering 
results in an indefinite freeze of the console: graphical output is 
frozen, and system does not respond to keyboard (Ctrl-Alt-Del or 
Ctrl-Alt-F1).  However, the system continues to run (tested with ssh).  
Sometimes, after several minutes, the console recovers, the OpenGL user 
segfaults, and the system returns to normal (until the next attempt to 
use an OpenGL Linux app).


This problem has existed forever.  I am not sure it is actually a fault 
in Linux emulation, as these very same symptoms ("failed to retrieve 
device information" message, console freeze) existed back in 
FreeBSDDesktop/freebsd-base-graphics days when attempting to run purely 
FreeBSD OpenGL apps.  At the time the workaround was a patch to Mesa's 
GPU detection; the underlying kernel problem wasn't addressed.


Where would I begin to investigate the problem, in order to fix it 
and/or to decide who's bug it is?  Unless there is something simpler to 
try, I may have to dig up those old Mesa patches and see whether a 
non-Linux binary can be made to trigger the same symptom.


By design, is it considered acceptable that any member of the "video" 
group has permission to destroy functionality of the graphics 
subsystem?  Is this a bug in the general case, or an accepted technical 
limitation?


Copying to x11@.

Theron
___
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"

Re: r336876 breaks sysutils/acpi_call

[Theron]

On 8/25/18 11:51 PM, Theron wrote:
A recent change in CURRENT has sysutils/acpi_call reliably cause a 
kernel panic


The problem is with the port itself, not with CURRENT.  A bug is filed 
accordingly.

___
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"

r336876 breaks sysutils/acpi_call

[Theron]

A recent change in CURRENT has sysutils/acpi_call reliably cause a 
kernel panic when run on a Dell XPS laptop system.  I bisected this to 
r336876: Use SMAP on amd64.  I would have thought that this is a simple 
compatibility problem requiring only a port update, except that the same 
kernel and acpi_call on different hardware are not affected.  On the 
problematic system, the kernel module loads without incident; it is when 
executing ACPI commands, even normally harmless operations such as 
requesting read-only constants, that the system freeze occurs.  ACPI 
functionality seems otherwise unaffected.


Kernel debugging console and crash dumps are also broken on this system 
(I suspect due to Intel graphics) however it is an unrelated problem, 
and is only an excuse for my inability to provide any further crash 
information.


Having already bisected to the breaking commit, is there anything else I 
should do to improve the chances this problem gets fixed, or are there 
any hardware compatibility notes I may have missed?


Theron
___
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"

Re: how to deal with variable set but not used warnings?

[Theron]

On 06/03/18 17:33, Warner Losh wrote:

On Sun, Jun 3, 2018 at 3:28 PM, Rick Macklem  wrote:


mmacy has sent me a bunch of warnings of the "variable set but not used"
kind
generated by gcc8.

When I've looked at the code, these are for RPC arguments I parse but do
not
use at this time.
I'd  like to leave the code in place, since these arguments may be needed
in the
future and it is hard to figure out how to get them years from now, when
they
might be needed.
I can think of 3 ways to handle this:
1 - Get rid of the code. (As above, I'd rather not do this.)
2 - Wrap the code with "#if 0"/"#endif" or similar. I'll admit that I find
this rather
   ugly and tends to make the code harder to follow.
3 - Leave the code and add a comment w.r.t. why the variables are set but
not used.

So, what do others think is the preferable alternative?
(Or maybe you have a #4 that seems better than any of these.)


4. Disable the stupid warning in the Makefile / build system. If you don't
care, and there's a good reason for what you are doing (sounds like there
is), better to just disable the warning as so much useless noise.

Warner
___
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"

Or possibly, alongside a comment as in (3), use one of these:
5 - Disable warning pragma - 
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
6 - Use __attribute__((unused)) - 
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes


___
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"

Re: suspend/resume regression

[Theron]

On 05/13/18 15:44, Pete Wright wrote:
so i've done a bit more debugging on my end.  i've even installed the 
11.2-BETA branch last night since 11-STABLE worked without issues 
about a month or so ago.


i've set "debug.acpi.resume_beep=1" and when resuming after entering 
an S3 sleep state the bell rings and does not stop until i do a hard 
reset (both with i915kms loaded and unloaded).


kinda at a loss as to how this could break both CURRENT and basically 
11-STABLE.  i'm going to make a ubuntu live image and test that, my 
laptop is a System76 laptop that shipped with ubuntu originally.  if 
that is broken as well then i guess this could be a hardware issue.


ubuntu live image suspends/resumes without issue so this certainly 
seems to be a freebsd issue unfortunately.  i guess next step is to 
attempt to find a working CURRENT snapshot that does suspend/resume 
without issue then start looking at commits?


-pete

Returning to the original issue: complete failure to resume, rather than 
slowness: I am affected as well.  CURRENT r333093 worked, but r333582 
fails in a manner consistent with what Pete has described, with or 
without drm loaded.  There have been a few commit messages mentioning 
ACPI in that window of history, which I will use to help me bisect when 
I have time.


Theron
___
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"

Re: suspend/resume regression

[Theron]

Hi!
I'm also seeing issues, not as severe as Pete, but after I resume 
(which works, with drm-next and DMC firmware), the system becomes 
sluggish.  It feels like I/O takes more time, and graphics are 
sluggish (very sientific, I know, but for instance git operations are 
much slower after a resume).  I know there's been an update to acpica 
between my system updates, when this started to happen, but I haven't 
had time to revert that update and test again.  I will try to do that 
and report back.

Regards

Hi Niclas,
I used drm-next on Skylake with issues which sound similar. Resuming 
from suspend, or simply switching the laptop display output off and on 
from xrandr, resulted in graphics sluggishness (drop to 30fps in 
glxgears) and graphical corruption in Xorg apps, which persisted even 
after restarting these apps.  Switching to drm-stable made the problems 
go away; I haven't had time to figure out what -next is doing 
differently to cause them.


Pete's issue sounds more severe, and unrelated as it happens without drm 
loaded.  My kernel is two weeks out of date (r333093), so I need to 
check whether the more recent changes affect my system as well.


Theron
___
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"

Re: pkg, drm-next-kmod and base packages

[Theron]

On 05/10/18 03:45, Johannes Dieterich wrote:

Hi

On Wednesday, May 9, 2018, Boris Samorodov wrote:

Hi All,

I use self-built base packages. How can I test/use drm-next-kmod?
Packages for kernel and drm-nex-kmod are in conflict:
-
Checking integrity... done (1 conflicting)
   - drm-next-kmod-4.11.g20180224 [FreeBSD] conflicts with
FreeBSD-kernel-pkg64x-12.0.s20180509041454 [installed] on
/boot/modules/drm.ko
Checking integrity... done (0 conflicting)
-

Since I don't have a system with pkgbase configured, is there a way to figure 
out what files conflict?

The pkg output indicates that /boot/modules/drm.ko is the conflicting file.

It surprises me that there are any since we do not override anything normally 
(some kernel modules are indeed overlapping but they get installed in different 
directories).
On a non-pkgbase -CURRENT system, drm.ko and drm2.ko from base are in 
/boot/kernel/, while drm.ko from drm-stable-kmod is in /boot/modules/.  
Any kernel modules from base being placed outside of /boot/kernel is not 
what I would expect for a non-pkgbase system; is there a reason pkgbase 
should not follow this rule?


Theron
___
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"

Re: pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead

[Theron Tarigo]

On 03/18/18 18:35, AN wrote:
Is there a way to restart the audio subsystem without rebooting the 
machine?
Building kernel with sound and snd_* as loadable modules should enable 
this to be accomplished with kldunload/kldload.  In my experience though 
all sound device files must be closed before unloading these modules to 
avoid some lockup issues.

___
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"

Re: pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead

[Theron Tarigo]

On 03/18/18 18:52, Theron Tarigo wrote:

On 03/18/18 18:35, AN wrote:
Is there a way to restart the audio subsystem without rebooting the 
machine?
Building kernel with sound and snd_* as loadable modules should enable 
this to be accomplished with kldunload/kldload.  In my experience 
though all sound device files must be closed before unloading these 
modules to avoid some lockup issues.


___
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"