My system has issues running adma mode with sata_nv. I have an nforce4
motherboard.
What is the current status of this problem?
Is there any information I can provide to help debug it?
I gave up trying various fixes about 6 months ago, and put "sata_nv.adma=0" on
the kernel command line in LILO, and that fixed the problem.
However, recently I changed distributions and went back to 2.6.20 (kubuntu 7.04).
This kernel says that sata_nv.adma=0 is an invalid kernel option.
I'm pretty puzzled by that, because it is supposed to disable adma mode in the
sata_nv driver.
/proc/cmdline says:
root=<hash> ro sata_nv.adma=0 quiet splash
...so it seems I did give the parameter properly.
Any ideas appreciated.
Is there a better way to deal with this?
Also, one more: does it hurt to wait until the sata_nv driver fails a few
times (at which point it stops bitching) and use the machine? Once it
fails about 6 times, I no longer have any issues, and speed is still good
enough to use until a real fix can be had.
Thanks.
--
shannon | An Irishman is never drunk as long as he can hold onto
| one blade of grass and not fall off the face of the earth.
Charles Shannon Hendrix wrote:
>
> My system has issues running adma mode with sata_nv. I have an nforce4
> motherboard.
>
> What is the current status of this problem?
You'll have to be a bit more specific than that. A few problems have
arisen in the past, but currently I don't think there is anything known
outstanding other than one hotplug issue which currently is lacking in
information to debug.
>
> Is there any information I can provide to help debug it?
>
> I gave up trying various fixes about 6 months ago, and put
> "sata_nv.adma=0" on the kernel command line in LILO, and that fixed the
> problem.
>
> However, recently I changed distributions and went back to 2.6.20
> (kubuntu 7.04).
>
> This kernel says that sata_nv.adma=0 is an invalid kernel option.
>
> I'm pretty puzzled by that, because it is supposed to disable adma mode
> in the sata_nv driver.
>
> /proc/cmdline says:
>
> root=<hash> ro sata_nv.adma=0 quiet splash
>
> ..so it seems I did give the parameter properly.
>
> Any ideas appreciated.
If sata_nv is built modular, then you may need to put:
options sata_nv adma=0
in /etc/modprobe.conf instead.
However I should point out that adma=0 is a poor workaround, it would be
better to find the real cause of the problem.
>
> Is there a better way to deal with this?
>
> Also, one more: does it hurt to wait until the sata_nv driver fails a
> few times (at which point it stops bitching) and use the machine? Once it
> fails about 6 times, I no longer have any issues, and speed is still
> good enough to use until a real fix can be had.
Please post the dmesg output from when this happens. If it starts
working after the kernel disables NCQ, then it might mean that your
drive has some problems with NCQ..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Charles Shannon Hendrix wrote:
> Ah... I thought I put the error in my post.
>
> Here is an example:
>
> Jun 10 19:47:21 daydream kernel: [ 174.432000] ata4: timeout waiting
> for ADMA IDLE, stat=0x400
> Jun 10 19:47:21 daydream kernel: [ 174.432000] ata4: timeout waiting
> for ADMA LEGACY, stat=0x400
> Jun 10 19:47:21 daydream kernel: [ 174.432000] res
> 40/00:00:00:00:00/0
> 0:00:00:00:00/00 Emask 0x4 (timeout)
Looks like a line or two is missing here, there should be one saying
what the failed command was. Can you post the full dmesg output from the
start with these occurrences in it?
> Jun 10 19:47:21 daydream kernel: [ 174.744000] ata4: soft resetting port
> Jun 10 19:47:21 daydream kernel: [ 174.900000] ata4: SATA link up 1.5
> Gbps (SStatus 113 SControl 300)
> Jun 10 19:47:21 daydream kernel: [ 174.908000] ATA: abnormal status
> 0xD0 on port 0xf885659c
> Jun 10 19:47:21 daydream kernel: [ 174.920000] ATA: abnormal status
> 0xD0 on port 0xf885659c
> Jun 10 19:47:21 daydream last message repeated 2 times
> Jun 10 19:47:21 daydream kernel: [ 174.936000] ata4.00: ata_hpa_resize
> 1: sectors = 156301488, hpa_sectors = 156301488
> Jun 10 19:47:21 daydream kernel: [ 174.944000] ata4.00: ata_hpa_resize
> 1: sectors = 156301488, hpa_sectors = 156301488
> Jun 10 19:47:21 daydream kernel: [ 174.944000] ata4.00: configured for
> UDMA/133
> Jun 10 19:47:21 daydream kernel: [ 174.944000] ata4: EH complete
> Jun 10 19:47:21 daydream kernel: [ 174.944000] SCSI device sdb:
> 156301488 512-byte hdwr sectors (80026 MB)
> Jun 10 19:47:21 daydream kernel: [ 174.944000] sdb: Write Protect is off
> Jun 10 19:47:21 daydream kernel: [ 174.944000] SCSI device sdb: write
> cache: enabled, read cache: enabled, doesn't support DPO or FUA
>
> A lot of people reported this problem. Basically the driver does this a
> few times, and then stops.
>
>> If sata_nv is built modular, then you may need to put:
>>
>> options sata_nv adma=0
>
> It is, but I thought the kernel command line was still supposed to be
> able to
> pass options to a module. That's not correct?
It really should, but I don't think it does.
>
> Anyway, I'll create a new init ramdisk with the module option set and
> see how that works.
>
>> However I should point out that adma=0 is a poor workaround, it would
>> be better to find the real cause of the problem.
>
> Agreed.
>
> However, I tried all the patches and workarounds before, and had to give
> up to get work done.
>
> It has happened across two different motherboards, and on two drives.
>
> Right now it happens with my second drive (I have two identical Seagate
> SATA drives). The last time I had adma enabled, it was the first drive.
>
> No idea why it would be one drive one time and the other one a different
> time.
>
>> Please post the dmesg output from when this happens. If it starts
>> working after the kernel disables NCQ, then it might mean that your
>> drive has some problems with NCQ..
>
> See above for dmesg output.
>
> If that were true, then why would NCQ work perfectly under Windows?
> Neither drive has issues there.
>
> If the drives are at fault, then shouldn't they have the problem
> regardless of the OS running?
>
> FreeBSD had no trouble either.
>
> Linux didn't have trouble until the 2.6.20 kernel.
There was no support for ADMA or NCQ on these controllers in Linux until
2.6.20.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/