[02:50] <Kano> hi, somebody found the conflicting option that made nfs work again...
[02:50] <Kano> really good,but took a bit long
[02:51] <Kano> i have got this error now:
[02:51] <Kano> alg: cipher: Test 1 failed on encryption for aes-asm
[02:51] <Kano> anybody else has that in dmesg?
[06:55] <karthik_> need some help in ubuntu regarding how it does switching workspaces internally
[17:41] <CarlFK> is there a .deb for the new firewire stack talked about here: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration  
[17:52] <rexbron> CarlFK: To my knowledge, the generic ubuntu kernel only builds the old firewire stack. 
[17:53] <CarlFK> rexbron: I was told I should try the new one.  trying to figure out what the easiest way to do that is
[17:53] <rexbron> 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] <rexbron> CarlFK: have you built your own kernel before?
[17:54] <CarlFK> yes
[17:55] <CarlFK> https://wiki.ubuntu.com/CarlKarsten  top 7 lines 'My kernel howto'
[17:55] <rexbron> 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] <rexbron> CarlFK: I would branch the kernel and modify the config as nessicary, then push to a PPA
[17:56] <CarlFK> ok - was hoping someone else had already started 
[17:56] <CarlFK> that's a good idea - I have a bunch of boxes I want to test on
[17:57] <rexbron> 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] <CarlFK> have you encountered the  "ieee1394: Node suspended"  problem ?
[17:59] <rexbron> 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] <rexbron> CarlFK: no I have not
[18:00] <rexbron> CarlFK: what apps do you want to use with the new stack?
[18:00] <CarlFK> dvgrab
[18:00] <CarlFK> streaming dv camcorder 
[18:00] <CarlFK> for about 6 hours at a time 
[18:01] <rexbron> CarlFK: dvgrab depends hevily on libraw1394, which needs to be version 2.0 for compat with firewire-core
[18:01] <rexbron> 2.0 is not in ubuntu or debian atm
[18:01] <rexbron> and as we found out with ffado, changes the api semantics in rather oblique ways
[18:02] <rexbron> 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] <CarlFK> grumble :)
[18:04] <CarlFK> rexbron: I am guessing you are familiar with the current module code?
[18:05] <CarlFK> or something... Ill just continue.. :)
[18:06] <rexbron> 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] <CarlFK> 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] <CarlFK> rats.
[18:06] <rexbron> CarlFK: that said, I might be able to help
[18:07] <CarlFK> I have to either turn off/on the cam, un/plug the cable, or un/load the modules 
[18:07] <CarlFK> the module thing kinda provs that the hardware is in a usable state 
[18:08] <rexbron> CarlFK: does it need to be in one contigous file? Can you just run a script that restarts dvgrab every x minutes?
[18:08] <CarlFK> yes and no.  
[18:08] <CarlFK> that is going to cause a hickup
[18:09] <CarlFK> and to keep the 'down time' to under a minute, I would need to restart every min.  that's 'bad' 
[18:09] <CarlFK> getting dvgrab to exit on this condition might smooth that over 
[18:10] <CarlFK> but... I think a better solution (that requires a kernel hack...)
[18:11] <CarlFK> 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] <CarlFK> and see if the device is still 'gone'
[18:12] <CarlFK> 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] <CarlFK> 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] <rexbron> hmmm
[18:14] <CarlFK> 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] <CarlFK> so if you know someone who could make that hack, I would be happy to give it a good workout
[18:16] <CarlFK> http://spreadsheets.google.com/ccc?key=pIfz0wOzPtW1E6KpNZ_9oUQ&hl=en  my attempt to find a pattern 
[18:17] <CarlFK> brb
[18:47] <rexbron> 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