silidan1apw: hi, did you get the link to the wireshark file i posted yesterday?06:34
silidan1apw: hi, did you get the link to the wireshark file i posted yesterday?10:06
apwsilidan1, i saw the link go by yes10:15
silidan2apw: hi, did you get the link to the wireshark file i posted yesterday?10:46
apwsilidan2, yes i saw the link go by10:46
silidan2apw: did you have the chance to look at the URBs?10:47
apwsilidan2, no10:47
silidan2apw: ok, let me know when you got the chance to look at em and if it gave you new insights..10:48
silidan2apw: should i let the camera manufacturer know about this channel?10:48
apwsilidan2, it is a public channel10:49
apwsilidan2, if they have insite beyond "we think it is the kernel" then by all means10:50
apwpeople blame the kernel all the time as an opaque box so it must be to blame, ignoring the fact it is just a program and the source is available10:52
apwwhich is more than the source for their app is10:52
silidan2apw: ok, i wrote them an email about this channel.10:53
silidan2apw: yea, i got the impression so far that their communication was very "word effective"10:54
silidan2apw: but since my programming skills seem to be rather basic, and i havent done some serious Linux development yet, i cant really say im in a position to argue...10:56
silidan2apw: so far i at least want to thank your for putting so much effort from you into this10:57
apwsilidan2, you said from this you could see the data size, where are you seeing that10:59
apwsilidan2, i only see small control messages, so either i hav eth wrong trace, or i am using wireshark wrong11:01
apwsilidan2, oh no it changes after a heck of a lot of control messages, odd11:01
silidan2apw: when you scroll down to the packages with info "URB_BULK in", the length shows "61504", when you expand the detailed view of one of these URBs, you scroll down to "Data Length", it shows "61440"11:02
apwand how long are they on windows ?11:02
silidan2apw: on windows they are about 300kB11:03
silidan2apw: the Data Length is exactly 300kB, the URB itself a bit larger11:03
apwsilidan2, do you have that trace as well for me11:04
silidan2apw: yea, but it currently resides on another machine... ill get it11:04
silidan2apw: oh i found a selection of the interesting part during image transfer.. ill send that first11:05
apwsilidan2, sounds fine11:05
apwi only want to look at a in out BULK pair anyhow11:06
silidan2apw: here it is: http://wikisend.com/download/522674/usbcap_winxp_asi120mc_selection.pcapng11:06
silidan2apw: there arent in out pairs in windows... thats another difference...11:07
apwsilidan2, i need to see the first one then11:08
silidan2apw: ok ill make a new complete capture then with the enumeration on this machine here... ill be off some minutes11:09
apwsilidan2, as you say windows version is asking for some kind of continuous mode, and they are not in linux11:09
silidanapw: ok im currently uploading it, it takes some time, its about 60 megabyte...11:25
silidanapw: if you wrote something after i send my last message pls repeat11:25
apw> silidan2, as you say windows version is asking for some kind of continuous mode, and they are not in linux11:26
silidanapw: the question then is if they do not do this because libusb doesnt allow it, or ?11:28
apwthat sounds like a question for them, but lets see the first request11:28
silidanapw: damn slow line here... 12 minutes to go...11:28
apwand see what that looks like11:28
silidanapw: besides building with debug symbols and using gdb, is there another way to trace all calls beeing made during the runtime of an application, so eg app calls liba, liba calls libb, libb calls libc and so on?11:35
apwsilidan, mostly gdb can give you some idea i fyou have the symbols installed11:36
apwdebug packages installed, that said, really your vendor should sort this out11:37
apwor they should take hte thing back11:37
silidanapw: ok here we go: http://wikisend.com/download/848572/winxp_asi120_capture.pcap11:39
silidanapw: yea sure i was just asking genrally, maybe i overlooked something, so far i learned only about strace and ltrace.. besides the source dependent gdb approach11:43
apwsilidan, well all we can see in this trace is unspecified control meesages sent and then the device starts sending unsolicited continuous data11:48
apwsilidan, in linux they ask first and keep asking, so this seems most likely a difference in the way they are11:49
apwasking for the data, at the userspace level, at a level we have no visibility for11:49
apwsilidan, and the needing to ask for each block would clearly add huge latency and likely is the cause of your 1/3 performance11:51
silidanapw: yea they told me they wrote the windows driver themselves, and on linux they used libusb...11:51
apwsilidan, in my opinion this is not something the kernle is doing11:52
apwi think this is a differnce in the mode they are slecting at the device, and likely that is a libusb or higher hting11:52
silidanapw: there is maybe somthing else: i recently made a capture of a large filetransfer to a usb harddrive (usb3.0 harddrive over usb2.0 bus) and there i saw the same bulk package length of about 60kB11:53
silidanapw: at least here on linux...11:53
=== psivaa is now known as psivaa-lunch
silidanapw: what i mean is i never saw any URB on linuy that was larger than about 60kB12:01
apwsilidan, right but a disk is different you are doing random IO to it, so you have to ask for things individually to address the sector12:13
silidanapw: sure, maybe im just mixing up USB bulk transfer size limits (i think it was 4MB) with URB size...12:16
silidanapw: is there maybe a limit to the read() write() system calls in linux?12:21
apwsilidan, they arn't using those as far as i can see, i think they are mmaping data into the kernel for direct access12:36
apwsilidan, and IO sizes are defined by the media in the main, and cirtinaly multi megabyte io is possible12:36
apwthey could just let us read their source, you know, so we know what they are doing12:37
silidanapw: ok, so we can for now conclude this with the statement: you doubt that it is a kernel thing, to be sure you need to see the sources of their sdk. 12:39
silidanapw: and again i want to thank you for your time and patience, i will relay this to the manufacturer, maybe they will contact you here12:45
silidanapw: you may also want to keep in mind that this manufacturer is based in china and thus they are at UTC +8:00, so quite some time difference, are you maybe also reachable via a mailing list?13:11
apwthey will find me here i am sure, we overlap quite some hours13:12
silidanapw: ok13:13
=== psivaa-lunch is now known as psivaa
=== alvesadrian is now known as adrian
rtgkees, can you comment on bug #1499089 ? Is X86_LEGACY_VM86 no longer a vulnerability in 4.2/4.3 ?15:43
ubot5bug 1499089 in linux (Ubuntu) "Please enable kconfig X86_LEGACY_VM86 for i386" [Undecided,Confirmed] https://launchpad.net/bugs/149908915:43
=== ddstreet_away is now known as ddstreet
=== eichiro_ is now known as eichiro
=== ming is now known as Guest97207
rtgkamal, Ted Tso requested 2 patches for 3.18 (0f2af21aae1197, 94426f4b964815). You've only applied 0f2af21aae1197 to 3.19. Why not the second ? Both are v4.1-rc2 commits.16:40
kamalrtg, I applied the first patch to 3.19 because its indicated as a CVE fixer (but neither is marked cc: stable, hence the second did not get applied).  Point me at Ted's request?17:06
rtgkamal, on the stable list, subject is 'Please apply these two patches to the 3.18 stable branch'17:07
kamalrtg, yeah, okay I'll pick it up also and cram it into the imminent (tomorrow) 3.19-stable release.17:12
rtgkamal, ack17:12
kamalhenrix, this probably needs to be applied to 3.16 also (like me, you've got the first but not the second -- you need:17:12
kamal94426f4 ext4: fix loss of delalloc extent info in ext4_zero_range()17:13
kamal(probably :-)17:13
keesrtg: my head is still spinning from the threads on that. I think nothing needs X86_LEGACY_VM86 any more though17:19
rtgkees, it does seem like just a performance optimization17:19
henrixkamal: ack, i'll check.  thanks17:39
rtgapw, linux-raspi2 published finally, tools and all19:32

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!