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?
>
>
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]>
>
On Monday, August 27, 2007 9:59 AM, Joe Perches wrote:
> On Mon, 2007-08-27 at 09:30 -0600, Moore, Eric wrote:
> > Yes it was changed to [EMAIL PROTECTED] I had posted a
> > patch about a month back, along with the changes for all the driver
> > sources.
>
On Friday, August 24, 2007 6:03 PM, Joe Perches wrote:
>
> The MPT driver subsystem block has an invalid
> list address of [EMAIL PROTECTED]
>
> Is there a replacement address?
>
> LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
> P:Eric Moore
> M:[EMAIL PROTECTED]
> M:[EMAIL PROTECTED]
On Friday, August 24, 2007 6:03 PM, Joe Perches wrote:
The MPT driver subsystem block has an invalid
list address of [EMAIL PROTECTED]
Is there a replacement address?
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
P:Eric Moore
M:[EMAIL PROTECTED]
M:[EMAIL PROTECTED]
L:
On Monday, August 27, 2007 9:59 AM, Joe Perches wrote:
On Mon, 2007-08-27 at 09:30 -0600, Moore, Eric wrote:
Yes it was changed to [EMAIL PROTECTED] I had posted a
patch about a month back, along with the changes for all the driver
sources.
This is what I have:
LSILOGIC MPT
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
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
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
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
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:
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
> If you're going to include it just for the sake of including it, not
> because the code in question actually uses types or function
> declarations defined in there, don't bother, you're just using an
> anti-social mechanism to keep this header file in the tree.
>
> Please, let's kill this
Valdis.Kletnieks silly little rant:
> Certainly appropriate content for something on your website,
> and vendors who
> provide programs like dmidecode and parsemce are always
> welcome. I could
> probably be convinced that such info should have at least a
> pointer somewhere
> in
Valdis.Kletnieks silly little rant:
Certainly appropriate content for something on your website,
and vendors who
provide programs like dmidecode and parsemce are always
welcome. I could
probably be convinced that such info should have at least a
pointer somewhere
in
If you're going to include it just for the sake of including it, not
because the code in question actually uses types or function
declarations defined in there, don't bother, you're just using an
anti-social mechanism to keep this header file in the tree.
Please, let's kill this header
On Monday, February 19, 2007 5:07 PM, Adrian Bunk wrote:
> This patch makes the needlessly global mptspi_target_destroy() static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
ACK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
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
On Monday, February 19, 2007 5:07 PM, Adrian Bunk wrote:
This patch makes the needlessly global mptspi_target_destroy() static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
ACK
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
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
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
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':
>
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':
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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
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 ...
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
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 problem
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.
> >>
>
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.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
2.6.13-rc3/2.6
.13-rc3
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
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
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
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
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;
> > > > -}
> > > >
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
> > 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
>
> On Sun, 2005-07-10 at 18:15 -0600, Moore, Eric Dean wrote:
> > I'd rather you not kill linux_compat.h file.
> > I use this file for compatibility of driver source
> > across various kernel versions. I provide our
> > customers with driver builds containing
I've seen the report. I need more info from Bharata on how
to reproduce. Perhaps you can send me email offline which
provides specific instructions to how to configure kdump,
how to capture the dump, and what you did to crash your system.
Eric Moore
LSI Logic Corporation
On Tuesday, July 12,
On Sun, 2005-07-10 at 18:15 -0600, Moore, Eric Dean wrote:
I'd rather you not kill linux_compat.h file.
I use this file for compatibility of driver source
across various kernel versions. I provide our
customers with driver builds containing single source
which needs to compile
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 list:
I've seen the report. I need more info from Bharata on how
to reproduce. Perhaps you can send me email offline which
provides specific instructions to how to configure kdump,
how to capture the dump, and what you did to crash your system.
Eric Moore
LSI Logic Corporation
On Tuesday, July 12,
I'd rather you not kill linux_compat.h file.
I use this file for compatibility of driver source
across various kernel versions. I provide our
customers with driver builds containing single source
which needs to compile in kernels 2.6.5( e.g. SLES9),
2.6.8 (e.g. RHEL4), and 2.6.11 ( e.g. SuSE
I'd rather you not kill linux_compat.h file.
I use this file for compatibility of driver source
across various kernel versions. I provide our
customers with driver builds containing single source
which needs to compile in kernels 2.6.5( e.g. SLES9),
2.6.8 (e.g. RHEL4), and 2.6.11 ( e.g. SuSE
On Saturday, March 26, 2005 4:21 AM, Christoph Hellwig wrote:
> I took a quick look an a here's a few comments:
>
> - I don't think renaming mptscsih.c to mpt_core.c makes sense.
>the new name is confusing at best, and keeping the old name allows
>to keep SCCS history aswell. That means
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
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
On Saturday, March 26, 2005 4:21 AM, Christoph Hellwig wrote:
I took a quick look an a here's a few comments:
- I don't think renaming mptscsih.c to mpt_core.c makes sense.
the new name is confusing at best, and keeping the old name allows
to keep SCCS history aswell. That means the
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various transport layers; e.g. SPI, FC, and eventually SAS.
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various transport layers; e.g. SPI, FC, and eventually SAS.
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various transport layers; e.g. SPI, FC, and eventually SAS.
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various transport layers; e.g. SPI, FC, and eventually SAS.
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various transport layers; e.g. SPI, FC, and eventually SAS.
Here are several patches(7) which follow this email.
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various
Here are several patches(7) which follow this email.
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various transport layers; e.g. SPI, FC, and eventually SAS.
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various transport layers; e.g. SPI, FC, and eventually SAS.
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various transport layers; e.g. SPI, FC, and eventually SAS.
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various transport layers; e.g. SPI, FC, and eventually SAS.
These patches are for the mpt fusion scsi host drivers, which separate
the scsi host drivers into separate bus type kernel modules. This was
requested
by several people on the linux-scsi@ forum, so our driver can properly
support
the various transport layers; e.g. SPI, FC, and eventually SAS.
On Tuesday, March 22, 2005 12:05 PM, James Bottomley wrote:
> On Tue, 2005-03-22 at 11:40 -0700, Moore, Eric Dean wrote:
> > History on this:
> > Between the 3.01.16 and 3.01.18, we introduced new method
> > to passing command line options to the driver. Some of the
>
Here is a patch for mpt fusion drivers, which
fix's issue of poor performance when driver compiled
built-in to the kernel.
Thanks to Chen, Kenneth W.
History on this:
Between the 3.01.16 and 3.01.18, we introduced new method
to passing command line options to the driver. Some of the
command
Here is a patch for mpt fusion drivers, which
fix's issue of poor performance when driver compiled
built-in to the kernel.
Thanks to Chen, Kenneth W.
History on this:
Between the 3.01.16 and 3.01.18, we introduced new method
to passing command line options to the driver. Some of the
command
On Tuesday, March 22, 2005 12:05 PM, James Bottomley wrote:
On Tue, 2005-03-22 at 11:40 -0700, Moore, Eric Dean wrote:
History on this:
Between the 3.01.16 and 3.01.18, we introduced new method
to passing command line options to the driver. Some of the
command line options are used
EBDA - Extended Bios Data Area
Does Linux and various boot loaders(lilo/grub/etc)
having any restrictions on where and how big
memory allocated in EBDA is? Is this
handled for 2.4/2.6 Kernels?
Reason I ask is we are considering having
BIOS(for a SCSI HBA Controller) allocating
memory in EBDA
EBDA - Extended Bios Data Area
Does Linux and various boot loaders(lilo/grub/etc)
having any restrictions on where and how big
memory allocated in EBDA is? Is this
handled for 2.4/2.6 Kernels?
Reason I ask is we are considering having
BIOS(for a SCSI HBA Controller) allocating
memory in EBDA
66 matches
Mail list logo
