tag:blogger.com,1999:blog-6469704299235308349.post3381949067817523224..comments2024-03-28T15:50:13.644+11:00Comments on -ck hacking: linux-4.20-ck1, MuQSS version 0.185 for linux-4.20ckhttp://www.blogger.com/profile/02904761195451530213noreply@blogger.comBlogger70125tag:blogger.com,1999:blog-6469704299235308349.post-86774808137904165882020-06-20T07:04:01.402+10:002020-06-20T07:04:01.402+10:00psi: task underflow! cpu=0 t=2 tasks=[0 0 0 1] cle...psi: task underflow! cpu=0 t=2 tasks=[0 0 0 1] clear=c set=0<br /><br />on 5.7.4-ck1 on a ryzen 1600Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-70331400643691369872019-04-13T13:57:38.784+10:002019-04-13T13:57:38.784+10:00[ 1.535455] ------------[ cut here ]-----------...[ 1.535455] ------------[ cut here ]------------<br />[ 1.535460] Current state: 1<br />[ 1.535464] WARNING: CPU: 1 PID: 0 at 0xffffffff8108c865<br />[ 1.535466] Modules linked in:<br />[ 1.535469] CPU: 1 PID: 0 Comm: MuQSS/1 Not tainted 5.0.7-ck1 #3<br />[ 1.535471] Hardware name: System manufacturer System Product Name/Crosshair IV Formula, BIOS 3029 10/09/2012<br />[ 1.535474] RIP: 0010:0xffffffff8108c865<br />[ 1.535476] Code: 04 77 29 89 f1 ff 24 cd 38 76 a0 81 80 3d 53 1b bd 00 00 75 17 89 c6 48 c7 c7 90 c6 ad 81 c6 05 41 1b bd 00 01 e8 7b ae fa ff <0f> 0b 48 83 c4 08 5b c3 48 8b 47 60 48 85 c0 75 64 83 fe 03 89 73<br />[ 1.535480] RSP: 0018:ffff888437c43f50 EFLAGS: 00010082<br />[ 1.535482] RAX: 0000000000000010 RBX: ffff888437c504c0 RCX: ffffffff81c1fdb8<br />[ 1.535483] RDX: 0000000000000001 RSI: 0000000000000086 RDI: ffffffff81f8fcac<br />[ 1.535485] RBP: 7fffffffffffffff R08: 00000000000001f0 R09: 0000000000000000<br />[ 1.535487] R10: 0720072007200720 R11: 0720072007200720 R12: 7fffffffffffffff<br />[ 1.535489] R13: ffff888437c56900 R14: ffff888437c569f8 R15: ffff888437c56a38<br />[ 1.535491] FS: 0000000000000000(0000) GS:ffff888437c40000(0000) knlGS:0000000000000000<br />[ 1.535493] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br />[ 1.535494] CR2: 0000000000000000 CR3: 0000000001c0c000 CR4: 00000000000006e0<br />[ 1.535496] Call Trace:<br />[ 1.535498] <br />[ 1.535500] 0xffffffff8108e7cb<br />[ 1.535502] 0xffffffff810817cb<br />[ 1.535503] 0xffffffff81601568<br />[ 1.535505] 0xffffffff8160117f<br />[ 1.535506] <br />[ 1.535507] RIP: 0010:0xffffffff8100f592<br />[ 1.535509] Code: 0f ba e0 24 72 11 65 8b 05 bb eb ff 7e fb f4 65 8b 05 b2 eb ff 7e c3 bf 01 00 00 00 e8 17 e0 07 00 65 8b 05 a0 eb ff 7e fb f4 <65> 8b 05 97 eb ff 7e fa 31 ff e8 ff df 07 00 fb c3 66 66 2e 0f 1f<br />[ 1.535512] RSP: 0018:ffffc9000007bf00 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13<br />[ 1.535515] RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000001<br />[ 1.535516] RDX: 000000005b7f1466 RSI: 0000000000000001 RDI: 0000000000000380<br />[ 1.535518] RBP: ffffffff81c601a8 R08: 0000000000000000 R09: 0000000000019840<br />[ 1.535520] R10: 0000001e3c819be7 R11: 000000007260bc7a R12: 0000000000000000<br />[ 1.535522] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br />[ 1.535524] 0xffffffff8105bd2f<br />[ 1.535526] 0xffffffff8105bf5b<br />[ 1.535527] 0xffffffff810000d4<br />[ 1.535529] ---[ end trace 71fe021b29fa5d1f ]---<br /><br />I am having this problem on all my phenom 2 systems, looks like some kind of interrupt problem, I tried to enable nothreadedirqs option and also enabled fix for broken boot irqs option but none of them had any effect on this, I enabled stack traces but for some reason he don't show them :x<br /><br />anyone might know what this is ? I searched around and found this which may be helpful: https://pastebin.com/y0aXvBNP<br />(this is not mine but it looks very much like mine)<br /><br />thank :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-56339499522210477842019-03-10T23:00:20.751+11:002019-03-10T23:00:20.751+11:00Thanks.Thanks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-49574517136374625602019-03-10T08:58:44.146+11:002019-03-10T08:58:44.146+11:00The patches are uploaded. Too busy to announce rig...The patches are uploaded. Too busy to announce right now.Con Kolivashttps://www.blogger.com/profile/05355844537881606702noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-74002662015322351192019-03-10T07:45:45.145+11:002019-03-10T07:45:45.145+11:00How to git2patch(es)?How to git2patch(es)?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-74853703572436383522019-03-10T00:40:27.416+11:002019-03-10T00:40:27.416+11:00looking forward to the availability of the patches...looking forward to the availability of the patches. Somehow I am too stupid to create them from git on my own ...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-21102294373211945592019-03-09T21:03:23.392+11:002019-03-09T21:03:23.392+11:00It's actually already up on git. Lacking only ...It's actually already up on git. Lacking only separate patches and an announce.Con Kolivashttps://www.blogger.com/profile/05355844537881606702noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-7224551204522015272019-03-06T10:27:17.604+11:002019-03-06T10:27:17.604+11:00So much misinformation... MuQSS has nothing to do ...So much misinformation... MuQSS has nothing to do with BFQ, nor anything to do with any I/O schedulers. -ck also has nothing to do with BFQ nor any I/O schedulers.Con Kolivashttps://www.blogger.com/profile/05355844537881606702noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-42456326607429468932019-03-06T09:04:07.580+11:002019-03-06T09:04:07.580+11:00MuQSS not supporting cgroups is exactly the proble...MuQSS not supporting cgroups is exactly the problem. Some time ago I predicted, in response to some proposed patches, the removal of the legacy IO schedulers.<br /><br />As of right now, I am also predicting that the hierarchical support (cgroup support; see KConfig for reference) of BFQ will become non-optional, it will become mandatory. An integral part of BFQ. At that point we can expect MuQSS to no longer fully support BFQ. And since BFQ is the only remaining viable option for an IO scheduler on non-SSD devices (MQ-DEADLINE is just a joke for heavy IO), well... I think the pattern should become obvious.<br /><br />Why do you think the legacy IO schedulers were removed? The argument was to simplify the code, maintainability. Obviously they are going to play that card for blk_mq and the mq schedulers as well. At which point the aforementioned hierarchical support of BFQ will become non-optional.<br /><br />Additionally, BFQ is being pushed HARD as the de-facto standard IO scheduler. And cgroups are likewise being pushed hard as the de-facto standard to priority handling.<br /><br />Regarding CFS not being changed -- CFS has fully supported cgroups from the day those were implemented. Since it predates cgroups (although not by much).<br /><br />Continuing not support cgroups will probably be fine for 5.0, probably even for the remainder of 2019. But at some point, they will simply become unavoidable. Probably mid-2020, I'm guessing.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-41721595798985112442019-03-06T04:44:18.445+11:002019-03-06T04:44:18.445+11:00How would any of the IO scheduler changes require ...How would any of the IO scheduler changes require changes to MuQSS? Nothing was changed within the kernel's default CPU scheduler either for that reason.<br /><br />Also, there were barely any changes to BFQ, definitely nothing related to cgroups. Additionally MuQSS has never supported cgroups, so even if there was any such changes, I don't think they would require huge amounts of work.<br /><br />Energy Aware Scheduler is probably the biggest scheduler related change, but I'm not sure whether that requires big changes for MuQSS.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-71156101159915307782019-03-05T04:22:38.292+11:002019-03-05T04:22:38.292+11:00Yes.
Thanks.
MUQSS is still the best.
Well worth t...Yes.<br />Thanks.<br />MUQSS is still the best.<br />Well worth to wait.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-7585204595498945692019-03-05T02:56:30.951+11:002019-03-05T02:56:30.951+11:00Might be a while, I'm guessing. With the compl...Might be a while, I'm guessing. With the complete removal of legacy IO schedulers (yes, it happened) and BFQ's interaction with cgroups, MuQSS might need some work to be fully compatible with 5.0.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-19575619810632919692019-03-04T22:39:07.120+11:002019-03-04T22:39:07.120+11:00Any ETA for 5.0?Any ETA for 5.0?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-10156675372788687152019-02-23T08:51:48.615+11:002019-02-23T08:51:48.615+11:00Kind of late to the party, but you can refer to Ze...Kind of late to the party, but you can refer to Zen Kernel's MuQSS branch if you're having trouble building - we probably already ran into and fixed many build problems due to stable patches.<br /><br />https://github.com/zen-kernel/zen-kernel/commit/7c660f6524371c3f9d693deb9595ff6c0725942cdamentzhttps://www.blogger.com/profile/07613469397631531886noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-9371706191348781902019-02-18T02:56:43.958+11:002019-02-18T02:56:43.958+11:00Ok, thanks.Ok, thanks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-1667060321027850342019-02-18T00:02:54.251+11:002019-02-18T00:02:54.251+11:00It is the MuQSS patch, and not the whole -ck patch...It is the MuQSS patch, and not the whole -ck patch set.<br /><br />You can either replace this "fixed" patch in your -ck patchset for a full -ck kernel, or use it as a single patch if you only want MuQSS. (My github has the full -ck patchset if interested in that).Sveinar Søplerhttps://www.blogger.com/profile/18401720133659243541noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-34727187516883050242019-02-17T13:46:19.088+11:002019-02-17T13:46:19.088+11:00So I use just that one^ for MUQSS only (no ck)?So I use just that one^ for MUQSS only (no ck)?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-47635590990508875262019-02-17T06:42:09.270+11:002019-02-17T06:42:09.270+11:00All good.
Thanks.All good.<br />Thanks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-56728783220419886512019-02-17T02:27:47.573+11:002019-02-17T02:27:47.573+11:00And this was obviously meant to be a reply for the...And this was obviously meant to be a reply for the >=4.20.8 patch comments... :|ooonoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-21263943427041668982019-02-17T02:24:18.170+11:002019-02-17T02:24:18.170+11:00the pastebin is missing a newline at the end which...the pastebin is missing a newline at the end which results in the error.<br />It still applies fine regardless, as stated at the last line of patch output (or you can add the newline yourself if the error bothers you)ooonoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-21400079082991530752019-02-16T22:43:22.072+11:002019-02-16T22:43:22.072+11:00Updated patch: https://github.com/SveSop/kernel_cy...Updated patch: https://github.com/SveSop/kernel_cybmod/blob/MuQSS/0001-MultiQueue-Skiplist-Scheduler-version-v0.185.patch<br /><br />I should probably have named it _v2.patch or something, but well.. Soon 5.0 kernel, and it will be a new version anyway :)<br />Sveinar Søplerhttps://www.blogger.com/profile/18401720133659243541noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-47239522403232356362019-02-16T22:00:12.179+11:002019-02-16T22:00:12.179+11:00Is this a problem?Is this a problem?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-57303630225359432762019-02-16T12:24:14.653+11:002019-02-16T12:24:14.653+11:00I get this with just the MUQSS patch:
(Stripping ...I get this with just the MUQSS patch:<br /><br />(Stripping trailing CRs from patch; use --binary to disable.)<br />patching file kernel/sched/MuQSS.c<br />patch unexpectedly ends in middle of line<br />Hunk #1 succeeded at 227 with fuzz 1.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-49026591626570956582019-02-16T07:38:50.509+11:002019-02-16T07:38:50.509+11:00Thanks.Thanks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-75541882255228280052019-02-16T04:15:07.570+11:002019-02-16T04:15:07.570+11:00Indeed, the above change looks correct and seems t...Indeed, the above change looks correct and seems to work.<br /><br />Here's a patch against -ck patched kernel sources: https://pastebin.com/EPMEir9booonoreply@blogger.com