Bartlomiej Zolnierkiewicz wrote:
Based on the previous work by Tejun Heo.
There should be no functionality changes caused by this patch.
I didn't get the point. Why do you consider them "empty"?
Cc: Tejun Heo <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTE
Bartlomiej Zolnierkiewicz wrote:
Index: b/drivers/ide/ide-io.c
===
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -638,17 +638,18 @@ static ide_startstop_t drive_cmd_intr (i
{
struct request *rq = HWGROUP(drive)->r
Bartlomiej Zolnierkiewicz wrote:
* Rename init_hwif_data() to ide_init_port_data() and export it.
* For all users of ide_register_hw() with 'initializing' argument set
hwif->present and hwif->hold are always zero so convert these host
drivers to use ide_find_port()+ide_init_port_data()+ide_
Hi,
On Thursday 13 December 2007, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> >>>* Rename init_hwif_data() to ide_init_port_data() and export it.
>
> >>>* For all users of ide_register_hw() with 'initializing' argument set
> >>> hwif->present and hwif->hold are always zero so
On Thursday 13 December 2007, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> > Based on the previous work by Tejun Heo.
>
> > There should be no functionality changes caused by this patch.
>
> I didn't get the point. Why do you consider them "empty"?
These requests don't have
Mikael Pettersson wrote:
On Thu, 15 Nov 2007 12:32:14 +0900, Tejun Heo wrote:
* sata_promise: Generally works okay; however there are still some
problems with recent 3Gbps chips. (Mikael, please pitch in)
Right, 2nd-gen 3Gbps chips have had "intermittent" issues,
which we hope are cured by the
Patric Karlsson writes:
> Mikael Pettersson wrote:
> > On Thu, 15 Nov 2007 12:32:14 +0900, Tejun Heo wrote:
> >> * sata_promise: Generally works okay; however there are still some
> >> problems with recent 3Gbps chips. (Mikael, please pitch in)
> >
> > Right, 2nd-gen 3Gbps chips have had "in
>
> I really think that a lot of the new variable/macro/enum names are overly
> long,
> making the code a bit harder to read.
> The patch is all about "System On Chip (SOC)" support,
> yet the names all say "INTEGRATED".
well, many socs have SATA or Ethernet controllers as pci controller,
but in t
Bartlomiej Zolnierkiewicz wrote:
* Rename init_hwif_data() to ide_init_port_data() and export it.
* For all users of ide_register_hw() with 'initializing' argument set
hwif->present and hwif->hold are always zero so convert these host
drivers to use ide_find_port()+ide_init_port_data()+id
saeed bishara wrote:
I really think that a lot of the new variable/macro/enum names are overly long,
making the code a bit harder to read.
The patch is all about "System On Chip (SOC)" support,
yet the names all say "INTEGRATED".
well, many socs have SATA or Ethernet controllers as pci controlle
On 2007-12-13 15:09, Mikael Pettersson wrote:
Patric Karlsson writes:
> Mikael Pettersson wrote:
> > On Thu, 15 Nov 2007 12:32:14 +0900, Tejun Heo wrote:
> >> * sata_promise: Generally works okay; however there are still some
> >> problems with recent 3Gbps chips. (Mikael, please pitch in)
>
Jens,
I'm experimenting here with trying to generate large I/O through libata,
and not having much luck.
The limit seems to be the number of hardware PRD (SG) entries permitted
by the driver (libata:ata_piix), which is 128 by default.
The problem is, the block layer *never* sends an SG entry la
(resending with corrected email address for Jens)
Jens,
I'm experimenting here with trying to generate large I/O through libata,
and not having much luck.
The limit seems to be the number of hardware PRD (SG) entries permitted
by the driver (libata:ata_piix), which is 128 by default.
The probl
On Thu, Dec 13, 2007 at 01:37:59PM -0500, Mark Lord wrote:
> The problem is, the block layer *never* sends an SG entry larger than 8192
> bytes,
> and even that size is exceptionally rare. Nearly all I/O segments are 4096
> bytes,
> so I never see a single I/O larger than 512KB (128 * 4096).
>
On Thu, 2007-12-13 at 11:42 -0700, Matthew Wilcox wrote:
> On Thu, Dec 13, 2007 at 01:37:59PM -0500, Mark Lord wrote:
> > The problem is, the block layer *never* sends an SG entry larger than 8192
> > bytes,
> > and even that size is exceptionally rare. Nearly all I/O segments are 4096
> > byte
Mark Lord wrote:
(resending with corrected email address for Jens)
Jens,
I'm experimenting here with trying to generate large I/O through libata,
and not having much luck.
The limit seems to be the number of hardware PRD (SG) entries permitted
by the driver (libata:ata_piix), which is 128 by d
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
> Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
> libata,
> but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
Just a suspicion ... could this be slab vs slub? ie check your configs
are the same / simi
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
Just a suspicion ... could this be slab vs slub? ie check your configs
On Thu, Dec 13 2007, Mark Lord wrote:
> Matthew Wilcox wrote:
> >On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
> >>Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
> >>libata,
> >>but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
> >
> >Just a suspici
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
Just a suspici
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to
64KB for libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB segment
On Thu, Dec 13 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Thu, Dec 13 2007, Mark Lord wrote:
> >>Matthew Wilcox wrote:
> >>>On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
> Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB
> for libata,
> but 2.6.24
On Thu, Dec 13 2007, Mark Lord wrote:
> Mark Lord wrote:
> >Jens Axboe wrote:
> >>On Thu, Dec 13 2007, Mark Lord wrote:
> >>>Matthew Wilcox wrote:
> On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
> >Problem confirmed. 2.6.23.8 regularly generates segments up to
> >64KB for
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to
64KB for libata,
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
Just a suspici
On Thu, Dec 13 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Thu, Dec 13 2007, Mark Lord wrote:
> >>Mark Lord wrote:
> >>>Jens Axboe wrote:
> On Thu, Dec 13 2007, Mark Lord wrote:
> >Matthew Wilcox wrote:
> >>On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
> >>>Problem
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.
On Thu, Dec 13 2007, Jens Axboe wrote:
> On Thu, Dec 13 2007, Mark Lord wrote:
> > Jens Axboe wrote:
> > >On Thu, Dec 13 2007, Mark Lord wrote:
> > >>Mark Lord wrote:
> > >>>Jens Axboe wrote:
> > On Thu, Dec 13 2007, Mark Lord wrote:
> > >Matthew Wilcox wrote:
> > >>On Thu, Dec 13, 2007
On Thu, Dec 13 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Thu, Dec 13 2007, Mark Lord wrote:
> >>Jens Axboe wrote:
> >>>On Thu, Dec 13 2007, Mark Lord wrote:
> Mark Lord wrote:
> >Jens Axboe wrote:
> >>On Thu, Dec 13 2007, Mark Lord wrote:
> >>>Matthew Wilcox wrote:
>
Jens Axboe wrote:
On Thu, Dec 13 2007, Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, M
On Thu, Dec 13 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Thu, Dec 13 2007, Jens Axboe wrote:
> >>On Thu, Dec 13 2007, Mark Lord wrote:
> >>>Jens Axboe wrote:
> On Thu, Dec 13 2007, Mark Lord wrote:
> >Mark Lord wrote:
> >>Jens Axboe wrote:
> >>>On Thu, Dec 13 2007, Mark Lord
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew
Mark Lord wrote:
Jens Axboe wrote:
..
OK, it's a vm issue, I have tens of thousand "backward" pages after a
boot - IOW, bvec->bv_page is the page before bvprv->bv_page, not
reverse. So it looks like that bug got reintroduced.
...
Mmm.. shouldn't one of the front- or back- merge logics work fo
On Thu, Dec 13 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Thu, Dec 13 2007, Mark Lord wrote:
> >>Jens Axboe wrote:
> >>>On Thu, Dec 13 2007, Jens Axboe wrote:
> On Thu, Dec 13 2007, Mark Lord wrote:
> >Jens Axboe wrote:
> >>On Thu, Dec 13 2007, Mark Lord wrote:
> >>>Mark Lord
On Wed, 12 Dec 2007 15:38:15 -0500 (EST), Kiyoshi Ueda <[EMAIL PROTECTED]>
wrote:
> On Tue, 11 Dec 2007 15:48:03 -0800, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > > - end_that_request_first(rq, uptodate, rq->hard_nr_sectors);
> > > - end_that_request_last(rq, uptodate);
> > > + if (__blk_end_req
On Thu, Dec 13, 2007 at 09:09:59PM +0100, Jens Axboe wrote:
> > >diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
> > >index e30b1a4..1e34b6f 100644
> > >--- a/block/ll_rw_blk.c
> > >+++ b/block/ll_rw_blk.c
> > >@@ -1349,6 +1351,8 @@ new_segment:
> > > sg = sg_next(sg);
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> OK, it's a vm issue,
cc linux-mm and probable culprit.
> I have tens of thousand "backward" pages after a
> boot - IOW, bvec->bv_page is the page before bvprv->bv_page, not
> reverse. So it looks like that bug got rein
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
> On Thu, 13 Dec 2007 21:09:59 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> >
> > OK, it's a vm issue,
>
> cc linux-mm and probable culprit.
>
> > I have tens of thousand "backward" pages after a
> > boot - IOW, bvec->bv_page is the
Tejun Heo wrote:
Bill Davidsen wrote:
Jan Engelhardt wrote:
On Dec 1 2007 06:26, Justin Piszcz wrote:
I ran the following:
dd if=/dev/zero of=/dev/sdc
dd if=/dev/zero of=/dev/sdd
dd if=/dev/zero of=/dev/sde
(as it is always a very good idea to do this with any new disk)
On Thu, Dec 13 2007, Andrew Morton wrote:
> On Thu, 13 Dec 2007 21:09:59 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> >
> > OK, it's a vm issue,
>
> cc linux-mm and probable culprit.
>
> > I have tens of thousand "backward" pages after a
> > boot - IOW, bvec->bv_page is the page before bvp
Andrew Morton wrote:
On Thu, 13 Dec 2007 17:15:06 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe <[EMAIL PROTECTED]> wrote:
OK, it's a vm issue,
cc linux-mm and probable culprit.
I hav
On Thu, 13 Dec 2007 17:15:06 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
> > On Thu, 13 Dec 2007 21:09:59 +0100
> > Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > OK, it's a vm issue,
> >
> > cc linux-mm and probable culpri
I am working on a driver for the CD Rom drive on the Sega Dreamcast
(the so-called "GD Rom" drive). This device is electorically
compatible with IDE-3 devices and has a pretty good match in terms of
the control block registers but it implements its own packet command
interface.
I now have a workin
Mark Lord wrote:
Andrew Morton wrote:
On Thu, 13 Dec 2007 17:15:06 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe <[EMAIL PROTECTED]> wrote:
OK, it's a vm issue,
cc linux-mm and probable
Mark Lord wrote:
Mark Lord wrote:
Andrew Morton wrote:
On Thu, 13 Dec 2007 17:15:06 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe <[EMAIL PROTECTED]> wrote:
OK, it's a vm issue,
cc lin
From: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Implement Enclosure Management via the LED protocol. See the AHCI 1.1 spec
for details.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Tejun Heo <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTE
From: "Konstantin A. Lepikhov" <[EMAIL PROTECTED]>
ata1.00: exception Emask 0x2 SAct 0x1 SErr 0x0 action 0x2 frozen
ata1.00: spurious completions during NCQ issue=0x0 SAct=0x1
FIS=004040a1:0020
ata1.00: cmd 60/70:00:83:a6:f0/00:00:04:00:00/40 tag 0 cdb 0x0 data 57344 in
Device Model: TOS
From: Andrew Morton <[EMAIL PROTECTED]>
WARNING: line over 80 characters
#36: FILE: drivers/ata/pata_bf54x.c:1512:
+ while (bfin_port_info[board_idx].udma_mask>0 && udma_fsclk[udma_mode] >
fsclk) {
ERROR: need spaces around that '>' (ctx:VxV)
#36: FILE: drivers/ata/pata_bf54x.c:1512:
+
From: Andrew Morton <[EMAIL PROTECTED]>
drivers/ata/libata-eh.c: In function `ata_port_pbar_desc':
drivers/ata/libata-eh.c:215: warning: long long unsigned int format, long
unsigned int arg (arg 4)
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers
From: Andrew Morton <[EMAIL PROTECTED]>
WARNING: line over 80 characters
#70: FILE: drivers/ata/pata_hpt37x.c:850:
+ struct pci_dev *pdev_0 = pci_get_slot(pdev->bus, pdev->devfn -
1);
ERROR: else should follow close brace '}'
#78: FILE: drivers/ata/pata_hpt37x.c:858:
+ }
+
From: Tejun Heo <[EMAIL PROTECTED]>
xfer_mask is unsigned int not unsigned long. Change ->mode_filter to
take and return unsigned int.
While at it, rename @adev of ata_pci_default_filter() to @dev for
consistency.
[EMAIL PROTECTED]: fix types]
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Signed
From: Andrew Morton <[EMAIL PROTECTED]>
total: 0 errors, 0 warnings, 15 lines checked
Your patch has no obvious style problems and is ready for submission.
Please run checkpatch prior to sending patches
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Tejun Heo <[EMAIL P
From: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/ata/pata_pcmcia.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff -puN
drivers/ata/pata_pcmcia.c~pata_pcmci
From: Alan Cox <[EMAIL PROTECTED]>
Rework the pata_legacy driver to have an internal way to plug multiple
legacy interface types and designs into the driver.
This driver supports
- Generic legacy ISA on primary/secondary and tertiary ports
- BIOS or jumper configured legacy ports
On Thu, 2007-12-13 at 19:46 -0500, Mark Lord wrote:
> "Improved version", more similar to the 2.6.23 code:
>
> Fix page allocator to give better chance of larger contiguous segments
> (again).
>
> Signed-off-by: Mark Lord <[EMAIL PROTECTED]
> ---
>
> --- old/mm/page_alloc.c 2007-12-13 19
"Improved version", more similar to the 2.6.23 code:
Fix page allocator to give better chance of larger contiguous segments (again).
Signed-off-by: Mark Lord <[EMAIL PROTECTED]
---
--- old/mm/page_alloc.c 2007-12-13 19:25:15.0 -0500
+++ linux-2.6/mm/page_alloc.c 2007-12-13 19:43:07.0
Mark Lord wrote:
Mark Lord wrote:
Mark Lord wrote:
Andrew Morton wrote:
On Thu, 13 Dec 2007 17:15:06 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe <[EMAIL PROTECTED]> wrote:
OK, it's a
On Thu, 13 Dec 2007 19:30:00 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
> Here's the commit that causes the regression:
>
> ...
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -760,7 +760,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int
> order,
> struct page *pa
Mark Lord wrote:
Mark Lord wrote:
Mark Lord wrote:
Mark Lord wrote:
Andrew Morton wrote:
On Thu, 13 Dec 2007 17:15:06 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe <[EMAIL PROTECTED]> w
Andrew Morton wrote:
On Thu, 13 Dec 2007 19:30:00 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
Here's the commit that causes the regression:
...
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -760,7 +760,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int
order,
struct
Mark Lord wrote:
Andrew Morton wrote:
On Thu, 13 Dec 2007 19:30:00 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
Here's the commit that causes the regression:
...
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -760,7 +760,8 @@ static int rmqueue_bulk(struct zone *zone,
unsigned int order,
On Thu, 13 Dec 2007 19:40:09 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
> And here is a patch that seems to fix it for me here:
>
> * * * *
>
> Fix page allocator to give better change of larger contiguous segments
> (again).
>
> Signed-off-by: Mark Lord <[EMAIL PROTECTED]
> ---
>
>
> --- ol
On Thu, 13 Dec 2007 19:57:29 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-12-13 at 19:46 -0500, Mark Lord wrote:
> > "Improved version", more similar to the 2.6.23 code:
> >
> > Fix page allocator to give better chance of larger contiguous segments
> > (again).
> >
> > Sig
Andrew Morton wrote:
On Thu, 13 Dec 2007 19:57:29 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
On Thu, 2007-12-13 at 19:46 -0500, Mark Lord wrote:
"Improved version", more similar to the 2.6.23 code:
Fix page allocator to give better chance of larger contiguous segments (again).
Signed-o
On Thu, Dec 13, 2007 at 05:03:08PM -0800, Andrew Morton wrote:
> + /*
> + * Find a page of the appropriate migrate type. Doing a
> + * reverse-order search here helps us to hand out pages in
> + * ascending physical-address order.
> +
[EMAIL PROTECTED] wrote:
> From: "Konstantin A. Lepikhov" <[EMAIL PROTECTED]>
>
> ata1.00: exception Emask 0x2 SAct 0x1 SErr 0x0 action 0x2 frozen
> ata1.00: spurious completions during NCQ issue=0x0 SAct=0x1
> FIS=004040a1:0020
> ata1.00: cmd 60/70:00:83:a6:f0/00:00:04:00:00/40 tag 0 cdb 0x0
This is the listing of open bugs that are not new time wise, mostly
over a month old, which is a long time for current rate of
development.
Most bugs need initial response, and all need attention (tlc).
It would be appreciated if the corresponding maintenance team could
take a look at the bugs, clo
Hello, all.
During 2.6.24-rc1, libata enabled ATA-ACPI support by default and there
have been a lot of regression reports stemming from it. I have patchset
ready to fix most of the problems. With these patches applied, libata
should be able to cope with most failures pretty well. There is one
r
Tejun Heo wrote:
Hello, all.
During 2.6.24-rc1, libata enabled ATA-ACPI support by default and there
have been a lot of regression reports stemming from it. I have patchset
ready to fix most of the problems. With these patches applied, libata
should be able to cope with most failures pretty we
Hello,
This patchset contains the following patches to improve ACPI corner
case handling.
0001-libata-drop-const-from-struct-ata_port-param-on-ata.patch
0002-libata-update-ata_-_printk-macros-such-that-level.patch
0003-libata-add-more-opcodes-to-ata.h.patch
0004-libata-implement-ata_acpi_
Add dev->__acpi_init_gtm and store initial GTM values on host
initialization. If the field is valid, ata_acpi_init_gtm() returns
pointer to the saved GTM structure; otherwise, NULL. This is to
remember BIOS/firmware programmed initial timing for later use before
reset and mode configuration modif
Add constants for DEVICE CONFIGURATION OVERLAY and SET_MAX to
include/linux/ata.h.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
include/linux/ata.h | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/include/linux/ata.h b/include/linux/ata.h
index 5c4e54a..
No other libata interface function takes const ata_port. Drop them
from ata_acpi_gtm/stm().
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-acpi.c |4 ++--
include/linux/libata.h|4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/li
Make prink helpers format @lv together rather than prepending to the
format string as constant.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
include/linux/libata.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/libata.h b/include/linux/libata.h
i
* If _GTF evalution fails, it's pointless to retry. Just disable ATA
ACPI.
* After disabling ACPI, return success iff the number of executed _GTF
command equals zero. Otherwise, tell EH to retry. This change
fixes bogus 1 return bug where ata_acpi_on_devcfg() expects the
caller to reloa
As _GTF commands can't transfer data, device error never signals
transfer error. It indicates that the device vetoed the operation, so
it's meaningless to retry.
This patch makes libata-acpi to report and continue on device errors
when executing _GTF commands. Also commands rejected by device do
Implement _GTF command filtering which can be controlled by
libata.acpi_filter kernel parameter and filter LOCK commands using it.
DCO FREEZE LOCK, SECURITY FREEZE LOCK and SET MAX [FREEZE] LOCK are
filtered by default.
Note that detecting SET MAX LOCK requires looking at the previous
command. Th
Don't fail suspend because of _GTM failure. This might eventually
cause _GTF evaluation failure during resume but that's better than
failing suspend.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-acpi.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
dif
ata_acpi_cbl_80wire() is called from cable detection where transfer
spped is forced to PIO0 after resetting. On some controllers, this
results in incorrect result or ACPI evaluation failure. Use cached
initial _GTM value.
This is partial fix for 2.6.24. More extensive update to ACPI mode
filter
Robert Hancock wrote:
>> Problem is that _GTM implementation on certain BIOSen crap themselves if
>> invoked on empty channels. However, as written above, because initial
>> _GTM caching is done before any actual operation is performed on the
>> port, libata can't determine whether the port is occ
Tejun Heo wrote:
> Hello,
>
> This patchset contains the following patches to improve ACPI corner
> case handling.
I'm working on an improved version. Please hold a bit. Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL
81 matches
Mail list logo
