linux-kernel - Re: Geode LX800 hanging at boot in vesa_store_edid() w/ CONFIG_FIRMWARE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 4 Mar 2008 08:39:57 -0700
From:	Jordan Crouse <jordan.crouse@....com>
To:	Andrew Paprocki <andrew@...iboo.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Geode LX800 hanging at boot in vesa_store_edid() w/
	CONFIG_FIRMWARE_EDID=y

On 04/03/08 02:11 -0500, Andrew Paprocki wrote:
> I have a LX800 board which hangs at boot time *only* if no monitor is
> plugged into the VGA port. It hangs for about 20 minutes and then
> continues booting.  If a monitor is plugged into the system while it
> is hung, it recovers after a few minutes and continues booting.  I
> added puts() debugging in the kernel main() and it is hanging in
> vesa_store_edid() in the first asm() call:
> 
>         /* Note: The VBE DDC spec is different from the main VESA spec;
>            we genuinely have to assume all registers are destroyed here. */
> 
>         asm("pushw %%es; movw %2,%%es; "INT10"; popw %%es"
>             : "+a" (ax), "+b" (bx)
>             :  "c" (cx), "D" (di)
>             : "esi");
> 
> After waiting for a really long time, this int10 finishes and it
> executes the second asm() call which returns right away.  I never
> tried booting the system without a head, so I never noticed this
> problem before.  Does this point to some kind of BIOS bug?  The system
> boots fine when CONFIG_FIRMWARE_EDID is disabled (I'm not even sure if
> it should have been enabled in the first place), but I want to make
> sure the manufacturer is alerted if there is a BIOS problem.

This is most likely a BIOS bug.  Once we go in to the hated INT10,
we lose all control (and visiblity).  If I can make silly assumptions
based on your description, it looks like there may be some sort of very
long timeout on the bitbanging code in the BIOS that does the DDC.

Can you give me the details of the platform and BIOS vendor?  I'll work
the issue from my end.

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/