* [RFC] VBE DDC bios call stalls boot
@ 2006-04-23 19:08 Yum Rayan
2006-04-23 20:14 ` Ingo Oeser
2006-04-23 20:24 ` Dave Jones
0 siblings, 2 replies; 6+ messages in thread
From: Yum Rayan @ 2006-04-23 19:08 UTC (permalink / raw)
To: linux-kernel
In my setup I have a monitor connected via a DLink KVM (DKVM 2K). The
boot stalls forever during early boot phase until I physically
disconnect the KVM from the video port at my CPU box and reconnect it.
I was able to trace it to the VBE/DDC call in video.S. The bios call
does not seem to return. When I disconnect the video, the bios call
returns with failure and boot picks it back from there. When I
directly connect my monitor bypassing the KVM, this issue does not
happen.
There is a bios call to check if read EDID is supported. My first
thought was that before doing read EDID, video.S should first check to
see if the hardware supports the read EDID feature. Unfortunately that
bios call too ends up in the woods until I physically
disconnect/reconnect my CPU video output that feeds into the KVM. I
see the same issue with user space programs such as read-edid and
xwindows that also attempt to read EDID. They simply stall at the DDC
call until I physically disconnect/reconnect my video.
I don't think boot should stall for any reason. Moreover given that
user space programs are doing these VBE/DDC calls, I don't see any
compelling reason why this code need to exist is such early boot
stage. If it absolutely needs to be called in the kernel, at least if
invoked sometime later, we could time out this call as a workaround.
Kindly suggest the best approach. The following patch works for me:
Thanks.
--- linux-2.6.15.4.a/arch/i386/boot/video.S 2006-02-09 23:22:48.000000000 -0800
+++ linux-2.6.15.4.b/arch/i386/boot/video.S 2006-04-23 11:19:01.000000000 -0700
@@ -1946,13 +1946,6 @@ store_edid:
rep
stosl
- movw $0x4f15, %ax # do VBE/DDC
- movw $0x01, %bx
- movw $0x00, %cx
- movw $0x00, %dx
- movw $0x140, %di
- int $0x10
-
popw %di # restore all registers
popw %dx
popw %cx
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] VBE DDC bios call stalls boot
2006-04-23 19:08 [RFC] VBE DDC bios call stalls boot Yum Rayan
@ 2006-04-23 20:14 ` Ingo Oeser
2006-04-23 23:40 ` Antonino A. Daplas
2006-04-23 20:24 ` Dave Jones
1 sibling, 1 reply; 6+ messages in thread
From: Ingo Oeser @ 2006-04-23 20:14 UTC (permalink / raw)
To: Yum Rayan; +Cc: linux-kernel
On Sunday, 23. April 2006 21:08, Yum Rayan wrote:
> I don't think boot should stall for any reason. Moreover given that
> user space programs are doing these VBE/DDC calls, I don't see any
> compelling reason why this code need to exist is such early boot
> stage. If it absolutely needs to be called in the kernel, at least if
> invoked sometime later, we could time out this call as a workaround.
Don't configure CONFIG_FB_FIRMWARE_EDID, if it doesn't work
on your hardware.
Just disable "Enable firmware EDID" in
"Device Drivers"->"Graphics support"->"Support for frame buffer devices"
of your menuconfig dialog. The help mentions, that this will not always work.
That will make your hardware work flawlessly again.
Regards
Ingo Oeser
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] VBE DDC bios call stalls boot
2006-04-23 20:14 ` Ingo Oeser
@ 2006-04-23 23:40 ` Antonino A. Daplas
0 siblings, 0 replies; 6+ messages in thread
From: Antonino A. Daplas @ 2006-04-23 23:40 UTC (permalink / raw)
To: Ingo Oeser; +Cc: Yum Rayan, linux-kernel
Ingo Oeser wrote:
> On Sunday, 23. April 2006 21:08, Yum Rayan wrote:
>> I don't think boot should stall for any reason. Moreover given that
>> user space programs are doing these VBE/DDC calls, I don't see any
>> compelling reason why this code need to exist is such early boot
>> stage. If it absolutely needs to be called in the kernel, at least if
>> invoked sometime later, we could time out this call as a workaround.
>
> Don't configure CONFIG_FB_FIRMWARE_EDID, if it doesn't work
> on your hardware.
This option is new and not yet available in 2.6.15, so you may have
to use your patch temporarily. If you can, set CONFIG_VIDEO_SELECT = n
in Device Drivers -> Graphics support -> Console Drivers ->
Video mode selection support. However, this is automatically selected by FB,
PCI, and X86_32, so it may not be changeable.
The "vga=" option will not be available if VIDEO_SELECT is not set.
Or just apply this changeset:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=59153f7d7effdb5b3c81eb6d03914a866157b319
to make CONFIG_FB_FIRMWARE_EDID available.
Tony
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] VBE DDC bios call stalls boot
2006-04-23 19:08 [RFC] VBE DDC bios call stalls boot Yum Rayan
2006-04-23 20:14 ` Ingo Oeser
@ 2006-04-23 20:24 ` Dave Jones
2006-04-23 23:47 ` Antonino A. Daplas
1 sibling, 1 reply; 6+ messages in thread
From: Dave Jones @ 2006-04-23 20:24 UTC (permalink / raw)
To: Yum Rayan; +Cc: linux-kernel
On Sun, Apr 23, 2006 at 12:08:27PM -0700, Yum Rayan wrote:
> There is a bios call to check if read EDID is supported. My first
> thought was that before doing read EDID, video.S should first check to
> see if the hardware supports the read EDID feature. Unfortunately that
> bios call too ends up in the woods until I physically
> disconnect/reconnect my CPU video output that feeds into the KVM.
Is this how your patch looked when you tried this ?
Dave
--- linux-2.6.15/arch/i386/boot/video.S~ 2006-01-06 01:26:06.000000000 -0500
+++ linux-2.6.15/arch/i386/boot/video.S 2006-01-06 01:28:40.000000000 -0500
@@ -1951,9 +1951,18 @@ store_edid:
stosl
movw $0x4f15, %ax # do VBE/DDC
- movw $0x01, %bx
+ movw $0x00, %bx # INSTALLATION CHECK / CAPABILITIES
movw $0x00, %cx
- movw $0x00, %dx
+ movw $0x00, %dx
+ movw $0x140, %di
+ int $0x10
+ cmpb $0x01, %ah
+ je no_edid
+
+ movw $0x4f15, %ax # do VBE/DDC
+ movw $0x01, %bx # READ_EDID
+ movw $0x00, %cx
+ movw $0x00, %dx
movw $0x140, %di
int $0x10
--- linux-2.6.15/arch/i386/boot/video.S~ 2006-01-06 02:55:20.000000000 -0500
+++ linux-2.6.15/arch/i386/boot/video.S 2006-01-06 02:55:28.000000000 -0500
@@ -1966,6 +1966,7 @@ store_edid:
movw $0x140, %di
int $0x10
+no_edid:
popw %di # restore all registers
popw %dx
popw %cx
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] VBE DDC bios call stalls boot
2006-04-23 20:24 ` Dave Jones
@ 2006-04-23 23:47 ` Antonino A. Daplas
2006-04-24 7:27 ` Yum Rayan
0 siblings, 1 reply; 6+ messages in thread
From: Antonino A. Daplas @ 2006-04-23 23:47 UTC (permalink / raw)
To: Dave Jones, Yum Rayan, linux-kernel
Dave Jones wrote:
> On Sun, Apr 23, 2006 at 12:08:27PM -0700, Yum Rayan wrote:
>
> > There is a bios call to check if read EDID is supported. My first
> > thought was that before doing read EDID, video.S should first check to
> > see if the hardware supports the read EDID feature. Unfortunately that
> > bios call too ends up in the woods until I physically
> > disconnect/reconnect my CPU video output that feeds into the KVM.
>
> Is this how your patch looked when you tried this ?
I've discovered that checking for availability does not give any added benefit,
but this is the correct approach and I have to agree with this patch.
Tony
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] VBE DDC bios call stalls boot
2006-04-23 23:47 ` Antonino A. Daplas
@ 2006-04-24 7:27 ` Yum Rayan
0 siblings, 0 replies; 6+ messages in thread
From: Yum Rayan @ 2006-04-24 7:27 UTC (permalink / raw)
To: Antonino A. Daplas; +Cc: Dave Jones, linux-kernel
> > Is this how your patch looked when you tried this ?
>
> I've discovered that checking for availability does not give any added benefit,
> but this is the correct approach and I have to agree with this patch.
My patch was similar. I referenced
http://www.vesa.org/public/VBE/VBEDDC11.PDF. Differences were the
finer look up of the ambiguous status code and setting up ES:DI to be
NULL before call to INT 10h, as follows:
--- linux-2.6.15.4.a/arch/i386/boot/video.S 2006-02-09 23:22:48.000000000 -0800
+++ linux-2.6.15.4.b/arch/i386/boot/video.S 2006-04-24 00:07:08.000000000 -0700
@@ -1946,6 +1946,22 @@ store_edid:
rep
stosl
+ pushw %es
+ movw $0x4f15, %ax # report VBE/DDC capabilities
+ xorw %bx, %bx
+ xorw %cx, %cx
+ xorw %di, %di
+ pushw %di
+ popw %es
+ int $0x10
+ popw %es
+
+ cmpb $0x0, %ah # function call failed
+ jne no_edid
+
+ cmpb $0x4f, %al # function not supported
+ jne no_edid
+
movw $0x4f15, %ax # do VBE/DDC
movw $0x01, %bx
movw $0x00, %cx
@@ -1953,6 +1969,7 @@ store_edid:
movw $0x140, %di
int $0x10
+no_edid:
popw %di # restore all registers
popw %dx
popw %cx
> This option is new and not yet available in 2.6.15, so you may have
> to use your patch temporarily.
I was able to download a more recent kernel and configure
CONFIG_FB_FIRMWARE_EDID. Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-04-24 7:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-23 19:08 [RFC] VBE DDC bios call stalls boot Yum Rayan
2006-04-23 20:14 ` Ingo Oeser
2006-04-23 23:40 ` Antonino A. Daplas
2006-04-23 20:24 ` Dave Jones
2006-04-23 23:47 ` Antonino A. Daplas
2006-04-24 7:27 ` Yum Rayan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox