Messages in this thread | | | Date | Tue, 21 Aug 2001 17:35:50 -0700 (PDT) | From | Matthew Jacob <> | Subject | Re: Qlogic/FC firmware |
| |
> > Other than it's age, I see *zero* reason to remove it from the tree. > > Well let me quote from it again > > /* > * W W A RRRR N N IIIII N N GGG > * W W A A R R N N I N N G G > * W W A A R R NN N I NN N G > * W W W AAAAA RRR N N N I N N N G GG > * W W W A A R R N NN I N NN G G > * W W W W A A R R N N I N N G G > * W W A A R R N N IIIII N N GGGG > * > * This version of firmware is a release candidate, > * design verification testing (DVT) has not been completed. > */ > > or in simple terms "might lose all your data"
Take this with a grain of salt. It's true that it hasn't passed DVT. But it's also true that f/w which *has* passed DVT has eaten your data as well.
Almost precisely by definition, if the system you embed this firmware in is *not* one that has gone thru Qlogic DVT, you should in fact be putting the warning on yourself.
> > > >Well maybe, and whats the right way to do that, oh my god I do believe its > > >an initrd. > > > > __init_data > > Doesnt work in modules. See previous twice repeated discussion. > > As Matthew has noted, we have a source of newer firmware, and because the > sparc's have this annoying firmware problem it is going to be appropriate > to add build in firmware as a config option (probably set with def_bool on > sparc..) > > At the time a) I didnt realise the sparc setup was so anal, and b) I didnt > know about the firmware update. >
It's not just a question of having firmware updated into flash- which, btw, companies like Veritas have shied away from getting custoemrs to do because you *do* have a small but finite amount of risk updating flash. It's also code that as yet has to be written for qlogicfc (e.g.) that would pull it *out* of flash so it can be pushed into SRAM (which is what the BIOS code on other platforms do).
-matt
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |