All of lore.kernel.org
 help / color / mirror / Atom feed
From: Larry Finger <Larry.Finger@lwfinger.net>
To: Randy Dunlap <rdunlap@infradead.org>,
	Gene Heskett <gheskett@wdtv.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Loseing my patience with libata and sata_nv
Date: Fri, 14 Feb 2014 18:14:31 -0600	[thread overview]
Message-ID: <52FEB167.9080404@lwfinger.net> (raw)
In-Reply-To: <52FE639C.2030007@infradead.org>

On 02/14/2014 12:42 PM, Randy Dunlap wrote:
> On 02/14/2014 08:31 AM, Gene Heskett wrote:
>> Which is required for my $290 ASUS M2n-SLI Deluxe motherboard to boot.
>>
>> Not finding the option in any kernel tree that exists on my system,
>> except it appears its been replaced or something.
>>
>> This once in a lifetime boot, to 3.12.9, shows from an lsmod:
>> libata                146855  2 sata_nv,pata_amd
>> scsi_mod              153579  4 sr_mod,sg,sd_mod,libata
>>
>> I haven't a clue how I got it in this boot, and I built it.  And
>> apparently a make oldconfig, carefully done by hand (takes about an hour
>> 30 to do) is not capable of adding it to a .config BECAUSE it does NOT
>> exist in any of the arch/x86/configs/i386_defconfig's present on this machine.
>
> It does not have to exist in any defconfig.  Those are just default config files
> and SATA_NV is not enabled by default, but you can still enable it.
>
>> Here is how I searched:
>>
>> gene@coyote:~/src/linux-3.0.69$ grep SATA_NV arch/x86/configs/i386_defconfig
>> gene@coyote:~/src/linux-3.0.69$ cd ../linux-3.2.40
>> gene@coyote:~/src/linux-3.2.40$ grep SATA_NV arch/x86/configs/i386_defconfig
>> gene@coyote:~/src/linux-3.2.40$ cd ../linux-3.4.36
>> gene@coyote:~/src/linux-3.4.36$ grep SATA_NV arch/x86/configs/i386_defconfig
>> gene@coyote:~/src/linux-3.4.36$ cd ../linux-3.8.2
>> gene@coyote:~/src/linux-3.8.2$ grep SATA_NV arch/x86/configs/i386_defconfig
>> gene@coyote:~/src/linux-3.8.2$ cd ../linux-3.8.3
>> gene@coyote:~/src/linux-3.8.3$ grep SATA_NV arch/x86/configs/i386_defconfig
>> gene@coyote:~/src/linux-3.8.3$ cd ../linux-3.12.0
>> gene@coyote:~/src/linux-3.12.0$ grep SATA_NV arch/x86/configs/i386_defconfig
>> gene@coyote:~/src/linux-3.12.0$ cd ../linux-3.12.6
>> gene@coyote:~/src/linux-3.12.6$ grep SATA_NV arch/x86/configs/i386_defconfig
>> gene@coyote:~/src/linux-3.12.6$ cd ../linux-3.12.9
>> gene@coyote:~/src/linux-3.12.9$ grep SATA_NV arch/x86/configs/i386_defconfig
>> gene@coyote:~/src/linux-3.12.9$ cd ../linux-3.13.1
>> gene@coyote:~/src/linux-3.13.1$ grep SATA_NV arch/x86/configs/i386_defconfig
>> gene@coyote:~/src/linux-3.13.1$ cd ../linux-3.13.2
>> gene@coyote:~/src/linux-3.13.2$ grep SATA_NV arch/x86/configs/i386_defconfig
>> gene@coyote:~/src/linux-3.13.2$
>>
>> I've been fighting with this, intermittently for about 6 months.  Except
>> for this 3.12.9 where I must have been holding my mouth right, all the
>> rest are boot failures because it can't find the boot drive with so-and-so
>> for a UUID. sata_nv is on the missing list, even in this WORKing boots defconfig.
>> "Working" however is a miss-statement, no multimedia stuff was built.
>>
>> There has to be a rule I am violating, but even with Randy's D's help, it is
>> not becoming obvious.  FWIW libata references also can't be found, but as
>> can be seen, its in memory right now.
>
> libata is built whenever CONFIG_ATA is enabled.
>
>>
>> So please guys, what is the magic dependency that causes libata and
>> sata_nv to be included in a .config?
>
> The SATA_NV kconfig symbol depends on (requires) the following other kconfig
> symbols to be enabled:
> 	ATA_SFF and ATA_BMDMA and PCI and ATA
>
> If those are not enabled, then you will need to use 'make <some>config' to
> enabled them before you can enable SATA_NV.

Gene,

Your CONFIG indicates that you are building both libata and sata_nv. Perhaps you 
are not including them in your initrd, or whatever it is called in your distro. 
That makes them unavailable at boot time due to the chicken-and-egg problem. You 
need those drivers to access the drive, but that is where they reside. An easy 
way might be to make those two drivers be built in rather than as modules.

Larry



  parent reply	other threads:[~2014-02-15  0:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-14 16:31 Loseing my patience with libata and sata_nv Gene Heskett
2014-02-14 18:42 ` Randy Dunlap
2014-02-14 19:21   ` Gene Heskett
2014-02-14 22:16     ` Randy Dunlap
2014-02-15  0:14   ` Larry Finger [this message]
2014-02-15  4:01     ` Gene Heskett

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=52FEB167.9080404@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=gheskett@wdtv.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.