Hello! I'm having problems with K-TEK-M275TP-FN-BL-ML keyboard
(http://www.key-tek.cn/Productview.asp?id=777). It is USB device with
keyboard and touchpad combined. It works in OS correctly, but doesn't work
in SeaBIOS.
I've tried to debug this issue and found that "usb_kbd_setup" function fails
on "(epdesc->wMaxPacketSize != 8)" check, cause "epdesc->wMaxPacketSize" is
actually 32. I've modified this "if" statement to pass 32 value also and now
function completes successfully. But it didn't help to solve my issue. There
are no interrupts from keyboard, "ehci_poll_intr" always returns -1 on
check:
if (token & QTD_STS_ACTIVE) {
// No intrs found.
return -1;
}
I don't know what to do now. What should I check next?
Does SeaBIOS support USB keyboard+touchpad devices at all?
When TCGBIOS is enabled on a machine without a physical TPM, SeaBIOS
takes over half a minute to print to the display, and over another half
minute before handing control over to a boot device. Disable this option
by default to have it be an explicit choice.
Tested on a Dell Inspiron 660s (no TPM) configured with libgfxinit, and,
separately, configured with a PCIe video card with onboard VGA BIOS.
Signed-off-by: Jean Lucas <jean(a)4ray.co>
---
src/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/Kconfig b/src/Kconfig
index 55a87cb..b5d370a 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -467,7 +467,7 @@ menu "BIOS interfaces"
config TCGBIOS
depends on S3_RESUME
bool "TPM support and TCG BIOS extensions"
- default y
+ default n
help
Provide TPM support along with TCG BIOS extensions
--
2.16.2
Recently both qemu.git and xen.git updated their copy of seabios.
Qemu is broken quite some time already, now also xen fails after
updating from rel-1.10.2 to rel-1.11.1.
This happens in SLE11 which uses gcc-4.3:
[ 86s] Compile checking out/src/hw/blockcmd.o
[ 86s] src/hw/blockcmd.c: In function 'scsi_rep_luns_scan':
[ 86s] src/hw/blockcmd.c:229: error: unknown field 'cdbcmd' specified in initializer
[ 86s] src/hw/blockcmd.c:229: warning: missing braces around initializer
[ 86s] src/hw/blockcmd.c:229: warning: (near initialization for 'op.<anonymous>')
[ 86s] src/hw/blockcmd.c:229: warning: initialization makes integer from pointer without a cast
[ 86s] make[7]: *** [out/src/hw/blockcmd.o] Error 1
How can this be fixed?
Olaf
On Tue, Mar 27, 2018 at 10:08:20AM +0800, Zhe Liu wrote:
> Dear Kevin,
> Thanks for getting back to me. Your replay helps me a lot. And there
> are two things I want to make clear.
> 1. > The real-mode handlers installed at 0x60-0x66 are intended for
> software interrupts.
> During the booting of the vm seabios, which modules will raise the software
> interrupts? (Qemu? KVM? VirtualMachine?)
Software interrupts are for guest software to raise and interally
catch. Some old DOS-era software does this.
> 2. In src/post.c: init_ivt, the handlers for 0x60-0x66 is set to none
> as below.
> for (i=0x60; i<=0x66; i++)
> SET_IVT(i, SEGOFF(0, 0));
> If I change the handlers of 0x60-0x66 to default handler, which is
> "iret" directly, is there some side effects?
It might break some old DOS-era software.
Notably, though, if something external is raising random interrupts,
it's likely going to cause havoc with both modern and old software.
-Kevin
This series of patches attempts to fix the probing of the CRB interface
for real hardware.
Stephen Douthit tested the changes on real hardware and it seems to
fix an existing problem.
Stefan
v1->v2:
- test LOC_STATE register for set tpmRegValidSts flag and unset
locAssigned flag without writing to any other registers
Stefan Berger (3):
tpm: Wait for tpmRegValidSts flag on CRQ interface before probing
tpm: revert return values for successful/failed CRB probing
tpm: when CRB is active, select, lock it, and check addresses
src/hw/tpm_drivers.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
--
2.5.5
On Thu, Mar 22, 2018 at 11:40:46AM +0800, Zhe Liu wrote:
> Hi!
> Recently, I encountered a seabios hanging problem. When I try to inject an
> MSI-X interrupt along with SMI in qemu like below:
> *************** patch below*********************
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c- a/target-i386/kvm.c
>
>
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
>
> @@ -104,6 +104,7 @@ static uint32_t num_architectural_pmu_counters;
> static int has_xsave;
> static int has_xcrs;
> static int has_pit_state2;
> +static int msi_count;
>
> static bool has_msr_mcg_ext_ctl;
>
> @@ -2870,12 +2871, 26 @@ void kvm_arch_pre_run(CPUState *cpu, struct
> kvm_run *run)
> DPRINTF("inject SMI\n");
> + MSIMessage msg = {.address = 0x0, .data = 0x4062};
> + if (msi_count == 1) {
> + ret = kvm_irqchip_send_msi(kvm_state, msg);
> + if (ret <0) {
> + QEMU_LOG(LOG_ALERT, "MSI lost %s\n", strerror(-ret));
> + }
> + }
> + msi_count++;
>
> ret = kvm_vcpu_ioctl(cpu, KVM_SMI);
> if (ret < 0)
> **************patch above*************************
>
> Then, when the vm will hang when booting.
> There will be only one line in the vnc displayer:
> "Guest has not initialized the display(yet)"
>
> I went through the codes(kvm qemu seabios), and I found the check_irqs
> function in seabios will allow interrupt for a while.
> When the interrupt triggered, the vcpu will lookup the seabios IDT table
> and jump to the interrupt handler.
>
> However, in ivt_init(void), the entries from 0x60 to 0x66 will be cleared,
> which is configured by the patch below.
>
> https://github.com/coreboot/seabios/commit/b164d2c1b8ff2dd764dcf064e2624d...
>
> So the vcpu will jump to an undefined entry instead of the default entry.
>
> =========================================================================
> I removed the patch, and the bug seems to disappear. I wonder if this is an
> approprite solution.
This doesn't seem like a SeaBIOS issue. The real-mode handlers
installed at 0x60-0x66 are intended for software interrupts; not for
hardware raised interrupts.
I don't know why the machine irq routing would deliver a hardware
interrupt to that vector, but I suspect that is what needs to be
looked at.
-Kevin
Hi!
Recently, I encountered a seabios hanging problem. When I try to inject an
MSI-X interrupt along with SMI in qemu like below:
*************** patch below*********************
diff --git a/target-i386/kvm.c b/target-i386/kvm.c- a/target-i386/kvm.c
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -104,6 +104,7 @@ static uint32_t num_architectural_pmu_counters;
static int has_xsave;
static int has_xcrs;
static int has_pit_state2;
+static int msi_count;
static bool has_msr_mcg_ext_ctl;
@@ -2870,12 +2871, 26 @@ void kvm_arch_pre_run(CPUState *cpu, struct
kvm_run *run)
DPRINTF("inject SMI\n");
+ MSIMessage msg = {.address = 0x0, .data = 0x4062};
+ if (msi_count == 1) {
+ ret = kvm_irqchip_send_msi(kvm_state, msg);
+ if (ret <0) {
+ QEMU_LOG(LOG_ALERT, "MSI lost %s\n", strerror(-ret));
+ }
+ }
+ msi_count++;
ret = kvm_vcpu_ioctl(cpu, KVM_SMI);
if (ret < 0)
**************patch above*************************
Then, when the vm will hang when booting.
There will be only one line in the vnc displayer:
"Guest has not initialized the display(yet)"
I went through the codes(kvm qemu seabios), and I found the check_irqs
function in seabios will allow interrupt for a while.
When the interrupt triggered, the vcpu will lookup the seabios IDT table
and jump to the interrupt handler.
However, in ivt_init(void), the entries from 0x60 to 0x66 will be cleared,
which is configured by the patch below.
https://github.com/coreboot/seabios/commit/b164d2c1b8ff2dd764dcf064e2624d...
So the vcpu will jump to an undefined entry instead of the default entry.
=========================================================================
I removed the patch, and the bug seems to disappear. I wonder if this is an
approprite solution.
=========================================================================
There is an another strange thing:
I opened kvm trace, and it showed like below:
************************
kvm_inj_exception: #UD(0x0)
kvm_entry: vcpu0
kvm_run: vcpu 0 to guest mode
kvm_run: vcpu 0 out guest mode
kvm_exit: reason EXCEPTION_NMI rip 0x3 info 0 80000306
kvm_emulate_insn: 0:3:f0 53 (real)
kvm_inj_exception: #UD(0x0)
kvm_entry: vcpu0
kvm_run: vcpu 0 to guest mode
kvm_run: vcpu 0 out guest mode
kvm_exit: reason EXCEPTION_NMI rip 0x3 info 0 80000306
kvm_emulate_insn: 0:3:f0 53 (real)
************************
It seems the emulation got wrong at cs:eip = 0:0x3, but the entry is set to
0 in ivt_init(void).
thanks!
Hi,
Time to prepare a 1.11-stable release, so we can pick up bugfixes for the
upcoming qemu release. Looking at the commits I think these should go in:
a3c93bd81d build: Use git describe --always
42812e062a shadow: Don't invoke a shutdown on reboot unless in a reboot loop
14d91c353e pci: fix 'io hints' capability for RedHat PCI bridges
0541f2f0f2 paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified
Comments? Other suggestions?
thanks,
Gerd
