linux-kernel - Re: [bisect] kernel 2.6.38 regression with root nfs mounting

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <AANLkTinE-bhSAuLHQQzHOoktGpf2bDMLUB04uo7EO7qv@mail.gmail.com>
Date:	Wed, 23 Mar 2011 07:05:58 +0100
From:	Belisko Marek <marek.belisko@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Brian Downing <bdowning@...os.net>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Chuck Lever <chuck.lever@...cle.com>,
	Trond Myklebust <Trond.Myklebust@...app.com>
Subject: Re: [bisect] kernel 2.6.38 regression with root nfs mounting

On Tue, Mar 22, 2011 at 2:34 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Tue, Mar 22, 2011 at 08:52:12AM +0100, Belisko Marek wrote:
>> CC: also lkml
>
> And please Cc those that are on that commit.
>
>
>>
>> After update from 2.6.38-rc8 to 2.6.38 is mounting rootfs over nfs not possible.
>> Log:
>> VFS: Mounted root (nfs filesystem) on device 0:14.
>> Freeing init memory: 132K
>> nfs: server 10.146.1.21 not responding, still trying
>> nfs: server 10.146.1.21 not responding, still trying
>>
>> This is never ending. I make short bisect (not too much commits
>> between versions)
>> and bad commit was reported: 53d4737580535e073963b91ce87d4216e434fab5
>>
>> NFS: NFSROOT should default to "proto=udp"
>>
>> I've tested on mini2440 board (DM9000, static IP).
>> Is there some missing option or something else to be checked?
>
> Sometimes git bisect messes up. Did you verify that commit broke the
> kernel? It's easy to do:
Sure I did same thing to check if bisect is correct. I try to check also patch
but after short look it doesn't seems to be something strange or guilty there.
>
> git checkout 53d4737580535e073963b91ce87d4216e434fab5~1
>
> then build and boot the kernel and test if it works.
>
> git checkout 53d4737580535e073963b91ce87d4216e434fab5
>
> then build and boot again and test if it fails.
>
> If the first checkout works and the second fails, then you have verified
> that is the guilty commit.
>
> Thanks,
>
> -- Steve
>
>>
>> Regards,
>>
>> marek
>>
>> --
>> as simple and primitive as possible
>> -------------------------------------------------
>> Marek Belisko - OPEN-NANDRA
>> Freelance Developer
>>
>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> Tel: +421 915 052 184
>> skype: marekwhite
>> icq: 290551086
>> web: http://open-nandra.com
>

regards,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
icq: 290551086
web: http://open-nandra.com
--
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/