# Frequent interruptions of IO in FreeBSD 11.2?



## stratacast1 (Jul 15, 2018)

I just did a fresh install of FreeBSD 11.2 on my prior 11.1 box, and I'm finding now after doing so, I will frequently have my audio cut out for just a moment. My audio plays out of USB to a FiiO E10K external DAC. I don't know sound, and I don't know where to begin on this one. I'm also on KDE5 with phonon-gstreamer as my backend for phonon. No indication that there is high CPU causing this. In addition to the audio cutouts, I've noticed that sometimes there will be a jitter in my mouse movement, like there's a moment where my processor just ignores any sort of IO. I haven't noticed this while typing yet, but that could just be in the timing.


----------



## stratacast1 (Jul 16, 2018)

Just an update...I found this is more than just an audio issues, this is also affecting my mouse movement. Is there a way to delete threads? I want to remove this and post something new in a different section since this isn't just limited to audio


----------



## rigoletto@ (Jul 17, 2018)

Just re-work the thing and ask a moderator to move it.


----------



## stratacast1 (Jul 21, 2018)

I found this is also affecting keyboard input. Since this is all I/O related but doesn't seem to affect storage media, could this be xorg related then? I use nvidia graphics for one...One thing that is different from my last setup is this time I ended up getting the nvidia stuff from x11/nvidia-driver instead of getting it with pkg. In addition to that, I configured my xorg.conf file with nvidia-xconfig (same as last time)


----------



## shkhln (Jul 21, 2018)

stratacast1 said:


> I found this is also affecting keyboard input.
> ...
> I use nvidia graphics for one...



Are there USB video cards now?


----------



## phoenix (Jul 21, 2018)

There are USB video cards. We use a couple different ones on Windows stations at work for multi-monitor setups. They're ok for office work, but you won't be playing 3D games using them.

That's not what the OP is using, though. They've got a normal Nvidia card. And a bunch of USB devices, which are experiencing drop-outs for some reason.

To the OP: are these USB 2.x or 3.x devices? Plugged into USB 2.x or 3.x ports? And are those ports connected direct to the CPU, the chipset, or a separate controller? Have you tried moving then between ports?


----------



## stratacast1 (Jul 21, 2018)

I specify nvidia because nvidia-xconfig generated the xorg.conf file, which, to my understanding, has all the x configs for keyboard/mouse input.

phoenix - these are USB 3.0 ports, and my external DAC is connected via USB 2.0. I haven't tried moving between ports, I'll give that a go right after posting this. To my understanding, my keyboard/mouse are going direct to the CPU, but my DAC is going to the B350 chipset. My mobo is an Asus B350 Gaming-F board, and I'm running a Ryzen 1600. My I/O connections haven't changed from 11.1 to 11.2


----------



## stratacast1 (Jul 22, 2018)

I just tried doing different USB ports and it did not resolve the issue


----------



## shkhln (Jul 22, 2018)

I would usually suggest disconnecting USB devices one by one, but then that motherboard (Asus B350 Gaming-F) doesn't have any PS/2 ports... F suffix seems quite appropriate here.


----------



## rigoletto@ (Jul 22, 2018)

TL;DR, I suspect that is electric pollution between the USB ports.


----------



## stratacast1 (Jul 22, 2018)

lebarondemerde said:


> I suspect that is electric pollution between the USB ports.


Why would an OS upgrade suddenly cause that? And it's FreeBSD only. Windows 10 on separate drives and in the same PC is not having these issues


----------



## shkhln (Jul 23, 2018)

Let's try going over the first post again.



stratacast1 said:


> I just did a fresh install of FreeBSD 11.2 on my prior 11.1 box



Any particular reason for a fresh install? Did you copy config files (/boot/loader.conf, /etc, /usr/local/etc) from the previous installation?



stratacast1 said:


> I will frequently have my audio cut out for just a moment.



'Frequently' as in? How easy is it to observe? Does it consistently happen all the time?



stratacast1 said:


> My audio plays out of USB to a FiiO E10K external DAC. I don't know sound, and I don't know where to begin on this one. I'm also on KDE5 with phonon-gstreamer as my backend for phonon. No indication that there is high CPU causing this. In addition to the audio cutouts, I've noticed that sometimes there will be a jitter in my mouse movement, like there's a moment where my processor just ignores any sort of IO.



Can you (temporarily) switch to the onboard audio? If your problem is USB related there might still be mouse jitter, but sound should be ok.


----------



## stratacast1 (Jul 23, 2018)

shkhln said:


> Any particular reason for a fresh install? Did you copy config files (/boot/loader.conf, /etc, /usr/local/etc) from the previous installation?



I did a fresh install because my 11.1 install got totally obliterated when I tried to disable virtualbox kernel modules during my upgrade. Because it was unrecoverable, I just did a fresh install. Everything is a vanilla install. The only remnant of my 11.1 install is my home zpool that I later imported after the install.



shkhln said:


> 'Frequently' as in? How easy is it to observe? Does it consistently happen all the time?



Frequent as in 1-3x per minute, but sometimes it could be once every 5 minutes. It's very easy to tell because the audio will hang up and mouse movement pausing will be very obvious. It happens all the time now.



shkhln said:


> Can you (temporarily) switch to the onboard audio? If your problem is USB related there might still be mouse jitter, but sound should be ok.


After about 10 minutes of playing audio from onboard audio, I found that I did not get this jitter. Even as my mouse was receiving the jitter. So this has to be a USB issue then. I'll be trying Windows 10 again later tonight to confirm that if it is in fact specific to FreeBSD after the update, or it's just that I'm now aware of the problem...it's been a week since I've been able to boot into Windows, I should be able to tonight


----------



## stratacast1 (Jul 25, 2018)

Okay, I had the chance to jump on Windows, Windows does not exhibit this USB jitter behavior so there's some sort of bug in FreeBSD


----------



## Crivens (Jul 25, 2018)

You may rum `systat` to see the interrupts, that may show some details missing.


----------



## nihr43 (Jul 25, 2018)

*stratacast1* - My workstation is a freebsd 11 stable with i3, nvidia graphics from ports, virtualbox from ports, and I also use a usb audio device.  Sometime around the 11.2 RELEASE code freeze - I made the mistake of upgrading, and my mouse started stuttering absolutely terribly.  It really seemed to be correlated with sata disk IO.  It was so bad I initially thought my southbridge was melting or something.  No effect on usb audio for me though.  Before giving up, I upgraded once more after the freeze was released on STABLE, and all is good now.  Better than ever actually.  I'm on r336229.  You should really try upgrading straight to STABLE - I suspect something is up with 11.2 r0.

It would be neat to pin down the actual diff that fixed this for me and make sure its fixed in 11.2 r1.  I dont know much about that process though.


----------



## stratacast1 (Jul 26, 2018)

Nothing really sticks out running systat. I didn't see any sort of CPU spike, don't see anything happening as far as interrupts go


----------



## shkhln (Jul 26, 2018)

nihr43 said:


> I'm on r336229.


CURRENT? It would be difficult to correlate your experience with OP's experience.


----------



## nihr43 (Jul 26, 2018)

shkhln said:


> CURRENT? It would be difficult to correlate your experience with OP's experience.



No... FreeBSD 11.2-STABLE #0 r336229.  Slightly after the 11 stable code thaw during the 11.2 release process. 11.2 release was 335563.


----------



## shkhln (Jul 26, 2018)

I only see https://svnweb.freebsd.org/base?view=revision&revision=336229, which is in CURRENT and hasn't been backported anywhere yet.


----------



## nihr43 (Jul 26, 2018)

`uname -v`

FreeBSD 11.2-STABLE #0 r336229M: Thu Jul 12 20:41:11 CDT 2018

I guess I don't understand what revision numbers mean.  Isn't the directory revision just the latest commit in the directory?  I missed that M earlier.  Whats the M?


----------



## stratacast1 (Jul 26, 2018)

I think that's encouraging to know I wasn't the only one having similar issues  I'm on FreeBSD 11.2-RELEASE #0 r335510. I'll try updating to a newer revision today and see if that helps!


----------



## shkhln (Jul 26, 2018)

nihr43 said:


> FreeBSD 11.2-STABLE #0 r336229M: Thu Jul 12 20:41:11 CDT 2018



Weird. I don't compile my kernel, however I've used a search function on this forum to get a few more uname results for comparison. There more revision numbers pointing to CURRENT than to STABLE. I suppose I don't know how this works either.



nihr43 said:


> Whats the M?



No idea.


----------



## stratacast1 (Jul 26, 2018)

shkhln said:


> Weird. I don't compile my kernel, however I've used a search function on this forum to get a few more uname results for comparison. There more revision numbers pointing to CURRENT than to STABLE. I suppose I don't know how this works either.



CURRENT is their release for current working builds, that are the latest working builds and are using more experimental features and code, so they'd probably shove out more of these releases more often for testing. STABLE is branches from which major releases are made. They have lot mor detail here:

https://people.freebsd.org/~trhodes/doc/handbook/current-stable.html


----------



## rigoletto@ (Jul 26, 2018)

shkhln said:


> There more revision numbers pointing to CURRENT than to STABLE.



There may have dozens of commits in -CURRENT on a single day.


----------



## nihr43 (Jul 26, 2018)

Id guess my "M" is for modified.  I added vimage.

OK, I just now updated my STABLE /usr/src/ and refreshed svn.freebsd.org at the same time.

As for the weird revision numbers, whatever revision "base" is at is what your source tree will get tagged, regardless of current / stable.  `svnlite info` shows me :

Revision: 336745
Last Changed Rev: 336741

So those revisions as uname reports seem to be a relative timestamp of CURRENT at the time of checkout


----------



## shkhln (Jul 26, 2018)

lebarondemerde said:


> There may have dozens of commits in -CURRENT on a single day.



Doesn't matter in the slightest. You version number is supposed to point to the revision of source code it has been built from. RELEASE kernel version somehow manages to point to the RELENG branch. Why STABLE doesn't?


----------



## rigoletto@ (Jul 26, 2018)

shkhln said:


> There more revision numbers pointing to CURRENT than to STABLE. I suppose I don't know how this works either.





lebarondemerde said:


> There may have dozens of commits in -CURRENT on a single day.





shkhln said:


> Doesn't matter in the slightest.



Yes, it is clear you don't know how it works, and also you didn't read neither the link stratacast1 pointed before nor Thread 40469;

But

RELEASE *never* change, all updates after RELEASE but before the next RELEASE are made on RELENG. STABLE is where the next RELEASE is *prepared*, and CURRENT is the playground.

I already lost the count of how many time either I seen some folk having to explain or I had to write it in here (forums)...


----------



## shkhln (Jul 26, 2018)

Please, _don't explain to people things you don't understand_. I'm extremely angry right now.


----------



## rigoletto@ (Jul 26, 2018)

I don't give a _thing_ for what you or any one feel.


----------



## stratacast1 (Jul 26, 2018)

Anyways....to return us to topic...I'm in the same boat as *nihr43* now it seems. My audio jittering is completely fixed after an update. I'm on FreeBSD 11.2-RELEASE #0 r336744 now. However, I still notice some mouse jitter right now though, but I think it's not AS bad as what it was. At this point maybe there was some KDE5 update that is causing the mouse stutter?


----------



## nihr43 (Jul 26, 2018)

stratacast1 said:


> I'm on FreeBSD 11.2-RELEASE #0 r336744 now.



OK now I'm lost.  I thought you were going to stable?  In anycase I'm going to start watching for other people complaining about usb on 11.2

Also I'd suspect xorg before kde.   One other thing I've done is I have the following in my rc to make sure my mouse is using hald.  hald comes from pkg hal :

hald_enable="YES"
moused_ums0_enable="NO"

That may do nothing, the extent of my knowledge there is that I have a process called "hald-addon-mouse-sysmouse" and I know my mouse works well.


----------



## shkhln (Jul 26, 2018)

nihr43 said:


> So those revisions as uname reports seem to be a relative timestamp of CURRENT at the time of checkout



It seems so. Already reported as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189180.


----------



## rigoletto@ (Jul 26, 2018)

The repository revision number is global, every single time you change the file whether it is on trunk, or branch or tag, the number will increase.

STABLE is a ( not tagged ) branch of *trunk* ( aka -CURRENT ), and the -RELEASE branch come out from the -STABLE branch, but this one is also *tagged*. Then the -RELENG branch is created for that particular -RELEASE.

A branch is just a copy from trunk ( or whether you are getting it from ) that can have other revisions merged inside of it later, and so it does not have its own branch specific revision numbers.

A tag also does not have its own specific revision numbers ( by svn default ) but can have a special commit to get those, and it happens in FreeBSD.

So, as I pointed before ( Thread 66705/post-395992 ), -RELEASE never changes, and every new update *IS* -RELENG until the next -RELEASE come out, and the revision numbers would be the same from whether that specific file was modified for the last time ( -RELENG it self, -STABLE, -CURRENT ) when _freezed_ for that particular merge.

*[EDIT]*

If your working copy is -RELENG and you merged a newer revision from -CURRENT the build will point to what your *working copy is*, a -RELENG branch with the last revision number you put in it.


----------



## shkhln (Jul 26, 2018)

None of this has anything to do with the part of my post you decided to have a beef with. Do you also consider the submitter of PR 189180 an idiot?


----------



## stratacast1 (Jul 27, 2018)

Spoke to soon. Still having the USB issue. There must be some ongoing bug somewhere. Maybe I should submit a bug report? It's pretty frustrating


----------



## rigoletto@ (Jul 27, 2018)

shkhln said:


> None of this has anything to do with the part of my post you decided to have a beef with. Do you also consider the submitter of PR 189180 an idiot?



Are you aware that PR is purely about "aesthetics" and would just slowdown (very little but will) the building time?

Using svnversion(1) by default would make sense when preparing updates to be distributed by freebsd-update(8) ( IDK if used because I always build from source ) but not for svn users since they are supposedly to know how to handle the tools ( there are a manual available for all of them ), and can easily run `svnversion -c /usr/src` if they are concerned about these "aesthetics".

Or simple use the GIT mirror that may do something different, IDK.


----------



## rigoletto@ (Jul 27, 2018)

stratacast1 said:


> Spoke to soon. Still having the USB issue. There must be some ongoing bug somewhere. Maybe I should submit a bug report? It's pretty frustrating



I advise you to ask on IRC ( Freenode - #freebsd or #freebsd-bugs <- this is for bugs triage ) first.


----------



## shkhln (Jul 27, 2018)

lebarondemerde said:


> Are you aware that PR is purely about "aesthetics" and would just slowdown (very little but will) the building time?



You know that you are not obliged to defend obvious bugs, right? Nobody would take away your (imaginary) community participation rights.


----------



## rigoletto@ (Jul 27, 2018)

If you _think_ this behavior is a bug you should know this is the default svn behavior, and so you should open a PR on subversion asking them to fix it, and also to get rid of svnversion(1) because this is a just a hack for their flawed source control system.


----------



## shkhln (Jul 27, 2018)

Do you seriously think so or you just trolling me now? SVN is indeed a piece of shit, but it's not an SVN bug: `svn log` is fully capable of displaying only commits belonging to a specific branch, it is also a default behavior when it is pointed at an appropriate directory. It's a basic functionality ffs.


----------



## rigoletto@ (Jul 27, 2018)

shkhln said:


> Are seriously think so or you just trolling me now? SVN is indeed a piece of shit, but it's not an SVN bug: `svn log` is fully capable of displaying only commits belonging to a specific branch, it is also a default behavior when it is pointed at an appropriate directory. It's a basic functionality ffs.



Who said anything about `svn log`? Have you any idea of how svn manage the revision numbers (tip: I already mildly explained it before)?

Did you bothered to look what the patch on that PR you pointed out does, *and or if that was already merged*? Have you even bothered to run `svnversion --help` to learn what it does?

*[EDIT]*

I will let you with all your knowledge that solve nothing to not get the thread locked what would not be nice with OP.


----------



## shkhln (Jul 27, 2018)

lebarondemerde said:


> I already mild explained it before



Right.



lebarondemerde said:


> A branch is just a copy from trunk ( or whether you are getting it from ) that can have other revisions merged inside of it later, and so it does not have its own branch specific revision numbers.



Here is a log full of merge commits: https://svnweb.freebsd.org/base/stable/11/?view=log. With revision numbers, of course. That's what uname is supposed to reference. I not sure what's difficult to understand about that.


----------

