From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 12:18:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60051106568D; Sun, 27 Sep 2009 12:18:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 303548FC13; Sun, 27 Sep 2009 12:18:03 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA14452; Sun, 27 Sep 2009 15:18:01 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MrshU-0004h6-Sv; Sun, 27 Sep 2009 15:18:01 +0300 Message-ID: <4ABF57F5.1050106@icyb.net.ua> Date: Sun, 27 Sep 2009 15:17:57 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: Hans Petter Selasky References: <4ABA36B1.9070706@icyb.net.ua> <200909241651.47850.hselasky@c2i.net> <4ABC646D.4070604@icyb.net.ua> <200909250928.51515.hselasky@c2i.net> In-Reply-To: <200909250928.51515.hselasky@c2i.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 12:18:05 -0000 on 25/09/2009 10:28 Hans Petter Selasky said the following: > On Friday 25 September 2009 08:34:21 Andriy Gapon wrote: >> Not sure how to interpret this. > > In ohci_controller_init() try to disable the > > DPRINTF("SMM active, request owner change\n"); > > part of the code for !(ohci_unit == 0) or (ohci_unit == 2) and see what > happens. > > Your clue might also indicate that we should request owner change for all > OHCI's before resetting any of them. Possibly a BIOS bug! Haven't tried the suggested changes yet, but here is some more info. This is register dump of ohci0 just _before_ we start doing anything with it: ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: [ITHREAD] ohci_dumpregs:567: ohci_dumpregs: rev=0x00000110 control=0x00000184 command=0x00000000 ohci_dumpregs:571: intrstat=0x00000024 intre=0xc0000042 intrd=0xc0000042 ohci_dumpregs:575: hcca=0xbfdf1f00 percur=0x00000000 ctrlhd=0xbfdf1c50 ohci_dumpregs:579: ctrlcur=0x00000000 bulkhd=0x00000000 bulkcur=0x00000000 ohci_dumpregs:583: done=0xbfdf1ca0 fmival=0x27782edf fmrem=0x000009bd ohci_dumpregs:587: fmnum=0x00008e3a perst=0x00002a27 lsthrs=0x00000628 ohci_dumpregs:591: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:594: port1=0x00000303 port2=0x00000100 ohci_dumpregs:600: HCCA: frame_number=0x0000 done_head=0x00000000 This is dump just after we programmed it: ohci_controller_init:308: rewrite head regs ohci_dumpregs:567: ohci_dumpregs: rev=0x00000110 control=0x000000af command=0x00000000 ohci_dumpregs:571: intrstat=0x00000044 intre=0x8000005a intrd=0x8000005a ohci_dumpregs:575: hcca=0x06647000 percur=0x00000000 ctrlhd=0x06692000 ohci_dumpregs:579: ctrlcur=0x00000000 bulkhd=0x06693000 bulkcur=0x00000000 ohci_dumpregs:583: done=0x00000000 fmival=0xa7782edf fmrem=0x80001096 ohci_dumpregs:587: fmnum=0x0000000d perst=0x00002a2f lsthrs=0x00000628 ohci_dumpregs:591: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:594: port1=0x00010301 port2=0x00000100 ohci_dumpregs:600: HCCA: frame_number=0x000e done_head=0x00000000 This is dump of ohci0 registers just before we run takeover code of ohci1: ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: [ITHREAD] ohci_controller_init:185: reread ohci0 regs: ohci_dumpregs:567: ohci_dumpregs: rev=0x00000110 control=0x000000af command=0x00000000 ohci_dumpregs:571: intrstat=0x00000044 intre=0x8000005a intrd=0x8000005a ohci_dumpregs:575: hcca=0x06647000 percur=0x00000000 ctrlhd=0x06692000 ohci_dumpregs:579: ctrlcur=0x00000000 bulkhd=0x06693000 bulkcur=0x00000000 ohci_dumpregs:583: done=0x00000000 fmival=0xa7782edf fmrem=0x800003b5 ohci_dumpregs:587: fmnum=0x00000012 perst=0x00002a2f lsthrs=0x00000628 ohci_dumpregs:591: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:594: port1=0x00010301 port2=0x00000100 ohci_dumpregs:600: HCCA: frame_number=0x0012 done_head=0x00000000 And this is dump of ohci0 right after we've taken over ohci1: ohci_controller_init:195: SMM active, request owner change ohci_controller_init:219: usbus1: resetting ohci_controller_init:246: reread ohci0 regs: ohci_dumpregs:567: ohci_dumpregs: rev=0x00000110 control=0x000000af command=0x00000000 ohci_dumpregs:571: intrstat=0x00000004 intre=0x8000005a intrd=0x8000005a ohci_dumpregs:575: hcca=0x06647000 percur=0x00000000 ctrlhd=0xbfdf1c50 ohci_dumpregs:579: ctrlcur=0x00000000 bulkhd=0x06693000 bulkcur=0x00000000 ohci_dumpregs:583: done=0xbfdf1ca0 fmival=0xa7782edf fmrem=0x80002122 ohci_dumpregs:587: fmnum=0x00000192 perst=0x00002a2f lsthrs=0x00000628 ohci_dumpregs:591: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:594: port1=0x00000303 port2=0x00000100 ohci_dumpregs:600: HCCA: frame_number=0x0192 done_head=0x00000000 As you can see, indeed, the register gets over-written right when we take over ohci1. Some additional observations: 1. frame_number seems to grow quite a lot for ohci0 2. before we touch ohci0 it has port1=0x00000303, after reset port1=0x00010301, after ohci1 takeover port1=0x00000303 again. I'd say that this is a pretty strong evidence that BIOS does something to ohci0 after we took over it and while we are taking over ohci1. Another idea of working around this: 1) in pci fixup code disable USB SMI for these chipsets 2) (optional) in ohci code skip takeover step Sounds messy. -- Andriy Gapon