[lkml]   [2000]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Does this help explain better?? ATA/IDE Thread
re: S/390

if I understand it correctly the S/390 can partition itself on the fly to
run multiple operating systems (including multiple copies of the same
OS) so all you would need to do is to start a new copy of linux that has
the filter turned off and you can get access to your hardware.

David Lang

On Wed, 26
Jul 2000, Malcolm Beattie wrote:

> Date: Wed, 26 Jul 2000 12:58:30 +0100
> From: Malcolm Beattie <>
> To: James Sutherland <>
> Cc: Stephen Frost <>,
> Horst von Brand <>,
> Subject: Re: Does this help explain better?? ATA/IDE Thread
> James Sutherland writes:
> > 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.
> Your point is wrong. You are wrong. Changing firmware on a live
> production S/390 system is safe, supported and has been done for
> years if not decades (I don't know when CMLIC was introduced).
> > > 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.
> Stop thinking only about small systems. Linux runs on large systems
> too. We are talking about systems with maybe hundreds of disks. Not
> only would it be time consuming to hot-swap them all one at a time
> but, in the case of S/390, you're going to have difficulty finding a
> separate system in which to hot-plug the disks. Your "spare
> workstation" would have to be a P/390 with real channel hardware
> attached. This is not the way that things are done.
> > 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??
> Stop thinking about small systems. You have RAID across multiple busses
> (not SCSI) with channel multipathing and hot-boxing. If firmware
> upgrades caused such problems then IBM and the other PCMs would have
> had much egg on their faces and fixed it. Trying to physically remove
> every disk, channel and PU just to do a firmware upgrade on it is far
> worse. It would be similar to requiring disk removal just to do mke2fs.
> And why are your expecting firmware upgrades to go wrong? Do you really
> think a large system vendor would supply untested or broken firmware
> upgrades for a high-reliability system? Once again, stop thinking about
> small systems. (Oh, and even if a channel is flooded with crap, the
> system will automatically hot-box it and choose another path to the
> necessary devices transparently, assuming you've multipathed them as
> you should).
> --Malcolm
> --
> Malcolm Beattie <>
> Unix Systems Programmer
> Oxford University Computing Services
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> Please read the FAQ at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.110 / U:0.284 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site