| 00:13.47 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-135.ozonline.com.au) |
| 01:15.56 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 02:07.54 | *** join/#qi-hardware xiangfu (~xiangfu@123.117.8.145) |
| 02:16.34 | *** join/#qi-hardware qwebirc5779 (4b653207@gateway/web/freenode/ip.75.101.50.7) |
| 02:17.53 | wpwrak | heh, now the price hike is out :) let's see what happens |
| 02:40.34 | wolfspra1l | nothing will happen |
| 02:50.09 | wpwrak | ;-) |
| 02:50.34 | wpwrak | i guess i should try to organize some angry protests, just to prove you wrong :) |
| 03:04.36 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 03:47.00 | *** join/#qi-hardware sucotronic (~felix@187.Red-83-43-42.dynamicIP.rima-tde.net) |
| 04:11.40 | *** join/#qi-hardware Maroni (~user@94.245.250.53) |
| 04:46.11 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 04:55.47 | *** join/#qi-hardware wolfspraul (~wolfsprau@221.220.180.221) |
| 05:18.56 | *** join/#qi-hardware wolfspra1l (~wolfsprau@222.129.18.5) |
| 05:34.59 | roh | hehe |
| 05:35.05 | roh | price-hike? ah. |
| 05:35.36 | roh | well.. i was actually thinking about buying a efika mx from tuxbrain. they seem to be difficult to get over here |
| 05:42.25 | roh | wolfspra1l: are there no working watches anymore or why does the public mean to give 10mio to these guys?! |
| 05:44.24 | wolfspra1l | don't understand |
| 05:44.38 | wolfspra1l | it's something people like, obviously |
| 05:45.12 | wolfspra1l | I certainly don't ask "why are 10 mio spent on this or that" - if you just look around the world a bit you could ask yourself that question for billions and billions spent every day on total bs |
| 05:45.43 | wolfspra1l | I do like how they pulled it off though, will watch whether they can establish strong/new sales channels. |
| 05:47.26 | roh | wolfspra1l: well.. it doesnt happen that often that one asks for 100k and gets 10mio |
| 05:47.49 | roh | just too sad that i do not carry watches anymore ;) |
| 06:00.32 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 06:05.47 | *** join/#qi-hardware phirsch (~phirsch@xdsl-78-35-51-87.netcologne.de) |
| 07:07.17 | *** join/#qi-hardware kristoffer (~kristoffe@c-34dae555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 07:17.34 | *** join/#qi-hardware Ayla (~paul@250.178.123.78.rev.sfr.net) |
| 07:59.33 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 08:07.07 | qi-bot | The build has FAILED: http://fidelio.qi-hardware.com/~xiangfu/building/Nanonote/Ben/openwrt-xburst.full_system-20120601-0638 |
| 08:48.59 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 08:57.27 | qi-bot | [commit] Werner Almesberger: b2/: rename a bit too general "dump" to "dump_param" (master) http://qi-hw.com/p/eda-tools/b723c88 |
| 08:57.28 | qi-bot | [commit] Werner Almesberger: b2/: new option -dCHARS to dump specific db; replaces use of -v (master) http://qi-hw.com/p/eda-tools/3ebac68 |
| 08:57.29 | qi-bot | [commit] Werner Almesberger: b2/boom.c (main): rearrange to reduce indentation depth (master) http://qi-hw.com/p/eda-tools/be1277e |
| 08:57.30 | qi-bot | [commit] Werner Almesberger: b2/db.c: new function parts_dump to dump the whole parts database (master) http://qi-hw.com/p/eda-tools/2241276 |
| 08:57.32 | qi-bot | [commit] Werner Almesberger: b2/: move parts dumping from lang.y to boom.c and make optional (-dc) (master) http://qi-hw.com/p/eda-tools/f09e4b2 |
| 08:57.34 | qi-bot | [commit] Werner Almesberger: b2/test/Common: support multiple files of the same kind (!-c1, !-c2, etc.) (master) http://qi-hw.com/p/eda-tools/69701f4 |
| 08:57.36 | qi-bot | [commit] Werner Almesberger: b2/lang.y (part): show part ID in error message (master) http://qi-hw.com/p/eda-tools/ea57323 |
| 08:57.38 | qi-bot | [commit] Werner Almesberger: b2/test/char: part characteristics database test (master) http://qi-hw.com/p/eda-tools/dd727b1 |
| 08:58.26 | *** join/#qi-hardware rz2k (~rz2k@ilos.rz2k.ru) |
| 09:11.05 | *** join/#qi-hardware wolfspraul (~wolfsprau@222.129.18.5) |
| 10:13.52 | *** join/#qi-hardware rz2k (~rzk@2002:5f19:9ef6:1:222:4dff:fe7c:450f) |
| 10:59.21 | *** join/#qi-hardware B_Lizzard (~havoc@athedsl-430890.home.otenet.gr) |
| 11:22.01 | *** join/#qi-hardware freespace (foobar@stark.pictorii.com) |
| 11:44.11 | viric | http://vincentpetry.net/blog/?p=151 worth for openwrt/nanonote? |
| 11:54.32 | Ayla | should run out of the box on the dingoo |
| 11:57.41 | viric | ah nice :) |
| 11:57.52 | viric | I even did not care to see if it is packaged already, sorry |
| 11:58.23 | viric | so in the dingoo you run even python games. nice |
| 12:02.25 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 12:09.25 | DocScrutinizer51 | wolfspraul: which nfs version? |
| 12:42.55 | wolfspraul | don't know |
| 13:43.18 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 14:43.12 | *** join/#qi-hardware xwalk_ (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 14:46.50 | *** join/#qi-hardware compcube (~compcube@c-68-43-48-46.hsd1.mi.comcast.net) |
| 14:46.50 | *** join/#qi-hardware compcube (~compcube@pdpc/supporter/student/compcube) |
| 15:45.40 | DocScrutinizer51 | well, I'm just having fun with copying a complete image of $HOMe (~27GB) from my old laptop to a new one, via scp |
| 15:46.27 | DocScrutinizer51 | recovers nicely (when mc is managing that copy via /#sh://) but suuuucks for speed |
| 15:46.48 | DocScrutinizer51 | buzzword fishfs it seems |
| 15:49.47 | viric | the network link is your bottleneck? |
| 15:50.22 | DocScrutinizer51 | nah |
| 15:50.41 | DocScrutinizer51 | friggin fs operations via ssh are |
| 15:50.57 | DocScrutinizer51 | ~20 files/s |
| 15:51.15 | viric | why don't you use rsync for example? |
| 15:51.36 | DocScrutinizer51 | facing another ~12h ETA, plus penalty for each file on source that's not readable by user |
| 15:52.12 | DocScrutinizer51 | viric: because I'm a lazy asshole and just realized mc can connect to the ssh of source PC |
| 15:52.24 | viric | not a bad reason |
| 15:52.50 | viric | at least mc provides ETA. |
| 15:52.57 | viric | I don't know any other tool that des |
| 15:52.59 | viric | does |
| 15:53.30 | DocScrutinizer51 | I nevertheless evaluated option a tiny bit before, and concluded rsync via ssh would do exactly the same, but without nice progress indicator and requesters etc |
| 15:53.34 | viric | I'm more of: ssh pc "tar c /home" | tar x |
| 15:53.35 | viric | :) |
| 15:53.59 | viric | well, rsync via ssh would not have a slowdown of fs operations through ssh |
| 15:54.16 | viric | rsync gives work to the remote rsync. |
| 15:54.23 | DocScrutinizer51 | you *might* be right actually |
| 15:54.45 | DocScrutinizer51 | initially I thought "whatever time it takes, I'm not in a hurry" |
| 15:55.47 | DocScrutinizer51 | now I realize I have to observe this process for 12h, to eventually hit return to make a warning requester go away, whenever there's a file owned by root and not user, and not readable by user |
| 15:57.47 | viric | ha. :) |
| 15:57.54 | viric | if you know the size of the data... use 'pv' |
| 15:58.14 | viric | ssh pc "tar cp /home" | pv -S 23g | tar xp |
| 15:58.18 | viric | and you'll get an ETA. :) |
| 15:58.21 | viric | ssh pc "tar cp /home" | pv -a -S 23g | tar xp |
| 15:58.29 | viric | the averaging may work better for ETA. |
| 15:59.33 | viric | store the 'tar' stderr, and you'll have a list of the errors. |
| 15:59.44 | viric | ssh pc "tar cp /home" 2> tarc-errors.txt | pv -a -S 23g | tar xp |
| 16:56.18 | *** join/#qi-hardware lekernel (~lekernel@g225039002.adsl.alicedsl.de) |
| 17:23.59 | DocScrutinizer51 | I used sftp from console now, logging in to source PC as root --- rocks! |
| 17:24.40 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 17:25.11 | DocScrutinizer51 | from scroll spreed in xterm I estimate I'm up from ~20fileops/s to >500 now |
| 17:27.23 | DocScrutinizer51 | well, this might have been the part where dest files already been existing |
| 17:27.36 | DocScrutinizer51 | suddenly it dropped significantly |
| 17:34.08 | *** join/#qi-hardware kuribas (~user@94-227-36-245.access.telenet.be) |
| 17:36.42 | DocScrutinizer51 | still, I'm confident it won't take longer than 2 hours now |
| 17:40.18 | *** join/#qi-hardware Ayla (~paul@233.188.103.84.rev.sfr.net) |
| 17:56.26 | DocScrutinizer51 | mhm, 2 minutes for qi ML |
| 17:56.41 | DocScrutinizer51 | /home/jr/.kde/share/apps/kmail/mail/.lists.directory/qi/cur/1292839187.22703.sSFlI 100% 5131 5.0KB/s 00:00 |
| 18:00.55 | DocScrutinizer51 | those 130,000 mails suck for sftp, even at an estimated rate of 100/s |
| 18:02.11 | viric | it depends on your filesystem too |
| 18:03.24 | viric | if it seeks once per letter... on a 7200rpm disk it will do little more than 100/s |
| 18:03.58 | viric | with sftp you still have each file requested remotely, one by one. |
| 18:07.34 | DocScrutinizer51 | sure |
| 18:07.54 | DocScrutinizer51 | /home/jr/.kde/share/apps/kmail/mail/.lists.directory/.openmoko.directory/.public.directory/cmty/cur/1326897176.26507.33lRp 100% 7094 6.9KB/s 00:00 |
| 18:08.20 | viric | good luck. |
| 18:08.42 | DocScrutinizer51 | I hope it'll be thru with mail eventually |
| 18:09.37 | viric | I don't think sftp will respect symlinks, dates, ... |
| 18:11.52 | DocScrutinizer51 | -pr will |
| 18:12.16 | DocScrutinizer51 | bottleneck CPU still, not HDD: Avg: 25.1% sy: 5.1% ni: 0.0% hi: 0.0% si: 0.6% wa: 35.4% |
| 18:13.23 | DocScrutinizer51 | which makes a total of 100% on one of both cores, plus a bit on other one |
| 18:13.40 | DocScrutinizer51 | wa is it |
| 18:14.56 | DocScrutinizer51 | device reads SDA (8.0): ~80/s max |
| 18:15.02 | DocScrutinizer51 | usually way ,ower |
| 18:15.05 | DocScrutinizer51 | lower* |
| 18:15.35 | DocScrutinizer51 | well, no, that's actually average. max is 500 |
| 18:17.43 | DocScrutinizer51 | those 80 though could actually be the msg files read one by one |
| 18:21.21 | DocScrutinizer51 | *yawn* |
| 18:21.34 | DocScrutinizer51 | watching make runs is more fun ;-) |
| 18:24.43 | DocScrutinizer51 | *yaaaawn* /home/jr/.kde/share/apps/kmail/mail/.lists.directory/.openmoko.directory/.public.directory/cmty/cur/1221116234.3915.HLS8k:2,S 100% 3816 3.7KB/s 00:00 |
| 18:25.48 | DocScrutinizer51 | sobs for all the inodes |
| 18:26.52 | wpwrak | if you delete all the files, your inodes will enjoy freedom again :) |
| 18:27.49 | DocScrutinizer51 | jr@halley:~> find /home/jr/.kde/share/apps/kmail/mail/ |wc -l |
| 18:27.50 | DocScrutinizer51 | 154729 |
| 18:28.49 | DocScrutinizer51 | took an amazing ~5s to complete, despite this sftp monster running concurently |
| 18:29.33 | DocScrutinizer51 | YAY OM-kernel ML |
| 18:29.47 | DocScrutinizer51 | through with community |
| 18:30.32 | DocScrutinizer51 | anyway mail takes >30% of the files to copy |
| 18:30.51 | DocScrutinizer51 | number of, not volume |
| 18:32.41 | DocScrutinizer51 | \o/ internal |
| 18:43.08 | qi-bot | [commit] Werner Almesberger: fisl2011/Makefile (DL): Atben_atusb_prod_03.jpg was missing (master) http://qi-hw.com/p/wernermisc/8418a19 |
| 18:43.49 | DocScrutinizer51 | and stalled >:-( |
| 18:48.39 | DocScrutinizer51 | fsck that d-link dir615, which obviously has problems with occasionally dropping ARP table or whatever |
| 18:49.01 | DocScrutinizer51 | or firewall/NAT hangups |
| 18:49.55 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-157-201.netcologne.de) |
| 18:57.06 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 19:24.16 | *** join/#qi-hardware kilae_ (~chatzilla@catv-161-018.tbwil.ch) |
| 19:43.23 | DocScrutinizer51 | fuuuuuck, sftp won't resume, I.E. will start from very first file again, ignoring all the stuff already copied. Worse: rsync does that too :-o |
| 19:44.31 | DocScrutinizer51 | seems rsync hold a local file where it keeps a list of files already synced, and it doesn't care at all about actually existing real files on destination |
| 19:47.08 | DocScrutinizer51 | or maybe not |
| 19:47.34 | DocScrutinizer51 | already at "xfer#25322" |
| 19:55.17 | DocScrutinizer51 | 44k done 61k left |
| 20:02.07 | *** join/#qi-hardware Maroni (~user@94.245.250.111) |
| 20:23.25 | DocScrutinizer51 | left 1900 of 171000 |
| 20:24.30 | DocScrutinizer51 | and friggin rsync is way slower than sftp: while sftp maxed out a ~11MB/s on large files, rsync gets to 3.xMB/s when lucky |
| 20:25.37 | DocScrutinizer51 | and the WTF: it's not been dir615 but the sis190 kernel module of source machine. Had to modprobe-cycle it to make the NIC work again |
| 20:25.58 | DocScrutinizer51 | "it"=the lockup |
| 20:57.17 | *** join/#qi-hardware Ayla (~paul@197.94.102.84.rev.sfr.net) |
| 21:25.18 | *** join/#qi-hardware hypermodern_ (~pete@netblock-208-127-216-39.dslextreme.com) |
| 21:26.10 | *** part/#qi-hardware hypermodern_ (~pete@netblock-208-127-216-39.dslextreme.com) |
| 22:21.24 | DocScrutinizer51 | sigh |
| 22:21.32 | DocScrutinizer51 | sent 8096479 bytes received 19742271984 bytes 2132984.34 bytes/sec |
| 22:21.34 | DocScrutinizer51 | total size is 28602138243 speedup is 1.45 |
| 22:21.36 | DocScrutinizer51 | rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1530) [generator=3.0.9] |
| 22:23.37 | wpwrak | make a tar and scp it ? or would that be too easy ? :) |
| 22:23.59 | wpwrak | extra points for rsyncing the tar, since this will let you restart |
| 22:24.22 | DocScrutinizer51 | make a tar of 28GB, on a disk that has 300MB free? |
| 22:24.34 | DocScrutinizer51 | suuure |
| 22:24.40 | wpwrak | delete all the porn first :) |
| 22:28.09 | DocScrutinizer51 | well, seems it's thru now. but now I have a dir /home/jr/halley with lots of stuff in it. And a dir /home/jr/halley/home/jr, with all the stuff in it again :-S |
| 22:29.40 | wpwrak | that's called a "backup" :) |
| 22:29.50 | DocScrutinizer51 | could you tell from the cmdline >> rsync -vaRzxP --fake-super root@192.168.1.30:/home/jr/ ~/halley/jr/ << which is the real stuff now? |
| 22:30.53 | wpwrak | my bet would be on the subdirectory |
| 22:31.20 | wpwrak | but you can just move it out. then do a du -sh to compare size |
| 22:31.31 | DocScrutinizer51 | indeed |
| 22:31.53 | wpwrak | or diff -r if you're bold and they should be the same :) |
| 22:31.55 | DocScrutinizer51 | already thought abizt du -sh, but thanks for the moving suggestion |
| 22:32.09 | DocScrutinizer51 | about* |
| 22:36.50 | DocScrutinizer51 | jr@HaleBopp:~/halley/jr> du -sh /home/jr/halley2/home/jr/; du -sh /home/jr/halley |
| 22:36.50 | DocScrutinizer51 | 28G /home/jr/halley2/home/jr/ |
| 22:36.52 | DocScrutinizer51 | 13G /home/jr/halley |
| 22:36.56 | DocScrutinizer51 | wpwrak: thanks |
| 22:37.43 | DocScrutinizer51 | it seems like the destination argument on that rsync cmd took no effect at all |
| 22:38.51 | DocScrutinizer51 | anyway 28G is what I expected |
| 22:39.34 | wpwrak | you could du a find with md5sum on source and origin to be 100% sure |
| 22:39.43 | wpwrak | s/du /do |
| 22:39.45 | qi-bot | wpwrak meant: "you could do a find with md5sum on source and origin to be 100% sure" |
| 22:41.09 | *** join/#qi-hardware qwebirc27345 (4766dbad@gateway/web/freenode/ip.71.102.219.173) |
| 22:41.10 | wpwrak | cd /home/jr/halley; find . -type f -exec md5sum '{}' \; >~/output |
| 22:41.44 | wpwrak | then do a sort out1 out2 | uniq -u |
| 22:41.45 | DocScrutinizer51 | what for? |
| 22:42.00 | rjeffries | wolfspraul expresed interest in making hos own PCBs. this article is not bad. http://hackaday.com/2012/06/02/pcb-manufacturing-tutorial/ |
| 22:42.07 | wpwrak | that will allow you to see if a) all the files made it and b) if they were copied correctly |
| 22:42.34 | rjeffries | s /hos/his/ |
| 22:43.11 | DocScrutinizer51 | this will take longer than doing another rsync |
| 22:46.35 | wpwrak | no. worst case, it takes just as long :) |
| 22:47.13 | DocScrutinizer51 | friggin idiot I am, giving -R parameter without thinking |
| 22:50.19 | wpwrak | better than --remove-source-files :) |
| 22:52.35 | wpwrak | rjeffries: seems reasonably up to date. the etchant tank is a bit overkill, though, unless you plan to do monster boards |
| 22:53.53 | rjeffries | wprak did you see [not talking about this artcle] where one person made a spray chamber so he could etch boards quickly with no muss or fuss? amusing. |
| 22:53.55 | wpwrak | he seems a bit confused about what 3D printers do, too |
| 22:55.31 | DocScrutinizer51 | HAH, now the benefits of rsync hit |
| 22:55.37 | DocScrutinizer51 | +mwDGO1eWKyOiCJnpYZVFtUcItXrsync: readlink_stat("/home/jr/.gvfs") failed: Permission denied (13) |
| 22:55.38 | DocScrutinizer51 | rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1530) [generator=3.0.9] |
| 22:56.06 | DocScrutinizer51 | second run was "lightning fast" |
| 22:57.00 | DocScrutinizer51 | nfc what's this >>key_read: uudecode AAAAB3NzaC1kc3MAAAEBAP8Bo+QhQ...<< foo at beginning though |
| 22:57.49 | DocScrutinizer51 | friggin 7 lines of uuencoded key, WHY oh WHY? |
| 22:58.26 | wpwrak | rjeffries: the chemistry link is interesting, though: http://www.stephenhobley.com/blog/2011/03/02/still-messing-with-forces-i-dont-understand-the-formula/ |
| 22:58.47 | wpwrak | replacing the muriatic acid (HCl) with household chemicals |
| 22:58.57 | DocScrutinizer51 | OUCH |
| 22:59.34 | wpwrak | i just hope those people never get their hands on higher grade peroxide. the graveyard of overly adventurous pioneers is already quite full :) |
| 22:59.42 | DocScrutinizer51 | he could rub some marshmallows on it and let ants eat away the copper |
| 23:03.27 | DocScrutinizer51 | ~curse gnome and all g* |
| 23:03.27 | infobot | May you be reincarnated as a Windows XP administrator, gnome and all g* ! |
| 23:03.43 | wpwrak | that could work. probably a bit slow, though |
| 23:04.33 | wpwrak | faster than just waiting for proton decay, though :) |
| 23:09.06 | DocScrutinizer51 | wpwrak: would you be interested in getting involved into a bit of kernel development discussion? |
| 23:11.05 | wpwrak | the kernel is vast. what area of it ? |
| 23:12.32 | DocScrutinizer51 | there's this guy FreemanGordon over there at #maemo-ssu, and he investigated for almost a felt year now how to make thumb interworking working on N900 which has an OMAP with a silicon erratum that fscks up the branch prediction when you (mem)swap a thumb branch for a ARM branch, or sth like that |
| 23:13.31 | DocScrutinizer51 | actually there are (at least) two silicon errata, and common urban legend is the fixes for those two are mutually exclusive |
| 23:13.44 | wpwrak | nice ;-) |
| 23:13.58 | wpwrak | sounds like a topic for the linux-arm list ? |
| 23:14.03 | DocScrutinizer51 | freemanG now claims he made it work, but none of the "experts" is willing to listen |
| 23:15.14 | DocScrutinizer51 | which is kinda expected, since that OMAP3430 is rather old silicon anyway |
| 23:15.53 | wpwrak | did he try that list ? i'm no longer on it, so it can't check quickly |
| 23:15.58 | DocScrutinizer51 | and not much to earn on fixing kernel stuff to make thumb interworking fixed for that particular chip - at least unless you're a fan of N900 |
| 23:16.17 | DocScrutinizer51 | list not yet afaik |
| 23:16.42 | wpwrak | thumb is for running closed binaries ? |
| 23:18.29 | DocScrutinizer51 | well, thumb is a smaller (16bit) alternative opcode set |
| 23:18.46 | DocScrutinizer51 | or what's been the question? |
| 23:19.16 | DocScrutinizer51 | his interest is in reducing RAM footprint of certain libraries like Qt etc |
| 23:19.46 | DocScrutinizer51 | since N900 is in a permanent swap hell |
| 23:20.39 | wpwrak | ah, i see |
| 23:20.43 | DocScrutinizer51 | thumb instruction set is supposed to be ~30% smaller than ARM, but possibly slower in execution |
| 23:20.59 | wpwrak | i think (conceptually) what thumb is. just never saw anyone actually use it |
| 23:21.24 | DocScrutinizer51 | you usually don't even realize I guess |
| 23:21.24 | wpwrak | you mean s/instruction set/code size/ ? |
| 23:21.40 | DocScrutinizer51 | err yep |
| 23:22.25 | DocScrutinizer51 | e.g. STE modem is all thumb afaik |
| 23:22.40 | wpwrak | evil blobs :) |
| 23:22.51 | DocScrutinizer51 | sure |
| 23:24.55 | DocScrutinizer51 | do you think you could give some guidance what to post to linux-arm ML |
| 23:26.01 | DocScrutinizer51 | *my* problem with FreemanG is that our ideas of patch validation differ vastly |
| 23:26.05 | wpwrak | i'm only an occasional visitor there myself. haven't posted there since openmoko. so i wouldn't have any specific recommendations. just do the usual - describe problem, solution, and see what happens |
| 23:26.24 | wpwrak | patch validation ? |
| 23:27.01 | DocScrutinizer51 | somehow I think such a patch for a silicon erratum has to be validated somehow |
| 23:27.08 | DocScrutinizer51 | to be effective |
| 23:27.25 | DocScrutinizer51 | and actually target the problem comprehensively |
| 23:27.53 | wpwrak | well it needs testing, like anything else. if the erratum is version-dependent, it may need a switch, too |
| 23:28.32 | DocScrutinizer51 | esp since here we got 2 bugs in chip, with common notion (seemingly based on rumour) being that the already esisting patches are mutually exclusive |
| 23:30.03 | DocScrutinizer51 | and my approach is based on building a testbed that 100% reproducably and traceably invokes the problem |
| 23:30.59 | DocScrutinizer51 | while FMG's approach is "it's not possible to write such testbed. but ubuntu is all thumb and it runs on my N900 since 3 weeks now. That's proof enough" |
| 23:32.21 | DocScrutinizer51 | maybe slightly different rationale and wording, but the general idea AIUI is like that |
| 23:34.42 | DocScrutinizer51 | I'm affraid with this approach of his, he won't see benevolent reviews on linux-arm ML |
| 23:35.04 | wpwrak | he does seem to have a certain, erm, assertive style, yes |
| 23:35.16 | DocScrutinizer51 | that's where your comments are welcome |
| 23:37.22 | wpwrak | just tell him the key guys on linux-arm have had daily exercise as top of the foodchain bullies for the last 20 years. he's not going to out-stubborn them ;-) |
| 23:37.50 | wpwrak | well, some of them have. others are gentle :) |
| 23:37.52 | DocScrutinizer51 | (version dependent) one of the fixes - published by TI itself - is by setting some bit in auxiliary control register of CPU, to flush branch prediction on every context switch (whatever that means, now that I come to think of it) |
| 23:38.33 | DocScrutinizer51 | obviously there is a performance penalty in flushing branch prediction frequently |
| 23:39.05 | wpwrak | if it's just per context switch, that should be negligible |
| 23:39.18 | DocScrutinizer51 | usually yes |
| 23:40.52 | DocScrutinizer51 | then there's another bug that kicks in on that (or not), related to commands that flush branch prediction which may result in some nonsensical CPU action (like branching to a destination offset by an unrelated obscure register) |
| 23:41.52 | DocScrutinizer51 | and patch for that is to either not use the flush-branch-prediction-queue instructions, or to initialize that random bogus unrelated register to 0, so it won't affect stuff |
| 23:41.52 | wpwrak | maybe whitequark could write a thumb decompiler for you ;-) then you could recompile the whole mess with something that's actually been tested :) |
| 23:42.35 | wpwrak | so zero-initialize and flush, to kill both birds ? |
| 23:42.37 | DocScrutinizer51 | all disclaimer: IIRC & AIUI |
| 23:44.07 | DocScrutinizer51 | yeah, and that's where fun starts: so far nobody was able to do that (except Nokia), as you can access that auxiliary register only in secure mode / context. The secure context gets irreversibly locked during bootloader execution |
| 23:44.31 | qi-bot | [commit] Werner Almesberger: b2/test/curr: currency exchange test (master) http://qi-hw.com/p/eda-tools/0ba0abb |
| 23:44.32 | qi-bot | [commit] Werner Almesberger: b2/lang.y (provider): don't allow provider to be redefined (master) http://qi-hw.com/p/eda-tools/994ed00 |
| 23:44.33 | qi-bot | [commit] Werner Almesberger: b2/test/prov: provider database test (master) http://qi-hw.com/p/eda-tools/4184c01 |
| 23:44.35 | qi-bot | [commit] Werner Almesberger: b2/test/Common (run_boom): place inventory after parts and currency (master) http://qi-hw.com/p/eda-tools/e62bb06 |
| 23:44.37 | qi-bot | [commit] Werner Almesberger: b2/test/inv: inventory database test (master) http://qi-hw.com/p/eda-tools/cc5d9a9 |
| 23:44.39 | qi-bot | [commit] Werner Almesberger: b2/: move substitutions dump from parser to boom.c (master) http://qi-hw.com/p/eda-tools/3027dac |
| 23:44.41 | qi-bot | [commit] Werner Almesberger: b2/: insert a virtual empty hierarchy if test input starts with other file (master) http://qi-hw.com/p/eda-tools/d1593b6 |
| 23:44.54 | DocScrutinizer51 | FMG now claims he found a "BIOS call" to write to that register from normal linux context |
| 23:45.08 | wpwrak | OMG :) |
| 23:45.35 | wpwrak | how can the BIOS write to an "irreversibly locked" register ? |
| 23:45.47 | DocScrutinizer51 | it's basically like a usual age old sw irq |
| 23:46.09 | DocScrutinizer51 | "BIOS" = ROM bootloader code here |
| 23:47.03 | wpwrak | so it depends on the location of the executing code ? because it doesn't seem to be locked. else it wouldn't matter what you do once linux runs |
| 23:47.28 | DocScrutinizer51 | AIUI there's a way to trigger an exception that switches state of CPU to secure context and same time jumps to the "BIOS" code - just like good old INTxx |
| 23:48.42 | DocScrutinizer51 | it's just the RING0, RING-N concept |
| 23:48.44 | wpwrak | ah, i see. well, if that register doesn't get changed by anything else, then he can put that magic code in the platform-specific initialization |
| 23:49.01 | wpwrak | and still flush branch prediction on each context switch |
| 23:49.30 | DocScrutinizer51 | yep, probably that's what he does, or plans to do, or whatever |
| 23:49.47 | DocScrutinizer51 | I not *completely* wrapped my head around all that yet |
| 23:52.42 | *** join/#qi-hardware Ayla (~paul@197.94.102.84.rev.sfr.net) |