From: devzero@web.de
To: Parag Warudkar <parag.warudkar@gmail.com>
Cc: Matt.Domsch@dell.com, hpa@zytor.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [RFC] be more verbose when probing EDD
Date: Sun, 16 Dec 2007 20:11:33 +0100 [thread overview]
Message-ID: <49448787@web.de> (raw)
> It does not look like this issue is common - googling for "Linux EDD Boot
> hang" does not bring up relevant and recent results - in fact this post of
> yours comes on top.
i don`t wonder here - how should one know that it`s an edd problem if all he sees is a blank screen with a blinking cursor in the upper left ?
so i assume, "Linux EDD Boot hang" isn`t the best term for searching here.
i think, there is no universal search phrase - i found some references with different words (linux install, blank screen, blinking cursor....)
some of them
http://forums.suselinuxsupport.de/lofiversion/index.php/t61581.html
http://suseforums.net/index.php?showtopic=1302
http://forums.suselinuxsupport.de/lofiversion/index.php/t3157.html
http://www.linuxforums.org/forum/installation/73984-cant-boot-past-loading-kernel-fedora-4-a.html
http://ubuntuforums.org/archive/index.php/t-146180.html
http://ubuntuforums.org/showthread.php?t=450630
http://www.linuxquestions.org/questions/linux-software-2/grub-freezes-before-uncompressing-kernel-464619/
not sure if really all of them are the edd problem i have, but i`m quite sure for some of those.
can provide more links if somebody likes.
> Adding 3 printks for each such obscure problem would make it even more
i wouldn`t call that problem obscure.
i have seen this problem more than 5 times since that code is in linux. so it`s at least enough to discuss about even if no other person thinks it`s necessary :) just the fact that it`s not been discussed often (here or elsewhere) doesn`t mean, that it exist or that users come across that. it`s more that type of "mhh, let`s try linux instead of windows. oh, doesn`t boot. ok, let`s stay with windows then...". you don`t expect people like those posting the right question to the right forum, do you?
> If there are known chipsets / BIOSes that have this problem - applying
> quirks - something like this quirk for pmtmr [1]- (if they work this
> early) or even special casing them with forced edd=off may be the right and more useful thing to do.
mhh. i`m unsure. ok, i`m no kernel-hacker but there are so many variants of bios/hardware out there so blacklisting certain bios versions may be never more than half of a solution.
roland
> -----Ursprüngliche Nachricht-----
> Von: "Parag Warudkar" <parag.warudkar@gmail.com>
> Gesendet: 16.12.07 18:34:48
> An: devzero@web.de
> CC: linux-kernel@vger.kernel.org, Matt.Domsch@dell.com, hpa@zytor.com
> Betreff: Re: [PATCH] [RFC] be more verbose when probing EDD
>
> On Sun, 16 Dec 2007, devzero@web.de wrote:
>
> >
> > - it seems there are buggy Bios implementations out there which have problems with EDD
> > - your favourite distro may have set CONFIG_EDD=y|m , so EDD probe is on by default quite often nowadays.
> > - setting "edd=off" when you get that hang on boot is _not_ obvious.
>
> It does not look like this issue is common - googling for "Linux EDD Boot
> hang" does not bring up relevant and recent results - in fact this post of
> yours comes on top. Further more there does not seem to be problems with
> newer BIOSes so we would be irritating lot many users needlessly.
>
> Adding 3 printks for each such obscure problem would make it even more
> complex to parse and make sense of the boot log - I, for example, already
> dislike the mostly-useless-to-end-user stuff it spews on a normal boot.
>
> If there are known chipsets / BIOSes that have this problem - applying
> quirks - something like this quirk for pmtmr [1]- (if they work this
> early) or even special casing them with forced edd=off may be the right and more useful thing to do.
>
> [1] http://www.webservertalk.com/archive242-2006-3-1447442.html
>
> Parag
>
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220
next reply other threads:[~2007-12-16 19:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-16 19:11 devzero [this message]
2007-12-16 19:59 ` [PATCH] [RFC] be more verbose when probing EDD Parag Warudkar
2007-12-16 20:18 ` Alan Cox
2007-12-17 23:25 ` Jan Engelhardt
2007-12-17 23:27 ` H. Peter Anvin
2007-12-18 0:10 ` Alan Cox
2007-12-18 0:22 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2007-12-16 21:04 devzero
2007-12-16 21:01 ` Alan Cox
2007-12-16 19:19 devzero
2007-12-16 15:34 devzero
2007-12-16 17:34 ` Parag Warudkar
2007-12-16 18:17 ` H. Peter Anvin
2007-12-22 1:15 ` Andi Kleen
2007-12-22 1:48 ` H. Peter Anvin
2007-12-22 1:57 ` Andi Kleen
2007-12-22 2:22 ` H. Peter Anvin
2007-12-22 2:41 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49448787@web.de \
--to=devzero@web.de \
--cc=Matt.Domsch@dell.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=parag.warudkar@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox