#qi-hardware IRC log for Friday, 2014-05-09

whitequarkhmm: http://hackaday.com/2014/05/08/testing-the-efficiency-of-pcb-etchants/02:05
kyakyeah, this exact notion of "proper OS" had been preventing me from using Linux on desktop for many years07:23
whitequarkdidn't prevent me, but it's just not good design. or should I say, lack of any design whatsoever?07:27
whitequarkneither unix nor c were ever designed; they went from "kept together with wd-40 and duct tape" to "the committee decides where do we add more wd-40 and duct tape"07:28
whitequarkand if you dare to tear off even the tiniest chunk of the duct tape, the whole contraption folds07:29
whitequarkI'm not even exaggerating07:29
kyakso you just went blaming from unix to c, good move :)07:32
whitequarkwell, they're tightly related. and suggesting unix as an example of proper... anything is absurd07:32
whitequarkpractically everything else that exists is just even more horrible, though07:33
kyakthat's what i was going to say.. there is no "proper"07:33
whitequarkthere is "proper", deep within research labs and the like07:34
whitequarksadly, software, especially free software, is governed by network effects, not quality07:34
kyaksometimes the research labs are even more far away from proper, untied to real life and real application07:34
whitequarksome of them are, some of them are far more practical than anything the industry offers07:35
whitequarkhow about, I dunno, a JavaCard with a sandbox that is mathematically proven to be impenetrable?07:35
whitequarksomething something openssl chrome firefox javascript07:36
kyak50 years after, somebody proves that your mathematics is wrong07:36
whitequarknot going to happen.07:36
kyakand laughs at "shitty design"07:36
whitequarkyou still have to care about a bunch of other kinds of attacks, say, side-channel attacks allowing to extract key material07:36
kyakwell, designers of unix definitely had no idea you wanted you flash drive mount automatically07:37
whitequarkbut at least a random guy from the street can't execute and persist any code he likes on your "secure" container07:37
kyaknew technologies arise, making older designs obsolete. You can't account for everything07:38
whitequarkdesign of unix was outdated right when it has appeared, and not too far long in the future everyone just started adding silly extensions07:38
kyaki'm not sure about that..07:39
whitequarkabout what, unix wars or that it was broken from the start?07:39
kyakthat unix was outdated right when it appeared07:39
whitequarktake a look at ALGOL-68 and Burroughs B5000, for example07:40
whitequarkand that wasn't exactly rocket science at the point07:40
whitequarkif you think unix is somehow innovative in timesharing, virtual memory, etc, etc, just take a look at the design of THE multiprogramming system07:41
kyakthere is no "good" and "evil", i'm pretty sure what you mentioned had its drawbacks. There is a reason unix survived07:41
whitequarkthat reason is not technical. it's called "network effects"07:42
kyaki doubt that07:42
whitequarkwell, it's easy to eliminate technical reasons. you just have to look at the design of contemporary systems07:42
whitequarkso when you eliminate the impossible, the rest, however doubtful, must be the truth07:43
kyaki prefer to believe in natural selection.. the better survices, the worse dies07:44
kyakif unix survived, and nobody knows about Burroughs B5000, than unix is better - easy.07:44
whitequarkmore fit ` technically better. exactly what I'm telling you about.07:45
kyakwell, this just proves that fitness is not all about technical greatness07:46
whitequarkand there's nothing good about that07:46
whitequarkfitness considers immediate, short-term gain, usually sacrificing long-term one07:47
kyakdon't even talk about long term in this area...07:47
whitequarkdo I have to point you to the amount of idiotic vulnerabilities in software written in C?07:47
whitequarkdo I have to remind you that today, practically any system is vulnerable if poked just a little bit harder than usual?07:48
whitequarkdo I have to explain that this does not have to be the case?07:48
kyakdo i have to point out that C language is all about trade off?07:48
kyakthe tools is more dangerous, but allows to do more07:49
kyakand sometimes more efficiently07:49
kyakif you don't like it, choose another tool07:49
whitequarkI can't, that's the whole problem07:49
whitequarkall the OSes are written in C. my bank uses C. my hospital uses C. the thing in my pocket that has all the information about me uses C. so on.07:50
kyakthen the time for the "new" tool can not come yet07:50
whitequarkso you're saying, ummmm, "C is good because network effects prevent adoption of anything else".07:51
whitequarkthat's amazing logic, I can use it to justify anything07:51
kyakwhen people reached the limits of wooden tools, then invented how to used stone tools07:51
kyakso it seems like C yet has something to say07:51
whitequarkand talking about the tradeoffs... it's basically a UI failure. C makes it very easy to write dangerously incorrect code07:53
whitequarkit could make that hard, but didn't. thus, bad design.07:54
whitequarkwhen your cars trap people inside on collisions and catch fire, you don't say "that's a design choice", whether it was one. you recall the damn cars and make sure this never happens again07:54
whitequarkbut I guess the field will be so immature until most of the people who think suck tooling is OK die.07:55
kyakthat's why none of automotive companies writes C code by hand anymore :)07:55
whitequarkof course they do, MISRA-C is explicitly targeted at handwritten C code07:56
kyakhave you heard of MISRA-AC-AGC?07:56
whitequarkhow widely is it deployed?07:56
kyakdon't get me started about automatic code generation, i've been in the automotive industry for years07:56
whitequarkand anyway, automotive even has it relatively good. consumer is where the horror truly lies07:57
whitequarkI grant you that automotive, or aerospace, are able to deal with the fallout (but at what cost?)07:57
kyak..and ACG is used very widely07:57
whitequarknow look at openssl07:57
kyakyeah, thats another story07:58
whitequarkor linux--local privilege escalation is so often, people don't even talk about it a lot07:58
kyakthey should learn the lesson: "everyone needs formal verification"07:58
whitequarkhave you seen Coq?07:58
larscits funny. A lot of companies now want to use Linux in the automotive segement, but the Linux kernel coding sytle clashes with the MIRSA coding style.07:58
whitequarkor CompCert?07:58
kyaknope, i've seen Polyspace07:58
whitequarkabsolutely do take a look at CompCert. it's a formally verified C compiler that optimizes code at about GCC's -O107:59
whitequarkmeaning there can be no miscompilation.07:59
whitequarkthere's the issue of verifying the code itself, but it's another one :)07:59
kyakintersting.. then you have a look at Polyspace, it's a formal verification tool (using abstract interpretation) that works on C/C++/Ada code08:00
whitequarkI will. have you also seen KLEE?08:00
kyaki wonder how CompCert goes about DO-178 qualification...08:00
whitequarkthat's LLVM's abstract interpreter08:00
whitequarkDO-178 is one of the goals for CompCert development, yes. no idea if they actually got the papers08:01
kyakit's a big pain in the industry, actually.. the lack of qualified compiler08:01
kyakand the companies do weird things to prove their object code is correct to source code...08:01
whitequarkseems you need to cooperate with your friends from academia a bit more ;)08:02
kyakwell.. there will always be a gap between research and development08:03
kyakwhitequark: please point me to KLEE, google shows irrelevant results08:04
whitequarkKLEE is a bit... dated08:05
whitequarkbut in right hands, it could still be very much useful (if sometimes not directly)08:05
whitequarkkyak: there's also Coq, which is the tool you use to efficiently build verified software08:06
kyaki'll have a look08:06
whitequarkI'm currently working through a book, Software Foundations, explaining how to use it08:06
whitequarkbut it's a huge pain in the ass to deal with, unfortunately08:06
whitequarklike, I've spent six hours yesterday trying that my Peano-representation-to-binary-digits converter is correct, which is probably one of the most basic things you could imagine08:08
whitequarkI failed08:08
whitequarktrying to prove*08:08
kyakwhitequark: btw, there are tools that let you automatically generate tests for 100% model coverage (the model, from which the code is generated). It uses formal methods, so 100% coverage is guaranteed (unless there is "dead code", which you then automagically find)08:08
whitequarkwhat about dynamical invariants?08:08
kyakwhat's that?08:08
kyaklike, polymorphism?08:08
whitequarkhrm, no. something like "if(fuel_low && fuel_high) {", that can't ever be dynamically true, but there's no way to statically infer that08:09
whitequarkhow would your tool handle it?08:09
whitequarkI'm not talking about the case when there's two sensors for fuel_low and fuel_high; that's just the differently interpreted output from a single sensor.08:09
kyakah, it would prove it unsatisfiable08:10
whitequarkas expected; and what'd you do?08:10
kyakthe toos would show it to you, it is you, the developer, who needs to justify08:10
kyakthe tools knows nothing about the physics behind the system, just the mathematics.. 08:11
whitequarkwell, nevermind, actually. the regulations usually dictate a highly restricted style of programming anyway08:11
whitequarkwhat I mean is that such tools are OK for some limited areas, but for other places rapidly become inapplicable08:12
whitequarkyou can verify an L4 microkernel, say (it has been done), but there probably will not be a verified kernel for desktops for decades08:12
whitequarkit's just too complex08:12
kyakthese tools are good for algorithms, that is, the application software. It is indeed very hard to apply to system software08:13
kyakor basic software, if you wish08:13
whitequarkthere are still ways to gain confidence in the behavior of the overall system, namely split the system into smallest components with least authority and prove that the part that communicates messages is correct08:13
whitequark(the microkernel approach, if you'd like)08:13
whitequarke.g. this has been done to get a "verified" browser, where Webkit is ran in an OS sandbox, and only the controlling part is verified08:14
whitequarkbut they require a radical change in the software architecture, which is even less likely to happen than switch from C or something08:14
kyakand probably radical changes in minds..08:15
whitequarkwell, that's exactly the problem :)08:15
whitequarkconvince people that formal verification is good. then, convince them it's possible. then, convince they should invest in it.08:16
kyakwhitequark: anyway, here's the formal model verifier: http://www.mathworks.com/products/sldesignverifier/ and the code prover: http://www.mathworks.com/products/polyspace-code-prover/08:16
whitequarkany one of the three steps is nearly impossible to achieve08:16
kyakhave fun watching webinars, if you have some time :)08:16
whitequarkugh. my brain doesn't accept audio information08:16
whitequarkanyway, I have an overall understanding of formal methods08:17
kyakif you want to get your hands dirty, just let me know - i can issue you a temporary license08:17
whitequarkoh, now this is getting interesting08:17
whitequark(although I still prefer FOSS for the reason that I can share the results and knowledge...)08:18
larscyou are now a licensed code verifier08:18
whitequarkkyak: oh also, do take a look at clang-analyzer too08:18
whitequarkit's a best-effort thing, but it catches a lot of bugs in practical software, like Linux08:18
kyakallright, have to go now. whitequark, i will :) saved a couple of bookmarks08:18
larscThis morning I was wondering how hard it is to build a verification tool that automatically finds race conditions in a single driver module08:25
larsce.g. typically a driver has only a single entry and exit point08:25
larscbut in the entry and exit functions you typically have some foobar_register(foobar_ops); foobar_unregister(foobar_ops)08:26
larscwhere foobar_ops is a collection of function pointers08:26
whitequarklarsc: have you seen tsan?08:26
larscfrom the point on where foobar_register has been called you have to assume that those functions can be called concurrently08:26
larscwhitequark: no08:27
whitequarkit's just what you want08:27
larsca right, threadsanitizer08:27
whitequarkhmmm, could you try something like08:27
whitequarkrunning it over usermodelinux?08:27
larscI don't want to do live analysis08:28
whitequarkoh, a static analyzer08:28
whitequarkI've never heard of static data race analysis, to be honest08:28
larscI was thinking about first splitting the code into blocks of sideeffect free code, then build a graph of which block may follow after which other block. But I'm afraid there will be a state explosion08:31
whitequarkyou can probably split them into ranges or sets somehow08:32
whitequarkI'm sure there's been literature on the topic, have you looked?08:32
larscno, just had the thoughts a couple of hours ago08:33
kyakand now i'm really out08:36
larschm, what can run concurrent with what else typically only changes when you add/remove a new concurrent function to the system, or if you take/release a lock08:38
whitequarkI can't parse that sentence08:39
larscwhen you have two functions f1 and f2 and the can run concurrently that means that any instruction in f1 can be followed by any instruction in f2 and vice versa08:40
whitequarkumm, that's a very simplified view08:41
whitequarkI think you must consider a memory model08:42
whitequarklarsc: really though, you don't need to consider all instructions08:42
whitequarkyou only need to ensure that concurrent access is either atomic or protected by a lock 08:43
larscyes, thats why I said split things into blocks of side-effect freeness08:43
whitequarkno, I mean, you don't have to analyze all possible parallel paths at all08:43
whitequarkconcurrent paths, rather08:43
whitequarkyou only have to analyze a single path, because the predicate "protected by a lock" only considers a single thread08:44
whitequark("atomic" is trivial)08:44
larsctypically there is no global lock08:44
whitequarkso you will have to categorize data into two categories: 1) owned by a thread T 2) protected by lock L08:45
whitequarkthen, for category 2, you'll have to prove that no accesses outside a section protected by a lock happen. this is a relatively simple flow analysis08:45
whitequarkfor 1, it's much trickier08:45
whitequarkbut I hope that kernel has some sane standard notion of ownership08:46
whitequarkand there should never be any data that is neither owned by a specific thread nor protected by a lock08:47
whitequarkmakes sense?08:48
larscbut I think it might be more complex08:49
whitequarkI will happily discuss it; I'm fairly interested in the topic08:49
whitequarktbh I think you may be onto something; I can't recall any existing tools that work like that08:49
Action: larsc too, but I'm trying to get work done right now ;)08:50
larscWhat I meant was that there are other ways of mutal exclusion then just taking a lock08:51
larsce.g. before you register your callback ops you know that data accessed before that point can not be concurrently accessed in the callbacks08:51
whitequarkthat's ownership08:52
whitequarki.e. you can skip locking if you own the thing. but you're right in that now that becomes modal08:52
larscI think I would describe it with code paths being dead or alive09:05
larscthere are certain events that mark a code path dead or alive09:05
larsce.g. a taking a mutex makes all other codepaths that use the same mutex dead09:05
larscyou get in problems though when the calculation whether the code is dead or alive becomes turing complete09:06
whitequarkyes, that's why I suggested ownership09:06
larsce.g. if (rand() % 2) mutex_lock()09:06
whitequarkownership usually corresponds to some well-defined domain concept09:07
whitequarkwhich people won't mess with just for the sake of maintainability09:07
whitequarksay, memory allocated on stack is only owned by the caller09:08
whitequarkmemory allocated with malloc is owned by caller unless put into memory that belongs to someone els09:08
whitequarkand you rarely if at all transfer ownership entirely09:13
whitequarkperhaps only for something like buffers in a network stack09:13
larsccan you transfer ownership to None?09:17
larsce.g. every thread needs to take a lock?09:17
whitequarksure, though I would call that "Shared"09:18
whitequarkit's basically a standard poisoning scheme09:21
whitequarklarsc: frama-c.com?10:22
whitequarkI'm being told it does what you want10:22
larscI'll take a look, thanks10:38
viricmany years ago, there was a tool called 'spin' or so10:51
viricdecades, even10:52
Action: wpwrak celebrates the return of the intertubes10:52
viricit was... http://spinroot.com/spin/whatispin.html10:53
viricit's still used, it seems :)10:54
wpwrak(spin) "still used" and why not ? it's a great tool10:56
viriclast time I touched it, it was in early 0s10:59
viricand back then I thought I was using an old tool11:00
wpwrakwell, unless you design protocols for a living it's not a tool you should need every day ... ;-)11:00
viricI coulnd't find any other tool that did that, though11:00
viricopen source tool I mean11:00
wpwrakwhitequark: (etchant comparison) not terribly useful, given that they only tried two11:01
whitequarkmmm yes, it's only mildly interesting11:02
whitequarkI definitely should try FeCl3-with-a-sponge11:02
whitequarkseems to produce fascinating results. I'm not sure why *exactly* is it faster11:02
wpwrakFeCl is just a mess. have you ever tried it ? all the lovely stains ...11:03
whitequarkI totally did11:03
whitequarkhad a 1L bottle of FeCl3 and used it for ~6 months11:03
wpwrakand you still want to go back to *that* ? :)11:04
whitequarkit didn't really bother me in the ways you describe11:04
whitequarkit was somewhat slow and uneven, but some of that can be attributed to poor tradecraft back then11:05
whitequarkI don't ever want to deal with hot FeCl3 though11:05
wpwrakoh, it "works". but you need to warm it, any spills cause stains (and the messy procedure means that spills are more likely), it very quickly loses transparency, and it's a pain to get rid of the spent acid.11:06
whitequarkjust pour it down the drain11:07
wpwrakcompare to HCl+H2O2: works fine at room temperature, very low spill risk and spills are colorless (i assume - haven't actually had one i noticed yet), stays clear all the way, you just let it dry and then dispose of the salt.11:08
whitequark(transparency) is it ever transparent?11:08
wpwrakin russia, there are no fish :)11:08
whitequarkand acquiring H2O2 is still a pain...11:09
whitequarkeh. as if a whopping 10g of copper would affect *anything*11:09
wpwrakfecl ? well, sufficient to see the pcb. but when etching starts, it all gets black11:09
whitequarkand 10g of copper is how many pcbs? a hundred?11:09
wpwrakhow big are your pcb ? and what sort of copper coating do you have ? 1/2 oz, 1 oz, 2 oz ? single-or double-sided ?11:11
whitequarksay 1/2oz double-sided, 10x10cm would be most common11:11
whitequarkand I usually pour the copper in planes on the board11:12
wpwrakso let's say 70% coverage11:13
wpwrakthat should be about 1 gram of dissolved copper per board11:14
wpwrakseem that about 10 ug are enough to reach LD50 in trouts and minnows. so that gram is about 50 fish. http://www.southwestsalmon.org/wp-content/uploads/2014/01/Morris_Stratus_CuTox_RBT_FHM_LowHardnessH2O.pdf11:22
whitequarkumm, µg? not µg/L?11:23
wpwrakah, sorry, yes. tought that had used the accumulated value11:24
whitequarkyepp, µg/L. now consider in how much water exactly that 1 gram of copper is dissolved.11:24
whitequarkwhile I appreciate the sentiment and everything, the fact is, it's not going to do anything11:24
whitequarkneither will 10g neither 100g (over the course of a year or so, which seems reasonable)11:25
wpwraknice feature ;) "cp: will not overwrite just-created ... with ..."14:35
nicksydney_Is the best PCB etchant in every kitchen ? -- http://www.instructables.com/id/Is-the-best-PCB-etchant-in-every-kitchen-/?ALLSTEPS14:36
wpwrakit's not in mine - i keep the hcl outdoors :)14:36
nicksydneywpwrak: nice idea about casing http://www.instructables.com/id/ChronosMEGA-a-wrist-watch/?ALLSTEPS 14:45
nicksydneyit has got it's own design page http://www.shapeways.com/model/1809825/chronosmega-watch-case.html?modelId=1809825&materialId=8114:46
wpwrak"Atmel ATmega328P QFP processor" *groan*14:50
nicksydneywpwrak: change that to M0 smaller package and make more interesting display and call it WrakWatch :)14:52
wpwrakyou mean with a nice big wrecking ball chained to it ? :)14:53
nicksydneynot sure which ball you are referring to :)14:55
nicksydneythought of hacking something like this for my son's school bag http://www.instructables.com/id/Wearable-Message-Board/?ALLSTEPS so it scroll his name across :)14:56
wpwrakbetter make a tornado :) http://projects.qi-hardware.com/index.php/p/antorcha/source/tree/master/tornado14:58
nicksydneyuhhhh nice14:59
nicksydneywpwrak: you can make few boards and sell it on tindie ... surely people will buy it 15:00
wpwrakwish we had less of a "you should do/make/..." culture here and more "i'll do/make/..."15:02
wpwrakidea, proof of concept design, etc., all there. neatly pre-chewed for someone else to continue with. but no. guess the couch is just too comfty :)15:03
nicksydney"i'm making RA8875 board" :)15:04
nicksydneyand soon "I'm making scrollable LED for backpack" 15:05
nicksydneywow the antocha design is nice15:05
nicksydneydo you have pic of the proto for antorcha ?15:06
wpwrakliek this ? http://www.almesberger.net/misc/ant/proto2.jpg   or in use: http://www.almesberger.net/misc/ant/edd1.jpg15:10
wpwrakand this is tornado: http://downloads.qi-hardware.com/people/werner/tornado/proto1122.ogv15:11
wpwrak(just on the bench - it's a bit tricky to take pictures of it running)15:12
wpwrakwould redesign it with a kl2x now, though. free usb :)15:13
nicksydneywill be interesting if later on i try that design and put the led into pyralux material like being used in here http://www.instructables.com/id/Making-flexible-PCBs-with-a-laser-jet-printer-or-c/?ALLSTEPS15:13
nicksydneyyeah using Pyralux will be interesting 15:14
wpwrakit's aim for rigidity. mechanical stress on that thing is already through the roof, so anything that helps to keep chips from popping off the circuit is hotly welcome15:17
wpwraknice ... a CR2032 holder you can "sink" into the PCB. http://www.memoryprotectiondevices.com/datasheets/BU2032SM-JJ-MINI-GTR-datasheet.pdf15:35
Action: ysionneau just received his components from seeedstudio15:53
wpwrakjust in time for the weekend :)15:55
larsctime to plant things16:10
wpwrakhmm, seems that i may be able to shrink the kl26 from 48 to 32 pins. that would be neat :)17:25
apeleteHi larsc, are you still there ?18:27
ysionneaunice PCB making technique http://goo.gl/aNzLHt18:28
ysionneauless chemistry ;)18:28
larscapelete: yes18:49
apeleteglad to see you around :)18:51
apeletelarsc: stepping through jz4740_dma_start_transfer() with gdb (since the dma_complete callback is not being called in mmc driver)18:53
apeletethere's something I don't understand18:53
apeletelarsc: when it gets to line 338 (http://lxr.free-electrons.com/source/drivers/dma/dma-jz4740.c?v=3.12#L338) the value of src_addr is actually 56:18:56
larscdid you set fifo_addr in the config?18:57
larscthis need to point to the physical address of the mmc controlers data fifo register18:58
apeleteI set src_addr in case of DMA_DEV_TO_MEM transfer: http://git.seketeli.net/cgit/~apelete/qi-kernel.git/tree/drivers/mmc/host/jz4740_mmc.c?h=jz4740-dma#n18218:59
apeletelarsc: don't know if it is the same as fifo_addr19:00
larscor wait19:00
larscI think it is19:00
larsc56 is 0x38 which is JZ_REG_MMC_RXFIFO19:01
larscso that means host->mem_res->start must be 019:02
larscwhich is wrong19:02
larscthis line is fishy http://git.seketeli.net/cgit/~apelete/qi-kernel.git/tree/drivers/mmc/host/jz4740_mmc.c?h=jz4740-dma#n103219:03
apeleteso I have a problem at "host->mem_res = devm_ioremap_resource(&pdev->dev, res);"19:03
larschost->mem_res should = res19:03
larscthen host->base = devm_ioremap_resource(&pdev->dev, host->mem_res)19:04
larscthe compiler should have actually screamed at your for that line19:05
apeletelarsc: he didn't, kept the scream for himself :-/19:07
apeleteI'll fix the lines you're talking about and try again19:07
apeletelarsc: gdb won't let me print the content of host->mem_res in mmc_probe callback: http://paste.debian.net/98532/19:42
apeletelarsc: src_addr looks ok, but dma still fails (and dma_complete still isn't called) -> http://paste.debian.net/98533/19:42
apelete(gdb) p src_addr19:43
apelete$4 = 26857068019:43
apelete(gdb) p dst_addr19:43
apelete$5 = 1461721619:43
larscwe'll get there19:46
larscdst_addr looks a bit short19:47
larscyou don't seem to set JZ_MMC_CMDAT_DMA_EN19:49
apeletehmm, not sure what you're talking about, let me look at the code19:49
larscyou need to set the JZ_MMC_CMDAT_DMA_EN in the CMDAT register, otherwise the MMC controller will not tell the DMA controller that there is any data to transfer19:50
larscno data to transfer -> no callback19:50
apeleteokay I see, so I should set JZ_MMC_CMDAT_DMA_EN in jz4740_mmc_send_command()19:52
apeletelarsc: looks good to you http://paste.debian.net/98536/ ? (compiling)19:58
apeletelarsc: making some progress, kernel is now crashing: http://paste.debian.net/98538/20:06
larsccan you check which is the NULL pointer?20:09
apeletelarsc: how can chan->desc->vdesc be valid when chan->desc = NULL; ?20:09
larscit is not20:10
larscvdesc is desc + 20 or something20:10
larscso it will not be NULL20:10
larscbut NULL + 2020:10
larsctry to replace the else with else if (chan->desc)20:12
larscthat makes no sense20:12
larscthis is stupid:20:13
larsc                chan->desc = NULL;20:13
larsc                vchan_cookie_complete(&chan->desc->vdesc);20:13
larscshould be something like: vdesc = &chan->desc->vdesc; chan->desc = NULL; vchan_cookie_complete(vchan);20:14
apeletechan->desc = NULL; looks strange to me, but I may be mistaken here20:14
apeletelarsc: ok, looks more logical20:14
apeletelet's try that20:14
larscI think it would even be fine to just swap the two lines20:15
larscthis all happens while holding a lock, so there is no chance of a race condition20:16
larscalso be aware that you need this commit http://git.seketeli.net/cgit/~apelete/qi-kernel.git/commit/?h=jz-3.1320:21
apeletelarsc: should I still invert the two following lines after list_del(&chan->desc->vdesc.node); ?20:22
apeletelarsc: now it fails in dma_complete() callback http://paste.debian.net/98551/ :) 20:42
larscthat's your function20:43
larscjust drop the cache_inv for now20:44
apeletejust fixed a mistake where I forgot to init struct completion used by dma_complete callback21:16
apeletelarsc: more porgress, now failing with an I/O error in sd driver I guess -> http://paste.debian.net/98562/21:17
larscbut it detects the card correctly21:21
larscwhich means it is able to read data 21:21
apeleteyes, the I/O error is from:21:22
apelete./block/blk-core.c:2330:printk_ratelimited(KERN_ERR "end_request: %s error, dev %s, sector %llu\n",21:22
larsccan you check if we set -EIO in the driver somehwhere21:23
apeleteyes, in jz4740_mmc_transfer_check_state() : http://lxr.free-electrons.com/source/drivers/mmc/host/jz4740_mmc.c?v=3.12#L22021:25
larscyea, but does it actually run that code in your case?21:27
larscand then the next question is why is the error condition valid21:28
larscanyway, I'll be away for a while21:29
apeletelarsc: okay, will check if we set EIO in the mmc driver21:31
apeletethanks for helping :-)21:31
--- Sat May 10 201400:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!