RE: [Bugme-new] [Bug 9752] New: getting FAULT code message at startup in mpt fusion scsi driver
On Tuesday, January 15, 2008 1:37 PM, Andrew Morton wrote: On blade startup we're seeing the following message: Fusion MPT base driver 3.02.55 Copyright (c) 1999-2005 LSI Logic Corporation Fusion MPT SAS Host driver 3.02.55 mptbase: Initiating ioc0 bringup mptbase: ioc0: WARNING - IOC is in FAULT state!!! FAULT code = 1804h mptbase: ioc0: ERROR - Failed to come READY after reset! IocState=0 mptbase: ioc0 NOT READY WARNING! mptbase: WARNING - ioc0 did not initialize properly! (-1) mptsas: probe of :05:01.0 failed with error -1 What is happening is while the driver loading, the controller is in FAULT_STATE, and we are unable to recover. The FAULT_CODE = (0x1804) = IFAULT_IOP_SELFTEST_FAILED_TIMER, means Timer Failure. I suggest this customer try contacting LSI support channels. More than likely a firmware upgrade might fix this issue. I really doubt its a driver issue. The channel support email id is [EMAIL PROTECTED] There maybe a Notrel Product Marketing account manager, but I'm not for sure. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: MPT Fusion initialization in 2.6.23.12
On Friday, January 11, 2008 7:01 AM, Karen Shaeffer wrote: mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=000Fh I've traced through the mptbase.c code and can see these invalid config pages are read from the controller during initialization. This doesn't appear to cause any ill effects, but I am wondering how to resolve this? Maybe a MPT BIOS or MPT firmware upgrade will fix this? Karen - this is not an error. The driver present the sas topology to the transport layer. It does so by scaning firmware config pages by passing XXX_FORM_GET_NEXT_HANDLE. When there are no more devices, the firmware returns Invalid Page. This applies for expanders as well. I actually thought his particular print was only displayed by toggling debug logging, meaning by default settings, this would not apear. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: MPT Fusion initialization in 2.6.23.12
On Monday, January 14, 2008 5:42 PM, Grant Grundler wrote: mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=0001h My interpretation of this (and Eric should know this alot better) is the host is attempting to read (action=01h) this page (type 08h == MPI_CONFIG_PAGETYPE_RAID_VOLUME) and couldn't. ie maybe HW RAID isn't configured on the card? Grant - Your right that this is MPI_CONFIG_PAGETYPE_RAID_VOLUME(=0x8). I responded too soon earlier, my thinking it was scanning the sas topology, in which its expected to get Invalid pages. In previous email, the form being passed (1 thru 0xF) means someone is scaning the target ids, from 1 thru 15. I just checked my code, and there is no place where I scan volumes. The only place I ask for the volume pages, is in mpt_inactive_raid_volume, and I only ask for this page when I already know the target_id. Thus I think this must be application driven thru mptctl interface. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: reproducible DV to the wrong device (fusion)
On Wednesday, January 02, 2008 11:54 AM, Bernd Schubert wrote: I complained about this before, but always got ignored. Please not this time. Sorry, I didn't see your email before today. On IOC0 there is 2:0:4:0 and on IOC1 there is 3:0:13:0 and 3:0:14:0. pfs1n14-m:~# /tmp/scsiadd -a 2 0 4 0 [ 2595.405276] scsi 2:0:4:0: Activating scsi error recovery [ 2595.405711] mptbase: ioc0: LogInfo(0x11010400): F/W: bug! MID not found MID = means the firmware was unable to locate the proper message id associated to some request when completing some command. Apparently the command never completed back to driver, and eh threads were woken. The MID might be fixed by a firmware upgrade. Do you know which version you have? It will be provided in the banner when the driver loads. I already tried echo -1 /proc/sys/dev/scsi/logging_level, but this doesn't reveal anything. Please, we really need to fix this, as this is really troublesome in production situation. Some hints for further debugging should be suffienct for now. If your using a linux kernel that was released since last summer, I now provide logging support in the driver which can be enabled/disabled via sysfs attributes and command line option. I will send you documentation in seperate private email. Some info of this provided in mptdebug.h in the source code. For domain validation, you need to enable the MPT_DEBUG_DV bits. Also CONFIG_FUSION_LOGGING needs to be enabled in the kernel config, and set your kernel logging level for klogd to 7 (or KERN_DEBUG). Example insmod mptbase.ko mpt_debug_level=0x200 or echo 0x200 /sys/class/scsi_host/host0/debug_level - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Problems with LSI MegaRaid 1068e
On Wednesday, December 26, 2007 12:39 PM, Cory Visi wrote: To whom it may concern: I am working with a SuperMicro Super Server AS2020A-8RB with an integrated LSI MegaRaid 1068e (Firmware M1068e.01.08221427R). The configuation uses 3x 73 GB SAS drives in a RAID 5 configuration (using the RAID key). MegaRAID != Fusion Please contact the MegaRAID team. I guess it will be either Sreenivas Bagalkote([EMAIL PROTECTED]) or Sumant Patro([EMAIL PROTECTED]). Their contact info should be available in the MAINTAINERS file in the top folder of the kernel source tree. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: MPTSAS Driver and scatter gather lists
On Tuesday, December 04, 2007 8:45 AM, Steven Pratt wrote: Also, is there any reason we can't increase sg_tablesize for mptsas? The default 128, set in Kconfig (look at FUSION_MAX_SGE).It only set to 40 when that is not defined. What is in your kernel .config, e.g look for CONFIG_FUSION_MAX_SGE. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: how to handle QUEUE_FULL/SAM_STAT_TASK_SET_FULL in userspace?
On Thursday, November 15, 2007 12:44 PM, James Smart wrote: The midlayer doesn't do this automatically. The LLDD has to note the QUEUE_FULL/TASK_SET_FULL status, then call scsi_adjust_queue_depth() to manipulate things. And this gets really hairy to decrease load, then ramp back up. yeah I need to do that, but the customer should do it via sysfs, as I previously noted, he is on 2.6.14 kernel. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: how to handle QUEUE_FULL/SAM_STAT_TASK_SET_FULL in userspace?
On Wednesday, November 14, 2007 10:23 AM, Chris Friesen wrote: QUEUE_FULL and SAM_STAT_TASK_SET_FULL are not errors. I consider them errors in the same way that ENOMEM or ENOBUFS (or even EAGAIN) are errors. There is a shortage of resources and the command could not be completed, please try again later. Also, the behaviour has changed from 2.6.10 with the 3.01.18 fusion driver, to 2.6.14 with the 3.02.57 fusion driver. With 2.6.10 our user app never saw SAM_STAT_TASK_SET_FULL. I suspect it is due to the fact that it's using a queue size of 7, while in 2.6.14 it's using a queue size of 32 or 64. Which kernel version is behaving properly? You already figured out the problem, I don't understand why your asking if the kernel verison is behaving properly. You said between those driver versions the device queue depth increased from 32 to 64, and that is exactly what happened. The reason for the increase is some customer ask for the increase queue_depth which helps with performance. We are not going to decrease it back. I've asked seagate what the queue size should be for that hardware, but haven't heard back yet. SAM_STAT_TASK_SET_FULL returned for the target that handle the number of commands, and QUEUE_FULL returned from hba firmware meaning its can't handle the number of commands. Translated, the commands are retried by scsiml.I probably should be calling scsi_track_queue_full which would be throttling the command back, however I'm not sure whether it matters. We have a userspace app calling ioctl(...SG_IO...) on /dev/sdX and occasionally getting a status of SAM_STAT_TASK_SET_FULL. I may be misreading the code, but it doesn't appear that the midlayer is retrying these commands. If the queue length in 2.6.14 is correct then how do I handle that status code? Maybe delay a bit then retry a few times? How much delay? How many retries? SAM_STAT_TASK_SET_FULL in /usr/src/linux/scsi/scsi.h, is the same as QUEUE_FULL. If you look in scsi_error.c searching for QUEUE_FULL, you will see that it will translate to ADD_TO_MLQUEUE, which means it will reposted to the request queue. Ultimately, calling scsi_track_queue_full would help by reducing the queue_depth on the fly, however I'm not sure if that is there in the older kernels your running. What I suggest you do is write a script to update the queue_depth to the values youre wanting. Example # echo 32 /sys/class/scsi_device/0:0:0:0/device/queue_depth - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: LSIFC909 problem
On Sunday, October 21, 2007 1:34 AM, egi wrote:
Since kenel 2.6.8 my system doesn't regonize any more my FC-drives.
I installed latest kernel 2.6.23-git7 incl patch but no chance.
I get the following message during the boot:
Oct 21 08:57:06 localhost kernel: Fusion MPT base driver 3.04.05
Oct 21 08:57:06 localhost kernel: Copyright (c) 1999-2007 LSI Logic
Corporation
Oct 21 08:57:06 localhost kernel: Fusion MPT FC Host driver 3.04.05
Oct 21 08:57:06 localhost kernel: mptbase: Initiating ioc0 bringup
Oct 21 08:57:06 localhost kernel: ioc0: LSIFC909 B1:
Capabilities={Initiator,LAN}
Oct 21 08:57:06 localhost kernel: mptbase: ioc0: IOCStatus(0x0022):
Config Page Invalid Page: type=00h, page=02h, action=00h,
form=h
Oct 21 08:57:06 localhost kernel: mptbase: ioc0: IOCStatus(0x0022):
Config Page Invalid Page: type=09h, page=00h, action=00h,
form=h
Oct 21 08:57:06 localhost kernel: scsi0 : ioc0: LSIFC909 B1,
FwRev=0100h, Ports=1, MaxQ=1023, IRQ=21
modules:
Sorry for delayed repsonse, but the FC909 is not supported anymore. I
need to suppy a patch to remove this support. Here is feedback from
Micheal Reed. About a two years ago the mptfc was rewrote to support
the fibre channel transport layer.
Micheal Reed wrote:
Looking at the 2.6.5 sles9 driver, I see that the WWNN and WWPN values
are still read from fc device page 0, given a channel and id as
input. The channel and id, which I equate to bus and target,
are discovered the old fasioned way, by probing every possible target on
the bus to see which respond. This is done by a call to
scsi_scan_host().
The new transport code definitely does it differently, by reading fc
device page 0, passing in the port_id of the previous port to retrieve
data for the next port, and registering the discovered targets with the
fc transport.
In the new code, the sorting of the targets won't work, which isn't a
showstopper.
The CurrentTargetID and CurrentBus values are taken from fc device page
0 and placed in the VirtTarget structure, so this is the cause for
concern. This VirtTarget structure is stored in the scsi_target's
hostdata field and is used to map the fc transport's target id to the
firmware's target id.
The 909 doesn't offer the needed functionality to support usage of the
fc transport.
If the firmware accepted commands for a target via its port id instead
of bus/target there might be a way around this, but, that would be a lot
of design effort for not a lot of return, even if it were possible.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 16/17] mptbase: reset ioc initiator during PCI resume
On Tuesday, October 02, 2007 5:06 PM, Darrick J. Wong wrote: Yep. Replied to it, too. Apparently it never got to you, so I've attached it below. Sorry, I didn't receive the previous email you sent. - On Thu, Sep 20, 2007 at 07:06:35PM -0600, Moore, Eric wrote: Darrick - MESSAGE_UNIT_RESET is already issued from inside mpt_do_ioc_recovery(), so you don't need to send this in advance of that.YOu will find that occuring from the function MakeIocReady. Anyways... would it be possible for you to enable debug logging so I can see what problem your having? I suggest MPT_DEBUG and MPT_DEBUG_INIT. If its possible for you to manually load mptbase, that way you can set the command line option. I took a look at MakeIocReady(), and this section caught my eye: /* Is it already READY? */ if (!statefault (ioc_state MPI_IOC_STATE_MASK) == MPI_IOC_STATE_READY) return 0; Yes, the purpose of MakeIocReady is to get the card in READY state. If your already in READY state, there is no reason to continue in MakeIocReady. A MESSAGE_UNIT_RESET places the card into READY state. You will see that we already issued MESSAGE_UNIT_RESET from mptbase_suspend. So it should be in READY state coming into mptbase_resume, depending on which power state you transferred to from suspend.The code you added in this patch is not required, meaning we dont need to send MESSAGE_UNIT_RESET prior to ioc_do_recovery, becuase from MakeIocReady will issue a MESSAGE_UNIT_RESET if your not already in READY.I suspect there must be something else going on if you have to issue MESSAGE_UNIT_RESET when your already in READY state. My card works fine without your patch. I did the following: # echo standby /sys/power/state There could be issues in the firmware your using. I noticed FwRev=00060200h in the log,, which is 6.02, and over a year old. I will send out a seperate email which I will copy you to the IBM system engineer support here at LSI, should be able to assist on this issue. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 16/17] mptbase: reset ioc initiator during PCI resume
On Tuesday, October 02, 2007 3:38 PM, Darrick J. Wong wrote: It appears that the LSI SAS 1064E chip needs to be reset after a suspend/resume cycle before the driver attempts further communications with the chip. Without this patch, resuming the chip results in this error message being printed repeatedly and no more disk I/O. mptbase: ioc0: ERROR - Invalid IOC facts reply, msgLength=0 offsetof=6! So far it seems to fix suspend/resume on all the MPT Fusion cards I have (SAS and U320 SCSI) but since I don't know the internals of that chip I can't say for sure if this is a proper fix. I replied to this thread a couple times last week, and no response from Darrick. I doubt this is required becase the MESSAGE_UNIT_RESET is issued from inside mpt_do_ioc_recovery. I need some logs with debug enabled. Darrick did you see my email? Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Some plans for scsi_cmnd
On Tuesday, September 25, 2007 7:38 AM, Matthew Wilcox wrote: As I said, it's ambitious. But it'll let us get rid of scsi_pointer and host_scribble entirely. Are you serious about removing the host_scribble? In fusion we currently are hanging our per request message frame pointer there. Its used for two reasons: (1) Old fibre channel firmware bug. The bug is the same message frame completed twice. 1st completion is okay and the scsi_cmd is reallocated to some other IO. Meanwhile the driver receives a double completion of the same message frame, and the driver attempts to complete the reallocated scsi_cmd to some other IO. The sanity check on host_scribble avoids this. (2) error recovery threads decides to complete a scsi_cmd before its been returned back by the scsi lld, and the scsi_cmd is reused for some other IO. Meanwhile fusion firmware finally decides it wants to command the command, then the driver is completing the reallocated scsi_cmd that is mapped to some other IO. Again, host_scribble sanity check makes sure we finish off the scsi_cmd that its intended for. Thus said, someone upgrades to newer FC firmware, they will not have issue #1. Regarding issue #2, if eh threads allow scsi lld to cleanup ts own scsi cmds, then we shouldn't need this. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/9] mpt fusion: error recovery improvements,andsynchronizing internal commands
On Tuesday, September 25, 2007 11:32 AM, James Bottomley wrote: Youve rejected the error recovery patchs, which is fair enough. Just the separation ... the actual patch looks OK. I'll will continue working to separate the error recovery improvements: into smaller feature add, but will take some time. I want some constructive feedback, and too big of patch is deterring some people from looking at it. Thanks, Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/9] mpt fusion: error recovery improvements, andsynchronizing internal commands
On Saturday, September 22, 2007 10:23 AM, James Bottomley wrote: OK, I thought I'd wait here for the breakout, but in the meantime I tried to compile the first five patches, but they don't: CC [M] drivers/message/fusion/mptscsih.o drivers/message/fusion/mptscsih.c: In function 'mptscsih_qcmd': drivers/message/fusion/mptscsih.c:1357: error: 'MPT_SCSI_HOST' has no member named 'resetPending' drivers/message/fusion/mptscsih.c: In function 'mptscsih_TMHandler': drivers/message/fusion/mptscsih.c:1554: error: 'MPT_ADAPTER' has no member named 'diagLock' ... Its not going to compile if you didn't pull down all 6 patchs associated to error recovery improvements. Those six patchs were divided by sources. Meaning patch 4 was mptbase.[h,c] changes, then patch5 was mptctl.[c,h] changes, and so on. So the changes assoicated for mptscsich.c are in patch 8. Since you didn't apply the 8th patch, offcourse your going to get the errrors in mptscish.c.All patchs 4-9 need to go togeather, as mentioned in the first patch 0. The series can't be applied in this form, because if git bisect steps into the middle of this, the compile will break (and hence the bisection) and a lot of people will say a lot of nasty things. A patch series really needs to be one patch per logical change (with other peoples' patches broken out) in a form that is separately compilable for each patch. Additionally, with a separate change log and summary (i.e. not four patches all saying mpt fusion: error recovery improvements, and synchronizing internal commands). I understand, and thats been going on for the past couple months, starting with Sathya's patchs early August. The changes associated with the rewrite of internal commands, and errror recovery is rather difficult to seperate due to many depandancies and new structure changes, and my concerned risk of what small steps could introduce more issues, so IMO, the least risk was jump starting you to the customer and factory tested code. I'll back all of this out; can you resend the series conforming to the above request? The first three patchs did conform that, which are: 1) adding usage of shost_priv and removing all the typecasting 2) Fixing sparse warnings 3) locking down ScsiLookup Youve rejected the error recovery patchs, which is fair enough. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/9] mpt fusion: error recovery improvements, andsynchronizing internal commands
On Saturday, September 22, 2007 10:02 AM, James Bottomley wrote: What fixes? The object of a change log is to preserve the history of a particular change (as per the Developer Certificate of Origin). This means if you get a patch from someone, you should also collect their signoff with it, then you pass it on to me complete with your signoff added (and a note if you had to modify it to fit it into the patch series or otherwise alter it). James James, Mike sent me an email back on June 13, contain 11 suggested changes associated with his test efforts with my new code having rewrote internal command error handling, and adding new polling function for controller fault handling. The changes he quoted associated to the ones in mptfc seem vague. I have the email I could forward, but at that time, It probably doesnt matter. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH -mm] mpt fusion: Shut up uninitialized variable warnings
On Sunday, September 02, 2007 2:20 PM, Satyam Sharma wrote: drivers/message/fusion/mptctl.c: In function 'mptctl_mpt_command': drivers/message/fusion/mptctl.c:1764: warning: 'bufIn.len' may be used uninitialized in this function drivers/message/fusion/mptctl.c:1765: warning: 'bufOut.len' may be used uninitialized in this function come because gcc gets confused by some goto statements in above function. The warnings have been verified to be bogus, however, the function does initialize these later (after the offending goto's) in the function anyway. So let's move those initializations to top of function, thereby also shutting up these warnings. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] ACK, this patch is fine. However the patch needs posting to lsml. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mptsas: scan the logical volume at first
On Monday, August 27, 2007 11:58 AM, Yinghai Lu wrote: [PATCH] mptsas: scan the logical volume at first user like to see the raid show as /dev/sda before left raw disks. So scan the volume at first to make their life easier. Signed-off-by: Yinghai Lu [EMAIL PROTECTED] Although I agree with the patch, there are people on this list that will reject it due to the fact distro's ship today having udev label and device id mapping, so device ordering should be an non-issue. However there are systems that ship that don't have BIOS BBS support, allowing you to select the boot device. Without it BBS support, you are forced to boot to the lowest device id. There are HP and Dell systems like that. Are SUN systems like that? If so, there is an additional patch which I have yet posted that will sort the raid volumes in acsending order. Currently they are in descending order (due to Firmware putting them in that order), which if you did a install to what you think is /dev/sda, its really the highest target id, and when you reboot, the BIOS will boot to the lowest id, which is /dev/sdb, and it will not find the boot partition. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mptsas: scan the logical volume at first
On Monday, August 27, 2007 4:52 PM, Yinghai Lu wrote: Yes, I was wondering why kernel.org mainline will have /dev/sdb for first raid. but it seems RHEL 5 kernel have first raid before second raid...( it after all left over raw devices..), maybe they already aplied some patch? can you send out patch? That is not necessary, as we have already implemented the change to sort volumes in acsending order to Red hat and Suse, and its been accepted. I will post the change to lsml. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/6] mpt fusion: Add support for ATTO 4LD: Rebranded LSI 53C1030
On Saturday, August 18, 2007 12:40 AM, Mr. James W. Laferriere wrote: drivers/message/fusion/mptbase.c:4656: error: `PCI_VENDOR_ID_ATTO' undeclared (first use in this function) drivers/message/fusion/mptbase.c:4656: error: (Each undeclared identifier is reported only once drivers/message/fusion/mptbase.c:4656: error: for each function it appears in.) make[3]: *** [drivers/message/fusion/mptbase.o] Error 1 make[2]: *** [drivers/message/fusion] Error 2 make[1]: *** [drivers/message] Error 2 make: *** [drivers] Error 2 Why aren't you not doing a pull on the scsi-misc git tree? Your missing another patch I posted which updated the include/linux/pci_ids.h, having the PCI_VENDOR_ID_ATTO declared. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 2/4] scsi: expose AN support to user space
On Wednesday, August 15, 2007 8:02 AM, James Bottomley wrote: Actually, we just got a second potential consumer ... although I'll reprod to have the reporter send it to the list. It's a device that needs notice of report luns data changing. The proposed mechanism looks a bit narrow now (too tied to media change). I'll see if I can propose a more generic update. I believe James is referring to my Promise issue. That is - the customers mutipath enclosure our SAS controller. They have alternating luns mapped to each path. The odd luns mapped to a single path, and the even luns to the other. When a cable is pulled, a check condition is generated (0x6, 0x3F, 0xE), means report_luns data has changed. What the enclosure does it move the luns over to the alternate path.Our driver is not reporting the new luns because no event is generated to mpt fusion driver from controller firmware (firmware only reports when a target has been added/removed, not lun). The mpt fusion driver reports to the sas transport layer, the libata layer is not involved. Shouldn't someone above sscsi lld be snooping that sence, and then sending REPORT_LUNS to find out what changed. I've added some Promise contacts, I hope they include the interested partied to this discussion. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/6] mpt fusion: Add support for ATTO 4LD: Rebranded LSI 53C1030
On Tuesday, August 14, 2007 4:34 AM, Prakash, Sathya wrote: Add support for ATTO UL4D, they are rebranded 53C1030. The changes are 1. Adding a new PCI vendor ID in pci table 2. The spi_port_page_2 is in different format than that of LSI generic spi_port_page_2 and hence mapping code is added. signed-off-by: Sathya Prakash [EMAIL PROTECTED] ACK - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/6] mpt fusion: Usage of high priority request FIFO to send task management commands
On Tuesday, August 14, 2007 4:39 AM, Prakash, Sathya wrote: Added support for sending the task management requests through High priority request FIFO instead of Doorbell writes when firmware support High priority FIFO. signed-off-by: Sathya Prakash [EMAIL PROTECTED] --- ACK - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/6] mpt fusion: Changing call back indices to u8 from int
On Tuesday, August 14, 2007 4:43 AM, Prakash, Sathya wrote: The call back index requires only u8 but in lot of places it is referred as int, now everywhere the call back index variables are declared as u8 with uniform name cb_idx signed-off-by: Sathya Prakash [EMAIL PROTECTED] --- Pls note we killed both mpt_lan_index and mpt_stm_index, external symbols, which the janitors have long wanted to remove. The new function mpt_get_cb_idx will obtain the proper cb_idx handle. ACK - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/6] mpt fusion: Creation of mptsas.h header file
On Tuesday, August 14, 2007 4:46 AM, Prakash, Sathya wrote: The data structure definitions from mptsas.c are moved to a new header file mptsas.h signed-off-by: Sathya Prakash [EMAIL PROTECTED] --- ACK - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/6] mpt fusion: Link speed change display support
On Tuesday, August 14, 2007 4:50 AM,Prakash, Sathya wrote: When there is state change in FC links, a message is displayed with old and new link speed. signed-off-by: Sathya Prakash [EMAIL PROTECTED] --- ACK - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] mpt fusion: Changing company name from LSI Logic to LSI
On Tuesday, August 14, 2007 4:53 AM, Prakash, Sathya wrote: Recently LSI Logic Corp is renamed as LSI Corp, so where ever there is a reference of LSI Logic, they are changed to LSI in mpt fusion driver code. signed-off-by: Sathya Prakash [EMAIL PROTECTED] --- ACK - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/6] mpt fusion: Creation of mptsas.h header file
On Tuesday, August 14, 2007 12:50 PM, Matthew Wilcox wrote: On Tue, Aug 14, 2007 at 04:15:38PM +0530, Prakash, Sathya wrote: The data structure definitions from mptsas.c are moved to a new header file mptsas.h Why? Are they used outside mptsas.c in some future patch? Having rougly 10 data structures, and nearly 100 lines of code, Id prefer it to have it in a seperate header so our sources files is not so cluttered with a bunch of structs and defines.. In our internal sources, we do need this broken out into a seperate header due to its inclusion in our IOCTLS sources. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/6] mpt fusion: Add support for ATTO 4LD: Rebranded LSI 53C1030
On Tuesday, August 14, 2007 4:44 PM, Christoph Hellwig wrote: Not that we can change it anymore, but what idiot decided to do such a change? An chance LSI could stop licencees from doing such bloody braindamaged things to the firmware in the future? add a reminder for anyone to never but ATTO hardware as the company is utterly useles.. I really not sure the significance of that change to spi_device config pages. My guess that atto flags have something significant to some other OS, like windows. I couldn't find anyone from ATTO that would answer my doubts. There are some customers that want PCI EXPRESS U320 card, and LSI never decided to make anything beyond xscale. There is this express card from ATTO, as well as one from HP, both having the LSI 1030 chip. LSI managment approved this request for this patch, so we pushed forward with supplying this changeset. I have reposted the patch per Wilcox's request having the ATTO ids, but I just don't see it posted to the forum. I may have to repost. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
On Monday, July 30, 2007 5:36 PM, FUJITA Tomonori wrote: Looks good for me. Here's an updated version. Can you add your signed-off or acked-by? --- From: FUJITA Tomonori [EMAIL PROTECTED] Subject: [PATCH] mptsas: add SAS management protocol handler This patch adds support for SAS Management Protocol (SMP) passthrough support via bsg. Like libsas's smp support, user-space tools can send a smp request frame via sg_io_v4's dout_xferp and get a smp response frame via din_xferp. In addition, user-space tools can get the mpt reply via sg_io_v4's response field too if necessary. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Acked-by: Eric Moore [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] mpt fusion: Add logging support
On Monday, July 30, 2007 4:32 PM, FUJITA Tomonori wrote: On another note, while unloading the driver, and I get an following opps from bsg in the context of scsi_remove_host. This is w/o the SMP passthrough patch, so why would fusion drivers be linked to bsg? Woudn't this break mptspi and mptfc, since they will not be working with bsg. Call Trace: [881f519c] :scsi_transport_sas:sas_bsg_remove+0x27/0x32 [881f6349] :scsi_transport_sas:sas_host_remove+0x30/0x34 [80375326] transport_remove_classdev+0x1d/0x4c [80375001] attribute_container_device_trigger+0x69/0xa7 [8803778b] :scsi_mod:scsi_remove_host+0xcd/0xfa [883461ac] :mptscsih:mptscsih_remove+0x32/0xae [8031416d] pci_device_remove+0x24/0x48 [803720ed] __device_release_driver+0x91/0xb3 [80372631] driver_detach+0xd6/0x115 [80371ba3] bus_remove_driver+0x6d/0x90 [803143f4] pci_unregister_driver+0x17/0x6b [88355044] :mptsas:mptsas_exit+0x10/0x5f [80252afb] sys_delete_module+0x1b1/0x1e0 [80307d9c] __up_write+0x21/0x10d [8020bc4e] system_call+0x7e/0x83 This patch fix the problem? --- From: FUJITA Tomonori [EMAIL PROTECTED] Subject: [PATCH] scsi_transport_sas: initialize sas_host_attrs-q fix the bug to call bsg_unregister_queue for an uninitialized queue. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] yes it does fix it. I'm not sure if this has already been posted to lsml@, but please apply to scsi-rc-fixes-2.6. Thanks, Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
On Sunday, July 29, 2007 1:37 AM, FUJITA Tomonori wrote:
Eric, can I get your ACK on this patch?
One comment on the the patch:
+ if (!(ioc-sas_mgmt.status MPT_IOCTL_STATUS_COMMAND_GOOD)) {
+ printk(KERN_ERR %s: smp response invalid!\n,
__FUNCTION__);
+ ret = -ENXIO;
+ }
We don't need this part since user-space can get mpt's reply, I think.
Correct, this should be removed. The processing of the mpt reply has
been pushed to user-space.On another note, according to the mpi
specification, its says there should always be a reply message frame
returned for every smp passthru. So I thinking this would be the best
way to close out the end of this function. What do you think?
+ if (ioc-sas_mgmt.status MPT_IOCTL_STATUS_RF_VALID) {
+ SmpPassthroughReply_t *smprep;
+
+ smprep = (SmpPassthroughReply_t *)ioc-sas_mgmt.reply;
+ memcpy(req-sense, smprep, sizeof(*smprep));
+ req-sense_len = sizeof(*smprep);
+ } else
+ printk(KERN_ERR %s: smp passthru reply failed to be
returned\n, __FUNCTION__);
+ ret = -ENXIO;
+ }
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] mpt fusion: Add logging support
On Saturday, July 28, 2007 11:40 AM, James Bottomley wrote: I tell you what, let me just show you the actual patch. This allows you to write to the /sys/module/mptbase/parameters/mpt_debug_level and have it take effect in every ioc. ACK, If possible, I would like this patch thrown in with the other fusion logging patchs you added over the weekend to the scsi-rc-fixes-2.6 stream. Thanks. On another note, while unloading the driver, and I get an following opps from bsg in the context of scsi_remove_host. This is w/o the SMP passthrough patch, so why would fusion drivers be linked to bsg? Woudn't this break mptspi and mptfc, since they will not be working with bsg. Call Trace: [881f519c] :scsi_transport_sas:sas_bsg_remove+0x27/0x32 [881f6349] :scsi_transport_sas:sas_host_remove+0x30/0x34 [80375326] transport_remove_classdev+0x1d/0x4c [80375001] attribute_container_device_trigger+0x69/0xa7 [8803778b] :scsi_mod:scsi_remove_host+0xcd/0xfa [883461ac] :mptscsih:mptscsih_remove+0x32/0xae [8031416d] pci_device_remove+0x24/0x48 [803720ed] __device_release_driver+0x91/0xb3 [80372631] driver_detach+0xd6/0x115 [80371ba3] bus_remove_driver+0x6d/0x90 [803143f4] pci_unregister_driver+0x17/0x6b [88355044] :mptsas:mptsas_exit+0x10/0x5f [80252afb] sys_delete_module+0x1b1/0x1e0 [80307d9c] __up_write+0x21/0x10d [8020bc4e] system_call+0x7e/0x83 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] mpt fusion: Add logging support
On Friday, July 27, 2007 10:21 AM, wrote:
The way your module parameter works is slightly counter intuitive. On
all our other drivers, you can write a value into
/sys/module/module/parameters/debug parameter
And have it acted on immediately. In yours, it seems only to work
before the host is probed (because after that, the value in the ioc
structure is what's used).
not true, the debug parameter can be configured prior to the host being
probed.We have a command line option called mpt_debug_level, that
can set the debug level from mptbase.ko. That way you can enable
certain debug during probe time prior to the loading of
mptsas/mptfc/mptspi. Once those upper drivers are loaded, you can toggle
off and on the debug via the shost_attrib. This is explained in
mptdebug.h.
The other question is are you really sure you actually want per host
debugging? is the added flexibility in being able to turn it
on and off
per host worth the problems of explaining to the users where
to find the
parameter? I've got to bet that 95% of the installations only have a
single fusion card anyway. would it not be simpler just to have a
global module parameter that can be set and acted on from
/sys/modules?
I like having the added flexibility, and potential customers may agree.
Our driver stack support multiple bus protocols, unlike other vendors,
and some customers may ship fibre, sas, and spi in a single systems..
For my personal use, I like being able to have per host debugging, as I
have multiple cards in my systems.There are several cases I've
debugged two controller case, when boot OS is on one controller, and the
debug efforts on another, in that case I only want to concern myself
with the debug in question, not boot OS. The method of debug usesage is
in mptdebug.h, so I would think people would look there, and figure it
out. I also have a script below that sets all the host debug sas chips.
Does this sound reasonable? If not, let me know.
---[Cut below]---
#!/bin/bash
#set -x
if (( $# != 1 )); then
echo -e \\nuseage: set_debug_level level
echo -e \\n
exit 1
fi
scsi_host=/sys/class/scsi_host
cd ${scsi_host}
subfolders=`ls -1`
for i in ${subfolders}; do
cd ${i}
if [ `cat proc_name` != mptsas ]; then
cd ${scsi_host}
continue;
fi;
echo $1 debug_level
debug_level=`cat debug_level`
echo for ${i} debug_level=$debug_level
cd ${scsi_host}
done;
---[Cut above]---
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
On Thursday, July 26, 2007 6:44 PM, FUJITA Tomonori wrote: Does this work for you? Sorry, I'm not at the lab now and can't test it. But I can do next week. I also updated bsg's smp_rep_manufacturer to print the mpi's replay. You can get it from the git tree. yes this will work, and I pulled the updated sgv4, and saw your inclusion of mptsas.h. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] mpt fusion: Add logging support
On Tuesday, July 24, 2007 4:07 AM, Prakash, Sathya wrote: The patches in this patch set adds support for logging facility that can be used to debug a number of Fusion MPT related problems. The logging support can be enabled or disabled changing the kernel configuration flag CONFIF_FUSION_LOGGING The debug level can be programmed on the fly via SysFS (hex values) echo [level] /sys/class/scsi_host/host#/debug_level and also can be passed as module parameter mpt_debug_level for mptbase.ko There are various debug levels that can be found in the source file mptdebug.h Since the difference is of size 175 KB, it is split into five different patches grouped based on the files as described below. [PATCH 1/5] : Changes for logging support in Kconfig, Makefile, mptbase.h and addition of mptdebug.h [PATCH 2/5] : Changes in mptbase.c for logging support [PATCH 3/5] : Changes in mptscsih.c for logging support [PATCH 4/5] : Changes in mptfc.c mptlan.c mptsas.c and mptspi.c for logging support [PATCH 5/5] : Changes in mptctl.c for logging support These set of patchs are to replace the current cumbersome implementation of enabling debug defines in the driver Makefile, and recompiling the driver.The new method allows the enduser to enable/disable debug information any time without having to recompile or reboot the system. These code has been verified in the LSI test labs for several months, and there is no performance regressions with this. If there are no other further objections, please apply. ACK Eric Moore - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
On Thursday, July 26, 2007 4:09 AM, FUJITA Tomonori wrote: The SMP response's function result wasn't set correctly? bsg's smp_rep_manufacturer didn't check the result so it showed garbase, I guess. BTW, I took the code to check the result from Doug's smp_utils and put bsg's smp_rep_manufacturer: http://www.kernel.org/pub/linux/kernel/people/tomo/smp/ or git://git.kernel.org/pub/scm/linux/kernel/git/tomo/sgv4-tools.git Thanks.with Doug Gilberts help, I have solved the git dilema thru firewall. I need a socks proxy, which I found from http://tsocks.sourceforge.net/ That's the reason why I said before, sense buffer is not used for smp and using sense buffer would be the easiest way to push up the mpt unique response to userspace. do you suggest the scsi llds would would need to translate there own codes (in my case iocstatus/loginfo/sasstatus) into common sense sk/asc/ascq ? Here's an updated patch. The patch looks good. It can be applied upstream. I tested on x86_64, not big endian (I could try out on a ppc64 when I have time). Here is the output from your latest tool with various expanders I have in my lab. # ./smp_rep_manufacturer /sys/class/bsg/sas_host2 SAS-1.1 format: 0 vendor identification: LSI product identification: Virtual SMP Port product revision level: # ./smp_rep_manufacturer /sys/class/bsg/expander-3:0 SAS-1.1 format: 1 vendor identification: LSILOGIC product identification: x36-00.00.06.00 product revision level: component vendor identification: LSI component id: 531 # ./smp_rep_manufacturer /sys/class/bsg/expander-3:1 SAS-1.1 format: 1 vendor identification: XYRATEX product identification: SAS-01 product revision level: 03A component vendor identification: LSI component id: 517 # ./smp_rep_manufacturer /sys/class/bsg/expander-3:2 SAS-1.1 format: 1 vendor identification: HP product identification: MSA 50-10D25G1 product revision level: component vendor identification: LSI component id: 512 component revision level: 1 # ./smp_rep_manufacturer /sys/class/bsg/expander-3:3 SAS-1.1 format: 0 vendor identification: LSILOGIC product identification: SASx12 A.0 product revision level: - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
On Tuesday, July 24, 2007 6:48 PM, FUJITA Tomonori wrote: I hadn't enabled bsg support in the linux kernel, that was my problem. What do you mean? You might hit the bug that you can't build scsi as a modular. It was fixed before rc1. The issue is I'm new to BSG, and I didn't know I needed to enable CONFIG_BLK_DEV_BSG in the kernel config. I upgraded today to rc1, and your correct, I don't have to link the scsi mod into kernel. Don't worry about this point, I'm squared away now. # ./sgv4-tools/smp_rep_manufacturer /sys/class/bsg/expander-0:1 I think that James tested this with aic94xx, however, I guess that nobody has tested this with mptsas. I got garbage (I'm using the 2.6.23-git11 patch from last week, before rc1): # ./smp_rep_manufacturer /sys/class/bsg/expander-2:0 SAS-1.1 format: 1 vendor identification: _BUS_ADD product identification: RESS=unix:abstra product revision level: ct=/ component vendor identification: tmp/dbus component id: 11609 component revision level: 69 With Doug Gilberts tools it works: # smp_rep_manufacturer --sa=0x500605b016b0 /dev/mptctl Report manufacturer response: SAS-1.1 format: 0 vendor identification: LSILOGIC product identification: SASx12 A.0 product revision level: Also, unloading and reloading the driver resulted in two expander entryies in /sys/class/bsg.The old entry was not deleted when I unloaded the driver. When I tryied to run smp_rep_manufacture on the old expander instance, it panicked. With a sas analyzer, I figured out today why the bsg version of smp_rep_manufacture is not working.There is a bug in mptsas_smp_handler. The calculation of the first scatter gather element size for the outbound data is incorrect. Its being set to the resonse data length, when instead it should be the request data legth. This is incorrect: + flagsLength |= (rsp-data_len - 4); It should be + flagsLength |= (smpreq-RequestDataLength); I forgot to remove bsg entries. James fixed the bug. Please try 2.6.23-rc1. thanks, I noticed its fixed in rc1 But probably, the tool still don't work against an expander. Does it work against the Virtual SMP Port? I tried out this by passing /sys/class/bsg/sas_host0, and I saw it return Virtual SMP. I guess this can be left in. Oh, I thought that LSI wants to send the smp_reply back to user space since Doug's smp-utils does. But If you don't want, I'll just put the response check code that you suggested in the previous mail. On second thought, It would be nice to have iocstatus, iocloginfo, and sasstatus available in user space, that way the appliacation will have a better understanding of what error occurred. Without that info, how will you it know if the response data you receive is valid data? For instance, before I identified the bug in the sgel size, you were displaying garbage. The driver could have prevented that by returning -ENXIO I guess, instead how about pushing up that info to user space. what do you think?maybe there should be some translation to common error returns code between the varous sas vendors supporting this portal. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] mpt fusion: Changes in mptscsih.c for logging support
On Tuesday, July 24, 2007 4:31 AM, Boaz Harrosh wrote: NACK This driver was already converted to accessors please don't use old (going a way soon) scsi_cmnd members directly Sathya - a little background on this. I believe this all started with the Proposals to change the way all drivers work with SCSI commands email from James Bottomley back on May 11th. here: http://marc.info/?t=11789086433r=1w=2. The fusion driver was ported by FUJITA Tomonori in this patch http://marc.info/?l=linux-scsim=117896437623559w=2. So the bottomline, is anywere we access the scsi_cmnd pointer in the debug prints, needs to be ported using the new wrappers (in scsi_cmnd.h). Can you please review and repost? Thanks, Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
Tomo - do you have any documentation on how to specify a bsg device? I
was trying to run the smp_rep_manufacture from sgv4_tools, and I got
that error. Due to that, I have not able to test this patch. However,
here are some feedback with regards to the patch:
On Sunday, July 08, 2007 9:52 PM, FUJITA Tomonori wrote:
+
+smpreq-RequestDataLength = req-data_len - 4;
Our firmware formats the data in little endian, so you'll need to
convert this inorder for it work under other endian formats, like sparc
and ppc. So this code should be:
smpreq-RequestDataLength = cpu_to_le16(req-data_len - 4);
+smpreq-Function = MPI_FUNCTION_SMP_PASSTHROUGH;
+
+ if (rphy)
+ memcpy(smpreq-SASAddress, rphy-identify.sas_address,
+sizeof(smpreq-SASAddress));
should be using cpu_to_le64 before the data is put into
smpreq-SASAddress
+ else {
+ struct mptsas_portinfo *port_info;
+
+ mutex_lock(ioc-sas_topology_mutex);
+ port_info = mptsas_find_portinfo_by_handle(ioc,
ioc-handle);
+ if (port_info port_info-phy_info)
+ memcpy(smpreq-SASAddress,
+
(port_info-phy_info[0].phy-identify.sas_address),
+sizeof(smpreq-SASAddress));
+ mutex_unlock(ioc-sas_topology_mutex);
+ }
I'm not sure what the intent of this else case. I think it should be
deleted, and replaced with a return of ENXIO.The sas_topology is a
flat model, with the first object the intiatiator, and the other objects
in the list are expanders.What your your attempting to obtain is the
first port object connected to the initiator, which could be anything,
for instance it could be an end device, instead of expander.So I
think if your rphy object is not returning a valid sas_address, then
return instead of attempting to find something from the sas_topology.
I hope the API is making sure this is an expander before mptsas is even
called, is that handled?
+ /* a reply frame is expected */
+ if (!(ioc-sas_mgmt.status MPT_IOCTL_STATUS_RF_VALID)) {
+ printk(%s: the smp response invalid!\n, __FUNCTION__);
+ ret = -ENXIO;
+ }
+
I think in addition to having a valid reply, I think you should look at
the iocstatus to insure the reply itself was successfull, and that there
were no data underruns.
ioc_status = le16_to_cpu(smpReply-IOCStatus) MPI_IOCSTATUS_MASK;
if ((ioc_status != MPI_IOCSTATUS_SUCCESS)
(ioc_status != MPI_IOCSTATUS_SCSI_DATA_UNDERRUN)) {
return -ENXIO;
}
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] update mpt Kconfig help
On Thursday, July 19, 2007 1:27 PM, Gwendal Grignou wrote: Update help in Kconfig for mptfc driver to indicate the driver supports Brocade FC 4G HBA. signed-off-by: Gwendal Grignou [EMAIL PROTECTED] ACK Eric Moore - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mpt fusion: add support for Brocade branded LSI FC HBA
On Tuesday, July 17, 2007 2:49 AM, Prakash, Sathya wrote: Resubmitting with Eric Moore suggested modifications: --- Add support for Brocade 410/420 4Gbit FC HBAs. They are re-branded LSI HBAs [LSI7104EP-LC/LSI7204EP-LC] This patch should be applied over the following patches: 1. mpt fusion: deregister from transport layer if PCI registration failed 2. mpt fusion: add sysfs attributes to display IOC parameters 3. add PCI_VENDOR_ID macro for Brocade in pci_ids.h signed-off-by: Sathya Prakash [EMAIL PROTECTED] --- ACK Eric Moore - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mpt fusion: add support for Brocade branded LSI FC HBA
On Friday, July 13, 2007 3:29 AM, Prakash, Sathya wrote:
You need to include in this patch, the fix that occurred between the
4.00.09 and 4.00.10 drivers. That fix is in mptDisplayIocCapabilties,
where it was removing the first three characters from the prod_name.
Without this change, 040 would be displayed instead of BRE040.
Here are some additional request:
+mpt_get_product_name(u16 vendor, u16 device, u8 revision,
char *prod_name)
+{
+ char *product_str = NULL;
+
+ if (vendor == 0x1657) {
+ switch (device)
You should use the define PCI_VENDOR_ID_BROCADE instead of the hardcoded
0x1657 value.
+ if (vendor != PCI_VENDOR_ID_LSI_LOGIC)
+ goto out;
This sanity check on PCI_VENDOR_ID_LSI_LOGIC needs to be removed. I
will be required in the pending ATTO UL4D patch.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mpt fusion: add sysfs attributes to display IOC parameters
On Thursday, July 12, 2007 8:12 AM, Brian King wrote: This should be removed from the patch. This information is already available in sysfs: /sys/module/mptscsih/version He is correct, the version is there in /sys/module/mptsas/version as well. Please repost the patch with this removed. Thanks, Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RAID1 can't be written after pulling out the secondary hard disk
On Thursday, June 14, 2007 8:05 PM, Lee Webb wrote: Can I ask which kernel version the fix for this issue was introduced in? I have recently installed CentOS5 running a 2.6.18-8.1.4.el5 kernel on a new Dell PowerEdge SC1435 appear to be having the same issue as that reported by Zhao. I'm trying to track down the fix for it, but am having trouble. The fix was just posted to lsml. I have already provided ports to both Red Hat and Suse. Eric Moore - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Very slow writes with mptsas
On Wednesday, June 06, 2007 12:06 PM, Douglas Gilbert wrote: Matthew Jacob wrote: The FreeBSD problem was fixed by Scott Long a couple of days ago by doing some cut through SAS stuff that enabled Write Cache for SATA drives. Why LSI-Logic couldn't just blitheringly synthesize mode page 8 is beyond me, but okay. I dunno whether the issue here is the same one Scott tackled- probably given the messages. Eric- you listening in on this? Matt, Just in case Eric doesn't answer, I suspect if the HBA firmware can be upgraded (from Dell or LSI?) then WCE (write cache enable) in the caching mode page will be supported. It is one of the few mode page settings that is required to be implemented in SAT. The other field that should be changeable is DRA (disable read ahead). Both work on my LSI SAS HBA. There is two ways this can be done. (1) In Linux, we expose hidden raid components to the sg layer, and you can use some of Doug Gilberts sg utilties to modify the WCE bit in the caching mode pages to each physical disk. I've used sg_modes to read them, and sg_wr_modes to write them back out. (2) You can enable write caching in the volume settings of the firmware config page called RAID_VOLUME_PAGE_0.In the VolumeSettings, bit 0, there is WriteCachingEnabled bit. When this is set to one, all the write caching is enabled for all the hidden physical disks.You can modify the VolumeSettings by sending a RAID_ACTION request, with the MPI_RAID_ACTION set to CHANGE_VOLUME_SETTINGS, with the ActionDataWord field corresponding to the VolumeSettings; e.g. set bit 0 to one.We have a tool called lsiutil that will enable this. Let me know, and I will send that source over.I don't know why the firmware doesn't allows the caching page to be modified to the volume. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVDdriveconnected to mptspi driver
James - I obtained a log from Doug (attached), and the firmware is returning BUSY, so your correct. That will end up as a ADD_TO_MLQUEUE disposition. Does the mid-layer throttle back the queue when a device returns busy, I don't know?I still believe that the lld shouldn't report that a device supports tagged when it really doesn't.I hope you will consider this patch, if not, let me know how to proceed. Eric Eric Moore wrote: On Tuesday, May 29, 2007 4:03 PM, James Bottomley wrote: The device is presumably returning BUSY when you try to send a second command when it's already processing the first ... that should be propagated back to the mid-layer causing it to throttle the queue ... it seems this wasn't happening for some reason to get such a massive slowdown. Is this a more generic problem in the fusion or is it a simple issue only affecting the untagged case? Right, probably SELECTION_TIMEOUT. Or command timeout with error handling threads getting called. Either way, the customer hasn't provided a dmesg log or scsi bus trace, so we don't know for sure. But is this analysis really required? Dont' you think the driver should return that it doens't support queued commands when sdev-tagged_supported (look at scsi_scan.c function scsi_add_lun) is set to zero? It appears that is what other drivers in the kernel tree do.When I reorganized the code in a patch I provided back in February, I moved analyzing the sdev-tagged_supported flag to after I set the queue depth, not before. ISO 9660 Extensions: Microsoft Joliet Level 3 ISO 9660 Extensions: RRIP_1991A mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x0008 iocstatus=0x scsi_state=0x00 scsi_status=0x08 loginfo=0x mptscsih_io_done: [0:0:1:0] resid=30720 bufflen=30720 xfer_cnt=0 sr 0:0:1:0: [sr0] Done: MLQUEUE sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 11 00 00 0f 00 mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x0008 iocstatus=0x scsi_state=0x00 scsi_status=0x08 loginfo=0x mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0 mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x0008 iocstatus=0x scsi_state=0x00 scsi_status=0x08 loginfo=0x mptscsih_io_done: [0:0:1:0] resid=32768 bufflen=32768 xfer_cnt=0 mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x0008 iocstatus=0x scsi_state=0x00 scsi_status=0x08 loginfo=0x mptscsih_io_done: [0:0:1:0] resid=49152 bufflen=49152 xfer_cnt=0 sr 0:0:1:0: [sr0] Done: MLQUEUE sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 48 00 00 28 00 sr 0:0:1:0: [sr0] Done: MLQUEUE sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 70 00 00 10 00 sr 0:0:1:0: [sr0] Done: MLQUEUE sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 a8 00 00 18 00 mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x0008 iocstatus=0x scsi_state=0x00 scsi_status=0x08 loginfo=0x mptscsih_io_done: [0:0:1:0] resid=32768 bufflen=32768 xfer_cnt=0 mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x0008 iocstatus=0x scsi_state=0x00 scsi_status=0x08 loginfo=0x mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0 sr 0:0:1:0: [sr0] Done: MLQUEUE sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 70 00 00 10 00 sr 0:0:1:0: [sr0] Done: MLQUEUE sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 48 00 00 28 00 mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x0008 iocstatus=0x scsi_state=0x00 scsi_status=0x08 loginfo=0x mptscsih_io_done: [0:0:1:0] resid=32768 bufflen=32768 xfer_cnt=0 sr 0:0:1:0: [sr0] Done: MLQUEUE sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 70 00 00 10 00 mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x0008 iocstatus=0x scsi_state=0x00 scsi_status=0x08 loginfo=0x mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0 mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x0008 iocstatus=0x scsi_state=0x00 scsi_status=0x08 loginfo=0x mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0 mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x0008 iocstatus=0x scsi_state=0x00 scsi_status=0x08 loginfo=0x mptscsih_io_done: [0:0:1:0] resid=2048 bufflen=2048 xfer_cnt=0 mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x0008 iocstatus=0x scsi_state=0x00 scsi_status=0x08 loginfo=0x mptscsih_io_done: [0:0:1:0] resid=14336 bufflen=14336
RE: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVDdrive connected to mptspi driver
On Tuesday, May 22, 2007 3:27 PM, James Bottomley wrote: On Tue, 2007-05-22 at 14:25 -0600, Doug Chapman wrote: Eric, Sorry to bother you on this again, I realize you are very busy. From our off-list email and from your comments to Chip Coldwell in redhat BZ 225177 it sounded like you were prepared to ACK this. Any chance you could send your official ACK so this can be committed? much appreciated, Actually I'd like a little analysis of why first, please Eric. It seems to me, with the current wrong ordering in the initialisation results in a large queue depth being given to the DVD (which are habitually very low queue depth ... or even untagged beasts). So does the slowdown result from the fusion accepting N commands for the DVD and then rejecting N-1 of them resulting in ping pong between the mid-layer and driver? If so, we probably want to fix the command throttling in the driver. James - Sorry, for delay, somehow I missed this email. I approve the patch that was submitted by Doug Chapman. Here is the reasoning: The DVD device that Doug is using is either a SCSI_1 device, or it doesn't support Q-tags. The problem is the driver is setting the Queue depth to 32, when it should of been 1. With the queue depth set larger than one, this device doesn't work properly. This bug came about when I reorganized some spi functions by moving them from mptscsih.c over to mptspi.c. When I did that, there were some flags not set correctly in mptscsih_change_queue_depth. The function that sets these flags is mptspi_setTargetNegoParms.Prior to reorganizing the code, I was calling mptscsi_setTargetNegoParms before I set the queue depth, the current code does it after.If you accept this patch, then it sets the flags properly. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVDdriveconnected to mptspi driver
On Tuesday, May 29, 2007 4:03 PM, James Bottomley wrote: The device is presumably returning BUSY when you try to send a second command when it's already processing the first ... that should be propagated back to the mid-layer causing it to throttle the queue ... it seems this wasn't happening for some reason to get such a massive slowdown. Is this a more generic problem in the fusion or is it a simple issue only affecting the untagged case? Right, probably SELECTION_TIMEOUT. Or command timeout with error handling threads getting called. Either way, the customer hasn't provided a dmesg log or scsi bus trace, so we don't know for sure. But is this analysis really required? Dont' you think the driver should return that it doens't support queued commands when sdev-tagged_supported (look at scsi_scan.c function scsi_add_lun) is set to zero? It appears that is what other drivers in the kernel tree do.When I reorganized the code in a patch I provided back in February, I moved analyzing the sdev-tagged_supported flag to after I set the queue depth, not before. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 10/28] Fix |/|| confusion in fusion driver
On Monday, May 21, 2007 7:00 PM, Dave Jones wrote: Andrew, the last time this was posted, Eric picked up on some other flaws in the same area. James asked him to followup with a patch, but unless I'm mistaken, that never arrived. This diff should replace the one in your tree until Eric has an equivalent or better. Signed-off-by: Dave Jones [EMAIL PROTECTED] ACK Thanks Dave, this patch will work. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 18/30] Fix |/|| confusion in fusion driver
On Thursday, April 26, 2007 1:35 AM, Dirk Mueller wrote:
This patch corrects a |/|| confusion in
mptscsih_copy_sense_data. Using ||
means that the data that ends up being written is (almost always) 1,
instead of being bit-wise or'ed.
Cc: Eric Moore [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/message/fusion/mptscsih.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -puN
drivers/message/fusion/mptscsih.c~fix--confusion-in-fusion-dri
ver drivers/message/fusion/mptscsih.c
---
a/drivers/message/fusion/mptscsih.c~fix--confusion-in-fusion-driver
+++ a/drivers/message/fusion/mptscsih.c
@@ -2463,9 +2463,9 @@ mptscsih_copy_sense_data(struct scsi_cmn
ioc-events[idx].event =
MPI_EVENT_SCSI_DEVICE_STATUS_CHANGE;
ioc-events[idx].eventContext =
ioc-eventContext;
- ioc-events[idx].data[0] =
(pReq-LUN[1] 24) ||
-
(MPI_EVENT_SCSI_DEV_STAT_RC_SMART_DATA 16) ||
- (sc-device-channel
8) || sc-device-id;
+ ioc-events[idx].data[0] =
(pReq-LUN[1] 24) |
+
(MPI_EVENT_SCSI_DEV_STAT_RC_SMART_DATA 16) |
+ (sc-device-channel
8) | sc-device-id;
ioc-events[idx].data[1] =
(sense_data[13] 8) || sense_data[12];
Thanks, I agree with the change, however shouldn't we be changing:
ioc-events[idx].data[1] = (sense_data[13] 8) || sense_data[12];
to
ioc-events[idx].data[1] = (sense_data[13] 8) | sense_data[12];
And in the mptbase.h, the definition of the struct should be changed
from
typedef struct _mpt_ioctl_events {
u32 event; /* Specified by define above */
u32 eventContext; /* Index or counter */
int data[2];/* First 8 bytes of Event Data
*/
} MPT_IOCTL_EVENTS;
to
typedef struct _mpt_ioctl_events {
u32 event; /* Specified by define above */
u32 eventContext; /* Index or counter */
u32 data[2];/* First 8 bytes of Event Data
*/
} MPT_IOCTL_EVENTS;
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Bugme-new] [Bug 8426] New: massive slowdown on SCSI CD/DVDdrive connected to mptspi driver
On Thursday, May 03, 2007 9:50 PM, Doug Chapman wrote: ACK, tested this on my system where I originally found the problem and all is well with this. Ignore my earlier comment about the original patch adding the new function mptspi_initTarget. After looking at what is going on I realize that it didn't add this, it was just renamed from mptscsih_initTarget. Are you still having issues? I'm not clear with the above ACK email. AFAIK, that patch your refering to which I submitted is only moving code, not actually changing any functionality. If your having a problem with speed, then its most likely a domain validation problem. In this driver, the domain validation is done from the spi transport layer.When you load the driver, there should be some messages displayed along with the inquiry info during device scan, that would provide the negotiation rates. Search your /var/log/messages or dmesg. You can also look in the SysFS, and all the info is there as well. If your device is host_W:Channel_X:Target_Y:Lun_Z, then you would look in /sys/class/spi_transport_targetW:X:Y:Z/ , in this folder will be period. The period is found below at the end of the each line in nano seconds units. factor:0x08 Ultra320 (160 Mega-transfers / second) (6.25 ns) factor:0x09 Ultra160 ( 80 Mega-transfers / second) (12.5 ns) factor:0x0A Ultra2 ( 40 Mega-transfers / second) (25 ns) factor:0x0B Ultra2 ( 40 Mega-transfers / second) (30.3 ns) factor:0x0C Ultra( 20 Mega-transfers / second) (50 ns) factor:0x19 FAST ( 10 Mega-transfers / second) factor:0x32 SCSI ( 5 Mega-transfers / second) factor:0xFF 5 Mega-trasfers/second and asynchronous Also, in the mpt fusion, I have some debug you could enable, which will dump all the negotiation parameters as they are written and read from via the driver. The spi transport layer calls these entry points when it wants to change the negotiation parameter for each test it runs. In the mpt fusion driver Makefile, you need to uncomment the line MPT_DEBUG_DV. When you do that, then mptspi_print_read_nego and mptspi_print_write_nego would be called. I would like to point out that around the same time I supplied that mpt fusion patch, there were changes in scsi_transport_spi.c, that would effect negotitaion with regards to the starting min sync rate value. This file is in /usr/src/linux/drivers/scsi. You could diff between your kernels to see the changes. Eric Moore LSI - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RAID1 can't be written after pulling out the secondary hard disk
On Tuesday, April 10, 2007 3:01 AM, Zhao Forrest wrote: Hi Eric, We conducted the following test on a SUN Galaxy x64 server, then RAID1 can't be written anymore, fs become read-only. The steps of reproducing the bug: I sent you earlier a patch via Novell Bugzilla 244006. Please let me know if this satisfies your needs, then I will post a port of that patch here to [EMAIL PROTECTED] Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: MPT Fusion LSI22320 , Domain validation loops .
On Saturday, March 17, 2007 2:33 PM, James W. Laferriere wrote: Hello All , I am have been having this problem since I purchased the controller and after changing out the disks I thought were the problem . I am still getting the continous : mptscsih: ioc1: attempting task abort! (sc=f7a64500) scsi 3:0:4:0: command: Inquiry: 12 00 00 00 60 00 mptbase: Initiating ioc1 recovery mptscsih: ioc1: task abort: SUCCESS (sc=f7a64500) target3:0:4: Domain Validation detected failure, dropping back target3:0:4: Domain Validation skipping write tests target3:0:4: Ending Domain Validation target3:0:4: asynchronous target3:0:5: Beginning Domain Validation mptscsih: ioc0: attempting target reset! (sc=f7a64380) The acutual device id's change and the driver continously resets the busses starts all over . The disks are in a HP DS-SL13R-BA 4354R 14drive ultra3 racKmount cabinet w/ dualbus dualps , Which seems to present a ID6 , That does not show up in any of the bus scans . Now I have previously had the same cabinet with 18gb disks which had the same problem with this controller . BUT I also have a LSI Logic / Symbios Logic 53c1010 66MHz Ultra3 dual SCSI bus Adapter which works flawlessly with the 18gb disks in this very same cabinet . The cables for connecting the adapter(s) to tha cabinet are less than 24 inches in length . Would anyone please shed some light on what it is I am doing wrong or need to do or ? Too have this controller recognise these disk drives in this cabinet . There is a seperate mailing list for scsi releated issues, e.g. [EMAIL PROTECTED] I've posted a patch to address your issue several times, however it seems its not been picked up by the scsi subsystem maintainer. The last time it was posted was here: http://marc.info/?l=linux-scsim=117089244809072w=2 An alternative is you could obtain our latest drivers from the LSI download site, where these drivers should have this patch http://www.lsilogic.com/cm/DownloadSearch.do. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] fusion - honour return value of pci_enable_device() in mpt_resume()
On Friday, March 16, 2007 1:06 AM, Horms wrote: Honour the return value of pci_enable_device(), which seems to be a desirable thing to do: Both patch's look good. Thanks, Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ PATCH ] mptsas: Fix oops for insmod during kexec
On Friday, March 09, 2007 2:23 PM, Christoph Hellwig wrote: This needs a much better explanation. Please show the codepath leading to this. I was working with Judith on this patch earlier this week, so this is approved by LSI,,, ACK. This fix's an oops during driver load time. mptsas_probe calls mpt_attach(over in mptbase.c). Inside that call, we read some manufacturing config pages to setup some defaults. While reading the config pages, the firmware doesn't complete the reply in time, and we have a timeout. The timeout results in hardreset handler being called. The hardreset handler calls all the fusion upper layer driver reset callback handlers. The mptsas_ioc_reset function is the callback handler in mptsas.c. So where I'm getting to, is mptsas_ioc_reset is getting called before scsi_host_alloc is called, and the pointer ioc-sh is NULL.,,, as well as the hostdata. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: end to end error recovery musings
On Tuesday, February 27, 2007 12:07 PM, Martin K. Petersen wrote: Not sure you're up-to-date on the T10 data integrity feature. Essentially it's an extension of the 520 byte sectors common in disk arrays. For each 512 byte sector (or 4KB ditto) you get 8 bytes of protection data. There's a 2 byte CRC (GUARD tag), a 2 byte user-defined tag (APP) and a 4-byte reference tag (REF). Depending on how the drive is formatted, the REF tag usually needs to match the lower 32-bits of the target sector #. I from the scsi lld perspective, all we need 32 byte cdbs, and a mechinism to pass the tags down from above. It appears our driver to firmware insterface is only providing the reference and application tags. It seems the guard tag is not present, so I guess mpt fusion controller firmware is setting it(I will have to check with others). I assume that for transfers greater than a sector, that the controller firmware updates the tags for all the other sectors within the boundary. I'm sure the flags probably tell whether EEDP is enabled or not. I will have to check if there are some manufacturing pages that say whether the controller is capable of EEDP(as not all our controllers support it). Here are the EEDP associated fields we provide in our scsi passthru, as well as target assist. u32 SecondaryReferenceTag u16 SecondaryApplicationTag u16 EEDPFlags u16 ApplicationTagTranslationMask u32 EEDPBlockSize - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] fusion kernel-doc warning fixes
On Tuesday, February 20, 2007 12:17 PM, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Fix kernel-doc warnings in fusion driver code. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- ACK - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: LSI Logic 40919o fibre channel: scsi works ip not
On Saturday, February 17, 2007 9:04 AM, Mario Giammarco wrote: Now regarding the whole thing surrounding mptlan, I don't think that LSI officially supports that feature any more or willing to fix any bugs for it in their firmware or driver. Is that right? If so, we might as well remove that driver from the kernel. No, don't be thinking about removing that driver. LSI Logic still supports this driver. I had forwarded Mario's original email to Stephen Shirron last week. He should of been contacted by now, if not, please let me know. Eric Moore LSI Logic - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Fw: SAS1068 PCI-X Fusion-MPT SAS 1000:0055
The 2.6.9-22.EL kernel is RHEL4 Update 2. You may want to contact someone from the LSI MegaRAID group, or Red Hat since this is a binary only deliverable. You should be able to find a MegaRAID contact in the MAINTAINERS file in the top directory of the kernel source tree. I work on mpt fusion drivers, which is a seperate division within LSI. Eric On Sunday, February 04, 2007 11:49 PM, Frederic TEMPORELLI wrote: Eric, Do you have more information about 'megasr' module, which seems able to manage 'MegaRAID' on LSI 1068 ? This module is also named 'megaswr' Here's modinfo output for this module (binary for RH4, but can also be found for SLES9) == [EMAIL PROTECTED] x86_64]# modinfo megaswr.ko filename: megaswr.ko parm: low_mem_g:Set to 1 to simulate low mem condition parm: dbglvl_g:driver-wide debug flag license:GPL description:LSI Logic SofrRAID Driver author: LSI Logic Corporation alias: pci:vdsvsdbc*sc*i* alias: pci:vdsvsdbc*sc*i* alias: pci:vdsvsdbc*sc*i* ... alias: pci:vdsvsdbc*sc*i* alias: pci:vdsvsdbc*sc*i* depends:scsi_mod vermagic: 2.6.9-22.ELsmp SMP gcc-3.4 == = the module is provided by LSI (I get it from the web from supermicro) = the module is under GPL (but sources aren't shipped, nor the GPL license ) = the module is shipped with a 'pci.ids' file, with following content: == 0x8086 0x2652 megaswr MegaSWR|INTEL-ICH6R 0x8086 0x2682 megaswr MegaSWR|INTEL-ESB2 0x8086 0x27C1 megaswr MegaSWR|INTEL-ICH7R 0x8086 0x27C3 megaswr MegaSWR|INTEL-ICH7R 0x1000 0x0030 megaswr MegaSWR|LSILogic-1030 0x1000 0x0050 megaswr MegaSWR|LSILogic-1064 0x1000 0x0054 megaswr MegaSWR|LSILogic-1068 0x1000 0x0055 megaswr MegaSWR|LSILogic-1068 0x1000 0x0057 megaswr MegaSWR|LSILogic-1064E 0x1000 0x0059 megaswr MegaSWR|LSILogic-1068E == (note the chip with id 1000:0055) Hope that you can give us more details... regards -- Frederic TEMPORELLI Frederic TEMPORELLI a écrit : Hi, Also seen on a NEC server, a 1068 chip with a jumper used to switch chip PCI ID and its BIOS: - PCI ID = 0054 = 'MPT Fusion' BIOS - PCI ID = 0055 = 'MegaRAID' BIOS I'm feeling that I submit this unusual chip ID to pciid DB some month ago... More important: there's a driver for this chip when it is used in 'MegaRAID' mode (standard 'mptsas' driver may be used for MPT Fusion mode) . This driver is named 'megasr' and is available (binaries) from several server vendors (Intel/Supermicro/Hitachi...) for standard distro (RH,Suse). Seems that this driver is provided by LSI (modinfo)... regards -- Fred Moore, Eric a écrit : On Friday, January 26, 2007 12:53 PM, Jun'ichi Nomura wrote: Hi, I have new NEC server with SAS1068 PCI-X Fusion-MPT SAS pciid: 1000:0055 mptsas form 2.6.20-rc5 don't recognize it ;( I see that driver support only 1000:0054 and 1000:0058 devices. It might be that the device has software RAID feature and changes device ID based on setup. (1000:0055 when software RAID is enabled and 1000:0054 or something for normal SAS) If so, there is a chance you can disable the software RAID via BIOS setup utility. Thanks, -- Jun'ichi Nomura, NEC Corporation of America You probably want to talk to the megaraid folks and see if the have a driver for that. I didn't submit a device id of 0055 to sourceforge. The only 1068 ids that are clamied by mptsas is 0054 and 0058 which are the pcix and pcie solutions. I notice that 0055 is listed in repository, but it was not me that submitted that. http://pci-ids.ucw.cz/iii/?i=1000 Eric Moore - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] : definion, code, and use of new SCSI ML hoststatus DID_COND_REQUEUE
On Friday, February 02, 2007 4:34 PM, Edward Goggin wrote: On Fri, 2007-02-02 at 17:18 -0600, James Bottomley wrote: On Fri, 2007-02-02 at 18:11 -0500, Edward Goggin wrote: That solution doesn't work for the RDAC/MPP driver as the BUSY status handler retries indefinitely. We need a solution which works for both a bare metal host running RDAC/MPP which for this use case, wants to get control over the failed command ASAP and a VMware host which may need to retry longer than DID_BUS_BUSY currently allows for. No it doesn't, not any longer... the mid-layer retries for the command up to its timeout before failing. That's the point about questioning the validity of the original problem. James I think I see your argument ... retries for BUSY and all other scsi/host status's are limited by the code in scsi_softirq_done which filters the disposition returned by scsi_decide_disposition, so no status will yield an indefinite retry. Not clear if that's soon enough for RDAC/MPP. For the VMware case, it appears to allow an additional 30 seconds (beyond what DID_BUSY_BUSY would allow) for a retry. Yanling, comments? IMO we can kill the code that interprets the BUSY sam status. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] - export scsilun_to_int
On Wednesday, January 31, 2007 10:02 AM, James Bottomley wrote: This is wrong. the int represents our internal coding of the 8 byte extended LUN (currently it's a lossy transform that only allows up to two level LUNs, so one day this will definitely change). No driver should be using this internally. From the patches it merely looks like you want to print out the value of a struct scsilun in debugging code, so perhaps a simple print_scsilun or something would be better? James No, this section of code is needed for more than printing the lun value. Here is a snip from that patch you may of missed: - if ((mf-TargetID != ((u8)vdevice-vtarget-target_id)) || (mf-LUN[1] != ((u8) vdevice-lun))) +if ((mf-Bus != vdevice-vtarget-channel) || +(mf-TargetID != vdevice-vtarget-id) || +(lun != vdevice-lun)) We need to convert the SAM3 LUN format, back to the scsi-mid layer version of the lun value, which currently is defined as an integer in linux.We save that scsi midlayer verison of lun, inside vdevice-lun at the start of day. The mf-LUN field will be in SAM3 LUN format. This sanity if/then check is required as we are trying to complete outstanding request for a given scsi_device, eg. lun. Do you want me to create my own function for converting the lun value, or can I use this one already defined in the linux kernel? Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Fw: SAS1068 PCI-X Fusion-MPT SAS 1000:0055
On Friday, January 26, 2007 12:53 PM, Jun'ichi Nomura wrote: Hi, I have new NEC server with SAS1068 PCI-X Fusion-MPT SAS pciid: 1000:0055 mptsas form 2.6.20-rc5 don't recognize it ;( I see that driver support only 1000:0054 and 1000:0058 devices. It might be that the device has software RAID feature and changes device ID based on setup. (1000:0055 when software RAID is enabled and 1000:0054 or something for normal SAS) If so, there is a chance you can disable the software RAID via BIOS setup utility. Thanks, -- Jun'ichi Nomura, NEC Corporation of America You probably want to talk to the megaraid folks and see if the have a driver for that. I didn't submit a device id of 0055 to sourceforge. The only 1068 ids that are clamied by mptsas is 0054 and 0058 which are the pcix and pcie solutions. I notice that 0055 is listed in repository, but it was not me that submitted that. http://pci-ids.ucw.cz/iii/?i=1000 Eric Moore - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fusion: Call pci_set_mwi()
On Friday, October 13, 2006 10:25 AM,Matthew Wilcox wrote:
Hi Eric,
Even though the 1030 is a PCI-X device, it can still be
plugged into a PCI
bus, and end up operating in PCI mode. According to the
documentation,
it will benefit from using MWI and MRM commands, but in order to do so
under Linux, we need to call pci_set_mwi(), which is what
this patch does.
Please apply.
P.S. The if condition is just to avoid the warning from __must_check.
Most device drivers do need to check and adjust their
internal flags if
it fails, but according to the 1030 manual, the chip automatically
decides when to use MWI.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
diff --git a/drivers/message/fusion/mptbase.c
b/drivers/message/fusion/mptbase.c
index 29d0635..d301a67 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1153,6 +1153,9 @@ #endif
if (pci_enable_device(pdev))
return r;
+ if (pci_set_mwi(pdev))
+ /* We don't have to do anything if it fails */;
+
dinitprintk((KERN_WARNING MYNAM : mpt_adapter_install\n));
if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
I just responded to the HP thread, and I remember this patch.
I hadn't had a chance to check this up. Pls let me know importance of
this,
and I will ask around the office wrt to this patch.. You don't think
this shouldn't break anything else? , such
as pci-express cards, cuase we have 1030 pcie, as well as FC and SAS
that
are express.
Eric
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/5] fusion: vmware bug fix prevent inifinite retries
On Tuesday, January 09, 2007 2:33 PM, Edward Goggin wrote: multi-pathing. This requirement shouldn't be a problem for the IBM RDAC/MPP driver either since it should already be setting the REQ_FAILFAST attribute of I/Os for which it is providing multi-pathing, similar to what the Linux dm-multipath driver already does. This approach seems to be the best. The other one from Petr is good as well, however I've not had time today to verify whether this detection algorithm will work properly, as we have built pcie 1030 parts, and its checking for pcix compatibilty at offset 0x68. With regards to this patch, I need to contact the mpp folks to see whether they are setting the REQ_FAILFAST attribute. I will followup shortly. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: PROBLEM: LSIFC909 mpt card fails to recognize devices
On Sunday, January 07, 2007 11:07 AM, Justin Rosander wrote: Hi Eric, I tried recompiling the kernel per your instructions, but I got a failure here: CC [M] drivers/message/fusion/mptbase.o drivers/message/fusion/mptbase.c: In function 'mpt_resume': drivers/message/fusion/mptbase.c:1526: warning: ignoring return value of 'pci_enable_device', declared with attribute warn_unused_result CC [M] drivers/message/fusion/mptscsih.o drivers/message/fusion/mptscsih.c: In function 'mptscsih_initTarget': drivers/message/fusion/mptscsih.c:2691: error: 'lun' undeclared (first use in this function) drivers/message/fusion/mptscsih.c:2691: error: (Each undeclared identifier is reported only once drivers/message/fusion/mptscsih.c:2691: error: for each function it appears in.) make[4]: *** [drivers/message/fusion/mptscsih.o] Error 1 make[3]: *** [drivers/message/fusion] Error 2 make[2]: *** [drivers/message] Error 2 make[1]: *** [drivers] Error 2 Did I do something wrong? Regards, Justin All you need to do is change lun to sdev-lun. I fix'ed that compile error in a patch I posted last week on the lsml: http://marc.theaimsgroup.com/?l=linux-scsim=116796872432421w=2 Can you try again? Eric Moore - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/5] fusion: vmware bug fix prevent inifinite retries
On Saturday, January 06, 2007 8:31 AM, James Bottomley wrote:
DID_BUS_BUSY causes an immediate retry, but it does debit the retry
count, so it shouldn't cause infinite retries ... if it
does, there's
something else wrong here.
I should also point out that the MPI_SCSI_STATUS_BUSY is
SAM_STAT_BUSY ... this return will cause a queue stop and a
requeue, but
it doesn't actually debit the retries, so it *may* cause an infinite
loop if the system is permanently busy.
Finally, whatever's causing this, it should probably be
treated the same
for all fusion bus types ...
James - I was incorrect in the way I worded this patch. Please read
further.
Original request came to me an you from Manon Goo [EMAIL PROTECTED] on
November 21, see attached.
Here is what VMware says, per Adam Zimman [EMAIL PROTECTED]:
VMkernel emulates a 1030/SPI. Path Failovers induce the vmkernel to
return a BUSY
status for VM initiated SCSI I/O requests. After a few I/O commands are
returned with
BUSY status, the RHEL VM will make the disk read-only. The host status
of DID_BUS_BUSY
causes the RHEL scsi error recovery process to retry a BUSY I/O at most
5 times and
then return an I/O failure upward in the I/O stack. If the I/O request
failed with a scsi
status of BUSY rather than a host status of DID_BUS_BUSY, the RHEL scsi
error recovery process
would retry the I/O indefinitely.
In the 03.02.19, we add added the current logic for the following
reason:
When a target device responds with BUSY status, the MPT driver was
sending DID_OK to the
SCSI mid layer, which caused the IO to be retried indefinitely between
the mid layer and the
driver. By changing the driver return status to DID_BUS_BUSY, the
target BUSY status can
now flow through the mid layer to an upper layer Failover driver, which
will manage the I/O timeout.
Eric
---BeginMessage---
Dear Sirs,
When changing from kernel 2.6.13 to 2.6.14 a change to the mtpscsih.c
driver was introduced thet changed the behaviour of the driver in respect
to timeouts.
The introduced changes around line 760. As far as I undestand this change
propagets a bussy device running async as a host failture.
This is extremely troublesome when using the mptscsi driver with vmware ESX
because esx expects the driver to wait when doing SAN pathfailovers or
going async.
Is there any chance to have the old behavior ?
Thanks in advance
Manon Goo
break;
+ case MPI_IOCSTATUS_SCSI_DATA_OVERRUN: /* 0x0044 */
+ sc-resid=0;
case MPI_IOCSTATUS_SCSI_RECOVERED_ERROR:/* 0x0040 */
case MPI_IOCSTATUS_SUCCESS: /* 0x */
- scsi_status = pScsiReply-SCSIStatus;
- sc-result = (DID_OK 16) | scsi_status;
+ if (scsi_status == MPI_SCSI_STATUS_BUSY)
+ sc-result = (DID_BUS_BUSY 16) |
scsi_status;
+ else
+ sc-result = (DID_OK 16) | scsi_status;
if (scsi_state == 0) {
;
} else if (scsi_state
MPI_SCSI_STATE_AUTOSENSE_VALID) {
Manon Goo
Dembach Goo Informatik GmbH Co KG
Rathenauplatz 9
D-50674 Köln
Tel: +49 221 801483 0
Mobil: +49 177 8091974
Fax: +49 221 801483 20
Email: [EMAIL PROTECTED]
pgpiJuHN1gm6k.pgp
Description: PGP signature
---End Message---
RE: [PATCH 2/5] fusion: vmware bug fix prevent inifinite retries
On Monday, January 08, 2007 3:25 PM, James Bottomley wrote: Right, I sort of suspected something like this. BUSY/QUEUE_FULL handling was a bit iffy in 2.4; but it was sorted out in the 2003/4 timeframe. Nowadays, I think you want to translate the MPI_SCSI_STATUS_BUSY directly to SAM_STAT_BUSY (i.e. just remove the special casing if). I think your'e on the same page with the folks from VMware, where the've asked us to go back to our old driver code. Meaning we kill the check for MPI_SCSI_STATUS_BUSY, instead the sam status is sent back as is without changing the DID_OK to DID_BUS_BUSY, etc. My problem with that is whether is breaks the Fibre Channel Folks. Will FC failover solution work properly if we go back to the old code? I add Stephen Shirron and Mike Reed. I don't know. Here is an explanation why that fix was needed back about a year ago: When a target device responds with BUSY status, the MPT driver was sending DID_OK to the SCSI mid layer, which caused the IO to be retried indefinitely between the mid layer and the driver. By changing the driver return status to DID_BUS_BUSY, the target BUSY status can now flow through the mid layer to an upper layer Failover driver, which will manage the I/O timeout. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: PROBLEM: LSIFC909 mpt card fails to recognize devices
Justin wrote: Success! Here you are Can you send the dmesg, boot.log, or messages from /var/log ? It appears you've sent me lspci output instead. Eric. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: can't boot 2.6.13
On Thursday, September 08, 2005 3:19 PM, Mike Miller(HP) wrote: I am not able to boot the 2.6.13 version of the kernel. I've tried different systems, tried downloading again, still nothing. Here's the last thing I see from the serial port: md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. RAMDISK: Compressed image found at block 0 input: AT Translated Set 2 keyboard on isa0060/serio0 VFS: Mounted root (ext2 filesystem). logips2pp: Detected unknown logitech mouse model 1 input: PS/2 Logitech Mouse on isa0060/serio1 SCSI subsystem initialized Fusion MPT base driver 3.03.02 Copyright (c) 1999-2005 LSI Logic Corporation We introduced split drivers for 2.6.13. There are new layer drivers that sit ontop of mptscsih.ko. These drivers are split along bus protocal, so there is mptspi.ko, mptfc.ko, and mptsas.ko. This is to tie into the scsi transport layers that are split the same. For 1030(a SPI controller) If your using RedHat, you need to change mptscish to mptspi in /etc/modprobe.conf. If your using SuSE, you need to change mptscish to mptspi in /etc/sysconfig/kernel - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] fusion: whitespace fixes
Please apply
Signed-off-by: Eric Moore [EMAIL PROTECTED]
Index: scsi-misc-2.6/drivers/message/fusion/mptspi.c
===
--- scsi-misc-2.6.orig/drivers/message/fusion/mptspi.c
2005-08-17 19:46:11.0 +0200
+++ scsi-misc-2.6/drivers/message/fusion/mptspi.c
2005-08-17 19:46:46.0 +0200
@@ -162,15 +162,15 @@
u8 *mem;
int error=0;
int r;
-
+
if ((r = mpt_attach(pdev,id)) != 0)
return r;
-
+
ioc = pci_get_drvdata(pdev);
ioc-DoneCtx = mptspiDoneCtx;
ioc-TaskCtx = mptspiTaskCtx;
ioc-InternalCtx = mptspiInternalCtx;
-
+
/* Added sanity check on readiness of the MPT adapter.
*/
if (ioc-last_state != MPI_IOC_STATE_OPERATIONAL) {
Index: scsi-misc-2.6/drivers/message/fusion/mptbase.c
===
--- scsi-misc-2.6.orig/drivers/message/fusion/mptbase.c
2005-08-17 19:46:11.0 +0200
+++ scsi-misc-2.6/drivers/message/fusion/mptbase.c
2005-08-17 21:22:03.0 +0200
@@ -218,8 +218,7 @@
* (also referred to as a IO Controller or IOC).
* This routine must clear the interrupt from the adapter and does
* so by reading the reply FIFO. Multiple replies may be processed
- * per single call to this routine; up to MPT_MAX_REPLIES_PER_ISR
- * which is currently set to 32 in mptbase.h.
+ * per single call to this routine.
*
* This routine handles register-level access of the adapter but
* dispatches (calls) a protocol-specific callback routine
to handle
@@ -279,11 +278,11 @@
cb_idx = mr-u.frame.hwhdr.msgctxu.fld.cb_idx;
mf = MPT_INDEX_2_MFPTR(ioc, req_idx);
- dmfprintk((MYIOC_s_INFO_FMT Got
non-TURBO reply=%p req_idx=%x\n,
- ioc-name, mr, req_idx));
+ dmfprintk((MYIOC_s_INFO_FMT Got
non-TURBO reply=%p req_idx=%x cb_idx=%x Function=%x\n,
+ ioc-name, mr, req_idx,
cb_idx, mr-u.hdr.Function));
DBG_DUMP_REPLY_FRAME(mr)
- /* Check/log IOC log info
+ /* Check/log IOC log info
*/
ioc_stat = le16_to_cpu(mr-u.reply.IOCStatus);
if (ioc_stat
MPI_IOCSTATUS_FLAG_LOG_INFO_AVAILABLE) {
@@ -345,7 +344,7 @@
if ((mf) ((mf =
MPT_INDEX_2_MFPTR(ioc, ioc-req_depth))
|| (mf ioc-req_frames)) ) {
printk(MYIOC_s_WARN_FMT
- mpt_interrupt: Invalid
mf (%p) req_idx (%d)!\n, ioc-name, (void *)mf, req_idx);
+ mpt_interrupt: Invalid
mf (%p)!\n, ioc-name, (void *)mf);
cb_idx = 0;
pa = 0;
freeme = 0;
@@ -399,7 +398,7 @@
* @mf: Pointer to original MPT request frame
* @reply: Pointer to MPT reply frame (NULL if TurboReply)
*
- * Returns 1 indicating original alloc'd request frame ptr
+ * Returns 1 indicating original alloc'd request frame ptr
* should be freed, or 0 if it shouldn't.
*/
static int
@@ -408,28 +407,17 @@
int freereq = 1;
u8 func;
- dprintk((MYIOC_s_INFO_FMT mpt_base_reply() called\n,
ioc-name));
-
- if ((mf == NULL) ||
- (mf = MPT_INDEX_2_MFPTR(ioc, ioc-req_depth))) {
- printk(MYIOC_s_ERR_FMT NULL or BAD request
frame ptr! (=%p)\n,
- ioc-name, (void *)mf);
- return 1;
- }
-
- if (reply == NULL) {
- dprintk((MYIOC_s_ERR_FMT Unexpected NULL Event
(turbo?) reply!\n,
- ioc-name));
- return 1;
- }
+ dmfprintk((MYIOC_s_INFO_FMT mpt_base_reply()
called\n, ioc-name));
+#if defined(MPT_DEBUG_MSG_FRAME)
if (!(reply-u.hdr.MsgFlags
MPI_MSGFLAGS_CONTINUATION_REPLY)) {
dmfprintk((KERN_INFO MYNAM : Original request
frame (@%p) header\n, mf));
DBG_DUMP_REQUEST_FRAME_HDR(mf)
}
+#endif
func = reply-u.hdr.Function;
- dprintk((MYIOC_s_INFO_FMT mpt_base_reply, Function=%02Xh\n,
+ dmfprintk((MYIOC_s_INFO_FMT mpt_base_reply, Function=%02Xh\n,
ioc-name, func));
if (func == MPI_FUNCTION_EVENT_NOTIFICATION) {
@@ -448,8 +436,14 @@
* Hmmm... It seems that
EventNotificationReply is an exception
* to the rule of one reply per request.
*/
- if (pEvReply-MsgFlags
MPI_MSGFLAGS_CONTINUATION_REPLY)
+ if (pEvReply-MsgFlags
RE: [PATCH 3/4] fusion: endianess fixes
Please apply
Signed-off-by: Eric Moore [EMAIL PROTECTED]
Assorted endianess fixes. I'll work on full endianess annotations
later.
Index: scsi-misc-2.6/drivers/message/fusion/mptbase.c
===
--- scsi-misc-2.6.orig/drivers/message/fusion/mptbase.c
2005-08-17 19:47:15.0 +0200
+++ scsi-misc-2.6/drivers/message/fusion/mptbase.c
2005-08-17 19:48:53.0 +0200
@@ -2171,7 +2171,7 @@
facts-IOCExceptions =
le16_to_cpu(facts-IOCExceptions);
facts-IOCStatus = le16_to_cpu(facts-IOCStatus);
facts-IOCLogInfo = le32_to_cpu(facts-IOCLogInfo);
- status = facts-IOCStatus MPI_IOCSTATUS_MASK;
+ status = le16_to_cpu(facts-IOCStatus)
MPI_IOCSTATUS_MASK;
/* CHECKME! IOCStatus, IOCLogInfo */
facts-ReplyQueueDepth =
le16_to_cpu(facts-ReplyQueueDepth);
@@ -4800,8 +4800,8 @@
pReq-Reserved3 = 0;
pReq-NumAddressBytes = 0x01;
pReq-Reserved4 = 0;
- pReq-DataLength = 0x04;
- pdev = (struct pci_dev *) ioc-pcidev;
+ pReq-DataLength = cpu_to_le16(0x04);
+ pdev = ioc-pcidev;
if (pdev-devfn 1)
pReq-DeviceAddr = 0xB2;
else
Index: scsi-misc-2.6/drivers/message/fusion/mptctl.c
===
--- scsi-misc-2.6.orig/drivers/message/fusion/mptctl.c
2005-08-17 19:46:11.0 +0200
+++ scsi-misc-2.6/drivers/message/fusion/mptctl.c
2005-08-17 19:47:37.0 +0200
@@ -242,7 +242,7 @@
/* Set the command status to GOOD if IOC Status is GOOD
* OR if SCSI I/O cmd and data underrun or
recovered error.
*/
- iocStatus = reply-u.reply.IOCStatus
MPI_IOCSTATUS_MASK;
+ iocStatus =
le16_to_cpu(reply-u.reply.IOCStatus) MPI_IOCSTATUS_MASK;
if (iocStatus == MPI_IOCSTATUS_SUCCESS)
ioc-ioctl-status |=
MPT_IOCTL_STATUS_COMMAND_GOOD;
Index: scsi-misc-2.6/drivers/message/fusion/mptscsih.c
===
--- scsi-misc-2.6.orig/drivers/message/fusion/mptscsih.c
2005-08-17 19:46:46.0 +0200
+++ scsi-misc-2.6/drivers/message/fusion/mptscsih.c
2005-08-17 19:47:37.0 +0200
@@ -3453,7 +3453,7 @@
* some type of error occurred.
*/
MpiRaidActionReply_t*pr =
(MpiRaidActionReply_t *)mr;
- if (pr-ActionStatus ==
MPI_RAID_ACTION_ASTATUS_SUCCESS)
+ if
(le16_to_cpu(pr-ActionStatus) == MPI_RAID_ACTION_ASTATUS_SUCCESS)
completionCode =
MPT_SCANDV_GOOD;
else
completionCode =
MPT_SCANDV_SOME_ERROR;
@@ -4002,9 +4002,9 @@
dnegoprintk((syncronize cache: id=%d
width=0 factor=MPT_ASYNC
offset=0 negoFlags=%x
request=%x config=%x\n,
id, flags, requested, configuration));
- pcfg1Data-RequestedParameters =
le32_to_cpu(requested);
+ pcfg1Data-RequestedParameters =
cpu_to_le32(requested);
pcfg1Data-Reserved = 0;
- pcfg1Data-Configuration =
le32_to_cpu(configuration);
+ pcfg1Data-Configuration =
cpu_to_le32(configuration);
cfg.pageAddr = (bus8) | id;
mpt_config(hd-ioc, cfg);
}
@@ -5254,7 +5254,7 @@
/* Update tmax values with those from Device Page 0.*/
pPage0 = (SCSIDevicePage0_t *) pPage;
if (pPage0) {
- val = cpu_to_le32(pPage0-NegotiatedParameters);
+ val = le32_to_cpu(pPage0-NegotiatedParameters);
dv-max.width = val
MPI_SCSIDEVPAGE0_NP_WIDE ? 1 : 0;
dv-max.offset =
(valMPI_SCSIDEVPAGE0_NP_NEG_SYNC_OFFSET_MASK) 16;
dv-max.factor =
(valMPI_SCSIDEVPAGE0_NP_NEG_SYNC_PERIOD_MASK) 8;
@@ -5282,12 +5282,12 @@
dv-now.offset, val,
configuration, dv-now.flags);
dnegoprintk((Setting Max: id=%d
width=%d factor=%x offset=%x negoFlags=%x request=%x config=%x\n,
id, dv-now.width,
dv-now.factor, dv-now.offset, dv-now.flags, val, configuration));
- pPage1-RequestedParameters = le32_to_cpu(val);
+ pPage1-RequestedParameters = cpu_to_le32(val);
pPage1-Reserved = 0;
- pPage1-Configuration =
le32_to_cpu(configuration);
+ pPage1-Configuration =
RE: [PATCH 1/4] fusion: update LSI headers
Please apply Signed-off-by: Eric Moore [EMAIL PROTECTED] Index: scsi-misc-2.6/drivers/message/fusion/lsi/mpi_cnfg.h === --- scsi-misc-2.6.orig/drivers/message/fusion/lsi/mpi_cnfg.h 2005-08-17 12:03:52.0 +0200 +++ scsi-misc-2.6/drivers/message/fusion/lsi/mpi_cnfg.h 2005-08-17 12:04:01.0 +0200 @@ -6,7 +6,7 @@ * Title: MPI Config message, structures, and Pages * Creation Date: July 27, 2000 * - *mpi_cnfg.h Version: 01.05.08 + *mpi_cnfg.h Version: 01.05.09 * * Version History * --- @@ -232,6 +232,23 @@ * New physical mapping mode in SAS IO Unit Page 2. * Added CONFIG_PAGE_SAS_ENCLOSURE_0. * Added Slot and Enclosure fields to SAS Device Page 0. + * 06-24-05 01.05.09 Added EEDP defines to IOC Page 1. + * Added more RAID type defines to IOC Page 2. + * Added Port Enable Delay settings to BIOS Page 1. + * Added Bad Block Table Full define to RAID Volume Page 0. + * Added Previous State defines to RAID Physical Disk + * Page 0. + * Added Max Sata Targets define for DiscoveryStatus field + * of SAS IO Unit Page 0. + * Added Device Self Test to Control Flags of SAS IO Unit + * Page 1. + * Added Direct Attach Starting Slot Number define for SAS + * IO Unit Page 2. + * Added new fields in SAS Device Page 2 for enclosure + * mapping. + * Added OwnerDevHandle and Flags field to SAS PHY Page 0. + * Added IOC GPIO Flags define to SAS Enclosure Page 0. + * Fixed the value for MPI_SAS_IOUNIT1_CONTROL_DEV_SATA_SUPPORT. * -- */ @@ -477,6 +494,7 @@ #define MPI_MANUFACTPAGE_DEVICEID_FC929X(0x0626) #define MPI_MANUFACTPAGE_DEVICEID_FC939X(0x0642) #define MPI_MANUFACTPAGE_DEVICEID_FC949X(0x0640) +#define MPI_MANUFACTPAGE_DEVICEID_FC949ES (0x0646) /* SCSI */ #define MPI_MANUFACTPAGE_DEVID_53C1030 (0x0030) #define MPI_MANUFACTPAGE_DEVID_53C1030ZC(0x0031) @@ -769,9 +787,13 @@ } CONFIG_PAGE_IOC_1, MPI_POINTER PTR_CONFIG_PAGE_IOC_1, IOCPage1_t, MPI_POINTER pIOCPage1_t; -#define MPI_IOCPAGE1_PAGEVERSION(0x02) +#define MPI_IOCPAGE1_PAGEVERSION(0x03) /* defines for the Flags field */ +#define MPI_IOCPAGE1_EEDP_MODE_MASK (0x0700) +#define MPI_IOCPAGE1_EEDP_MODE_OFF (0x) +#define MPI_IOCPAGE1_EEDP_MODE_T10 (0x0100) +#define MPI_IOCPAGE1_EEDP_MODE_LSI_1(0x0200) #define MPI_IOCPAGE1_INITIATOR_CONTEXT_REPLY_DISABLE(0x0010) #define MPI_IOCPAGE1_REPLY_COALESCING (0x0001) @@ -795,6 +817,11 @@ #define MPI_RAID_VOL_TYPE_IS(0x00) #define MPI_RAID_VOL_TYPE_IME (0x01) #define MPI_RAID_VOL_TYPE_IM(0x02) +#define MPI_RAID_VOL_TYPE_RAID_5(0x03) +#define MPI_RAID_VOL_TYPE_RAID_6(0x04) +#define MPI_RAID_VOL_TYPE_RAID_10 (0x05) +#define MPI_RAID_VOL_TYPE_RAID_50 (0x06) +#define MPI_RAID_VOL_TYPE_UNKNOWN (0xFF) /* IOC Page 2 Volume Flags values */ @@ -820,13 +847,17 @@ } CONFIG_PAGE_IOC_2, MPI_POINTER PTR_CONFIG_PAGE_IOC_2, IOCPage2_t, MPI_POINTER pIOCPage2_t; -#define MPI_IOCPAGE2_PAGEVERSION(0x02) +#define MPI_IOCPAGE2_PAGEVERSION(0x03) /* IOC Page 2 Capabilities flags */ #define MPI_IOCPAGE2_CAP_FLAGS_IS_SUPPORT (0x0001) #define MPI_IOCPAGE2_CAP_FLAGS_IME_SUPPORT (0x0002) #define MPI_IOCPAGE2_CAP_FLAGS_IM_SUPPORT (0x0004) +#define MPI_IOCPAGE2_CAP_FLAGS_RAID_5_SUPPORT (0x0008) +#define MPI_IOCPAGE2_CAP_FLAGS_RAID_6_SUPPORT (0x0010) +#define MPI_IOCPAGE2_CAP_FLAGS_RAID_10_SUPPORT (0x0020) +#define MPI_IOCPAGE2_CAP_FLAGS_RAID_50_SUPPORT (0x0040) #define MPI_IOCPAGE2_CAP_FLAGS_SES_SUPPORT (0x2000) #define MPI_IOCPAGE2_CAP_FLAGS_SAFTE_SUPPORT(0x4000) #define MPI_IOCPAGE2_CAP_FLAGS_CROSS_CHANNEL_SUPPORT(0x8000) @@ -945,7 +976,7 @@ } CONFIG_PAGE_BIOS_1, MPI_POINTER PTR_CONFIG_PAGE_BIOS_1, BIOSPage1_t, MPI_POINTER pBIOSPage1_t; -#define MPI_BIOSPAGE1_PAGEVERSION
RE: [PATCH 4/4] fusion: extended config header support
Please apply
Signed-off-by: Eric Moore [EMAIL PROTECTED]
Index: scsi-misc-2.6/drivers/message/fusion/mptbase.c
===
--- scsi-misc-2.6.orig/drivers/message/fusion/mptbase.c
2005-08-18 15:24:27.0 +0200
+++ scsi-misc-2.6/drivers/message/fusion/mptbase.c
2005-08-18 15:24:28.0 +0200
@@ -485,10 +485,21 @@
pCfg-status = status;
if (status == MPI_IOCSTATUS_SUCCESS) {
- pCfg-hdr-PageVersion
= pReply-Header.PageVersion;
- pCfg-hdr-PageLength =
pReply-Header.PageLength;
- pCfg-hdr-PageNumber =
pReply-Header.PageNumber;
- pCfg-hdr-PageType =
pReply-Header.PageType;
+ if ((pReply-Header.PageType
+ MPI_CONFIG_PAGETYPE_MASK) ==
+
MPI_CONFIG_PAGETYPE_EXTENDED) {
+
pCfg-cfghdr.ehdr-ExtPageLength =
+
le16_to_cpu(pReply-ExtPageLength);
+
pCfg-cfghdr.ehdr-ExtPageType =
+ pReply-ExtPageType;
+ }
+
pCfg-cfghdr.hdr-PageVersion = pReply-Header.PageVersion;
+
+ /* If this is a regular
header, save PageLength. */
+ /* LMP Do this better
so not using a reserved field! */
+
pCfg-cfghdr.hdr-PageLength = pReply-Header.PageLength;
+
pCfg-cfghdr.hdr-PageNumber = pReply-Header.PageNumber;
+
pCfg-cfghdr.hdr-PageType = pReply-Header.PageType;
}
}
@@ -3821,7 +3832,7 @@
hdr.PageLength = 0;
hdr.PageNumber = 0;
hdr.PageType = MPI_CONFIG_PAGETYPE_LAN;
- cfg.hdr = hdr;
+ cfg.cfghdr.hdr = hdr;
cfg.physAddr = -1;
cfg.action = MPI_CONFIG_ACTION_PAGE_HEADER;
cfg.dir = 0;
@@ -3865,7 +3876,7 @@
hdr.PageLength = 0;
hdr.PageNumber = 1;
hdr.PageType = MPI_CONFIG_PAGETYPE_LAN;
- cfg.hdr = hdr;
+ cfg.cfghdr.hdr = hdr;
cfg.physAddr = -1;
cfg.action = MPI_CONFIG_ACTION_PAGE_HEADER;
cfg.dir = 0;
@@ -3932,7 +3943,7 @@
hdr.PageLength = 0;
hdr.PageNumber = 0;
hdr.PageType = MPI_CONFIG_PAGETYPE_FC_PORT;
- cfg.hdr = hdr;
+ cfg.cfghdr.hdr = hdr;
cfg.physAddr = -1;
cfg.action = MPI_CONFIG_ACTION_PAGE_HEADER;
cfg.dir = 0;
@@ -4014,7 +4025,7 @@
hdr.PageLength = 0;
hdr.PageNumber = 2;
hdr.PageType = MPI_CONFIG_PAGETYPE_IO_UNIT;
- cfg.hdr = hdr;
+ cfg.cfghdr.hdr = hdr;
cfg.physAddr = -1;
cfg.action = MPI_CONFIG_ACTION_PAGE_HEADER;
cfg.dir = 0;
@@ -4104,7 +4115,7 @@
header.PageLength = 0;
header.PageNumber = 0;
header.PageType = MPI_CONFIG_PAGETYPE_SCSI_PORT;
- cfg.hdr = header;
+ cfg.cfghdr.hdr = header;
cfg.physAddr = -1;
cfg.pageAddr = portnum;
cfg.action = MPI_CONFIG_ACTION_PAGE_HEADER;
@@ -4177,7 +4188,7 @@
header.PageLength = 0;
header.PageNumber = 2;
header.PageType = MPI_CONFIG_PAGETYPE_SCSI_PORT;
- cfg.hdr = header;
+ cfg.cfghdr.hdr = header;
cfg.physAddr = -1;
cfg.pageAddr = portnum;
cfg.action = MPI_CONFIG_ACTION_PAGE_HEADER;
@@ -4245,7 +4256,7 @@
header.PageLength = 0;
header.PageNumber = 1;
header.PageType = MPI_CONFIG_PAGETYPE_SCSI_DEVICE;
- cfg.hdr = header;
+ cfg.cfghdr.hdr = header;
cfg.physAddr = -1;
cfg.pageAddr = portnum;
cfg.action = MPI_CONFIG_ACTION_PAGE_HEADER;
@@ -4254,8 +4265,8 @@
if (mpt_config(ioc, cfg) != 0)
return -EFAULT;
- ioc-spi_data.sdp1version = cfg.hdr-PageVersion;
- ioc-spi_data.sdp1length = cfg.hdr-PageLength;
+ ioc-spi_data.sdp1version = cfg.cfghdr.hdr-PageVersion;
+ ioc-spi_data.sdp1length = cfg.cfghdr.hdr-PageLength;
header.PageVersion = 0;
header.PageLength = 0;
@@ -4264,8 +4275,8 @@
if (mpt_config(ioc, cfg) != 0)
return -EFAULT;
- ioc-spi_data.sdp0version = cfg.hdr-PageVersion;
- ioc-spi_data.sdp0length = cfg.hdr-PageLength;
+ ioc-spi_data.sdp0version = cfg.cfghdr.hdr-PageVersion;
+ ioc-spi_data.sdp0length = cfg.cfghdr.hdr-PageLength;
dcprintk((MYIOC_s_INFO_FMT Headers: 0: version %d length %d\n,
ioc-name, ioc-spi_data.sdp0version,
ioc-spi_data.sdp0length));
@@ -4307,7
RE: [PATCH 0/2] fusion SAS support
On Monday, August 29, 2005 2:01 AM, Christoph Hellwig wrote:
The expander with one crossover cable has been shipped to you
this morning. The crossover should be connected to phy0 on the expander.
/sys/class/sas_port/port-4:3/port-12:0
/sys/class/sas_port/port-4:3/port-12:1
/sys/class/sas_port/port-4:3/port-12:2
/sys/class/sas_port/port-4:3/port-12:3
If so, then the sas_transport code needs to change.
In the /sys/class/ hierachy they will have to be flat due to the
way the generic class_device code works. No it's still open whether
we will have a flat hierachy of class_devices or whether we'll attach
extender ports to the struct device of the parent port. I'll prefer
the former because it keeps the hierachy simpler and mirrors what is
done in FibreChannel, James prefers the latter. I'll
probably prototype
both.
Does flat means all sas hbas and expanders would reside in
/sys/class/sas_port ??
How would one figure out the topology parent-child relationship
between hbas-expanders? I think with large topologies having everything
on the same level will be very messy.
I think getting the NDA and docs is more important.
That is on the way being worked. Hopefully very soon.
I have the spec sitting here next to me.
Ask if you have doubts on anything, and I will explain.
What I really
want to do is to call scsi_scan_target for every sas device
that's a scsi
target, so that we can support multi-lun devices easily and
coherently with
other SCSI transports. Now I need to figure out how to properly get
information out of the Fusion firmware to only report
attached sas devices,
not individual luns, and I need to make sure different sas
devices never
get the same target id, so scsi_scan_device does the right
thing. This
could mean I need to the work I suggested to Luben in a
previous mail to
make -id meaningless for SAS and similar transports, or a
scsi midlayer
to fusion target id mapping.
I will explain - in this loop below in your sas patch:
+ if (*phy_counter = ioc-num_sas_ports) {
+ sas_add_target(ioc-sas_ports[pg0-PhysicalPort],
+ ioc-sas_attached[pg0-PhysicalPort],
+ pg0-Bus, pg0-TargetID);
+ } else
add this check below - before calling sas_add_target,
so you will get the unique scans for each valid scsi target.
The SMP devices and phys entries for the direct hba phys will be ignored:
if (le32_to_cpu(sasDevicePg0-DeviceInfo)
(MPI_SAS_DEVICE_INFO_SSP_TARGET |
MPI_SAS_DEVICE_INFO_STP_TARGET |
MPI_SAS_DEVICE_INFO_SATA_DEVICE )) {
Also - I suggest maintaining a link list of devices in
the driver when sas_add_target is called.
This having the sas address, and respective HCTL mapping, and
other properties. Something similar to the function called
mpt_sas_get_info() in the 3.02.55 driver.
Thus if you decide to make -id meaningless for SAS(Lubens thread),
the scsi core could merely send sas address, or maybe an object, or handle,
or what ever you decide.
Thus the driver could map back to the created object/handle when
sas_add_target occured.
Then for queue command, it can take the object/handle, then translate
to internal bus/target mapping so SCSI_IO request can be sent to
the firmware as its is today.
Hot plug support - how is this going to be done. Take a look
at mptscsih_hot_plug_worker_thread, that I sent in 3.02.55.
We'll probably have a workqueue for it in the transport
class, but hotplug
support isn't on the top of my TODO list, so it'll have to
wait a little.
What ever you decide. Just to let you know the sas firmware send
device_added and device_not_responding events, so we know when
when devices come and go. We also have events for raid volumes
being added and removed on the fly, and the corresponding hidden phys disk
coming and going as well. The current hotplug workqueue in the driver is
handling
raid and non-raid events for devices coming and going.
Something for you to consider when you get around to looking at hot plug.
Eric Moore
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] fusion SAS support
On Wednesday, August 24, 2005 3:14 AM, Christoph Hellwig wrote:
On Wed, Aug 24, 2005 at 02:10:14AM -0700, Jeremy Higdon wrote:
However, after updating firmware on the 1064, this latter problem
seems to be fixed (still doesn't discover devices on the expander
at driver init).
As mentioned expanders aren't tested at all yet, I'll fix it as soon
as I have an expander and hopefully soon the fusion specs
(still waiting
for lsi to contact me about the nda)
I will ship you a SASx12 Expander on Monday. My manager is working
on NDA's for both you and James, and hopefully they will be completed
very soon. I sent you two SAS HBA, perhaps one of those you could
send to James Bottomley.
I apologize its taking so long to review the patches you sent last
week, but I have been swamped working issues for many different customers.
I only began looking at your patches last night. Here are some comments:
+ ioc-sas_ports[i] = sas_port_add(ioc-sh, i, attrs);
+ if (IS_ERR(ioc-sas_ports[i])) {
+ error = PTR_ERR(ioc-sas_ports[i]);
+ goto out_free_ports;
+ }
This code is only attaching ports for the direct ports. I have
a LSI SAS1064 - 4 ports - so it only reports four ports.
I see:
/sys/class/sas_port/port-4:0
/sys/class/sas_port/port-4:1
/sys/class/sas_port/port-4:2
/sys/class/sas_port/port-4:3
In my configuration I have SASx12 sitting on the 3rd port.
Expander support is not there in your version of the driver.
How do you propose to report the expanders 12 ports that is attached to
/sys/class/sas_port/port-4:3 ?? Will I see all the 12 ports added
to /sys/class/sas_port/ or should these ports be inside
/sys/class/sas_port/port-4:3 ?? Such as
/sys/class/sas_port/port-4:3/port-12:0
/sys/class/sas_port/port-4:3/port-12:1
/sys/class/sas_port/port-4:3/port-12:2
/sys/class/sas_port/port-4:3/port-12:3
If so, then the sas_transport code needs to change.
+ if (*phy_counter = ioc-num_sas_ports) {
+ sas_add_target(ioc-sas_ports[pg0-PhysicalPort],
+ ioc-sas_attached[pg0-PhysicalPort],
+ pg0-Bus, pg0-TargetID)
My expander has 7 devices attached. There is 5 SATA and 2 SAS devices.
From the function mptsas_probe_attached_device - this will
call Sas Device Page 0, this containing all the devices seen in
the domain. The function sas_add_target() will be called
for all seven devices, to include the SMP expander; e.g. 8 times.
During the time it called sas_add_target() 8 times, its sending the same
ioc-sas_ports and ioc-sas_attached data pointers because all 8
devices are at pg0-PhysicalPort=3. Thus how will setup the
12 ports for expander? The information regarding
these 12 ports can be obtained via Sas Expander Page 1.
I guess we can add this to the function mptsas_probe_phy() so ports for
direct attached and expanders are reported? What do you think, or
did you have another idea bout this? I'm not sure about how
calling sas_port_add() 4 times for the HBA, and 12 times
for the exander, how that would be populating the tree. I guess you want
to wait till you recieve the expander to comment on this?
Additional comments:
Loading the driver as modules - will not work because its missing
EXPORT_SYMBOL(mptbase_sas_persist_operation) in mptbase.c
We have Integrated RAID support for SAS - thus in my code(3.02.55) I have
broken out the RAID related parameters from typedef _ScsiCfgData
into another structure called _RaidCfgData - I would suggest
picking up these changes.
Hot plug support - how is this going to be done. Take a look
at mptscsih_hot_plug_worker_thread, that I sent in 3.02.55.
There are other minor items left out in your port, which I would like
added. I will go ahead make those changes and send across a patch for that.
Eric Moore
LSI Logic
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] SPI transport class and generic Domain Validation for fusion
On Monday, August 08, 2005 3:47 PM, James Bottomley wrote: Eric, This attached patch should do DV on both physical devices and the underlying devices of fusion IM assemblies (providing you apply it on top of the prior underlying device exposure patch), which, I believe was your only outstanding concern with the last generic DV patch. There is one slight unsightly piece: the IM device still attaches to the transport class however all the parameters it shows actually belong to the underlying device at that id ... I could do with finding a way of persuading the SPI transport class not to attach to RAID devices. Since this addresses all of LSI's prior concerns, may I now apply it? Roy/Laura/Roy/Steve, and others - This is a patch to remove our internal dv(domain validation) code and replace with generic dv implemention in the linux kernel. This is a year old push from kernel.org , for the drivers in upstream kernel. James: I've not been able to review this patch, nor the other one you sent. On concern is whether spi transport handle asyn events? Meaning will it do domain validation on RAID1 volume - for a new drive that was hot swapped with a good disk? In the driver look at mptscsih_event_process - this code is handling a aync event from the firmware telling the driver to perform dv on disk that was just added. Pls don't rush this into the kernel untill we have time to review, and/or talk to our internal test teams on test effort, and/or talk to our customers explaning the risk in removing this code. Eric Moore - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] MPT FUSION driver causes panic on bootup on PPC 970 k ernel
These endian fix's have already been submitted long ago. Try a newer kernel, such as 2.6.13-rc3. Thankyou, Eric Moore LSI Logic On Monday, July 25, 2005 3:48 PM, Mark Bellon wrote: A PPC 970 kernel with the MPT FUSION driver configured in would cause the kernel to panic. The problem occurs because of some apparently incorrect logic dealing with the cpu_to_le* and le*_to_cpu routines. Patch is attached. Comments? mark - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 22/82] remove linux/version.h from drivers/message/fus ion
On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
In general, this construct:
-#if (LINUX_VERSION_CODE KERNEL_VERSION(2,6,6))
-static int inline scsi_device_online(struct scsi_device *sdev)
-{
- return sdev-online;
-}
-#endif
is better tested as:
#ifndef scsi_device_inline
static int inline scsi_device_online(struct scsi_device *sdev)
{
return sdev-online;
}
#endif
when you can. It cleanly eliminates the version test, and tests for
exactly what you're looking for - is this function defined.
What you illustrated above is not going to work.
If your doing #ifndef around a function, such as scsi_device_online, it's
not going to compile
when scsi_device_online is already implemented in the kernel tree.
The routine scsi_device_online is a function, not a define. For a define
this would work.
I'm trying your example around msleep, msleep_interruptible, and
msecs_to_jiffies, and
my code simply won't compile in SLES9 SP2(-191). In SLES9 SP1(-139), these
three routines were not implemented and
your suggestion works. I won't be able to to a linux version check as this
change occurred between service packs
of the 2.6.5 kernel suse tree. Anybody on the linux forums have any ideas?
Example:
#ifdef msleep
static void inline msleep(unsigned long msecs)
{
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(msecs_to_jiffies(msecs) + 1);
}
#endif
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 22/82] remove linux/version.h from drivers/message/fus ion
On Wednesday, July 13, 2005 8:38 AM, Christoph Hellwig wrote:
In general, this construct:
-#if (LINUX_VERSION_CODE KERNEL_VERSION(2,6,6))
-static int inline scsi_device_online(struct scsi_device *sdev)
-{
- return sdev-online;
-}
-#endif
is better tested as:
#ifndef scsi_device_inline
static int inline scsi_device_online(struct scsi_device *sdev)
{
return sdev-online;
}
#endif
Even better fusion should stop using this function because doing so
is broken.. We tried that long ago but it got stuck somewhere.
Christoph - We have already fixed the problem long ago; e.g.
remember when you asked me to kill the timers from the eh threads.
Thus in todays drivers you will not find scsi_device_online called anywhere
in
the fusion drivers.
I only objected to killing the linux_compat.h file because its being used
in our internal supported drivers, and it makes it easier upgrade path
for maintaining mainstream drivers if that was left behind in the kernel
tree.
However everybody has ambushed me on this stance, so go ahead and kill it.
We'll manage fine without it.
Eric Moore
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] mptfusion: Kconfig Adding new bus type drivers for fu sion drivers.
mptfusion patch 1/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) Kconfig - added new mptspi and mptfc scsi lld drivers (2) Kconfig - increased MAX_SGE from 40 to 128 (2) Makefile - compilation support for split drivers (3) Makefile - cleaned up debug defines; e.g. removed obsolete, added others Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-1-kconfig.patch Description: Binary data
[PATCH 3/7] mptfusion: mptctl Remove credits and update copyright
mptfusion patch 3/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) mptctl.c: Remove credits and update copyright (2) mptctl.c: cleanup in get_iocinfo Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-3-mptctl.patch Description: Binary data
[PATCH 4/7] mptfusion: mptlan Remove credits and update copyright
mptfusion patch 4/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) mptlan.c: Remove credits and update copyright (2) mptlan.c: Remove -sralston references Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-4-mptlan.patch Description: Binary data
[PATCH 2/7] mptfusion: mptbase cleanup, split driver support, DMA 32_BIT_MASK
mptfusion patch 2/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) mptbase.c: Move registering pci ids to scsi lld drivers (2) mptbase.c: Use the DMA_32BIT_MASK constant (3) mptbase.c: Fix for multiple pci domains (4) mptbase.c: Remove le32 conversion from BlockSize, which was u8 size (5) mptbase.c: Remove credits, -sralston references , update copyright (6) mptbase.c: split driver support Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-2-mptbase.patch Description: Binary data
[PATCH 7/7] mptfusion: mptfc Adding Stub Driver - Fiber Channel
mptfusion patch 7/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) mptfc.c: This driver is having module_init, module_exit, and probe. (2) mptfc.c: Registering for Fibre Channel pci ids are done from this module. (3) mptfc.c: Convert MODULE_PARM to module_param Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-7-mptfc.patch Description: Binary data
[PATCH 5/7] mptfusion: mptscsih Split driver support
mptfusion patch 5/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) mptscsih.c: Remove credits, -sralston references , update copyright (2) mptscsih.c: split driver support (3) mptscsih.c: module_init, module_exit, and probe routines moved to new stub drivers, mptfc and mptspi (4) mptscsih.c: some global parameters are moved to MPT_SCSI_HOST (5) mptscsih.c: removed scsi_device_online check. Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-5-mptscsih.patch Description: Binary data
[PATCH 3/7] mptfusion: mptctl Remove credits and update copyright
mptfusion patch 3/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) mptctl.c: Remove credits and update copyright (2) mptctl.c: cleanup in get_iocinfo Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-3-mptctl Description: Binary data
[PATCH 2/7] mptfusion: mptbase cleanup, split driver support, DMA 32_BIT_MASK
mptfusion patch 2/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) mptbase.c: Move registering pci ids to scsi lld drivers (2) mptbase.c: Use the DMA_32BIT_MASK constant (3) mptbase.c: Fix for multiple pci domains (4) mptbase.c: Remove le32 conversion from BlockSize, which was u8 size (5) mptbase.c: Remove credits, -sralston references , update copyright (6) mptbase.c: split driver support Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-2-mptbase Description: Binary data
[PATCH 1/7] mptfusion: Kconfig Adding new bus type drivers for fu sion drivers.
mptfusion patch 1/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) Kconfig - added new mptspi and mptfc scsi lld drivers (2) Kconfig - increased MAX_SGE from 40 to 128 (2) Makefile - compilation support for split drivers (3) Makefile - cleaned up debug defines; e.g. removed obsolete, added others Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-1-kconfig Description: Binary data
[PATCH 4/7] mptfusion: mptlan Remove credits and update copyright
mptfusion patch 4/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) mptlan.c: Remove credits and update copyright (2) mptlan.c: Remove -sralston references Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-4-mptlan Description: Binary data
[PATCH 5/7] mptfusion: mptscsih Split driver support
mptfusion patch 5/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) mptscsih.c: Remove credits, -sralston references , update copyright (2) mptscsih.c: split driver support (3) mptscsih.c: module_init, module_exit, and probe routines moved to new stub drivers, mptfc and mptspi (4) mptscsih.c: some global parameters are moved to MPT_SCSI_HOST (5) mptscsih.c: removed scsi_device_online check. Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-5-mptscsih Description: Binary data
[PATCH 7/7] mptfusion: mptfc Adding Stub Driver - Fiber Channel
mptfusion patch 7/7: This patch can also be found at this URL: ftp://ftp.lsil.com/HostAdapterDrivers/linux/FiberChannel/2.6-kernel/3.03.00/ Changelog: (1) mptfc.c: This driver is having module_init, module_exit, and probe. (2) mptfc.c: Registering for Fibre Channel pci ids are done from this module. (3) mptfc.c: Convert MODULE_PARM to module_param Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-7-mptfc Description: Binary data
RE: Question about scsi_device_online() usage in mptscsih
On Friday, April 15, 2005 8:30 AM, James Bottomley wrote: On Fri, 2005-04-15 at 19:13 +0900, Masao Fukuchi wrote: The sequence is: 1.Host issues SCSI command to fusion MPT driver. 2.Mid layer detects command timeout and then performs error recovery sequence. But the sequence fails and it causes device offline. (fusion MPT driver still hold the command) 4.Fusion MPT driver activates host reset and calls mptscsih_flush_running_cmds(). Well, this is the error: The Fusion host reset should be activated from the eh_host_reset_handler. Since I removed the eh timers, this is not going to happen. The driver is always waiting for task management request to complete before returning control back to the mid-layer. Before when the driver used timers, the eh thread returned immediately back to the mid-layer, and the actual task management request to the firmware was delayed and completed later. If the task management request didn't complete, the timer would expire, and host reset would be called, and it was possible to opps as Fukuchi has indicated. Thus I think its safe to say, we can remove the scsi_device_online from mptscsih_flush_running_cmds. Right?? Eric Moore LSI Logic - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mptscsih: MODULE_PARM() - module_param()
This request makes very good sense. I'm working on this, and hopefully resubmit everthing very soon. Regards, Eric Moore On Tuesday, April 12, 2005 10:38 AM, James Bottomley wrote: On Tue, 2005-04-05 at 14:30 -0600, Moore, Eric Dean wrote: Ok fine - This fix is already there in the series of patches I provided a week ago for splitting the mpt fusion drivers into seperate bus type drivers. James any word on whether those series of patches will get approved? The patches themselves look fine. However, there's a problem which I just discovered on putting it together and taking it for a test spin: the MODULE_DEVICE_TABLE directive is still in mptbase. This means that the udev/hotplug system thinks that when it's loaded mptbase everything's done, which now means that everyone loses their devices since the upper drivers aren't loaded. To make this all work and keep the distros happy, the MODULE_DEVICE_TABLE has to be split out and placed into the mptspi or mptfc components. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mptscsih: MODULE_PARM() - module_param()
Ok fine - This fix is already there in the series of patches I provided a week ago for splitting the mpt fusion drivers into seperate bus type drivers. James any word on whether those series of patches will get approved? In addition, Steve Ralston is no longer working in this group. No need to copy him on this. Eric Moore LSI Logic. On Tuesday, April 05, 2005 1:18 PM, Magnus Damm wrote: Convert obsolete MODULE_PARM() to module_param(). This also fixes mpt_factor that currently is a short parameter (h) but the actual variable is an int. Signed-off-by: Magnus Damm [EMAIL PROTECTED] --- linux-2.6.12-rc2/drivers/message/fusion/mptscsih.c 2005-04-05 16:59:53.0 +0200 +++ linux-2.6.12-rc2-autoparam/drivers/message/fusion/mptscsih.c 2005-04-05 20:28:11.459725880 +0200 @@ -98,23 +98,23 @@ /* Command line args */ static int mpt_dv = MPTSCSIH_DOMAIN_VALIDATION; -MODULE_PARM(mpt_dv, i); +module_param(mpt_dv, int, 0); MODULE_PARM_DESC(mpt_dv, DV Algorithm: enhanced=1, basic=0 (default=MPTSCSIH_DOMAIN_VALIDATION=1)); static int mpt_width = MPTSCSIH_MAX_WIDTH; -MODULE_PARM(mpt_width, i); +module_param(mpt_width, int, 0); MODULE_PARM_DESC(mpt_width, Max Bus Width: wide=1, narrow=0 (default=MPTSCSIH_MAX_WIDTH=1)); static int mpt_factor = MPTSCSIH_MIN_SYNC; -MODULE_PARM(mpt_factor, h); +module_param(mpt_factor, int, 0); MODULE_PARM_DESC(mpt_factor, Min Sync Factor (default=MPTSCSIH_MIN_SYNC=0x08)); static int mpt_saf_te = MPTSCSIH_SAF_TE; -MODULE_PARM(mpt_saf_te, i); +module_param(mpt_saf_te, int, 0); MODULE_PARM_DESC(mpt_saf_te, Force enabling SEP Processor: enable=1 (default=MPTSCSIH_SAF_TE=0)); static int mpt_pq_filter = 0; -MODULE_PARM(mpt_pq_filter, i); +module_param(mpt_pq_filter, int, 0); MODULE_PARM_DESC(mpt_pq_filter, Enable peripheral qualifier filter: enable=1 (default=0)); /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=-=-=-=*/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] mptfusion: Remove credits and update copyright
Remove credits and update copyright - mptctl.[c,h] Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-3-mptctl Description: Binary data
[PATCH 5/7] mptfusion: Remove credits and update copyright
Remove credits, -sralston references , update copyright : mptlan.[c,h] Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-5-mptlan Description: Binary data
[PATCH 4/7] mptfusion: Adding Stub Driver - Fiber Channel
Adding Stub Driver - Fiber Channel : mptfc.c This driver is having module_init, module_exit, and probe Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-4-mptfc Description: Binary data
[PATCH 2/7] mptfusion: Cleanups, split driver support, DMA32_BIT_ MASK support
Changelog: mptbase.[c,h] (1) Use the DMA_32BIT_MASK constant (2) Remove credits, -sralston references , update copyright (3) split driver support Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-2-mptbase Description: Binary data
[PATCH 6/7] mptfusion: split driver support
split driver support: mptscsih.[c,h] Changelog (1) Remove credits, -sralston references , update copyright (2) split driver support (3) module_init, module_exit, and probe routines moved to new stub drivers, mptfc and mptspi (4) some global parameters are moved to MPT_SCSI_HOST Signed-off-by: Eric Moore [EMAIL PROTECTED] patch-6-mptscsih Description: Binary data
RE: [PATCH 6/7] - MPT FUSION - SPLITTING SCSI HOST DRIVERS
On Sunday, March 27, 2005 8:04 AM, James Bottomley wrote: On Sun, 2005-03-27 at 01:16 -0800, Jeremy Higdon wrote: James, actually this queue depth code predates your change_queue_depth API. I don't think it was ever converted to the new API. Erk, you're right. My todo list says I'm only waiting on 3ware patches for all the conversions to be complete, but I think I missed auditing fusion because it's not in the scsi directory...OK I'll do it after we get the driver split sorted out. James I can probably look into adding this support once we get the slit drivers accepted. Thankyou, Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
