Another data point on the current libata EH:
I have now been running 2.6.13 for a week now
with no crashes attributable to libata.
This is stock 2.6.13, plus:
-- libata passthru patch (needed for laptop-mode, etc..)
-- libata atapi DMA patch (needed for modern laptop)
-- libata suspend
Mark Lord wrote:
-- libata atapi DMA patch (needed for modern laptop)
Which patch is this? DMA alignment?
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 8/19/05, Mark Lord [EMAIL PROTECTED] wrote:
Erik Slagter wrote:
On Thu, 2005-08-18 at 20:46 -0400, Mark Lord wrote:
After a week of further experience with this patch,
..
I'm now reverting to the original broken patch
..
What is exactly the broken patch and what is this patch?
On 8/19/05, Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
On 8/19/05, Mark Lord [EMAIL PROTECTED] wrote:
Erik Slagter wrote:
On Thu, 2005-08-18 at 20:46 -0400, Mark Lord wrote:
After a week of further experience with this patch,
..
I'm now reverting to the original broken patch
One idea would be to inject more faults into disk (ATA)
as opposed to the Optical (ATAPI) drives, and see if doing
so in combination with the existing ATAPI poll/fails will
trigger things more quickly.
This can be done by using Passthru to issue invalid commands
to a drive, which the drive will
Tejun Heo wrote:
And this is the combined patch against ncq head of libata-dev-2.6
tree. Commit d032ec9048ff82a704b96b93cfd6f2e8e3a06b19.
Only ata_piix, sata_sil and ahci are converted and all other SATA
drivers are broken. So, enable only those three SATA drivers when
compiling with this
Hello, Jeff.
The patch I posted in this thread is just collapsed version of the
following patchset.
http://marc.theaimsgroup.com/?l=linux-idem=112074204019013w=2
Above post has it splitted over 11 patches and has proper explanations.
Jeff Garzik wrote:
Tejun Heo wrote:
And this is
Tejun Heo wrote:
* _All_ errors are handled in EH thread.
* Once any error has occurred, all normal processing stops until error
condition is cleared by EH.
Do you mean all normal processing for that channel stops,
or *ALL* processing on all libata channels stops?
Obviously the former, I
Mark Lord wrote:
Tejun Heo wrote:
* _All_ errors are handled in EH thread.
* Once any error has occurred, all normal processing stops until
error condition is cleared by EH.
Do you mean all normal processing for that channel stops,
or *ALL* processing on all libata channels stops?
Tejun Heo wrote:
Mark Lord wrote:
Tejun Heo wrote:
* _All_ errors are handled in EH thread.
* Once any error has occurred, all normal processing stops until
error condition is cleared by EH.
Do you mean all normal processing for that channel stops,
or *ALL* processing on all libata
I'm back from holiday now, and will try your one-liner
in place of the more complex patch I had been using.
Okay, the one-liner eh fix for libata appears to prevent
the lockups here, so I will continue using it from now on
in place of the earlier more complex patch.
And it looks obviously
Hi, Mark.
Mark Lord wrote:
Tejun,
I'm back from holiday now, and will try your one-liner
in place of the more complex patch I had been using.
(that's what you intended, right?)
Yeap, and if possible, please also try the second large patch. I
wanna make sure it's free of that problem.
On Fri, Aug 05, 2005 at 12:52:07PM +0900, Tejun Heo wrote:
Mark Lord wrote:
The problem with this patch is that is causes leaks, and doesn't
actually ready the devices because scsi_eh_ready_devs() is never called:
scsi_eh_abort_cmds() is guaranteed to fail out every time its called.
13 matches
Mail list logo
