* Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > > isapc should never be SMP, so the keyboard reset would be enough even if
> > > it were fixed to be an INIT. Hence my suggestion of using 0xcf9 for
> > > recent QEMU with PCI machine types, followed by keyboard reset for old
> > > QEMU +
Hi,
> > isapc should never be SMP, so the keyboard reset would be enough even if
> > it were fixed to be an INIT. Hence my suggestion of using 0xcf9 for
> > recent QEMU with PCI machine types, followed by keyboard reset for old
> > QEMU + isapc.
>
> Any chance of getting this fix into the
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 18/02/2017 17:55, Kevin O'Connor wrote:
> > On Sat, Feb 18, 2017 at 04:11:28PM +0100, Paolo Bonzini wrote:
> >> On 18/02/2017 04:45, Kevin O'Connor wrote:
> >>> On Fri, Feb 17, 2017 at 02:12:57PM +0100, Paolo Bonzini wrote:
> On
On 18/02/2017 17:55, Kevin O'Connor wrote:
> On Sat, Feb 18, 2017 at 04:11:28PM +0100, Paolo Bonzini wrote:
>> On 18/02/2017 04:45, Kevin O'Connor wrote:
>>> On Fri, Feb 17, 2017 at 02:12:57PM +0100, Paolo Bonzini wrote:
On 15/02/2017 18:35, Dr. David Alan Gilbert wrote:
> Yes it seems
On Sat, Feb 18, 2017 at 04:11:28PM +0100, Paolo Bonzini wrote:
> On 18/02/2017 04:45, Kevin O'Connor wrote:
> > On Fri, Feb 17, 2017 at 02:12:57PM +0100, Paolo Bonzini wrote:
> >> On 15/02/2017 18:35, Dr. David Alan Gilbert wrote:
> >>> Yes it seems to.
> >>> One worry is that if we ever fix the
On 18/02/2017 04:45, Kevin O'Connor wrote:
> On Fri, Feb 17, 2017 at 02:12:57PM +0100, Paolo Bonzini wrote:
>> On 15/02/2017 18:35, Dr. David Alan Gilbert wrote:
>>> Yes it seems to.
>>> One worry is that if we ever fix the qemu triple-fault so it really
>>> does what you're describing and only
On Fri, Feb 17, 2017 at 02:12:57PM +0100, Paolo Bonzini wrote:
> On 15/02/2017 18:35, Dr. David Alan Gilbert wrote:
> > Yes it seems to.
> > One worry is that if we ever fix the qemu triple-fault so it really
> > does what you're describing and only resets the CPU, then I'm not
> > sure your int3
On 02/17/17 14:10, Paolo Bonzini wrote:
>
>
> On 15/02/2017 16:52, Kevin O'Connor wrote:
>> On Wed, Feb 15, 2017 at 11:01:03AM +0100, Laszlo Ersek wrote:
>>> On 02/14/17 20:14, Kevin O'Connor wrote:
On Tue, Feb 14, 2017 at 07:52:01PM +0100, Laszlo Ersek wrote:
> If item (1) is fixed in
On 15/02/2017 18:35, Dr. David Alan Gilbert wrote:
> Yes it seems to.
> One worry is that if we ever fix the qemu triple-fault so it really
> does what you're describing and only resets the CPU, then I'm not
> sure your int3 is the right choice.
>
> The other question is whether that
On 14/02/2017 22:50, Gerd Hoffmann wrote:
> Hi,
>
>> Just for historical perspective - the reason I think qemu didn't
>> implement the pam "read from rom and write to memory" mode is that I
>> don't think there's a good way to emulate that with page tables (and
>> the range needs to be
On 15/02/2017 16:52, Kevin O'Connor wrote:
> On Wed, Feb 15, 2017 at 11:01:03AM +0100, Laszlo Ersek wrote:
>> On 02/14/17 20:14, Kevin O'Connor wrote:
>>> On Tue, Feb 14, 2017 at 07:52:01PM +0100, Laszlo Ersek wrote:
If item (1) is fixed in QEMU, then the above "root cause" goes away, and
* Kevin O'Connor (ke...@koconnor.net) wrote:
> On Wed, Feb 15, 2017 at 11:07:05AM +, Dr. David Alan Gilbert wrote:
> > In the principal of removing our quirks, the following seems to work for me,
> > Kevin, do you agree it's the right behaviour?
>
> I ran some quick tests with your patch and
On 02/15/17 16:52, Kevin O'Connor wrote:
> On Wed, Feb 15, 2017 at 11:01:03AM +0100, Laszlo Ersek wrote:
>> On 02/14/17 20:14, Kevin O'Connor wrote:
>>> On Tue, Feb 14, 2017 at 07:52:01PM +0100, Laszlo Ersek wrote:
If item (1) is fixed in QEMU, then the above "root cause" goes away, and
On Wed, Feb 15, 2017 at 11:07:05AM +, Dr. David Alan Gilbert wrote:
> In the principal of removing our quirks, the following seems to work for me,
> Kevin, do you agree it's the right behaviour?
I ran some quick tests with your patch and I can confirm it fixes the
first problem. However,
On Wed, Feb 15, 2017 at 11:01:03AM +0100, Laszlo Ersek wrote:
> On 02/14/17 20:14, Kevin O'Connor wrote:
> > On Tue, Feb 14, 2017 at 07:52:01PM +0100, Laszlo Ersek wrote:
> >> If item (1) is fixed in QEMU, then the above "root cause" goes away, and
> >> the workaround in SeaBIOS can be
* Kevin O'Connor (ke...@koconnor.net) wrote:
> On Tue, Feb 14, 2017 at 07:04:05PM +0100, Laszlo Ersek wrote:
> > On 02/14/17 18:16, Kevin O'Connor wrote:
> > > Also, the PAM registers on real hardware support a mode where reads to
> > > 0xf return the pristine copy of the bios while writes
On 02/14/17 20:14, Kevin O'Connor wrote:
> On Tue, Feb 14, 2017 at 07:52:01PM +0100, Laszlo Ersek wrote:
>> On 02/14/17 19:43, Kevin O'Connor wrote:
>>> On Tue, Feb 14, 2017 at 07:04:05PM +0100, Laszlo Ersek wrote:
On 02/14/17 18:16, Kevin O'Connor wrote:
> Also, the PAM registers on real
Hi,
> Just for historical perspective - the reason I think qemu didn't
> implement the pam "read from rom and write to memory" mode is that I
> don't think there's a good way to emulate that with page tables (and
> the range needs to be executable so just making it all device memory
> isn't
On Tue, Feb 14, 2017 at 07:52:01PM +0100, Laszlo Ersek wrote:
> On 02/14/17 19:43, Kevin O'Connor wrote:
> > On Tue, Feb 14, 2017 at 07:04:05PM +0100, Laszlo Ersek wrote:
> >> On 02/14/17 18:16, Kevin O'Connor wrote:
> >>> Also, the PAM registers on real hardware support a mode where reads to
>
* Kevin O'Connor (ke...@koconnor.net) wrote:
> On Tue, Feb 14, 2017 at 07:04:05PM +0100, Laszlo Ersek wrote:
> > On 02/14/17 18:16, Kevin O'Connor wrote:
> > > Also, the PAM registers on real hardware support a mode where reads to
> > > 0xf return the pristine copy of the bios while writes
On 02/14/17 19:43, Kevin O'Connor wrote:
> On Tue, Feb 14, 2017 at 07:04:05PM +0100, Laszlo Ersek wrote:
>> On 02/14/17 18:16, Kevin O'Connor wrote:
>>> Also, the PAM registers on real hardware support a mode where reads to
>>> 0xf return the pristine copy of the bios while writes update
>>>
On Tue, Feb 14, 2017 at 07:04:05PM +0100, Laszlo Ersek wrote:
> On 02/14/17 18:16, Kevin O'Connor wrote:
> > Also, the PAM registers on real hardware support a mode where reads to
> > 0xf return the pristine copy of the bios while writes update
> > memory. I didn't think there was any
* Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > Do you mean a workaround for the (historically lacking) emulation of the
> > PAM chipset registers? PAM emulation has been correct for quite a while
> > now in QEMU, as far as I can tell.
> >
> > (Sorry if I'm completely off.)
>
> That
On 02/14/17 18:16, Kevin O'Connor wrote:
> On Tue, Feb 14, 2017 at 05:36:34PM +0100, Laszlo Ersek wrote:
>> On 02/14/17 17:22, Kevin O'Connor wrote:
>>> On Tue, Feb 14, 2017 at 02:50:23PM +, Dr. David Alan Gilbert wrote:
I've been sporadically carrying on debugging this and I
think I
Hi,
> Do you mean a workaround for the (historically lacking) emulation of the
> PAM chipset registers? PAM emulation has been correct for quite a while
> now in QEMU, as far as I can tell.
>
> (Sorry if I'm completely off.)
That was the first thing coming to my mind too.
So, yes, recent
On Tue, Feb 14, 2017 at 05:36:34PM +0100, Laszlo Ersek wrote:
> On 02/14/17 17:22, Kevin O'Connor wrote:
> > On Tue, Feb 14, 2017 at 02:50:23PM +, Dr. David Alan Gilbert wrote:
> >> I've been sporadically carrying on debugging this and I
> >> think I have a bit more understanding, but not
* Kevin O'Connor (ke...@koconnor.net) wrote:
> On Tue, Feb 14, 2017 at 02:50:23PM +, Dr. David Alan Gilbert wrote:
> > I've been sporadically carrying on debugging this and I
> > think I have a bit more understanding, but not quite all the way.
> >
> > I'm pretty sure we are trying to run
On 02/14/17 17:22, Kevin O'Connor wrote:
> On Tue, Feb 14, 2017 at 02:50:23PM +, Dr. David Alan Gilbert wrote:
>> I've been sporadically carrying on debugging this and I
>> think I have a bit more understanding, but not quite all the way.
>>
>> I'm pretty sure we are trying to run code that's
On Tue, Feb 14, 2017 at 02:50:23PM +, Dr. David Alan Gilbert wrote:
> I've been sporadically carrying on debugging this and I
> think I have a bit more understanding, but not quite all the way.
>
> I'm pretty sure we are trying to run code that's been over written
> by variable data - which I
* Kevin O'Connor (ke...@koconnor.net) wrote:
> On Mon, Jan 23, 2017 at 06:49:07PM +, Dr. David Alan Gilbert wrote:
> > * Laszlo Ersek (ler...@redhat.com) wrote:
> > > On 01/23/17 16:49, Kevin O'Connor wrote:
> > > > On Mon, Jan 23, 2017 at 11:11:02AM +0100, Laszlo Ersek wrote:
> > > >> On
On Mon, Jan 23, 2017 at 06:49:07PM +, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
> > On 01/23/17 16:49, Kevin O'Connor wrote:
> > > On Mon, Jan 23, 2017 at 11:11:02AM +0100, Laszlo Ersek wrote:
> > >> On 01/20/17 20:39, Dr. David Alan Gilbert wrote:
> > >>> *
* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
> > On 01/23/17 16:49, Kevin O'Connor wrote:
> > > On Mon, Jan 23, 2017 at 11:11:02AM +0100, Laszlo Ersek wrote:
> > >> On 01/20/17 20:39, Dr. David Alan Gilbert wrote:
> > >>> * Kevin O'Connor
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 01/23/17 16:49, Kevin O'Connor wrote:
> > On Mon, Jan 23, 2017 at 11:11:02AM +0100, Laszlo Ersek wrote:
> >> On 01/20/17 20:39, Dr. David Alan Gilbert wrote:
> >>> * Kevin O'Connor (ke...@koconnor.net) wrote:
> On Fri, Jan 20, 2017 at 06:40:44PM
On 01/23/17 16:49, Kevin O'Connor wrote:
> On Mon, Jan 23, 2017 at 11:11:02AM +0100, Laszlo Ersek wrote:
>> On 01/20/17 20:39, Dr. David Alan Gilbert wrote:
>>> * Kevin O'Connor (ke...@koconnor.net) wrote:
On Fri, Jan 20, 2017 at 06:40:44PM +, Dr. David Alan Gilbert wrote:
> Hi,
>
On 01/20/17 20:39, Dr. David Alan Gilbert wrote:
> * Kevin O'Connor (ke...@koconnor.net) wrote:
>> On Fri, Jan 20, 2017 at 06:40:44PM +, Dr. David Alan Gilbert wrote:
>>> Hi,
>>> I turned the debug level up to 4 on our smaller (128k) ROM downstream
>>> build and seem to have hit a case where
* Kevin O'Connor (ke...@koconnor.net) wrote:
> On Fri, Jan 20, 2017 at 06:40:44PM +, Dr. David Alan Gilbert wrote:
> > Hi,
> > I turned the debug level up to 4 on our smaller (128k) ROM downstream
> > build and seem to have hit a case where it's been layed out so that the
> > 'ExtraStack' is
On Fri, Jan 20, 2017 at 06:40:44PM +, Dr. David Alan Gilbert wrote:
> Hi,
> I turned the debug level up to 4 on our smaller (128k) ROM downstream
> build and seem to have hit a case where it's been layed out so that the
> 'ExtraStack' is at the same location as some code (display_uuid) which
Hi,
I turned the debug level up to 4 on our smaller (128k) ROM downstream
build and seem to have hit a case where it's been layed out so that the
'ExtraStack' is at the same location as some code (display_uuid) which
was causing some very random behaviour;
from an objdump disassemble of the
38 matches
Mail list logo
