Bug 1458
| Summary: | Kernel does not Uncompress | ||
|---|---|---|---|
| Product: | Platform Specific/Hardware | Reporter: | Stefan Fleiter (stefan.fleiter) |
| Component: | Other | Assignee: | Zwane Mwaikambo (zwane) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | blocking | CC: | bunk, mikedoug, zwane |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.0 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
.config for kernel that does not uncompress
.config working with 2.5.67-bk5, but not with 2.5.67-bk6 ultra minimal config disable store_edid Skip EDID on VBE1.2 Skip EDID on VBE1.2 No EDID/DDC on VBE12 |
||
|
Description
Stefan Fleiter
2003-10-30 09:12:55 UTC
Created attachment 1291 [details]
.config for kernel that does not uncompress
.config for kernel that does not uncompress
Try the early printk stuff to see if you get anything. Be sure to turn it on ;-) ftp://ftp.kernel.org/pub/linux/kernel/people/mbligh/patches/2.6.0-test8/2.6.0-test8-mjb1/100-early_printk Did patch, configure, recompile and set boot-param, but no change. Any other idea? Invested a lot of work: Kernel 2.5.67-bk5 still works. Kernel 2.5.67-bk6 shows the symptom described above. patch-2.5.67-bk5-bk6 is quite big, but also has a lot of architecture specific stuff. Maybe someone familiar with kernel-hacking could have a look, I would try suggested patches. Created attachment 1351 [details]
.config working with 2.5.67-bk5, but not with 2.5.67-bk6
The above is a more minimal .config.
Created attachment 1509 [details]
ultra minimal config
So you don't ask for additional info but close this bug report because of insufficient data? I spend many hours tracking the bug down to the patch 2.5.67-bk5-bk6.bz2 and you tell me I gave not enough data? What do you need to know? What patch/version should I test? I did require additional info, that's why i posted the 'ultra minimal' config, could you try the latest kernel with that configuration? It's unlikely to boot all the way but getting to mounting root will suffice. You did *not* tell me to test the minimal config. How should I know it wasn't for your testing. Will do it as I've time. My apologies then, it was my incorrect assumption. Thanks for testing. No problems. I'm glad there is somebody interested in my kernel problems! [Kernel test11] Your ultra minimal config works, it can't boot because my root disk is on a SCSI disk. I'll try to find the config option causing the lockup/hang/crash/whatever. I'm compiling your config with SCSI added at the moment. I was right, adding SCSI, i.e. CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 CONFIG_AIC7XXX_DEBUG_ENABLE=y CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y makes the kernel hang at boot time without any output, earlyprintk does not work in this situation. Could this be related to http://www.ussg.iu.edu/hypermail/linux/kernel/0310.1/1523.html ? It is a UP-System and preempt is not set. So which SCSI-specififc part of patch-2.5.67-bk5-bk6 could make this happen? Thanks for narrowing it down so quickly! i have a Dell 410 with a similar controller, does aic7xxx_old work for you? Can you just to play it safe, disable CONFIG_PREEMPT? Another thing to check for is your final kernel image size because the SCSI code doesn't get initialised until much later after boot so you would at least see console output. `size vmlinux` and ls -l arch/i386/boot/bzImage. My mistake, ignore the comment about CONFIG_PREEMPT. Also i don't think the problem in the URL and yours are related. Ok it is *not SCSI-related. Was a bug in mybuild scripts which did not detec a build-error and copied a broken bzImage. The config option leading to the kernel not booting is CONFIG_VIDEO_SELECT=y. I checked sveral .config-files which did not produce a working kernel for me, all worked after setting CONFIG_VIDEO_SELECT=n. So again ( :-) ): Which part of patch-2.5.67-bk5-bk6 could cause this? Thanks for your attention. What does your kernel command line look like? vga=ask? vga boot-params =============== none: kernel does not boot vga=extended: kernel does not boot vga=ask: I get the menu, after entering mode number kernel halts The following part of the diff seems suspicious to me: diff -urN linux-2.5.67-bk5/arch/i386/boot/video.S linux-2.5.67-bk6/arch/i386/boot/video.S --- linux-2.5.67-bk5/arch/i386/boot/video.S?????2003-04-07 10:30:58.000000000 -0700 +++ linux-2.5.67-bk6/arch/i386/boot/video.S?????2003-04-15 04:36:14.000000000 -0700 Created attachment 1698 [details]
disable store_edid
Could you test the following patch with CONFIG_VIDEO_SELECT=y
For future reference, the preceding patch was to disable the following changeset; ChangeSet 1.1035 2003/04/14 12:14:31 torvalds@home.transmeta.com Store EDID only when CONFIG_VIDEO_SELECT is set and edid function actually exists. But the real changeset to watch out for would be; ChangeSet 1.1006 2003/04/10 11:20:26 jsimmons@kozmo.(none) [FBDEV] EDID support from OpenFirmware on PPC platoforms and from the BIOS on intel platforms. What happens with vga=normal? > Could you test the following patch with CONFIG_VIDEO_SELECT=y Building at the moment... > What happens with vga=normal? Without patch? Doesn't boot either. > Could you test the following patch with CONFIG_VIDEO_SELECT=y
The patch fixes the problem for me.
Thanks a lot!
Hello Stefan, sorry for the long delay in following up to you. Do you experience the same problem (without the patch) in current 2.6 kernels? Yes, it still happens with kernel 2.6.3-rc2. James could you please have a look at this? So half a year has passed with no action on this. :-( I have a new System now and no access to the old one any more. Sorry. *** Bug 3291 has been marked as a duplicate of this bug. *** This bug certainly hasn't been fixed, it requires specific video hardware but is still out there. Unless someone points me towards a changelog, we should at least leave it open. I verify the bug, being still open. graphics card: Chips & Technologies 65548 VESA VBE 1.2 Configuration CONFIG_VIDEO_SELECT=Y CONFIG_FIRMWARE_EDID=Y kernel <= 2.6.17.14 : works kernel >2.6.18 : crashes hanging right before uncompressing kernel. The first patch suggested here http://bugme.osdl.org/attachment.cgi?id=1698&action=view works fine. Actually I have not tried this, since CONFIG_FIRMWARE_EDID=N also disables the store_edid [at least during booting the kernel. I do not know about other side effects]. But not at the same time disabling video select (which I consider still useful). With this altered configuration even kernel 2.6.19.2 boots fine. :) diff linux-2.6.17.14/arch/i386/boot/video.S linux-2.6.18.6/arch/i386/boot/video.S 1932c1932 < #ifdef CONFIG_FB_FIRMWARE_EDID --- > #ifdef CONFIG_FIRMWARE_EDID 1949a1950,1965 > pushw %es # save ES > xorw %di, %di # Report Capability > pushw %di > popw %es # ES:DI must be 0:0 > movw $0x4f15, %ax > xorw %bx, %bx > xorw %cx, %cx > int $0x10 > popw %es # restore ES > > cmpb $0x00, %ah # call successful > jne no_edid > > cmpb $0x4f, %al # function supported > jne no_edid > 1956a1973 > no_edid: This diff is from inside the store_edid subroutine. Basically it's the check to see if 0x4f15 is available at all. It's introduced by the chancesets Zwane Mwaikambo mentioned. It's interesting, since this check crashes my machine, but the actual call 0x4f15 with bx=$0x01 does not crash my machine. The latter one is performed by 2.6.17.x ct4554x BIOS Manual http://www.asiliant.com/pdf/oc54x.pdf states offering only functions 0x4f00 - 0x4f10. I assume they did not implement the check for 0x4f15. http://www.vesa.org/public/VBE/vbe3.pdf Appendix 3, page 82 states "Added Supplemental Functions definition and defined Supplemental Functions 10-16h". Therefore the actual check for 0x4f15 is NOT required by VBE 1.2. Suggested fixes: Option 1: Add a note to the description text of "CONFIG_FIRMWARE_EDID" saying not to be used in <=VBE 1.2 Option 2: If CONFIG_FIRMWARE_EDID provides in other source codes that I have not looked into any useful functionality even with VBE 1.2, than maybe dynamically check VBE version before trying to call 0x4f15. Some other related information: Crashes my machine right after check for 0x4f15 http://john.fremlin.de/programs/linux/read-edid/ X.Org X11R7.1 (Debian Testing 1:7.1.0-10) chips server with DDC/EDID : seems to work vesa server with DDC/EDID : seems also to work (I expected this to crash) Created attachment 10388 [details]
Skip EDID on VBE1.2
Test with CONFIG_FIRMWARE_EDID and CONFIG_VIDEO_SELECT
Created attachment 10411 [details]
Skip EDID on VBE1.2
Use %ds
Tested by Tobias Hain, i'll get this pushed upstream. Created attachment 10412 [details]
No EDID/DDC on VBE12
Updated for i386 & x86_64
Thanks to Zwane a fix has been integrated in vanilla kernel 2.6.21:
-- 8< --
[PATCH] x86: Don't probe for DDC on VBE1.2
VBE1.2 doesn't support function 15h (DDC) resulting in a 'hang' whilst
uncompressing kernel with some video cards. Make sure we check VBE version
before fiddling around with DDC.
Tested on;
i386, Chips & Technologies 65548 VESA VBE 1.2
CONFIG_VIDEO_SELECT=Y
CONFIG_FIRMWARE_EDID=Y
Untested on x86_64.
Signed-off-by: Zwane Mwaikambo <zwane@infradead.org>
Signed-off-by: Andi Kleen <ak@suse.de>
|