10.02.2024 22:09, Kevin O'Connor :
> On Wed, Feb 07, 2024 at 03:21:15AM +0300, Michael Tokarev wrote:
>> 07.02.2024 02:17, Michael Tokarev пишет:
> [...]
>>> The binary in question is vgabios-stdvga.bin.
> [...]
>> "SMBIOS 2.1 table length 66822 exceeds 65535"
>>
>> Which wont help with 7.2 machine types (it changes defaults for 8.1+).
>>
>> And yes, running current qemu with -M pc-q35-7.2 shows the same issue
>> again.
>>
>> So it might not be a gcc issue really, but just a too large bios and
>> gcc-13 is able to produce more compact code which actually fits.
>
> Ah, that makes sense. In the future, if you enable the seabios logs
> it should help track these things down. (Take the log from the
> working version and compare it to the log from the non-working
> version.) I suspect in the log would be messages from
> seabios/seavgabios hinting to the issue.
Ok, that's a good idea indeed. Somehow I forgot about this.
So, I rebuilt seabios with DEBUG=8. I did NOT rebuilt vgabios
though, since after rebuilding it with debug added, the whole
thing seem to work. However, the "bad" vgabios is just a bit
larger than the "good" one:
-rw-r--r-- 1 mjt mjt 39936 Jan 24 09:35 bios-bad/vgabios-stdvga.bin
-rw-r--r-- 1 mjt mjt 39424 Nov 30 20:20 bios-good/vgabios-stdvga.bin
this is from debian seabios package 1.16.3-2 (good, compiled with
gcc-13) and 1.16.3-2~bpo12+1 (bad, compiled with gcc-12). There's
no difference in there besides the version string and gcc used to
compile it, all the rest is exactly the same.
This is debug level 1 difference (qemu machine pc-q35-7.2) -- bpo12+1
is the bad one:
diff -U1 debugcon-good debugcon-bad
--- debugcon-good 2024-02-10 22:36:01.432450772 +0300
+++ debugcon-bad 2024-02-10 22:36:23.477127564 +0300
@@ -1,3 +1,3 @@
-SeaBIOS (version 1.16.3-debian-1.16.3-2)
-BUILD: gcc: (Debian 13.2.0-7) 13.2.0 binutils: (GNU Binutils for Debian) 2.41
+SeaBIOS (version 1.16.3-debian-1.16.3-2~bpo12+1)
+BUILD: gcc: (Debian 12.2.0-14) 12.2.0 binutils: (GNU Binutils for Debian) 2.40
No Xen hypervisor found.
@@ -14,3 +14,3 @@
qemu/e820: addr 0x0000000100000000 len 0x0000000040000000 [RAM]
-Relocating init from 0x000d4020 to 0x7efeb120 (size 85568)
+Relocating init from 0x000d3b00 to 0x7efeae00 (size 86368)
Moving pm_base to 0x600
@@ -18,3 +18,3 @@
1: /pci@i0cf8/pci8086,2922@3/drive@0/disk@0
-kvmclock: at 0xe8580 (msr 0x4b564d01)
+kvmclock: at 0xe8380 (msr 0x4b564d01)
kvmclock: stable tsc, 3792 MHz
@@ -62,5 +62,5 @@
Found 2 cpu(s) max supported 2 cpu(s)
-Copying PIR from 0x7efffbe0 to 0x000f5560
-Copying MPTABLE from 0x00006cfc/7efe1bf0 to 0x000f5450
-Copying SMBIOS from 0x00006cfc to 0x000f5290
+Copying PIR from 0x7efffbe0 to 0x000f5500
+Copying MPTABLE from 0x00006cfc/7efe18d0 to 0x000f53f0
+Copying SMBIOS from 0x00006cfc to 0x000f5220
table(50434146)=0x7ffe2134 (via rsdt)
@@ -69,7 +69,7 @@
Running option rom at c000:0003
-Start SeaVGABIOS (version 1.16.3-debian-1.16.3-2)
-VGABUILD: gcc: (Debian 13.2.0-7) 13.2.0 binutils: (GNU Binutils for Debian) 2.41
+Start SeaVGABIOS (version 1.16.3-debian-1.16.3-2~bpo12+1)
+VGABUILD: gcc: (Debian 12.2.0-14) 12.2.0 binutils: (GNU Binutils for Debian) 2.40
enter vga_post:
a=00000008 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000
- si=00000000 di=000060c0 bp=00000000 sp=00006d16 cs=f000 ip=d00f f=0000
+ si=00000000 di=00006060 bp=00000000 sp=00006d1a cs=f000 ip=d04a f=0000
VBE DISPI: bdf 00:01.0, bar 0
@@ -81,8 +81,8 @@
Removing mode 19e
-Attempting to allocate 512 bytes lowmem via pmm call to f000:d0c0
+Attempting to allocate 512 bytes lowmem via pmm call to f000:d0e6
pmm call arg1=0
-VGA stack allocated at e8380
+VGA stack allocated at e8180
Turning on vga text mode console
set VGA mode 3
-SeaBIOS (version 1.16.3-debian-1.16.3-2)
+SeaBIOS (version 1.16.3-debian-1.16.3-2~bpo12+1)
EHCI init on dev 00:1d.7 (regs=0xfebf2020)
@@ -111,5 +111,5 @@
Searching bootorder for: HALT
-drive 0x000f5200: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=67108864
+drive 0x000f5190: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=67108864
Running option rom at cb00:0003
-Space available for UMB: cd800-e7800, f4de0-f51e0
+Space available for UMB: cd800-e7800, f4d80-f5170
Returned 16637952 bytes of ZoneHigh
@@ -180,4 +180 @@
VBE mode info request: 118
-VBE mode set: 4144
-set VGA mode 144
-VBE current mode=4144
So it looks like it is stuck at setting VBE mode.
Attached are 2 level-8 debug logs from good and bad runs. Unfortunately I
see about the same picture as above, with lots of details before last 3
lines, and the same 3 last lines difference. Trying to find a working
combination for vgabios debugging..
Does it make any sense so far?
Thanks,
/mjt_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org
So.. the difference is vgabios only, not seabios (vgabios-stdvga in this case). And I can't get it to work with debugging vgabios, it always fails even with DEBUG_LEVEL=2 (and level-1 logging isn't useful). I was able to capture logs just for the non-working version, so there's nothing to compare it against. So I tried a different machine type in qemu, the one which works, which uses SMBIOS 3.0 (q35-8.2). I also tried to compile the same vgabios with different compilers (gcc-13 vs gcc-12), in a hope to have working one with gcc-13 (the same way it works without debug). This one produces extra output at the end. This should make a bit more sense, but I'm not sure, never tried to debug this stuff.. Thanks! /mjt_______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
Am 10.02.24 um 21:17 schrieb Michael Tokarev: > So.. the difference is vgabios only, not seabios (vgabios-stdvga in this > case). > > And I can't get it to work with debugging vgabios, it always fails even > with DEBUG_LEVEL=2 > (and level-1 logging isn't useful). > > I was able to capture logs just for the non-working version, so there's > nothing to > compare it against. So I tried a different machine type in qemu, the > one which > works, which uses SMBIOS 3.0 (q35-8.2). > Hi, Windows apparently doesn't read SMBIOS 3.0 tables: https://gitlab.com/qemu-project/qemu/-/issues/2008#note_1712210029 Not sure if this is relevant for your issue and it only "works" because of that with newer machine models. But it seems worth mentioning. Best Regards, Fiona _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
On Mon, Feb 12, 2024 at 01:06:34PM +0100, Fiona Ebner wrote:
> Am 10.02.24 um 21:17 schrieb Michael Tokarev:
> > So.. the difference is vgabios only, not seabios (vgabios-stdvga in this
> > case).
> >
> > And I can't get it to work with debugging vgabios, it always fails even
> > with DEBUG_LEVEL=2
> > (and level-1 logging isn't useful).
> >
> > I was able to capture logs just for the non-working version, so there's
> > nothing to
> > compare it against. So I tried a different machine type in qemu, the
> > one which
> > works, which uses SMBIOS 3.0 (q35-8.2).
> >
>
>
> Hi,
>
> Windows apparently doesn't read SMBIOS 3.0 tables:
> https://gitlab.com/qemu-project/qemu/-/issues/2008#note_1712210029
>
> Not sure if this is relevant for your issue and it only "works" because
> of that with newer machine models. But it seems worth mentioning.
Note that there is an option to explicitly set the smbios version:
qemu -machine q35,smbios-entry-point-type={32,64}
That will override the machine type default.
take care,
Gerd
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org
On Sat, Feb 10, 2024 at 11:17:54PM +0300, Michael Tokarev wrote:
> So.. the difference is vgabios only, not seabios (vgabios-stdvga in this case).
>
> And I can't get it to work with debugging vgabios, it always fails even with DEBUG_LEVEL=2
> (and level-1 logging isn't useful).
>
> I was able to capture logs just for the non-working version, so there's nothing to
> compare it against. So I tried a different machine type in qemu, the one which
> works, which uses SMBIOS 3.0 (q35-8.2).
Thanks for testing. So, if I understand the issue correctly:
1. If smbios v3 is used then the problem does not occur.
2. If gcc v13 is used to compile vgabios then the problem does not occur.
3. If smbios v2 is used and gcc v12 is used then win10 can not boot.
Is that correct?
A strange issue. Issues like this tend to be very difficult to track
down.
As a random guess, one possibility is that it could be related to
vgabios stack size usage. You could try always enabling the "extra
vga stack" with a change like:
--- a/vgasrc/vgabios.c
+++ b/vgasrc/vgabios.c
@@ -285,8 +285,7 @@ vga_set_mode(int mode, int flags)
// Disable extra stack if it appears a modern OS is in use.
// This works around bugs in some versions of Windows (Vista
// and possibly later) when the stack is in the e-segment.
- MASK_BDA_EXT(flags, BF_EXTRA_STACK
- , (flags & MF_LEGACY) ? BF_EXTRA_STACK : 0);
+ MASK_BDA_EXT(flags, BF_EXTRA_STACK, BF_EXTRA_STACK);
if (memmodel == MM_TEXT) {
SET_BDA(video_cols, width);
SET_BDA(video_rows, height-1);
Separately, if you can provide the failing and succeeding builds, I
can try to take a look at it locally. To do this, make sure you're on
commit 82faf1d5, run make, run "tar cfz fullbuild.tgz out/", and
provide the resulting tgz file.
-Kevin
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.orgOn Tue, 20 Feb 2024 14:41:50 -0500
Kevin O'Connor <kevin@koconnor.net> wrote:
> On Sat, Feb 10, 2024 at 11:17:54PM +0300, Michael Tokarev wrote:
> > So.. the difference is vgabios only, not seabios (vgabios-stdvga in this case).
> >
> > And I can't get it to work with debugging vgabios, it always fails even with DEBUG_LEVEL=2
> > (and level-1 logging isn't useful).
> >
> > I was able to capture logs just for the non-working version, so there's nothing to
> > compare it against. So I tried a different machine type in qemu, the one which
> > works, which uses SMBIOS 3.0 (q35-8.2).
>
> Thanks for testing. So, if I understand the issue correctly:
> 1. If smbios v3 is used then the problem does not occur.
one thing to note is that Windows isn't able to find SMBIOS v3 tables
due to bug in anchor lookup within winload.exe. So essentially v3 tables
mean that Windows doesn't access SMBIOS at all, while with v2 it's actually
using SMBIOS tables.
> 2. If gcc v13 is used to compile vgabios then the problem does not occur.
> 3. If smbios v2 is used and gcc v12 is used then win10 can not boot.
> Is that correct?
>
> A strange issue. Issues like this tend to be very difficult to track
> down.
>
> As a random guess, one possibility is that it could be related to
> vgabios stack size usage. You could try always enabling the "extra
> vga stack" with a change like:
>
> --- a/vgasrc/vgabios.c
> +++ b/vgasrc/vgabios.c
> @@ -285,8 +285,7 @@ vga_set_mode(int mode, int flags)
> // Disable extra stack if it appears a modern OS is in use.
> // This works around bugs in some versions of Windows (Vista
> // and possibly later) when the stack is in the e-segment.
> - MASK_BDA_EXT(flags, BF_EXTRA_STACK
> - , (flags & MF_LEGACY) ? BF_EXTRA_STACK : 0);
> + MASK_BDA_EXT(flags, BF_EXTRA_STACK, BF_EXTRA_STACK);
> if (memmodel == MM_TEXT) {
> SET_BDA(video_cols, width);
> SET_BDA(video_rows, height-1);
>
> Separately, if you can provide the failing and succeeding builds, I
> can try to take a look at it locally. To do this, make sure you're on
> commit 82faf1d5, run make, run "tar cfz fullbuild.tgz out/", and
> provide the resulting tgz file.
>
> -Kevin
> _______________________________________________
> SeaBIOS mailing list -- seabios@seabios.org
> To unsubscribe send an email to seabios-leave@seabios.org
>
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org
© 2016 - 2024 Red Hat, Inc.