[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 11:21 AM, Gene Heskett wrote:
> On Friday 14 February 2014, 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.
> I don't believe the help states that.

AFAICT the Kconfig help does not tell what builds libata.
Would it help if it did?

Maybe by adding 'libata' to this prompt text:
"Serial ATA and Parallel ATA drivers"
"Serial ATA and Parallel ATA drivers (libata)"

>>> 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
> I wrote down those deps from the make menuconfig help screen, they are as
> stated. I made sure with gedit and grep...
> It gets to:
> Early console decompressing the kernel
> booting the kernel
> Thats it, no disk activity, its hung.
> .config for a 3.13.2 attached.
>> If those are not enabled, then you will need to use 'make <some>config'
>> to enabled them before you can enable SATA_NV.

Please add this string to the kernel command line to see if helps to
narrow down what is happening:


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