| === chuck_ is now known as zul | ||
| Kano | hi, somebody found the conflicting option that made nfs work again... | 02:50 |
|---|---|---|
| Kano | really good,but took a bit long | 02:50 |
| 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? | 02:51 |
| karthik_ | need some help in ubuntu regarding how it does switching workspaces internally | 06:55 |
| === asac_ is now known as asac | ||
| === asac_ is now known as asac | ||
| CarlFK | is there a .deb for the new firewire stack talked about here: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration | 17:41 |
| rexbron | CarlFK: To my knowledge, the generic ubuntu kernel only builds the old firewire stack. | 17:52 |
| 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:53 |
| rexbron | CarlFK: have you built your own kernel before? | 17:54 |
| CarlFK | yes | 17:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| CarlFK | have you encountered the "ieee1394: Node suspended" problem ? | 17:58 |
| 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 | 17:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| CarlFK | rexbron: I am guessing you are familiar with the current module code? | 18:04 |
| CarlFK | or something... Ill just continue.. :) | 18:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| CarlFK | but... I think a better solution (that requires a kernel hack...) | 18:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:16 |
| CarlFK | brb | 18:17 |
| 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 | 18:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!