SCSI device not found on an Adaptec AHA-2940U2/U2W and Intel DH87MC motherboard

Author: Peter Apian-Bennewitz, page updated: 23.1.2021
my list of other hardware bits, personal home page

symptom

A Nikon LS1000, 8bit SCSI single ended, is connected with a suitable cable to the external (16bit) port of an Adaptec AHA-2940U2/U2W. The device is listed correctly in the Adaptec Bios SCSI scan menu. Termination and cable length are correct, and the set-up had worked before on Tyan and Fujitsu motherboards, last with Linux Debian 8, 32bit.

After moving to Debian10 64bit on an Intel DH87MC board, the Nikon LS1000 was not seen at all under Linux. This is not a problem with the scan software sane or xsane. The device is missing at low level. Normally it would show up as additional /dev/sdX, with X a suitable number depending on the system.
The usual SCSI-scanning command echo "0 4 0" > /sys/class/scsi_host/host5/scan (with 4 being the SCSI ID of the Nikon and host5 being the SCSI host) resulted in nothing better.
Another specific symptom are lines like scsi 5:0:4:0: tag#175 abort scheduled in the system log.

tests

Checks focussed first on changes in the kernel aic7xxx driver, and possible difference in SCSI setup between Debian8 and Debian10. Turns out that between linux-3.3.x and linux-4.19.xx the driver changed little, apart from some general kernel changes in procfs/sysfs and kmalloc().
Things started to become clear when the LS1000 and Adaptec card got rechecked on a Debian8 system with a different motherboard. Most notable was a kernel message when the SE cable (and therefor the SE terminator) is plugged to the Adaptec. This kernel printk() was missing on the Intel board. The printk() is called from IRQ handler in the aic7xxx driver, which clearly suggested that the PCI interrupt is not working on the Intel DH87MC.

solution: fix PCI interrupt malfunction on Intel motherboard with a Bios upgrade

Upgrading the Intel Bios is not easy, since Intel not only discontinued support (which is somewhat OK), they removed all downloadable Bios images from their website in 2019. Which is fucking bad care for customers, some idiotic idea of pointy hair guy in management, worth a Dilbert cartoon. The board had been purchased in 2013, is a nice piece of well engineered hardware that works otherwise. The only place to get an updated Bios from a some trustworthy source is: https://community.intel.com/t5/Intel-Desktop-Boards/How-to-obtain-download-BIOS-Update-MCH8710H-86A-for-Intel/td-p/731760 .
Turns out that, with MC0164.bio, Intel Bios version 0164 of 2018 replaced 0047 of 2013. Eh voila, the IRQ of the Adaptec PCI card is back and the SCSI bus is usable again.

conclusion

The problem is not specific to the Nikon scanner. Very likely no SCSI device would have worked. So, if your system lists the Adaptec SCSI card (or others) in lspci, but you get mysterious "abort" lines and timeouts in the system log, one reason could be a problem with PCI interrupt handling on the motherboard.
Specifically to the AHA-2940U2/U2W: When hot-plugging a SCSI single-ended device to a running AHA-2940U2/U2W, without other devices, there must be a line Transceiver State Has Changed in the kernel log. If not, something is wrong. The AHA-2940U2/U2W can handle both single-ended and differential SCSI buses, and switches automatically depending on what type of termination it detects. This works with 16bit (wide) or 8bit (legacy) SCSI devices.
All assuming that the Adaptec settings in the Adaptec Bios menu are default, or at least reasonable. Setting "wide negotiation" to "no" for the specific SCSI ID had no influence.

copyright

Peter Apian-Bennewitz, info[AT]pab-opto.de, Text written, Images taken by me.
Copyright GNU_Free_Documentation_License.
Reference to this text is appreciated and mandatory, if content is used elsewhere.
Disclaimer: We're not responsible for the contents of external sites, whose contents may change after we checked and linked to them.


/icos/en-flag.png 
web address of this page: http://www.pab-opto.de?d=/pers/hwtests/intel_DH87MC_Adaptec_2940_problem
Datenschutzerklärung , Impressum
page contents © pab