Claims to have fixed the write performance issues with multiple volumes. Haven't tried it personally (I do not have a 9500S card, and I have only installed one once for a client).
NOTE: This (9.2.1.1) is an actual, formal, supported release -- not an unsupported engineering release.
On Sun, 28 Aug 2005 at 9:20am, Bryan J. Smith wrote
Claims to have fixed the write performance issues with multiple volumes. Haven't tried it personally (I do not have a 9500S card, and I have only installed one once for a client).
NOTE: This (9.2.1.1) is an actual, formal, supported release -- not an unsupported engineering release.
It does seem a bit rushed, though, as the firmware included in the driver is *older* than the firmware one downloads separately as part of the codeset. ??
On Mon, 29 Aug 2005, Joshua Baker-LePain wrote:
On Sun, 28 Aug 2005 at 9:20am, Bryan J. Smith wrote
Claims to have fixed the write performance issues with multiple volumes. Haven't tried it personally (I do not have a 9500S card, and I have only installed one once for a client).
NOTE: This (9.2.1.1) is an actual, formal, supported release -- not an unsupported engineering release.
It does seem a bit rushed, though, as the firmware included in the driver is *older* than the firmware one downloads separately as part of the codeset. ??
Is it possible to upgrade the firmware from CentOS? I'm using CentOS 4 with the built-in kernel module.
The box doesn't have a floppy drive or anything so it's no so easy to update from floppy. My boot volume is on the 3Ware
On Fri, 9 Sep 2005 at 7:20pm, Remco Barendse wrote
On Mon, 29 Aug 2005, Joshua Baker-LePain wrote:
On Sun, 28 Aug 2005 at 9:20am, Bryan J. Smith wrote
Claims to have fixed the write performance issues with multiple volumes. Haven't tried it personally (I do not have a 9500S card, and I have only installed one once for a client).
NOTE: This (9.2.1.1) is an actual, formal, supported release -- not an unsupported engineering release.
It does seem a bit rushed, though, as the firmware included in the driver is *older* than the firmware one downloads separately as part of the codeset. ??
Is it possible to upgrade the firmware from CentOS? I'm using CentOS 4 with the built-in kernel module.
The box doesn't have a floppy drive or anything so it's no so easy to update from floppy. My boot volume is on the 3Ware
You can use the 'fw' driver that 3ware distributes. But, as I mentioned above, in this case it doesn't include the latest firmware, which is the one that actually fixes the multiple-unit bug. So you have to manually flash it from a DOS environment. If you can't shoehorn a floppy in temporarily, have a look at PXE. Or, just wait -- 3ware says on the website they'll be releasing an updated driver with the right firmware.
On Fri, 9 Sep 2005, Joshua Baker-LePain wrote:
On Fri, 9 Sep 2005 at 7:20pm, Remco Barendse wrote
On Mon, 29 Aug 2005, Joshua Baker-LePain wrote:
On Sun, 28 Aug 2005 at 9:20am, Bryan J. Smith wrote
Claims to have fixed the write performance issues with multiple volumes. Haven't tried it personally (I do not have a 9500S card, and I have only installed one once for a client).
NOTE: This (9.2.1.1) is an actual, formal, supported release -- not an unsupported engineering release.
It does seem a bit rushed, though, as the firmware included in the driver is *older* than the firmware one downloads separately as part of the codeset. ??
Is it possible to upgrade the firmware from CentOS? I'm using CentOS 4 with the built-in kernel module.
The box doesn't have a floppy drive or anything so it's no so easy to update from floppy. My boot volume is on the 3Ware
You can use the 'fw' driver that 3ware distributes. But, as I mentioned above, in this case it doesn't include the latest firmware, which is the one that actually fixes the multiple-unit bug. So you have to manually flash it from a DOS environment. If you can't shoehorn a floppy in temporarily, have a look at PXE. Or, just wait -- 3ware says on the website they'll be releasing an updated driver with the right firmware.
Cool, suppose I have the patience to wait, will the fw driver work on a running system that booted from the array with a stock CentOS kernel?
Or do I need to compile my own kernel with the fw driver included (I prefer not to go down that path)
On Fri, 9 Sep 2005 at 7:30pm, Remco Barendse wrote
On Fri, 9 Sep 2005, Joshua Baker-LePain wrote:
You can use the 'fw' driver that 3ware distributes. But, as I mentioned above, in this case it doesn't include the latest firmware, which is the one that actually fixes the multiple-unit bug. So you have to manually flash it from a DOS environment. If you can't shoehorn a floppy in temporarily, have a look at PXE. Or, just wait -- 3ware says on the website they'll be releasing an updated driver with the right firmware.
Cool, suppose I have the patience to wait, will the fw driver work on a running system that booted from the array with a stock CentOS kernel?
Yes. You just need to put the driver in the /lib/modules directory of the right kernel (in place of the old driver), and then make a new initrd for the kernel you're running.
On Fri, 9 Sep 2005, Joshua Baker-LePain wrote:
On Fri, 9 Sep 2005 at 7:30pm, Remco Barendse wrote
On Fri, 9 Sep 2005, Joshua Baker-LePain wrote:
You can use the 'fw' driver that 3ware distributes. But, as I mentioned above, in this case it doesn't include the latest firmware, which is the one that actually fixes the multiple-unit bug. So you have to manually flash it from a DOS environment. If you can't shoehorn a floppy in temporarily, have a look at PXE. Or, just wait -- 3ware says on the website they'll be releasing an updated driver with the right firmware.
Cool, suppose I have the patience to wait, will the fw driver work on a running system that booted from the array with a stock CentOS kernel?
Yes. You just need to put the driver in the /lib/modules directory of the right kernel (in place of the old driver), and then make a new initrd for the kernel you're running.
OK, thanks. Sorry for my next question, how do I create the new initrd and how do i specify which drivers to (not) include in the new initrd?
This is still blackmagic to me. I have an ISDN PRI card in the system for which I need a specific driver. There is a driver included with the kernel which kudzu always wants to install but I don't want initrd to include that driver.
My current workaround is to pull the card from the box before any upgrades, not ideal at all
(Sorry if this is really like a n00b's question)
On Fri, 9 Sep 2005 at 8:12pm, Remco Barendse wrote
On Fri, 9 Sep 2005, Joshua Baker-LePain wrote:
Yes. You just need to put the driver in the /lib/modules directory of the right kernel (in place of the old driver), and then make a new initrd for the kernel you're running.
OK, thanks. Sorry for my next question, how do I create the new initrd and how do i specify which drivers to (not) include in the new initrd?
For the current kernel, I did this to upgrade the 3w-9xxx module:
cd /lib/modules/2.6.9-11.ELsmp/kernel/drivers/scsi/ mv 3w-9xxx.ko 3w-9xxx.dist cp ~/src/driver-9.2.1.1/3w-9xxx.ko 3w-9xxx.9.2.1.1 cp 3w-9xxx.9.2.1.1 3w-9xxx.ko cd /boot/ rm initrd-2.6.9-11.ELsmp.img mkinitrd initrd-2.6.9-11.ELsmp.img 2.6.9-11.ELsmp
Remco Barendse redhat@barendse.to wrote:
OK, thanks. Sorry for my next question, how do I create the new initrd
# mkinitrd (options) /boot/initrd-`uname -r`-(tag) `uname -r`
[ The `uname -r` returns the kernel revision ]
and how do i specify which drivers to (not) include in the new initrd?
The mkinitrd binary is pretty smart at what to and what to not include. E.g., it figures Ext2/3 if the root is Ext2/3 (and Ext2/3 is a filesystem driver), if scsi_hostadapter is defined in modprobe.conf, then the base scsi, that driver, plus sd (SCSI disk) drivers, etc...
In the case of 3Ware, you'll have something like: alias scsi_hostadapter 3w-xxxx (3w-9xxx for 9000) In /etc/modprobe.conf (/etc/modules.conf for 2.4/CentOS3)
You can manually force things with "--with" and "--preload" (to load before the "--with" or other things automagically included).
In the "old days" I used to manually define the load order of the SCSI core, 3Ware driver and SCSI disk modules. But nowdays, the "alias scsi_hostadapter" ensures all 3 are built into the initrd.
This is still blackmagic to me. I have an ISDN PRI card in the system for which I need a specific driver. There is a driver included with the kernel which kudzu always wants to install but I don't want initrd to include that driver.
If it's _not_ required to mount the root (/) filesystem, then it doesn't go into the initrd. E.g., filesystem, disk device, SAN (and any networking required), network (if thin client/NFS mounted root), etc... are typically loaded as necessary (NOTE: disk label support is never modular, always static in vmlinuz itself).
An ISDN card driver shouldn't be put in the initrd.
My current workaround is to pull the card from the box before any upgrades, not ideal at all
Ouch. You shouldn't have to do that.
Joshua Baker-LePain jlb17@duke.edu wrote:
Yes. You just need to put the driver in the /lib/modules directory of the right kernel (in place of the old driver), and then make a new initrd for the kernel you're running.
Anal Note: Don't forget to run "depmod -a" between the two steps.
On Fri, 9 Sep 2005, Bryan J. Smith wrote:
Joshua Baker-LePain jlb17@duke.edu wrote:
Yes. You just need to put the driver in the /lib/modules directory of the right kernel (in place of the old driver), and then make a new initrd for the kernel you're running.
Anal Note: Don't forget to run "depmod -a" between the two steps.
OK, so the full sequence would be :
cd /lib/modules/2.6.9-11.ELsmp/kernel/drivers/scsi/ mv 3w-9xxx.ko 3w-9xxx.dist cp ~/src/driver-9.2.1.1/3w-9xxx.ko 3w-9xxx.9.2.1.1 cp 3w-9xxx.9.2.1.1 3w-9xxx.ko cd /boot/ depmod -a rm initrd-2.6.9-11.ELsmp.img mkinitrd initrd-2.6.9-11.ELsmp.img 2.6.9-11.ELsmp
(what on earth does depmod do, depmod --help prints a lot of nice stuff but does't make any sense to me). Is it just to check all required modules are there or is that the util used to specify which modules to (not) load.
How can I see which modules are currently in initrd?
Remco Barendse redhat@barendse.to wrote:
The box doesn't have a floppy drive or anything so it's no so easy to update from floppy.
That's precisely why I keep a 250MB "dd" image with DR-DOS 7.03 on it. I can plop it on any server.
That's also why I _always_ leave several primary partitions and a few GBs free at the beginning of the disk -- _always_. I.e., my root (/) or /boot is _always_ /dev/sda3, and everything else goes in /dev/sda4 (which may be LVM/LVM2).
I can plop that 250MB "dd" image down as /dev/sda1 at a moments notice, and reconfigure GRUB to chainload it.
My boot volume is on the 3Ware
I know. I just boot DR-DOS 7.03 "clean". Even though the "C:" it's on the 3Ware volume, the firmware update works.
On Fri, 9 Sep 2005, Bryan J. Smith wrote:
Remco Barendse redhat@barendse.to wrote:
The box doesn't have a floppy drive or anything so it's no so easy to update from floppy.
That's precisely why I keep a 250MB "dd" image with DR-DOS 7.03 on it. I can plop it on any server.
That's also why I _always_ leave several primary partitions and a few GBs free at the beginning of the disk -- _always_. I.e., my root (/) or /boot is _always_ /dev/sda3, and everything else goes in /dev/sda4 (which may be LVM/LVM2).
I can plop that 250MB "dd" image down as /dev/sda1 at a moments notice, and reconfigure GRUB to chainload it.
My boot volume is on the 3Ware
I know. I just boot DR-DOS 7.03 "clean". Even though the "C:" it's on the 3Ware volume, the firmware update works.
Thanks for the tips. I don't know if I'd want an extra partition on all my servers.
An alternative idea, create a DOS boot disc with the firmware update, burn that as a bootable cdrom and perform the upgrade.
I tried that last week but for some reason the cd didn't boot but that's probably more because I goofed up creating the cd :)
And I don't care about the cost of a cd recordable compared to not upgrading the controller
Remco Barendse redhat@barendse.to wrote:
Thanks for the tips. I don't know if I'd want an extra partition on all my servers.
Reserving 1-8GB at the front of my server's array volume has saved my bacon so many times -- DOS for firmware upload, vendor diagnostic tool, helper Linux install for recovery, etc...
An alternative idea, create a DOS boot disc with the firmware update, burn that as a bootable cdrom and perform the upgrade.
Assuming you have at least CD-ROM drive. ;-> And sometimes there can be issues with that.
E.g., ServerWorks ServerSet III southbridges were not always well known for their "good" ATA support.
I tried that last week but for some reason the cd didn't boot but that's probably more because I goofed up creating the cd :)
Instead of dorking with all that, I can plop down the dd image. I purposely leave an unused /dev/hda1 of cylinders 1-79 (assuming 255/63 heads/sectors) in case I do need to plop down that dd image. In many cases, I go ahead and set it up anyway -- just in case (leaving /dev/hda2 for any possible Linux install as a "helper" system).
Once it's there, copying over a vendor firmware .com/.exe and other files is a matter of mounting /dev/hda1 as msdos (not vfat ;-), and plopping it. No CD building issues.
And I don't care about the cost of a cd recordable compared to not upgrading the controller
What I care about is the only 5 seconds it takes me to mount the msdos filesystem, copy the vendor firmware .com/.exe and other files, and then unmount versus the minutes to put together a boot CD or USB image.
Bryan J. Smith wrote:
[snip]
Once it's there, copying over a vendor firmware .com/.exe and other files is a matter of mounting /dev/hda1 as msdos (not vfat ;-), and plopping it. No CD building issues.
[snip]
This is interesting. What is the exact difference between msdos and vfat? Long file names?
Mike
-
Bryan J. Smith -
Joshua Baker-LePain -
Mike McCarty -
Remco Barendse