SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform
by Kevin O'Connor 19 Dec '15

19 Dec '15

On Thu, Nov 19, 2015 at 12:42:50PM +0000, Xulei (Stone) wrote: > Kevin, > > After deeply analyzing, i think there may be 3 possible reasons: > 1)wrong CountCPUs value. It seems CountCPUs++ in handle_smp() has no > lock to protect. So, sometimes, 2 or more vcpu may get the same > current value of CountCPUs. Then we'll get a single incrementation > instead of 2 or more and "while (cmos_smp_count != CountCPUs)" will > loop forever; The handle_smp() code is called from romlayout.S:entry_smp() which does take a lock. So, all of handle_smp() should run synchronous. > 2)wrong cmos_smp_count value. SeaBIOS rtc reads an incorrect number? Not sure - the last time there were problems in this area of the code others used kvmtrace to try and track this down. Since you are getting dprintf statements, you could also try outputting cmos_smp_count prior to the loop (see patch below). > 3)yield() stuck. Is it possible that SeaBIOS is stuck during yield? > I've tested, when yield() is running, SeaBIOS seems has not created > some other threads except the main thread. So I don't know what's > the function of yield() here.? The yield() allows hardware interrupts to occur. But note that yield() isn't called in the loop - is is only called after the loop completes. If you are only getting this on massive repetitive reboot requests, there are some other possible explanations: - perhaps the SIPI is getting lost because one of the CPUs is still resetting or still processing a SIPI from the last reboot? - the seabios code itself may have been corrupted if the memcpy() in qemu_prep_reset() got far enough along to clear HaveRunPost, but did not get far enough along to fully complete the memcpy(). If the failure is reproducible, the patch below could help narrow the possibilities. -Kevin --- a/src/fw/smp.c +++ b/src/fw/smp.c @@ -125,6 +125,7 @@ smp_setup(void) // Wait for other CPUs to process the SIPI. u8 cmos_smp_count = rtc_read(CMOS_BIOS_SMP_COUNT) + 1; + dprintf(1, "cmos_smp_count=%d\n", cmos_smp_count); while (cmos_smp_count != CountCPUs) asm volatile( // Release lock and allow other processors to use the stack. @@ -136,6 +137,7 @@ smp_setup(void) " jc 1b\n" : "+m" (SMPLock), "+m" (SMPStack) : : "cc", "memory"); + dprintf(1, "finish smp\n"); yield(); // Restore memory.

3 2

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 18 Dec '15

18 Dec '15

On Fri, Dec 18, 2015 at 07:08:24PM +0000, edward wandasiewicz wrote: > Wrong file. Correct file attached. I checked for rel-1.9.0-45-gec65068 Thanks, can you retry with 46-g0cc3233 ? -Kevin

2 1

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by edward wandasiewicz 18 Dec '15

18 Dec '15

Wrong file. Correct file attached. I checked for rel-1.9.0-45-gec65068 Edward. On Fri, Dec 18, 2015 at 6:40 PM, edward wandasiewicz <0.w3ntd(a)gmail.com> wrote: > Done. > > On Fri, Dec 18, 2015 at 6:25 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Fri, Dec 18, 2015 at 06:11:56PM +0000, edward wandasiewicz wrote: >>> As requested. >> >> Thanks, but I had an off-by-one error in the patch - can you do the >> same thing with 45-gec65068? >> >> -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 18 Dec '15

18 Dec '15

On Fri, Dec 18, 2015 at 06:11:56PM +0000, edward wandasiewicz wrote: > As requested. Thanks, but I had an off-by-one error in the patch - can you do the same thing with 45-gec65068? -Kevin

2 1

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by edward wandasiewicz 18 Dec '15

18 Dec '15

---------- Forwarded message ---------- From: "edward wandasiewicz" <0.w3ntd(a)gmail.com> Date: 18 Dec 2015 6:11 p.m. Subject: Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly To: "Kevin O'Connor" <kevin(a)koconnor.net> Cc: As requested. Edward. On Fri, Dec 18, 2015 at 6:00 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > On Fri, Dec 18, 2015 at 11:51:16AM +0000, edward wandasiewicz wrote: >> I managed to replicate a scenario 2 but with Type-C instead of USB 3, >> with both 42-g9c58583 and 43-g55de21d >> >> 2(b) NO - Type C & Type C - once each (Philips & Muskin) - but double >> Philips showing >> >> cbmem.yes.both.TypeC.TypeC.DoublePhilips.42-g9c58583 >> >> cbmem.yes.both.TypeC.TypeC.DoublePhilips.43-g55de21d > > The 43-g55de21d revision was supposed to address the "double philips" > issue. I need some additional debug information - can pull down > 44-g809467a, decrease the debug level to 3, and forward the log from a > "double philips" boot? > > -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 18 Dec '15

18 Dec '15

On Fri, Dec 18, 2015 at 11:51:16AM +0000, edward wandasiewicz wrote: > I managed to replicate a scenario 2 but with Type-C instead of USB 3, > with both 42-g9c58583 and 43-g55de21d > > 2(b) NO - Type C & Type C - once each (Philips & Muskin) - but double > Philips showing > > cbmem.yes.both.TypeC.TypeC.DoublePhilips.42-g9c58583 > > cbmem.yes.both.TypeC.TypeC.DoublePhilips.43-g55de21d The 43-g55de21d revision was supposed to address the "double philips" issue. I need some additional debug information - can pull down 44-g809467a, decrease the debug level to 3, and forward the log from a "double philips" boot? -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 18 Dec '15

18 Dec '15

On Sun, Dec 13, 2015 at 09:16:02PM +0000, edward wandasiewicz wrote: > On Sun, Dec 13, 2015 at 9:05 PM, edward wandasiewicz <0.w3ntd(a)gmail.com> wrote: > > Hooray, it works... minus 2 scenarios :( > > > > With both Philips USB and Mushkin USB attached, and I perform a cold boot > > > > 1. YES - USB 3 & USB 3 - once each (Philips & Mushkin) > > > > cbmem.yes.both.USB3.USB3.gz > > > > 2. NO - USB 3 & USB 3 - once each (Philips & Muskin) - but double > > Philips showing > > > > cbmem.yes.both.USB3.USB3.DoublePhilips.gz > > > > 3. YES - USB 3 & Type C - once each (Philips & Mushkin) > > > > cbmem.yes.both.USB3.TypeC.gz > > > > I can't get a double Philips to appear > > > > 4. YES - Type C & Type C - once each (Philips & Mushkin) > > > > cbmem.yes.both.TypeC.TypeC.gz > > > > 5. NO - Type C & Type C - one Philiips & no Mushkin > > > > I forgot to save > > > > $ cbmem -c > > > > and now can't replicate it. :( If you can't reproduce, it may have been a transient hardware issue (eg, loose plug). Otherwise, to summarize, the devices are now detected pretty reliably, but you still have an issue with double detection of the Philips drive? The double detection looks like the controller doing something weird. I need to look closer at the spec, but I don't think I'll be able to do that until later in the week. > > When I do, I will post output. > > When attempting a cold boot - shutdown - cold boot - shutdown - cold > boot - shutdown - .... > > It seems the list of bootable devices can change order, yet the > devices are plugged into the same ports all the time, and never > unplugged. By default, the order of USB drives in the menu is basically random. If you want to ensure a particular order for USB then a "bootorder" file can be created. You can look at the wiki for info on how to do that, or you can try to extract the bootorder file that John Lewis uses in his roms. -Kevin

3 3

5 basic features provided by CSM, which SeaBIOS does provide?
by Stojsavljevic, Zoran 18 Dec '15

18 Dec '15

Hello both lists, Jiming, There are 5 basic features, provided by CSM SeaBIOS payload, and I am looking to list of these features. Could you, please, provide to me list of these features, and some description, and/or pointer to these descriptions? Thank you in advance, Zoran Stojsavljevic _______ Most of The Time you should be "intel inside" to be capable to think "out of the box". Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928

1 0

[PATCH 0/6] seabios: update to release 1.9.0
by Gerd Hoffmann 18 Dec '15

18 Dec '15

Hi, seabios 1.9.0 was released in November, missing hard freeze by a few days. Now 2.5 is out of the door and the master branch is open, time to care about the update now, so here we go. The patch series carries the seabios update itself, a few build and config adjustments and acpi cleanups. The update is also available here: git://git.kraxel.org/qemu work/seabios Please test & review, Gerd PS: Pull request will most likely have to wait until january, when I'm back online after xmas and newyear vacation. Gerd Hoffmann (6): seabios: update submodule to release 1.9.0 seabios: update 128k bios config seabios: use new EXTRAVERSION to tag qemu builds seabios: stop updating aml files seabios: update binaries to release 1.9.0 q35: skip q35-acpi-dsdt.aml load if not needed hw/i386/pc_q35.c | 5 ++++- pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes pc-bios/bios.bin | Bin 131072 -> 131072 bytes pc-bios/vgabios-cirrus.bin | Bin 38400 -> 38400 bytes pc-bios/vgabios-qxl.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios-stdvga.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios-virtio.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios-vmware.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios.bin | Bin 38400 -> 38400 bytes roms/Makefile | 7 +++---- roms/config.seabios-128k | 2 ++ roms/seabios | 2 +- 12 files changed, 10 insertions(+), 6 deletions(-) -- 1.8.3.1

3 8

Re: [SeaBIOS] SeaBIOS Digest, Vol 73, Issue 11
by jwang＠whu.edu.cn 18 Dec '15

18 Dec '15

> -----原始邮件----- > 发件人: seabios-request(a)seabios.org > 发送时间: 2015年12月18日星期五 > 收件人: seabios(a)seabios.org > 抄送: > 主题: SeaBIOS Digest, Vol 73, Issue 11 > > Send SeaBIOS mailing list submissions to > seabios(a)seabios.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.seabios.org/mailman/listinfo/seabios > or, via email, send a message with subject or body 'help' to > seabios-request(a)seabios.org > > You can reach the person managing the list at > seabios-owner(a)seabios.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SeaBIOS digest..." > > > Today's Topics: > > 1. Re: [Qemu-devel] [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load > if not needed (Marcel Apfelbaum) > 2. Re: [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load if not > needed (Eduardo Habkost) > 3. Re: SeaBIOS recognising USB 3.0 on boot works - partly > (Kevin O'Connor) > 4. Re: SeaBIOS Digest, Vol 72, Issue 33 (Kevin O'Connor) > 5. Re: Qemu-kvm VM halt at allocate VGA stack when continuously > reset VM (Kevin O'Connor) > 6. Re: Qemu-kvm VM halt at allocate VGA stack when continuously > reset VM (Xulei (Stone)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 17 Dec 2015 18:49:05 +0200 > From: Marcel Apfelbaum <marcel.apfelbaum(a)gmail.com> > To: Gerd Hoffmann <kraxel(a)redhat.com>, qemu-devel(a)nongnu.org > Cc: Eduardo Habkost <ehabkost(a)redhat.com>, "Michael S. Tsirkin" > <mst(a)redhat.com>, seabios(a)seabios.org, Paolo Bonzini > <pbonzini(a)redhat.com>, Richard Henderson <rth(a)twiddle.net> > Subject: Re: [SeaBIOS] [Qemu-devel] [PATCH 6/6] q35: skip > q35-acpi-dsdt.aml load if not needed > Message-ID: <5672E781.1010802(a)gmail.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > M > On 12/17/2015 12:40 PM, Gerd Hoffmann wrote: > > Only old machine types which don't use the acpi builder (qemu 1.7 + older) > > have to load that file for proper acpi support. > > > > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> > > --- > > hw/i386/pc_q35.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c > > index 133bc68..727269e 100644 > > --- a/hw/i386/pc_q35.c > > +++ b/hw/i386/pc_q35.c > > @@ -129,7 +129,10 @@ static void pc_q35_init(MachineState *machine) > > } > > > > pc_cpus_init(pcms); > > - pc_acpi_init("q35-acpi-dsdt.aml"); > > + if (!has_acpi_build) { > > + /* only machine types 1.7 & older need this */ > > Actually 1.6 and older, right? (I might be wrong) > > > + pc_acpi_init("q35-acpi-dsdt.aml"); > > + } > > > > kvmclock_create(); > > > > > > It looks OK to me. > > Reviewed-by: Marcel Apfelbaum <marcel(a)redhat.com> > > Thanks, > Marcel > > > > ------------------------------ > > Message: 2 > Date: Thu, 17 Dec 2015 15:22:46 -0200 > From: Eduardo Habkost <ehabkost(a)redhat.com> > To: Gerd Hoffmann <kraxel(a)redhat.com> > Cc: qemu-devel(a)nongnu.org, seabios(a)seabios.org, Paolo Bonzini > <pbonzini(a)redhat.com>, Richard Henderson <rth(a)twiddle.net>, "Michael > S. Tsirkin" <mst(a)redhat.com>, Igor Mammedov <imammedo(a)redhat.com> > Subject: Re: [SeaBIOS] [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load if > not needed > Message-ID: <20151217172246.GQ3774(a)thinpad.lan.raisama.net> > Content-Type: text/plain; charset=us-ascii > > On Thu, Dec 17, 2015 at 11:40:49AM +0100, Gerd Hoffmann wrote: > > Only old machine types which don't use the acpi builder (qemu 1.7 + older) > > have to load that file for proper acpi support. > > > > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> > > --- > > hw/i386/pc_q35.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c > > index 133bc68..727269e 100644 > > --- a/hw/i386/pc_q35.c > > +++ b/hw/i386/pc_q35.c > > @@ -129,7 +129,10 @@ static void pc_q35_init(MachineState *machine) > > } > > > > pc_cpus_init(pcms); > > - pc_acpi_init("q35-acpi-dsdt.aml"); > > + if (!has_acpi_build) { > > + /* only machine types 1.7 & older need this */ > > + pc_acpi_init("q35-acpi-dsdt.aml"); > > + } > > This conflicts with: > > Subject: [Qemu-devel] [PATCH v3 0/6] pc: Initialization and compat function cleanup > Date: Tue, 1 Dec 2015 20:58:02 -0200 > Message-Id: <1449010688-19205-1-git-send-email-ehabkost(a)redhat.com> > > But rebasing it is very simple (just replace has_acpi_build with > pcmc->has_acpi_build). > > But I would prefer to finally apply the series that deletes > pc-q35-2.3 and older (submitted in August), so we just can delete > this code. > > -- > Eduardo > > > > ------------------------------ > > Message: 3 > Date: Thu, 17 Dec 2015 17:17:17 -0500 > From: Kevin O'Connor <kevin(a)koconnor.net> > To: edward wandasiewicz <0.w3ntd(a)gmail.com> > Cc: seabios(a)seabios.org, John Lewis <jlewis(a)johnlewis.ie> > Subject: Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - > partly > Message-ID: <20151217221717.GA8967(a)morn.lan> > Content-Type: text/plain; charset=us-ascii > > On Mon, Dec 14, 2015 at 07:02:14PM -0500, Kevin O'Connor wrote: > > The double detection looks like the controller doing something weird. > > I need to look closer at the spec, but I don't think I'll be able to > > do that until later in the week. > > After reviewing the spec I have a guess to what is occurring. Can you > pull the "testing" branch again and retry? > > -Kevin > > > > ------------------------------ > > Message: 4 > Date: Thu, 17 Dec 2015 17:22:56 -0500 > From: Kevin O'Connor <kevin(a)koconnor.net> > To: Wim Vervoorn <wvervoorn(a)eltan.com> > Cc: "seabios(a)seabios.org" <seabios(a)seabios.org>, Stefan Berger > <stefanb(a)us.ibm.com> > Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33 > Message-ID: <20151217222256.GA9447(a)morn.lan> > Content-Type: text/plain; charset=us-ascii > > On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote: > > Hello, > > > > I noticed that a lot of work is going on for the TPM support in SeaBIOS. > > > > All of this work is TPM 1.2 based. I was wondering if there are any > > plans to support TPM 2.0 in the future. > > I'm not aware of any plans. > > -Kevin > > > > ------------------------------ > > Message: 5 > Date: Thu, 17 Dec 2015 17:28:52 -0500 > From: Kevin O'Connor <kevin(a)koconnor.net> > To: "Xulei (Stone)" <stone.xulei(a)huawei.com> > Cc: "seabios(a)seabios.org" <seabios(a)seabios.org> > Subject: Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when > continuously reset VM > Message-ID: <20151217222851.GB9447(a)morn.lan> > Content-Type: text/plain; charset=us-ascii > > On Thu, Dec 17, 2015 at 05:28:23AM +0000, Xulei (Stone) wrote: > > 1. This problem seems have relations with PIC irq0 and host CPU feature: > > On one of my host, this problem never happens while on another, it's > > very easy to happen (both of hosts have the same kmod,qemu,libvirt and > > SeaBIOS, SeaVGABIOS, except for the CPU feature). > > > > 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something > > wrong printing handle_smp log. > > > > 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, > > and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. > > > > For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly > > when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). > > At first glance, this sounds like there is a level based interrupt > enabled somewhere and after a reset the apic isn't disabled. It > doesn't seem like a seabios issue - as seabios doesn't really use the > apic. I'd raise it on the qemu list. > > -Kevin > > > > ------------------------------ > > Message: 6 > Date: Fri, 18 Dec 2015 00:02:04 +0000 > From: "Xulei (Stone)" <stone.xulei(a)huawei.com> > To: Mohammed Gamal <mohammed.gamal(a)profitbricks.com>, "Kevin O'Connor" > <kevin(a)koconnor.net> > Cc: "seabios(a)seabios.org" <seabios(a)seabios.org> > Subject: Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when > continuously reset VM > Message-ID: > <8E78D212B8C25246BE4CE7EA0E645FE52E0888(a)SZXEMI504-MBS.china.huawei.com> > > Content-Type: text/plain; charset="utf-8" > > Thanks for Gamal's and Kevin's reply. > Here i'd like to provide more information: > - My VM is running under KVM (KMOD 3.6); > - qmp returns: > virsh # qemu-monitor-command hrg_sles11_sp3_64_2U_ide --pretty '{"execute":"query-kvm"}' > { > "return": { > "enabled": true, > "present": true > }, > "id": "libvirt-18099" > } > - kmod ftrace returns: > > <...>-113789 [014] 858323.684996: kvm_emulate_insn: f0000:9:ff ff (real) > <...>-113789 [014] 858323.684996: kvm_inj_exception: #UD (0x0) > <...>-113789 [014] 858323.684996: kvm_entry: vcpu 0 > <...>-113789 [014] 858323.684997: kvm_exit: reason EXCEPTION_NMI rip 0x9 info 0 80000306 > > <...>-113789 [014] 858323.684997: kvm_emulate_insn: f0000:9:ff ff (real) > <...>-113789 [014] 858323.684997: kvm_inj_exception: #UD (0x0) > <...>-113789 [014] 858323.684998: kvm_entry: vcpu 0 > <...>-113789 [014] 858323.684998: kvm_exit: reason EXCEPTION_NMI rip 0x9 info 0 80000306 > > So, it seems at some points, guest executes an invalid opcode triggering kmod injects exception UD > and seabios handle this exception through handle_hwpic1. > > Any idea? > >Hi Xulei, > > > >i have a few questions about the problem you're experiencing, since I do see something similar: > > > >- Is your VM running under KVM? > >- If yes, does the KVM process show any register dumps or failure messages? > >- What's the output of: > >$ virsh qemu-monitor-command devstack --pretty '{"execute":"query-kvm"}' > >when seabios fails to load? > > > >Regards, > >Mohammed > > > > > > > >On Thu, Dec 17, 2015 at 6:28 AM, Xulei (Stone) <stone.xulei(a)huawei.com> wrote: > > > > > > > > >On Wed, Dec 02, 2015 at 07:09:36AM +0000, Xulei (Stone) wrote: > > >> I move HaveRunPost = 1 to handle_post() (after make_bios_writable()), and > > >> I have tested for 1 day with continuously resetting, it seems works well! > > >> Does following patch have some side effects? > > > > > >Thanks. I'll be traveling for the next two weeks. I'll take a look > > >when I return. > > > > > > > Hi, Kevin: > > Welcome journey back! I keep on this problem for about 1 month. Here, > > I provide some detail information and wish you could pay a little time > > thinking about this. > > > > My test script is very easy: > > > > #!/bin/bash > > vmname=$1 > > while [ 1 ] > > do > > virsh reset $vmname & > > virsh reset $vmname & > > sleep 5 > > done > > > > > > 1. This problem seems have relations with PIC irq0 and host CPU feature: > > On one of my host, this problem never happens while on another, it's > > very easy to happen (both of hosts have the same kmod,qemu,libvirt and > > SeaBIOS, SeaVGABIOS, except for the CPU feature). > > > > 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something > > wrong printing handle_smp log. > > > > 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, > > and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. > > > > For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly > > when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). > > > > ==========bad SeaBIOS log========= > > [2015-12-17 12:37:30] In 32bit resume > > [2015-12-17 12:37:30] =====Attempting a hard reboot==== > > [2015-12-17 12:37:30] SeaBIOS (version rel-1.8.1-0-g4adadbd-20151217_104405-linux-emBwNn) > > [2015-12-17 12:37:30] No Xen hypervisor found. > > [2015-12-17 12:37:30] Running on QEMU (i440fx) > > [2015-12-17 12:37:30] Running on KVM > > [2015-12-17 12:37:30] RamSize: 0x80000000 [cmos] > > [2015-12-17 12:37:30] Relocating init from 0x000db230 to 0x7ffad360 (size 76768) > > [2015-12-17 12:37:30] Found QEMU fw_cfg > > [2015-12-17 12:37:30] RamBlock: addr 0x0000000000000000 len 0x0000000080000000 [e820] > > [2015-12-17 12:37:30] Moving pm_base to 0x600 > > [2015-12-17 12:37:30] boot order: > > [2015-12-17 12:37:30] 1: /pci@i0cf8/ide@1,1/drive@0/disk@0 > > [2015-12-17 12:37:30] 2: HALT > > [2015-12-17 12:37:30] maininit > > [2015-12-17 12:37:30] platform_hardware_setup > > [2015-12-17 12:37:30] init pic > > [2015-12-17 12:37:30] pic_setup > > [2015-12-17 12:37:30] pic_reset > > [2015-12-17 12:37:30] enable_hwirq > > [2015-12-17 12:37:30] CPU Mhz=3304 > > [2015-12-17 12:37:30] enable_hwirq > > [2015-12-17 12:37:30] enable_hwirq > > [2015-12-17 12:37:30] === PCI bus & bridge init === > > [2015-12-17 12:37:30] PCI: pci_bios_init_bus_rec bus = 0x0 > > [2015-12-17 12:37:30] === PCI device probing === > > [2015-12-17 12:37:30] Found 6 PCI devices (max PCI bus is 00) > > [2015-12-17 12:37:30] === PCI new allocation pass #1 === > > [2015-12-17 12:37:30] PCI: check devices > > [2015-12-17 12:37:30] === PCI new allocation pass #2 === > > [2015-12-17 12:37:30] PCI: IO: c000 - c02f > > [2015-12-17 12:37:30] PCI: 32: 0000000080000000 - 00000000fec00000 > > [2015-12-17 12:37:30] PCI: map device bdf=00:01.2 bar 4, addr 0000c000, size 00000020 [io] > > [2015-12-17 12:37:30] PCI: map device bdf=00:01.1 bar 4, addr 0000c020, size 00000010 [io] > > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 6, addr febe0000, size 00010000 [mem] > > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 1, addr febf0000, size 00001000 [mem] > > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 0, addr fc000000, size 02000000 [prefmem] > > [2015-12-17 12:37:30] PCI: init bdf=00:00.0 id=8086:1237 > > [2015-12-17 12:37:30] PCI: init bdf=00:01.0 id=8086:7000 > > [2015-12-17 12:37:30] PIIX3/PIIX4 init: elcr=00 0c > > [2015-12-17 12:37:30] PCI: init bdf=00:01.1 id=8086:7010 > > [2015-12-17 12:37:30] PCI: init bdf=00:01.2 id=8086:7020 > > [2015-12-17 12:37:30] PCI: init bdf=00:01.3 id=8086:7113 > > [2015-12-17 12:37:30] Using pmtimer, ioport 0x608 > > [2015-12-17 12:37:30] PCI: init bdf=00:02.0 id=1013:00b8 > > [2015-12-17 12:37:30] PCI: Using 00:02.0 for primary VGA > > [2015-12-17 12:37:30] handle_hshamanpnd:dl leae_p_sismcmp_p:i: d a=ap3 <<======= here, seems abnormal! > > [2015-12-17 12:37:30] i?f[cf_^ifd_=f3 > > [2015-12-17 12:37:30] ?f[f^f_f]f??^X?<90>Found 4 cpu(s) max supported 4 cpu(s) > > [2015-12-17 12:37:30] Copying PIR from 0x7ffbea18 to 0x000f5700 > > [2015-12-17 12:37:30] Copying MPTABLE from 0x00006e30/7ffa42c0 to 0x000f55e0 > > [2015-12-17 12:37:30] Copying SMBIOS entry point from 0x00006e11 to 0x000f55c0 > > [2015-12-17 12:37:31] Scan for VGA option rom > > [2015-12-17 12:37:31] Running option rom at c000:0003 > > [2015-12-17 12:37:31] Start SeaVGABIOS (version rel-1.8.1-0-g4adadbd-20150316_085902-nilsson.home.kraxel.org) > > [2015-12-17 12:37:31] enter vga_post: > > [2015-12-17 12:37:31] a=00000010 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000 > > [2015-12-17 12:37:31] si=00000000 di=000057e0 bp=00000000 sp=00006dbe cs=f000 ip=d1fb f=0000 > > [2015-12-17 12:37:31] cirrus init > > [2015-12-17 12:37:31] cirrus init 2 > > [2015-12-17 12:37:31] Attempting to allocate VGA stack via pmm call to f000:d2a0 <<====== here stuck, loop handle PIC irq0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > ... always hanle_hwpic1 irq=0, never ends anymore... > > > > >-Kevin > > _______________________________________________ > > SeaBIOS mailing list > > SeaBIOS(a)seabios.org > > http://www.seabios.org/mailman/listinfo/seabios > > > > > > > > > >-- > > > >Mohammed Gamal > >Software Engineer > > > >ProfitBricks GmbH > >Greifswalder Stra?e 207 > >D - 10405 Berlin > > > >Tel: +49 30 577 008 20 > >Email: mohammed.gamal(a)profitbricks.com <mailto:axel.herr@profitbricks.com> > > > >Web: http://www.profitbricks.de > > > >Sitz der Gesellschaft: Berlin. > >Registergericht: Amtsgericht Charlottenburg, HRB 125506B. > >Gesch?ftsf?hrer: Andreas Gauger, Achim Weiss. > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios > > ------------------------------ > > End of SeaBIOS Digest, Vol 73, Issue 11 > *************************************** -- Best Wishes! *********************************************************************************************** Juan Wang Computer School, Wuhan University Key Laboratory of Aerospace Information Security and Trusted Computing, Ministry of Education Mobile Phone : 18986213038 E-Mail : jwang(a)whu.edu.cn ***********************************************************************************************

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS