From: Rolf Eike Beer <eike-kernel@sf-tec.de>
To: Bolke de Bruin <bdbruin@aub.nl>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Kernel 2.6.5 - Compaq Fibre Channel 64-bit/66Mhz HBA
Date: Thu, 11 Aug 2005 18:58:38 +0200 [thread overview]
Message-ID: <200508111858.45153@bilbo.math.uni-mannheim.de> (raw)
In-Reply-To: <42FB7FC2.10405@aub.nl>
[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]
Am Donnerstag, 11. August 2005 18:41 schrieben Sie:
>>arrays allocated by the driver eat 2kB each, so a stack overflow is very
>>likely. Even with 8kB stack it is still not impossible. Using the version
>>from 2.6.5 will not be a very good idea I think, it's likely to crash your
>>machine one day.
>>
>:-(
>:
>>The right solution would be fixing the driver to use kmalloc()/kfree() when
>> he really needs the memory. There was a patch only a few days ago that
>> tried to do that, but it was not really well done and would have crashed.
>> If you are really interested in I can do such a patch. The code of this
>> driver sucks universes through nanotubes, but one day someone _will_ have
>> to start cleaning this up.
>
>Define: really interested
>
>So, probably we are really interested. Though there are a couple of caveats:
>
>- Testing can be done only very limited. We have only one raid array
>available and it is in production
If whatever I do will go wrong you'll see it very fast. Then you can't receive
data ;)
>- Servers are not in yet, but will been in the next couple of weeks
>- As Arjan noted the kernel will be "some vendor 2.6.5". More precisely
>sles9 or rhle 3. This is dictated by the setup of informix 10 on those
>machines, we are stuck with that unfortunately. To be really interesting
>a patch should be backportable to 2.6.5 (or the equivalent rh kernel).
This should be rather simple. Just use their kernel sources, copy the files
from a newer kernel in and rebuild the module.
>- I am currently investigating if other controllers are able to support
>this raid array and are supported. If so it might be a better idea to
>use those
Yes, if you find some which have a driver that smells less it would be a good
idea to use them.
>- We are willing to offer something in exchange. This ranges from 24
>bottles of beer of your choice to something else. The something else
>part needs to be discussed, but the beer part I can be held responsible
>for :-)
*g* I'll remind you ;)
Eike
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-08-11 16:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-11 15:46 Kernel 2.6.5 - Compaq Fibre Channel 64-bit/66Mhz HBA Bolke de Bruin
2005-08-11 15:51 ` Arjan van de Ven
2005-08-11 16:19 ` Rolf Eike Beer
2005-08-11 16:41 ` Bolke de Bruin
2005-08-11 16:58 ` Rolf Eike Beer [this message]
2005-08-11 17:58 ` Kernel 2.6.5 - Compaq Fibre Channel 64-bit/66Mhz HBA [PATCH] Rolf Eike Beer
[not found] ` <200508160955.49133@bilbo.math.uni-mannheim.de>
[not found] ` <4301A6BB.3020403@aub.nl>
2005-08-16 8:58 ` Rolf Eike Beer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200508111858.45153@bilbo.math.uni-mannheim.de \
--to=eike-kernel@sf-tec.de \
--cc=bdbruin@aub.nl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox