Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2017-10-13

00:00:33 Quit wodz (Ping timeout: 240 seconds)
00:00:56 Join wodz [0] (~wodz@89-79-40-110.dynamic.chello.pl)
00:04:03 Quit petur (Quit: Leaving)
00:04:18__builtinuser890104: I was hoping to get some way to output PCM through the piezo
00:08:48__builtinprobably through pulse-width modulation
00:20:29 Quit munch (Quit: Let's blast this shit and get naked)
00:27:58 Quit alexweissman (Remote host closed the connection)
00:29:44 Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net)
00:36:08saratoga_what is the sampling rate you can drive it with?
00:37:30 Quit wodz (Quit: Leaving)
00:39:09 Join munch [0] (pls@gateway/shell/elitebnc/x-jkouwoqptxopphfn)
00:56:29Bilguspamaury should I keep running the benchmark with autoslow off from earlier?
00:57:08Bilgusoh he went to bed nm
01:00
01:06:18jhMikeSThis is embarrasing not to be able to answer: Which revision is 3.14 based off?
01:06:39BilgusAll of them?
01:07:03*jhMikeS slaps Bilgus
01:07:40jhMikeSIt was branched from something
01:07:52BilgusI changed that patch to check for else SYS_TIMEOUT it should be good, though is there any plans to ever put back the disk caching code?
01:08:09jhMikeSput back?
01:08:44Bilgusits commented out in the SYS_TIMEOUT routine
01:09:47Bilgusline 1673 /* TODO: This needs to be fixed to use the idle callback, disable it
01:09:47Bilgus * for simplicity until its done right */
01:10:19Bilgusif thats is never going back the !filling timeout for the queue can probably be upped bu a bit
01:11:54jhMikeSoh, the fill on idle code?
01:12:05Bilgusyep
01:13:36jhMikeScould just remove it since it's probably not going any time soon. it's not like it can't be pulled out of the history if it's really wanted, or perhaps done better after whatever you're fixing.
01:16:23Bilgusi'd just as soon leave it be, it works and I doubt a few less comparisons a second are going to amount to too much
01:19:15 Quit krabador (Quit: Leaving)
01:19:45 Join krabador [0] (~krabador@unaffiliated/krabador)
01:19:57jhMikeSit's disabled and probably doesn't quite work correctly
01:20:33 Quit saratoga_ (Ping timeout: 260 seconds)
01:20:33 Quit _meg (Ping timeout: 240 seconds)
01:21:19Bilgusoh I was saying leaving the timeout there at HZ/2 it checks watermark each time through
01:21:58 Quit krabador (Remote host closed the connection)
01:22:05jhMikeSyou quoted the TODO: so i thought you were talking about that disabled code
01:23:34Bilgusah sorry no I was wondering if that would be added back in there if/when it came back
01:24:33 Join _meg [0] (~notsure@211.25.203.45)
01:26:43BilgusI'm pretty sure that code is the reason the !filling timeout is HZ/2 rather than HZ or more
01:28:51 Join _jhMikeS_ [0] (~jethead71@d192-24-173-177.try.wideopenwest.com)
01:28:51 Quit jhMikeS (Disconnected by services)
01:28:52 Nick _jhMikeS_ is now known as jhMikeS (~jethead71@d192-24-173-177.try.wideopenwest.com)
01:29:00jhMikeSNot really. The watermarks are set in playback so the timeout better be shorter than the margin before the buffer goes empty.
01:32:11 Quit Ruhan (Quit: Connection closed for inactivity)
01:32:43jhMikeSflash has a 1 second margin +0/-0.5
01:35:50Bilgusoh see glad I asked
01:37:01BilgusIt seems to me though that this isn't the only place a call to rebuffer happens though so isn't it kinda redundant to have it checking in the thread and recieving calls from the codec?
01:37:29Bilgusor is it just a CYA kinda situation
01:41:01jhMikeSthe codec is really concerned with the PCM buffer level more than anything
01:42:22 Quit dys (Ping timeout: 248 seconds)
01:44:20Bilgusdo you suppose that could cause the condition I was seeing in high demand during AAC-HE? basically if it wasn't boosted before it hit time to rebuffer it would never catch up even dropping calls for cpu_boost
01:44:51jhMikeS the audio thread stays (or is supposed to stay) boosted while adding handles which should keep buffering from getting ahead and unboosting anything just because it doesn't see anything
01:45:17Bilgusyeah that wasn't happening
01:45:17__builtinjhMikeS: 8817467 I think
01:45:33jhMikeS__builtin: 95% confidence interval?
01:46:09__builtinit's a mess actually
01:46:11__builtinlemme check
01:47:09jhMikeSwas that before or after eefc7c7?
01:47:59__builtinafter
01:48:07__builtinrelease was 1 May
01:48:32***Saving seen data "./dancer.seen"
01:48:40jhMikeShmmm
01:50:55__builtinyeah, it was the few commits around 8817467
01:51:18jhMikeSBilgus: was it getting overloaded and the thread not getting into buffer_handle on time (that's the only place where it boosts)?
01:53:24jhMikeSBilgus: Is AAC HE particularly CPU intensive?
01:53:34__builtinsaratoga: (re piezo) timer frequency on the 6G is 12MHz I think
01:56:29jhMikeSBilgus: the codec could be going high priority and preventing the buffering thread from running if the target has trouble decoding that
01:57:11jhMikeSobviously if it doesn't get scheduled to run, then it can't boost itself
01:57:42jhMikeSthen again, codec should be boosting itself too if that's the case
01:58:42jhMikeSmaybe put the trigger before the open and lseek calls?
01:59:55jhMikeSit's not like those are lightweigh and don't make a thread block a lot
01:59:58 Quit Rondom (Remote host closed the connection)
02:00
02:00:49 Join Rondom [0] (~rondom@modo.nonmodosedetiam.net)
02:04:34__builtinuser890104: do you know any details about how the piezo is controlled beyond what's in piezo-6g.c?
02:24:22 Quit CH23 (Quit: Page closed)
02:59:41 Join deevious_ [0] (~Thunderbi@193.226.142.214)
03:00
03:00:59 Quit deevious (Ping timeout: 240 seconds)
03:00:59 Nick deevious_ is now known as deevious (~Thunderbi@193.226.142.214)
03:34:39BilgusJhmikeS buffer_handle already has a cpu_boost call in it but its essentially ignored according to logging it gets 2 calls for boost and neither does anything
03:35:49Bilgushttps://pastebin.com/B47yrQJw
03:37:58Bilgussorry I have one that shows it better https://pastebin.com/kVhD8iua
03:39:27Bilgusit looses it at line 83. tick: 4493, boost_counter: 84. tick: 4495, boost_counter: 1
03:39:33Bilgusloses*
03:40:19Bilguseach time boost_counter gets called it should increment or decrement the counter
03:41:31Bilgusand just after that you see count: (data_counters.remaining) go nuts
03:48:34***Saving seen data "./dancer.seen"
04:00
04:10:16 Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-vucnwziupcgmmsmp)
04:27:17user890104__builtin: i'm afraid not, i only know that it's hardwired to a timer pin (E or F) on nano 2g (maybe 3g too?)
04:37:19jhMikeSBilgus: how would it be ignored?
04:37:46Bilgusall I can figure is a race condition
04:38:11BilgusI'm looking at the audio buffer and pcm buffer noww i'll post it shortly
04:40:49jhMikeSwas it the same thread that did it in both? 82 looks like it did something
04:44:17Bilgus82 is just the call to cpu_set freq
04:44:34Bilgushen it returns it increments boost_count
04:45:21jhMikeSthe way you have it logged it should always delta +1/-1, right?
04:45:24Bilgusah you know what it is it got them out of order
04:45:49Bilgusyeah it either + or - 1
04:46:02Bilgusbut I think I might know whats happening
04:46:17Bilgusits calling for a unboost and a boost within the sma etick
04:46:50jhMikeShmmm...
04:47:00Bilguslet me get this other log up
04:47:09jhMikeSwhich target is this?
04:47:40jhMikeSif the function allows reentrancy that's probably bad
04:47:51jhMikeSat least without a mutex
04:48:06Bilgusits the fuze+
04:49:34BilgusI see the boost code has if (!cpu_boost_lock())
04:50:57jhMikeSwhich does nothing if it's not implemented (not needed on most atm)
04:51:24jhMikeSif set_cpu_frequency yields though, it better be serialized
04:52:06Bilgusyeah no define its always true ill check that next
04:53:32Bilgusno it doesn't have anything to enforce order
04:54:07Bilgushttps://github.com/Rockbox/rockbox/blob/c7f897faa4276ade8fb26a3522ff5b3041b4cd56/firmware/target/arm/imx233/system-imx233.c#L319
04:55:25saratogawhat the heck did i do with my fuze+
04:59:17Bilgushuh weird I didn't get any data in my log file for the file in question :/
04:59:37jhMikeSimx233_power_set_regulator yields which could let threads pile in there and mess it up
05:00
05:00:46jhMikeSbetter implement the boost lock/unlock before moving on
05:01:19BilgusI'm no low level kinda guy do i just set a mutex at the beginning and release at end?
05:01:38Bilgusor just enable cpu_boost_lock
05:01:45Bilguswell implement
05:03:05jhMikeSsee system-as3525.c and its header
05:03:28jhMikeSset_cpu_frequency__lock/__unlock
05:04:10Bilgusk
05:04:28jhMikeScould probably just copy that stuff over
05:10:39Bilgusuh huh lol
05:11:06Bilgusall except for there being lots of targets but ill test it on the fuze= first
05:11:11Bilgus+
05:26:16 Join almog1006 [0] (4d8bf186@gateway/web/freenode/ip.77.139.241.134)
05:27:02jhMikeSif they share the same code it's still the right setup
05:27:12 Quit Aldem (Ping timeout: 255 seconds)
05:27:15Bilgusit worked
05:27:48BilgusI have to do some more testing to say for 100% sure but It hasn't done it once in 3 runs
05:28:08Bilgusso priority inversion?
05:28:21Bilgusis that whats thats called?
05:28:33jhMikeSreentrancy but the function isn't reentrant
05:28:42Bilguslol what that is called
05:29:03jhMikeSpriority inversion is when a low priority thread keeps a higher one from executing
05:29:17Bilgusah see thats what I thought it was
05:29:28Bilgusoriginally..
05:29:55jhMikeSin that case, there's a thread yielding but another thread tries to change the frequency before one already doing it is finished
05:30:02Bilgusok I'll get this all cleaned up spit out one more log and then abandon the other patch
05:30:27Bilgusyeah you have all the buffers and codecs fighting for the same space
05:30:51Bilguswell the same function
05:31:11jhMikeSso, a race condition is basically it
05:33:22Bilguswell thank you very much mike I learned something and you lead me to the real issue
05:41:59 Quit almog1006 (Quit: Page closed)
05:44:45jhMikeSBilgus: you're welcome. you said "race condition" early on which made me check the possibility.
05:48:36***Saving seen data "./dancer.seen"
06:00
06:08:01 Quit TheSeven (Ping timeout: 258 seconds)
06:09:11 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
06:25:39 Quit TheSeven (Ping timeout: 258 seconds)
06:25:54 Join [7] [0] (~quassel@rockbox/developer/TheSeven)
06:45:53 Join ender` [0] (krneki@foo.eternallybored.org)
06:48:54BilgusHey saratoga I just ran the test_codec after implementing cpu_boost_lock and there is now little to no difference on the decode speeds between with auto_slow and without it
06:57:24 Quit alexweissman (Remote host closed the connection)
06:57:59 Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net)
06:59:45 Quit alexweissman (Remote host closed the connection)
07:00
07:00:00 Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net)
07:02:15Bilgusno nevermind :
07:14:25Bilgusfuze+ NO auto slow boosted 095.87s 183.61% 247.66Mhz
07:14:25Bilgus boosted 148.49s 118.54% 383.61MHz
07:14:25Bilgusfuze+ No auto slow no boost 416.36s 042.27% 151.40Mhz
07:14:25Bilgus NO boost 568.89s 030.94% 206.85MHZ
07:19:38 Quit Ruhan (Quit: Connection closed for inactivity)
07:30:36 Quit alexweissman (Remote host closed the connection)
07:48:38***Saving seen data "./dancer.seen"
07:57:44Bilguspamaury when you get a chance can you look at http://gerrit.rockbox.org/r/#/c/1699/ and make sure I implemented it properly specifically mutex_init()
08:00
08:11:34 Quit _meg (Ping timeout: 240 seconds)
08:13:13 Join _meg [0] (~notsure@211.25.203.45)
08:26:01 Quit deevious (Ping timeout: 260 seconds)
08:46:54 Quit duo8 (Ping timeout: 248 seconds)
08:47:35 Join almog1006 [0] (4d8bf186@gateway/web/freenode/ip.77.139.241.134)
08:54:38 Quit sielicki (Read error: Connection reset by peer)
08:55:31 Join sielicki [0] (~sielicki@unaffiliated/n1cky)
09:00
09:03:16 Join deevious [0] (~Thunderbi@193.226.142.214)
09:06:38 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
09:25:09 Quit mapache_ (Quit: Lost terminal)
09:48:39***Saving seen data "./dancer.seen"
10:00
10:08:58 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
10:11:02almog1006pamaury: Hi.. Thank you very much! I'm done translating the entire firmware
10:12:42 Quit TheEaterOfSouls (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823])
10:13:28 Join MrZeus [0] (~MrZeus@81.144.218.162)
10:15:55pamauryalmog1006: I haven't made progress on repackin
10:17:36pamauryBilgus: I see, indeed I thought the boost code was locking already, and my code is not reentrant
10:17:45pamaurydid that solve the problem? The code looks good to me
10:24:11 Join petur [0] (~petur@rockbox/developer/petur)
10:28:30almog1006pamaury: However thank you very much for your unpacking tools:)
10:28:35almog1006Do you have an estimate when you write the repacking codes?
10:29:04 Join PimpiN8 [0] (~textual@145.132.155.235)
10:29:43wodzpamaury: Have you got my email?
10:30:33pamaurywodz: yes thanks
10:30:46wodzgreat
10:31:01pamauryalmog1006: no, I lost my reverse engineering work on the
10:31:15pamaurycode from which I got the unpacker code
10:31:24wodzI have version 5.20 somewhere as well if you are interested.
10:31:38pamauryand there is something wrong with it I think, I will need to re-disassemble it
10:33:00wodzpamaury: any progress with amsv2 rom?
10:33:18pamaurywodz: a bit, but the code is so intricate I only mke baby steps at a time
10:34:00almog1006pamaury: Does that mean I'm in a big problem?
10:34:07 Join dys [0] (~dys@x5f71e881.dyn.telefonica.de)
10:34:51wodzalmog1006: That means you need to stimulate pamaury's motivation
10:37:08almog1006My luck is that he needs it anyway for Rockbox
10:40:11wodzalmog1006: Not he. I need this tool for my work on atj213x
10:42:09almog1006So we're in the same boat
10:43:40wodzalmog1006: The difference is that I have tons of other work before I'll need repacking working.
10:51:26 Quit pamaury (Ping timeout: 240 seconds)
11:00
11:30:34 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
11:48:40***Saving seen data "./dancer.seen"
13:00
13:15:01 Join CH23 [0] (4dfa0218@gateway/web/freenode/ip.77.250.2.24)
13:16:52CH23I have in my hands a sandisk cruzer blade 8gb with a NAND chip SDTNPNAHEM-008
13:18:04CH23homerun on first try
13:23:53 Join smoke_fumus [0] (~smoke_fum@37.151.179.94)
13:25:12CH23I also have a Sandisk cruzer Edge with same NAND
13:28:48CH23and finally Sandisk Cruzer Micro with SDTNMNAHSM-004G
13:33:53CH23man_in_shack: do you know how long it usually takes for something to ship from your location to mine>
13:36:38wodzCH23: Are you going to transplant nand chip from pendrive into clip/clip+/zip ?
13:36:50CH23clip+ indeed
13:37:10wodzCH23: might be interesting to decap broken nand chip
13:38:13CH23how would i do that
13:41:37wodzCH23: Its 'a bit' involved process http://zacsblog.aperturelabs.com/2013/02/decapping-integrated-circuits-using.html
13:43:04CH23how about i mail it to you instead :P
13:43:59wodzCH23: Currently I have no longer access to lab currently :/
13:44:31 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:45:06CH23i'm doing all of this on a 9 year old laptop, and soldering stuff for stained glass soldering lol
13:48:44***Saving seen data "./dancer.seen"
14:00
14:02:22CH23the cruzer blade has sandisk files on it dated 24th of august 2011, so this NAND was still used recently.
14:05:13CH23cruzer edge is exactly the same
14:24:49 Quit mmint (Ping timeout: 258 seconds)
14:28:33 Join mmint [0] (~mmint@unaffiliated/mmint)
14:35:10 Quit jhMikeS (Ping timeout: 248 seconds)
14:36:55man_in_shackCH23: no, but i haven't sent it yet. will send on monday. is friday 11:30pm here now
14:45:50BilgusPamaury it seems to have fixed the problem although I did get a hang at some point in testing but that could just be total coincidence as I couldn't reproduce again after.
14:56:16BilgusAlso FWIW the boost code is locking as far as boost_count only boosts on ++0 and unboosts on −−1 where as AFAICT the mutex holds the states per thread and doesn't let other threads unboost
14:57:19Bilgusso It might be more like the codec/buffer/audio code is really the issue and it needs to be reworked
14:57:59Bilgusbut maybe we just need to implement boost lock across the code
15:00
15:00:56 Quit man_in_shack (Ping timeout: 260 seconds)
15:05:36BilgusI Imagine its still the case that under high load the other devices would probably exhibit the same behaviour
15:08:24Bilgusmaybe it would be a better idea to force inline cpu_boost and have it carry a static bool
15:24:45Bilgushuh trigger_cpu_boost is already doing that ???
15:24:56 Quit wodz (Ping timeout: 264 seconds)
15:26:54 Join man_in_shack [0] (~chat@unaffiliated/man-in-shack/x-4279753)
15:29:58 Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:e4d3:4538:2553:fd81)
15:34:02 Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net)
15:44:29pamauryBilgus: I'm not sure I'm following you
15:45:04Bilgustrigger_cpu_boost works on a per thread basis
15:45:55pamauryBilgus: yes but the locking is done at the global level
15:46:05Bilgusbut there are several places where cpu_boost is used in the codebase now its ok when it does a boost ##SOME ACTION## unboost
15:46:33Bilgusbut for instance in the backlight fading code it has several calls to unboost
15:47:09pamaurybasically at the thread level, you can't nest calls to {trigger,cance}_cpu_boost, the boosting is just a boolean. But then it calls cpu_boost which is global and counts boost/unboost calls and does the locking
15:47:19BilgusI'm pretty sure it should only be taking one patch from boost to unboost but if it didn't then it would cause the same problem
15:47:40Bilgussure when you actually use trigger_cpu_boost
15:48:03Bilgusbut if you call cpu_boost directly there is no guarantee..
15:48:13pamauryyou can call cpu_boost directly, it still does the locking and the counting
15:48:13 Quit petur (Remote host closed the connection)
15:48:22Bilgusno
15:48:34pamauryjust look at the code, system.c
15:48:37Bilgusit does count but not lock
15:48:46***Saving seen data "./dancer.seen"
15:48:59pamauryit does, locking is not done in thread.c, it's done in system.c
15:49:15Bilgusin as far as count+ or count- but it doesn't protect the code that has called trigger_cpu_boost
15:49:30pamauryprotect from what?
15:50:13Bilgusok ill give you a for instance
15:51:13BilgusI'm in thread foo I call trigger_cpu_boost(true) ok boost_count+=1 ..BC now == 1
15:51:44Bilgusi'm in thread BAR and I call cpu_boost ok BC ==2
15:52:18Bilgusnow I call cpu_boost(false) BC = 1
15:52:29BilgusI call it again BC == 0
15:52:42Bilgusi go back to thread foo oh wait no cpu boost
15:54:03Bilgusnow look at https://github.com/Rockbox/rockbox/blob/03dd4b92be7dcd5c8ab06da3810887060e06abd5/firmware/backlight.c
15:54:46pamauryBilgus: but that's broken code you are describing. If you call cpu_boost, you must call cpu_unboost. and if you call trigger_cpu_boost then you must call cancel_cpu_boost.
15:55:04pamauryI'm just pointing out that cpu_boost and trigger_cpu_boost are not the same, they do not do the same thing
15:56:08Bilguswell they do the same thing as in they both call cpu_boost and ++ or −− the counter
15:56:35pamauryno
15:56:54pamauryas I explained before, trigger_cpu_boost tracks per thread with a boolean
15:57:17Bilgushttps://github.com/Rockbox/rockbox/blob/03dd4b92be7dcd5c8ab06da3810887060e06abd5/firmware/kernel/thread.c#L1501
15:57:25pamauryso if a thread does:
15:57:25pamaurytrigger_cpu_boost -> BC=1
15:57:25pamaurytrigger_cpu_boost -> BC=1 (because thread was already boosting, it's ignored)
15:57:25DBUGEnqueued KICK pamaury
15:57:25pamaurycancel_cpu_boost -> BC=0
15:58:25pamaurytrigger_cpu_boost is per-thread and means "this thread needs to boost now" whereas cancel_cpu_boost means "this thread doesn't need to boost now"
15:58:46Bilgussure but if you are boosted with trigger and I call cpu_boot(false) 2x you are no longer boosted
15:59:00Bilguscpu_boost**
15:59:12pamauryyeah but you don't want to do that, that's the whole point
15:59:23BilgusI know look at backlight.c
15:59:47pamauryI don't see a problem, backlight.c first calls cpu_boost(true) then cpu_boost(false). backlight is not per-thread
15:59:51Bilgusand search for cpu_boost
16:00
16:00:12Bilgushow many times can cpu_boost(flase) be called?
16:00:16Bilgusfalse
16:01:02pamaurycounting the occurrences with grep is just wrong, you may have two code paths that call cpu_boost(false) and which are mutually exclusive
16:01:15Bilgussur elook at the code though
16:02:05pamauryand?
16:02:57pamauryif you see a bug in backlight then fix it, I don't know enough about backlight.c to spot a bug
16:04:33Bilgusok
16:05:09pamaurycpu_boost(true) is called when the timer is set. when the timer expies, cpu_boost(false) is called. The other cpu_boost(false) is called on BACKLIGHT_FADE_FINISH but when BACKLIGHT_FADE_FINISH is sent, the timer is unregistered
16:05:17pamaurythus there is no way cpu_boost(false) can be called twice imo
16:05:43pamauryat least no obvious way
16:09:49Bilguswell its the first that caught my eye esp since the fuze has backlight fading
16:10:29Bilgusthe other is audio_path.c which doesn't apply atm and tag cache thats just a mess
16:11:51 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
16:12:43pamauryI mean even if there was a problem with it, that could not cause a hang though, the boost counter would simply be wrong
16:14:02Bilguswhich when you are trying to boost to decode a file would not be the best?
16:16:41pamauryyeah but have you encountered this bug? (after fixing locking)
16:19:49Bilgusno
16:20:08Bilgusbut I just don't see how that could actually be it
16:20:44BilgusI think it is just covering up (making impossible) the real problem
16:20:48 Join petur [0] (~petur@rockbox/developer/petur)
16:21:20Bilgusbut if thats true then every device actually needs locking
16:21:47Bilgusand no the backlight one didn't do it
16:25:00pamauryBilgus: the locking is done in cpu_boost, I don't see how backlight has anything to do with locking
16:25:19pamaurylocking needs to be done when set_cpu_frequency is not reentrant
16:25:28pamauryimx233's code was not reentrant
16:26:19 Join amayer [0] (~amayer@24.152.198.8.res-cmts.eph2.ptd.net)
16:28:43Bilguswell I'm sure you know more than I do but I just don't see how that could actually come into effect with trigger_cpu_boost working the way it does?
16:29:45 Join krabador [0] (~krabador@unaffiliated/krabador)
16:46:13 Quit almog1006 (Quit: Page closed)
16:54:15BilgusOk I get it I had to think about it for awhile but I think I grasp what you mean
16:56:53 Quit krabador (Remote host closed the connection)
16:59:56 Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-pobfgbgrzasazfzw)
17:00
17:28:04 Join krabador [0] (~krabador@unaffiliated/krabador)
17:46:18 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:48:50***Saving seen data "./dancer.seen"
18:00
18:06:23 Quit pamaury (Ping timeout: 248 seconds)
18:18:26 Quit krabador (Ping timeout: 240 seconds)
18:34:47 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
18:41:56 Quit sparetire (Ping timeout: 240 seconds)
18:44:52 Join sparetire [0] (~sparetire@unaffiliated/sparetire)
19:00
19:15:46 Join detectiveaoi [0] (~detective@130.218.12.236)
19:16:14 Quit detectiveaoi (Remote host closed the connection)
19:18:59 Join krabador [0] (~krabador@unaffiliated/krabador)
19:38:54 Quit michaelni (Read error: Connection reset by peer)
19:42:33 Join lebellium [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr)
19:48:54***Saving seen data "./dancer.seen"
19:55:28 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at)
20:00
20:05:26 Quit dys (Ping timeout: 240 seconds)
20:12:24 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
20:13:53 Join dys [0] (~dys@x5f71d060.dyn.telefonica.de)
20:28:33 Quit dys (Ping timeout: 255 seconds)
20:42:49 Quit bzed (Remote host closed the connection)
20:43:04 Join bzed [0] (~bzed@shell.bzed.at)
20:51:38 Join p3tur [0] (~petur@78-23-23-252.access.telenet.be)
20:51:38 Quit p3tur (Changing host)
20:51:38 Join p3tur [0] (~petur@rockbox/developer/petur)
20:56:55 Join dys [0] (~dys@x5f72797e.dyn.telefonica.de)
21:00
21:48:57***Saving seen data "./dancer.seen"
22:00
22:20:57 Quit krabador (Quit: Leaving)
22:36:23__builtinuser890104: ok, thanks!
22:36:32__builtinit's timer A on the 6G, it seems
22:38:20__builtinI think I should be able to control it directly, though
22:39:10__builtinthe pin is P0_0, which supports GPIO
22:39:30 Quit amayer (Quit: Leaving)
22:41:44__builtinthis datasheet is nice :)
23:00
23:02:09 Quit The_Prospector (Quit: when in doubt, kernel panic)
23:05:12 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman)
23:13:28 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com)
23:21:38__builtinah, figured it out
23:48:58***Saving seen data "./dancer.seen"
23:58:34 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823])

Previous day | Next day