On Wed, Nov 28, 2018 at 12:14:07PM +0100, Laszlo Ersek wrote: > Right. Before I raised my short question about *not* short-circuiting > get_pnp_rom() with "isvga" set, I had read through the BZ, and I was > *very* tempted to say "this is what's wrong with our industry". :) The > oprom in question is mind-bogglingly broken, from the discussion / > analysis in the BZ. > > (I'm sure somewhere deep in an internal bug tracking system at the card > vendor there is a ticket about some broken platform BIOS where the BEV > wouldn't work, and they had to hook Int19h.)
Right - fundamental to X86 booting is the idea that firmware developers write code, PC manufacturers write code, peripheral manufacturers write code, and only users test all the code together. It's a broken workflow. It's been nearly 40 years and X86 is still stuck in this broken workflow. > >> I'm leery of making a change like this, because there's a good chance > >> it will break something in some other obscure software. > > > > I've added a rather verbose message printing some information about the > > rom because of that. > > > >> I think fixing this in iPXE would be preferable if possible. > > > > See above. ipxe doesn't need fixing. > > I support the addition of this "safety code", and I tend to agree (with > the BZ discussion) that making it *dynamically* configurable could be > difficult and/or overkill. > > Kevin, would you feel easier about the Int19h vector restoration if it > were controlled by a new, static, config knob? If we could do it safely that would be fine. My fear is that it introduces a regression. A new config option would be okay, but it doesn't sound like that will help, as it seems that once one narrows down the problem to a bad behaving optionrom, one could just as easily block that optionrom instead.. I'm not sure what the best choice is. -Kevin _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
