=== chuck_ is now known as zul [02:50] hi, somebody found the conflicting option that made nfs work again... [02:50] really good,but took a bit long [02:51] i have got this error now: [02:51] alg: cipher: Test 1 failed on encryption for aes-asm [02:51] anybody else has that in dmesg? [06:55] need some help in ubuntu regarding how it does switching workspaces internally === asac_ is now known as asac === asac_ is now known as asac [17:41] is there a .deb for the new firewire stack talked about here: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration [17:52] CarlFK: To my knowledge, the generic ubuntu kernel only builds the old firewire stack. [17:53] rexbron: I was told I should try the new one. trying to figure out what the easiest way to do that is [17:53] CarlFK: myself and the ubuntustudio-dev team are looking at what it would take to transition to the new stack, but we have come across many issues [17:54] CarlFK: have you built your own kernel before? [17:54] yes [17:55] https://wiki.ubuntu.com/CarlKarsten top 7 lines 'My kernel howto' [17:55] Then that might be the best way or if you want to help, I was looking at rolling a firewire kernel for testing purposes but havn't found the time. [17:56] CarlFK: I would branch the kernel and modify the config as nessicary, then push to a PPA [17:56] ok - was hoping someone else had already started [17:56] that's a good idea - I have a bunch of boxes I want to test on [17:57] CarlFK: not to my knowledge, but we can always use help. if abogaini ever pops in here or #ubuntustudio-devel, he is our kernel guy and responcible for -rt. If anything I would expect the new firewire stack to be enabled there first [17:58] have you encountered the "ieee1394: Node suspended" problem ? [17:59] CarlFK: I worked out (most) of the dependancies that would need to be addresssd to enable the new firewire stack ubuntu wide here: https://blueprints.edge.launchpad.net/ubuntu/+spec/better-user-firewire-experience [17:59] CarlFK: no I have not [18:00] CarlFK: what apps do you want to use with the new stack? [18:00] dvgrab [18:00] streaming dv camcorder [18:00] for about 6 hours at a time [18:01] CarlFK: dvgrab depends hevily on libraw1394, which needs to be version 2.0 for compat with firewire-core [18:01] 2.0 is not in ubuntu or debian atm [18:01] and as we found out with ffado, changes the api semantics in rather oblique ways [18:02] CarlFK: so your more than welcome to try, but the solution to your problem is more work than just rolling a new kernel [18:02] grumble :) [18:04] rexbron: I am guessing you are familiar with the current module code? [18:05] or something... Ill just continue.. :) [18:06] CarlFK: I don't maintain any of this and couldn't write kernel code if I wanted to, I'm just the fw guy for ubuntustudio [18:06] what I am seeing is: run dvgrab. after some random abmount of time, sometimes 5 min, sometimes 13 hours, the output file (dvgrab-nnnn.dv) stops growing [18:06] rats. [18:06] CarlFK: that said, I might be able to help [18:07] I have to either turn off/on the cam, un/plug the cable, or un/load the modules [18:07] the module thing kinda provs that the hardware is in a usable state [18:08] CarlFK: does it need to be in one contigous file? Can you just run a script that restarts dvgrab every x minutes? [18:08] yes and no. [18:08] that is going to cause a hickup [18:09] and to keep the 'down time' to under a minute, I would need to restart every min. that's 'bad' [18:09] getting dvgrab to exit on this condition might smooth that over [18:10] but... I think a better solution (that requires a kernel hack...) [18:11] when the module detects whatever causes it to report "node suspended" is to first do its reset thing (whatever happens when I un/load it) [18:11] and see if the device is still 'gone' [18:12] if it is, then the cam really was shut off. if it is back, ignore that signal? (or whatever its called) and just keep going like nothing happened [18:13] when i plug the same cameras into a mac running osx, I see 'stuff' in the logs that looks like the same event, but the stream is not stopped. [18:13] hmmm [18:14] networking protocols have room for errors. my guess is this is like that, but the linux code is not dealing with it as well as it should [18:16] so if you know someone who could make that hack, I would be happy to give it a good workout [18:16] http://spreadsheets.google.com/ccc?key=pIfz0wOzPtW1E6KpNZ_9oUQ&hl=en my attempt to find a pattern [18:17] brb [18:47] CarlFK: the only thing that jumps out at me is the Ricoh FW controler. They are very poorly designed and very buggy at the hw level