From owner-cvs-src@FreeBSD.ORG Tue Sep 16 13:07:02 2008 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93D721065686 for ; Tue, 16 Sep 2008 13:07:02 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by mx1.freebsd.org (Postfix) with ESMTP id 13DB18FC2B for ; Tue, 16 Sep 2008 13:07:01 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so1473618tid.3 for ; Tue, 16 Sep 2008 06:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:organization :x-operation-sytem:from; bh=MIuH/Qh4cSEcmjz296eygY6DHuyCY5IbJKgjOo0jCH8=; b=lX108CpWk/6lxgYqlGHVCAapZdzMy25Wn1cQqcRqwLlL7W3IZIRzlidZ7gnE1vFMz6 VS8fjQO5M9XFZq1K98R4kvkCyO/qVBZ4oZSUYlbIEBYNav+5af1KLNqjJiN+hvptlIon PXmpR1hScNpqyXu0NaPV2VIaWxfag8mRPhQIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem:from; b=dnWoxrpCVaF58oKU+mKNgxXVdAoc929qBUTOMnF0tjGKmH+m6SSokKwtMulmUhrUdh XSzvr4amniJGcBJgPwaca3qtHwFDRUVbAFReNFnLYfmSH3YCX9EjcCxPPZglpEty1B8M 2NQeBsZtQvW0bZmhO7TnMdLC9+YTbe5/Wl4f0= Received: by 10.110.92.8 with SMTP id p8mr1366866tib.25.1221570420418; Tue, 16 Sep 2008 06:07:00 -0700 (PDT) Received: from freebsd.weongyo.org ( [211.53.35.67]) by mx.google.com with ESMTPS id j5sm1179829tid.12.2008.09.16.06.06.57 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Sep 2008 06:06:58 -0700 (PDT) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Tue, 16 Sep 2008 22:06:46 +0900 Date: Tue, 16 Sep 2008 22:06:46 +0900 To: Sam Leffler Message-ID: <20080916130646.GA52103@freebsd.weongyo.org> Mail-Followup-To: Sam Leffler , src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org References: <200809100341.m8A3f5n4001038@repoman.freebsd.org> <48C7EF65.3050204@freebsd.org> <20080911073458.GB23009@freebsd.weongyo.org> <48C93C1B.2080800@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48C93C1B.2080800@freebsd.org> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/usb if_zyd.c if_zydreg.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 13:07:02 -0000 On Thu, Sep 11, 2008 at 08:41:15AM -0700, Sam Leffler wrote: > Weongyo Jeong wrote: > >On Wed, Sep 10, 2008 at 09:01:41AM -0700, Sam Leffler wrote: > > > >>Weongyo Jeong wrote: > >> > >>>weongyo 2008-09-10 03:40:51 UTC > >>> > >>> FreeBSD src repository > >>> > >>> Modified files: > >>> sys/dev/usb if_zyd.c if_zydreg.h > >>> Log: > >>> SVN rev 182900 on 2008-09-10 03:40:51Z by weongyo > >>> > >>> rename flags and add a ZYD_FLAG_DETACHING flag to indicate we're > >>> detaching that when the USB is pulled out forcibly during the driver is > >>> running background scan, a page fault can be occurred even if we called > >>> usb_rem_task() when detaching. It looks like a kind of races. > >>> > >>> > >>> > >>If I understand the issue, it should be handled in the 802.11 state > >>machine. The device should be clocked to the INIT state and as a result > >>clear any outstanding tasks, timers, etc. The only reason you need to > >>do something special is if the h/w is gone and you need to guard against > >>accessing it. > >> > >> Sam > >> > >> > > > >This patch is to fix the below panic that it looks that it sometimes > >occurs when we pull out USB stick forcibly during the driver's trying to > >search channels or run background scan. > > > >If we have a method to detect whether detach() is called by being pulled > >out USB stick unexpectedly or detach() is called by operations of > >kldunload(8), I think I can handle this case more flexibly. (I'm not > >sure it's true. :-) Is there a way to detect this case or something I > >missed? > > > >I have no ideas yet how I can handle it in 802.11 state machine. > > > >[root@kkk /usr/src/sys/modules/zyd]# zyd0: at uhub3 port 4 (addr 2) > >disconnected > >zyd0: zyd_read sleep timeout > >zyd0: could not send command (error=IOERROR) > >zyd0: could not send command (error=IOERROR) > >zyd0: could not send command (error=IOERROR) > >zyd0: zyd_read sleep timeout > >zyd0: could not send command (error=IOERROR) > >zyd0: zyd_read sleep timeout > >zyd0: could not send command (error=IOERROR) > >zyd0: could not send command (error=IOERROR) > >zyd0: could not send command (error=IOERROR) > >zyd0: detached > > > >Fatal trap 12: page fault while in kernel mode > >cpuid = 0; apic id = 00 > >fault virtual address = 0x6a626f7f > >fault code = supervisor read, page not present > >instruction pointer = 0x20:0xc07908b6 > >stack pointer = 0x28:0xc3e30aec > >frame pointer = 0x28:0xc3e30aec > >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 = 16 (usbtask-dr) > >[thread pid 16 tid 100026 ] > >Stopped at devclass_get_name+0x6: movl 0x14(%eax),%eax > >db> bt > >Tracing pid 16 tid 100026 td 0xc40cc8c0 > >devclass_get_name(6a626f6b,c3e30b14,c0790e77,deadc0de,ffffffff,...) at > >devclass_get_name+0x6 > >device_get_name(deadc0de,ffffffff,0,c69c2a00,1,...) at device_get_name+0x1c > >device_print_prettyname(deadc0de,c69c2a00,1,c69c2a00,c3e30bc4,...) at > >device_print_prettyname+0x17 > >device_printf(deadc0de,c69cc297,100,c69cc290,3e8,...) at device_printf+0x12 > >zyd_cmd(2,c3e30be0,1,1,c3e5932c,...) at zyd_cmd+0x1f0 > >zyd_read16(c69cc567,c0bd8504,c3e30c10,c07aa70b,c69cc567,...) at > >zyd_read16+0x38 > >zyd_rfwrite(1,c69c2a00,c3e30c98,c69c9124,c69c2a08,...) at zyd_rfwrite+0x1c > >zyd_al2230_set_channel(c69c2a08,2,c69cc567,ac7,0,...) at > >zyd_al2230_set_channel+0x21 > >zyd_set_chan(c0ca30d0,0,c69cc567,ac7,c0c38d34,...) at zyd_set_chan+0x54 > >zyd_scantask(c69c2a00,0,5c,c0af321d,0,...) at zyd_scantask+0xe1 > >usb_task_thread(c0c38d34,c3e30d38,c0afb326,322,c40cc8c0,...) at > >usb_task_thread+0xca > >fork_exit(c06dcfd0,c0c38d34,c3e30d38) at fork_exit+0x112 > >fork_trampoline() at fork_trampoline+0x8 > >--- trap 0, eip = 0, esp = 0xc3e30d70, ebp = 0 --- > >db> > > > > > > In zyd_newstate the current code does this: > > usb_rem_task(sc->sc_udev, &sc->sc_task); > > /* do it in a process context */ > sc->sc_state = nstate; > sc->sc_arg = arg; > > if (nstate == IEEE80211_S_INIT) { > zvp->newstate(vap, nstate, arg); > return 0; > } else { > usb_add_task(sc->sc_udev, &sc->sc_task, USB_TASKQ_DRIVER); > return EINPROGRESS; > } > > You need to clear any pending task callbacks, not just the one > associated with sc_udev (unless your callbacks do evil things like check > the current state to deal with races). The transition to the INIT state > must execute synchronously for multiple reasons (including detach); in > that case it looks like you must explicitly cancel the task that handles > scan-related work. Oh. I see. :-) I'll will test and commit it. Thanks! regards, Weongyo Jeong