| silidan1 | apw: hi, did you get the link to the wireshark file i posted yesterday? | 06:34 |
|---|---|---|
| silidan1 | apw: hi, did you get the link to the wireshark file i posted yesterday? | 10:06 |
| apw | silidan1, i saw the link go by yes | 10:15 |
| silidan2 | apw: hi, did you get the link to the wireshark file i posted yesterday? | 10:46 |
| apw | silidan2, yes i saw the link go by | 10:46 |
| silidan2 | apw: did you have the chance to look at the URBs? | 10:47 |
| apw | silidan2, no | 10:47 |
| silidan2 | apw: ok, let me know when you got the chance to look at em and if it gave you new insights.. | 10:48 |
| silidan2 | apw: should i let the camera manufacturer know about this channel? | 10:48 |
| apw | silidan2, it is a public channel | 10:49 |
| apw | silidan2, if they have insite beyond "we think it is the kernel" then by all means | 10:50 |
| apw | people 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 available | 10:52 |
| apw | which is more than the source for their app is | 10:52 |
| silidan2 | apw: ok, i wrote them an email about this channel. | 10:53 |
| silidan2 | apw: yea, i got the impression so far that their communication was very "word effective" | 10:54 |
| silidan2 | apw: 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 |
| silidan2 | apw: so far i at least want to thank your for putting so much effort from you into this | 10:57 |
| apw | silidan2, you said from this you could see the data size, where are you seeing that | 10:59 |
| apw | silidan2, i only see small control messages, so either i hav eth wrong trace, or i am using wireshark wrong | 11:01 |
| apw | silidan2, oh no it changes after a heck of a lot of control messages, odd | 11:01 |
| silidan2 | apw: 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 |
| apw | and how long are they on windows ? | 11:02 |
| silidan2 | apw: on windows they are about 300kB | 11:03 |
| silidan2 | apw: the Data Length is exactly 300kB, the URB itself a bit larger | 11:03 |
| apw | silidan2, do you have that trace as well for me | 11:04 |
| silidan2 | apw: yea, but it currently resides on another machine... ill get it | 11:04 |
| silidan2 | apw: oh i found a selection of the interesting part during image transfer.. ill send that first | 11:05 |
| apw | silidan2, sounds fine | 11:05 |
| apw | i only want to look at a in out BULK pair anyhow | 11:06 |
| silidan2 | apw: here it is: http://wikisend.com/download/522674/usbcap_winxp_asi120mc_selection.pcapng | 11:06 |
| silidan2 | apw: there arent in out pairs in windows... thats another difference... | 11:07 |
| apw | silidan2, i need to see the first one then | 11:08 |
| silidan2 | apw: ok ill make a new complete capture then with the enumeration on this machine here... ill be off some minutes | 11:09 |
| apw | silidan2, as you say windows version is asking for some kind of continuous mode, and they are not in linux | 11:09 |
| silidan | apw: ok im currently uploading it, it takes some time, its about 60 megabyte... | 11:25 |
| silidan | apw: if you wrote something after i send my last message pls repeat | 11:25 |
| apw | > silidan2, as you say windows version is asking for some kind of continuous mode, and they are not in linux | 11:26 |
| silidan | apw: the question then is if they do not do this because libusb doesnt allow it, or ? | 11:28 |
| apw | that sounds like a question for them, but lets see the first request | 11:28 |
| silidan | apw: damn slow line here... 12 minutes to go... | 11:28 |
| apw | and see what that looks like | 11:28 |
| silidan | apw: 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 |
| apw | silidan, mostly gdb can give you some idea i fyou have the symbols installed | 11:36 |
| apw | debug packages installed, that said, really your vendor should sort this out | 11:37 |
| apw | or they should take hte thing back | 11:37 |
| silidan | apw: ok here we go: http://wikisend.com/download/848572/winxp_asi120_capture.pcap | 11:39 |
| silidan | apw: 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 approach | 11:43 |
| apw | silidan, well all we can see in this trace is unspecified control meesages sent and then the device starts sending unsolicited continuous data | 11:48 |
| apw | silidan, in linux they ask first and keep asking, so this seems most likely a difference in the way they are | 11:49 |
| apw | asking for the data, at the userspace level, at a level we have no visibility for | 11:49 |
| apw | silidan, and the needing to ask for each block would clearly add huge latency and likely is the cause of your 1/3 performance | 11:51 |
| silidan | apw: yea they told me they wrote the windows driver themselves, and on linux they used libusb... | 11:51 |
| apw | silidan, in my opinion this is not something the kernle is doing | 11:52 |
| apw | i think this is a differnce in the mode they are slecting at the device, and likely that is a libusb or higher hting | 11:52 |
| silidan | apw: 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 60kB | 11:53 |
| silidan | apw: at least here on linux... | 11:53 |
| === psivaa is now known as psivaa-lunch | ||
| silidan | apw: what i mean is i never saw any URB on linuy that was larger than about 60kB | 12:01 |
| apw | silidan, right but a disk is different you are doing random IO to it, so you have to ask for things individually to address the sector | 12:13 |
| silidan | apw: sure, maybe im just mixing up USB bulk transfer size limits (i think it was 4MB) with URB size... | 12:16 |
| silidan | apw: is there maybe a limit to the read() write() system calls in linux? | 12:21 |
| apw | silidan, they arn't using those as far as i can see, i think they are mmaping data into the kernel for direct access | 12:36 |
| apw | silidan, and IO sizes are defined by the media in the main, and cirtinaly multi megabyte io is possible | 12:36 |
| apw | they could just let us read their source, you know, so we know what they are doing | 12:37 |
| silidan | apw: 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 |
| silidan | apw: and again i want to thank you for your time and patience, i will relay this to the manufacturer, maybe they will contact you here | 12:45 |
| silidan | apw: 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 |
| apw | they will find me here i am sure, we overlap quite some hours | 13:12 |
| silidan | apw: ok | 13:13 |
| === psivaa-lunch is now known as psivaa | ||
| === alvesadrian is now known as adrian | ||
| rtg | kees, can you comment on bug #1499089 ? Is X86_LEGACY_VM86 no longer a vulnerability in 4.2/4.3 ? | 15:43 |
| ubot5 | bug 1499089 in linux (Ubuntu) "Please enable kconfig X86_LEGACY_VM86 for i386" [Undecided,Confirmed] https://launchpad.net/bugs/1499089 | 15:43 |
| === ddstreet_away is now known as ddstreet | ||
| === eichiro_ is now known as eichiro | ||
| === ming is now known as Guest97207 | ||
| rtg | kamal, 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 |
| kamal | rtg, 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 |
| rtg | kamal, on the stable list, subject is 'Please apply these two patches to the 3.18 stable branch' | 17:07 |
| kamal | rtg, yeah, okay I'll pick it up also and cram it into the imminent (tomorrow) 3.19-stable release. | 17:12 |
| rtg | kamal, ack | 17:12 |
| kamal | henrix, 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 |
| kamal | 94426f4 ext4: fix loss of delalloc extent info in ext4_zero_range() | 17:13 |
| kamal | (probably :-) | 17:13 |
| kees | rtg: my head is still spinning from the threads on that. I think nothing needs X86_LEGACY_VM86 any more though | 17:19 |
| rtg | kees, it does seem like just a performance optimization | 17:19 |
| henrix | kamal: ack, i'll check. thanks | 17:39 |
| rtg | apw, linux-raspi2 published finally, tools and all | 19:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!