| 00:04.42 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-135.ozonline.com.au) |
| 00:05.56 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-135.ozonline.com.au) |
| 00:10.12 | DocScrutinizer51 | wpwrak: if you're interested: http://mg.pov.lt/maemo-ssu-irclog/search?q=silicon http://mg.pov.lt/maemo-ssu-irclog/search?q=errat http://mg.pov.lt/maemo-irclog/search?q=errat -- and the two errata: http://cache.freescale.com/files/32bit/doc/errata/IMX50CE.pdf >>freemangordonDocScrutinizer, the errata which we are told is mutually exclusive (and its number is stated in logs on #beagle dm8tbr is talking about) is 687067<< and |
| 00:10.13 | DocScrutinizer51 | THe PRIMARY issue: http://cateee.net/lkddb/web-lkddb/ARM_ERRATA_430973.html |
| 00:12.03 | *** join/#qi-hardware freespace (foobar@stark.pictorii.com) |
| 00:14.11 | *** join/#qi-hardware DocAvalanche (~lagrange@lagrange.cloud-7.de) |
| 00:14.12 | *** join/#qi-hardware DocAvalanche (~lagrange@openmoko/engineers/joerg) |
| 00:14.58 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-157-201.netcologne.de) |
| 00:15.12 | *** join/#qi-hardware lekernel (~lekernel@g225039002.adsl.alicedsl.de) |
| 00:20.24 | DocScrutinizer51 | >>...operations may not work as intended. Instead of writing zeros to the valid bit of the BTB entry matching the MVA provided, the CP15 “Invalidate Branch Predictor by MVA” operation writes the value currently in the “Instruction L1 System Array Debug Register 0.” << nice, isn't it? |
| 00:22.01 | kristianpaul | WHAT 149 usd?? ;-) |
| 00:27.59 | kristianpaul | includes some wireless upgrade or such? ;-) |
| 00:33.49 | DocScrutinizer51 | kristianpaul: hmm? |
| 00:35.17 | kristianpaul | DocScrutinizer51: http://lists.en.qi-hardware.com/pipermail/discussion/2012-June/009693.html |
| 00:37.36 | wpwrak | that's wolfgang rewriting the book on marketing :) |
| 00:38.16 | wpwrak | it's actually a good idea. if it doesn't work, the loss is minimal. if it works, he gets the nobel price in economy |
| 00:40.40 | kristianpaul | ;-) |
| 00:46.38 | wolfspraul | what now? :-) wait have to restart my machine... |
| 00:52.46 | *** join/#qi-hardware wolfspraul (~wolfsprau@222.129.18.5) |
| 00:54.34 | wpwrak | wolfspraul: we're contemplating the metaphysical dimensions of the price increase :) |
| 00:55.01 | *** join/#qi-hardware zear (~zear@h196n1-g-kt-a31.ias.bredband.telia.com) |
| 00:55.57 | wolfspraul | increased happiness |
| 00:56.50 | wolfspraul | I am *seriously* considering to put a little multiple-choice test before the online shop, where people have to answer questions that show that they understand what they will buy with the Ben & M1 :-) |
| 00:57.06 | wolfspraul | only because it's too difficult technically (or I'm too lazy) have I not done that yet |
| 00:58.35 | wolfspraul | good morning everybody btw |
| 00:59.51 | wpwrak | if you want to add such a test, make it optional |
| 01:00.10 | wolfspraul | won't do it anyway, just a thought |
| 01:00.51 | wpwrak | a link "DO YOU HAVE ENOUGH STAMINA FOR THE MILKYMIST ? >>>" |
| 01:01.16 | wolfspraul | beautiful questions that will make people think about what they buy |
| 01:01.18 | wpwrak | naw, that's too long |
| 01:01.36 | wpwrak | "ARE YOU READY FOR THE MILKYMIST ?" |
| 01:02.07 | wpwrak | for those who have odd associations already, this should enhance the experience :) |
| 01:05.36 | wpwrak | actually ... make a youtube spot with "ARE YOU READY TO DO THE MILKYMIST ?" |
| 01:05.47 | wpwrak | then enjoy the video responses :) |
| 01:08.26 | wolfspraul | I became more interested in the innards of an fpga recently, so I am starting a little educate-myself project here https://github.com/Wolfgang-Spraul/fpgatools |
| 01:08.53 | wolfspraul | my first goal is very simple, I want to dig into the .bit bitstream and be able to read it better in text form |
| 01:09.08 | wolfspraul | let's see how that goe |
| 01:09.09 | wolfspraul | goes |
| 01:09.22 | wpwrak | "plain C, no C++" yes !! ;-) |
| 01:09.59 | wolfspraul | see. I wrote those design goals to make you happy! :-) |
| 01:10.29 | wpwrak | indeed :) |
| 01:10.31 | wolfspraul | nothing works yet though. next step: go through commands. |
| 01:10.36 | wpwrak | very good design goals |
| 01:10.43 | wpwrak | or, rather, design principles |
| 01:11.50 | DocScrutinizer51 | (OMAP silicon errata) http://mg.pov.lt/maemo-irclog/%23maemo.2012-05-21.log.html#t2012-05-21T20:19:58 is where a lengthy but comprehensive discussion starts between freemangordon, me (docscrutinizer), and a few words from javispedro. If you bother to read it, just ignore estel_ posts as they are distracting, to use an euphemism |
| 01:17.30 | DocScrutinizer51 | it goes for almost 2 hours, and I think it sums up the basic issues of the whole topic |
| 01:18.17 | wpwrak | phew. maybe for the next time when i;ll have to wait at security in an US airport :) |
| 01:18.42 | wpwrak | i'm sure all involved are grown up enough to not make fools of themselves on linux-arm ;-) |
| 01:29.05 | wolfspraul | wpwrak: btw, I have to say I love the effect of -Wall during development |
| 01:29.19 | wolfspraul | I didn't use it before, so I was in the typical struggle circle |
| 01:29.32 | wolfspraul | write thousands of lines, then a heroic battle with warnings later |
| 01:29.57 | wolfspraul | often fought with mass casts or simply turning warnings off :-) |
| 01:30.24 | wolfspraul | but if it's on when first writing something, it's a breeze to fix right at the spot |
| 01:39.51 | kristianpaul | uses pendantic as well |
| 01:42.17 | DocScrutinizer51 | even uses lint at work |
| 01:42.52 | DocScrutinizer51 | mandatory procedure according to company policy |
| 01:43.52 | DocScrutinizer51 | plus recently another tool called coverity or similar, I haven't had a look into that one yet |
| 01:44.21 | DocScrutinizer51 | seems lint and coverity are complementary |
| 01:47.31 | wpwrak | for me, -Wall -Wextra -Wshadow -Wmissing-prototypes -Wmissing-declarations |
| 01:47.44 | wpwrak | and then valgrind :) |
| 01:47.51 | DocScrutinizer51 | ooh sure |
| 01:48.47 | wpwrak | -Wshadow can be a tad annoying but catches rather nasty bugs |
| 01:49.35 | wpwrak | e.g., int foo; ... void bar(int fo) { do_something(foo); } |
| 01:50.29 | wpwrak | or int items; void bar(int item) { do_something(item); do_something_else(items); } |
| 01:51.02 | wpwrak | in the 2nd case, you won't get a warning about the unused "item" argument. this sort of name error happens quite easily when you're a bit tired or distracted |
| 01:52.12 | *** join/#qi-hardware wej (~j@95.211.10.3) |
| 01:52.36 | DocScrutinizer51 | still, if you're facing code as fsckdup as http://lxr.free-electrons.com/source/net/caif/caif_socket.c#L377 ff... :-S |
| 01:53.34 | wpwrak | this code wants a function for the "skb == NULL" case :) |
| 01:54.04 | DocScrutinizer51 | this code wants a refactoring done by a devel with a brain |
| 01:54.43 | DocScrutinizer51 | anyway >> * Copied from unix_stream_recvmsg, but removed credit checks,<< |
| 01:54.53 | wpwrak | yeah, preferably one without previous experience with the italian kitchen :) |
| 01:54.58 | DocScrutinizer51 | makes me think it' |
| 01:55.25 | DocScrutinizer51 | s not been my colleagues that thought it's a nice idea to test compiler optimization |
| 01:56.10 | DocScrutinizer51 | look at all the useless unconditional assignments to err |
| 01:57.26 | wpwrak | they're a common pattern in the linux kernel. nothing wrong there. |
| 01:58.05 | wpwrak | the only issue is see is that the jumps are quite complicated |
| 01:58.12 | DocScrutinizer51 | if (err = sock_error(sk) ) goto unlock; if (sk->sk_shutdown & RCV_SHUTDOWN) { err = -ECONNRESET; goto unlock;}; |
| 02:00.05 | DocScrutinizer51 | the first if() maybe style question, the second if case mere common sense |
| 02:00.56 | DocScrutinizer51 | you don't pull out assignemnts out of the if branch for no good reason - even when compiler usually will optimize it |
| 02:02.41 | DocScrutinizer51 | try to trace such code in Lauterbach and get a severe headache, as compiler was feeling nausea and decided to completely rewrite your code |
| 02:03.08 | wpwrak | your first if will get you a warning |
| 02:03.19 | DocScrutinizer51 | quite possibly |
| 02:03.29 | wpwrak | and you can safely leave that sort of low-level optimization to the compiler |
| 02:03.38 | DocScrutinizer51 | nonsense |
| 02:03.56 | DocScrutinizer51 | (unless you talk about first if() ) |
| 02:04.00 | wpwrak | focus on code clarity, not what was hard for compilers 30 years ago ;-) |
| 02:04.23 | DocScrutinizer51 | my major consern was exactly about code clarity |
| 02:04.57 | wpwrak | well, since it seems to be from linux, why not clean it up and send a patch ? |
| 02:05.06 | DocScrutinizer51 | pulling out the err= -ECONNRESET from the if branch is all anti-code-clarity |
| 02:06.31 | DocScrutinizer51 | ROTFL @ http://lxr.free-electrons.com/source/net/caif/caif_socket.c#L415 |
| 02:06.43 | DocScrutinizer51 | there (s)he did it right |
| 02:08.35 | DocScrutinizer51 | while a do { } while() spanning over ~80 lines is a nogo in itself |
| 02:10.43 | DocScrutinizer51 | actually one style rule at work is: functions mustn't span more than a screenfull of lines |
| 02:11.51 | wpwrak | keeping functions short is a good concept |
| 02:12.35 | DocScrutinizer51 | indeed |
| 02:13.36 | DocScrutinizer51 | and instead of if (sk->sk_state == CAIF_CONNECTING) you can use if (CAIF_CONNECTING == sk->sk_state) |
| 02:14.35 | DocScrutinizer51 | as if (CAIF_CONNECTING = sk->sk_state) for sure gives a warning/error |
| 02:14.56 | wpwrak | both yield a diagnostic |
| 02:15.14 | DocScrutinizer51 | both? |
| 02:15.21 | wpwrak | try it :) |
| 02:15.27 | DocScrutinizer51 | ??? |
| 02:15.40 | wpwrak | gcc complains if you if (var = value) ... |
| 02:15.46 | DocScrutinizer51 | sure |
| 02:16.16 | DocScrutinizer51 | but if probably goes mad when you if (const = var) |
| 02:16.53 | DocScrutinizer51 | and for your case the warning will depend on -Wxxx |
| 02:17.38 | wpwrak | *shrug* don't f* around without protection :) |
| 02:17.56 | DocScrutinizer51 | hm? |
| 02:18.29 | wpwrak | you'll have that warning enabled unless you're very careless already |
| 02:19.25 | wpwrak | (i.e., -Wall enables it) |
| 02:19.53 | DocScrutinizer51 | but yeah, you also tried to teach me not to use parantheses in complex conditions, as you claimed that's what operators precedence is for. Company policy is we *shall* use them |
| 02:20.04 | wpwrak | and you want to keep it on. else, you'll still trip over a typo in if (var1 == var2) |
| 02:20.34 | wpwrak | you can solve that by firing all the pascal programmers ;-) |
| 02:21.11 | DocScrutinizer51 | lol |
| 02:21.14 | wpwrak | and maybe print a few copies of the C operator precedence table. it's very well thought out and, believe it or not, the compiler knows it too ;-) |
| 02:22.50 | wpwrak | i think i ran into some crappy "C" compiler for CP/M once that did have some precedence bugs. but that was a pretty long time ago |
| 02:23.11 | DocScrutinizer51 | well, that guy solved it his way: http://lxr.free-electrons.com/source/net/caif/caif_socket.c#L398 +5 |
| 02:23.36 | DocScrutinizer51 | ;-P |
| 02:23.55 | wpwrak | well, not the worst way to deal with it |
| 02:24.19 | DocScrutinizer51 | you must be kidding |
| 02:25.07 | wpwrak | once you get past being proud of yourself because you managed to write a 500 character expression that actually seems to work, the inner drive for writing complicated if statement drops dramatically |
| 02:25.20 | DocScrutinizer51 | the whole friggin code in that do loop cries out loud for a case switch |
| 02:26.52 | wpwrak | hmm, let's call the language with a case statement that can handle that "J" ;-) |
| 02:27.29 | DocScrutinizer51 | hmm, maybe not |
| 02:28.14 | DocScrutinizer51 | nah, call it shell script |
| 02:28.31 | DocScrutinizer51 | or maybe qbasic |
| 02:28.45 | DocScrutinizer51 | but honestly I don't suggest to do THAT |
| 02:29.08 | DocScrutinizer51 | I didn't realize the error checks were all from different sources |
| 02:33.22 | wpwrak | that code has to do some quite tricky stuff. also note that errors only yield an error code if no data has been moved yet |
| 02:37.40 | DocScrutinizer51 | sure |
| 02:39.46 | DocScrutinizer51 | (<wpwrak> this code wants a function for the "skb == NULL" case) isn't that simple to do either, regarding all the explicit and implicit (break, continue) gotos |
| 02:41.11 | wpwrak | yes, i know :) |
| 02:41.35 | wpwrak | but if you spend a few hours on it, maybe you find a nice simplification :) |
| 02:41.56 | DocScrutinizer51 | the whole function caif_stream_recvmsg() already qualifies for a bad example of spaghetti code |
| 03:14.34 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 03:31.10 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-135.ozonline.com.au) |
| 03:47.41 | *** join/#qi-hardware sucotronic (~felix@141.Red-80-35-38.staticIP.rima-tde.net) |
| 03:59.50 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 04:09.25 | *** join/#qi-hardware Ayla (~paul@183.45.123.78.rev.sfr.net) |
| 04:26.30 | *** join/#qi-hardware rejon (~rejon@221.221.174.82) |
| 04:26.35 | *** join/#qi-hardware rejon_ (~rejon@221.221.174.82) |
| 05:14.08 | qi-bot | [commit] Werner Almesberger: b2/boom.c (main): run queries also if no variables are set (master) http://qi-hw.com/p/eda-tools/e919b16 |
| 05:14.09 | qi-bot | [commit] Werner Almesberger: b2/subst.c (dump_chunks): closing } was missing when dumping variable expansion (master) http://qi-hw.com/p/eda-tools/cae92bb |
| 05:14.10 | qi-bot | [commit] Werner Almesberger: b2/: move implicit initialization of FN, F1, ... to explicit function subex_init (master) http://qi-hw.com/p/eda-tools/c6e3944 |
| 05:14.11 | qi-bot | [commit] Werner Almesberger: b2/: resolve FN in subst_init and don't consider an FN match evidence of existance (master) http://qi-hw.com/p/eda-tools/c2414a5 |
| 05:14.14 | qi-bot | [commit] Werner Almesberger: b2/: disallow assigning to FN (master) http://qi-hw.com/p/eda-tools/b35b6e2 |
| 05:14.15 | qi-bot | [commit] Werner Almesberger: b2/test/: add first set of substitution tests (master) http://qi-hw.com/p/eda-tools/fb7b246 |
| 06:13.44 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 06:21.08 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 06:28.03 | *** join/#qi-hardware valhalla (~valhalla@81-174-23-137.dynamic.ngi.it) |
| 06:50.36 | *** join/#qi-hardware phirsch_ (~phirsch@xdsl-89-0-76-167.netcologne.de) |
| 07:14.49 | valhalla | in the italian increasing the nanonote price looks like a suicidal move (but then it wasn't a big market anyway, and without an EU shop it was probably going do get smaller anyway) |
| 07:15.53 | *** join/#qi-hardware kristoffer (~kristoffe@c-34dae555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 08:00.51 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 08:21.31 | *** join/#qi-hardware lekernel (~lekernel@g225039146.adsl.alicedsl.de) |
| 09:46.02 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 10:00.55 | lekernel | wolfspraul: (fpgatools) the tool you want to write exists already, it's called xdl. it's proprietary ofc. |
| 10:01.44 | lekernel | also see https://github.com/sbourdeauducq/s6bitstream |
| 10:03.55 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 10:11.07 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 10:42.47 | qi-bot | [commit] Paul Cercueil: MMC: JZ4740: Remove duplicated code. (jz-3.4) http://qi-hw.com/p/qi-kernel/92ca0b9 |
| 10:46.12 | Ayla | larsc: hi, could you review that patch? http://pastebin.com/EALuMB0r |
| 10:47.20 | Ayla | larsc: I'd like to know if that code was missing on purpose (so that I'm not adding a bug instead of removing one) |
| 10:50.56 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 10:52.34 | larsc | Ayla: looks good |
| 10:52.53 | Ayla | ok, thank you |
| 11:05.23 | qi-bot | [commit] Paul Cercueil: MMC: JZ4740: Fix handling of read errors. (jz-3.4) http://qi-hw.com/p/qi-kernel/c36b5d5 |
| 11:27.44 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 11:31.14 | *** join/#qi-hardware Ayla (~paul@183.45.123.78.rev.sfr.net) |
| 12:04.47 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 12:55.03 | Ayla | mth, larsc: I found something interesting about the MMC bug |
| 12:56.53 | Ayla | mth, larsc: http://pastebin.com/yPrJqRKk <= this patch should not change the behaviour of the driver, do you agree? |
| 13:06.28 | larsc | why not? |
| 13:07.52 | Ayla | because JZ_MMC_IRQ_RXFIFO_RD_REQ should already be inside irq_reg |
| 13:08.30 | larsc | but you mask out all other irqs |
| 13:10.12 | Ayla | no, inside jz4740_mmc_set_irq_enabled the value is OR'd inside host->irq_mask |
| 13:10.21 | Ayla | and host->irq_mask is written to the register |
| 13:10.34 | Ayla | so the other IRQs are not modified |
| 13:11.28 | larsc | yea, but for example JZ_MMC_IRQ_RXFIFO_WR_REQ is never disabled with your patch |
| 13:13.12 | Ayla | of course it is disabled with the patch |
| 13:13.34 | Ayla | oh |
| 13:13.47 | Ayla | you mean JZ_MMC_IRQ_TXFIFO_WR_REQ (the write one?) |
| 13:13.56 | larsc | uhm, yes |
| 13:14.35 | larsc | if we hit a timeout when polling for the irq it is enabled |
| 13:14.50 | larsc | and disabled again after the interrupt |
| 13:14.57 | Ayla | yes, but it has to be cleared before starting the interrupt thread |
| 13:15.03 | Ayla | and it's not |
| 13:16.25 | larsc | doesn't jz4740_mmc_set_irq_enabled(host, irq_reg, false); disable it? |
| 13:16.32 | larsc | if irq_reg = JZ_MMC_IRQ_TXFIFO_WR_REQ |
| 13:17.04 | Ayla | yes |
| 13:18.34 | larsc | which means if you and irq_reg with the rxfifo irq you won't disable it anymore |
| 13:20.18 | Ayla | why not? |
| 13:20.29 | Ayla | ah crap |
| 13:20.30 | Ayla | x_x |
| 13:20.36 | Ayla | n00b error |
| 13:22.10 | Ayla | larsc: however, the jz_mmc_irq writes the JZ_REG_MMC_IREG twice |
| 13:22.26 | Ayla | the second one obviously overriding the first |
| 13:23.48 | larsc | IREG is write-one-to-clear |
| 13:24.23 | Ayla | yes |
| 13:24.24 | larsc | writing a '1' to a bit will clear that bit, writing a '0' will leave it unchanged |
| 13:25.12 | Ayla | meh, the docs are on my other PC :s |
| 13:26.15 | Ayla | larsc: but perhaps the two writes occur too rapidly for the hardware? :) |
| 13:26.57 | Ayla | well I believe writing a '1' two times has no effect anyway |
| 13:28.31 | larsc | you can change the code to have only one write to IREG |
| 13:31.34 | Ayla | but why did it need two writes to IREG at the first place? |
| 13:34.58 | larsc | you don't need them, but it was more convenient that way, that chance that both writes will be exectured in the same irq handler run is pretty low anyway |
| 13:35.44 | Ayla | why wouldn't they be executed in the same IRQ handler? ... |
| 13:35.50 | Ayla | they are in the same function |
| 13:36.40 | larsc | because both writes are conditional |
| 13:39.45 | Ayla | why do you read the IREG register btw? Does it contain something useful? |
| 13:40.01 | Ayla | IIRC the interrupt status is located inside another register |
| 13:40.08 | Ayla | (I really need the doc ...) |
| 13:44.09 | larsc | The MSC_IREG register shows the currently requested interrupt. The FIFO request interrupts, |
| 13:44.12 | larsc | TXFIFO_WR_REQ, and RXFIFO_RD_REQ are masked off with the DMA_EN bit in the MSC_CMDAT |
| 13:44.15 | larsc | register. The software is responsible for monitoring these bit in program I/O mode. |
| 13:52.48 | Ayla | ok, I think I start to understand the code |
| 13:53.02 | Ayla | the first write to IREG is there to acknowledge unwanted interrupts |
| 13:53.24 | larsc | yes |
| 13:57.51 | lekernel | wpwrak: I already etched some PCBs with HCl + peroxide (and 30%, not 3%). I'm still alive :) though that thing definitely releases chlorine gas you don't want to breathe. |
| 13:58.04 | *** mode/#qi-hardware [+o DocScrutinizer51] by ChanServ |
| 13:58.14 | *** mode/#qi-hardware [+C] by DocScrutinizer51 |
| 13:58.22 | *** mode/#qi-hardware [-o DocScrutinizer51] by ChanServ |
| 13:59.12 | DocScrutinizer51 | lekernel: real fun starts when you mix some acetone (or other solvent) into this etching liquid |
| 14:01.27 | lekernel | but I wouldn't call chlorine "very poisonous". think of stuff like dimethylmercury, arsine, germane, etc... |
| 14:04.06 | DocScrutinizer51 | well, it's been called greencross in WW-II iirc |
| 14:04.07 | wpwrak | chlorine usually doesn't kill you on the spot, but it can cause lasting damage |
| 14:04.18 | Ayla | larsc: the IREG is written inside the worker thread |
| 14:04.25 | DocScrutinizer51 | very nasty lasting damage |
| 14:04.29 | Ayla | which does not execute in an interrupt context |
| 14:04.36 | DocScrutinizer51 | got it's own name in medicine |
| 14:05.35 | Ayla | larsc: what's the behaviour of writing that bit when the interrupt has yet to appear? |
| 14:05.35 | DocScrutinizer51 | chlorine acne |
| 14:05.44 | wpwrak | and HCl+30% peroxide (without diluting it) is way too fast to get useful results. sure, the etching takes only seconds, but it will be very uneven |
| 14:06.08 | lekernel | chlorine was only used for a short while, before they found more toxic stuff |
| 14:06.08 | DocScrutinizer51 | undercuts getting a severe problem |
| 14:07.05 | wpwrak | lekernel: a knife will kill you just as dead as a musket or a modern armor-piercing projectile ;-) |
| 14:07.10 | lekernel | chloracne is actually not caused by chlorine, but organic compounds |
| 14:07.46 | lekernel | some containing chlorine atoms in the molecule (thus the name) |
| 14:07.54 | lekernel | but Cl2 doesn't cause chloracne |
| 14:08.03 | DocScrutinizer51 | hmmm |
| 14:08.15 | DocScrutinizer51 | I'd not bet on that |
| 14:08.17 | larsc | Ayla: nothing should happen |
| 14:08.30 | lekernel | only lung damage |
| 14:09.01 | wpwrak | given an ideal diode of size zero, ... |
| 14:09.08 | DocScrutinizer51 | how's that damage working, chemically? |
| 14:09.21 | wpwrak | who needs lungs anyway ;-) |
| 14:09.34 | lekernel | I can imagine there are many reactions. chlorine is a very reactive compound. |
| 14:09.50 | lekernel | eats through most materials |
| 14:10.06 | DocScrutinizer51 | so what's the result of Cl2 reacting with the organic material in your lungs? |
| 14:10.15 | lekernel | lung goo |
| 14:10.32 | wpwrak | the problem isn't the original "pure" gas you inhale. it's the blood you spit later :) |
| 14:10.39 | DocScrutinizer51 | and chloro-organnic compounds, no? |
| 14:10.55 | lekernel | no, I think that's a different toxicity |
| 14:12.00 | lekernel | try putting some piece of meat in a bottle of chlorine for a while :) |
| 14:12.03 | larsc | wpwrak: ah, thats overrated, i've been spitting blood for the last 4 days and i'm still alive ;) |
| 14:12.09 | DocScrutinizer51 | I seem to recall a teacher who poisoned half the class of pupils with chlor gas, and most of them got chlor acne |
| 14:12.29 | wpwrak | larsc: been in a bar fight again ? :) |
| 14:12.30 | DocScrutinizer51 | but I might be wrong, as that's been a news of 30 years ago |
| 14:13.42 | wpwrak | was that in chemistry or history ? |
| 14:14.01 | larsc | wpwrak: I at least look like as if I had been. Had my wisdomtooth removed... |
| 14:14.05 | DocScrutinizer51 | in newspaper? |
| 14:14.14 | DocScrutinizer51 | aaah, in chemistry |
| 14:14.49 | wpwrak | larsc: ah, dental bliss. always the most exquisite of pains. |
| 14:15.09 | Ayla | larsc: after a data transfer, the DATA_TRAN_DONE bit is set on the IREG, which is correct, but the doc states that the "stop" command should be sent first |
| 14:15.22 | Ayla | larsc: and the code first writes the IREG then sends the "stop" command |
| 14:17.46 | larsc | Ayla: might be an issue, but i doubt it |
| 14:18.56 | Ayla | if it was not, it wouldn't be written on the doc to do so, no? :) |
| 14:21.05 | whitequark | oh, Cl2 in lungs is easy: Cl2 + H2O = HCl + HOCl |
| 14:21.24 | whitequark | it's like drowning in acid |
| 14:21.33 | larsc | Ayla: which page? |
| 14:22.55 | Ayla | page 477 |
| 14:25.31 | larsc | which file? |
| 14:25.41 | Ayla | jz4740_pm.pdf |
| 14:26.10 | lekernel | whitequark: hmm, Cl2 doesn't do that with water on itself |
| 14:26.16 | lekernel | by itself |
| 14:27.39 | lekernel | it needs some catalyst or energy source... sunlight works for that (that's why you can remove the chlorine taste of tap water by putting it under daylight for a while... acid has a less potent taste) |
| 14:27.44 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 14:30.14 | whitequark | lekernel: maybe one of 1000s of biological compounds in lungs acts as a catalyst? |
| 14:30.50 | whitequark | well anyway, I'm pretty sure that Cl2 would attack them on itself, too |
| 14:31.22 | whitequark | but from my chemistry class I recall that chlorine danger is from its dissolution in water |
| 14:32.06 | lekernel | sure, if it stays in the air, it won't attack your body which is made mostly of water... unfortunately, chlorine is also very soluble in water |
| 14:32.29 | whitequark | ah, so you mean that Cl2 can dissolve in water just as any other gas would |
| 14:32.42 | lekernel | it's _particularly_ soluble in water |
| 14:32.42 | whitequark | yeah, that's plausible |
| 14:32.58 | whitequark | interesting |
| 14:33.00 | lekernel | iirc you can dissolve dozens of liters of Cl2 in a liter of water |
| 14:33.20 | lekernel | at room temperature and atmospheric pressure |
| 14:33.31 | whitequark | http://en.wikipedia.org/wiki/Chlorine#Characteristics |
| 14:33.34 | whitequark | Hydrolysis |
| 14:33.47 | Ayla | larsc: that's not a big problem, that interrupt is never un-masked |
| 14:33.49 | whitequark | and let me find the ratio of that reaction |
| 14:34.24 | lekernel | hm, no, that's only 1 liter. still a lot. |
| 14:37.06 | whitequark | lekernel: https://aquaox.wordpress.com/2010/01/27/chlorine-efficacy/ |
| 14:37.24 | whitequark | looks like unless you have a real lot of chlorine in water, it's mostly hydrolysed |
| 14:37.29 | whitequark | (which is somewhat expected) |
| 14:39.45 | lekernel | depends on pH http://aquaox.files.wordpress.com/2010/01/r_wqb_chlorine_graph.gif |
| 14:40.27 | whitequark | yeah, that's why I said "a lot" |
| 14:40.41 | whitequark | generally, pH of lungs is near to neutral |
| 14:40.58 | lekernel | and... chlorine hydrolysis itself changes the pH, as it generates H+ |
| 14:41.05 | whitequark | exactly |
| 14:41.18 | whitequark | so that'll come to an equilibrium somewhere on the left side |
| 14:42.15 | wpwrak | conclusion: if you smell chlorine, try to inhale as much of it as possible, to avoid lung damage |
| 14:42.31 | whitequark | besides which, as the lungs are damaged by low pH, the more chlorine you have (an thus more elemental chlorine), the more pH-generated damage you'll have too |
| 14:42.41 | wpwrak | i think there may be an opening in the argentina ministry for public health. they need people who think like that ;-) |
| 14:43.04 | whitequark | wpwrak: you seem to be proud of your government :) |
| 14:43.52 | wpwrak | whitequark: oh yes, everybody here is proud of it. there were protest marches against it thursday and friday, with more predicted for next week |
| 14:44.54 | whitequark | huh. and here, the "occupy" movement has finally came from the overseas |
| 14:44.56 | wpwrak | whitequark: it's all those ungrateful people who don't understand that you don't need a stable currency, an economy, let alone a halfway credible juridical system |
| 14:47.25 | wpwrak | vive la revolucion mondial ! :) |
| 14:47.34 | wpwrak | s/al/ale |
| 14:47.36 | qi-bot | wpwrak meant: "vive la revolucion mondiale ! :)" |
| 14:48.16 | Ayla | révolution* |
| 14:48.26 | lekernel | wpwrak: heard of the Shadoks? :) |
| 14:48.26 | wpwrak | no accents here :) |
| 14:48.55 | wpwrak | not yet |
| 14:49.19 | lekernel | "When one tries continuously, one ends up succeeding. Thus, the more one fails, the greater the chance that it will work." etc. :) |
| 14:49.32 | Ayla | wpwrak: I thought that was french :) |
| 14:50.05 | wpwrak | i'm just reading wikipedia ... interesting. that's pretty much exactly how our government chooses to do things |
| 14:58.04 | wpwrak | what caused the latest protests was a rather baffling marie antoinette moment: the government has been trying for a while to get hold of every dollar they can reach. so they decreed import bans, currency exchange restrictions, recently something that looks like travel restrictions, and so on |
| 14:59.21 | wpwrak | they also lectured the people that it was morally wrong to "bet on dollars" when the national currency is the peso. (which devalues at about 25% per year, making it ideal for long-term savings.) |
| 15:00.40 | wpwrak | they also told people that it was risky for them to save in dollars, and so on. for months. then, wednesday, the newspapers published in what currencies the various ministers keep their savings, fresh from the latest tax declarations. |
| 15:01.03 | larsc | hehe |
| 15:01.57 | larsc | wpwrak: what's the interest for loans? |
| 15:01.59 | wpwrak | lo and behold, all that had declared more than pocket money had substantial savings in dollars. (one minister, i think of economy, declared to be destitute - zero cash or bank accounts) |
| 15:02.18 | wpwrak | wait, it gets better |
| 15:04.50 | wpwrak | then, on thursday morning, head of the senate anibal fernandez, who has been the government's spokesperson for all that sort of nonsense advice, admonitions, and insults against the "evil rich", was questioned by journalists why he had all those dollars when he himself had kept on saying all the time it was morally wrong and a bad idea. |
| 15:05.36 | qi-bot | The build has FAILED: http://fidelio.qi-hardware.com/~xiangfu/building/Nanonote/Ben/openwrt-xburst.full_system-20120602-1340 |
| 15:05.51 | wpwrak | his response, for once, was perfectly honest and didn't lack clarity: he said that was none of their business, he got his dollars as it was convenient, there was nothing wrong with that, and he's free to do as he pleases. |
| 15:06.13 | wpwrak | that night, people were in the streets, voicing their disagreement |
| 15:06.45 | Ayla | you're on Buenos Aires? |
| 15:07.41 | *** join/#qi-hardware compcube (~compcube@c-68-43-48-46.hsd1.mi.comcast.net) |
| 15:07.41 | *** join/#qi-hardware compcube (~compcube@pdpc/supporter/student/compcube) |
| 15:08.18 | wpwrak | maybe i should clarify exchange restrictions: to buy dollars in argentina, since a few months, you first have to get the purchase greenlighted by the tax authority. then they set a maximum amount, based on your declared income. surprisingly often, this amount turned out to be zero, even for people who earned quite well and who obediently declared their income. |
| 15:09.42 | wpwrak | a few weeks ago, they tightened the restrictions. now the result is always zero for a whole class of taxpayers. (all that are in a simplified tax regime for lower incomes) and even more often for the rest as well. one retiree tried to buy ten dollars and was refused. |
| 15:09.56 | wpwrak | Ayla: yup |
| 15:11.31 | wpwrak | a consequence of the restriction on dollar purchases was that the black market dollar took off like a rocket. it's usually around 10% above the official dollar. now it's about 30% higher. |
| 15:12.57 | wpwrak | of course, the government then started a witch hunt on exchange offices and all that. and they have dogs sniffing for money at border crossings. (many people take their pesos to neighbouring countries to exchange them there to dollars) |
| 15:15.25 | wpwrak | and after months of all that sort of chicanery, that government spokesman simply brushes it all away, telling people HE is free to do what he wants to do (but of course, the plebs isn't) |
| 15:16.29 | *** join/#qi-hardware kuribas (~user@94-227-36-245.access.telenet.be) |
| 15:16.55 | wpwrak | to compound this, the vice president is involved in a corruption scandal. of course, he denies everything, even knowing all the other folks involved. despite all sorts of evidence popping up, including one of those folks he claims to never even have seen living in an apartment he owns. |
| 15:18.16 | wpwrak | when it got too annoying, the government set out to solve the problem for good and they removed the state attorney, the judge, and the attorney general. |
| 15:19.31 | wpwrak | to add insult to injury, the guy they want to install as new attorney general, besides being a good friend of that ruling group, has a CV littered with false claims |
| 15:20.43 | Ayla | :) |
| 15:20.44 | wpwrak | tuesday, he'll have an interview by the senate, which will then decide whether they'll accept him or not. this will be rather interesting. |
| 15:22.27 | Ayla | larsc: I have some comments about the jz4740_mmc_read_data |
| 15:24.28 | Ayla | what's the "i" variable refering to exactly? |
| 15:24.49 | Ayla | it gets the value "miter->length" but doesn't seem to be used as such |
| 15:25.25 | wpwrak | larsc: loans ... with a credit card, nominal 41% p.a., effective 50%, total cost of financing (with fees and such) 63% |
| 15:25.44 | Ayla | larsc: forget about it :) |
| 15:25.54 | larsc | Ayla: i is the number of .... ok |
| 15:26.37 | wpwrak | non-card loans are also in the 40-70% segment |
| 15:26.56 | larsc | if a read operation takes to long to complete jz4740_mmc_read_data will stop reading/writing and when the next interrupt occurs it will be called again |
| 15:27.58 | Ayla | yes I got that, |
| 15:28.05 | Ayla | but how will it resume exactly? |
| 15:28.38 | larsc | it will be called in the irq worker thread |
| 15:28.46 | Ayla | I mean, if i != 0, and the second mmc_poll_irq() times out, some bytes are lost |
| 15:30.03 | larsc | sg_miter_next will continue where sg_miter_stop has been called |
| 15:30.16 | larsc | see the the poll_timeout label |
| 15:30.29 | larsc | miter->consumed is updated |
| 15:30.35 | Ayla | what about the while(j) loop then? |
| 15:30.55 | wpwrak | (that's for loans in pesos) |
| 15:30.59 | Ayla | it checks 32 times for the IRQ flag, what if it times out at the 31st time? |
| 15:31.17 | Ayla | the content of "buf" will be lost, because the miter variable is not updated |
| 15:32.15 | Ayla | and you can't read those bits again, because of the FIFO |
| 15:33.49 | larsc | why is it not updated? |
| 15:35.29 | Ayla | I don't know |
| 15:35.33 | Ayla | it should be, |
| 15:35.39 | Ayla | but it is not: http://pastebin.com/6br7bGTr |
| 15:36.36 | larsc | hm? if there is an timeout it will jump to poll_timeout, which will update it |
| 15:37.35 | Ayla | which does not know how many bytes you actually read |
| 15:39.03 | larsc | why not? |
| 15:39.23 | Ayla | how could it? |
| 15:40.02 | larsc | we increase the address of buf whenever we read data |
| 15:41.19 | Ayla | ok. I give up. |
| 15:45.21 | Ayla | larsc: the IRQ will be un-masked before the jump to poll_timeout, there might be a race there |
| 15:46.17 | Ayla | now I'm seriously out of ideas |
| 15:47.32 | larsc | the thread won't be restarted, before the previous run has finished |
| 15:47.53 | Ayla | ok |
| 15:48.45 | larsc | one thing you can try though is to call request_threaded_irq with IRQF_ONESHOT |
| 15:48.55 | larsc | because there might be a race afterall |
| 15:51.58 | larsc | yes, the thread won't be restarted if it is currently running |
| 15:52.52 | larsc | you could test whether this ever happens by modifing kernel/irq/handle.c and insert a printk in line 68 |
| 15:54.19 | larsc | ayla, you said the problem was only occuring when you reclocked the cpu freq? |
| 15:54.44 | Ayla | no, it's unrelated to the CPU clock |
| 15:54.53 | larsc | ok |
| 15:54.56 | Ayla | but it happens more often at a high clock |
| 15:55.10 | larsc | makes sense |
| 15:55.31 | larsc | because it polls faster |
| 15:55.56 | larsc | the timeout in jz4740_mmc_poll_irq shouldn't count the number of polls, but rather uses jiffies |
| 15:56.15 | larsc | to make it immune to frequency changes |
| 15:57.31 | Ayla | it's not a problem if it polls faster |
| 15:57.58 | Ayla | I mean it's not related to the current problem |
| 15:59.19 | larsc | why? |
| 15:59.57 | Ayla | the bug I'm trying to fix occurs when there is a timeout, having the kernel poll faster just trigger more timeouts |
| 16:00.06 | larsc | yes |
| 16:00.26 | Ayla | on both cases the bug is there, that's what I mean |
| 16:00.46 | larsc | it's that it polls faster is another issue |
| 16:00.59 | larsc | /it's// |
| 16:01.10 | Ayla | yes |
| 16:01.50 | larsc | the fix should be IRQF_ONESHOT, this will ensure that the primary handler won't be called as long as the threaded handler is running |
| 16:02.12 | Ayla | heh, you really think it's that simple? ;) |
| 16:02.23 | Ayla | IRQF_ONESHOT fixes nothing |
| 16:02.52 | larsc | did you try the printk? |
| 16:03.41 | Ayla | I did, but I'm having a hard time seeing this, as when the bug appears the kernel crashes and my dingoo reboots |
| 16:04.02 | larsc | hm |
| 16:06.31 | Ayla | note that if I un-plug the SD, the watchdog kicker in user-space will still work, and the device won't power off |
| 16:07.04 | larsc | so it is a crash in kernel space? |
| 16:07.15 | Ayla | yes, and I think that's what mth said too |
| 16:07.23 | larsc | hm |
| 16:07.32 | larsc | and you have no backtrace? |
| 16:07.38 | Ayla | IIRC he said that the execution was stuck in the jz_mmc_irq handler |
| 16:07.56 | Ayla | which was re-starting as soon as it exits |
| 16:07.59 | larsc | hm |
| 16:08.39 | Ayla | which sounds like a non-masked and non-cleared interrupt |
| 16:08.46 | larsc | do you have a serial? |
| 16:09.00 | Ayla | I do |
| 16:09.20 | larsc | can you try to printk the non expected interrupts? |
| 16:10.28 | Ayla | I need mth's code that forces timeouts, I downloaded it some days ago but now I'm on my netbook ... |
| 16:10.52 | Ayla | do you have it on your log perhaps? He wrote the link in #dingoonity |
| 16:11.46 | Ayla | if I don't use that patch, the bug never appears, because the serial line introduces enough delay |
| 16:11.55 | larsc | it's not in the log anymore |
| 16:23.48 | Ayla | correction: it does enter the worker thread |
| 16:29.08 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host171-91-dynamic.54-79-r.retail.telecomitalia.it) |
| 16:29.38 | *** join/#qi-hardware B_Lizzard (~havoc@athedsl-430890.home.otenet.gr) |
| 16:32.42 | qi-bot | [commit] Werner Almesberger: b2/subst.c (prepare_re): recognize % in union pattern (master) http://qi-hw.com/p/eda-tools/e93ff0e |
| 16:32.43 | qi-bot | [commit] Werner Almesberger: b2/: introduce unit pattern (##), for dimensionless values (master) http://qi-hw.com/p/eda-tools/cc895fe |
| 16:32.44 | qi-bot | [commit] Werner Almesberger: b2/test/: more substitution tests (master) http://qi-hw.com/p/eda-tools/12b21f0 |
| 16:32.46 | qi-bot | [commit] Werner Almesberger: b2/: add regular expression conversion debugging (option -R) (master) http://qi-hw.com/p/eda-tools/da1010f |
| 16:32.48 | qi-bot | [commit] Werner Almesberger: b2/test/Common: also provide empty hierarchy if the input is empty; name the file (master) http://qi-hw.com/p/eda-tools/4a586fc |
| 16:32.50 | qi-bot | [commit] Werner Almesberger: b2/test/subesc: test regexp escaping in substitutions (master) http://qi-hw.com/p/eda-tools/3f4a068 |
| 16:32.52 | qi-bot | [commit] Werner Almesberger: b2/: add "print VAR" command in substitutions (for debugging/tracing) (master) http://qi-hw.com/p/eda-tools/ee0a2a4 |
| 16:32.54 | qi-bot | [commit] Werner Almesberger: b2/subex.c (compose): search "out" variables before "in" variables (master) http://qi-hw.com/p/eda-tools/31c1c58 |
| 16:32.56 | qi-bot | [commit] Werner Almesberger: b2/test/subcont: test "continue" in substitutions (master) http://qi-hw.com/p/eda-tools/e56a71e |
| 16:33.06 | Ayla | larsc: when one read times out, the JZ_MMC_IRQ_RXFIFO_RD_REQ interrupt is enabled |
| 16:33.32 | Ayla | that interrupt is handled by jz_mmc_irq, which starts the jz_mmc_irq_worker thread |
| 16:33.45 | Ayla | and re-starts a data transfer |
| 16:34.00 | Ayla | but the JZ_MMC_IRQ_RXFIFO_RD_REQ is never cleared |
| 16:35.01 | Ayla | errr |
| 16:36.27 | Ayla | so the transfer should work, as it polls for that flag |
| 16:36.28 | Ayla | ... |
| 16:38.01 | Ayla | it times out on the first try, so it doesn't read a single byte |
| 16:38.53 | *** join/#qi-hardware abushcrafter (55d26110@gateway/web/freenode/ip.85.210.97.16) |
| 16:39.49 | Ayla | larsc: so the jz_mmc_irq pops up because the JZ_MMC_IRQ_RXFIFO_RD_REQ interrupt happens, |
| 16:40.14 | Ayla | but the transfer times out because the JZ_MMC_IRQ_RXFIFO_RD_REQ flag on IREQ is missing. |
| 16:40.20 | Ayla | how good is that? |
| 16:42.55 | *** join/#qi-hardware jurting (~jommpa90_@ip-69-211-230-46.dialup.ice.net) |
| 16:45.04 | larsc | that actually makes some sense |
| 16:45.35 | larsc | can you confirm that it will timeout? |
| 16:47.02 | larsc | is it really the rd_req timeout? |
| 16:47.29 | larsc | Receive FIFO read request. Set if data FIFO becomes half full (the number of words is >= 8) or the entries in data FIFO are the last read data. |
| 16:47.33 | larsc | from the datasheet |
| 16:47.47 | larsc | since we haven't read anything from the fifo it should still be set |
| 16:47.49 | Ayla | yes, it is JZ_MMC_IRQ_RXFIFO_RD_REQ |
| 16:48.01 | Ayla | I read 0x20 on the IREG when the interrupt happens |
| 16:48.41 | larsc | i suppose removing the last jz4740_mmc_set_irq_enabled in the hardirq handler will fix it |
| 16:49.38 | Ayla | larsc: it should still be set, yes |
| 16:49.41 | Ayla | but it's not |
| 16:50.23 | Ayla | otherwise it would not time out |
| 16:50.31 | larsc | yep |
| 16:51.28 | larsc | not acking the interrupts in the hardirq handler seems to be the right fix, because for example we have the same issue for the DATA_TRANSFER_DONE interrupt |
| 16:52.02 | larsc | uhm and forget about what i said about jz4740_mmc_set_irq_enabled, i meant the writel to IREG |
| 16:52.06 | Ayla | we're not acking the rd_req interrupt, because it's not possible |
| 16:52.27 | Ayla | that bit in IREG is read-only |
| 16:53.37 | larsc | so it is cleared after it has been masked? |
| 16:54.23 | larsc | in hw? |
| 16:54.47 | Ayla | it is cleared by the hardware, I believe |
| 16:55.06 | larsc | yes, but why? |
| 16:55.15 | larsc | that's what we want to find out |
| 16:56.17 | Ayla | the first question is why is it cleared, while we can't write it |
| 16:56.36 | Ayla | the second question, is why is the interrupt reappearing? |
| 16:56.40 | larsc | one possibility is that it ANDs the irq mask with the pending interrupts in hardware |
| 16:56.49 | larsc | because we unmask the interrupt again |
| 16:57.13 | larsc | it's actually easy to test. add a second read to IREG right after the jz4740_mmc_set_irq_enabled in the hardirq handler |
| 17:00.00 | Ayla | no, I still read 0x20 |
| 17:00.10 | Ayla | after the mask is written |
| 17:01.10 | larsc | and after writing to ireg? |
| 17:03.50 | Ayla | same value |
| 17:04.00 | larsc | uhm, with mth's patch won't poll_irq always timeout? |
| 17:04.37 | larsc | should this 'if (--timeout_next)' be 'if (--timeout_next == 0)'? |
| 17:06.07 | Ayla | heh... good point |
| 17:11.32 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 17:17.58 | Ayla | ok, now it times out a lot, but it still manages to load the root filesystem |
| 17:19.03 | Ayla | which means that timeouts are not involved in the bug that occurs during resume |
| 17:19.34 | larsc | you can't be sure of that |
| 17:20.06 | Ayla | well, the timeout mechanism seems fine |
| 17:21.32 | larsc | it works fine during normal operation |
| 17:21.41 | larsc | that's all you know |
| 17:22.20 | Ayla | well, yes |
| 17:52.58 | *** join/#qi-hardware xwalk_ (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 17:53.24 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 18:25.50 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 18:31.36 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 19:11.14 | *** join/#qi-hardware phirsch_ (~phirsch@xdsl-89-0-97-10.netcologne.de) |
| 19:13.22 | *** join/#qi-hardware Maroni (~user@046-220-017-119.dyn.orange.at) |
| 20:31.39 | *** join/#qi-hardware compcube (~compcube@d14-69-115-126.try.wideopenwest.com) |
| 20:31.39 | *** join/#qi-hardware compcube (~compcube@pdpc/supporter/student/compcube) |
| 21:26.58 | *** join/#qi-hardware lekernel (~lekernel@g225039146.adsl.alicedsl.de) |
| 21:41.39 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-135.ozonline.com.au) |
| 21:43.11 | mth | larsc: you're right about the timeouts |
| 21:44.08 | mth | is it expected that if everything is done on interrupts it won't mount the rootfs on time, or is there still an issue there? |
| 21:44.43 | mth | mounting a vfat partition shouldn't require all that much data to be read |
| 21:45.31 | Ayla | mth, it's min-init job to mount the rootfs |
| 21:46.18 | Ayla | and it already waits for the SD card to appear |
| 21:46.21 | mth | is it the squashfs mount that times out then? |
| 21:47.07 | Ayla | what timeout are you speaking about exactly? |
| 21:48.17 | Ayla | what I know is that min-init tries to mount the VFAT partition until it eventually succeeds |
| 21:48.37 | Ayla | which is weird, if you ask me, as the SD card should be ready as soon as it appears on /dev |
| 21:49.05 | Ayla | I mean, the kernel should not allow it to appear in /dev if it's not yet ready |
| 21:51.34 | mth | at some point the kernel says it cannot start init and will reboot in 5 seconds |
| 21:52.32 | Ayla | it does so when min-init gives up mounting the VFAT partition or the rootfs |
| 21:55.33 | mth | so it doesn't try until it succeeds then; it gives up after a while if it doesn't succeed |
| 21:57.12 | Ayla | it tries 20 times, each try separated by 100ms |
| 21:58.04 | Ayla | usually it fails a couple of times, that's why you can see errors on dmesg on OD |
| 22:02.30 | Ayla | it would be better, IMHO, to make all calls return -ETIMEDOUT on the kernel, until the card marks itself as reseted |
| 22:04.11 | Ayla | well it probably does that already |
| 23:21.05 | *** join/#qi-hardware panda (~hzhang@2001:5c0:1000:a::307) |
| 23:25.08 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
