On Fri, 9 Apr 2010, Hendrik Sattler wrote: > I found some additional problems with f_obex: > 1. > After the client disconnects, a select() call with one FD checking for input > data wil always return immediately but read() return 0. I fixed this by > closing the device and re-opening. tcflush() doesn't help. Why is that a problem? Isn't it supposed to work that way? > 2. > I see oops messages: > Apr 8 21:31:20 yavin4 kernel: WARNING: at drivers/usb/gadget/composite.c:183 usb_function_activate+0x32/0x77 [g_serial]() > Apr 8 21:31:20 yavin4 kernel: Hardware name: TravelMate 6592 > Apr 8 21:31:20 yavin4 kernel: Modules linked in: g_serial dummy_hcd lp tekram_sir irtty_sir sir_dev irda binfmt_misc fuse loop iwlagn iwlcore mac80211 cfg80211 tpm_infineon tpm tpm_bios > Apr 8 21:31:20 yavin4 kernel: Pid: 0, comm: swapper Tainted: G W 2.6.33-dirty #3 > Apr 8 21:31:20 yavin4 kernel: Call Trace: > Apr 8 21:31:20 yavin4 kernel: <IRQ> [<ffffffff81030e0a>] ? warn_slowpath_common+0x76/0x8c > Apr 8 21:31:20 yavin4 kernel: [<ffffffffa0034acc>] ? usb_function_activate+0x32/0x77 [g_serial] > Apr 8 21:31:20 yavin4 kernel: [<ffffffffa0035162>] ? gserial_connect+0xdb/0x117 [g_serial] > Apr 8 21:31:20 yavin4 kernel: [<ffffffffa00352a8>] ? obex_set_alt+0x9d/0xab [g_serial] > Maybe that's the cause for the freezes that I still have. Maybe. Certainly it's a bug in the driver. > 3. > I sometimes see the message: > dummy_hcd dummy_hcd: Unlink after no-IRQ? Controller is probably using the wrong IRQ. That's normal; you can ignore it. This message appears because, unlike other host controller drivers, dummy-hcd doesn't use interrupts. (I probably should change dummy-hcd to prevent those messages from appearing...) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
