Re: [parisc-linux] Re: Why toggle_bounce only for disks?

2005-08-19 Thread James Bottomley
On Fri, 2005-08-19 at 12:21 +0200, Jens Axboe wrote: Because not bouncing is a performance optimization and I only did the work on ide-cd to allow it. Your patch breaks ide-cd on highmem i386 machines, so it's not acceptable. Tells us more about this crash instead, I'm pretty sure you are

Re: libata total system lockup fix

2005-08-19 Thread Bartlomiej Zolnierkiewicz
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?

Re: libata total system lockup fix

2005-08-19 Thread Bartlomiej Zolnierkiewicz
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

Re: [git] libata-dev queue updated

2005-08-19 Thread Jeff Garzik
Brett Russ wrote: Jeff Garzik wrote: In such cases, patches are divided into branches by category: ncq (NCQ queueing support), chs-support (C/H/S support), adma (new ADMA driver), sil24 (new Silicon Image 312x driver), passthru (ATA passthrough/SMART support), etc. Jeff, The below doesn't

Re: libata error handling

2005-08-19 Thread Luben Tuikov
On 08/19/05 01:40, Tejun Heo wrote: I genearally agree that the events are somewhat standard for block devices but IMHO SCSI EH also has fair amount SCSI-specific assumptions and ATA is a bit too different from SCSI to fit cleanly into it. For example, when handling NCQ errors, the whole

Re: [patch] libata passthrough - return register data from HDIO_* commands

2005-08-19 Thread John W. Linville
On Mon, Aug 15, 2005 at 11:11:02PM +0100, Jon Escombe wrote: Here is a first attempt at a patch to return register data from the libata passthrough HDIO ioctl handlers, I needed this as the ATA 'unload immediate' command returns the success in the lbal register. Haven't had any feedback

Re: [patch] libata passthrough - return register data from HDIO_* commands

2005-08-19 Thread John W. Linville
On Fri, Aug 19, 2005 at 03:06:27PM -0400, John W. Linville wrote: On Mon, Aug 15, 2005 at 11:11:02PM +0100, Jon Escombe wrote: Here is a first attempt at a patch to return register data from the libata passthrough HDIO ioctl handlers, I needed this as the ATA 'unload immediate' command

Re: libata error handling

2005-08-19 Thread Patrick Mansfield
On Fri, Aug 19, 2005 at 02:46:35PM -0400, Luben Tuikov wrote: Using the command time out hook and the strategy routine, gives _complete_ control over host recovery, and I really do mean _complete_. I assume you mean hostt-eh_timed_out. Is anyone implmenting (or has implemented) a

Re: libata error handling

2005-08-19 Thread Mike Anderson
Luben Tuikov [EMAIL PROTECTED] wrote: On 08/19/05 15:38, Patrick Mansfield wrote: The eh_timed_out + eh_strategy_handler is actually pretty perfect, and _complete_, for any application and purpose in recovering a LU/device/host (in that order ;-) ). The two problems I see with the hook

Re: libata error handling

2005-08-19 Thread Luben Tuikov
On 08/19/05 16:11, Patrick Mansfield wrote: On Fri, Aug 19, 2005 at 04:03:15PM -0400, Luben Tuikov wrote: The eh_timed_out + eh_strategy_handler is actually pretty perfect, and _complete_, for any application and purpose in recovering a One other point: Another problems is that we quiesce

Re: libata error handling

2005-08-19 Thread Luben Tuikov
On 08/19/05 17:10, Patrick Mansfield wrote: Luben - On Fri, Aug 19, 2005 at 04:43:41PM -0400, Luben Tuikov wrote: On 08/19/05 16:11, Patrick Mansfield wrote: I was changing it to wakeup the eh even while other IO is outstanding, so the eh can wakeup and cancel individual commands while

Re: [git patches] ide update

2005-08-19 Thread Bartlomiej Zolnierkiewicz
On 8/19/05, Alan Cox [EMAIL PROTECTED] wrote: On Gwe, 2005-08-19 at 11:02 +0200, Bartlomiej Zolnierkiewicz wrote: lkml.org/lkml/2005/1/27/20 AFAIK CS5535 driver was never ported to 2.6.x. Somebody needs to port it to 2.6.x kernel, cleanup to match kernel coding standards and test.