sata_nv: 2.6.22 is not fixed, but certainly improved

sata_nv: 2.6.22 is not fixed, but certainly improved

[Charles Shannon Hendrix]

I just compiled 2.6.22.1 on my Kubuntu 7.0.4 system.

As before, I get errors using my Seagate SATA drives, and setting adma=0
fixes the problem.  I've posted the exact error/reset messages several times
before.

However, I would like to note that it happens far less often with 2.6.22.1
than it did with 2.6.21.

The history on my own machine is like this:

	2.6.19	perfect, but of course no ADMA/NCQ
	2.6.20	horrible, with hard resets starting immediately upon
		boot, and taking 15 minutes to finally disable NCQ
	2.6.21	bad resets, but they only occured ever 10-30 minutes,
		NCQ never disabled
	2 6.22	resets infrequent, they are soft resets, and much
		quicker than before (i.e. less interruption of my usage)
		NCQ is never disabled

I have no idea why I might be seeing a gradual reduction in the severity of
the problem, but it seems worth noting.

I want to point it out in case it means something to anyone working on
the kernel, especially the SATA code and drivers.

In the last 4 hours of use, I've seen a single reset.

On all previous kernels under the same load, I'd already have seen several of
them, or with 2.6.20, a constant stream of them.




-- 
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.

Re: sata_nv: 2.6.22 is not fixed, but certainly improved

[Robert Hancock]

Charles Shannon Hendrix wrote:
> I just compiled 2.6.22.1 on my Kubuntu 7.0.4 system.
> 
> As before, I get errors using my Seagate SATA drives, and setting adma=0
> fixes the problem.  I've posted the exact error/reset messages several times
> before.
> 
> However, I would like to note that it happens far less often with 2.6.22.1
> than it did with 2.6.21.
> 
> The history on my own machine is like this:
> 
> 	2.6.19	perfect, but of course no ADMA/NCQ
> 	2.6.20	horrible, with hard resets starting immediately upon
> 		boot, and taking 15 minutes to finally disable NCQ
> 	2.6.21	bad resets, but they only occured ever 10-30 minutes,
> 		NCQ never disabled
> 	2 6.22	resets infrequent, they are soft resets, and much
> 		quicker than before (i.e. less interruption of my usage)
> 		NCQ is never disabled
> 
> I have no idea why I might be seeing a gradual reduction in the severity of
> the problem, but it seems worth noting.
> 
> I want to point it out in case it means something to anyone working on
> the kernel, especially the SATA code and drivers.
> 
> In the last 4 hours of use, I've seen a single reset.
> 
> On all previous kernels under the same load, I'd already have seen several of
> them, or with 2.6.20, a constant stream of them.

Can you post the output you got from the reset on 2.6.22?

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: sata_nv: 2.6.22 is not fixed, but certainly improved

[Robert Hancock]

Robert Hancock wrote:
> Can you post the output you got from the reset on 2.6.22?

It's one of these:

ata4: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000
status 0x400 next cpb count 0x0 next cpb idx 0x0
ata4: CPB 0: ctl_flags 0x9, resp_flags 0x0
ata4: timeout waiting for ADMA IDLE, stat=0x400
ata4: timeout waiting for ADMA LEGACY, stat=0x400
ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata4.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0
          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata4: soft resetting port
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: configured for UDMA/133
ata4: EH complete
sd 5:0:0:0: [sdb] 156301488 512-byte hardware sectors (80026 MB)
sd 5:0:0:0: [sdb] Write Protect is off
sd 5:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA

Essentially the controller has been given a command (a cache flush, 
which for whatever reason seems to cause this frequently) but it doesn't 
give any indication that it has done anything with it (CPB response 
flags remain at 0). There have been a few reports of this, and I'm at a 
loss to explain why it happens. Certainly the publicly known information 
on this controller doesn't seem to give any hints on what if anything we 
could be doing wrong.

A workaround was added in sata_nv a while back that adds a delay between 
  completion of an NCQ command and issuing of a non-NCQ command, or vice 
versa. This seems to have improved things (for unknown reasons), but 
hasn't entirely fixed the problem. If your drive has NCQ support, it may 
be a remaining case of this problem.

I've previously asked for info on this issue from NVIDIA (as well as 
Jeff Garzik who has access to the controller documentation), but haven't 
gotten any info yet. Consider this another ping :-)

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/