Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
Textmode has joined #qi-hardware
rejon has joined #qi-hardware
urandom__ has quit [Remote host closed the connection]
xiangfu has joined #qi-hardware
qwebirc5779 has joined #qi-hardware
<wpwrak>
heh, now the price hike is out :) let's see what happens
qwebirc5779 has quit [Ping timeout: 245 seconds]
emeb has quit [Quit: Leaving.]
<wolfspra1l>
nothing will happen
<wpwrak>
;-)
<wpwrak>
i guess i should try to organize some angry protests, just to prove you wrong :)
xiangfu has quit [Ping timeout: 245 seconds]
xiangfu has joined #qi-hardware
sucotronic has quit [Ping timeout: 265 seconds]
sucotronic has joined #qi-hardware
Maroni has quit [Ping timeout: 260 seconds]
Maroni has joined #qi-hardware
xwalk has quit [Ping timeout: 265 seconds]
xwalk has joined #qi-hardware
xwalk has quit [Ping timeout: 244 seconds]
wolfspraul has joined #qi-hardware
wolfspra1l has quit [Ping timeout: 245 seconds]
Textmode has quit [Ping timeout: 255 seconds]
wolfspra1l has joined #qi-hardware
wolfspraul has quit [Ping timeout: 248 seconds]
<roh>
hehe
<roh>
price-hike? ah.
<roh>
well.. i was actually thinking about buying a efika mx from tuxbrain. they seem to be difficult to get over here
<roh>
wolfspra1l: are there no working watches anymore or why does the public mean to give 10mio to these guys?!
<wolfspra1l>
don't understand
<wolfspra1l>
it's something people like, obviously
<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
<wolfspra1l>
I do like how they pulled it off though, will watch whether they can establish strong/new sales channels.
<roh>
wolfspra1l: well.. it doesnt happen that often that one asks for 100k and gets 10mio
<roh>
just too sad that i do not carry watches anymore ;)
jekhor has joined #qi-hardware
phirsch has quit [Ping timeout: 252 seconds]
phirsch has joined #qi-hardware
xiangfu has quit [Remote host closed the connection]
<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
<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
<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
<viric>
I even did not care to see if it is packaged already, sorry
<viric>
so in the dingoo you run even python games. nice
DocScrutinizer has quit [Ping timeout: 265 seconds]
DocScrutinizer has joined #qi-hardware
<DocScrutinizer51>
wolfspraul: which nfs version?
<wolfspraul>
don't know
DocScrutinizer has quit [Ping timeout: 265 seconds]
DocScrutinizer has joined #qi-hardware
rejon has quit [Ping timeout: 260 seconds]
B_Lizzard has quit [Remote host closed the connection]
xwalk_ has quit [Quit: Leaving]
xwalk_ has joined #qi-hardware
compcube has joined #qi-hardware
compcube has quit [Changing host]
compcube has joined #qi-hardware
<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
<DocScrutinizer51>
recovers nicely (when mc is managing that copy via /#sh://) but suuuucks for speed
<DocScrutinizer51>
buzzword fishfs it seems
<viric>
the network link is your bottleneck?
<DocScrutinizer51>
nah
<DocScrutinizer51>
friggin fs operations via ssh are
<DocScrutinizer51>
~20 files/s
<viric>
why don't you use rsync for example?
<DocScrutinizer51>
facing another ~12h ETA, plus penalty for each file on source that's not readable by user
<DocScrutinizer51>
viric: because I'm a lazy asshole and just realized mc can connect to the ssh of source PC
<viric>
not a bad reason
<viric>
at least mc provides ETA.
<viric>
I don't know any other tool that des
<viric>
does
<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
<viric>
I'm more of: ssh pc "tar c /home" | tar x
<viric>
:)
<viric>
well, rsync via ssh would not have a slowdown of fs operations through ssh
<viric>
rsync gives work to the remote rsync.
<DocScrutinizer51>
you *might* be right actually
<DocScrutinizer51>
initially I thought "whatever time it takes, I'm not in a hurry"
<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
<viric>
ha. :)
<viric>
if you know the size of the data... use 'pv'
<viric>
ssh pc "tar cp /home" | pv -S 23g | tar xp
<viric>
and you'll get an ETA. :)
<viric>
ssh pc "tar cp /home" | pv -a -S 23g | tar xp
<viric>
the averaging may work better for ETA.
<viric>
store the 'tar' stderr, and you'll have a list of the errors.
<viric>
ssh pc "tar cp /home" 2> tarc-errors.txt | pv -a -S 23g | tar xp
valhalla has quit [Ping timeout: 252 seconds]
lekernel has joined #qi-hardware
jekhor has quit [Ping timeout: 252 seconds]
<DocScrutinizer51>
I used sftp from console now, logging in to source PC as root --- rocks!
jekhor has joined #qi-hardware
<DocScrutinizer51>
from scroll spreed in xterm I estimate I'm up from ~20fileops/s to >500 now
<DocScrutinizer51>
well, this might have been the part where dest files already been existing
<DocScrutinizer51>
suddenly it dropped significantly
kuribas has joined #qi-hardware
<DocScrutinizer51>
still, I'm confident it won't take longer than 2 hours now
<DocScrutinizer51>
fsck that d-link dir615, which obviously has problems with occasionally dropping ARP table or whatever
<DocScrutinizer51>
or firewall/NAT hangups
phirsch has joined #qi-hardware
DocScrutinizer has joined #qi-hardware
kilae_ has joined #qi-hardware
kilae has quit [Ping timeout: 260 seconds]
<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
<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
<DocScrutinizer51>
or maybe not
<DocScrutinizer51>
already at "xfer#25322"
<DocScrutinizer51>
44k done 61k left
Maroni has joined #qi-hardware
<DocScrutinizer51>
left 1900 of 171000
<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
<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
<DocScrutinizer51>
"it"=the lockup
Ayla has quit [Quit: Lost terminal]
Ayla has joined #qi-hardware
compcube has quit [Quit: Leaving]
jekhor has quit [Ping timeout: 248 seconds]
hypermodern_ has joined #qi-hardware
hypermodern_ has left #qi-hardware [#qi-hardware]
kilae_ has quit [Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725]]
<DocScrutinizer51>
sigh
<DocScrutinizer51>
sent 8096479 bytes received 19742271984 bytes 2132984.34 bytes/sec
<DocScrutinizer51>
total size is 28602138243 speedup is 1.45
<DocScrutinizer51>
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1530) [generator=3.0.9]
<wpwrak>
make a tar and scp it ? or would that be too easy ? :)
<wpwrak>
extra points for rsyncing the tar, since this will let you restart
<DocScrutinizer51>
make a tar of 28GB, on a disk that has 300MB free?
<DocScrutinizer51>
suuure
<wpwrak>
delete all the porn first :)
<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
<wpwrak>
that's called a "backup" :)
<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?
<wpwrak>
my bet would be on the subdirectory
<wpwrak>
but you can just move it out. then do a du -sh to compare size
<DocScrutinizer51>
indeed
<wpwrak>
or diff -r if you're bold and they should be the same :)
<DocScrutinizer51>
already thought abizt du -sh, but thanks for the moving suggestion
<DocScrutinizer51>
about*
<DocScrutinizer51>
jr@HaleBopp:~/halley/jr> du -sh /home/jr/halley2/home/jr/; du -sh /home/jr/halley
<DocScrutinizer51>
28G /home/jr/halley2/home/jr/
<DocScrutinizer51>
13G /home/jr/halley
<DocScrutinizer51>
wpwrak: thanks
<DocScrutinizer51>
it seems like the destination argument on that rsync cmd took no effect at all
<DocScrutinizer51>
anyway 28G is what I expected
<wpwrak>
you could du a find with md5sum on source and origin to be 100% sure
<wpwrak>
s/du /do
<qi-bot>
wpwrak meant: "you could do a find with md5sum on source and origin to be 100% sure"
qwebirc27345 has joined #qi-hardware
<wpwrak>
cd /home/jr/halley; find . -type f -exec md5sum '{}' \; >~/output
<wpwrak>
that will allow you to see if a) all the files made it and b) if they were copied correctly
<rjeffries>
s /hos/his/
<DocScrutinizer51>
this will take longer than doing another rsync
<wpwrak>
no. worst case, it takes just as long :)
<DocScrutinizer51>
friggin idiot I am, giving -R parameter without thinking
<wpwrak>
better than --remove-source-files :)
<wpwrak>
rjeffries: seems reasonably up to date. the etchant tank is a bit overkill, though, unless you plan to do monster boards
<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.
<wpwrak>
he seems a bit confused about what 3D printers do, too
<DocScrutinizer51>
HAH, now the benefits of rsync hit
<wpwrak>
replacing the muriatic acid (HCl) with household chemicals
<DocScrutinizer51>
OUCH
<wpwrak>
i just hope those people never get their hands on higher grade peroxide. the graveyard of overly adventurous pioneers is already quite full :)
<DocScrutinizer51>
he could rub some marshmallows on it and let ants eat away the copper
<DocScrutinizer51>
~curse gnome and all g*
<infobot>
May you be reincarnated as a Windows XP administrator, gnome and all g* !
<wpwrak>
that could work. probably a bit slow, though
<wpwrak>
faster than just waiting for proton decay, though :)
<DocScrutinizer51>
wpwrak: would you be interested in getting involved into a bit of kernel development discussion?
<wpwrak>
the kernel is vast. what area of it ?
Maroni has quit [Quit: 'quit_message']
<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
<DocScrutinizer51>
actually there are (at least) two silicon errata, and common urban legend is the fixes for those two are mutually exclusive
<wpwrak>
nice ;-)
<wpwrak>
sounds like a topic for the linux-arm list ?
<DocScrutinizer51>
freemanG now claims he made it work, but none of the "experts" is willing to listen
kristoffer has quit [Quit: Leaving]
<DocScrutinizer51>
which is kinda expected, since that OMAP3430 is rather old silicon anyway
<wpwrak>
did he try that list ? i'm no longer on it, so it can't check quickly
<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
<DocScrutinizer51>
list not yet afaik
<wpwrak>
thumb is for running closed binaries ?
<DocScrutinizer51>
well, thumb is a smaller (16bit) alternative opcode set
<DocScrutinizer51>
or what's been the question?
<DocScrutinizer51>
his interest is in reducing RAM footprint of certain libraries like Qt etc
<DocScrutinizer51>
since N900 is in a permanent swap hell
<wpwrak>
ah, i see
<DocScrutinizer51>
thumb instruction set is supposed to be ~30% smaller than ARM, but possibly slower in execution
<wpwrak>
i think (conceptually) what thumb is. just never saw anyone actually use it
<DocScrutinizer51>
you usually don't even realize I guess
<wpwrak>
you mean s/instruction set/code size/ ?
<DocScrutinizer51>
err yep
<DocScrutinizer51>
e.g. STE modem is all thumb afaik
<wpwrak>
evil blobs :)
<DocScrutinizer51>
sure
<DocScrutinizer51>
do you think you could give some guidance what to post to linux-arm ML
<DocScrutinizer51>
*my* problem with FreemanG is that our ideas of patch validation differ vastly
<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
<wpwrak>
patch validation ?
<DocScrutinizer51>
somehow I think such a patch for a silicon erratum has to be validated somehow
<DocScrutinizer51>
to be effective
<DocScrutinizer51>
and actually target the problem comprehensively
<wpwrak>
well it needs testing, like anything else. if the erratum is version-dependent, it may need a switch, too
<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
<DocScrutinizer51>
and my approach is based on building a testbed that 100% reproducably and traceably invokes the problem
<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"
<DocScrutinizer51>
maybe slightly different rationale and wording, but the general idea AIUI is like that
<DocScrutinizer51>
I'm affraid with this approach of his, he won't see benevolent reviews on linux-arm ML
<wpwrak>
he does seem to have a certain, erm, assertive style, yes
<DocScrutinizer51>
that's where your comments are welcome
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
<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 ;-)
<wpwrak>
well, some of them have. others are gentle :)
<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)
<DocScrutinizer51>
obviously there is a performance penalty in flushing branch prediction frequently
<wpwrak>
if it's just per context switch, that should be negligible
<DocScrutinizer51>
usually yes
<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)
<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
<wpwrak>
maybe whitequark could write a thumb decompiler for you ;-) then you could recompile the whole mess with something that's actually been tested :)
<wpwrak>
so zero-initialize and flush, to kill both birds ?
<DocScrutinizer51>
all disclaimer: IIRC & AIUI
<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
<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
<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
<DocScrutinizer51>
FMG now claims he found a "BIOS call" to write to that register from normal linux context
<wpwrak>
OMG :)
<wpwrak>
how can the BIOS write to an "irreversibly locked" register ?
<DocScrutinizer51>
it's basically like a usual age old sw irq
<DocScrutinizer51>
"BIOS" = ROM bootloader code here
<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
<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
<DocScrutinizer51>
it's just the RING0, RING-N concept
<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
<wpwrak>
and still flush branch prediction on each context switch
<DocScrutinizer51>
yep, probably that's what he does, or plans to do, or whatever
<DocScrutinizer51>
I not *completely* wrapped my head around all that yet