blob: 3b25ea2d0e1f7d753a2ab9befdca1824bb224a45 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
network: 0.730
architecture: 0.605
ppc: 0.603
performance: 0.581
device: 0.479
files: 0.478
socket: 0.476
mistranslation: 0.459
graphic: 0.457
peripherals: 0.412
kernel: 0.408
hypervisor: 0.404
register: 0.396
semantic: 0.389
permissions: 0.368
vnc: 0.359
boot: 0.341
PID: 0.332
risc-v: 0.321
debug: 0.307
user-level: 0.306
VMM: 0.221
arm: 0.218
i386: 0.217
virtual: 0.215
TCG: 0.192
x86: 0.169
assembly: 0.142
KVM: 0.130
hw/esp.c does not properly deal with TEST_UNIT_READY in NetBSD/sparc
The NetBSD ncr53c9x.c driver does a TEST_UNIT_READY command with SELATN but dma disabled sometimes (early during bus enumeration). This is fine, as the command will not produce nor consume any data, and works on real hardware.
However, the qemu emulation does not allow this (for reasons I don't understand).
The change below fixes the problem.
Guess I understand the code now - so here is a working version - though it may be considered slightly hackish
On Sat, Jun 16, 2012 at 5:50 PM, Martin Husemann <email address hidden> wrote:
> ** Patch added: "esp.c.patch"
> https://bugs.launchpad.net/bugs/1014099/+attachment/3192643/+files/esp.c.patch
Please see this on how to contribute patches to QEMU:
http://wiki.qemu.org/Contribute/SubmitAPatch
Stefan
Patch removed, as it was bogus and your workflow is weird, so I'll post a better patch to the devel list
Has this problem been fixed in 2012, so that we could close this ticket now? Or is there still something left to do?
Yes. Just to make sure I tested qemu 2.8 against an old disk image from 2012 and it boots fine w/o any complaints during the device probes.
|