>
> https://bugzilla.redhat.com/show_bug.cgi?id=288421
>
> When running Fedora on a Dell 2950 w/ integrated LSI Perc5i
(megaraid), the
> system will not boot after upgrading to 2.6.22. The boot message
indicates the
> system is somehow seeing through RAID, cannot access logical volume.
This
>
https://bugzilla.redhat.com/show_bug.cgi?id=288421
When running Fedora on a Dell 2950 w/ integrated LSI Perc5i
(megaraid), the
system will not boot after upgrading to 2.6.22. The boot message
indicates the
system is somehow seeing through RAID, cannot access logical volume.
This
causes
Sysfs Gurus,
I want to export few driver specific sysfs attributes when my driver loads.
This driver is a pci hotplug driver. I want to export these sysfs attributes
as soon as my pci_module_init succeeds.
1. I see that there is /sys/modules directory lists all the modules. Is this
a right place
Sysfs Gurus,
I want to export few driver specific sysfs attributes when my driver loads.
This driver is a pci hotplug driver. I want to export these sysfs attributes
as soon as my pci_module_init succeeds.
1. I see that there is /sys/modules directory lists all the modules. Is this
a right place
>On Sat, Mar 12, 2005 at 03:42:22AM -0800, Andrew Morton wrote:
>>...
>> All 606 patches:
>>...
>> megaraid_sas-announcing-new-module-for.patch
>> megaraid_sas: Announcing new module for LSI Logic's SAS
>based MegaRAID controllers
>>...
>
>Enormous stack usage:
>- megasas_init_mfi (due to
On Sat, Mar 12, 2005 at 03:42:22AM -0800, Andrew Morton wrote:
...
All 606 patches:
...
megaraid_sas-announcing-new-module-for.patch
megaraid_sas: Announcing new module for LSI Logic's SAS
based MegaRAID controllers
...
Enormous stack usage:
- megasas_init_mfi (due to ctrl_info)
Big stack
>
>Even for kernels with a 64bit dma_addr_t you can get 32bit dma
>addresses
>only. As a start check whether the pci_set_dma_mask for the 64bit mask
>failed - in that case you can always use 32bit SGLs.
>
Please help me understand: If dma_addr_t is 64 bit, I will get 64bit
addresses in
>> >
>> >Even for kernels with a 64bit dma_addr_t you can get 32bit dma
>> >addresses
>> >only. As a start check whether the pci_set_dma_mask for
>the 64bit mask
>> >failed - in that case you can always use 32bit SGLs.
>> >
>>
>> Please help me understand: If dma_addr_t is 64 bit, I will get
>> >
>> >> . And since this is compile time
>> >> system-wide property, I kept it as driver global.
>> >
>> >that step I don't understand... why is it a global
>*VARIABLE* if it's
>> >compile time system-wide property...
>> >
>>
>> I see your point! Are you saying I should use
>
>> . And since this is compile time
>> system-wide property, I kept it as driver global.
>
>that step I don't understand... why is it a global *VARIABLE* if it's
>compile time system-wide property...
>
I see your point! Are you saying I should use if(sizeof(dma_addr_t)==8)
instead of the
>>
>> I will make this an instance parameter if the idea to reduce as many
>> global variables as possible. But if the objection is because each
>> adapter
>> may have different value for variable, then it is indeed a global
>> value.
>> "is_dma64" - which is computed using the size of dma_addr_t
>> >
>> >> source "drivers/scsi/megaraid/Kconfig.megaraid"
>> >> +source "drivers/scsi/megaraid/Kconfig.megaraid_sas"
>> >>
>> >
>> >why a fully separate file and not add your ONE config option to
>> >Kconfig.megaraid instead ??
>> >
>>
>> Arjan, I didn't want to needlessly couple megaraid and
source drivers/scsi/megaraid/Kconfig.megaraid
+source drivers/scsi/megaraid/Kconfig.megaraid_sas
why a fully separate file and not add your ONE config option to
Kconfig.megaraid instead ??
Arjan, I didn't want to needlessly couple megaraid and megaraid_sas.
Since they are in
I will make this an instance parameter if the idea to reduce as many
global variables as possible. But if the objection is because each
adapter
may have different value for variable, then it is indeed a global
value.
is_dma64 - which is computed using the size of dma_addr_t - is
telling
. And since this is compile time
system-wide property, I kept it as driver global.
that step I don't understand... why is it a global *VARIABLE* if it's
compile time system-wide property...
I see your point! Are you saying I should use if(sizeof(dma_addr_t)==8)
instead of the shortcut
. And since this is compile time
system-wide property, I kept it as driver global.
that step I don't understand... why is it a global
*VARIABLE* if it's
compile time system-wide property...
I see your point! Are you saying I should use
if(sizeof(dma_addr_t)==8)
instead of the
Even for kernels with a 64bit dma_addr_t you can get 32bit dma
addresses
only. As a start check whether the pci_set_dma_mask for
the 64bit mask
failed - in that case you can always use 32bit SGLs.
Please help me understand: If dma_addr_t is 64 bit, I will get 64bit
addresses in
Even for kernels with a 64bit dma_addr_t you can get 32bit dma
addresses
only. As a start check whether the pci_set_dma_mask for the 64bit mask
failed - in that case you can always use 32bit SGLs.
Please help me understand: If dma_addr_t is 64 bit, I will get 64bit
addresses in scatterlist
>
>> source "drivers/scsi/megaraid/Kconfig.megaraid"
>> +source "drivers/scsi/megaraid/Kconfig.megaraid_sas"
>>
>
>why a fully separate file and not add your ONE config option to
>Kconfig.megaraid instead ??
>
Arjan, I didn't want to needlessly couple megaraid and megaraid_sas.
Since they are
>
>> +static int is_dma64;
>
>the fact that this is a global variable worries me.
>
Matt also has the same concern. I am pasting my response from my reply
to his comment:
I will make this an instance parameter if the idea to reduce as many
global variables as
>Subject: Re: [ANNOUNCE][PATCH 2.6.11 2/3] megaraid_sas:
>Announcing new module for LSI Logic's SAS based MegaRAID controllers
>
>On Fri, Mar 04, 2005 at 10:06:00PM -0500, Bagalkote, Sreenivas wrote:
>> We are announcing a driver for LSI Logic's new SAS based MegaRAID
>>
Subject: Re: [ANNOUNCE][PATCH 2.6.11 2/3] megaraid_sas:
Announcing new module for LSI Logic's SAS based MegaRAID controllers
On Fri, Mar 04, 2005 at 10:06:00PM -0500, Bagalkote, Sreenivas wrote:
We are announcing a driver for LSI Logic's new SAS based MegaRAID
controllers.
I'd like to start
+static int is_dma64;
the fact that this is a global variable worries me.
Matt also has the same concern. I am pasting my response from my reply
to his comment:
I will make this an instance parameter if the idea to reduce as many
global variables as possible.
source drivers/scsi/megaraid/Kconfig.megaraid
+source drivers/scsi/megaraid/Kconfig.megaraid_sas
why a fully separate file and not add your ONE config option to
Kconfig.megaraid instead ??
Arjan, I didn't want to needlessly couple megaraid and megaraid_sas.
Since they are in the same
Patch 3 of 3:
Signed-off-by: Sreenivas Bagalkote <[EMAIL PROTECTED]>
diff -Naur linux-2.6.11-orig/drivers/scsi/megaraid/megaraid_sas.h
linux-2.6.11/drivers/scsi/megaraid/megaraid_sas.h
--- linux-2.6.11-orig/drivers/scsi/megaraid/megaraid_sas.h 1969-12-31
19:00:00.0 -0500
+++
Hello All,
We are announcing a driver for LSI Logic's new SAS based MegaRAID
controllers. I am submitting the inlined patch in three parts. Please
review the patches.
Thank you,
Sreenivas Bagalkote
LSI Logic Corporation
Patch 1 of 3:
Signed-off-by: Sreenivas Bagalkote <[EMAIL PROTECTED]>
Hello All,
We are announcing a driver for LSI Logic's new SAS based MegaRAID
controllers. I am submitting the inlined patch in three parts. Please
review the patches.
Thank you,
Sreenivas Bagalkote
LSI Logic Corporation
Patch 1 of 3:
Signed-off-by: Sreenivas Bagalkote [EMAIL PROTECTED]
diff
Patch 3 of 3:
Signed-off-by: Sreenivas Bagalkote [EMAIL PROTECTED]
diff -Naur linux-2.6.11-orig/drivers/scsi/megaraid/megaraid_sas.h
linux-2.6.11/drivers/scsi/megaraid/megaraid_sas.h
--- linux-2.6.11-orig/drivers/scsi/megaraid/megaraid_sas.h 1969-12-31
19:00:00.0 -0500
+++
your efforts.
Thanks,
Sreenivas
LSI LOGIC Corporation
>-Original Message-
>From: Marcelo Tosatti [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, February 23, 2005 2:06 AM
>To: Andrey J. Melnikoff (TEMHOTA); Vasily Averin
>Cc: Matt Domsch; linux-kernel@vger.kernel.org; Mukker
efforts.
Thanks,
Sreenivas
LSI LOGIC Corporation
-Original Message-
From: Marcelo Tosatti [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 23, 2005 2:06 AM
To: Andrey J. Melnikoff (TEMHOTA); Vasily Averin
Cc: Matt Domsch; linux-kernel@vger.kernel.org; Mukker, Atul;
Bagalkote, Sreenivas
30 matches
Mail list logo
