Date: Sun, 21 Dec 2003 23:23:32 -0500 From: "Michael A. Hovan III" <mhovan+freebsd@hovan.org> To: freebsd-hardware@freebsd.org Subject: ichsmb driver not loading on Intel SE7501CW2 motherboard Message-ID: <99DB77EE-3436-11D8-941D-0030657E8346@hovan.org>
next in thread | raw e-mail | index | archive | help
Hello, A colleague and I are currently having difficulty building a FreeBSD 4.9 kernel that loads the ichsmb driver on an Intel SE7501CW2 motherboard. There appears to be some sort of problem mapping an interrupt to the device, as illustrated by the following boot message: ichsmb0: <Intel 82801CA (ICH3) SMBus controller> port 0x1100-0x111f irq 0 at device 31.3 on pci0 pci_cfgintr_virgin: using routable interrupt 3 pci_cfgintr: ROUTE_INTERRUPT failed. smbus0: <System Management Bus> on ichsmb0 smb0: <SMBus general purpose I/O> on smbus0 At some point near the end of the boot the console hangs, and the machine is in an unstable condition. When we do not load the ichsmb driver, the boot works fine, but the SMBus (obviously) does not work. As an experiment we built a 5.1 kernel which included the driver and it loaded fine, due to the addition of an ACPI/PCI bus driver in 5.x. We were then able to run utilities which interrogated devices on the system management bus. We are a little hesitant to put 5.x into service in a production environment at this time. So, we would really like to get this working on the 4.x series. The particular goal is to get the fan monitoring info from the Maxim MAX6651 chip that is on this motherboard, which appears to only support an SMBus interface. We have tried this with and without ACPI, with and without APM, and with and without an SMP kernel, and there is no difference. Further info that might be enlightening: When the boot hangs, we are able to ssh into the machine remotely, although the console remains frozen. When we try to run the monitoring utility we wrote, *it actually works* -- we get the correct fan information back from the max6651 chip, through the smbus interface. Even though the interrupt was unassigned, the smbus still worked. However, I did notice that any call to usleep() from a userland program will hang infinitely. Our guess is that this is the reason the boot hangs; one of the startup utilities calls usleep(). Still further info that might be enlightening to kernel folk: This is out of our depth, but on a lark, we found the line of code that printed the "ROUTE_INTERRUPT failed" message, which is in the pci_cfgintr() function in /usr/src/sys/i386/isa/pci_cfgreg.c . It returns 255 to indicate that the interrupt routing failed. If we comment out the "return(255);" line and rebuild the kernel, which causes the value 3 (the interrupt it was trying to route) to get returned, the boot will no longer hang -- but the SMBus now no longer works. Any suggestions on how to make this work, other things we could try, or other debugging information we should look at would be appreciated. Thanks, Mike & Carl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99DB77EE-3436-11D8-941D-0030657E8346>