ichsmb driver not loading on Intel SE7501CW2 motherboard

[Michael A. Hovan III]

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