That sata_nv issue should not be present anymore in the current 
libata-dev tree.

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

-

[ message continues ]

That's correct, it is not, at least the machine exception problem isn't.
However, the incorrect returns from SET_MAX are still an issue with that
hw. No idea what is causing it.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-

[ message continues ]

Curious.. Do you have some output or other details from what was 
actually returned? Also was this on more than one drive model?

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

-

[ message continues ]

I no longer have these outputs handy, although a bug report on
launchpad.net might have it (linux-source-2.6.20 package).

It was an abnormally huge value (hence the exposed signed extension
problems I fixed). The incorrect value was always the same for the same
controller/drive pair. It was not specific to a drive model, only
sata_nv (and I think pata_amd) was common to these cases.

Due to the extreme proximity of this bug being exposed to our release
deadline, we did not investigate the absolute cause of the issue, just
implemented a safer HPA detection to avoid them. If you have a sata_nv,
it is easy to get these values even with my patch since it outputs a
warning with the incorrect read back from SET_MAX. So the problems wont
go unnoticed.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

-

[ message continues ]