The IDE layers assume a failed flush cache is a simple error, but it is
actually far more complicated. The spec says that an error is returned by
flush cache if a sector cannot be committed to disc. In that case the
failed sector is dropped from cache and the command reports the bad
sector. It does
Hello,
I switched to libata drivers for my onboard PATA controller (PIIX4) recently.
Everything works fine except that kernel tries to start not only my hard
drive (sda) but also LS-120 floppy drive (sdb) which does not like it:
sd 0:0:0:0: [sda] Starting disk
ata1.00: configured for UDMA/33
sd
On Mon, 03 Dec 2007 13:49:36 +0900, Tejun Heo wrote:
> Mikael Pettersson wrote:
> >> what was the outcome of this discussion?
> >>
> >> I haven't looked over the Promise datasheet nor checked my brain for
> >> details, hoping Mikael would do that for me ;-)
> >
> > I've now tested this on top of
Mikael Pettersson wrote:
>> what was the outcome of this discussion?
>>
>> I haven't looked over the Promise datasheet nor checked my brain for
>> details, hoping Mikael would do that for me ;-)
>
> I've now tested this on top of 2.6.24-rc3, with no observable
> regressions. Blanking, writing, an
On Sat, 01 Dec 2007 18:23:44 -0500, Jeff Garzik wrote:
> Tejun Heo wrote:
> > Make pdc_atapi_pkt() use values from qc->tf instead of creating its
> > own. This is to ease future ATAPI handling changes.
> >
> > DONT APPLY YET
> > ---
> > Mikael, would this work? Values other than lbam and lbah re
Tejun Heo wrote:
Make pdc_atapi_pkt() use values from qc->tf instead of creating its
own. This is to ease future ATAPI handling changes.
DONT APPLY YET
---
Mikael, would this work? Values other than lbam and lbah remain the
same. Does sata_promise have strict requirements for lbam and lbah?
Hello,
Mikael Pettersson wrote:
>> buf[20] = (1 << 5) | ATA_REG_FEATURE;
>> buf[21] = feature;
>> buf[22] = (1 << 5) | ATA_REG_BYTEL;
>> -buf[23] = nbytes & 0xFF;
>> +buf[23] = qc->tf.lbam;
>> buf[24] = (1 << 5) | ATA_REG_BYTEH;
>> -buf[25] = (nbytes >> 8) & 0xFF;
>
On Mon, 26 Nov 2007 20:34:38 +0900, Tejun Heo wrote:
> Make pdc_atapi_pkt() use values from qc->tf instead of creating its
> own. This is to ease future ATAPI handling changes.
>
> DONT APPLY YET
> ---
> Mikael, would this work? Values other than lbam and lbah remain the
> same. Does sata_promi
Make pdc_atapi_pkt() use values from qc->tf instead of creating its
own. This is to ease future ATAPI handling changes.
DONT APPLY YET
---
Mikael, would this work? Values other than lbam and lbah remain the
same. Does sata_promise have strict requirements for lbam and lbah?
Thanks.
drivers/a
Jeff Garzik wrote:
>
> Alan's point was that the existing code will give you up to
> LIBATA_MAX_PRD entries. After the post-virtual-merge splitting code in
> ata_fill_sg() executes, the worst case result is ATA_MAX_PRD entries.
>
> Thus, since your code has the potential to increase the number o
On Sun, 28 Oct 2007 12:03:16 +0100 (MET), Mikael Pettersson wrote:
> On Sun, 28 Oct 2007 06:29:32 -0400, Jeff Garzik wrote:
> > BTW, looking at the Promise code I see
> >
> > > cam_con.h:
> > > /* for ASIC bug, limit the last element of SG byteCount must < 32 Dword */
> > > #define SG_COUNT_ASIC_B
Alexander Sabourenkov wrote:
Jeff Garzik wrote:
BTW, looking at the Promise code I see
cam_con.h:
/* for ASIC bug, limit the last element of SG byteCount must < 32
Dword */
#define SG_COUNT_ASIC_BUG 32
//#define SG_COUNT_ASIC_BUG 128
and in the code itself
/* check PRD table,
On Sun, 28 Oct 2007 06:29:32 -0400, Jeff Garzik wrote:
> BTW, looking at the Promise code I see
>
> > cam_con.h:
> > /* for ASIC bug, limit the last element of SG byteCount must < 32 Dword */
> > #define SG_COUNT_ASIC_BUG 32
> > //#define SG_COUNT_ASIC_BUG 128
>
> and in the code
Jeff Garzik wrote:
> BTW, looking at the Promise code I see
>
>> cam_con.h:
>> /* for ASIC bug, limit the last element of SG byteCount must < 32
>> Dword */
>> #define SG_COUNT_ASIC_BUG 32
>> //#define SG_COUNT_ASIC_BUG 128
>
> and in the code itself
>
>> /* check PRD table, last e
BTW, looking at the Promise code I see
cam_con.h:
/* for ASIC bug, limit the last element of SG byteCount must < 32 Dword */
#define SG_COUNT_ASIC_BUG 32
//#define SG_COUNT_ASIC_BUG 128
and in the code itself
/* check PRD table, last element <= (32 Dword), fix ASIC bug */
Alexander Sabourenkov wrote:
Hmm. sata_promise.c says:
* Maintained by: Jeff Garzik <[EMAIL PROTECTED]>
That should be changed :) I wrote the code but Mikael is now the
primary maintainer.
Meanwhile I'll check the Promise driver(s) to see if there's
something about SG table formatting
Alexander Sabourenkov wrote:
Alan Cox wrote:
I can't think of a way to avoid second pass over scatterlist without
duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).
This appears to be incomplete:
[...]
What guarantees you have enough PRD entries to do this without chang
Alexander Sabourenkov wrote:
> Alan Cox wrote:
>>> I can't think of a way to avoid second pass over scatterlist without
>>> duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).
>> This appears to be incomplete:
>>
>
> [...]
>
>> What guarantees you have enough PRD entries to do
Alan Cox wrote:
>> I can't think of a way to avoid second pass over scatterlist without
>> duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).
>
> This appears to be incomplete:
>
[...]
>
> What guarantees you have enough PRD entries to do this without changing
> the limit i
> I can't think of a way to avoid second pass over scatterlist without
> duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).
This appears to be incomplete:
> + VPRINTK("Splitting last PRD.\n");
> +
> + ap->prd[idx - 1].flags_len -=
> cpu
Hello.
> Interesting, but can you please give more background information?
> I.e., how did you determine the existence of this bug?
I was experiencing read/write errors, with data corruption.
Dmesgs and lspcis are at http://lxnt.info/linux/
I downloaded driver from the promise.com, put up 2.6.11
Hello.
Once again,
There appears to be a hardware bug in that it chokes on scatterlist
if the last item is larger than 164 bytes. This was discovered by
reading the code of vendor-supplied driver.
The patch that follows fixes my problem on 2.6.22.
I can't think of a way to avoid second pass over
MisterE wrote:
>
> Can you confirm that this only will happen when running at 300Gb mode?
I confirm that without this patch errors happen on both 150 and 300
modes, on both jumpered and unjumpered drives. It seems that errors are
highly hardware/configuration dependent.
> I'm willing to try your
On Sat, 27 Oct 2007 17:24:32 +0400, Alexander Sabourenkov wrote:
> There appears to be a hardware bug in that it chokes on scatterlist
> if the last item is larger than 164 bytes.
>
> The patch that follows fixes my problem on 2.6.22.
>
> I can't think of a way to avoid second pass over scatterli
Hello Alexander,
Saturday, October 27, 2007, 3:44:51 PM, you wrote:
>> There appears to be a hardware bug in that it chokes on scatterlist
>> if the last item is larger than 164 bytes.
Can you confirm that this only will happen when running at 300Gb mode?
I have the drives jumpered and have no
Alexander Sabourenkov wrote:
> Hello.
>
> There appears to be a hardware bug in that it chokes on scatterlist
> if the last item is larger than 164 bytes.
>
> The patch that follows fixes my problem on 2.6.22.
>
> I can't think of a way to avoid second pass over scatterlist without
> duplicating
Hello.
There appears to be a hardware bug in that it chokes on scatterlist
if the last item is larger than 164 bytes.
The patch that follows fixes my problem on 2.6.22.
I can't think of a way to avoid second pass over scatterlist without
duplicating code (ata_qc_prep() and ata_fill_sg() from lib
Repost of http://marc.info/?l=linux-ide&m=118106594419762&w=2
Could someone comment on the following please:
Add a hidden configuration for an architecture or machine to
select to show that the pata_platform driver should be show
in the configuration.
This method is used to allow each individual
Albert Lee wrote:
> Patch 7/9:
>
> After checking the current implementations of freeze()/thaw(), it seems only
> pdc_freeze()
> do more than simple irq masking. Remove the DMA disable code from
> pdc_freeze().
>
> The question is the design/semantic of freeze()/thaw().
> Maybe we should limit
Hello,
Albert Lee wrote:
> Patch 5/9:
>
> This patch changes polling codes to use freeze()/thaw() for irq off/on.
> ata_qc_set_polling() is also removed since now unused.
>
> The reason for freeze()/thaw(): some ATAPI devices raises INTRQ even if nIEN
> = 1.
> Using the host adapter irq mask
Patch 9/9:
It seems ->irq_on and ->irq_off are now only wrapped by freeze()/thaw() and
unused elsewhere.
This patch
- Remove ->irq_on and ->irq_off.
- Rename ->freeze and ->thaw to irq_on() and irq_off() to be specific.
Hopefully the LLDDs need to implement only one irq on/off by either h
Patch 8/9:
Currently ata_tf_load() writes to the Control register if it is changed.
The relevant bits in the ctl register are HOB, SRST and nIEN.
- HOB is only used by ata_tf_read().
- For SRST, soft reset is not the duty of tf_load.
- For nIEN, explicit irq_on()/irq_off and freeze()/thaw() a
Patch 7/9:
After checking the current implementations of freeze()/thaw(), it seems only
pdc_freeze()
do more than simple irq masking. Remove the DMA disable code from pdc_freeze().
The question is the design/semantic of freeze()/thaw().
Maybe we should limit them to simple irq on/off?
Signed-o
Patch 6/9:
Since now the polling code path uses freeze()/thaw() regardless of old EH or
new EH.
Add freeze()/thaw() to old EH LLDDs for use by the polling code.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
diff -Nrup 05_convert_hsm_to_freeze/drivers/ata/pata_ixp4xx_cf.c
06_add_freeze_thaw
Patch 5/9:
This patch changes polling codes to use freeze()/thaw() for irq off/on.
ata_qc_set_polling() is also removed since now unused.
The reason for freeze()/thaw(): some ATAPI devices raises INTRQ even if nIEN =
1.
Using the host adapter irq mask mechanism, if available, is more reliable
Patch 4/9:
Minor patch to call irq_off() from bmdma_freeze() to avoid duplicated code.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
diff -Nrup 03_add_irq_off_lldd/drivers/ata/libata-sff.c
04_convert_freeze/drivers/ata/libata-sff.c
--- 03_add_irq_off_lldd/drivers/ata/libata-sff.c20
Patch 3/9:
Minor patch to add the newly added ->irq_off() to LLDDs.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
diff -Nrup 02_add_irq_off/drivers/ata/ahci.c
03_add_irq_off_lldd/drivers/ata/ahci.c
--- 02_add_irq_off/drivers/ata/ahci.c 2007-06-01 12:08:21.0 +0800
+++ 03_add_irq_o
Patch 2/9:
Currently there is irq_on() but no irq_off().
Turning irq off is done via altering the nIEN bit of qc->tf, together with
tf_load().
This patch adds irq_off() for symmetry.
tf_load() and ata_qc_set_polling() will be fixed/removed in later patches.
Signed-off-by: Albert Lee <[EMAIL PRO
Patch 1/9:
It looks the calling of irq_on() in ata_bus_reset() and ata_std_postreset()
are leftover of the earlier EDD reset. Remove them.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
diff -Nrup 00_libata-dev/drivers/ata/libata-core.c
01_remove_leftover_irqon/drivers/ata/libata-core.c
---
For ATA, there are two levels of mechanism available to turn irq on/off.
- device level: nIEN bit in the control register. nIEN masks INTRQ from the
device.
- host adapter level: some controller can mask out per-port irq from the host
adapter.
Currently various parts of libata deal with irq on
1/8: fix the ata_altstatus() in ata_hsm_qc_complete()
2/8: move ata_altstatus() from ata_hsm_move() to pio data xfer functions
3/8: change the state after "PIO data-in" to HSM_ST_IDLE instead of HSM_ST_LAST
4/8: move and reduce locking to the pio data xfer functions
5/8: ack possibly unsolicited ir
Tony Breeds wrote:
> The commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc added deadline support to
> prereset and reset methods to libbata the pata_scc driver wasn't converted.
> This patch is a naive attempt to bring this driver up to scratch.
>
> Build failures are:
> drivers/ata/pata_scc.c: In
The commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc added deadline support to
prereset and reset methods to libbata the pata_scc driver wasn't converted.
This patch is a naive attempt to bring this driver up to scratch.
Build failures are:
drivers/ata/pata_scc.c: In function 'scc_pata_prereset':
d
1/7: set the state after "PIO data-in" to HSM_ST_IDLE instead of HSM_ST_LAST
2/7: fix the ata_altstatus() in ata_hsm_qc_complete()
3/7: move ata_altstatus() out from ata_hsm_move() to the pio data xfer functions
4/7: move polling idle irq check to ata_host_intr()
5/7: move and reduce locking to the
All this discussion is well and good, but I suspect there is a driver setup
problem where the interrupt isn't being handled properly. Please retest with
the latest version of skge driver (I just pushed patches to netdev about 2min
ago).
One patch changes to disable IRQ's from device for packets un
On Wed, Mar 14, 2007 at 10:46:47PM +0100, Andi Kleen wrote:
> Tejun Heo <[EMAIL PROTECTED]> writes:
> >
> > Let's assume there's a device which shares its INTX IRQ line with
> > another device and the other one is already initialized. During boot,
> > due to BIOS's fault, bad hardware design or s
> Do you mean between disabling IRQ mechanisms and enabling PCI device in
> pcim_prepare_device()?
Yes.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 15, 2007 at 11:37:20AM +0900, Tejun Heo wrote:
...
> Also, the current implementation doesn't have any arch independent part.
I thnk you meant "arch dependent" here.
> It's wholly contained in arch independent PCI layer, but it might be
> beneficial to have arch dependent hooks (IR
[cc'ing Andi, Hi!]
Hello,
Russell King wrote:
> On Wed, Mar 14, 2007 at 06:34:11PM -0400, Jeff Garzik wrote:
>> Russell King wrote:
>>> pci_enable_device() doesn't deal with this; in most PCI setups I've
>>> seen, there is no control at PCI level over whether a device generates
>>> an interrupt o
Andi Kleen wrote:
Tejun Heo <[EMAIL PROTECTED]> writes:
Let's assume there's a device which shares its INTX IRQ line with
another device and the other one is already initialized. During boot,
due to BIOS's fault, bad hardware design or sheer bad luck, the device
has got a pending IRQ.
This se
Stephen Hemminger wrote:
The problem is the BIOS is busted on these machines. How much effort
do we want to put into dealing with systems with broken BIOS?
I would rather have the root cause fixed than creating a bandaid that
has to be maintained for all the other architectures and platforms.
F
Russell King wrote:
In any case, relying on such a new control bit to implement this kind
of functionality would result in a very hit and miss result; Linux
How does Tejun's patch or thesis rely on this new control bit? He
explicitly mentions DISABLE_INTX variability...
Jeff
-
To
On Wed, Mar 14, 2007 at 06:34:11PM -0400, Jeff Garzik wrote:
> Russell King wrote:
> >pci_enable_device() doesn't deal with this; in most PCI setups I've
> >seen, there is no control at PCI level over whether a device generates
> >an interrupt on the bus. Certainly the memory and io command enable
Russell King wrote:
pci_enable_device() doesn't deal with this; in most PCI setups I've
seen, there is no control at PCI level over whether a device generates
an interrupt on the bus. Certainly the memory and io command enables
PCI grew an interrupt enable while you weren't looking:
PCI_COMMA
On Thu, Mar 15, 2007 at 12:23:02AM +0900, Tejun Heo wrote:
> The problem is that a PCI device can be in any arbitrary when it gets
> enabled and the device has to be enabled for its driver to
> initialize/reset it. The most common case this causes headache is as
> follows.
>
> Let's assume there'
Tejun Heo <[EMAIL PROTECTED]> writes:
>
> Let's assume there's a device which shares its INTX IRQ line with
> another device and the other one is already initialized. During boot,
> due to BIOS's fault, bad hardware design or sheer bad luck, the device
> has got a pending IRQ.
This seems to be a
On Thu, 15 Mar 2007, Tejun Heo wrote:
> Hello, all.
>
> This patch started off from the following thread.
>
> http://thread.gmane.org/gmane.linux.ide/16899
>
> The problem is that a PCI device can be in any arbitrary when it gets
> enabled and the device has to be enabled for its driver to
>
On Thu, 15 Mar 2007 00:23:02 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hello, all.
>
> This patch started off from the following thread.
>
> http://thread.gmane.org/gmane.linux.ide/16899
>
> The problem is that a PCI device can be in any arbitrary when it gets
> enabled and the device has
Hello, all.
This patch started off from the following thread.
http://thread.gmane.org/gmane.linux.ide/16899
The problem is that a PCI device can be in any arbitrary when it gets
enabled and the device has to be enabled for its driver to
initialize/reset it. The most common case this causes he
Hi!
> This patch is the result from the following discussion.
>
> http://thread.gmane.org/gmane.linux.ide/16475
>
> The problem is that CONFIG_PM affects a lot of low level drivers and
> scattering CONFIG_PM all over the place is too ugly. This patch...
>
> * implements __attribute_discard_t
Jeff wrote:
I think we would want to test bit 6 of IDENTIFY DEVICE word 83, issue SET
FEATURES - SPIN UP command if set,
otherwise do a READ VERIFY or some other media access command
The word-2 signature values already give us that information,
and I'm not certain that we can rely upon word 83
Hello, all.
This patch is the result from the following discussion.
http://thread.gmane.org/gmane.linux.ide/16475
The problem is that CONFIG_PM affects a lot of low level drivers and
scattering CONFIG_PM all over the place is too ugly. This patch...
* implements __attribute_discard_text__ an
Mark Lord wrote:
ATA/SATA drives can be set to not spinup automatically at power-on,
for use in staggered spin-up applications where frying power supplies
is to be avoided.
These drives may return incomplete IDENTIFY responses
until they have been spun-up first by the device driver.
There are t
Alan Cox wrote:
(2) The more common method is for the drive to require an explicit
set-features "spin-up" subcommand after the IDENTIFY.
I notice there is no ATA version check - was this feature in all versions
of ATA ?
No, the feature was not in early versions.
But it is not entirely clear t
> (2) The more common method is for the drive to require an explicit
> set-features "spin-up" subcommand after the IDENTIFY.
I notice there is no ATA version check - was this feature in all versions
of ATA ?
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a me
ATA/SATA drives can be set to not spinup automatically at power-on,
for use in staggered spin-up applications where frying power supplies
is to be avoided.
These drives may return incomplete IDENTIFY responses
until they have been spun-up first by the device driver.
There are two ways this happe
Robert Hancock wrote:
> This updates libata FUA support to be more more in line with reality.
> FUA support remains off by default.
>
> Add a setting for the fua command-line parameter on libata which enables
> FUA only on NCQ-supporting disks.
>
> Update the ata_dev_supports_fua function to remo
This updates libata FUA support to be more more in line with reality.
FUA support remains off by default.
Add a setting for the fua command-line parameter on libata which enables
FUA only on NCQ-supporting disks.
Update the ata_dev_supports_fua function to remove the blacklisting of
Maxtor BANC1
Stefan Richter wrote:
Robert Hancock wrote:
http://marc.theaimsgroup.com/?t=11692262122
It looks like Tejun's patch essentially does the same thing as mine with
the addition of the control from userspace. There is one exception
though, my patch also does the stop on removal of the SCSI disk
Robert Hancock wrote:
>> http://marc.theaimsgroup.com/?t=11692262122
>
> It looks like Tejun's patch essentially does the same thing as mine with
> the addition of the control from userspace. There is one exception
> though, my patch also does the stop on removal of the SCSI disk (i.e.
> writi
James Bottomley wrote:
On Mon, 2007-01-29 at 15:47 -0800, Andrew Morton wrote:
What we don't want to happen is for those disks to spin down during a
reboot.
It seems that this is OK with this patch.
Also, we probably don't want them to be spun down during a kexec_load,
but
I expect that's OK to
On Mon, 2007-01-29 at 15:47 -0800, Andrew Morton wrote:
> What we don't want to happen is for those disks to spin down during a
> reboot.
> It seems that this is OK with this patch.
>
> Also, we probably don't want them to be spun down during a kexec_load,
> but
> I expect that's OK too.
Actually
Andrew Morton wrote:
triviata:
--- linux-2.6.20-rc6nv/drivers/scsi/sd.c2007-01-28 17:00:00.0
-0600
+++ linux-2.6.20-rc6nvedit/drivers/scsi/sd.c2007-01-28 18:08:53.0
-0600
@@ -821,6 +821,39 @@ static int sd_sync_cache(struct scsi_dev
return res;
}
+static
On Sun, 28 Jan 2007 19:47:27 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> Here's a patch for sd.c I've cooked up which issues a START STOP UNIT
> command to stop the drive when the SCSI disk is removed or the machine
> is powered down. The rationale behind this is that apparently on many
> dr
Here's a patch for sd.c I've cooked up which issues a START STOP UNIT
command to stop the drive when the SCSI disk is removed or the machine
is powered down. The rationale behind this is that apparently on many
drives, simply cutting power to the spinning disk forces it to do an
emergency head par
On Sat, 18 Nov 2006 00:21:42 +0100
Sylvain Munaut <[EMAIL PROTECTED]> wrote:
> Aside from that, does the driver looks ok ? It has been tested ok on another
> 5200b platform as well. I'd like to include it in a patch set I'll probably
> send next weekend. I'll try to add the timing computation to
Jeff Garzik wrote:
> Sylvain Munaut wrote:
>> Since the current libata doesn't really support overriding IO accessors,
>> I'd keep it like
>> that for now. Apparently some other architecture needs special IO stuff
>> so we could see
>> a way to hook io accessor soon, and then we can change it if we
Sylvain Munaut wrote:
Since the current libata doesn't really support overriding IO accessors,
I'd keep it like
that for now. Apparently some other architecture needs special IO stuff
so we could see
a way to hook io accessor soon, and then we can change it if we notice
big problems.
Sure it do
Alan wrote:
> On Thu, 16 Nov 2006 23:12:19 +0100
> Sylvain Munaut <[EMAIL PROTECTED]> wrote:
>
>
>> * The manual states we should check for the TIP bit before all
>> PIO transaction. That's not really supported by libata and requires
>> reimplementing almost all the hooks. But after talking to F
Jarno Manninen wrote:
> On Friday 17 November 2006 00:12, Sylvain Munaut wrote:
>
>
>> * The manual states we should check for the TIP bit before all
>> PIO transaction. That's not really supported by libata and requires
>> reimplementing almost all the hooks. But after talking to Freescale,
>>
On Friday 17 November 2006 00:12, Sylvain Munaut wrote:
> * The manual states we should check for the TIP bit before all
> PIO transaction. That's not really supported by libata and requires
> reimplementing almost all the hooks. But after talking to Freescale,
> it turnsout it's not really necess
On Thu, 16 Nov 2006 23:12:19 +0100
Sylvain Munaut <[EMAIL PROTECTED]> wrote:
> * The manual states we should check for the TIP bit before all
> PIO transaction. That's not really supported by libata and requires
> reimplementing almost all the hooks. But after talking to Freescale,
> it turnsout i
This is the first attempt at a libata driver for this controller.
The two main issues :
* The manual states we should check for the TIP bit before all
PIO transaction. That's not really supported by libata and requires
reimplementing almost all the hooks. But after talking to Freescale,
it turnsou
On Fri, 09 Sep 2005 13:35:25 EDT, Jeff Garzik wrote:
>Albert Lee wrote:
>> Dear all,
>>
>> The interrupt driven PIO draft patch is ready for your review.
>>
>> Changes:
>> - add PIO_ST_FIRST for the state before sending ATAPI CDB or sending
>> "ATA PIO data out" first data block.
>> - remove th
Albert Lee wrote:
Dear all,
The interrupt driven PIO draft patch is ready for your review.
Changes:
- add PIO_ST_FIRST for the state before sending ATAPI CDB or sending
"ATA PIO data out" first data block.
- remove the ATA_FLAG_NOINTR flag since the interrupt handler is now
aware of the state
Dear all,
The interrupt driven PIO draft patch is ready for your review.
Changes:
- add PIO_ST_FIRST for the state before sending ATAPI CDB or sending
"ATA PIO data out" first data block.
- remove the ATA_FLAG_NOINTR flag since the interrupt handler is now
aware of the states
- modify ata_pio_
Resubmit since the offset changed by patch 4/5.
Also changed printk() in previous patch to DPRINTK().
Albert
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
--- libata-2.6-extrabytes/drivers/scsi/libata-core.c2005-03-29
20:23:24.0 +0800
+++ libata-
Hi Jeff,
Problem:
When testing the k3b CD burning program, k3b issued a request (read TOC) with
81 bytes of buff length.
The CD-RW device didn't like it and returned 82 bytes of data. Detailed log
below:
Mar 17 02:18:56 plinuxt01 kernel: ata_scsi_dump_cdb: CDB (1:0,0,0) 43 00 02 00
00 00 01 00
Bartlomiej,
I did a fresh check out of linux-2.6 and diff'd? That's strange ...
Anyhow, how about "Fixes to IDE hwif initialization error handling".
IMO it better captures what I'm trying to fix :)
P.
No problem, I can hand-merge this patch but these changes
need some description, "fix hwif_init(
On Tue, 08 Feb 2005 10:53:56 -0500, Prarit Bhargava <[EMAIL PROTECTED]> wrote:
> Bartlomiej pointed out that the sgiioc4.c changes have made their way
all changes
> into Linus' tree.
>
> Here's an updated change set.
>
> Thanks,
>
> P.
>
Bartlomiej pointed out that the sgiioc4.c changes have made their way
into Linus' tree.
Here's an updated change set.
Thanks,
P.
Signed-off-by: Prarit Bhargava <[EMAIL PROTECTED]>
= ide-probe.c 1.90 vs edited =
--- 1.90/drivers/ide/ide-probe.c2004-12-10 14:12:14 -05:00
+++ edited
Thanks for the comments Bartlomiej -- your input is always appreciated.
Here's a new patch taking into account your comments. I have updated
hwif_init
to return 0 on success and -errno on failure.
Thanks again,
P.
Signed-off-by: Prarit Bhargava <[EMAIL PROTECTED]>
= ide-probe.c 1.90 vs edit
On Wed, 26 Jan 2005 08:25:04 -0500, Prarit Bhargava <[EMAIL PROTECTED]> wrote:
> I didn't see any ACKs on this so I'm resubmitting
sorry for the delay
> I discovered an issue where a hwif_init failure lead to /proc/ide files
> being created for devices that failed probes. This resulted in
c
I didn't see any ACKs on this so I'm resubmitting
I discovered an issue where a hwif_init failure lead to /proc/ide files
being created for devices that failed probes. This resulted in
oops/WARN_ON/BUG_ON executions through the kernel depending on what
actions were on going.
The first part
94 matches
Mail list logo
