From owner-cvs-all@FreeBSD.ORG Sun Mar 27 17:34:21 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 6F6C616A4CE; Sun, 27 Mar 2005 17:34:21 +0000 (GMT) In-Reply-To: <200503271531.j2RFVNtJ053546@repoman.freebsd.org> from Ian Dowse at "Mar 27, 2005 03:31:23 pm" To: iedowse@FreeBSD.org (Ian Dowse) Date: Sun, 27 Mar 2005 17:34:21 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050327173421.6F6C616A4CE@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/usb usb.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2005 17:34:21 -0000 > Log: > Don't defer the boot-time exploration of high-speed USB busses. > This ensures that we explore EHCI busses before their companion > controllers' busses, so that ports connected to full/low speed > devices will be properly routed to the companion controllers by the > time the OHCI/UHCI exploration occurs. On the topic of USB, I've noticed a problem lately with my setup that seems to indicate a race condition somewhere in the ukbd driver. I have a Sun w2100z box with several USB 2.0 controllers. The system has two 2.4Ghz Opteron 250 CPUs, and I'm running it in SMP mode. It uses a Sun type 6 USB keyboard and USB mouse. I also have a Dell LCD flat screen display, which has a built-in USB hub. I have the display plugged into one of the Sun's USB ports and the keyboard and mouse plugged into the display, the idea being to reduce the number of cables dangling behind my desk. The thing is, when I power off the Dell monitor, it also powers off its internal USB hub. This in turn shuts off power to the keyboard and mouse, which now look as if they've been unplugged. I tend to power the monitor off when I leave for work in the morning and turn it back on when I come home. Ideally, the keyboard and mouse should reconnect once the power is on again, but when I turn the display back on, what I find is that the kernel has panicked inside ukbd_timeout(): ndis0: link up ndis0: no matching rate for: 216 uhub2: at uhub1 port 1 (addr 2) disconnected ukbd0: at uhub2 port 1 (addr 3) disconnected ukbd0: detached Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc05aef48 stack pointer = 0x10:0xe8ff6cb0 frame pointer = 0x10:0xe8ff6cc0 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 = 53 (swi4: clock sio) [thread pid 53 tid 100062 ] Stopped at ukbd_timeout+0x18: calll *0xc(%eax) db> where Tracing pid 53 tid 100062 td 0xc50112e0 ukbd_timeout(c08ec4c0) at ukbd_timeout+0x18 softclock(0) at softclock+0x1e7 ithread_loop(c4f7fc00,e8ff6d48,c4f7fc00,c05ff75c,0) at ithread_loop+0x120 fork_exit(c05ff75c,c4f7fc00,e8ff6d48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe8ff6d7c, ebp = 0 --- db> It looks as if the ukbd_timeout() routine is not always disabled when the ukbd driver is detached. I suspect there is a race condition somewhere that only manifests on SMP, but I haven't been able to track it down. This is with the 6.0 SNAP002 CD from March 18th. It also happened with the SNAP001 CD. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose =============================================================================