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
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) thi
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
> ini
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
ith an oem like IBM, Dell, HP, Sun, etc, let me know in private email,
and I will get you in contact with the correct product support lines.
Eric
> -Original Message-
> From: Cory Visi [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 26, 2007 3:30 PM
> To: Moore, Eric
>
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
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_FUS
> No. When the command goes via SG_IO it bypasses all return status
> processing (and QUEUE_FULL/BUSY is a return status). When it's
> submitted in the normal way (i.e. via a ULD) then the mid-layer
> processes these returns to a retry strategy.
>
James - Today I'm working some other customer i
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.
>
On Thursday, November 15, 2007 12:10 PM, Chris Friesen wrote:
>
> My impression is that the per-device queue is supposed to be
> decreased
> at runtime to match the actual size that the hardware can handle. In
> the earlier version we're seeing the queue set to 7 at runtime, while
> the more
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 compl
Zhao - mpt fusion uses scsi_transport_sas.c, not libsas.c.The
scsi_transport_sas.c module can't be removed.The libsas is for hbas
that have no firmware.
Eric
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Zhao Forrest
> Sent: Friday, Novem
On Tuesday, November 13, 2007 3:04 PM, Chris Friesen wrote:
>
> Chris Friesen wrote:
>
> > We recently moved from 2.6.10 to 2.6.14 and now we're
> seeing occasional
> > QUEUE_FULL/SAM_STAT_TASK_SET_FULL errors being returned to
> userspace.
> > These didn't ever show up in 2.6.10.
>
> I fou
On Monday, October 22, 2007 10:18 AM, Matthew Wilcox wrote:
> Sounds like we need a new driver written to support the FC909 then.
> Unless we could pretend the FC909 is a parallel scsi card or something
> ... that wasn't quite clear from Michael's mail.
>
ok, are you suggesting for FC909 we call
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
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 0
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 be
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 th
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, b
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
> sign
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 'm
On Saturday, September 22, 2007 9:39 AM, James Bottomley wrote:
>
> Well, I'll put this in this time. However, it contains a
> whole slew of
> pointless changes like this:
>
>
> > - mdelay (10);
> > + udelay (1);
>
> and
>
> > -
On Monday, September 10, 2007 11:56 AM, Arkadiusz Miskiewicz wrote:
>
> SR2520SAXS platform (S5000VSA mainboard in 2U SR2520 chassis) with
>
> 08:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064ET
> PCI-Express Fusion-MPT SAS (rev 02)
You have a 1064E B1 part. How much system m
On September 06, 2007 12:40 PM, Louis-Michel Gelinas wrote:
>
> After messing around with various kernels and drivers, I finnaly got
> this adaptor to work by changing the define
> MPI_MANUFACTPAGE_DEVID_SAS1068E to (0x0059) from (0x0058) in
>
> drivers/message/fusion/lsi/mpi_cnfg.h:553
>
> I
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.le
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?
>
> ca
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]>
>
Althou
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/mess
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 no
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 neve
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 rou
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 unsubscri
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]>
>
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 bo
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
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 cod
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
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 br
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
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 t
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__);
> +
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, a
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//parameters/
>
> And have it acted on immediately. In yours, it seems only to work
> before the host is prob
On Thursday, July 26, 2007 11:09 AM, FUJITA Tomonori wrote:
> For smp request/response, we use:
>
> request -> not used
> response -> not used
> dout_xferp -> pointer to a smp request frame
> din_xferp -> pointer to a smp response frame
>
>
> So we could use response field to send vendor's uniqu
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_F
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_ma
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
On Monday, July 23, 2007 11:28 PM, FUJITA Tomonori wrote:
>
> With 2.6.23-rc1 + mptsas smp patch, you get directories /sys/class/bsg
> like:
I hadn't enabled bsg support in the linux kernel, that was my problem.
>
> # ./sgv4-tools/smp_rep_manufacturer /sys/class/bsg/expander-0:1
>
>
> I thin
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 d
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,
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-s
On Tuesday, July 17, 2007 3:09 AM, Prakash, Sathya wrote:
> Reposting as this patch is not visible in the list yet.
>
> Resubmitting with the following change suggested by Brian King:
> The driver version from scsi_host attribute is redundant as
> it is already
> available in sysfs: /sys/module
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
On Thursday, July 12, 2007 10:11 PM, Prakash, Sathya wrote:
>
> Resubmitting with the following change suggested by Brian King:
> The driver version from scsi_host attribute is redundant as
> it is already
> available in sysfs: /sys/module/mptscsih/version.
> So it is removed from the patch
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" wou
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.
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
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
>
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 dev
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 ha
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
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
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
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 r
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
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
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 PROTECTE
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. mpts
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. Ther
On Monday, February 26, 2007 9:42 AM, Ric Wheeler wrote:
> Which brings us back to a recent discussion at the file
> system workshop on being
> more repair oriented in file system design so we can survive
> situations like
> this a bit more reliably ;-)
>
On the second day of the workshop, t
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
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 remov
On Tuesday, February 20, 2007 8:10 AM, Christopher Allen Wing wrote:
> Has anyone else been in this situation? One product that we
> found is a
> board sold by HP (HP SC11Xe) based on a LSI Logic chipset.
> This is a PCI
> Express controller with a single U320 parallel SCSI channel. It is
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 &#
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 n
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 t
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
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 orde
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
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_STA
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
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_BU
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/me
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 .
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
> +++
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
>
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/
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
> +++ s
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/c
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 m
On Sunday, August 21, 2005 10:53 AM, Christoph Hellwig wrote:
> This is just a brindup helper because the Fusion hardware does a SAS
> remote port to target ID mapping in firmware, in fact the firmware
> interface only addresses them using this assigned ID, which is a big
> shortcoming in the Fusio
James: Your patches are not applying cleanly, so tell which kernel do I use
as base to apply your patches?
I don't use git to get the source, I'm pulling patches from www.kernel.org.
I've tried:
2.6.13-rc6
2.6.13-rc6-git1
2.6.13-rc5-mm1
Eric Moore
-
To unsubscribe from this list: send the li
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
On Sunday, August 07, 2005 8:30 AM, James Bottomley wrote:
> On Sun, 2005-08-07 at 05:59 +, Holger Kiehl wrote:
> > Thanks, removing those it compiles fine. This patch also
> solves my problem,
> > here the output of dmesg:
>
> Well ... the transport class was supposed to help diagnose the p
Jul 2005, Andrew Morton wrote:
>
> > "Moore, Eric Dean" <[EMAIL PROTECTED]> wrote:
> >>
> >> Regarding the 1st issue, can you try this patch out. It
> maybe in the
> >> -mm branch. Andrew cc'd on this email can confirm.
> >>
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 o
On Tuesday, July 19, 2005 9:12 PM, Matt Domsch wrote:
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 i
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:
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;
> > > > -}
> > > >
> > But Id rather have same files in our maintained driver,
> > and whats in the kernel tree.
>
> Just think what a mess we'd have on our hands if we let
> everyone do that. Sorry, please don't put compat header
> files into the current upstream tree, thanks.
>
Fine.
-
To unsubscribe from this
1 - 100 of 147 matches
Mail list logo
