[lkml]   [2014]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Loseing my patience with libata and sata_nv
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:
> If those are not enabled, then you will need to use 'make <some>config' to
> enabled them before you can enable SATA_NV.


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.


 \ /
  Last update: 2014-02-15 02:01    [W:0.036 / U:1.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site