On Fri, 2012-04-13 at 21:03 +0200, Thomas Schäfer wrote: > Hi, > > may be the info is useless/already known. > Today I used the huawei e398 with the new wwan-driver at the underground > railway - of course with "special" conditions. The good news: The connection > was stalled but not broken. In other words, after some seconds/minutes the > packets flowed again without user action. Probably the connection went dormant in a dead spot while the firmware looked for a new sector. I suppose we probably need to figure out what the dormancy timeout is and adjust the TX watchdog timeout to be something similar. Cellular devices often keep the IP connection allocated (but not necessarily active) for quite a while after they lose a base station, while they're searching for another one. A cheap way of ensuring you don't have to set everything back up again just because you drove through a dead spot for 30 seconds. Dan > Here is the dmesg output: > > [ 507.009000] ------------[ cut here ]------------ > [ 507.009030] WARNING: at /home/abuild/rpmbuild/BUILD/kernel- > desktop-3.4.rc2/linux-3.4-rc2/net/sched/sch_generic.c:256 > dev_watchdog+0x1e7/0x1f0() > [ 507.009040] Hardware name: 701 > [ 507.009047] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out > [ 507.009054] Modules linked in: sit tunnel4 af_packet option usb_wwan > qmi_wwan usbnet usbserial cdc_wdm sr_mod cdrom ip6table_filter ip6_tables > iptable_filter ip_tables x_tables tun snd_pcm_oss snd_mixer_oss snd_seq > snd_seq_device edd mperf dm_mod sg snd_hda_codec_realtek uvcvideo > snd_hda_intel videobuf2_core videodev snd_hda_codec eeepc_laptop > videobuf2_vmalloc videobuf2_memops iTCO_wdt snd_hwdep sparse_keymap microcode > iTCO_vendor_support i2c_i801 joydev pcspkr snd_pcm rfkill snd_timer battery ac > pci_hotplug snd soundcore snd_page_alloc atl2 i915 drm_kms_helper drm > i2c_algo_bit button video fan processor ata_generic thermal thermal_sys [last > unloaded: speedstep_lib] > [ 507.009217] Pid: 0, comm: swapper/0 Not tainted 3.4.0-rc2-1-desktop #1 > [ 507.009224] Call Trace: > [ 507.009258] [<c02055e3>] try_stack_unwind+0x173/0x180 > [ 507.009278] [<c02042f7>] dump_trace+0x47/0xf0 > [ 507.009293] [<c020563b>] show_trace_log_lvl+0x4b/0x60 > [ 507.009308] [<c0205668>] show_trace+0x18/0x20 > [ 507.009325] [<c072c2f6>] dump_stack+0x6d/0x72 > [ 507.009346] [<c0233b08>] warn_slowpath_common+0x78/0xb0 > [ 507.009362] [<c0233bd3>] warn_slowpath_fmt+0x33/0x40 > [ 507.009377] [<c0658447>] dev_watchdog+0x1e7/0x1f0 > [ 507.009396] [<c0240d5c>] call_timer_fn+0x2c/0x160 > [ 507.009412] [<c02415cf>] run_timer_softirq+0xdf/0x220 > [ 507.009428] [<c023a302>] __do_softirq+0x82/0x210 > [ 507.009443] [<c02041de>] do_softirq+0x7e/0xb0 > [ 507.009465] [<0000000f>] 0xe > [ 507.009472] ---[ end trace 9c175c2124dddd8f ]--- > > Regards, > > Thomas > -- > 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 -- 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
