On 7/15/07, Timo Lindemann <tlindemann@arcor.de> wrote:Perhaps you could try updating your BIOS, if possible / applicable (?) Hey, just try git-bisect already :-) In fact, you can first try by just reverting / un-applying that patch that you initially had a suspicion on. Or, because you've already spent some time tracking down the issue, you could simply go through the git history of that file / subsystem in question and play around reverting individual patches that you find suspicious -- but really, there's no need to try and be cute with this: you could simply do a git-bisect (say between 2.6.20 and 2.6.21) and find the offending patch (or at least the one that un-hides the bug) that makes the boot fail ... [ BTW you haven't sent your dmesg / boot-time output ... if it isn't getting saved to disk, you could try serial / netconsole, copy it by hand, or simply take a photo and post it here. ] Cheers, Satyam -
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| H. Peter Anvin | Re: [PATCH] x86: Construct 32 bit boot time page tables in native format. |
| Christoph Lameter | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
git: | |
| Christoph Hellwig | Re: [PATCH 06/32] IGET: Mark iget() and read_inode() as being obsolete [try #2] |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
