#milkymist IRC log for Monday, 2011-08-01

aw_Does https://github.com/milkymist/bugs/issues/26 influence my current test works on rc3 boards now? ;-)02:24
aw_or it doesn't matter?02:24
kristianpauli think is a technical detail nor practical02:39
aw_so happy to continue using my current test image, right?02:41
aw_;-)02:41
aw_0x33; so good that VGA DDC failed at test image firstly was a false alarm caused my VGA cable un-close together with vga connector on m1. means that my vga cable's pins not have good contacts connection(male), I could buy a new one next time. I hope rest failed about DDC failed with this the reason. ;-)03:39
kristianpaulyou mean this vga-cable issue aply to several boards?03:40
wolfspraulkristianpaul: be patient :-)03:41
kristianpaulheh03:41
kristianpaulok03:41
kristianpaulbut sounds good, every problem seems to be solve replacing a cable ;-)03:41
wolfspraultesting is like this, you just don't know where the insight/root cause will pop up. can be all sorts of things.03:41
kristianpauli can imagine03:41
aw_the signals of SDA & SCL on failed board measured is good.03:42
wolfspraulit's not the first time that I've had a case where the pins of a cable broke03:42
wolfspraulconnectors are designed for certain duty cycles03:42
wolfspraulbut by definition in a test environment the connectors of the test equipment may be used far beyond the design of the connector03:42
wolfspraulso we just have to replace the test cables/connectors regularly, as part of keeping the test environment itself free from problems :-)03:43
aw_so hope all rest r, g, b analog signals are also caused by this reason, I'll spot them soon.03:43
wolfspraulI've seen _TOTALLY_ worn out connectors on factory lines, regularly03:43
wolfspraulkristianpaul: some connectors are, by design, meant to survive only 10 insert/remove cycles :-) can you imagine?03:43
wolfspraulin their lifetime03:44
aw_yup...i have to prepare maybe 2 ~ 3 pcs vga cable to switch them to keep be as good testing tools.03:44
kristianpaul10?!!!03:44
wolfspraulothers are designed for 1000, 5k, 10k, into the millions (but those are very special connectors then)03:44
wolfspraulwhen you just 'use' consumer goods, you tend to forget this03:44
wolfspraulyou don't realize that it's all designed with some goals in mind, nothing lasts forever03:44
wolfspraul(in hardware)03:44
wolfspraulyes, 10 :-)03:44
wolfspraulfor example certain FPC connectors03:45
aw_but seems that having a extended vga cable with 1 meter female to male type I have to prepare.03:45
wolfspraulkristianpaul: but my point is, every connector is designed for a certain lifetime/connect cycles. keep in mind. it's not 'indefinite'03:45
kristianpaulyeah, i killed a usb cable last week.. was from my first nokia phone two years ago !!03:46
wolfspraulsince it's mechanical and wears out, eventually something will break03:46
wolfspraulyup, there you go03:46
wolfspraulUSB is mostly in the 'thousands' of connect cycles, I think03:47
wolfspraul5K or so03:47
wolfspraulthere may be something in the standard, and then individual connectors or cables may try to go a little higher or don't care and go lower03:47
wolfspraulit's a consumer connector so people will rarely go through 5k of connect cycles03:47
wolfspraulanyway03:48
wolfspraullet's see how Adam's findings continue :-)03:48
kristianpaulyes i'm in patient/read only mode now03:48
wolfspraulI do hope we quickly can increase the number of PASS boards. so far the results are tough. but what can we do, right? stay calm and keep working and thinking :-)03:49
wolfspraulwe cannot blame any process, source, vendor, design choice, etc. until we can trace down real root causes03:50
kristianpaulMay be is same cable used in rc1, rc2? wich end of life is rc3 :-)03:50
Action: kristianpaul no more blames03:53
wolfspraulkristianpaul: no it's good. let's call it 'finding root causes'03:56
wolfspraultesting is an amazing challenge, I really like it, even after all these years. it just plays with your mind.03:56
wolfspraulif you keep testing something that never finds a problem, you should stop that test, right?03:56
wolfspraulbut at the same time you should not overlook anything unexpected, and be prepared for whatever unknown new problem may hit you, right?03:57
wolfspraulhow are those 2 possible at the same time?03:57
wolfspraulso the ideal test is more like a miracle. the moment you realize it's needed, you immediately find the problem. :-)03:59
wpwrakwolfspraul: (10 insertions) totally unthinkable ! the openmoko debug cable never existed. it's all a dirty lie ;-)04:25
rohmorning04:25
roh*yawn* .. yikes... monday. 1.8. new month. not even 6:30am04:26
GitHub105[flickernoise] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/flickernoise/commit/575e5813ddbc4be3ba89e65e3c3a06543ceb130009:13
GitHub105[flickernoise/master] YAFFS: flush task - Sebastien Bourdeauducq09:13
GitHub140[rtems] sbourdeauducq pushed 8 new commits to master: https://github.com/milkymist/rtems/compare/48c2947...189c80a09:53
GitHub140[rtems/master] 2011-07-31Joel Sherrill <joel.sherrilL@OARcorp.com> - joel09:53
Last message repeated 2 time(s).09:54
GitHub171[rtems] sbourdeauducq pushed 1 new commit to mmstaging: https://github.com/milkymist/rtems/commit/2d6d1edd467a22bc40cadd686081d5f0d1138f3610:31
GitHub171[rtems/mmstaging] Merge branch 'master' into mmstaging - Sebastien Bourdeauducq10:31
Alarmis it possible to have your opinion on these errors?10:40
Alarmhttp://pastebin.com/z1QXVRFj10:40
Alarmthe source file:10:42
Alarmhttp://pastebin.com/z1QXVRFj10:42
Alarmoups : The source file : http://pastebin.com/AiVJ3J5M10:44
GitHub133[rtems] sbourdeauducq pushed 1 new commit to mmstaging: https://github.com/milkymist/rtems/commit/af64cbc07f4357bace63b79486525e14c722cd3810:49
GitHub133[rtems/mmstaging] Update ChangeLog - Sebastien Bourdeauducq10:49
GitHub85[rtems] sbourdeauducq pushed 1 new commit to mmstaging: https://github.com/milkymist/rtems/commit/cce9e54216aa25710faeeb37fadbeb63ace44dbe10:50
GitHub85[rtems/mmstaging] removed score from changelog - Sebastien Bourdeauducq10:50
GitHub143[scripts] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/scripts/commit/3e09df1c556d362c2cb31e9c0a64d32a821eff4e11:36
GitHub143[scripts/master] Match latest development software - Sebastien Bourdeauducq11:36
FallenouAlarm: you should test the return value of open11:51
FallenouAlarm: after modifying the framebuffer, you should swap the buffers I think11:58
Fallenou(using the ioctl FBIOSWAPBUFFERS)11:58
Fallenouwell if you are in triple buffered mode11:58
Fallenouok it seems you are in single buffered mode, so forget about swapping12:00
FallenouAlarm: add a "volatile" to the declaration of the "pixels" variable maybe ?12:01
FallenouAlarm: anyway cannot read the link containing errors ( http://pastebin.com/z1QXVRFj )12:06
Fallenouit says "unknown paste ID"12:06
Action: larsc just wrote his very first gcc optimization :) reduces the kernel image size by ~8k12:33
AlarmFallenou: http://pastebin.com/paRn4BpG12:36
lekernellarsc, if you send me gcc patches I can commit them12:39
larsclekernel: ok12:43
FallenouAlarm:  RETEMS_INTERRUPT_LEVEL(0)12:43
Fallenouyou have a typo there12:43
Fallenouline 4312:44
Fallenouyou missed 42 by 1 :)12:44
larsci still don't get why gcc puts constants into the constant pool when optimization is enabled12:46
AlarmFallenou: right! I had not seen. I understand the relationship between the typographical error and the error message. thank you very much12:59
Fallenounp you're welcome :)12:59
lekernelI wonder how Xst handles synthesizing recursive VHDL functions16:16
lekernelhe, seems it's doing the right thing :)16:34
mwallelarsc: after sleeping about it. i think its still a gcc bug17:12
mwallebut not in our case, where its a macro17:12
mwallebut http://paste.debian.net/124773/ doesnt work either17:17
larscmwalle: i though the same thing when i woke up this morning17:26
mwallelol ;)17:27
mwalle DrJoel | I don't think so but worth popping on the list. It might be considered one.. I am betting it is just "don't do that" :-D17:46
larschm, it doing tail call optimization for lm32 has great potential. if i'm not mistaken we should always be able to translate 'call x; lw ra (sp+4); addi sp, sp, 4; ret;' to 'b x'17:48
larscok, we still need to load r and increment the stack register17:50
larscbut there are a lot of cases where ra was just pused onto the stack before the function call17:51
larscabout 1/5 of all kernel functions could make use of such an optimization18:09
mwallelarsc: load r?20:24
larscmwalle: load r?20:29
mwallelarsc | ok, we still need to load r and increment the stack register20:30
mwalleload ra?20:30
larscif it has been overwritten by a non tail call20:31
lekernelwolfspraul, more sourcing problems? http://en.qi-hardware.com/wiki/File:M1_rc3_0x37_u20s_mark_is_faked.png ......20:33
mwallelarsc: could you give a more detailed example? :)20:43
mwallera should be pushed onto the stack within the function prologue if call or calli is used20:44
larscand poped from the stack in the epilogue20:56
larscwhich is what i meant by load20:56
larscand ra only needs to be pushed on the stack if the function is not a leaf20:59
larscfurthermore we can optimize the code, so that ra doesn't need to be pushed on the stack if there is only one function call which is a tail call21:00
larscat least as far as i can see there is no abi requirement that would prevent it21:10
mwallelarsc: what about backtracing?21:22
mwallelarsc: http://gcc.gnu.org/ml/gcc/2011-08/msg00026.html21:47
larschm, right the function would disapear from the call graph, if backtraced21:55
larsci've been scanning through the kernel objcode looking for stupid constructs. and i've been wondering if we should add our own atomic operations22:02
larsccurrenlty atomic_dec evaluates to upper while the lower would be a more efficient solution http://pastebin.com/Mp1HRCWF22:03
mwallelarsc: one could do wcsr IE, r0 instead of the andi r3, r4, 0xfffe; wcsr IE, r322:11
larscyes. the end and is only there because of the good old times ;)22:13
larscinteresting but unimportant fact: there is exaclty one xnor instruction in the whole kernel22:23
larscthe optimized atomic operations reduce the size by about 24k22:28
mwallelarsc: could you review the patch i sent to the mm mailinglist?23:10
mwalleim going to bed now ;)23:11
larschm, i'm not sure whether it is correct23:14
larscbut i guess it is23:16
HodappI am surprised I haven't stumbled upon this project yet, but it looks quite interesting and well-developed.23:59
--- Tue Aug 2 201100:00

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