From owner-freebsd-current@FreeBSD.ORG Sat Jun 14 23:48:36 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 020EF717 for ; Sat, 14 Jun 2014 23:48:36 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D57FB2A2C for ; Sat, 14 Jun 2014 23:48:34 +0000 (UTC) Received: from [192.168.200.105] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id CED671936DE; Sat, 14 Jun 2014 23:48:32 +0000 (UTC) Subject: Re: SMBus controller From: Sean Bruno Reply-To: sbruno@freebsd.org To: Warner Losh In-Reply-To: <6F35309D-FA6D-4882-99A2-57346DFF16B9@gmail.com> References: <1402772923.1120.13.camel@bruno> <1402785781.1106.5.camel@bruno> <6F35309D-FA6D-4882-99A2-57346DFF16B9@gmail.com> Content-Type: text/plain; charset="windows-1251" Date: Sat, 14 Jun 2014 16:48:30 -0700 Message-ID: <1402789710.1106.8.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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: Sat, 14 Jun 2014 23:48:36 -0000 On Sat, 2014-06-14 at 17:25 -0600, Warner Losh wrote: > On Jun 14, 2014, at 4:43 PM, Sean Bruno wrote: > > > On Sat, 2014-06-14 at 12:08 -0700, Sean Bruno wrote: > >> I note that my TLenovo 61 has one of these: > >> > >> ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x20a917aa chip=0x283e8086 > >> rev=0x03 hdr=0x00 > >> vendor = 'Intel Corporation' > >> device = '82801H (ICH8 Family) SMBus Controller' > >> class = serial bus > >> subclass = SMBus > >> > >> > > > > So, there's something broken in the initialization of the driver and the > > driver dependencies here. > > > > If I load "smb.ko" by itself, no other modules are loaded (ichsmb, > > smbus). Should it? > > I don’t think so. If I kldload pci, would you expect most of the drivers in the system to be loaded? > Heck if I know. :-) I would suspect that of the three, ichsmb, smbus or smb, one of these should cause the other two to be loaded. This is not the case. > > If I load ichsmb, smbus is loaded, so that's good. But, the first time > > I do this, the driver seems to think I have 16 bus instances: > > > > > > iicsmb0: on iicbus0 > > iicsmb1: on iicbus1 > > iicsmb2: on iicbus2 > > iicsmb3: on iicbus3 > > iicsmb4: on iicbus4 > > iicsmb5: on iicbus5 > > iicsmb6: on iicbus6 > > iicsmb7: on iicbus7 > > iicsmb8: on iicbus8 > > iicsmb9: on iicbus9 > > iicsmb10: on iicbus10 > > iicsmb11: on iicbus11 > > iicsmb12: on iicbus12 > > iicsmb13: on iicbus13 > > iicsmb14: on iicbus14 > > iicsmb15: on iicbus15 > > smbus0: on iicsmb0 > > smbus1: on iicsmb1 > > smbus2: on iicsmb2 > > smbus3: on iicsmb3 > > smbus4: on iicsmb4 > > smbus5: on iicsmb5 > > smbus6: on iicsmb6 > > smbus7: on iicsmb7 > > smbus8: on iicsmb8 > > smbus9: on iicsmb9 > > smbus10: on iicsmb10 > > smbus11: on iicsmb11 > > smbus12: on iicsmb12 > > smbus13: on iicsmb13 > > smbus14: on iicsmb14 > > smbus15: on iicsmb15 > > > > I then load smb.ko and I get no useful output from smbmsg -p. > > > > If I try to acces /dev/smb1, ctrl-c it, unload all modules and then > > reload them, I get completely different (and functional) behavior. I > > only get ONE smbus and I can poll "devices" there, even though I have no > > idea what they are. > > > > ichsmb0: port 0x1c60-0x1c7f mem > > 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0 > > smbus0: on ichsmb0 > > smb0: on smbus0 > > root@bruno:/home/sbruno # smbmsg -p > > Probing for devices on /dev/smb0: > > Device @0x10: w > > Device @0x88: rw > > Device @0xa8: w > > Device @0xaa: rw > > Device @0xac: rw > > Device @0xae: rw > > Device @0xb8: rw > > Device @0xc2: w > > Device @0xc8: w > > > > > > > > > > > > > > Right ... so, I did the following: > > > > kldload ichsmb > > > > This seems to know to bull in smbus.ko. > > I kinda think that’s a bug. Makes it impossible to load/unload smbus independent of ichsmb. pccard had that issue, but I fixed it eons ago. However, it might be a necessary at the moment bug due to symbols being exported from smbus.ko that are needed btt ichsmb… > > > > ichsmb0: port 0x1c60-0x1c7f mem > > 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0 > > smbus0: on ichsmb0 > > > > > > This doesn't really do anything useful, until I load "smb.ko”: > > That makes sense to me. Again, each of these things is independent, or should be. > > It sounds like there’s other breakage going on. You might want to see what putting it in your kernel tells you. > > Warner Does it make sense that "16" devices are detected until I attempt to access a non existent one, reload the modules and then it seems to work correctly? It looks like something in initialization is hosed. sean