Am 1. Juli 2023 11:58:57 UTC schrieb Mark Cave-Ayland
:
>On 01/07/2023 10:53, Bernhard Beschow wrote:
>
>> Am 30. Juni 2023 08:48:02 UTC schrieb Paolo Bonzini :
>>> Il mer 28 giu 2023, 13:28 Bernhard Beschow ha scritto:
>>>
Am 27. Juni 2023 12:07:40 UTC schrieb Olaf Hering :
On 01/07/2023 10:53, Bernhard Beschow wrote:
Am 30. Juni 2023 08:48:02 UTC schrieb Paolo Bonzini :
Il mer 28 giu 2023, 13:28 Bernhard Beschow ha scritto:
Am 27. Juni 2023 12:07:40 UTC schrieb Olaf Hering :
Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow :
The BAR is a 32 bit register
Am 30. Juni 2023 08:48:02 UTC schrieb Paolo Bonzini :
>Il mer 28 giu 2023, 13:28 Bernhard Beschow ha scritto:
>
>>
>>
>> Am 27. Juni 2023 12:07:40 UTC schrieb Olaf Hering :
>> >Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow :
>> >
>> >> The BAR is a 32 bit register whose default value is
Am 30. Juni 2023 11:32:42 UTC schrieb Olaf Hering :
>Fri, 30 Jun 2023 08:05:29 + Bernhard Beschow :
>
>> Yes. Have a look for piix3/piix4 here:
>> https://www.intel.com/design/archives/chipsets/440/index.htm
>
>This is hidden behind a login or whatever.
None of the links ask annoying
Fri, 30 Jun 2023 08:05:29 + Bernhard Beschow :
> Yes. Have a look for piix3/piix4 here:
> https://www.intel.com/design/archives/chipsets/440/index.htm
This is hidden behind a login or whatever.
I should be able to come up with a commit message without hardware specs being
available.
Il mer 28 giu 2023, 13:28 Bernhard Beschow ha scritto:
>
>
> Am 27. Juni 2023 12:07:40 UTC schrieb Olaf Hering :
> >Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow :
> >
> >> The BAR is a 32 bit register whose default value is 0x0001. I think
> what's supposed to happen here is a
Am 30. Juni 2023 07:29:21 UTC schrieb Olaf Hering :
>Wed, 28 Jun 2023 09:27:16 + Bernhard Beschow :
>
>> Would you mind sending a patch fixing the BMIBA register to be reset as 32
>> bit?
>
>Will do so next week.
Great! Perhaps it could then be picked up by maintainers together with my
Wed, 28 Jun 2023 09:27:16 + Bernhard Beschow :
> Would you mind sending a patch fixing the BMIBA register to be reset as 32
> bit?
Will do so next week.
Are the specs for this chipset available, does this address really need
to be accessed in quantities of u32, or is perhaps u16 required?
Am 27. Juni 2023 12:07:40 UTC schrieb Olaf Hering :
>Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow :
>
>> The BAR is a 32 bit register whose default value is 0x0001. I think
>> what's supposed to happen here is a pci_set_long() rather than a
>> pci_set_byte().
>
>Indeed, the u32 at
Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow :
> The BAR is a 32 bit register whose default value is 0x0001. I think
> what's supposed to happen here is a pci_set_long() rather than a
> pci_set_byte().
Indeed, the u32 at that address changes from c121 to c101 with the current code.
Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow :
> Bits 4..15 represent the BAR address, and pci_set_byte() only clears bits
> 4..7, leaving bits 8..15 unchanged. Perhaps this causes the BAR to be moved
> into the UHCI region? Does changing the call to pci_set_long() fix the
> problem?
Mon, 26 Jun 2023 23:19:01 +0200 Olaf Hering :
> So far I was unable to decipher how the pci_set_word calls can
> possibly affect the outcome and the owner of memory_region_ops_read.
It is enough to return from piix_ide_reset right after
pci_set_word(pci_conf + PCI_COMMAND, 0) to trigger the
Am 27. Juni 2023 07:11:33 UTC schrieb Paolo Bonzini :
>On 6/26/23 23:19, Olaf Hering wrote:
>> I need advice on how to debug this.
>>
>> One thing that stands out is uhci_irq().
>> It reads a u16 from the USBSTS register.
>>
>> On the qemu side, this read is served from bmdma_read. Since the
On 6/26/23 23:19, Olaf Hering wrote:
I need advice on how to debug this.
One thing that stands out is uhci_irq().
It reads a u16 from the USBSTS register.
On the qemu side, this read is served from bmdma_read. Since the read
size is 2, the result is ~0, and uhci_irq() turns the controller off.
I need advice on how to debug this.
One thing that stands out is uhci_irq().
It reads a u16 from the USBSTS register.
On the qemu side, this read is served from bmdma_read. Since the read
size is 2, the result is ~0, and uhci_irq() turns the controller off.
In other words,
Am Tue, 16 May 2023 13:38:42 -0400
schrieb John Snow :
> I haven't touched IDE or block code in quite a long while now -- I
> don't think I can help land this fix, but I won't get in anyone's way,
> either. Maybe just re-submit the patches with an improved commit
> message / cover letter that
On Fri, May 12, 2023 at 5:14 PM Stefano Stabellini
wrote:
>
> On Wed, 10 May 2023, Olaf Hering wrote:
> > Wed, 10 May 2023 00:58:27 +0200 Olaf Hering :
> >
> > > In my debugging (with v8.0.0) it turned out the three pci_set_word
> > > causes the domU to hang. In fact, it is just the last one:
> >
On Wed, 10 May 2023, Olaf Hering wrote:
> Wed, 10 May 2023 00:58:27 +0200 Olaf Hering :
>
> > In my debugging (with v8.0.0) it turned out the three pci_set_word
> > causes the domU to hang. In fact, it is just the last one:
> >
> >pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
> >
Wed, 10 May 2023 00:58:27 +0200 Olaf Hering :
> In my debugging (with v8.0.0) it turned out the three pci_set_word
> causes the domU to hang. In fact, it is just the last one:
>
>pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
>
> It changes the value from 0xc121 to 0x1.
If I
Resuming this old thread about an unfixed bug, which was introduced in qemu-4.2:
qemu ends up in piix_ide_reset from pci_unplug_disks.
This was not the case prior 4.2, the removed call to
qemu_register_reset(piix3_reset, d) in
ee358e919e385fdc79d59d0d47b4a81e349cd5c9 did apparently nothing.
In
On 25/03/21 12:12, Olaf Hering wrote:
Am Mon, 22 Mar 2021 18:09:17 -0400
schrieb John Snow :
My understanding is that XEN has some extra disks that it unplugs when
it later figures out it doesn't need them. How exactly this works is
something I've not looked into too closely.
It has no extra
Am Mon, 22 Mar 2021 18:09:17 -0400
schrieb John Snow :
> My understanding is that XEN has some extra disks that it unplugs when
> it later figures out it doesn't need them. How exactly this works is
> something I've not looked into too closely.
It has no extra disks, why would it?
I assume
On 3/17/21 3:00 AM, Olaf Hering wrote:
Commit ee358e919e385fdc79d59d0d47b4a81e349cd5c9 causes a regression in
Xen HVM domUs which run xenlinux based kernels.
If the domU has an USB device assigned, for example with
"usbdevice=['tablet']" in domU.cfg, the late unplug of devices will
kill the
Commit ee358e919e385fdc79d59d0d47b4a81e349cd5c9 causes a regression in
Xen HVM domUs which run xenlinux based kernels.
If the domU has an USB device assigned, for example with
"usbdevice=['tablet']" in domU.cfg, the late unplug of devices will
kill the emulated USB host. As a result the khubd
24 matches
Mail list logo
