On Jun 14, 2014, at 5:48 PM, Sean Bruno <sbr...@ignoranthack.me> wrote:

> On Sat, 2014-06-14 at 17:25 -0600, Warner Losh wrote:
>> On Jun 14, 2014, at 4:43 PM, Sean Bruno <sbr...@ignoranthack.me> 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: <SMBus over I2C bridge> on iicbus0
>>> iicsmb1: <SMBus over I2C bridge> on iicbus1
>>> iicsmb2: <SMBus over I2C bridge> on iicbus2
>>> iicsmb3: <SMBus over I2C bridge> on iicbus3
>>> iicsmb4: <SMBus over I2C bridge> on iicbus4
>>> iicsmb5: <SMBus over I2C bridge> on iicbus5
>>> iicsmb6: <SMBus over I2C bridge> on iicbus6
>>> iicsmb7: <SMBus over I2C bridge> on iicbus7
>>> iicsmb8: <SMBus over I2C bridge> on iicbus8
>>> iicsmb9: <SMBus over I2C bridge> on iicbus9
>>> iicsmb10: <SMBus over I2C bridge> on iicbus10
>>> iicsmb11: <SMBus over I2C bridge> on iicbus11
>>> iicsmb12: <SMBus over I2C bridge> on iicbus12
>>> iicsmb13: <SMBus over I2C bridge> on iicbus13
>>> iicsmb14: <SMBus over I2C bridge> on iicbus14
>>> iicsmb15: <SMBus over I2C bridge> on iicbus15
>>> smbus0: <System Management Bus> on iicsmb0
>>> smbus1: <System Management Bus> on iicsmb1
>>> smbus2: <System Management Bus> on iicsmb2
>>> smbus3: <System Management Bus> on iicsmb3
>>> smbus4: <System Management Bus> on iicsmb4
>>> smbus5: <System Management Bus> on iicsmb5
>>> smbus6: <System Management Bus> on iicsmb6
>>> smbus7: <System Management Bus> on iicsmb7
>>> smbus8: <System Management Bus> on iicsmb8
>>> smbus9: <System Management Bus> on iicsmb9
>>> smbus10: <System Management Bus> on iicsmb10
>>> smbus11: <System Management Bus> on iicsmb11
>>> smbus12: <System Management Bus> on iicsmb12
>>> smbus13: <System Management Bus> on iicsmb13
>>> smbus14: <System Management Bus> on iicsmb14
>>> smbus15: <System Management Bus> 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: <Intel 82801H (ICH8) SMBus controller> port 0x1c60-0x1c7f mem
>>> 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0
>>> smbus0: <System Management Bus> on ichsmb0
>>> smb0: <SMBus generic I/O> 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: <Intel 82801H (ICH8) SMBus controller> port 0x1c60-0x1c7f mem
>>> 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0
>>> smbus0: <System Management Bus> 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.

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’s pure speculation on my 


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to