On Tue, 2005-03-22 at 13:35 -0700, Moore, Eric Dean wrote:
> I still wonder if the SPI transport layer will work for RAID volumes.
> Do you know if the spi transport layer supports dv on hidden devices in a
> raid volume?
> Meaning these hidden physical disks will not been seen by the block laye
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 us
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 for fine tuning dv(domain
> validation) in the driver. By accident
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 line
On Tue, 22 Mar 2005, Chen, Kenneth W wrote:
On Mon, 21 Mar 2005, Andrew Morton wrote:
Holger, this problem remains unresolved, does it not? Have you done any
more experimentation?
I must say that something funny seems to be happening here. I have two
MPT-based Dell machines, neither of which is u
>
> And there are places where it's actually useful:
>
> #if defined(CONFIG_FOO) || (defined(MODULE) && defined(CONFIG_FOO_MODULE))
>
> is a good way to express that driver bar can use functionality of driver
> foo if it's available.
a good way? I'd disagree with that :)
-
To unsubscribe
On Tue, Mar 22, 2005 at 11:52:22AM +0100, Arjan van de Ven wrote:
> On Tue, 2005-03-22 at 02:29 -0800, Chen, Kenneth W wrote:
>
> > Before:
> > /dev/sdc:
> > Timing buffered disk reads: 92 MB in 3.03 seconds = 30.32 MB/sec
> >
> > After:
> > /dev/sdc:
> > Timing buffered disk reads: 174 MB
On Tue, 2005-03-22 at 02:29 -0800, Chen, Kenneth W wrote:
> Before:
> /dev/sdc:
> Timing buffered disk reads: 92 MB in 3.03 seconds = 30.32 MB/sec
>
> After:
> /dev/sdc:
> Timing buffered disk reads: 174 MB in 3.02 seconds = 57.61 MB/sec
nice!
More proof that #ifdef MODULE is consider
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
>
> On Mon, 21 Mar 2005, Andrew Morton wrote:
> > Holger, this problem remains unresolved, does it not? Have you done any
> > more experimentation?
> >
> > I must say that something funny seems to be happening here. I have two
> > MPT-based Dell machin
On Mon, 21 Mar 2005, Andrew Morton wrote:
> Holger, this problem remains unresolved, does it not? Have you done any
> more experimentation?
>
> I must say that something funny seems to be happening here. I have two
> MPT-based Dell machines, neither of which is using a modular driver:
>
> akpm:/u
On Mon, 21 Mar 2005, Andrew Morton wrote:
Holger Kiehl <[EMAIL PROTECTED]> wrote:
Hello
On a four CPU Opteron compiling the Fusion-MPT as module gives much better
performance when compiling it in, here some bonnie++ results:
Version 1.03 --Sequential Output-- --Sequential Input- --Ra
Hello everyone,
On Mon, 2005-03-21 at 15:27 -0800, Andrew Morton wrote:
> > On a four CPU Opteron compiling the Fusion-MPT as module gives much better
> > performance when compiling it in, here some bonnie++ results:
> >
> > Version 1.03 --Sequential Output-- --Sequential Input-
>
Holger Kiehl <[EMAIL PROTECTED]> wrote:
>
> Hello
>
> On a four CPU Opteron compiling the Fusion-MPT as module gives much better
> performance when compiling it in, here some bonnie++ results:
>
> Version 1.03 --Sequential Output-- --Sequential Input-
> --Random-
>
Hello
On a four CPU Opteron compiling the Fusion-MPT as module gives much better
performance when compiling it in, here some bonnie++ results:
Version 1.03 --Sequential Output-- --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seek
14 matches
Mail list logo
