Jeff Garzik wrote:
Mark Hahn wrote:
I had good luck with this patch as well. I think the SATA-SMART patches
should go in too, even if they aren't perfect yet...
The Promise SATAII patch went in today.
The SMART patches absolutely -should not- go in. Certain common hdparm
commands can cause data
Gary Poppitz wrote:
We tracked down a problem with the 964 chipset with a 0x180 ID code that
may save someone on the list some time.
The chip will only transfer multiples of 4 bytes. Anything else will
cause it to hang.
Interesting, either ULi or SiS set me a needs-to-be-cleaned-up-a-lot fix
fo
Mark Hahn wrote:
has no builtin support for Promise SATAII 150 TX4 yet; a separate patch
(http://marc.theaimsgroup.com/?l=linux-ide&m=110426005503319&q=raw) is
needed to recognize this hardware.
I had good luck with this patch as well. I think the SATA-SMART patches
should go in too, even if th
> has no builtin support for Promise SATAII 150 TX4 yet; a separate patch
> (http://marc.theaimsgroup.com/?l=linux-ide&m=110426005503319&q=raw) is
> needed to recognize this hardware.
I had good luck with this patch as well. I think the SATA-SMART patches
should go in too, even if they aren't p
We tracked down a problem with the 964 chipset with a 0x180 ID code
that may save someone on the list some time.
The chip will only transfer multiples of 4 bytes. Anything else will
cause it to hang.
Our specific case occurred in cdrom.c in cdrom_get_disc_info.
There the code asks for 2 bytes t
>> If there is a bug, it is in ide_cdrom_driver declaration.
>> .end_request is not set to ide_cdrom_error.
>>
>
> I wondered about that. I'll give that a try.
>
OK, 2.6.11-rc3 has the same issue. The function ide_atapi_error() is
calling
drive->driver->end_request() when rq->errors exceeds
Please do a
bk pull bk://gkernel.bkbits.net/libata-2.6
This will update the following files:
drivers/scsi/ahci.c |2
drivers/scsi/libata-core.c | 187
drivers/scsi/libata-scsi.c | 35
drivers/scsi/sata_nv.c |
On Monday 07 February 2005 05:47, Tejun Heo wrote:
> Hello, Bartlomiej.
>
> Bartlomiej Zolnierkiewicz wrote:
> > [ against ide-dev-2.6 tree, boot tested on LBA48 drive ]
> >
> > This small patch fixes unneeded writes/reads to LBA48 taskfile registers
> > on LBA48 capable disks for following cases
FWIW, there are two limitations of libata in this area:
1) ISTR some PATA vendor-specific commands have a very specific set of
input and output registers to use, and input/output sets of registers
may differ from each other.
2) libata is lazy, and just reads registers in "groups": the
lbaH/M/L
