Open stsp opened 8 years ago
After reboot, the problem reliably re-appears. So what it does is some I/O in PCI config space in a loop. Maybe the mode listing should simply be disabled? Not the most important info IMHO.
No, not PCI conf. It talks to video card regs at 0xe000 IO space.
It turns out the problem happens only if booted with KMS driver. With nomodeset=1 the problem does not happen. This may be a vbios quirk, but in general using VBE functions with kms is unsafe. I suspect the mode listing should be disabled. Hope at least 4f00 func is safe as it doesn't need to talk to card perhaps.
Please test the latest version.
I tried sudo hwinfo --vbe and it hanged on probing video modes.
(gdb) bt
0 0x00007fbecd31292a in tsc () at include/x86emu_int.h:121
1 x86emu_run (emu=0x5803519f, flags=25) at decode.c:252
2 0x000000000207c8d0 in ?? ()
3 0x00007fbecd9141b1 in vm_run (emu=0x20cc0f0, emu@entry=0x2212a80,
4 0x00007fbecd914948 in list_modes (vm=0x110, vm@entry=0x20cc0f0,
5 0x00007fbecd915a85 in get_vbe_info (hd_data=0x2079010, vbe=0x207c8d0)
6 0x00007fbecd9462db in hd_scan_bios (hd_data=hd_data@entry=0x2079010)
7 0x00007fbecd926bc0 in hd_scan_no_hal (hd_data=0x2079010) at hd.c:2027
8 hd_scan (hd_data=hd_data@entry=0x2079010) at hd.c:1913
9 0x00007fbecd9277c8 in hd_list (hd_data=0x2079010, item=item@entry=hw_vbe,
10 0x0000000000404387 in do_hw (hd_data=hd_data@entry=0x2079010,
11 0x00000000004026f6 in main (argc=2, argv=) at hwinfo.c:365
I've googled out the similar problem here: http://bugs.rosalinux.ru/show_bug.cgi?id=7299
Unfortunately, while trying to debug it, it have suddenly disappeared. I guess perhaps something is not properly initialized?