Messages in this thread | | | From | nathan.zook@amd ... | Subject | RE: [patch-2.3.46-p2] P6 microcode update support | Date | Wed, 16 Feb 2000 11:33:07 -0600 |
| |
Umm, guys?
This proposal disturbs me. I find the following exchange particularly bothersome:
> -----Original Message----- > From: Tigran Aivazian [mailto:tigran@aivazian.fsnet.co.uk] > > Jan Niehusmann wrote: > > I don't know much about intel microcode, but perhaps a > microcode update > > _may_ change cache handling. So it might work with every microcode > > update available now (because Intel didn't make any incompatible > > changes), but may fail with the next one. > > the approach I take is pragmatic - something works until > proven broken. > If Intel give you microcode you just say thank you and use it. If it > breaks something you complain or work the OS around it yourself. Of > course it can change anything and break anything. But hopefully it > doesn't :)
Now maybe I'm just biased by my validation experience, but the attitude I always take is "it's broken unless demonstrated otherwise". I've had people describe LILO as a loaded gun. Ucode patch is a nuclear reactor. If a vendor says, "Don't do a ucode patch after doing X", then we had better not try a ucode patch after doing X. I know that we like to do uptime competitions, but a ucode patch can be a bigger deal than a minor stepping of a cpu--and no one complains about having to reboot their system when they change processors. :-))
I don't feel that avoiding a reboot is worth risking the damage caused by a failed hot-patch, particularly if the user MUST do a hot-patch.
Nathan Zook
> -----Original Message----- > From: Linus Torvalds [mailto:torvalds@transmeta.com] > Sent: Wednesday, February 16, 2000 11:02 AM > To: Tigran Aivazian > Cc: linux-kernel@vger.rutgers.edu; hpa@transmeta.com > Subject: Re: [patch-2.3.46-p2] P6 microcode update support > > > > Ok, the final patch I've seen looks ok, > > ... BUT ... > > I think we shoul dstart getting rid of /dev files for random > new devices.
- 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/
| |