Robert wrote:
> Kuan Luo wrote:
> > Robert worte.
> >> Kuan, does this patch (using the notifiers to see if the
> command is
> >> really done) still work if one port on the controller has
> >> ADMA disabled
> >> because it's in ATAPI mode? I seem to recall Allen Martin
> mentioning
> >> that
robert wrote:
> Kuan Luo wrote:
> > Robert worte.
> >> Kuan, does this patch (using the notifiers to see if the
> command is
> >> really done) still work if one port on the controller has
> >> ADMA disabled
> >> because it's in ATAPI mode? I seem to recall Allen Martin
> mentioning
> >> that
Kuan Luo wrote:
Robert worte.
Kuan, does this patch (using the notifiers to see if the command is
really done) still work if one port on the controller has
ADMA disabled
because it's in ATAPI mode? I seem to recall Allen Martin mentioning
that notifiers wouldn't work in this case.
I just
Kuan Luo wrote:
Robert worte.
Kuan, does this patch (using the notifiers to see if the command is
really done) still work if one port on the controller has
ADMA disabled
because it's in ATAPI mode? I seem to recall Allen Martin mentioning
that notifiers wouldn't work in this case.
I just
robert wrote:
Kuan Luo wrote:
Robert worte.
Kuan, does this patch (using the notifiers to see if the
command is
really done) still work if one port on the controller has
ADMA disabled
because it's in ATAPI mode? I seem to recall Allen Martin
mentioning
that notifiers wouldn't
Robert wrote:
Kuan Luo wrote:
Robert worte.
Kuan, does this patch (using the notifiers to see if the
command is
really done) still work if one port on the controller has
ADMA disabled
because it's in ATAPI mode? I seem to recall Allen Martin
mentioning
that notifiers wouldn't
Robert worte.
>
> Kuan, does this patch (using the notifiers to see if the command is
> really done) still work if one port on the controller has
> ADMA disabled
> because it's in ATAPI mode? I seem to recall Allen Martin mentioning
> that notifiers wouldn't work in this case.
>
I just
Jeff Garzik wrote:
Robert Hancock wrote:
Jeff Garzik wrote:
Ping... sata_nv status is still a bit open for 2.6.24, and I would
like to move us forward a bit.
* Kuan's patch... it has been confirmed (and is needed), correct?
can someone work up a good patch for 2.6.24? The only one I
Robert Hancock wrote:
Jeff Garzik wrote:
Ping... sata_nv status is still a bit open for 2.6.24, and I would
like to move us forward a bit.
* Kuan's patch... it has been confirmed (and is needed), correct?
can someone work up a good patch for 2.6.24? The only one I ever
received was
Kuan Luo wrote:
First thank davide to help to send the attachment.
Robert,
The patch is to solve the error message "ata1: CPB flags CMD err,
flags=0x11" when testing HDS7250SASUN500G in rhel4u5.
I tested this hd in 2.6.24-rc7 which needed to remove the mask in
blacklist to run the ncq and the
Jeff Garzik wrote:
Ping... sata_nv status is still a bit open for 2.6.24, and I would like
to move us forward a bit.
* Kuan's patch... it has been confirmed (and is needed), correct? can
someone work up a good patch for 2.6.24? The only one I ever received
was badly word-wrapped, and at
Robert Hancock wrote:
Kuan Luo wrote:
Robert hancock wrote:
What problem does this resolve? I tested it against the cache
flush/NCQ write switching problem we've been trying to solve, and it
doesn't look like it fixes that one - if I apply this patch and then
remove the udelay(20) in
Robert Hancock wrote:
Kuan Luo wrote:
Robert hancock wrote:
What problem does this resolve? I tested it against the cache
flush/NCQ write switching problem we've been trying to solve, and it
doesn't look like it fixes that one - if I apply this patch and then
remove the udelay(20) in
Jeff Garzik wrote:
Ping... sata_nv status is still a bit open for 2.6.24, and I would like
to move us forward a bit.
* Kuan's patch... it has been confirmed (and is needed), correct? can
someone work up a good patch for 2.6.24? The only one I ever received
was badly word-wrapped, and at
Kuan Luo wrote:
First thank davide to help to send the attachment.
Robert,
The patch is to solve the error message ata1: CPB flags CMD err,
flags=0x11 when testing HDS7250SASUN500G in rhel4u5.
I tested this hd in 2.6.24-rc7 which needed to remove the mask in
blacklist to run the ncq and the
Robert Hancock wrote:
Jeff Garzik wrote:
Ping... sata_nv status is still a bit open for 2.6.24, and I would
like to move us forward a bit.
* Kuan's patch... it has been confirmed (and is needed), correct?
can someone work up a good patch for 2.6.24? The only one I ever
received was
Jeff Garzik wrote:
Robert Hancock wrote:
Jeff Garzik wrote:
Ping... sata_nv status is still a bit open for 2.6.24, and I would
like to move us forward a bit.
* Kuan's patch... it has been confirmed (and is needed), correct?
can someone work up a good patch for 2.6.24? The only one I
Robert worte.
Kuan, does this patch (using the notifiers to see if the command is
really done) still work if one port on the controller has
ADMA disabled
because it's in ATAPI mode? I seem to recall Allen Martin mentioning
that notifiers wouldn't work in this case.
I just tried the
Robert Hancock wrote:
> As I mentioned, this doesn't seem to resolve the problem we're seeing
> with rapidly intermixed NCQ commands and cache flushes (at
> least, if I
> take out the arbitrary 20usec delay from the driver and add
> this patch,
> the problem still shows up). It could be a
Kuan Luo wrote:
Robert hancock wrote:
What problem does this resolve? I tested it against the cache
flush/NCQ
write switching problem we've been trying to solve, and it
doesn't look
like it fixes that one - if I apply this patch and then remove the
udelay(20) in sata_nv.c that I added which
Robert hancock wrote:
> What problem does this resolve? I tested it against the cache
> flush/NCQ
> write switching problem we've been trying to solve, and it
> doesn't look
> like it fixes that one - if I apply this patch and then remove the
> udelay(20) in sata_nv.c that I added which
Robert hancock wrote:
What problem does this resolve? I tested it against the cache
flush/NCQ
write switching problem we've been trying to solve, and it
doesn't look
like it fixes that one - if I apply this patch and then remove the
udelay(20) in sata_nv.c that I added which prevented
Kuan Luo wrote:
Robert hancock wrote:
What problem does this resolve? I tested it against the cache
flush/NCQ
write switching problem we've been trying to solve, and it
doesn't look
like it fixes that one - if I apply this patch and then remove the
udelay(20) in sata_nv.c that I added which
Robert Hancock wrote:
As I mentioned, this doesn't seem to resolve the problem we're seeing
with rapidly intermixed NCQ commands and cache flushes (at
least, if I
take out the arbitrary 20usec delay from the driver and add
this patch,
the problem still shows up). It could be a similar
Kuan Luo wrote:
hi robert,
I have fixed a bug in rhel4u5 2.6.9-55 when running adma mode
with HDS7250SASUN500G.
Could you check this code and if no problem, then help me to
submit to the newest kernel.
What problem does this resolve? I tested it against the cache flush/NCQ
Kuan Luo wrote:
hi robert,
I have fixed a bug in rhel4u5 2.6.9-55 when running adma mode
with HDS7250SASUN500G.
Could you check this code and if no problem, then help me to
submit to the newest kernel.
What problem does this resolve? I tested it against the cache flush/NCQ
26 matches
Mail list logo