On Wed, Dec 05, 2018 at 07:55:58AM +0100, Gerd Hoffmann wrote:
> On Fri, Nov 30, 2018 at 12:53:38PM +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > Do you know, for this particular optionrom, if int19 is recaptured and
> > > the user then chooses it from the boot menu, does it continue to work?
>
On Fri, Nov 30, 2018 at 12:53:38PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > Do you know, for this particular optionrom, if int19 is recaptured and
> > the user then chooses it from the boot menu, does it continue to work?
>
> I've asked them to test that.
Feedback arrived: Yes, picking a nic
On Thu, Nov 29, 2018 at 09:25:14AM +0100, Gerd Hoffmann wrote:
> > > 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
On Wed, Nov 28, 2018 at 11:16:57PM +0100, Laszlo Ersek wrote:
> So, if I understand correctly:
>
> - doing something generic in SeaBIOS is too risky / heavy-handed,
> - discriminating individual oproms in SeaBIOS is out of scope.
>
> Well... If we put it like that, I can't say that I disagree.
Hi,
> Unfortunately, I fear no one will see that warning in practice -
> instead I fear a problem would appear as an obscure regression.
Hmm, yes, have to agree to that. Took me a while to figure what was
going on in this case, and regressions causes by this have a good chance
to be equally
Hi,
> > 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
On 11/28/18 19:33, Kevin O'Connor wrote:
> On Wed, Nov 28, 2018 at 06:50:50PM +0100, Laszlo Ersek wrote:
>> On 11/28/18 16:51, Kevin O'Connor wrote:
>>> 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
>>>
On Wed, Nov 28, 2018 at 06:50:50PM +0100, Laszlo Ersek wrote:
> On 11/28/18 16:51, Kevin O'Connor wrote:
> > 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
On 11/28/18 16:51, Kevin O'Connor wrote:
> 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
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
On Wed, Nov 28, 2018 at 07:24:21AM +0100, Gerd Hoffmann wrote:
> On Tue, Nov 27, 2018 at 09:19:09PM -0500, Kevin O'Connor wrote:
> > That is very odd. I'm pretty sure iPXE normally does register itself
> > as a BEV - any idea why it's now hooking int19?
>
> It's not ipxe.
Ah, okay. The
On 11/28/18 07:24, Gerd Hoffmann wrote:
> On Tue, Nov 27, 2018 at 09:19:09PM -0500, Kevin O'Connor wrote:
>> On Tue, Nov 27, 2018 at 01:10:38PM +0100, Gerd Hoffmann wrote:
>>> Check whenever pnp roms attempt to redirect int19, and in case it does
>>> log a message and undo the redirect.
>>>
>>> A
> > @@ -136,9 +137,24 @@ init_optionrom(struct rom_header *rom, u16 bdf, int
> > isvga)
> >
> > tpm_option_rom(newrom, rom->size * 512);
> >
> > -if (isvga || get_pnp_rom(newrom))
> > +struct pnp_data *pnp = get_pnp_rom(newrom);
> > +if (isvga || pnp) {
> Is it OK to call
On Tue, Nov 27, 2018 at 09:19:09PM -0500, Kevin O'Connor wrote:
> On Tue, Nov 27, 2018 at 01:10:38PM +0100, Gerd Hoffmann wrote:
> > Check whenever pnp roms attempt to redirect int19, and in case it does
> > log a message and undo the redirect.
> >
> > A pnp rom should not need this, we have BEVs
On Tue, Nov 27, 2018 at 01:10:38PM +0100, Gerd Hoffmann wrote:
> Check whenever pnp roms attempt to redirect int19, and in case it does
> log a message and undo the redirect.
>
> A pnp rom should not need this, we have BEVs and BCVs for that.
> Nevertheless there are roms in the wild which are
On 11/27/18 13:10, Gerd Hoffmann wrote:
> Check whenever pnp roms attempt to redirect int19, and in case it does
> log a message and undo the redirect.
>
> A pnp rom should not need this, we have BEVs and BCVs for that.
> Nevertheless there are roms in the wild which are redirecting int19.
> At
Check whenever pnp roms attempt to redirect int19, and in case it does
log a message and undo the redirect.
A pnp rom should not need this, we have BEVs and BCVs for that.
Nevertheless there are roms in the wild which are redirecting int19.
At least some BIOS implementations for physical hardware
17 matches
Mail list logo
