Re: cdc_acm crash with multiple USB modems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 25, 2013 at 11:38:38AM -0600, Mike@xxxxxxxxxxxxx wrote:
> Hi there, 
> 
> Apologies if I'm submitting this issue to the wrong place.
> 
> The problem:
> 
> Basically I have a Hylafax server running with 4 USB modems all using the
> cdc_acm driver.  Everything works great unless a job is submitted that
> specifies multiple recipients and that hylafax may use any available modem.
> If the same job is submitted but a particular modem is assigned for the
> job, no problem.   Other jobs, sending or receiving, could be and often
> are, running at the same time.   I'm uncertain if during the problem
> condition that hylfax sees, 2 recipients, 2 available modems, lets send to
> them both at exactly the same time, and th
> 
> In that particular condition, a kernel panic is thrown and the machine
> locks up.
> 
> I've submitted the bug to the Hylafax maintainers *see attached  They
> think it's an issue with cdc_acm.  Is there any other information that
> would be helpful?
> 
> Thank you so much for your time, again if I'm in the wrong place, please
> let me know.
> 
> 
> :::System info:
> Ubuntu 12.04.03 LTS running a 3.2 Kenrnel

This is a Ubuntu-specific kernel and a fairly old one too. Unless you
can reproduce this problem with a recent kernel such as 3.12.2 from
kernel.org, you need to ask them about this.

Thanks,
Johan

> Hylafax installed from APT
> Four Modems USB Conexant Chipset,  cdc_acm module ttyACM0-4 mapped as
> faxmodem0-4 via udev
> 
> KERNEL=="ttyACM*", KERNELS=="2-1.1:1.0", SYMLINK+="faxmodem0", MODE="0777"
> KERNEL=="ttyACM*", KERNELS=="2-1.2:1.0", SYMLINK+="faxmodem1", MODE="0777"
> KERNEL=="ttyACM*", KERNELS=="2-1.3:1.0", SYMLINK+="faxmodem2", MODE="0777"
> KERNEL=="ttyACM*", KERNELS=="2-1.4.1:1.0", SYMLINK+="faxmodem3",
> MODE="0777"
> 
> :::Error:
> 
> kern.log records the following just before the crash, this happens seconds
> after the job is submitted.  
> 
> (This repeats over and over)
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312028] INFO: task faxgetty:5314
> block
> ed for more than 1 seconds.
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312091] "echo 0 >
> /proc/sys/kernel/hun
> g_task_timeout_secs" disables this message.
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312150] faxgetty        D
> bdb4de00
>  0  5314      1 0x00000000
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312158]  f509be38 00200086
> 00000003 bd
> b4de00 00000054 f50b4bc0 00200046 c18ca3c0
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312170]  c18ca3c0 bd7803b1
> 00000054 f7
> baa3c0 f120d860 f120bf20 c1578329 f120d860
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312182]  00000000 00000000
> f6c73280 f5
> 09be40 c1571371 f6c73280 c17ea6e0 f509a000
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312193] Call Trace:
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312208]  [<c1578329>] ?
> smp_apic_timer
> _interrupt+0x59/0x88
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312217]  [<c1571371>] ?
> apic_timer_int
> errupt+0x31/0x40
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312225]  [<c13e00e0>] ?
> hub_port_statu
> s+0xd0/0x100
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312231]  [<c156f115>]
> schedule+0x35/0x
> 50
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312236]  [<c156fcb6>]
> __mutex_lock_slo
> wpath+0xc6/0x120
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312241]  [<c156f964>]
> mutex_lock+0x24/
> 0x40
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312246]  [<c1570dd2>]
> tty_lock+0x12/0x
> 14
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312252]  [<c1334986>]
> tty_port_close_s
> tart+0x136/0x1d0
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312271]  [<f84f6a2e>]
> acm_tty_close+0x
> 3e/0xa0 [cdc_acm]
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312278]  [<c132d4df>]
> tty_release+0x10
> f/0x4e0
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312285]  [<c1105bee>] ?
> handle_mm_faul
> t+0x15e/0x2c0
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312291]  [<c1133a47>]
> fput+0xb7/0x1f
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312297]  [<c11302d4>]
> filp_close+0x54/
> 0x80
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312302]  [<c1130373>]
> sys_close+0x73/0
> xc0
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312308]  [<c1577ba3>]
> sysenter_do_call
> +0x12/0x28
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312313]  [<c1570000>] ?
> schedule_hrtim
> eout_range+0x20/0x20
> Nov 21 15:29:48 ITMFRW-CCI kernel: [  365.312318] INFO: task faxgetty:5315
> blocked for more than 1 seconds.
> 
> :::lsusb:
> 
> Bus 002 Device 003: ID 0572:1328 Conexant Systems (Rockwell), Inc. 
> Bus 002 Device 004: ID 17ef:7000 Lenovo 
> Bus 002 Device 005: ID 17ef:7000 Lenovo 
> Bus 002 Device 007: ID 17ef:7000 Lenovo 
> 
> 
> :::syslog when modems are plugged in:
> 
> Nov 25 10:59:42 ITMFRW-CCI kernel: [  192.484056] cdc_acm 2-1.1:1.0:
> ttyACM0: USB ACM device
> Nov 25 10:59:42 ITMFRW-CCI kernel: [  193.134054] cdc_acm 2-1.2:1.0:
> ttyACM1: USB ACM device
> Nov 25 10:59:43 ITMFRW-CCI kernel: [  193.854165] cdc_acm 2-1.3:1.0:
> ttyACM2: USB ACM device
> Nov 25 10:59:44 ITMFRW-CCI kernel: [  194.574277] cdc_acm 2-1.4.1:1.0:
> ttyACM3: USB ACM device
> 
> :::Hylafax userlist email:
> 
> Lee Howard
> 
> faxgetty's crashing is not the cause of the kernel panic.  Both are 
> symptoms of an earlier problem with your tty device driver. faxgetty 
> crashes because the tty device driver malfunctions and does something 
> unexpected.  The kernel panic is happening because of the same or 
> related malfunctions in the device driver.  So while it's possible that 
> faxgetty's flailing about following the first malfunction triggers a new 
> set of malfunctions in the device driver, leading to the kernel panic, 
> the call trace you've provided points fingers at the cdc_acm module.
> 
> smp_apic_timer, apic_timer_int, and hub_port_status are not calls that 
> faxgetty is making and are only related to what faxgetty is doing 
> because the tty driver is making those calls subsequent to some 
> behaviour by faxgetty.
> 
> Furthermore, this is evident from your problem description: whenever one 
> modem is used alone everything is fine, but if multiple modems are used 
> concurrently then things fail.  One faxgetty operates per-modem, and 
> faxgetty knows nothing at all about multiple modems; it operates no 
> differently when one is being used versus when two, three, or four are 
> being used.
> 
> I think that you should bring this up with the cdc_acm module developers.
> 
> Thanks,
> 
> Lee.
--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux