i386/100142: /dev/smb0 device not available on systems with Intel PiiX4

[Arthur Hartwig]

Thanks for your suggestion. However your data is from a different SMB
driver (ichsmb) than the one for which I reported the problem (intsmb).
I don't have the problem I reported on a ICH7 based system.

Arthur

ext Intron wrote:
> Arthur Hartwig wrote:
>
>>
>>> Number: 100142
>>> Category: i386
>>> Synopsis: /dev/smb0 device not available on systems with Intel PiiX4
>>> Confidential: no
>>> Severity: non-critical
>>> Priority: medium
>>> Responsible: freebsd-i386
>>> State: open
>>> Quarter: Keywords: Date-Required:
>>> Class: sw-bug
>>> Submitter-Id: current-users
>>> Arrival-Date: Wed Jul 12 05:10:14 GMT 2006
>>> Closed-Date:
>>> Last-Modified:
>>> Originator: Arthur Hartwig
>>> Release: 6.0
>>> Organization:
>> Nokia
>>> Environment:
>> FreeBSD oz-net-10.nes.nokia.com 6.0-RELEASE FreeBSD 6.0-RELEASE #3:
>> Wed Mar 1 10:46:02 EST 2006
>> hartwig at oz-net-10.nes.nokia.com:/usr/src/sys/i386/compile/oz-net-10 i386
>>> Description:
>> System configured with devices intppm, smbb and smbus.
>>
>> On startup smbus1 is reported but no smbus0 is reported. There is no
>> file /dev/smb0
>>
>> In sys/pci/intpm.c intpm_attach() executes smbinterface =
>> device_add_child(dev, ""intsmb", unit);
>> device_probe_and_attach(smbinterface);
>>
>> device_probe_and_attach() calls device_probe_child() which ends us
>> calling intsmb_probe() twice, once when search for the best matching
>> driver and again, because intsmb_probe() returns BUS_PROBE_DEFAULT,
>> immediately after the comment "Call the probe method again to make
>> sure we have the right description."
>>
>> Calling intsmb_probe() twice results in creation of devices smbus0
>> (on the first call to intsmb_probe) and smbus1 (on the second call to
>> intsmb_probe). The second probe call results in When intsmb_attach(0
>> is called, sc->smbus contains a pointer to a device structure for
>> smbus1 and consequently smbus1 is reported in the startup.
>>
>>
>>> How-To-Repeat:
>>
>>> Fix:
>> Suggested fix:
>> In sys/pci/intpm move
>> sc->smbus=device_add_child(dev, "smbus", -1);
>> if (!sc->smbus)
>> return (EINVAL); /* XXX don't know what to return else */
>>
>> from intsmb_probe() to intsmb_attach()
>>
>> The suggested fix mirrors more closely the code in sys/pci/viapm.c
>> and sys/pci/amdpm.c
>>
>>
>>
>>> Release-Note:
>>> Audit-Trail:
>>> Unformatted:
>> _______________________________________________
>> freebsd-i386 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-i386
>> To unsubscribe, send any mail to "freebsd-i386-unsubscribe at freebsd.org"
>
> Please try the following commands:
>
> kldload smbus
> kldload ichsmb
> kldload smb
>
> Then, I can access SMBUS via /dev/smb0.
> The kernel messages are:
>
> ichsmb0: <SMBus controller> port 0xc400-0xc41f irq 19 at device 31.3
> on pci0
> ichsmb0: [GIANT-LOCKED]
> smbus0: <System Management Bus> on ichsmb0
> smb0: <SMBus generic I/O> on smbus0
>
> The chipset on my motherboard is Intel 82915G-82801FB(ICH6).
>
> ------------------------------------------------------------------------
> From Beijing, China
>