From nobody@FreeBSD.org  Sat Apr  8 09:28:06 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id BBF7516A400
	for <freebsd-gnats-submit@FreeBSD.org>; Sat,  8 Apr 2006 09:28:06 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id EAC1343D7D
	for <freebsd-gnats-submit@FreeBSD.org>; Sat,  8 Apr 2006 09:27:56 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k389Ruiw071098
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 8 Apr 2006 09:27:56 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k389RuCF071090;
	Sat, 8 Apr 2006 09:27:56 GMT
	(envelope-from nobody)
Message-Id: <200604080927.k389RuCF071090@www.freebsd.org>
Date: Sat, 8 Apr 2006 09:27:56 GMT
From: Kyryll A Mirnenko <mirya@matrix.ua>
To: freebsd-gnats-submit@FreeBSD.org
Subject: uplcom(4) causes system hangups
X-Send-Pr-Version: www-2.3

>Number:         95512
>Category:       kern
>Synopsis:       [uplcom] uplcom(4) causes system hangups
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    jh
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Apr 08 09:30:15 GMT 2006
>Closed-Date:    Thu Dec 30 16:50:25 UTC 2010
>Last-Modified:  Thu Dec 30 16:50:25 UTC 2010
>Originator:     Kyryll A Mirnenko
>Release:        6.0-RELEASE
>Organization:
>Environment:
FreeBSD myhost 6.0-RELEASE-p6 FreeBSD 6.0-RELEASE-p6 #5: Thu Mar 23 15:57:16 EET 2006     root@myhost:/usr/src/sys/i386/compile/GENERIC  i386
>Description:
There 2 bugs seems to come from the same source when using uplcom(4):

1) both /dev/cuaU0 and /dev/ttyU0 can't be opened the same time. E.g. if starting getty on the latter it's impossible to make ppp call on the first (handbook-described dialup callback method). The kernel says:

ucom0: open bulk out error (addr 2): IN_USE

As far as this is definitely possible with direct COM modem (cuad) and comms/ltmdm winmodem driver (cual) such behavior is at least strange.

2) When making direct ppp call and receiving incoming via getty repeated message is produced by kernel:

putc to a clist with no reserved cblocks

At last when getty passes control to ppp (via a login script which is exec'ing `ppp -direct`) i'm getting a couple of "clist" mesages and one about "IN_USE" (in random sequence), after that the system freezes.

The kernel used is GENERIC, uplcom is added to loader.conf

>How-To-Repeat:
The USB2Serail i'm using is (according to usbdevs):USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00.

/etc/gettytab contains:

callback1|38400-baud:\
        :np:sp#38400:pp=/etc/ppp/callback.ppp:


/etc/ppp/callback.ppp:

#!/bin/sh
exec /usr/sbin/ppp -direct myisp-cb


/etc/ppp/ppp.conf:

default:
 set log Phase Chat LCP IPCP CCP tun
 ident user-ppp VERSION (built COMPILATIONDATE)
 set device /dev/cuaU0
 set speed 38400
 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
           \"\" AT OK-AT-OK ATE1Q0 OK \\dATDP\\T TIMEOUT 80 CONNECT"
 set timeout 600
 enable dns
 disable pred1 deflate lqr
 deny pred1 deflate lqr
 set urgent udp +53
 allow user mirya
 set ifaddr 0.0.0.0 0.0.0.0 0.0.0.0

myisp:
 set phone ispphone
 set authname auth
 set authkey pass
 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
           \"\" AT OK-AT-OK ATS0=1 OK \\dAT OK \\dAT OK \\dATDP\\T TIMEOUT 80 CONNECT"
 add default HISADDR
 set callback cbcp
 set cbcp myphone

myisp-cb:
 add default HISADDR
 set authname auth
 set authkey pass
 set logout "AT OK-AT-OK ATS0=0 OK \\dAT OK \\dAT OK"

Running as root:

# ppp -background cheap
# /usr/libexec/getty callback1 ttyU0 2>/dev/null >/dev/null &

Direct call is done correctly (some "clist" messages are dropped), getty seems to answer it and pass control to ppp, then everything hangs up as described above
>Fix:

>Release-Note:
>Audit-Trail:

From: Kyryll A Mirnenko aka Mirya <mirya@matrix.ua>
To: bug-followup@freebsd.org
Cc: mirya@matrix.ua
Subject: Re: kern/95512 : [uplcom] uplcom(4) causes system hangups
Date: Fri, 28 Apr 2006 00:36:49 +0300

 Recently updated to RELENG_6_1, the same sequence now produces no hangups but 
 random panics. I still can't establish callback link and got either ppp 
 terminating (see msgs above) or kernel panics. The traces will be available 
 in a few days

From: Kyryll A Mirnenko aka Mirya <mirya@matrix.ua>
To: bug-followup@freebsd.org,
 mirya@matrix.ua
Cc:  
Subject: Re: kern/95512: [uplcom] uplcom(4) causes system hangups
Date: Sat, 29 Apr 2006 19:07:54 +0300

 Here's full sequence for RELENG_6_1 / -O0 kernel with full debug (including 
 WITNESS/INVARIANTS) (up to posting date):
 
 1) I use
 USB-Serial Controller(0x2303), Prolific Technology Inc.(0x067b), rev 3.00
 according to usbdevs
 2) call out using ppp as described
 3) start getty to listen on ttyU0
 4) received 2 messages from kernel:
 putc to a clist with no reserved cblocks
 5) getty processes call-in, receiving couple of "clist" messages together with
 ucom0: open bulk out error (addr 2): IN_USE
 6) modem hangs up, no link established
 7) now when trying to access cuaU0/ttyU0 (e.g. with tip(1), etc), getting 
 "device not configured" error
 8) plugging out hardware device
 9) panic
 backtrace:
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address	= 0x4
 fault code		= supervisor read, page not present
 instruction pointer	= 0x20:0xc04f37ac
 stack pointer	        = 0x28:0xca77cb54
 frame pointer	        = 0x28:0xca77cba8
 code segment		= base 0x0, limit 0xfffff, type 0x1b
 			= DPL 0, pres 1, def32 1, gran 1
 processor eflags	= interrupt enabled, resume, IOPL = 0
 current process		= 22 (irq10: rl0 uhci0)
 panic: from debugger
 KDB: stack backtrace:
 Syncing disks, buffers remaining... 130 130 130 130 130 130 130 130 130 130 
 130 130 130 130 130 130 130 130 130 130 
 Giving up on 130 buffers
 Uptime: 23m44s
 Dumping 222 MB (2 chunks)
   chunk 0: 1MB (159 pages) ... ok
   chunk 1: 222MB (56800 pages) 206 190 174 158 142 126 110 94 78 62 46 30 14
 
 #0  doadump () at ../../../kern/kern_shutdown.c:235
 235		dumptid = curthread->td_tid;
 (kgdb) bt full
 #0  doadump () at ../../../kern/kern_shutdown.c:235
 No locals.
 #1  0xc05b1a47 in boot (howto=256) at ../../../kern/kern_shutdown.c:402
 	first_buf_printf = 0
 #2  0xc05b1dce in panic (fmt=0xc0802860 "from debugger")
     at ../../../kern/kern_shutdown.c:558
 	td = (struct thread *) 0xc1fb8180
 	bootopt = 256
 	newpanic = 1
 	ap = 0xca77c8d8 "\220w\204E7O"
 	buf = "from debugger", '\0' <repeats 242 times>
 #3  0xc045def2 in db_panic (addr=-1068550228, have_addr=0, count=-1, 
     modif=0xca77c908 "") at ../../../ddb/db_command.c:438
 No locals.
 #4  0xc045de84 in db_command (last_cmdp=0xc08a0004, cmd_table=0x0, 
     aux_cmd_tablep=0xc085e150, aux_cmd_tablep_end=0xc085e154)
     at ../../../ddb/db_command.c:350
 	cmd = (struct command *) 0xc0802850
 	t = 1
 	modif = 
 "\000\035\221\000\000\000\000\r\000\000\000\r\000\000\000\000\000\000\000\001\000\000\000<w 
 \035\2214wʲ6{\002\000\000\000Pw_ 
 \\\005`w7\bF\006/\200\004F\000\000\000\000\020\000\000\000lw\000\000\000\000PcY\235E\000\t\2120\001\212x\000\000\0007\bF\220w*E"
 	addr = -1068550228
 	count = -1
 	have_addr = 0
 	result = 0
 #5  0xc045df77 in db_command_loop () at ../../../ddb/db_command.c:458
 No locals.
 #6  0xc04603f7 in db_trap (type=12, code=0) at ../../../ddb/db_main.c:221
 	jb = {{_jb = {-1039836128, -898119252, -898119168, -1067883696, 0, 
       -1069153381, -1067622757, -1064658720, -898119168, -1067622328, 
       -1040481920, 0}}}
 	prev_jb = (void *) 0x0
 	bkpt = 0
 	watchpt = 0
 #7  0xc05d60f5 in kdb_trap (type=12, code=0, tf=0xca77cb14)
     at ../../../kern/subr_kdb.c:473
 	handled = 524930
 #8  0xc07d873f in trap_fatal (frame=0xca77cb14, eva=4)
     at ../../../i386/i386/trap.c:827
 	eflags = 524930
 	code = 0
 	type = 12
 	ss = 40
 	esp = -898118828
 	softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, 
   ssd_dpl = 0, ssd_p = 1, ssd_xx = 12, ssd_xx1 = 0, ssd_def32 = 1, 
   ssd_gran = 1}
 	msg = 0xc08574d7 "page fault"
 #9  0xc07d8362 in trap_pfault (frame=0xca77cb14, usermode=0, eva=4)
     at ../../../i386/i386/trap.c:744
 	va = 0
 	vm = (struct vmspace *) 0xc08a5120
 	map = 0xc08a5120
 	rv = 1
 	ftype = 1 '\001'
 	td = (struct thread *) 0xc1fb8180
 	p = (struct proc *) 0xc202520c
 #10 0xc07d7ddf in trap (frame=
       {tf_fs = -898170872, tf_es = 40, tf_ds = 40, tf_edi = 0, tf_esi = 
 -1067883696, tf_ebp = -898118744, tf_isp = -898118848, tf_ebx = -1039836128, 
 tf_edx = 0, tf_ecx = -898118872, tf_eax = 0, tf_trapno = 12, tf_err = 0, 
 tf_eip = -1068550228, tf_cs = 32, tf_eflags = 590406, tf_esp = -1038417024, 
 tf_ss = -1039810560}) at ../../../i386/i386/trap.c:434
 	td = (struct thread *) 0xc1fb8180
 	p = (struct proc *) 0xc202520c
 	sticks = 0
 	i = 0
 	ucode = 0
 	type = 12
 	code = 0
 	eva = 4
 #11 0xc07c014a in calltrap () at ../../../i386/i386/exception.s:139
 No locals.
 #12 0xc04f37ac in uhci_device_bulk_start (xfer=0xc22a6600)
     at ../../../dev/usb/uhci.c:1868
 	upipe = (struct uhci_pipe *) 0xc21b0380
 	dev = 0xc21b0900
 	sc = (uhci_softc_t *) 0xc205c000
 	ii = (uhci_intr_info_t *) 0xc22a6670
 	data = (uhci_soft_td_t *) 0x0
 	dataend = (uhci_soft_td_t *) 0x0
 	sqh = (uhci_soft_qh_t *) 0xc2066da0
 	err = USBD_NORMAL_COMPLETION
 	len = 0
 	isread = 0
 	endpt = 0
 	s = -898118720
 #13 0xc05091e1 in usbd_start_next (pipe=0xc21c9400)
     at ../../../dev/usb/usbdi.c:933
 	xfer = 0xc22a6600
 	err = 3257559552
 #14 0xc0509139 in usb_transfer_complete (xfer=0xc22a6100)
     at ../../../dev/usb/usbdi.c:874
 	pipe = 0xc21c9400
 	dmap = (usb_dma_t *) 0xc22a613c
 	sync = 0
 	erred = 0
 	repeat = 0
 	polling = 0
 #15 0xc04f2bbc in uhci_idone (ii=0xc22a6170) at ../../../dev/usb/uhci.c:1499
 	xfer = 0xc22a6100
 	upipe = (struct uhci_pipe *) 0xc21c9400
 	std = (uhci_soft_td_t *) 0xc2065ec0
 	status = 4456448
 	nstatus = 947913727
 	actlen = 0
 #16 0xc04f29f7 in uhci_check_intr (sc=0xc205c000, ii=0xc22a6170)
     at ../../../dev/usb/uhci.c:1374
 	std = (uhci_soft_td_t *) 0xc2065ea0
 	lstd = (uhci_soft_td_t *) 0xc2065f00
 	status = 541394943
 #17 0xc04f28d3 in uhci_softintr (v=0xc205c000) at ../../../dev/usb/uhci.c:1304
 	sc = (uhci_softc_t *) 0xc205c000
 	ii = (uhci_intr_info_t *) 0xc22a6170
 	nextii = (uhci_intr_info_t *) 0xc2023870
 #18 0xc0504c27 in usb_schedsoftintr (bus=0xc205c000)
     at ../../../dev/usb/usb.c:871
 No locals.
 #19 0xc04f2882 in uhci_intr1 (sc=0xc205c000) at ../../../dev/usb/uhci.c:1274
 	status = 2
 	ack = 2
 #20 0xc04f24f1 in uhci_intr (arg=0xc205c000) at ../../../dev/usb/uhci.c:1189
 	sc = (uhci_softc_t *) 0xc205c000
 #21 0xc059623a in ithread_execute_handlers (p=0xc202520c, ie=0xc1faa780)
     at ../../../kern/kern_intr.c:684
 	ih = (struct intr_handler *) 0xc2058dc0
 	ihn = (struct intr_handler *) 0x0
 #22 0xc05963fa in ithread_loop (arg=0xc2055c20)
     at ../../../kern/kern_intr.c:767
 	intr_event = (struct intr_thread *) 0xc2055c20
 	ie = (struct intr_event *) 0xc1faa780
 	td = (struct thread *) 0xc1fb8180
 	p = (struct proc *) 0xc202520c
 	__func__ = "ithread_loop"
 #23 0xc0594c19 in fork_exit (callout=0xc0596350 <ithread_loop>, 
     arg=0xc2055c20, frame=0xca77cd38) at ../../../kern/kern_fork.c:805
 	p = (struct proc *) 0xc202520c
 	td = (struct thread *) 0xc1fb8180
 #24 0xc07c01ac in fork_trampoline () at ../../../i386/i386/exception.s:208
 No locals.
 -- 
 Regards, Mirya
 ICQ #313898202

From: Kyryll A Mirnenko aka Mirya <mirya@matrix.ua>
To: bug-followup@FreeBSD.org,
 mirya@matrix.ua
Cc:  
Subject: Re: kern/95512: [uplcom] uplcom(4) causes system hangups
Date: Mon, 9 Oct 2006 01:23:42 +0300

 Updated to 6.2-BETA2, the problem still exists though can't get hangup on 
 incoming call directly. Here's what I do:
 
 - direct call
 - received incoming call - modem starts negotiations
 - two "putc to a clist with no reserved cblocks" kernel messages  on ttyv0
 - getty tries to open /dev/ttyU0
 - a couple of "putc to a clist with no reserved cblocks" an one "ucom0: open 
 bulk out error (addr 2): IN_USE" kernel message on console
 - getty reports /dev/ttyU0 can't be opened
 - modem hands up
 - retry the above sequence with the same effect except for the fact two 
 additional "putc to a clist with no reserved cblocks" kernel messages come on 
 direct call
 - after modem hangup unplug USB2COM connector
 - got panic with uhci IRQ handler as current process
 
 -- 
 Regards, Mirya
 ICQ #313898202
State-Changed-From-To: open->feedback 
State-Changed-By: jh 
State-Changed-When: Fri Nov 26 07:59:47 UTC 2010 
State-Changed-Why:  
Can you still reproduce this on 8.x? 


Responsible-Changed-From-To: freebsd-bugs->jh 
Responsible-Changed-By: jh 
Responsible-Changed-When: Fri Nov 26 07:59:47 UTC 2010 
Responsible-Changed-Why:  
Track. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=95512 
State-Changed-From-To: feedback->closed 
State-Changed-By: jh 
State-Changed-When: Thu Dec 30 16:50:23 UTC 2010 
State-Changed-Why:  
Feedback timeout. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=95512 
>Unformatted:
