On Tue, 25 Jul 2000, Malcolm Beattie wrote:
> Me:
> > Upgrading firmware would typically be an unusual enough event the reboot
> > wouldn't be an issue. In the environments where a reboot is unacceptable,
> > a firmware change on-the-fly would probably be unacceptable too...
>
> On the contrary, on important 24x7 systems you don't want to have to
> arrange for downtime just to update firmware/microcode.
I didn't say you would. My point was that changing firmware live on a
production system where any downtime is critical would not be very safe.
> S/390 already supports this (running Linux under VM and maybe running
> it in an LPAR or raw, but I'm not sure) under the name "Concurrent
> Maintenance of LIC" (LIC being Licensed Internal Code, the equivalent
> of microcode or firmware). This includes processors. As other
> architectures begin to play in the five-nines arena, we don't want
> Linux being left behind on those architectures just because of some
> "oh, you can always recompile the kernel or reboot" mentality.
In the case of hard drives, they should be hot-swappable in this
environment - in which case, you can remove them, upgrade them off-line on
a spare workstation, then restore them once you know they work.
What would you have done in your production system if the firmware upgrade
had, say, upset the SCSI ID selection so it conflicted with another drive
in the RAID array? You just lost two drives at once. Or, worse still, if
it starts flooding the bus with crap, because the firmware upgrade went
wrong, or the image had a bug in??
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:20 EST