[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI
From: |
BALATON Zoltan |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers |
Date: |
Wed, 25 Jun 2014 23:48:54 +0200 (CEST) |
User-agent: |
Alpine 2.02 (LMD 1266 2009-07-14) |
On Wed, 25 Jun 2014, Mark Cave-Ayland wrote:
On 24/06/14 11:53, BALATON Zoltan wrote:
All I can say is that debugging this stuff isn't easy, particularly
with MorphOS which has some rather unusual behaviours. But what we
really need from you now over the next few days is for you to compare
the debug output between the working and non-working cases and figure
out if we can fix this in time for the 2.1 release. You have
everything you need (including my acceptance test of booting both
MorphOS and Darwin ISOs), so time to take a deep breath and begin what
should be a challenging yet ultimately rewarding debugging process :)
I'm still working on finding a solution for the exception problems with
OpenBIOS that prevent MorphOS from working and I failed to understand
the whole working of macio, DBDMA and the whole block layer so far but I
can try to debug it. Can you tell how to reproduce the problem with
Darwin? The Darwin images don't seem to work with -M mac99 either before
or after the patch so no regressions there.
It's fairly simple to reproduce here:
qemu-system-ppc -M g3beige -cdrom darwinppc-602.iso -boot d
qemu-system-ppc -M g3beige -cdrom darwinppc-801.iso -boot d
qemu-system-ppc -M mac99 -cdrom darwinppc-801.iso -boot d
For -M g3beige then darwinppc-602.iso tends to hang just after the "ADB
present" line just before it finds the CDROM.
Rather annoyingly it seems to be a lot trickier to reproduce today than it
was with my original tests, currently 1 in 8 boots compared to 1 in 3 when I
did the OpenBIOS tests. Delays introduced by enabling debugging in
pmac_ide_transfer() seem to make it easier to trigger, as does compiling with
-O0 -g (slower) and also dropping the kernel FS cache.
Maybe it's an existing timing bug that happens to be exacerbated by the
patch? :/
For me darwinppc-602.iso seems to more consistently hang although it did
boot once but I had no debug logs that time. The diff between a boot with
the last two patches reverted (your non-block ATAPI patch and Alex's async
remainder) and HEAD shows this in case it gives a hint to someone:
--- debug-console.log.nopatch
+++ debug-console.log.fail
ATAPI limit=0x0 packet: bb 00 ff ff 00 00 00 00 00 00 00 00
ATAPI limit=0xfffe packet: 43 02 00 00 00 00 00 ff fe 80 00 00
reply: tx_size=48 elem_tx_size=0 index=0
byte_count_limit=65534
status=0x58
reply: tx_size=0 elem_tx_size=0 index=48
status=0x50
ATAPI limit=0x30 packet: 43 02 00 00 00 00 00 00 30 80 00 00
reply: tx_size=48 elem_tx_size=0 index=0
byte_count_limit=48
status=0x58
reply: tx_size=0 elem_tx_size=0 index=48
status=0x50
DBDMA: readl 0x0000000000000d04 => 0x00000000
DBDMA: channel 0x1a reg 0x1
DBDMA: writel 0x0000000000000d08 <= 0x00000000
DBDMA: channel 0x1a reg 0x2
DBDMA: writel 0x0000000000000d0c <= 0x011f8010
DBDMA: channel 0x1a reg 0x3
DBDMA: dbdma_cmdptr_load 0x011f8010
DBDMA: writel 0x0000000000000d00 <= 0x90009000
DBDMA: channel 0x1a reg 0x0
DBDMA: status 0x00009400
DBDMA: DBDMA_run_bh
DBDMA: channel_run
-dbdma_cmd 0x7fc7142f0560
+dbdma_cmd 0x7f58257f4b48
req_count 0x0930
command 0x2000
- phy_addr 0x017ca000
+ phy_addr 0x017cb000
cmd_dep 0x00000000
res_count 0x0000
xfer_status 0x0000
DBDMA: start_input
-DBDMA: addr 0x17ca000 key 0x0
+DBDMA: addr 0x17cb000 key 0x0
-waiting for data (0x3 - 0x930 - 50)
-ATAPI limit=0x930 packet: be 00 00 00 00 00 00 00 01 f8 00 00
-read dma: LBA=0 nb_sectors=1
-
-DBDMA: DBDMA_run_bh
-DBDMA: channel_run
-dbdma_cmd 0x7fc7142f0560
- req_count 0x0930
- command 0x2000
- phy_addr 0x017ca000
- cmd_dep 0x00000000
- res_count 0x0000
- xfer_status 0x0000
-DBDMA: start_input
-DBDMA: addr 0x17ca000 key 0x0
-
-io_buffer_size = 0
-remainder: 0 io->len: 2352 size: 2352
-precopying unaligned 304 bytes to 0x17ca800
-io->len = 0x800
-set remainder to: 0
-sector_num=0 size=2352, cmd_cmd=0
-io_buffer_size = 0x930
-remainder: 0 io->len: 0 size: 0
-end of transfer
-end of DMA
-done DMA
+non-block ATAPI DMA transfer size: 0
+end of non-block ATAPI DMA transfer
DBDMA: dbdma_end
DBDMA: conditional_wait
DBDMA: dbdma_cmdptr_save 0x011f8010
-DBDMA: xfer_status 0x00008400 res_count 0x0000
+DBDMA: xfer_status 0x00008400 res_count 0x0930
DBDMA: conditional_interrupt
DBDMA: conditional_branch
DBDMA: dbdma_cmdptr_load 0x011f8020
DBDMA: channel_run
-dbdma_cmd 0x7fc7142f0560
+dbdma_cmd 0x7f58257f4b48
req_count 0x0000
command 0x6030
phy_addr 0x00000000
cmd_dep 0x00000000
res_count 0x0000
xfer_status 0x0000
DBDMA: conditional_wait
DBDMA: dbdma_cmdptr_save 0x011f8020
DBDMA: xfer_status 0x00008400 res_count 0x0000
DBDMA: conditional_interrupt
DBDMA: conditional_interrupt: raise
DBDMA: conditional_branch
DBDMA: dbdma_cmdptr_load 0x011f8030
DBDMA: DBDMA_run_bh
DBDMA: channel_run
-dbdma_cmd 0x7fc7142f0560
+dbdma_cmd 0x7f58257f4b48
req_count 0x0000
command 0x7000
phy_addr 0x00000000
cmd_dep 0x00000000
res_count 0x0000
xfer_status 0x0000
-DBDMA: writel 0x0000000000000d00 <= 0xa0002000
-DBDMA: channel 0x1a reg 0x0
-DBDMA: status 0x00000000
-DBDMA: readl 0x0000000000000d04 => 0x00000000
-DBDMA: channel 0x1a reg 0x1
-DBDMA: readl 0x0000000000000d04 => 0x00000000
-DBDMA: channel 0x1a reg 0x1
-DBDMA: writel 0x0000000000000d08 <= 0x00000000
-DBDMA: channel 0x1a reg 0x2
-DBDMA: writel 0x0000000000000d0c <= 0x011f8010
-DBDMA: channel 0x1a reg 0x3
-DBDMA: dbdma_cmdptr_load 0x011f8010
-DBDMA: writel 0x0000000000000d00 <= 0x90009000
-DBDMA: channel 0x1a reg 0x0
-DBDMA: status 0x00009400
-DBDMA: DBDMA_run_bh
-DBDMA: channel_run
-dbdma_cmd 0x7fc7142f0560
- req_count 0x0800
- command 0x2000
- phy_addr 0x01526800
- cmd_dep 0x00000000
- res_count 0x0000
- xfer_status 0x0000
-DBDMA: start_input
-DBDMA: addr 0x1526800 key 0x0
-
-waiting for data (0x1 - 0x800 - 58)
-ATAPI limit=0x800 packet: 28 00 00 00 00 00 00 00 01 00 00 00
+ATAPI limit=0x930 packet: be 00 00 00 00 00 00 00 01 f8 00 00
read dma: LBA=0 nb_sectors=1
DBDMA: DBDMA_run_bh
-DBDMA: channel_run
-dbdma_cmd 0x7fc7142f0560
- req_count 0x0800
- command 0x2000
- phy_addr 0x01526800
- cmd_dep 0x00000000
- res_count 0x0000
- xfer_status 0x0000
-DBDMA: start_input
-DBDMA: addr 0x1526800 key 0x0
-
-io_buffer_size = 0
-remainder: 0 io->len: 2048 size: 2048
-io->len = 0x800
-set remainder to: 0
-sector_num=0 size=2048, cmd_cmd=0
-io_buffer_size = 0x800
-remainder: 0 io->len: 0 size: 0
-end of transfer
-end of DMA
-done DMA
-DBDMA: dbdma_end
-DBDMA: conditional_wait
-DBDMA: dbdma_cmdptr_save 0x011f8010
-DBDMA: xfer_status 0x00008400 res_count 0x0000
-DBDMA: conditional_interrupt
-DBDMA: conditional_branch
I'm not sure but could it be that it mistakes a transfer to a non-block
transfer for some reason?
Notes:
Darwin 6.02 doesn't support -M mac99 (always hangs) AFAICT.
Darwin 8.01 works but with -M mac99 IDE detection can take up to 30s or so.
I thought both of these hung but I did not wait 30 seconds.
Regards,
BALATON Zoltan
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, (continued)
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, BALATON Zoltan, 2014/06/23
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, Mark Cave-Ayland, 2014/06/23
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, Kevin Wolf, 2014/06/24
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, BALATON Zoltan, 2014/06/24
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, Alexander Graf, 2014/06/24
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, Kevin Wolf, 2014/06/24
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, Alexander Graf, 2014/06/24
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, Kevin Wolf, 2014/06/24
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, Alexander Graf, 2014/06/24
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, Mark Cave-Ayland, 2014/06/25
- Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers,
BALATON Zoltan <=
- Re: [Qemu-ppc] [PULL 075/118] macio: handle non-block ATAPI DMA transfers, BALATON Zoltan, 2014/06/23
[Qemu-ppc] [PULL 013/118] target-ppc: Remove PVR check from migration, Alexander Graf, 2014/06/04
[Qemu-ppc] [PULL 049/118] target-ppc: Introduce DFP Extract Biased Exponent, Alexander Graf, 2014/06/04
[Qemu-ppc] [PULL 065/118] PPC: Add definitions for GIVORs, Alexander Graf, 2014/06/04
[Qemu-ppc] [PULL 055/118] util: Add InvMixColumns, Alexander Graf, 2014/06/04
[Qemu-ppc] [PULL 021/118] libdecnumber: Eliminate Unused Variable in decSetSubnormal, Alexander Graf, 2014/06/04
[Qemu-ppc] [PULL 070/118] PPC: e500: Expose kernel load address in dt, Alexander Graf, 2014/06/04
[Qemu-ppc] [PULL 019/118] libdecnumber: Change gstdint.h to stdint.h, Alexander Graf, 2014/06/04
[Qemu-ppc] [PULL 072/118] PPC: e500: Move to u-boot as firmware, Alexander Graf, 2014/06/04
[Qemu-ppc] [PULL 063/118] PPC: Fail on leaking temporaries, Alexander Graf, 2014/06/04