> Yes, that's correct. However I'm quite confident from booting other
> non-Solaris OSs
> under qemu-system-sparc64 that PCI native mode is being used,
> particularly as it is
> possible to see the related PCI sabre IRQ routing configuration
> changes.
Considering that Solaris 10 is accessing CFR
On 04/03/2020 03:11, jasper.low...@bt.com wrote:
>> cmd646_update_irq() only seems to raise PCI interrupt, should it also
>> have
>> an option to use INT 14 and 15 in legacy mode similar to what my
>> patch
>> does for via-ide?
>
> Looking through /qemu/hw/ide/cmd646.c it doesn't look like QEMU
On Wed, 4 Mar 2020, jasper.low...@bt.com wrote:
cmd646_update_irq() only seems to raise PCI interrupt, should it also
have
an option to use INT 14 and 15 in legacy mode similar to what my
patch
does for via-ide?
Looking through /qemu/hw/ide/cmd646.c it doesn't look like QEMU has
support for leg
> cmd646_update_irq() only seems to raise PCI interrupt, should it also
> have
> an option to use INT 14 and 15 in legacy mode similar to what my
> patch
> does for via-ide?
Looking through /qemu/hw/ide/cmd646.c it doesn't look like QEMU has
support for legacy mode. At the very least, it looks l
I'm happy to do this. It will take a while for me to collect the
results though. I'll chime in once I have the results.
> That should give the ultimate answer to our guessing.
Agreed.
Thanks,
Jasper Lowell.
On Thu, 2020-02-27 at 12:38 +0100, BALATON Zoltan wrote:
> On Thu, 27 Feb 2020, jasper.lo
I haven't.
I did a pull this morning on master and everything seems to be working
again. The problem was likely the same.
Thanks,
Jasper Lowell.
On Thu, 2020-02-27 at 12:35 +0100, BALATON Zoltan wrote:
> On Thu, 27 Feb 2020, jasper.low...@bt.com wrote:
> > > I'll submit a RFC V2 patch with a pro
Hello,
On Wed, 26 Feb 2020, jasper.low...@bt.com wrote:
According to the CMD646U2 specification:
"When an IDE port is in PCI IDE Legacy Mode, the PCI646U2 is compatible
with standard ISA IDE. The IDE task file registers are mapped to the
standard ISA port addresses, and IDE drive interrupts occu
On Thu, 27 Feb 2020, jasper.low...@bt.com wrote:
I've since looked at a Ultra 5 board and can confirm that it shipped
with a CMD646U chip like the Ultra 10.
If you have access to an Ultra 5 maybe you could try testing what it does
with irqs. That should give the ultimate answer to our guessing
On Thu, 27 Feb 2020, jasper.low...@bt.com wrote:
I'll submit a RFC V2 patch with a proposed fix.
This will have to wait.
Recent commits have caused Solaris 10 to error out of booting much
earlier than previously.
Can you bisect which commit broke it? Is it the same that caused slowness
for
> I'll submit a RFC V2 patch with a proposed fix.
This will have to wait.
Recent commits have caused Solaris 10 to error out of booting much
earlier than previously.
Jasper Lowell.
On Thu, 2020-02-27 at 05:10 +, jasper.low...@bt.com wrote:
> I've since looked at a Ultra 5 board and can conf
I've since looked at a Ultra 5 board and can confirm that it shipped
with a CMD646U chip like the Ultra 10.
> Since both the generic PCI IDE and CMD646 Linux drivers mention irq
> is
> cleared on reading status I think using ide_ioport_read in
> hw/ide/pci.c
> may be correct for the generic case
On Wed, 26 Feb 2020, jasper.low...@bt.com wrote:
> Problem with that patch is that it removes this clearing from the func
> that's also used to emulate ISA IDE ioports which according to their
> spec should clear irq on read so that function should be OK but maybe
> should not be called by PCI
> Problem with that patch is that it removes this clearing from the
> func
> that's also used to emulate ISA IDE ioports which according to their
> spec
> should clear irq on read so that function should be OK but maybe
> should
> not be called by PCI IDE code?
This might be it.
The patch I pr
On Tue, 25 Feb 2020, jasper.low...@bt.com wrote:
I don't believe the quick interrupt here is the problem. Solaris 10
will spin for a short time while waiting for the interrupt bit to be
set before continuing with its routine. If it doesn't see the interrupt
bit is set before some timeout, it will
> > ide_exec_cmd 0.461 pid=147030 bus=0x55b77f922d10
> > state=0x55b77f922d98 cmd=0xef
> The command is run here if I'm not mistaken Does this set the irq
> right
> away on QEMU where on real hadware this may take some time? Not sure
> if
> that's a problem but trying to understand what's happen
On Sun, 23 Feb 2020, jasper.low...@bt.com wrote:
ide_exec_cmd 0.461 pid=147030 bus=0x55b77f922d10 state=0x55b77f922d98 cmd=0xef
The command is run here if I'm not mistaken Does this set the irq right
away on QEMU where on real hadware this may take some time? Not sure if
that's a problem but
I'm having another look at the SET_FEATURE Solaris 10 error. I've
enabled tracing and I see the following. The pci_cfg_read that shows up
at the end continues a few thousand times(?) but I've omitted it. This
appears to time out or something and then Solaris gives up on the
device.
ide_ioport_read
On Sat, 22 Feb 2020, BALATON Zoltan wrote:
On Sat, 22 Feb 2020, Mark Cave-Ayland wrote:
On 21/02/2020 06:50, jasper.low...@bt.com wrote:
The Linux libATA API documentation mentions that on some hardware,
reading the status register has the side effect of clearing the
interrupt condition. When e
On Sat, 22 Feb 2020, Mark Cave-Ayland wrote:
On 21/02/2020 06:50, jasper.low...@bt.com wrote:
The Linux libATA API documentation mentions that on some hardware,
reading the status register has the side effect of clearing the
interrupt condition. When emulating the generic Sun4u machine running
S
On 21/02/2020 06:50, jasper.low...@bt.com wrote:
> The Linux libATA API documentation mentions that on some hardware,
> reading the status register has the side effect of clearing the
> interrupt condition. When emulating the generic Sun4u machine running
> Solaris 10, the Solaris 10 CMD646 driver
On Sat, 22 Feb 2020, jasper.low...@bt.com wrote:
This patch doesn't solve all the problems for Solaris 10. It gets
further in the boot process but it is still unable to mount the file
system. I suspect that there are more bugs in the IDE/CMD646 emulation.
I'm going to continue looking into it. It
On Sat, 22 Feb 2020, jasper.low...@bt.com wrote:
I haven't found any documentation that mention that side effect either.
As you say, it only mentions that you should set the bit to clear.
While the side effect of clearing interrupts by reading the status
register doesn't appear to be in documenta
On Sat, 22 Feb 2020, jasper.low...@bt.com wrote:
I think the reason why the Solaris 10 driver crashes fatally whereas
Linux and OpenBSD ignore the side effect is because when clearing
interrupts, Solaris 10 expects the interrupt bit to be set and checks
this. Linux and OpenBSD appear to clear it
> The chip docs don't mention any side effect, they only say that the
> DMA
> IRQ and Error bits in the bus master IDE status reg (bits 2 and 1)
> are
> write 1 to clear
I haven't found any documentation that mention that side effect either.
As you say, it only mentions that you should set the b
On Fri, 21 Feb 2020, jasper.low...@bt.com wrote:
The Linux libATA API documentation mentions that on some hardware,
reading the status register has the side effect of clearing the
interrupt condition. When emulating the generic Sun4u machine running
Solaris 10, the Solaris 10 CMD646 driver exits
Patchew URL:
https://patchew.org/QEMU/20200221065015.337915-1-jasper.low...@bt.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN
The Linux libATA API documentation mentions that on some hardware,
reading the status register has the side effect of clearing the
interrupt condition. When emulating the generic Sun4u machine running
Solaris 10, the Solaris 10 CMD646 driver exits fatally because of this
emulated side effect. This
27 matches
Mail list logo
