Asus hides the SMBus PCI bridge within the ICH2 or ICH4 southbridge on Asus P4B533/P4PE mainboards. So ichsmb driver doesn't detects SMB bus. Fix: There are linux patch. See http://www.cs.helsinki.fi/linux/linux-kernel/2003-11/0868.html for details. How-To-Repeat: Include device smbus device ichsmb device smb to the kernel config file, recompile kernel and reboot. New kernel will not detects SMB bus. pciconf -lv will not list it too.
Attached is a patch against -CURRENT that solves this issue by enabling the i801 SMBus when the bus is scanned.
I successfully applied this patch to RELENG_5_2, but there was the compile error at fixup_pci.c. The problem was solved after adding line "#include <dev/pci/fixup_pci.h>" to it. With new kernel SMBus was detected and seems to be working. But, smbus got irq4 and i lost my sio0. :( ... Feb 9 20:59:12 bsd kernel: [-] pmccfg: 49 Feb 9 20:59:12 bsd kernel: Enabled Intel 801SMBus Feb 9 20:59:12 bsd kernel: pci_cfgintr: 0:31 INTA BIOS irq 9 Feb 9 20:59:12 bsd kernel: pci_cfgintr: 0:31 INTB BIOS irq 9 ... Feb 9 20:59:12 bsd kernel: ichsmb0: <Intel 82801DC (ICH4) SMBus controller> port 0xe800-0xe81f at device 31.3 on pci0 Feb 9 20:59:12 bsd kernel: pci_cfgintr: 0:31 INTB routed to irq 4 ^^^^^^^^^^^^^^^^^^^^ Feb 9 20:59:12 bsd kernel: smbus0: <System Management Bus> on ichsmb0 Feb 9 20:59:12 bsd kernel: smb0: <SMBus generic I/O> on smbus0 ... Feb 9 20:59:12 bsd kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^ Feb 9 20:59:12 bsd kernel: sio0: port may not be enabled Feb 9 20:59:12 bsd kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Feb 9 20:59:12 bsd kernel: sio0: type 16550A Feb 9 20:59:12 bsd kernel: sio1 at port 0x2f8-0x2ff irq 3 on isa0 Feb 9 20:59:12 bsd kernel: sio1: type 16550A ... Can this problem to be solved? Will this patch commited to RELENG_5_2? Alexander Zagrebin --
On Tue, 10 Feb 2004, Alexander Zagrebin wrote: > I successfully applied this patch to RELENG_5_2, > but there was the compile error at fixup_pci.c. > The problem was solved after adding line "#include <dev/pci/fixup_pci.h>" to > it. > With new kernel SMBus was detected and seems to be working. > But, smbus got irq4 and i lost my sio0. :( > > ... > Feb 9 20:59:12 bsd kernel: [-] pmccfg: 49 > Feb 9 20:59:12 bsd kernel: Enabled Intel 801SMBus > Feb 9 20:59:12 bsd kernel: pci_cfgintr: 0:31 INTA BIOS irq 9 > Feb 9 20:59:12 bsd kernel: pci_cfgintr: 0:31 INTB BIOS irq 9 > ... > Feb 9 20:59:12 bsd kernel: ichsmb0: <Intel 82801DC (ICH4) SMBus controller> > port 0xe800-0xe81f at device 31.3 on pci0 > Feb 9 20:59:12 bsd kernel: pci_cfgintr: 0:31 INTB routed to irq 4 > ^^^^^^^^^^^^^^^^^^^^ sio0 on irq4 should still work. > Feb 9 20:59:12 bsd kernel: smbus0: <System Management Bus> on ichsmb0 > Feb 9 20:59:12 bsd kernel: smb0: <SMBus generic I/O> on smbus0 > ... > Feb 9 20:59:12 bsd kernel: sio0: configured irq 4 not in bitmap of probed > irqs 0 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^ This message can be ignored if you know that irq 4 is correct. Old versions used to fail here, but that is not quite right because it is possible for the irq to work despite the test for it failing here. > Feb 9 20:59:12 bsd kernel: sio0: port may not be enabled This message is just a normally-usless hint about why the previous message was printed. > Feb 9 20:59:12 bsd kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on > isa0 Since you didn't get the message "sio0: unable to activate interrupt in fast mode - using normal mode", sio0 has apparently been attached first and subsequent attachment of ichsmb should fail because sio has set up the interrupt in fast mode so it is unavailable in the normal mode that ichsmb wants. If it actually succeeds, then there is a bug in the interrupt attachment (larger than the unimplemented details that prevent changing the sio interrupt's mode after attach time), and the bug could easily break delivery of interrupts too. Things should work better if ichsmb is attached first. I don't know how to force this except by making sio a module. Bruce
State Changed From-To: open->feedback Hello is this still a problem in more recent versiosn of FreeBSD ? (6.1 for example)
Responsible Changed From-To: freebsd-i386->remko grab the PR
State Changed From-To: feedback->closed Feedback timeout since 2006.
Hey, this bug still present in 7.2-STABLE. I have Asus P4PE m/b and it's annoying :-)