Am Donnerstag 08 April 2010 21:05:06 schrieb Alan Stern: > On Thu, 8 Apr 2010, Hendrik Sattler wrote: > > It was a problem with my obex server application. However, that should > > never cause a total freeze. Running through valgrind somehow made it > > survive the bug. I wrong pointer was given to the write() call, probably > > with invalid memory. A quick lock at gs_write() in u_serial.c didn't show > > any checks that the buffer pointer is valid. Is this already done by the > > tty layer itself? > > Since the pointer passed to gs_write() points to a kernelspace buffer > rather than a userspace buffer, the check must have been made somewhere > else. Maybe in the tty layer, maybe even in the VFS layer. 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. 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] Apr 8 21:31:20 yavin4 kernel: [<ffffffffa00361ca>] ? composite_setup+0x81f/0x9a8 [g_serial] Apr 8 21:31:20 yavin4 kernel: [<ffffffff8104a145>] ? ktime_get+0x5f/0xb8 Apr 8 21:31:20 yavin4 kernel: [<ffffffff8104e04b>] ? tick_sched_timer+0x0/0x86 Apr 8 21:31:20 yavin4 kernel: [<ffffffffa000d6d8>] ? dummy_timer+0x510/0x893 [dummy_hcd] Apr 8 21:31:20 yavin4 kernel: [<ffffffff8104a145>] ? ktime_get+0x5f/0xb8 Apr 8 21:31:20 yavin4 kernel: [<ffffffffa000d1c8>] ? dummy_timer+0x0/0x893 [dummy_hcd] Apr 8 21:31:20 yavin4 kernel: [<ffffffff81039ca2>] ? run_timer_softirq+0x1a3/0x217 Apr 8 21:31:20 yavin4 kernel: [<ffffffff81035a7f>] ? __do_softirq+0x88/0x109 Apr 8 21:31:20 yavin4 kernel: [<ffffffff81004fe2>] ? timer_interrupt+0x1a/0x21 Apr 8 21:31:20 yavin4 kernel: [<ffffffff81002d4c>] ? call_softirq+0x1c/0x28 Apr 8 21:31:20 yavin4 kernel: [<ffffffff81004951>] ? do_softirq+0x31/0x63 Apr 8 21:31:20 yavin4 kernel: [<ffffffff8103578f>] ? irq_exit+0x36/0x87 Apr 8 21:31:20 yavin4 kernel: [<ffffffff8100405b>] ? do_IRQ+0xa3/0xb9 Apr 8 21:31:20 yavin4 kernel: [<ffffffff8143eb93>] ? ret_from_intr+0x0/0xa Apr 8 21:31:20 yavin4 kernel: <EOI> [<ffffffff811cf114>] ? acpi_idle_enter_simple+0x153/0x17c Apr 8 21:31:20 yavin4 kernel: [<ffffffff811cf10a>] ? acpi_idle_enter_simple+0x149/0x17c Apr 8 21:31:20 yavin4 kernel: [<ffffffff8133e896>] ? cpuidle_idle_call+0x8b/0xc5 Apr 8 21:31:20 yavin4 kernel: [<ffffffff8100127c>] ? cpu_idle+0xa4/0xe4 Apr 8 21:31:20 yavin4 kernel: [<ffffffff818c0ba2>] ? start_kernel+0x323/0x32e Apr 8 21:31:20 yavin4 kernel: [<ffffffff818c034b>] ? x86_64_start_kernel+0xe5/0xe9 Apr 8 21:31:20 yavin4 kernel: ---[ end trace b71742068fb80d06 ]--- Apr 8 21:31:49 yavin4 kernel: g_serial gadget: high speed config #3: CDC OBEX config Maybe that's the cause for the freezes that I still have. 3. I sometimes see the message: dummy_hcd dummy_hcd: Unlink after no-IRQ? Controller is probably using the wrong IRQ. BTW: the "-dirty" comes from radeon fixes, so totally unrelated :) Thanks HS -- 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
