Now that ATAPI support is pretty stable, the 2.4 version of libata will
be receiving its final updates soon. Here is the current backport,
for testing and feedback.
Please report problems -- particularly any regressions -- to
[email protected]. I may not be able to respond personally
to each and every bug report, but rest assured all feedback is noted.
Sometimes, solutions only become apparent after a few people report the
same problem.
The 'combined' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-2.4.git
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.4.32-libata1.patch.bz2
(available as soon as kernel.org mirrors catch up)
contains the following updates:
drivers/pci/quirks.c | 86 ++
drivers/scsi/ahci.c | 305 ++++---
drivers/scsi/ata_piix.c | 136 +--
drivers/scsi/libata-core.c | 1743 +++++++++++++++++++++++++++---------------
drivers/scsi/libata-scsi.c | 1635 ++++++++++++++++++++++++++++++---------
drivers/scsi/libata.h | 68 -
drivers/scsi/sata_nv.c | 86 +-
drivers/scsi/sata_promise.c | 166 ++--
drivers/scsi/sata_promise.h | 33
drivers/scsi/sata_qstor.c | 114 +-
drivers/scsi/sata_sil.c | 100 +-
drivers/scsi/sata_sis.c | 146 ++-
drivers/scsi/sata_svw.c | 85 +-
drivers/scsi/sata_sx4.c | 292 +++----
drivers/scsi/sata_uli.c | 66 -
drivers/scsi/sata_via.c | 110 +-
drivers/scsi/sata_vsc.c | 79 +
include/linux/ata.h | 86 +-
include/linux/ioport.h | 1
include/linux/libata-compat.h | 102 ++
include/linux/libata.h | 264 ++++--
include/linux/pci_ids.h | 6
include/scsi/scsi.h | 4
kernel/ksyms.c | 1
kernel/resource.c | 10
25 files changed, 3957 insertions(+), 1767 deletions(-)
Jeff Garzik:
[libata] resync with kernel 2.6.13
[libata sata_sx4] trim trailing whitespace
[libata] resync with 2.6.14
[libata] resync with 2.6.15-rc3
[libata] fix build
[libata] combined mode support, using ugly ____request_resource() hack
[libata] fix potential oops in pdev_printk() compat helper
On Thu Dec 01, 2005 at 04:48:37PM -0500, Jeff Garzik wrote:
>
> Now that ATAPI support is pretty stable, the 2.4 version of libata will
> be receiving its final updates soon. Here is the current backport,
> for testing and feedback.
Awesome. 2.4.x lacks KM_IRQ0 in kmap_types.h
gcc -D__KERNEL__ -I/usr/src/linux-2.4.32/include -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fomit-frame-pointer -Os -falign-functions=2 -falign-jumps=2 -falign-labels=2 -falign-loops=2 -pipe -mpreferred-stack-boundary=2 -march=i486 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=libata_core -DEXPORT_SYMTAB -c libata-core.c
libata-core.c: In function `ata_sg_clean':
libata-core.c:2427: error: `KM_IRQ0' undeclared (first use in this function)
libata-core.c:2427: error: (Each undeclared identifier is reported only once
libata-core.c:2427: error: for each function it appears in.)
libata-core.c: In function `ata_sg_setup':
libata-core.c:2701: error: `KM_IRQ0' undeclared (first use in this function)
make[2]: *** [libata-core.o] Error 1
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Erik Andersen wrote:
> On Thu Dec 01, 2005 at 04:48:37PM -0500, Jeff Garzik wrote:
>
>>Now that ATAPI support is pretty stable, the 2.4 version of libata will
>>be receiving its final updates soon. Here is the current backport,
>>for testing and feedback.
>
>
> Awesome. 2.4.x lacks KM_IRQ0 in kmap_types.h
>
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.32/include -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fomit-frame-pointer -Os -falign-functions=2 -falign-jumps=2 -falign-labels=2 -falign-loops=2 -pipe -mpreferred-stack-boundary=2 -march=i486 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=libata_core -DEXPORT_SYMTAB -c libata-core.c
> libata-core.c: In function `ata_sg_clean':
> libata-core.c:2427: error: `KM_IRQ0' undeclared (first use in this function)
> libata-core.c:2427: error: (Each undeclared identifier is reported only once
> libata-core.c:2427: error: for each function it appears in.)
> libata-core.c: In function `ata_sg_setup':
> libata-core.c:2701: error: `KM_IRQ0' undeclared (first use in this function)
> make[2]: *** [libata-core.o] Error 1
hmmm, interesting. Easy enough to fix. I guess I didn't build on a
highmem box.
Jeff
Hi Jeff,
On Thu, Dec 01, 2005 at 08:41:01PM -0500, Jeff Garzik wrote:
> Erik Andersen wrote:
> >On Thu Dec 01, 2005 at 04:48:37PM -0500, Jeff Garzik wrote:
> >
> >>Now that ATAPI support is pretty stable, the 2.4 version of libata will
> >>be receiving its final updates soon. Here is the current backport,
> >>for testing and feedback.
> >
> >
> >Awesome. 2.4.x lacks KM_IRQ0 in kmap_types.h
> >
> >gcc -D__KERNEL__ -I/usr/src/linux-2.4.32/include -Wall
> >-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
> >-fomit-frame-pointer -Os -falign-functions=2 -falign-jumps=2
> >-falign-labels=2 -falign-loops=2 -pipe -mpreferred-stack-boundary=2
> >-march=i486 -DMODULE -nostdinc -iwithprefix include
> >-DKBUILD_BASENAME=libata_core -DEXPORT_SYMTAB -c libata-core.c
> >libata-core.c: In function `ata_sg_clean':
> >libata-core.c:2427: error: `KM_IRQ0' undeclared (first use in this
> >function)
> >libata-core.c:2427: error: (Each undeclared identifier is reported only
> >once
> >libata-core.c:2427: error: for each function it appears in.)
> >libata-core.c: In function `ata_sg_setup':
> >libata-core.c:2701: error: `KM_IRQ0' undeclared (first use in this
> >function)
> >make[2]: *** [libata-core.o] Error 1
>
> hmmm, interesting. Easy enough to fix. I guess I didn't build on a
> highmem box.
Same problem for me, but unfortunately, I don't know how to fix this. I've
seen that KM_IRQ* are not defined on x86. I don't know if I can use other
ones, not what would be the consequences. Would you please enlighten me a
bit on this, I'm willing to test it but don't know how to build it first.
Thanks in advance,
Willy
Hi Jeff,
On Sun, Dec 04, 2005 at 04:59:11PM +0100, Willy Tarreau wrote:
> > >libata-core.c:2427: error: for each function it appears in.)
> > >libata-core.c: In function `ata_sg_setup':
> > >libata-core.c:2701: error: `KM_IRQ0' undeclared (first use in this
> > >function)
> > >make[2]: *** [libata-core.o] Error 1
> >
> > hmmm, interesting. Easy enough to fix. I guess I didn't build on a
> > highmem box.
>
> Same problem for me, but unfortunately, I don't know how to fix this. I've
> seen that KM_IRQ* are not defined on x86. I don't know if I can use other
> ones, not what would be the consequences. Would you please enlighten me a
> bit on this, I'm willing to test it but don't know how to build it first.
Well, after finding a good doc on kmap_atomic on lwn.net, I think I
understood how to fix this. I grepped the whole kernel for kmap_atomic()
and found that KM_BIO_IRQ was only used by ntfs, which had a comment
stating that it was used to support highmem. So I thought we could share
the same type and rediffed the patch, and now the kernel builds.
Here is my proposal, I hope it's correct.
Cheers,
Willy
diff -urN linux-2.4.32-libata1/drivers/scsi/libata-core.c linux-2.4.32-libata1-highmem/drivers/scsi/libata-core.c
--- linux-2.4.32-libata1/drivers/scsi/libata-core.c 2005-12-04 16:32:33.000000000 +0100
+++ linux-2.4.32-libata1-highmem/drivers/scsi/libata-core.c 2005-12-04 18:37:28.000000000 +0100
@@ -2424,9 +2424,9 @@
sg[qc->orig_n_elem - 1].length += qc->pad_len;
if (pad_buf) {
struct scatterlist *psg = &qc->pad_sgent;
- void *addr = kmap_atomic(psg->page, KM_IRQ0);
+ void *addr = kmap_atomic(psg->page, KM_BIO_IRQ);
memcpy(addr + psg->offset, pad_buf, qc->pad_len);
- kunmap_atomic(psg->page, KM_IRQ0);
+ kunmap_atomic(psg->page, KM_BIO_IRQ);
}
} else {
if (sg_dma_len(&sg[0]) > 0)
@@ -2698,9 +2698,9 @@
psg->offset = offset_in_page(offset);
if (qc->tf.flags & ATA_TFLAG_WRITE) {
- void *addr = kmap_atomic(psg->page, KM_IRQ0);
+ void *addr = kmap_atomic(psg->page, KM_BIO_IRQ);
memcpy(pad_buf, addr + psg->offset, qc->pad_len);
- kunmap_atomic(psg->page, KM_IRQ0);
+ kunmap_atomic(psg->page, KM_BIO_IRQ);
}
sg_dma_address(psg) = ap->pad_dma + (qc->tag * ATA_DMA_PAD_SZ);
Hi Again,
sorry for the noise. I applied this patch on an already patched
kernel. KM_BIO_IRQ does not exist on vanilla 2.4.32. However,
KM_SOFTIRQ0 is not used, so here is the patch reworked to use
that instead.
Regards,
Willy
diff -urN linux-2.4.32-libata1/drivers/scsi/libata-core.c linux-2.4.32-libata1-highmem/drivers/scsi/libata-core.c
--- linux-2.4.32-libata1/drivers/scsi/libata-core.c 2005-12-04 16:32:33.000000000 +0100
+++ linux-2.4.32-libata1-highmem/drivers/scsi/libata-core.c 2005-12-04 18:37:28.000000000 +0100
@@ -2424,9 +2424,9 @@
sg[qc->orig_n_elem - 1].length += qc->pad_len;
if (pad_buf) {
struct scatterlist *psg = &qc->pad_sgent;
- void *addr = kmap_atomic(psg->page, KM_IRQ0);
+ void *addr = kmap_atomic(psg->page, KM_SOFTIRQ0);
memcpy(addr + psg->offset, pad_buf, qc->pad_len);
- kunmap_atomic(psg->page, KM_IRQ0);
+ kunmap_atomic(psg->page, KM_SOFTIRQ0);
}
} else {
if (sg_dma_len(&sg[0]) > 0)
@@ -2698,9 +2698,9 @@
psg->offset = offset_in_page(offset);
if (qc->tf.flags & ATA_TFLAG_WRITE) {
- void *addr = kmap_atomic(psg->page, KM_IRQ0);
+ void *addr = kmap_atomic(psg->page, KM_SOFTIRQ0);
memcpy(pad_buf, addr + psg->offset, qc->pad_len);
- kunmap_atomic(psg->page, KM_IRQ0);
+ kunmap_atomic(psg->page, KM_SOFTIRQ0);
}
sg_dma_address(psg) = ap->pad_dma + (qc->tag * ATA_DMA_PAD_SZ);