SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Xulei (Stone) 18 Dec '15

18 Dec '15

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.

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Kevin O'Connor 17 Dec '15

17 Dec '15

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

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Xulei (Stone) 17 Dec '15

17 Dec '15

>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

1 0

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

13 Dec '15

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. :( > > 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. We can get 1. SSD 2. Philips USB 3. Mushkin USB or 1. SSD 2. Mushkin USB 3. Philips USB I think scenario 5 is special case of the above, former, but no Mushkin 1. SSD 2. Philips USB Hope this helps. Edward. > > Edward. > > On Sun, Dec 13, 2015 at 7:53 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Sun, Dec 13, 2015 at 10:49:30AM +0000, edward wandasiewicz wrote: >>> With both the Philips USB and Mushkin USB plugged in on boot, I'm >>> still getting 4 different scenarios appearing. >>> >>> 1. Philips Only >>> 2. Mushkin Only >>> 3. Both recognised - listed once and once only >>> 4. Both recognised - Mushkin once, but the Philips listed twice >>> >>> I've attached >>> >>> $cbmem -c >>> >>> for each scenario >> >> Thanks. It looks like the usb code wasn't waiting for USB3 devices to >> be "enabled" before trying to talk to them. Can you pull down the >> "testing" branch again and retry? >> >> Also, the logs are quite large and they are exceeding the mailing list >> limits - going forward can you gzip the logs and attach them to your >> emails. >> >> -Kevin

1 0

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

13 Dec '15

On Sun, Dec 13, 2015 at 10:49:30AM +0000, edward wandasiewicz wrote: > With both the Philips USB and Mushkin USB plugged in on boot, I'm > still getting 4 different scenarios appearing. > > 1. Philips Only > 2. Mushkin Only > 3. Both recognised - listed once and once only > 4. Both recognised - Mushkin once, but the Philips listed twice > > I've attached > > $cbmem -c > > for each scenario Thanks. It looks like the usb code wasn't waiting for USB3 devices to be "enabled" before trying to talk to them. Can you pull down the "testing" branch again and retry? Also, the logs are quite large and they are exceeding the mailing list limits - going forward can you gzip the logs and attach them to your emails. -Kevin

2 1

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

10 Dec '15

On Fri, Dec 04, 2015 at 09:04:35PM +0000, edward wandasiewicz wrote: > Here's what happens with x1 Philips USB attached and x1 Mushkin > attached, and we cold boot with Kevin's patched SeaBIOS > > FIXED - when Philips drive is detected, it appears only once and once > only in the list of bootable devices - cbmem -c attached > > BROKE - the Mushkin drive hardly ever gets detected - Google ChromeOS > recovery SeaBIOS would always find it > > BROKEN - when Mushkin drive is detected, only the Mushkin is showing > in the list, no Philips in the list of bootable devices - cbmem -c > attached (reboot following a cold boot with Philips only showing) > > Sometimes Mushkin will appear on a cold boot - not very often, with no > Philips showing in the list, with both devices plugged in on boot up. [...] > |7cddd000| xhci_address: enable slot: got slotid 1 > |7cddd000| xhci_cmd_address_device: slotid 1 > |7cddd000| xhci_trb_queue: ring 0x7ce39d00 [nidx 2, len 0] > |7cddd000| xhci_process_events: ring 0x7ce39d00 [trb 0x7ce39d10, evt > 0x7ce39e00, type 33, eidx 2, cc 4] > |7cddd000| xhci_cmd_disable_slot: slotid 1 > |7cddd000| xhci_trb_queue: ring 0x7ce39d00 [nidx 3, len 0] > |7cddd000| xhci_process_events: ring 0x7ce39d00 [trb 0x7ce39d20, evt > 0x7ce39e00, type 33, eidx 3, cc 1] > |7cddd000| xhci_address: disable failed (cc 1/4) It looks like I messed up the error check on the patch. I uploaded a new patch. Can you clone the "testing" branch again and retry? Thanks, -Kevin

1 0

[PATCH] fw/pci: do not automatically allocate IO region for PCIe bridges
by Marcel Apfelbaum 07 Dec '15

07 Dec '15

PCIe downstream ports (Root Ports and switches Downstream Ports) appear to firmware as PCI-PCI bridges and a 4K IO space is allocated for them even if there is no device behind them requesting IO space, all that for hotplug purpose. However, PCIe devices can work without IO, so there is no need to allocate IO space for hotplug. Signed-off-by: Marcel Apfelbaum <marcel(a)redhat.com> --- Notes: - This patch fixes a 15 PCIe Root ports limitation when used with virtio pci-express devices having no IO space requirements: <qemu cmd line> -M q35 `for i in {1..15}; do echo -device ioh3420,chassis=$i,id=b$i -device virtio-net-pci,bus=b$i,disable-legacy=on; done` - There is a patch on QEMU devel list that tackles the problem from another angle by allowing PCIe downstream ports to not forward IO requests. https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04478.html - The mentioned patch is of course not enough and also requires management software intervention. Thanks, Marcel src/fw/pciinit.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 7b8aab7..4b37792 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -736,7 +736,9 @@ static int pci_bios_check_devices(struct pci_bus *busses) if (pci_region_align(&s->r[type]) > align) align = pci_region_align(&s->r[type]); u64 sum = pci_region_sum(&s->r[type]); - if (!sum && hotplug_support) + int res_opt = (type == PCI_REGION_TYPE_IO) && + pci_find_capability(s->bus_dev, PCI_CAP_ID_EXP, 0); + if (!sum && hotplug_support && !res_opt) sum = align; /* reserve min size for hot-plug */ u64 size = ALIGN(sum, align); int is64 = pci_bios_bridge_region_is64(&s->r[type], -- 2.1.0

2 2

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

04 Dec '15

On Fri, Dec 04, 2015 at 07:08:50PM +0000, edward wandasiewicz wrote: > On 4 Dec 2015 7:04 p.m., "Kevin O'Connor" <kevin(a)koconnor.net> wrote: > > > > On Fri, Dec 04, 2015 at 06:36:18PM +0000, edward wandasiewicz wrote: > > > @ John > > > > > > Is the work on SeaVGABIOS for CBFS work under construction for the > > > Broadwell based Pixel 2015? > > > > > > Looking at Kevin's chromeimage.sh - showing relevant parts only > > > > > > CBFSTOOL=cbfstool > > > PAYLOAD=out/bios.bin.elf > > > PAYLOADVGA=out/vgabios.bin > > [...] > > > # > > > # Add SeaVGABIOS to CBFS > > > # > > > $ CBFSTOOL $CBFSFILE add -f $PAYLOADVGA -n vgaroms/seavgabios.rom -t > optionrom > > > > > > Question - if it is work under construction, the above may or may not > > > show any VGA output? i.e. black screen > > > > > > Or give it a whirl, and I may surprise myself? > > > > > > Or stick with > > > > > > ## Extract vgabios from SeaBIOS CBFS area of original image. > > > > > > ORIGCBFSFILE=orig-seabios.cbfs > > > > > > $ dd if=$ORIGIMAGE of=$ORIGCBFSFILE skip=2 bs=2M count=1 2> /dev/null > > > > > > $ CBFSTOOL $ORIGCBFSFILE extract -n pci8086,0406.rom -f pci8086,0406.rom > > > > > > $ CBFSTOOL $CBFSFILE add -f pci8086,0406.rom -n pci8086,0a06.rom -t > optionrom > > > > The logs you sent me seemed to indicate that SeaVGABIOS was running, > > This means use vgaroms/seavgabios.rom > > and leave commented parts in a commented state - no need for > pci8086,0a06.rom parts Yes. -Kevin

2 1

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

04 Dec '15

On Fri, Dec 04, 2015 at 06:36:18PM +0000, edward wandasiewicz wrote: > @ John > > Is the work on SeaVGABIOS for CBFS work under construction for the > Broadwell based Pixel 2015? > > Looking at Kevin's chromeimage.sh - showing relevant parts only > > CBFSTOOL=cbfstool > PAYLOAD=out/bios.bin.elf > PAYLOADVGA=out/vgabios.bin [...] > # > # Add SeaVGABIOS to CBFS > # > $ CBFSTOOL $CBFSFILE add -f $PAYLOADVGA -n vgaroms/seavgabios.rom -t optionrom > > Question - if it is work under construction, the above may or may not > show any VGA output? i.e. black screen > > Or give it a whirl, and I may surprise myself? > > Or stick with > > ## Extract vgabios from SeaBIOS CBFS area of original image. > > ORIGCBFSFILE=orig-seabios.cbfs > > $ dd if=$ORIGIMAGE of=$ORIGCBFSFILE skip=2 bs=2M count=1 2> /dev/null > > $ CBFSTOOL $ORIGCBFSFILE extract -n pci8086,0406.rom -f pci8086,0406.rom > > $ CBFSTOOL $CBFSFILE add -f pci8086,0406.rom -n pci8086,0a06.rom -t optionrom The logs you sent me seemed to indicate that SeaVGABIOS was running, and thus you should use the steps above. -Kevin

2 1

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

04 Dec '15

On Fri, Dec 04, 2015 at 05:50:29PM +0000, edward wandasiewicz wrote: > Looking at the output from Googles ChromeOS shell-ball, I do: > > Write the hardware ID to get future ChromeOS updates > > $ ./gbb_utility --set --hwid="SAMUS XXX-YYY-ZZZ" bios.bin bios.hwid.bin > > # dd out 2 megs of the ROM at 4 megs in > > $ dd bs=1M skip=4 count=2 if=bios.hwid.bin of=rwlegacy.cbfs > > Using the flashrom from John's site as upstream doesn't know anything about > flashmap. > > $ wget https://johnlewis.ie/Chromebook-ROMs/utils/flashrom -O > flashrom.jlewis > > $ sudo ./flashrom.jlewis -w -i RW_LEGACY:rwlegacy.cbfs > > Looking at your script, ORIGIMAGE is my bios.hwid.bin > > Do I run flashrom from the shell-ball > > $ sudo flashrom -w ./newimage.rom -i RW_LEGACY > > Or John Lewis flashrom > > $ sudo flashrom.jlewis.version -w ./newimage.rom -i RW_LEGACY I would guess that either would work. Upstream flashrom is likely not going to work (if it doesn't support flashmap). As long as the flashrom does support flashmap, then it should work. (No guarantees.) -Kevin

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS