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.
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.
So please guys, what is the magic dependency that causes libata and
sata_nv to be included in a .config?
Thanks & Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
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.
--
~Randy
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.
>> 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.
Thanks Randy.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
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"
e.g.,
"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:
initcall_debug
--
~Randy
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
On Friday 14 February 2014, Larry Finger wrote:
>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
Almost exactly the same, Larry, I waited for the 2 minute timeout that
tried to print something on the top line of the screen before I got up to
walk over and reset it, but this time there was about a 1 minute blast of
disk activity from the drive it was trying to boot from, and I thought I
might have been an e2fsck, so I waited till the drive leds went off and
stayed off before resetting it. Nothing on the screen changed after that.
So call me clueless & you would be pretty accurate. :(
Is there another dependency yet?
Thanks.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.