[00:58:00] *** Quits: n1s (~n1s@rockbox/developer/n1s) (Quit: Ex-Chat) [02:04:14] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [02:04:14] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [06:08:49] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Disconnected by services) [06:08:58] *** Joins: [7] (~quassel@rockbox/developer/TheSeven) [08:04:11] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [08:04:11] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [08:26:51] *** Joins: n1s (~n1s@nl118-168-30.student.uu.se) [08:26:51] *** Quits: n1s (~n1s@nl118-168-30.student.uu.se) (Changing host) [08:26:51] *** Joins: n1s (~n1s@rockbox/developer/n1s) [10:11:35] *** Quits: Dgby714 (~dgby714@nala.villavu.com) (*.net *.split) [10:11:35] *** Quits: Elfish (amba@2001:1608:12:1:13:3:3:7) (*.net *.split) [10:11:35] *** Quits: Farthen (~Farthen@cassiopeia.uberspace.de) (*.net *.split) [10:11:35] *** Quits: Rurd2di (~Rurd2di@hotaru.1337.net.nz) (*.net *.split) [10:11:35] *** Quits: x56 (~0x56@sillytitties.com) (*.net *.split) [10:11:35] *** Quits: el3ctrik-away (~el3ctrik@2a00:1c10:5:201:216:3eff:fe98:c8f1) (*.net *.split) [10:11:36] *** Quits: [7] (~quassel@rockbox/developer/TheSeven) (*.net *.split) [10:11:36] *** Quits: n1s (~n1s@rockbox/developer/n1s) (*.net *.split) [10:11:36] *** Quits: gevaerts (~fg@rockbox/developer/gevaerts) (*.net *.split) [10:11:36] *** Quits: Poodlemastah (~Poodlemas@109-124-181-96.customer.t3.se) (*.net *.split) [10:11:36] *** Quits: ChanServ (ChanServ@services.) (*.net *.split) [10:17:28] *** Joins: n1s (~n1s@rockbox/developer/n1s) [10:17:28] *** Joins: [7] (~quassel@rockbox/developer/TheSeven) [10:17:28] *** Joins: gevaerts (~fg@rockbox/developer/gevaerts) [10:17:28] *** Joins: Poodlemastah (~Poodlemas@109-124-181-96.customer.t3.se) [10:17:28] *** Joins: el3ctrik-away (~el3ctrik@2a00:1c10:5:201:216:3eff:fe98:c8f1) [10:17:28] *** Joins: Rurd2di (~Rurd2di@hotaru.1337.net.nz) [10:17:28] *** Joins: Farthen (~Farthen@cassiopeia.uberspace.de) [10:17:28] *** Joins: Elfish (amba@2001:1608:12:1:13:3:3:7) [10:17:28] *** Joins: Dgby714 (~dgby714@nala.villavu.com) [10:17:28] *** Joins: x56 (~0x56@sillytitties.com) [10:17:28] *** Joins: ChanServ (ChanServ@services.) [10:17:28] *** hitchcock.freenode.net sets mode: +o ChanServ [12:21:21] *** Joins: liar (~liar@clnet-p09-185.ikbnet.co.at) [14:04:11] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [14:04:11] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [16:55:47] <[7]> user890104: I ran into a possible problem with our windows driver infrastructure [16:56:22] <[7]> it seems like windows identifies a subdevice of a composite device by its interface number, not by the interface class [16:57:16] <[7]> which means that we need to watch out that the debug interface will always get the same &MI_xx device ID part at the end [17:09:02] [7]: were you able to reproduce the windows crashes on reconnecting? [17:11:09] this probably explains why i need to select Update driver after running umstest, so it can pick up the composite driver (and its children devices) instead of the libusb one [17:12:42] maybe it doesn't realise at all that we changed the descriptors... and tries to send something UMS-related to emcore when reconnecting [17:18:41] <[7]> hm, it seems like we can register the driver as USB\VID_ffff&PID_e000&CLASS_ff&SUBCLASS_00&PROT_00 instead [17:19:28] <[7]> but my driver is still getting these Code 10 errors, so I need to debug that first [17:41:01] <[7]> dvi: {Restarting Devices} 16:11:04.760 [17:41:01] <[7]> dvi: Restart: USB\VID_FFFF&PID_E000\5&C1E6CCE&0&1 [17:41:01] <[7]> dvi: Restart complete. [17:41:01] <[7]> !!! dvi: Device not started: Device has problem: 0x0a: CM_PROB_FAILED_START. [17:41:01] <[7]> dvi: {Restarting Devices exit} 16:11:06.659 [17:41:04] <[7]> very meaningful... [17:48:11] so is the information on the MSDN page about that error code [17:48:21] This error code is set when one of the drivers in the device's driver stack fails IRP_MN_START_DEVICE. If there are many drivers in the stack, it can be difficult to determine the one that failed. [17:48:29] "it can be difficult" ... [18:23:52] [7]: let me know if you need anything tested on windows, i have win7 and win8 at the moment [18:26:11] <[7]> yes, microsoft's suggestion is basically "attach a kernel debugger and step through all that mess" [18:55:55] *** el3ctrik-away is now known as el3ctrik [18:58:29] * [7] starts to hate coinstallers [19:16:26] *** el3ctrik is now known as el3ctrik-away [19:47:28] * user890104 tries to make emCOREFS compatible with emCORE again [19:48:27] <[7]> hm, might be worth doing some performance benchmarks, and possibly writing a little helper app that assists emcorefs from the ipod side [19:48:43] <[7]> I ran into a roadblock with the Win7 VM approach [19:48:58] <[7]> seems like that VM managed to freeze up my GPU driver way too often [19:49:08] * [7] absolutely hates nvidia for that [20:03:08] [7]: i managed to crash windows, just by connecting emcore (no user apps running on the ipod) [20:03:32] <[7]> hm. sounds more and more like a driver problem then [20:03:53] and i can't find anything emcore-related in device manager, with hidden+nonpresent devices shown [20:04:12] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [20:04:13] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Read error: Connection reset by peer) [20:04:37] <[7]> check c:\windows\inf\oem*.inf and c:\windows\system32\driverstore\filerepository for anything that looks like one of your inf files [20:04:50] <[7]> searching for VEN_FFFF should be a good filter [20:05:49] <[7]> delete everything related to those (.inf/.pnf in the inf dir, whole folders in filerepository) [20:06:21] <[7]> look for USB mass storage volumes, partitions or similar stuff that could have been from umstest in the device manager [20:07:04] <[7]> run "sc delete winusb" [20:07:34] <[7]> then reboot both the PC and the ipod, and retry [20:08:50] ok, i'll give that a try [22:31:27] [7]: why did you remove self.dev.set_configuration() from libemcore.py that's called after usb.core.find? windows doesn't seem to be happy without it [22:33:01] usb.core.USBError: [Errno None] b'usb_claim_interface: could not claim interface 0, invalid configuration 0' [22:33:27] set_configuration without arguments sets configuration 1, and makes libusb happy [22:34:00] <[7]> that is very interesting [22:34:13] <[7]> typically the operating system sets configuration 1 when detecting the device [22:34:40] ah, you're calling windows an operating system? :) [22:34:48] <[7]> setting it to zero on exit actually caused problems, and I thought I'd keep it symmetric [22:35:17] <[7]> actively setting a configuration could also screw up cases where libemcore doesn't actually know which configuration is the right one [22:35:27] <[7]> which could now happen, thanks to userspace usb [22:35:50] ah, i see. what should be the proper fix then? [22:36:28] <[7]> the best solution might be only calling set_configuration(1) if get_configuration() returns 0 [22:36:50] let me try that [22:37:36] <[7]> hm, there are more bugs in that area... [22:38:01] <[7]> seems like it picks the interface number for the debug interface of the first configuration that has one, no matter which configuration is actually selected [22:40:01] <[7]> it's probably best to change that to: [22:40:01] <[7]> - determine current configuration value [22:40:01] <[7]> - if config == 0, set it to 1 and call set_configuration(1) [22:40:01] <[7]> - only look for the debug interface within the configuration with that number [22:40:02] <[7]> - refuse to connect if there is none (either the device doesn't expose a debug interface at all, or the user needs to switch to the right configuration) [22:40:27] <[7]> the current ipod-side code implements the debug interface as the last interface in every present configuration, if enabled [22:41:01] <[7]> so for the typical use cases, libemcore can stick with the currently active configuration, well, unless there is none [22:51:11] how do i get the current configuration value in pyusb? [22:52:37] <[7]> no idea, I'd guess there's a get_configuration() function or something like that? [22:57:30] ah, found it in the source code. it's dev.get_active_configuration().index [22:57:38] *** Quits: liar (~liar@clnet-p09-185.ikbnet.co.at) (Ping timeout: 245 seconds) [22:57:50] ok, it seems to work on windows. can you give it a try on linux? [22:58:34] http://pastie.org/pastes/8287055/text [23:02:43] uhm...ubuntu doesn't seem to like it [23:02:46] [ 3907.824263] python[1110]: segfault at 24 ip 0031210e sp bfbf7f00 error 4 in libusb-1.0.so.0.1.0[308000+e000] [23:03:05] *** Joins: liar (~liar@clnet-p09-185.ikbnet.co.at) [23:03:37] <[7]> is that the get or the set? [23:04:03] this is how i get it [23:04:24] and i set it using dev.set_configuration() without an argument [23:04:40] which should set the first one available [23:07:56] the way i get it is causing a segfault on linux [23:18:02] ah, this seems to be a bug of pyusb [23:18:16] https://github.com/walac/pyusb/commit/68036163ba4f9f2eed73bf3189d7c332ebea1f77 [23:23:31] <[7]> admn [23:23:32] <[7]> damn* [23:27:19] updating pyusb to 1.0.0-alpha4 fixes it [23:28:41] so using alpha3+ should be ok (it was fixed between alpha2 and alpha3) [23:29:30] no, alpha2 should also be ok, iiuc [23:31:41] <[7]> hm, this is all a huge mess :P [23:33:19] well, at least it works now [23:34:42] i can commit it if it looks ok to you [23:36:34] <[7]> I'd prefer if there were two changes while we're at it: [23:36:34] <[7]> 1. if possible, work around the segfault problem from within libemcore, it might be possible to call managed_open() ourselves before that call. we'll be opening it at some point later anyway, check if that can be moved to fix the problem. [23:36:34] <[7]> 2. fix the interface selection bug: only look at the actually selected configuration [23:43:44] i don't see a way to get the active configuration index without calling get_active_configuration(), since _active_cfg_index is not accessible [23:44:28] actually, i don't know much of python, so i'm not sure if i'm doing it correctly [23:54:47] <[7]> user890104: I suspect that adding a call to managed_open() (or something else that calls it, such as device.open()) before the call to get_active_configuration will work around the bug