From owner-freebsd-current@FreeBSD.ORG Sun Jun 15 01:49:48 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 63FD928F for ; Sun, 15 Jun 2014 01:49:48 +0000 (UTC) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2901E21F0 for ; Sun, 15 Jun 2014 01:49:47 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id h18so1738806igc.16 for ; Sat, 14 Jun 2014 18:49:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=2z/qn6ANRbUkXdTSWSulovHYAKyjlSnMjIxFTvqxygE=; b=SBajHQqt6QLM2r1/LnZVq4wh+Yy7RhvN1r7zQdc2i7EWtlKE6H+eonSN588ogmHV1t /GX8E9C/aQWh4AH19UObTSvMdvxo+1eSXUT1bs1aZ0WSwGmoFI4zU0sU40O+Bp3QzuIo IL8eQEaKlUZEiWJQfuEir3UxYt4bOna8XEP7Cuv72mM7IzsgSj7HtUWdm+Gfza46K55Z m76zUBMeocnYefTrb8aG9PasBuuxqbXrjKs1ylgkuOYjWkQ1sa9I8+Az6mvOjfxEzXHm ix/5CS3sCfsp4GABAcrkOTDNDhGYUsV0CuwrYVy7BXZOKqmD6oIzyFS/LTJNN9D+X5yc KFDw== X-Gm-Message-State: ALoCoQkmyMKx+9lyGzFmSfCRpJqLSwBhtjm0SfZbm6eJ4XPoMOAcNwSQsuzNHL1c+exYpuWHhx6Q X-Received: by 10.43.65.145 with SMTP id xm17mr12276804icb.44.1402796564715; Sat, 14 Jun 2014 18:42:44 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id p12sm8185902igx.18.2014.06.14.18.42.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Jun 2014 18:42:43 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_43160D4C-7DD3-4185-BD86-4DAA22965AEB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: SMBus controller From: Warner Losh In-Reply-To: <1402789710.1106.8.camel@bruno> Date: Sat, 14 Jun 2014 19:42:48 -0600 Message-Id: References: <1402772923.1120.13.camel@bruno> <1402785781.1106.5.camel@bruno> <6F35309D-FA6D-4882-99A2-57346DFF16B9@gmail.com> <1402789710.1106.8.camel@bruno> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1878.2) 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: Sun, 15 Jun 2014 01:49:48 -0000 --Apple-Mail=_43160D4C-7DD3-4185-BD86-4DAA22965AEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1251 On Jun 14, 2014, at 5:48 PM, Sean Bruno wrote: > On Sat, 2014-06-14 at 17:25 -0600, Warner Losh wrote: >> On Jun 14, 2014, at 4:43 PM, Sean Bruno = wrote: >>=20 >>> On Sat, 2014-06-14 at 12:08 -0700, Sean Bruno wrote:=20 >>>> I note that my TLenovo 61 has one of these: >>>>=20 >>>> ichsmb0@pci0:0:31:3: class=3D0x0c0500 card=3D0x20a917aa = chip=3D0x283e8086 >>>> rev=3D0x03 hdr=3D0x00 >>>> vendor =3D 'Intel Corporation' >>>> device =3D '82801H (ICH8 Family) SMBus Controller' >>>> class =3D serial bus >>>> subclass =3D SMBus >>>>=20 >>>>=20 >>>=20 >>> So, there's something broken in the initialization of the driver and = the >>> driver dependencies here. >>>=20 >>> If I load "smb.ko" by itself, no other modules are loaded (ichsmb, >>> smbus). Should it? >>=20 >> I don=92t think so. If I kldload pci, would you expect most of the = drivers in the system to be loaded? >>=20 >=20 > Heck if I know. :-) =20 >=20 > 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. >=20 >>> 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: >>>=20 >>>=20 >>> 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 >>>=20 >>> I then load smb.ko and I get no useful output from smbmsg -p. >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Right ... so, I did the following: >>>=20 >>> kldload ichsmb >>>=20 >>> This seems to know to bull in smbus.ko. >>=20 >> I kinda think that=92s 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=85 >>=20 >>=20 >>> ichsmb0: port 0x1c60-0x1c7f = mem >>> 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0 >>> smbus0: on ichsmb0 >>>=20 >>>=20 >>> This doesn't really do anything useful, until I load "smb.ko=94: >>=20 >> That makes sense to me. Again, each of these things is independent, = or should be. >>=20 >> It sounds like there=92s other breakage going on. You might want to = see what putting it in your kernel tells you. >>=20 >> Warner >=20 >=20 > 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. It does look hosed. I think that the code may assume bios interference = that we need to do if we get a nonsensical result. But that=92s pure = speculation on my part=85 Warner --Apple-Mail=_43160D4C-7DD3-4185-BD86-4DAA22965AEB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTnPoYAAoJEGwc0Sh9sBEAe2oQALDyfkIj9YF/Kedmg5379y1Y sPZBLx/8aeBMWYX51Cl/dI9BUuW0uo/9w49mgQFNy4sw9yln+6Im+AOikcXS6EX5 IeQUAXlSRWiGYbSRc6O7hE1pnxGofO9tNy7MMI4c+S4BtxkFcFXk297ZPPCey3Rb 9m17EVbPm//oaUIc0JygcHOHEIvQhluwIlo8SV9U38AJkqatLg0JMIbwwRvoI14f DOuUSYWNAxg7KH1LNre0yziX2zRgG5aaJ35J20VlgIpiK3A5IBg73pQYLJtqsP4m COIaeTfyMULnJnywhaJFif7M/wF2IeV8SkiBt35YT76B1mW6MxnUHDoJNe4c2zpz J6OEdFH824nHyCyP+3hqUWDANAkXt12GqmUCIODluzLHdVm8kksSBzlAienFXuGc P/xyNrCO5bvMO7amACyKbP0Aich27ezM2+XaMDqqXn9FNpwf4TYz5mXEhT1i84ti D3jLpaMEEYgWpwrfzOPLpUGibi9sVDoe4VBAf+xw3S+9PQJIpEpssBqKIZx9ou7s rtDxEVlrOP/Jg1Ie3LTGt6dpRrqiOKBXqOjpfqkTLaEpmjmM21daQQ5RIcZyGJuC MgEwIZas6R0Q1c8u5XzpkHtuRMPegjxH5ycuadHTI2/zSP1WXG+Fk3pbY89eRSJV HWAIbOJWsSaow0JmwEnu =afjS -----END PGP SIGNATURE----- --Apple-Mail=_43160D4C-7DD3-4185-BD86-4DAA22965AEB--