Frequent interruptions of IO in FreeBSD 11.2?

nihr43

Member

Thanks: 18
Messages: 45

#26
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

Well-Known Member

Thanks: 85
Messages: 267

#27
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

Daemon
Developer

Thanks: 751
Messages: 1,654

#28
There more revision numbers pointing to CURRENT than to STABLE. I suppose I don't know how this works either.
There may have dozens of commits in -CURRENT on a single day.
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)...
 
OP
OP
stratacast1

stratacast1

Active Member

Thanks: 20
Messages: 183

#31
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

Member

Thanks: 18
Messages: 45

#32
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.
 

Rigoletto

Daemon
Developer

Thanks: 751
Messages: 1,654

#34
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.
 
OP
OP
stratacast1

stratacast1

Active Member

Thanks: 20
Messages: 183

#36
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

Daemon
Developer

Thanks: 751
Messages: 1,654

#37
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

Daemon
Developer

Thanks: 751
Messages: 1,654

#38
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.
 

Rigoletto

Daemon
Developer

Thanks: 751
Messages: 1,654

#40
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

Well-Known Member

Thanks: 85
Messages: 267

#41
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.
 
Last edited:

Rigoletto

Daemon
Developer

Thanks: 751
Messages: 1,654

#42
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

Well-Known Member

Thanks: 85
Messages: 267

#43
I already mild explained it before
Right.

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.
 
Top