**** BEGIN LOGGING AT Mon Aug 05 02:59:58 2013
Aug 05 11:11:36 <vvu> _av500_: av500 ping
Aug 05 11:15:09 <av500> jo
Aug 05 11:15:24 <vvu> hello! have some time to dig in the gadgetfs code?
Aug 05 11:16:49 <av500> shoot
Aug 05 11:17:35 <vvu> the demo code in usb.c plays awkward. in /dev/gadget after i mount i have musb-hdrc
Aug 05 11:18:02 <vvu> but when i run the binary i get the "?? don't recognize /dev/gadget bulk device" error
Aug 05 11:18:47 <av500> hmm
Aug 05 11:19:05 <vvu> autoconfig returns -ENODEV
Aug 05 11:19:14 <vvu> let me power up again the BBB and try again
Aug 05 11:20:01 <av500> so gadget serial works
Aug 05 11:20:09 <av500> but not gadgetfs
Aug 05 11:20:16 <av500> but you can load the module?
Aug 05 11:20:21 <vvu> yep i can load it
Aug 05 11:20:31 <vvu> a minute to give you some pastebins from dmesg
Aug 05 11:23:42 <vvu> http://pastebin.com/dn1crc0p
Aug 05 11:23:45 <vvu> av500: ^^
Aug 05 11:25:18 <av500> oh
Aug 05 11:25:33 <vvu> and in dmesg i get
Aug 05 11:25:44 <vvu> http://pastebin.com/KW00Gpk3
Aug 05 11:31:03 <vvu> kernel bug ?
Aug 05 11:32:15 <av500> seems so
Aug 05 11:32:17 <av500> musb bug
Aug 05 11:32:27 <av500> what does it dmesg for gadgetserial?
Aug 05 11:33:41 <vvu> http://pastebin.com/NaZzxaFC
Aug 05 11:34:41 <av500> hmm
Aug 05 11:34:52 <av500> why is one null and the other "serial"
Aug 05 11:34:59 <av500> g_serial
Aug 05 11:35:42 <vvu> in this land of "usb" i can`t evaluate more :)
Aug 05 11:46:14 <vvu> any chances this bug is repairable by me? honestly i have no idea what is wrong
Aug 05 11:46:22 <_av500_> well
Aug 05 11:46:28 <_av500_> you could check the error msg
Aug 05 11:46:32 <_av500_> and follow back from there
Aug 05 11:46:39 <_av500_> find out why its null in the forst log line
Aug 05 11:47:57 <vvu> but why it tries to register udc ?
Aug 05 11:48:15 <av500> UDC it says for serial too
Aug 05 11:48:30 <av500> [null] is the issue I think
Aug 05 11:50:50 <vvu> the udc null comes from udc_bind_to_driver function
Aug 05 11:50:54 <vvu> in udc-core.c
Aug 05 11:51:51 <vvu> ret = driver->bind(udc->gadget, driver);
Aug 05 11:51:51 <vvu> 	if (ret)
Aug 05 11:51:51 <vvu> 		goto err1;
Aug 05 11:52:02 <vvu> and err1 is the dev_err which tells me stuff is null
Aug 05 11:52:19 <vvu> udc->driver->function is null
Aug 05 11:57:34 <av500> what kernel are you on?
Aug 05 11:57:41 <av500> I dont have udc_bind_to_driver
Aug 05 11:57:51 <vvu> Linux ubuntu-armhf 3.8.13-bone20 #1 SMP Wed May 29 06:14:59 UTC 2013 armv7l armv7l armv7l GNU/Linux
Aug 05 11:58:12 <av500> 3.8.2 sources here
Aug 05 11:58:23 <vvu> i was looking at src from here
Aug 05 11:58:24 <vvu> http://stuff.mit.edu/afs/sipb.mit.edu/contrib/linux/drivers/usb/gadget/udc-core.c
Aug 05 11:58:37 <vvu> just searched google with the error and got this source
Aug 05 12:03:54 <av500> hmm
Aug 05 12:03:58 <av500> in inode.c
Aug 05 12:04:08 <av500> function is set up with the driver_desc string
Aug 05 12:04:11 <av500> why is it null?
Aug 05 12:05:22 <vvu> av500: i`m going to lunch a bit, brb 1h max
Aug 05 12:09:22 <av500> static struct usb_gadget_driver probe_driver = {
Aug 05 12:09:23 <av500> 	.max_speed	= USB_SPEED_HIGH,
Aug 05 12:09:26 <av500> this one has no function
Aug 05 12:09:31 <av500> and name "nop"
Aug 05 12:09:36 <av500> its the "probe" driver
Aug 05 12:11:02 <av500> static int gadgetfs_probe(struct usb_gadget *gadget,
Aug 05 12:11:04 <av500> 		struct usb_gadget_driver *driver)
Aug 05 12:11:05 <av500> {
Aug 05 12:11:07 <av500> 	CHIP = gadget->name;
Aug 05 12:11:08 <av500> 	return -EISNAM;
Aug 05 12:11:10 <av500> }
Aug 05 12:11:13 <av500> .bind		= gadgetfs_probe,
Aug 05 12:11:20 <av500> well, that does return an error
Aug 05 12:11:58 <av500> arch/sparc/include/uapi/asm/errno.h:95:#define  EISNAM          120     /* Is a named type file */
Aug 05 12:12:01 <av500> 120 even
Aug 05 12:12:23 <av500> include/uapi/asm-generic/errno.h:93:#define     EISNAM          120     /* Is a named type file */
Aug 05 12:23:16 <av500> vvu: is that the full dmesg?
Aug 05 12:23:27 <av500> can you add some prink and recompile?
Aug 05 12:23:41 <av500> I compared the code to what we used in the past
Aug 05 12:23:47 <av500> seems mostly still the same
Aug 05 12:26:01 <av500> hmm
Aug 05 12:26:08 <av500> does it mount actually?
Aug 05 12:26:12 <av500> because I see no mount error
Aug 05 12:26:27 <av500> ah
Aug 05 12:26:29 <av500> I misread
Aug 05 12:26:32 <av500> it does mount
Aug 05 12:26:40 <av500> this dmesg error is OK then
Aug 05 12:31:00 <av500>  else if (stat (DEVNAME = "musb_hdrc", &statb) == 0) {
Aug 05 12:31:04 <av500> I see no otah
Aug 05 12:31:17 <av500> no path
Aug 05 12:31:22 <av500> no /dev/gadget/
Aug 05 12:31:24 <av500> ???
Aug 05 12:59:48 <tcort> anujdeshpande: I posted a comment on your blog post (it's awaiting moderation).
Aug 05 13:02:10 <tcort> I think the clock() function would work for millis/micros.
Aug 05 13:24:17 <anujdeshpande> tcort: sorry was afk. thanks btw ! from what i read online right now it looks great ! will try it out in a bit and let know
Aug 05 13:38:19 <vvu> av500: back now
Aug 05 13:38:37 <av500> ok
Aug 05 13:38:39 <av500> check usb.c
Aug 05 13:38:47 <av500> I think you fall into the final -ENODEV
Aug 05 13:38:58 <av500> because the stat fails on musb_hdrc
Aug 05 13:39:04 <vvu> yep
Aug 05 13:39:08 <av500> so, fix it
Aug 05 13:39:19 <vvu> hard code it ?
Aug 05 13:39:31 <vvu> without if/else ?
Aug 05 13:39:33 <av500> no
Aug 05 13:39:38 <av500> as I said
Aug 05 13:39:43 <av500>  /dev/gadget/ is missing
Aug 05 13:39:58 <av500> no idea how that was supposed to work
Aug 05 13:40:04 <av500> unless calling it from that path
Aug 05 13:40:18 <vvu> okok
Aug 05 13:45:34 <vvu> av500: same thingue
Aug 05 13:45:36 <vvu> thingie
Aug 05 13:58:27 <vvu> av500: got it to work, prints the serial code
Aug 05 13:58:35 <av500> :)
Aug 05 13:59:32 <vvu> now lets hook up the old timer galaxy nexus
Aug 05 14:01:20 <vvu> http://pastebin.com/Rigpsjqg
Aug 05 14:01:24 <vvu> serials match
Aug 05 14:01:26 <vvu> :D
Aug 05 14:04:39 <av500> great
Aug 05 14:05:00 <vvu> but BBB hangs when i run the code
Aug 05 14:05:19 <av500> minor issue :)
Aug 05 14:05:30 <vvu> totally
Aug 05 14:06:20 <vvu> i`m with ssh into my BBB, let me see via serial what it happens
Aug 05 14:11:51 <vvu> av500: when i connect my android i get http://pastebin.com/H2h3Ze19
Aug 05 14:20:57 <av500> ubuntu?
Aug 05 14:21:12 <vvu> i`m on ubuntu
Aug 05 14:21:25 <vvu> from http://www.armhf.com/
Aug 05 14:21:57 <av500> oh
Aug 05 14:22:07 <vvu> bad choice?
Aug 05 14:22:14 <av500> why not stock angstrom?
Aug 05 14:23:39 <vvu> habbit to have ubuntu everywhere
Aug 05 14:25:20 <vvu> should i try with angstrom?
Aug 05 14:25:43 <av500> I prefer we test with the angstrom kernel
Aug 05 14:25:52 <av500> not some random ubuntu
Aug 05 14:25:57 <vvu> ok
Aug 05 14:26:35 <vvu> will flash in like 20 mins the eMMC
Aug 05 14:29:44 <vvu> anyway in the FIT i will put the kernel from the official git, compiled by me. will have built in gadgetfs not as module if it works
Aug 05 14:37:32 * vvu waits and waits and waits and waits to flash the eMMC
Aug 05 14:52:29 <vvu> av500: with 3.8.11 i get mount: unknown filesystem type 'gadgetfs'
Aug 05 14:52:32 <vvu> angstrom distro
Aug 05 14:52:39 <av500> arf
Aug 05 14:52:41 <av500> check config
Aug 05 14:53:06 <vvu> i`m running the board jason sent me
Aug 05 14:53:09 <vvu> the untouched one
Aug 05 14:53:11 <vvu> from eMMC
Aug 05 14:53:21 <vvu> flashing took too long and got this one up
Aug 05 14:53:33 <av500> but gadgetfs loaded?
Aug 05 14:54:02 <vvu> yep
Aug 05 14:55:08 <vvu> [   23.450121] gadgetfs: USB Gadget filesystem, version 24 Aug 2004
Aug 05 14:55:19 <vvu> with no errors there
Aug 05 14:56:59 <av500> http://www.eewiki.net/display/linuxonarm/BeagleBone+Black+Comments?focusedCommentId=17498332#comment-17498332
Aug 05 14:57:51 <av500> ah
Aug 05 14:57:53 <av500> is musb loaded?
Aug 05 14:57:56 <av500> musb hdrc?
Aug 05 14:58:15 <av500> check dmesg
Aug 05 14:58:20 <av500> lsmod
Aug 05 14:58:37 <vvu> [    6.192372] usb usb2: Manufacturer: Linux 3.8.11 musb-hcd
Aug 05 14:58:50 <vvu> lsmod nothing regarding musb
Aug 05 15:04:15 <vvu> should i change the kernel with one compiled by myself and with gadgetfs support built in ?
Aug 05 15:04:17 <vvu> not as module
Aug 05 15:04:18 <vvu> ?
Aug 05 15:10:58 <vvu> av500: anyway to tail dmesg for angstrom? i knew tail /var/log/dmesg
Aug 05 15:11:12 <vvu> but angstrom uses journal...dunno what that stuff is
Aug 05 15:12:04 <av500> oh
Aug 05 15:12:10 <av500> no idea
Aug 05 15:12:14 <av500> google it :)
Aug 05 15:12:30 <vvu> when the system freezes i still get a bit of dmesg but with tail to get it fast
Aug 05 15:12:41 <vvu> got mount to work, but same freeze on angstrom
Aug 05 15:12:54 <av500> how did you get mount toi work?
Aug 05 15:13:01 <av500> freeze = shit
Aug 05 15:13:20 <vvu> rmmod g_multi
Aug 05 15:15:00 <vvu> doing gadget mass storage is not an option/
Aug 05 15:18:32 <av500> koen: any idea who can help with:  http://pastebin.com/H2h3Ze19
Aug 05 15:18:37 <av500> balbi still at TI?
Aug 05 15:19:17 <av500> http://www.mail-archive.com/linux-usb@vger.kernel.org/msg21634.html
Aug 05 15:23:22 <av500> google is full of musb babble issues
Aug 05 15:24:09 * vvu does not like musb
Aug 05 15:24:18 <av500> nobody does
Aug 05 15:24:42 * vvu does not like errors/problems/issues/bugs and other sort of insects
Aug 05 15:25:04 <av500> sadly my usb brain is on vacation
Aug 05 15:25:07 <av500> I shot him a mail
Aug 05 15:25:11 <vvu> av500: back to my question doing usb mass storage can be an option ? or same musb errors?
Aug 05 15:25:19 <av500> it can be
Aug 05 15:25:30 <av500> erm
Aug 05 15:25:42 <av500> well, you could expose emmc over MSC
Aug 05 15:25:43 <vvu> on the device side it looks straight forward, dunno on android host side how it enumerates
Aug 05 15:25:54 <av500> then the android app would do the "flashing"
Aug 05 15:26:05 <vvu> MSC ?
Aug 05 15:26:11 <av500> mass storage class
Aug 05 15:26:15 <vvu> yep
Aug 05 15:26:43 <vvu> "flashing" should be raw bulk transfer right?
Aug 05 15:26:49 <vvu> if you have any idea
Aug 05 15:27:00 <av500> well, msc is read/write hdd sectors
Aug 05 15:27:06 <av500> SCSI over usb
Aug 05 15:27:12 <av500> you'll have to implement that
Aug 05 15:27:39 <vvu> at this point i`m like "back to the drawing board"
Aug 05 15:29:55 <av500> hmm
Aug 05 15:30:11 <av500> I guess gadgetfs is not high on the testing list
Aug 05 15:30:16 <vvu> any suggestions what can i do until the fog clears ?
Aug 05 15:30:22 <av500> work on the android app
Aug 05 15:30:27 <av500> download image etc
Aug 05 15:31:07 <vvu> ok, will do that and will try to see if i can make "latest image rpi" what jason suggested in the mail
Aug 05 15:31:13 <av500> yes
Aug 05 15:31:50 <vvu> also, plans to release the app into play store?
Aug 05 15:36:44 <vvu> av500: ^^ ?
Aug 05 15:36:48 <av500> maybe
Aug 05 15:36:51 <av500> if it works :)
Aug 05 15:37:35 <vvu> works is a very relative term when those kernel bugs come into the topic
Aug 05 15:40:00 <vvu> av500: i`m offline for the moment, until the weekly meeting i will have the downloading part ready and maybe some of rpi images
Aug 05 15:40:05 <vvu> have a great day !
Aug 05 15:40:16 <av500> ok
Aug 05 15:49:25 <koen> av500: yes, balbi is still with TI
Aug 05 15:52:51 <av500> ic
Aug 05 15:53:54 <koen> aiui babble is a hardware condition that can't be recovered from
Aug 05 15:53:55 <koen> but
Aug 05 15:53:58 <koen> it can be avoided
Aug 05 15:54:10 <koen> I've seen too much TII double speak about it
Aug 05 15:54:50 <av500> I guess it can be avoided since it depends on what we do over usb
Aug 05 15:55:30 <av500> and we used to have gadgetfs work on omap3 musb
Aug 05 15:58:16 <av500> koen: you know this Ravi B guy?
Aug 05 16:07:45 <koen> only that he's working on musb
Aug 05 21:52:10 <_av500_> vvu: please enable musb debug
Aug 05 21:52:17 <_av500_> and run the gadgetfs stuff again
Aug 05 21:52:45 <vvu> musb debug in kernel?
Aug 05 21:56:00 <vvu> _av500_: what config is it?
Aug 05 22:02:17 <_av500_> MUSB_DEBUG or so
Aug 05 22:02:26 <_av500_> should be enabled
Aug 05 22:02:30 <_av500_> but you need to pass it when loading thre module
Aug 05 22:02:38 <_av500_> debug=1 or so
Aug 05 22:03:02 <vvu> yep but still need to find a way to check dmesg continously when running the usb.c code
Aug 05 22:04:53 <vvu> _av500_: the contact from TI answered with some good info?
Aug 05 22:08:23 <vvu> the angstrom modprobe has --verbose
Aug 05 22:08:31 <vvu> maybe this is the debug
Aug 05 22:19:48 <vvu> _av500_: http://pastebin.com/ByjMNLxS
Aug 05 22:19:55 <vvu> and it freezes after this
Aug 05 22:20:23 <vvu> maybe journal got the kernel error and i can see it
Aug 05 22:27:06 <vvu> _av500_: no luck, don`t have any output beside the one linked above
Aug 05 22:30:27 <ds2> Hmmm
Aug 05 22:33:58 <vvu> ds2: followed the conversation ?
Aug 05 22:42:22 <ds2> vvu: just the pastebin
Aug 05 22:42:25 <ds2> vvu: recap?
Aug 05 22:42:42 <vvu> modprobe gadgetfs works
Aug 05 22:42:49 <vvu> mounting gadgetfs works
Aug 05 22:43:16 <vvu> when i run the demo code from usb.c the one i gave you it freezes the system
Aug 05 22:43:21 <vvu> with the android device attaached
Aug 05 22:43:31 <vvu> without the android attached to the BBB it does not freeze
Aug 05 22:43:57 <vvu> ds2: http://pastebin.com/H2h3Ze19
Aug 05 22:44:02 <vvu> this is the freeze message
Aug 05 22:44:14 <vvu> after this only a hard reboot saves the board
Aug 05 22:45:26 <ds2> looks like a bug
Aug 05 22:45:32 <ds2> in the kernel's gadgetfs code
Aug 05 22:46:27 <ds2> look at teh logic pointed to in the trace
Aug 05 22:46:45 <ds2> it might be somehow invoking spinlock w/o an unlock
Aug 05 22:52:46 <vvu> ds2: i`m a bit lost here but will see what i can do
Aug 05 22:53:34 <ds2> how are you lost?
Aug 05 22:54:21 <vvu> spinlock is when a resource is blocked and the thread cannot access it ?
Aug 05 22:59:21 <ds2> that's the idea
Aug 05 22:59:32 <ds2> but a spinlock is a primative that will let you do that
Aug 05 22:59:39 <ds2> so let's say you have a spinlock foo
Aug 05 22:59:58 <ds2> and you have 2 threads of execution
Aug 05 23:00:27 <ds2> and they mess with a common data structure. You can prevent that structure from being simultanously modified by using spin locks.
Aug 05 23:00:32 <vvu> and with the spinlock you lock from one thread the other one can do stuff, then same principle applies ?
Aug 05 23:00:52 <ds2> Each time you try to modify it, you do a acquire spinlock, modify, then release it
Aug 05 23:01:02 <vvu> okok got it how it works
Aug 05 23:01:20 <ds2> if the other thread has the lock, you thread will sit there and spin hence the name spinlock. when the other thread releases it, your thread will have the lock and continue
Aug 05 23:01:28 <ds2> note that you spin, not sleep
Aug 05 23:02:25 <vvu> ds2: backtraces are read from bottom up or top down *noob question*
Aug 05 23:03:01 <ds2> top most is down
Aug 05 23:03:19 <vvu> ok got it
Aug 05 23:03:25 <ds2> so if this was a userspace program that was calling hundreds of functions, main will be at the end
Aug 05 23:03:31 <ds2> the top is closest to your PC
Aug 05 23:03:38 <ds2> PC as in program counter
Aug 05 23:03:43 <vvu> yep
Aug 05 23:03:43 <ds2> aka IP instruction pointer
Aug 05 23:04:21 <vvu> [  154.971010]  lock: 0xdf3f5800, .magic: dead4ead, .owner: usb/674, .owner_cpu: 0
Aug 05 23:04:36 <vvu> .owner refers to my binary right?
Aug 05 23:04:51 <ds2> no, that is the code in the kernel
Aug 05 23:04:57 <ds2> ur binary is a userland program
Aug 05 23:05:06 <ds2> here it is referring to the USB subsystem
Aug 05 23:05:31 <vvu> 674 is some line of code ?
Aug 05 23:05:58 <ds2> might be. not sure
Aug 05 23:15:58 <vvu> ds2: how does the kernel know when to do a backtrace of the memory block ?
Aug 05 23:16:17 <vvu> is there some specific mechanism that does this?
Aug 05 23:19:33 <Russ> you mean a WARN, BUG, or oops?
Aug 05 23:20:11 <vvu> in my case BUG
Aug 05 23:28:49 <ds2> when it gets an exception
Aug 05 23:28:57 <ds2> or gets requested to do so
Aug 05 23:30:00 <Russ> panic is the thing that eventually gets called in either case
Aug 05 23:34:40 <vvu> ds2: so the error here in the musb will be at the enumeration ep0 treats the enumeration part as i remember
Aug 05 23:36:00 <ds2> not necessarily
Aug 05 23:36:16 <ds2> it could be the MUSB got and error and didn't properly clean up before starting another enumeration
Aug 05 23:36:46 <ds2> if it didn't clean up and was in the middle of one, and it ries to re-enter enumeration again....
Aug 05 23:37:35 <vvu> 1st of all how does the enumeration work, on the android side i get the same serial as the one from BBB
Aug 05 23:37:39 <vvu> some communication is done
Aug 05 23:37:47 <vvu> and it dies afterwards
Aug 05 23:37:55 <vvu> before*
Aug 05 23:38:00 <vvu> wrong after :)
Aug 05 23:41:21 <ds2> ah
Aug 05 23:41:28 <ds2> that will take some typing. give me 1
Aug 05 23:42:38 <ds2> enumeration
Aug 05 23:42:59 <ds2> when you plug in a USB device, you change the values of the DM/DP lines from the defaults so the host side sees your thing.
Aug 05 23:43:14 <ds2> the host side should then issue a reset and send commands to the device
Aug 05 23:43:27 <ds2> this is over ep0
Aug 05 23:43:46 <ds2> the commands would be get descriptors and the device responds with a descriptor (or an error)
Aug 05 23:44:04 <ds2> somewhere in this, the host assigns an address
Aug 05 23:44:15 <ds2> that is enumeration in a nutshell
Aug 05 23:44:24 <vvu> the details about the device right? productid, vendorid those thingies?
Aug 05 23:44:33 <ds2> yes
Aug 05 23:44:49 <ds2> and power, class/type of device
Aug 05 23:45:27 <vvu> yep
Aug 05 23:45:35 <vvu> that serial that is generated for the device
Aug 05 23:45:43 <vvu> is the address ?
Aug 05 23:46:02 <ds2> no
Aug 05 23:46:12 <ds2> address is an arbitrary number used to identify the device on the bus
Aug 05 23:46:24 <ds2> prior to this, it uses basically a broadcast
Aug 05 23:46:35 <ds2> except it isn't quite a broadcast
Aug 06 00:15:34 <vvu> i need to put some printfs in the usb.c code to see where it fails
Aug 06 00:34:07 <vvu> ds2: when a urb is sent on a endpoint also on ep0 something is sent to notify ?
Aug 06 00:39:09 <ds2> I don't understand the question
Aug 06 00:39:53 <vvu> it was silly, figured out myself
Aug 06 00:39:59 <ds2> ok
Aug 06 00:40:12 <vvu> ep0 handels only connect/config/disconnect
Aug 06 00:40:23 <vvu> and nop right?
Aug 06 00:40:54 <vvu> the part in ubs.c with ep0 i get it
Aug 06 00:40:58 <vvu> it`s not o hard
Aug 06 00:41:07 <vvu> now comes the actually speaking part with the device
Aug 06 00:43:55 <vvu> ds2: i don`t get where the sink/source threads are started
Aug 06 00:47:11 <vvu> start_io is called by handle_control ; handle_control  is called by ep0_thread when it`s case GADGETFS_SETUP
Aug 06 00:47:24 <vvu> answered myself the question
Aug 06 00:49:05 <vvu> have a clue where to start debugging, until then good night!
**** ENDING LOGGING AT Tue Aug 06 02:59:58 2013