Description of problem: on a Dell PowerEdge 2950 I am using the Centos 5.x packages for x86_64 powered by the OpenVZ kernels. After the last update to the (as of Centos 5.2) latest kernel 2.6.18-92.1.1.el5.028stab057.2 I got alerted by the same kernel ERROR messages shown in the dmesg output: .... Fusion MPT base driver 3.04.05 Copyright (c) 1999-2007 LSI Corporation Fusion MPT misc device (ioctl) driver 3.04.05 mptctl: Registered with Fusion MPT base driver mptctl: /dev/mptctl @ (major,minor=10,220) mptctldrivers/message/fusion/mptctl.c::mptctl_ioctl() @596 - ioc0 not found! mptctldrivers/message/fusion/mptctl.c::mptctl_ioctl() @596 - ioc1 not found! mptctldrivers/message/fusion/mptctl.c::mptctl_ioctl() @596 - ioc2 not found! ... ... Version-Release number of selected component (if applicable): Linux RHEL 2.6.18-92.1.1.el5 How reproducible: boot the kernel on a Dell2950 ... look into the output of 'dmesg' ... OR you can reproduce these lines from mptctldrivers by doing a /usr/bin/srvadmin-services.sh restart srvadmin-services.sh is part of the Dell Server Management software (Vers-5.2_rev-A00_Apr-2007 for the PowerEdge 2950; to be installed optionally). Steps to Reproduce: 1. 2. 3. Actual results: the Fusion MPT base driver 3.04.05 in/from kernel 2.6.18-92.1.1.el5 is very, very verbose Expected results: the 5.1 kernel 2.6.18-53.1.6.el5 (comes with Fusion MPT base driver 3.04.04) is NOT that verbose Additional info: please read my contribution to a corresponding thread (includes my steps to comment the all too verbose printk() statement in mptctl.c) on: http://www.centos.org/modules/newbb/viewtopic.php?topic_id=15010&start=0#forumpost59603
What is calling these ioctls? The messages you are seeing are just the driver complaining that something in userspace gave an ioctl command or adapter that does not exist. Better to fix that thing to not call these ioctls in the first place.
Do you have some tool called RAIDwatcher / mptscsi-utils installed?
So, it seems like this is the result of the userspace mptscsi tools attempting to enumerate the controllers on the system (it'll call an ioctl on each one in turn, presumably ignoring any that fail). For e.g.: mptctldrivers/message/fusion/mptctl.c::mptctl_ioctl() @596 - ioc1 not found! mptctldrivers/message/fusion/mptctl.c::mptctl_ioctl() @596 - ioc2 not found! mptctldrivers/message/fusion/mptctl.c::mptctl_ioctl() @596 - ioc3 not found! mptctldrivers/message/fusion/mptctl.c::mptctl_ioctl() @596 - ioc4 not found! mptctldrivers/message/fusion/mptctl.c::mptctl_ioctl() @596 - ioc5 not found! mptctldrivers/message/fusion/mptctl.c::mptctl_ioctl() @596 - ioc6 not found! mptctldrivers/message/fusion/mptctl.c::mptctl_ioctl() @596 - ioc7 not found! mptctldrivers/message/fusion/mptctl.c::mptctl_ioctl() @596 - ioc8 not found! Etc. etc. This is presumably a system with one adapter (all controllers > ioc0 are logging an error). I'm guessing that the driver/utility are designed to work this way, so it's expected that the tool will call a bunch of ioctls for devices that don't exist. This seems to be a regression introduced upstream with this patch: commit 09120a8cd38dbdb0c9a59ff8456cf88b510e6baa Author: Prakash, Sathya <sathya.prakash> Date: Tue Jul 24 15:49:05 2007 +0530 [SCSI] mpt fusion: Changes in mptctl.c for logging support This patch contains changes in mptctl.c to support logging in MPT fusion drivers The changes are majorly in debug printks, the existing debugprintk are modified accroding to new debug macros defined in the file mptbdebug.h signed-off-by: Sathya Prakash <sathya.prakash> Signed-off-by: James Bottomley <James.Bottomley> This converts the dctlprintk into a regular KERN_DEBUG printk: - dctlprintk((KERN_ERR "%s::mptctl_ioctl() @%d - ioc%d not found!\n", - __FILE__, __LINE__, iocnumX)); + printk(KERN_DEBUG "%s::mptctl_ioctl() @%d - ioc%d not found!\n", + __FILE__, __LINE__, iocnumX); It doesn't seem like it was the intent of this patch to change the behaviour and make the ioctl debug messages more verbose by default. The dctlprintk macro is still defined in mptdebug.h in current git and is used widely in mptctl.c - seems like this case could benefit from being reverted to use the debug macro again.
Johann, My apologies for closing this bug without giving you an update as to why. We had support ticket matching this bug which was closed and so the bug was closed as well. It's been pointed out to me that this issue still very much is valid. I'm going to keep this ticket open as you continue to work with upstream. Just continue to keep us informed of your progress. Also, I might suggest reaching out to our production support team in connection with this bug, so as to get additional visibility here within Red Hat. Thanks Jeremy West
Everyone. I agree we need to revert back this. We need to keep this less verbose as these messages are annoying. We have patched our internal driver versions to be less verbose. Will check and if the upstream versions are not patched we will submit the patch to revert back to dctlprintk. Please consider changing this behavior in the Redhat inbox drivers. Will update the patch details here once it is submitted to upstream. Thanks Sathya
Created attachment 367650 [details] mptctl patch This patch should solve the issue. I believe it already has been committed in RHEL5.4, so I'm closing this for now. If I'm wrong please reopen this bz.