blob: 9eeb0ddc84593d20bd570b756cf65b0d014ef7e1 (
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
59
60
61
|
kernel: 0.935
boot: 0.935
mistranslation: 0.866
register: 0.810
PID: 0.732
semantic: 0.724
device: 0.688
user-level: 0.599
graphic: 0.579
performance: 0.543
permissions: 0.513
virtual: 0.491
x86: 0.487
network: 0.463
VMM: 0.443
ppc: 0.420
socket: 0.410
vnc: 0.408
architecture: 0.387
i386: 0.379
risc-v: 0.377
files: 0.376
TCG: 0.368
peripherals: 0.350
arm: 0.337
assembly: 0.311
debug: 0.303
KVM: 0.279
hypervisor: 0.239
linux 2.6.35 hangs with -no-acpi
Linux 2.6.35 hangs at boot when giving -no-acpi to qemu, for instance the Debian kernel:
qemu -no-acpi -kernel /boot/vmlinuz-2.6.35-trunk-686
There is no output except just "Booting the kernel"
On 09/01/2010 01:54 PM, Samuel thibault wrote:
> Public bug reported:
>
> Linux 2.6.35 hangs at boot when giving -no-acpi to qemu, for instance
> the Debian kernel:
>
> qemu -no-acpi -kernel /boot/vmlinuz-2.6.35-trunk-686
>
> There is no output except just "Booting the kernel"
>
Is this a kernel regression? A qemu regression? What do 'info
registers' and 'x/20i $eip' show?
You know better than this.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
Since kernel 2.6.35 is pretty much outdated nowadays, I think we can close this bug now (Feel free to re-open it if necessary).
|
