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
