Skip to contentSkip to conversation

dma_addr_t: which comment is correct?

DISCUSSION rubisher 3 participants 8 messages Dec 22, 2007 – Dec 28, 2007 PA-RISC architecture

lore
Share & tools
lore

rubisher

author
#0 lore raw

Hello *,

Continuing my blind investigation on ccio-dma stuff, I read those 2 different comments:
in include/asm-parisc/scatterlist.h, scartterlist structure is defined like this:
struct scatterlist {

#ifdef CONFIG_DEBUG_SG
        unsigned long sg_magic;
#endif
        unsigned long page_link;
        unsigned int offset;

        unsigned int length;

        /* an IOVA can be 64-bits on some PA-Risc platforms. */
        dma_addr_t iova;        /* I/O Virtual Address */
        __u32      iova_length; /* bytes mapped */
};

in absolute the comment "an IOVA can be 64-bits on some PA-Risc platforms." seems ok.

but otoh, include/asm-parisc/types.h, defined dma_addr_t like this:

/* Dma addresses are 32-bits wide. */

typedef u32 dma_addr_t;
typedef u64 dma64_addr_t;

#endif /* __ASSEMBLY__ */

OK it's just a comment but imho there is interesting matter in x86:

typedef u64 dma64_addr_t;
#if defined(CONFIG_X86_64) || defined(CONFIG_HIGHMEM64G) /* DMA addresses come in 32-bit and 64-bit flavours. */ typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
#endif

But I simply have no idea which "#if defined" would be the most relevant for parisc, any idea?

Cheers,

	r.
#1 lore raw
Quoted 20 lines · rubisher

Hello *,

Continuing my blind investigation on ccio-dma stuff, I read those 2 different comments:
in include/asm-parisc/scatterlist.h, scartterlist structure is defined like this:
struct scatterlist {

#ifdef CONFIG_DEBUG_SG
        unsigned long sg_magic;
#endif
        unsigned long page_link;
        unsigned int offset;

        unsigned int length;

        /* an IOVA can be 64-bits on some PA-Risc platforms. */
        dma_addr_t iova;        /* I/O Virtual Address */
        __u32      iova_length; /* bytes mapped */
};
Quoted 2 lines

in absolute the comment "an IOVA can be 64-bits on some PA-Risc platforms." seems ok.

Yes, it's correct. pa8800 allows 64-bit capabale devices to bypass the IOMMU. But I don't think we allow it yet since we would need to add code that stuffs the Virtual Index (for DMA to be cache coherent) into the high bits of the IOVA.

Quoted 8 lines

but otoh, include/asm-parisc/types.h, defined dma_addr_t like this:

/* Dma addresses are 32-bits wide. */

typedef u32 dma_addr_t;
typedef u64 dma64_addr_t;

#endif /* __ASSEMBLY__ */

Yes, this matches the current implementation.
Adding support for "bypass" on zx1 chipsets (pa8800/pa8900 CPUs) will require something more clever.

Quoted 10 lines

OK it's just a comment but imho there is interesting matter in x86:

typedef u64 dma64_addr_t;
#if defined(CONFIG_X86_64) || defined(CONFIG_HIGHMEM64G) /* DMA addresses come in 32-bit and 64-bit flavours. */ typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
#endif

Quoted 2 lines

But I simply have no idea which "#if defined" would be the most relevant for parisc, any idea?

u32 is correct now. u64 could be used for 64-bit builds when someone decides we should bypass the IOMMU to improve DMA mapping/unmapping performance.

3-4 years ago I saw about 3% better performance for Storage Devices _with_ the IOMMU enabled. IIRC, it was because of coalescing the longer SG lists into a single IOMMU entry was more efficient for the PCI device. Smaller, non-contiguous IOs would benefit from IOMMU bypass - e.g. NIC workloads.

hth,
grant

Quoted 7 lines

Cheers,

	r.

-
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#2 lore raw
Quoted 54 lines · Grant Grundler
Quoted 18 lines · rubisher

Hello *,

Continuing my blind investigation on ccio-dma stuff, I read those 2 different comments:
in include/asm-parisc/scatterlist.h, scartterlist structure is defined like this:
struct scatterlist {

#ifdef CONFIG_DEBUG_SG
        unsigned long sg_magic;
#endif
        unsigned long page_link;
        unsigned int offset;

        unsigned int length;

        /* an IOVA can be 64-bits on some PA-Risc platforms. */
        dma_addr_t iova;        /* I/O Virtual Address */
        __u32      iova_length; /* bytes mapped */
};
Quoted 1 line

in absolute the comment "an IOVA can be 64-bits on some PA-Risc platforms." seems ok.

Yes, it's correct. pa8800 allows 64-bit capabale devices to bypass the IOMMU. But I don't think we allow it yet since we would need to add code that stuffs the Virtual Index (for DMA to be cache coherent) into the high bits of the IOVA.

Quoted 8 lines

but otoh, include/asm-parisc/types.h, defined dma_addr_t like this:

/* Dma addresses are 32-bits wide. */

typedef u32 dma_addr_t;
typedef u64 dma64_addr_t;

#endif /* __ASSEMBLY__ */

Yes, this matches the current implementation.
Adding support for "bypass" on zx1 chipsets (pa8800/pa8900 CPUs) will require something more clever.

Quoted 11 lines

OK it's just a comment but imho there is interesting matter in x86:

typedef u64 dma64_addr_t;
#if defined(CONFIG_X86_64) || defined(CONFIG_HIGHMEM64G) /* DMA addresses come in 32-bit and 64-bit flavours. */ typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
#endif

But I simply have no idea which "#if defined" would be the most relevant for parisc, any idea?

u32 is correct now. u64 could be used for 64-bit builds when someone decides we should bypass the IOMMU to improve DMA mapping/unmapping performance.

Quoted 9 lines

3-4 years ago I saw about 3% better performance for Storage Devices _with_ the IOMMU enabled. IIRC, it was because of coalescing the longer SG lists into a single IOMMU entry was more efficient for the PCI device. Smaller, non-contiguous IOs would benefit from IOMMU bypass - e.g. NIC workloads.

hth,
grant

Ok,

btw do you notice how much way are there (in so few lines) to use a unsigned 32bits integer: u32, __u32 but also uint32_t, u_int32_t, ...

Is there some advise om the best pratice?

Ah also related to ccio-dma patch test on my c110, it seems that removing DELAYED_RESOURCE_CNT code help a bit this system with few ram (64Mb only) to survive a bit longer (enough to debootstrap and download 800Mb to be installed) but that didn't make the drill: there are still fs corruption from time to time and some reset on the lasi disk ;-(. This test just seems to confirm an issue of i/o coherency somewhere but where those rules could be broken???

Merry Xmas,

	r.
#3 lore raw

On Sun, Dec 23, 2007 at 10:50:34PM +0000, rubisher wrote:
...

Quoted 4 lines

btw do you notice how much way are there (in so few lines) to use a unsigned 32bits integer: u32, __u32 but also uint32_t, u_int32_t, ...

Is there some advise om the best pratice?

IIRC, Preferred is "u32". But use whatever is consistent with the file you are editing.

Quoted 8 lines

Ah also related to ccio-dma patch test on my c110, it seems that removing DELAYED_RESOURCE_CNT code help a bit this system with few ram (64Mb only) to survive a bit longer (enough to debootstrap and download 800Mb to be installed) but that didn't make the drill: there are still fs corruption from time to time and some reset on the lasi disk ;-(.
This test just seems to confirm an issue of i/o coherency somewhere but where those rules could be broken???

ISTR Joel Soete reporting problems for CCIO machines as well. Offhand, I don't know what's wrong and we depend on Ryan Bradetich and other volunteers to track that down.

cheers,
grant

Quoted 7 lines

Merry Xmas,

	r.

-
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw
Quoted 9 lines · Grant Grundler

On Sun, Dec 23, 2007 at 10:50:34PM +0000, rubisher wrote:
...

Quoted 4 lines

btw do you notice how much way are there (in so few lines) to use a unsigned 32bits integer: u32, __u32 but also uint32_t, u_int32_t, ...

Is there some advise om the best pratice?

IIRC, Preferred is "u32". But use whatever is consistent with the file you are editing.

IIRC, the __xx variants are to be used for userspace exported headers. See the comment in include/asm-parisc/types.h

HTH and merry Xmas

T-Bone

Signature · 2 lines
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
author
#5 lore raw

iommu_fill_pdir() and its /* Horrible hack. ... */ reading.

In reply to Grant Grundler
Quoted 12 lines · Grant Grundler

On Sun, Dec 23, 2007 at 10:50:34PM +0000, rubisher wrote:
...

Quoted 3 lines

btw do you notice how much way are there (in so few lines) to use a unsigned 32bits integer: u32, __u32 but also uint32_t, u_int32_t, ...

Is there some advise om the best pratice?

IIRC, Preferred is "u32". But use whatever is consistent with the file you are editing.

Quoted 2 lines

Ah also related to ccio-dma patch test on my c110, it seems that removing DELAYED_RESOURCE_CNT code help a bit this system with few ram (64Mb only) to survive a bit longer (enough to debootstrap and download 800Mb to be installed) but that didn't make the drill: there are still fs corruption from time to time and some reset on the lasi disk ;-(. This test just seems to confirm an issue of i/o coherency somewhere but where those rules could be broken???

Quoted 10 lines

ISTR Joel Soete reporting problems for CCIO machines as well. Offhand, I don't know what's wrong and we depend on Ryan Bradetich and other volunteers to track that down.

cheers,
grant

Quoted 3 lines

Merry Xmas,

	r.

-

Hello Grant,

I suspecting a possible issue with this hack in your iommu_fill_pdir():

you initialized dma_sg with the adress of startsg (/* pointer to current DMA */) then before the loop you dma_sg--;

(where and what dms_sg point to, I guess we have any idea?)

Now in the while (nents-- > 0), suppose the test "if (sg_dma_address(startsg) & PIDE_FLAG) {" failed,

so later in the loop the "sg_dma_len(dma_sg) += startsg->length" (which is actually "dma_sg->iova_length += startsg->length" ) imo could corrupt something?

That said I tried to re-use the first implementation of jejb (what was in ccio-dma.c before this patch <http://cvs.parisc-linux.org/linux-2.6/drivers/parisc/ccio-dma.c?r1=1.12&r2=1.13> but that doesn't seems to fix the ccio-dma issue at all: I can still read those kind of message at the console while doing such copy [snip]
scsi1: (4:0) phase mismatch at 01e8, phase IO CD MSG BSY REQ MSG IN
scsi1: Bus Reset detected, executing command 10953600, slot 109708a4, dsp 001301e8[01e8]

failing command because of reset, slot 10970778, cmnd 12644a00

failing command because of reset, slot 109708a4, cmnd 10953600

scsi1: (4:0) phase mismatch at 01e8, phase IO CD MSG BSY REQ MSG IN

scsi1: Bus Reset detected, executing command 12644c40, slot 10970520, dsp 001301e8[01e8]

failing command because of reset, slot 10970520, cmnd 12644c40

scsi1: (4:0) phase mismatch at 01e8, phase IO CD MSG BSY REQ MSG IN

scsi1: Bus Reset detected, executing command 109532a0, slot 1097064c, dsp 001301e8[01e8]

failing command because of reset, slot 1097064c, cmnd 109532a0

end_request: I/O error, dev sdc, sector 197250
[snip]
while doing such copy:

root@hpalin:/boot# find . | cpio -mpduv /mnt/OldPA/boot/.
/mnt/OldPA/boot/././vmlinux-cp
/mnt/OldPA/boot/././vmlinux-2.6.23-c110-p2
/mnt/OldPA/boot/././vmlinux-cp13
/mnt/OldPA/boot/././vmlinux-2.6.23-c110
/mnt/OldPA/boot/././vmlinux-cp6
/mnt/OldPA/boot/././config-2.6.23-pa-b180
/mnt/OldPA/boot/././vmlinux-cp9
/mnt/OldPA/boot/././lost+found
/mnt/OldPA/boot/././vmlinux-2.6.23-c110-p4
/mnt/OldPA/boot/././vmlinux-2.6.22-3-parisc
/mnt/OldPA/boot/././config-2.6.23-c110-p15
/mnt/OldPA/boot/././vmlinux-2.6.23-c110-p5
/mnt/OldPA/boot/././vmlinux-2.6.23-c110-p15
/mnt/OldPA/boot/././vmlinux-2.6.23-c110-p10
/mnt/OldPA/boot/././System.map-2.6.22-3-parisc
/mnt/OldPA/boot/././vmlinux-2.6.23-c110-p13
/mnt/OldPA/boot/././vmlinux-2.6.23-c110-p6
/mnt/OldPA/boot/././config-2.6.22-3-parisc
/mnt/OldPA/boot/././vmlinux-cp14
/mnt/OldPA/boot/././initrd.img-2.6.22-3-parisc
/mnt/OldPA/boot/././vmlinux-2.4.17-32
/mnt/OldPA/boot/././vmlinux-cp11
/mnt/OldPA/boot/././vmlinux-cp10
/mnt/OldPA/boot/././vmlinux-cp5
/mnt/OldPA/boot/././vmlinux-cp15
/mnt/OldPA/boot/././System.map-2.4.17-32
/mnt/OldPA/boot/././config-2.6.23-c110-p2
/mnt/OldPA/boot/././vmlinux-2.6.23-pa-b180
/mnt/OldPA/boot/././vmlinux-2.6.23-c110-p14
/mnt/OldPA/boot/././vmlinux-cp4
/mnt/OldPA/boot/././vmlinux-2.6.23-c110-p
/mnt/OldPA/boot/././config-2.4.17-32
/mnt/OldPA/boot/././vmlinux-2.6.23-c110-p9
/mnt/OldPA/boot/././vmlinux
/mnt/OldPA/boot/././vmlinux-2.6.23-c110-p11
/mnt/OldPA/boot/././vmlinux-t
/mnt/OldPA/boot/././vmlinux-co
138420 blocks

(the scsi1 is the lasi scsi hba as sources and the target being the disks on ncr53c720 hba)

or experimenting fs issues on this target disks?

That said ok I will wait either U2/Uturn ers public doc or all volonteers feedback.

Cheers,

	r.
#6 lore raw

Re: iommu_fill_pdir() and its /* Horrible hack. ... */ reading.

Hi,

Quoted 7 lines · rubisher

Hello Grant,

I suspecting a possible issue with this hack in your iommu_fill_pdir():

you initialized dma_sg with the adress of startsg (/* pointer to current DMA */)
then before the loop you dma_sg--;

Yes. The comment before that line explains why it does that.

...

Quoted 2 lines

Now in the while (nents-- > 0), suppose the test "if (sg_dma_address(startsg) & PIDE_FLAG) {" failed,

Do you have any evidence this test has failed when dma_sg is pointing at garbage?

While possible, that would be a bug in iommu_coalesce_chunks() for not setting PIDE_FLAG.

Quoted 3 lines

so later in the loop the "sg_dma_len(dma_sg) += startsg->length" (which is actually "dma_sg->iova_length += startsg->length" ) imo could corrupt something?

Yes, that would be the result. Can you try a bug catcher to prove that's something is actually getting corrupted?

Add something like the following around line 65 (before "sg_dma_len(dma_sg)" is assigned):

	BUG_ON(dma_sg < startsg);

On the same note, line 44 is clearly wrong:
41 if (sg_dma_address(startsg) & PIDE_FLAG) {
42 u32 pide = sg_dma_address(startsg) & ~PIDE_FLAG;
43
44 BUG_ON(pdirp && (dma_len != sg_dma_len(dma_sg)));
45
46 dma_sg++;

The BUG_ON at line 44 might fail when it shouldn't (and vice versa). My preference is to remove it or put "#ifdef DEBUG_IOMMU" around that line of code (not literally, but effectively).

In general, I didn't like the "pre-decrement" but it seems to work and makes the code a bit more efficient. Efficiency is extremely important for this code since it gets called so often. Small changes can have easily measured impact.

Quoted 9 lines

That said I tried to re-use the first implementation of jejb (what was in ccio-dma.c before this patch
<http://cvs.parisc-linux.org/linux-2.6/drivers/parisc/ccio-dma.c?r1=1.12&r2=1.13>
but that doesn't seems to fix the ccio-dma issue at all: I can still read those kind of message at the console while doing such copy [snip]
scsi1: (4:0) phase mismatch at 01e8, phase IO CD MSG BSY REQ MSG IN
scsi1: Bus Reset detected, executing command 10953600, slot 109708a4, dsp 001301e8[01e8]

I'm thinking we really need SCSI bus traces to figure out if the SCSI driver is doing the right thing and if not, exactly what is it doing.

If it is a CCIO bug, my guess is it's more likely to be problems with setting magic bits. We really need the ERS to review register settings.

..

Quoted 4 lines

(the scsi1 is the lasi scsi hba as sources and the target being the disks on ncr53c720 hba)

or experimenting fs issues on this target disks?

I doubt this is a file system problem.

Quoted 2 lines

That said ok I will wait either U2/Uturn ers public doc or all volonteers feedback.

I'm skeptical for the former and hopeful for the latter. There is a chance Linux Foundation could ask HP for those docs under NDA. But you need to sign up with Linux Foundataion as a developer and then request HP for those docs.

cheers,
grant

author
#7 lore raw

Re: iommu_fill_pdir() and its /* Horrible hack. ... */ reading.

Quoted 39 lines · Grant Grundler

Hi,

Quoted 6 lines · rubisher

Hello Grant,

I suspecting a possible issue with this hack in your iommu_fill_pdir():

you initialized dma_sg with the adress of startsg (/* pointer to current DMA */) then before the loop you dma_sg--;

Yes. The comment before that line explains why it does that.

...

Quoted 1 line

Now in the while (nents-- > 0), suppose the test "if (sg_dma_address(startsg) & PIDE_FLAG) {" failed,

Do you have any evidence this test has failed when dma_sg is pointing at garbage?

While possible, that would be a bug in iommu_coalesce_chunks() for not setting PIDE_FLAG.

Quoted 1 line

so later in the loop the "sg_dma_len(dma_sg) += startsg->length" (which is actually "dma_sg->iova_length += startsg->length" ) imo could corrupt something?

Yes, that would be the result. Can you try a bug catcher to prove that's something is actually getting corrupted?

Add something like the following around line 65 (before "sg_dma_len(dma_sg)" is assigned):

	BUG_ON(dma_sg < startsg);

On the same note, line 44 is clearly wrong:
41 if (sg_dma_address(startsg) & PIDE_FLAG) {
42 u32 pide = sg_dma_address(startsg) & ~PIDE_FLAG;
43
44 BUG_ON(pdirp && (dma_len != sg_dma_len(dma_sg)));
45
46 dma_sg++;

Quoted 4 lines

The BUG_ON at line 44 might fail when it shouldn't (and vice versa). My preference is to remove it or put "#ifdef DEBUG_IOMMU" around that line of code (not literally, but effectively).

Good idea:
here is the patch I used:

drivers/parisc/iommu-helpers.h 2007-12-28 12:45:29.000000000 +0000 renamed from drivers/parisc/iommu-helpers.h 2007-12-28 12:59:35.000000000 +0000 +5 -2
Index: linux-current/drivers/parisc/iommu-helpers.h
===================================================================
@@ -22,14 +22,14 @@
        /* Horrible hack.  For efficiency's sake, dma_sg starts one
         * entry below the true start (it is immediately incremented
         * in the loop) */
-        dma_sg--;
+       dma_sg--;
 
        while (nents-- > 0) {
                unsigned long vaddr;
                long size;
 
                DBG_RUN_SG(" %d : %08lx/%05x %08lx/%05x\n", nents,
-                          (unsigned long)sg_dma_address(startsg), cnt,
+                          (unsigned long)sg_dma_address(startsg), sg_dma_len(startsg),
                           sg_virt_addr(startsg), startsg->length
                );
 

@@ -41,7 +41,9 @@
                if (sg_dma_address(startsg) & PIDE_FLAG) {
                        u32 pide = sg_dma_address(startsg) & ~PIDE_FLAG;
 
+#ifdef DEBUG_IOMMU
                        BUG_ON(pdirp && (dma_len != sg_dma_len(dma_sg)));
+#endif
 
                        dma_sg++;
 

@@ -62,6 +64,7 @@
                        prefetchw(pdirp);
                }
 
+               BUG_ON(dma_sg < startsg);
                BUG_ON(pdirp == NULL);
 
                vaddr = sg_virt_addr(startsg);

=== <> ===

And :<(

------------[ cut here ]------------

kernel BUG at /CAD/linux-2.6.23-pa-git-20071022/drivers/parisc/iommu-helpers.h:67!

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI

PSW: 00000000000001001111011100001110 Not tainted

r00-03 0004f70e fff0bdc0 10212064 107dd000

r04-07 00000000 10880d48 00000001 00000006

r08-11 108fc8a0 10440e10 00000001 108fc8a0

r12-15 10000000 00008000 00000005 0000000e

r16-19 1084c800 1081880c 10387964 007dc005

r20-23 10491000 00001000 00000000 00000005

r24-27 107dc000 07dc0000 10880d40 103dee10

r28-31 00000000 00000000 10819080 108fc8b4

sr00-03 00000000 00000000 00000000 00000000

sr04-07 00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 102120a8 102120ac

IIR: 03ffe01f ISR: 00000000 IOR: 108fc8b4

CPU: 0 CR30: 10818000 CR31: f01043c0

ORIG_R28: aac6ca23

IAOQ[0]: ccio_map_sg+0x22c/0x3a8

IAOQ[1]: ccio_map_sg+0x230/0x3a8

RP(r2): ccio_map_sg+0x1e8/0x3a8

Backtrace: 

 [<10107164>] die_if_kernel+0xa0/0x1b0 

 [<10107898>] handle_interruption+0x624/0x6b4 

 [<1010b078>] intr_check_sig+0x0/0x34 

 [<10121574>] enqueue_task+0x28/0x44 

 [<102120ac>] ccio_map_sg+0x230/0x3a8 

 [<10171428>] do_filp_open+0x54/0x68 

 [<10211fd8>] ccio_map_sg+0x15c/0x3a8 

 [<10266d2c>] scsi_dma_map+0x48/0x58 

 [<1027597c>] NCR_700_queuecommand+0x38c/0x504 

 [<10260368>] scsi_dispatch_cmd+0x118/0x288 

 [<1026664c>] scsi_request_fn+0x184/0x2e0 

 [<101fb440>] __generic_unplug_device+0x38/0x44 

 [<101fb7fc>] generic_unplug_device+0x14/0x24 

 [<101f841c>] blk_backing_dev_unplug+0x1c/0x28 

 [<10198b18>] sync_buffer+0x38/0x50 

 [<1019ab20>] __bread+0x90/0xec 



Kernel panic - not syncing: Attempted to kill init!

but there must be something wrong in this test because same change applied to iommu-helper without 'horrible hack' panic at the same place:

------------[ cut here ]------------
kernel BUG at /CAD/linux-2.6.23-pa-git-20071022/drivers/parisc/iommu-helpers.h:64!

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111011100001110 Not tainted

r00-03  0004f70e fff0bdc0 10212068 107dd000
r04-07  00000000 108fc8b4 108fc8a0 10880d48
r08-11  00000006 10440e10 00000001 00000001
r12-15  1084c800 108fc8a0 10000000 00008000
r16-19  00000005 0000000e 10387964 007dc005
r20-23  10491000 00000000 00000000 00000005
r24-27  107dc000 07dc0000 10880d40 103dee10
r28-31  000007dc 00002ee0 10819080 00000000

sr00-03 00000000 00000000 00000000 00000000
sr04-07 00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 102120b0 102120b4
IIR: 03ffe01f ISR: 00000000 IOR: 00000000
CPU: 0 CR30: 10818000 CR31: f01043c0
ORIG_R28: aac6ca23
IAOQ[0]: ccio_map_sg+0x234/0x3ac
IAOQ[1]: ccio_map_sg+0x238/0x3ac
RP(r2): ccio_map_sg+0x1ec/0x3ac

Backtrace:
 [<10107164>] die_if_kernel+0xa0/0x1b0
 [<10107898>] handle_interruption+0x624/0x6b4
 [<1010b078>] intr_check_sig+0x0/0x34
 [<10121a84>] __wake_up_common+0x7c/0xcc
 [<101713c0>] nameidata_to_filp+0x44/0x58
 [<10171428>] do_filp_open+0x54/0x68
 [<10211fd8>] ccio_map_sg+0x15c/0x3ac
 [<10266d30>] scsi_dma_map+0x48/0x58
 [<10275980>] NCR_700_queuecommand+0x38c/0x504
 [<1026036c>] scsi_dispatch_cmd+0x118/0x288
 [<10266650>] scsi_request_fn+0x184/0x2e0
 [<101fb440>] __generic_unplug_device+0x38/0x44
 [<101fb7fc>] generic_unplug_device+0x14/0x24
 [<101f841c>] blk_backing_dev_unplug+0x1c/0x28
 [<10198b18>] sync_buffer+0x38/0x50
 [<1019ab20>] __bread+0x90/0xec

Kernel panic - not syncing: Attempted to kill init!

Rebooting in 10 seconds..

So we could only guess that the other BUG_ON(pdirp == NULL); do well its job and you have right I have no evidence that something is actually corrupted.

Quoted 6 lines

In general, I didn't like the "pre-decrement" but it seems to work and makes the code a bit more efficient. Efficiency is extremely important for this code since it gets called so often. Small changes can have easily measured impact.

Understand, eventhought for my linux learning only I prefer a more robust code

Quoted 8 lines
Quoted 4 lines

That said I tried to re-use the first implementation of jejb (what was in ccio-dma.c before this patch <http://cvs.parisc-linux.org/linux-2.6/drivers/parisc/ccio-dma.c?r1=1.12&r2=1.13> but that doesn't seems to fix the ccio-dma issue at all: I can still read those kind of message at the console while doing such copy [snip]
scsi1: (4:0) phase mismatch at 01e8, phase IO CD MSG BSY REQ MSG IN
scsi1: Bus Reset detected, executing command 10953600, slot 109708a4, dsp 001301e8[01e8]

I'm thinking we really need SCSI bus traces to figure out if the SCSI driver is doing the right thing and if not, exactly what is it doing.

Well, submitted some stress test (the loop of disk read/write with a tar -xf linux-2.6.11.tar) on the same disk but connected to a b180 (i.e. using same ncr53c710 driver for the same lasi hba but without ccio-dma driver) didn't showed any failures. (for the ncr53c720 hba, i didn't have any other system to test it without ccio-dma ;<( )

Quoted 9 lines

If it is a CCIO bug, my guess is it's more likely to be problems with setting magic bits. We really need the ERS to review register settings.

..

Quoted 3 lines

(the scsi1 is the lasi scsi hba as sources and the target being the disks on ncr53c720 hba)

or experimenting fs issues on this target disks?

I doubt this is a file system problem.

No, it's a ext3 which I use on severall other hp model (b180, b2k so without ccio-dma) without any issues

Quoted 8 lines
Quoted 2 lines

That said ok I will wait either U2/Uturn ers public doc or all volonteers feedback.

I'm skeptical for the former and hopeful for the latter. There is a chance Linux Foundation could ask HP for those docs under NDA. But you need to sign up with Linux Foundataion as a developer and then request HP for those docs.

Well I am not actualy a developer, just an engineer (not in computer science) trying to help but may be is it enough to sign up with Linux Foundation? If yes, can you send me a link to request papers?

tx again,

	r.

PS: This c110 boxe was more reliable (I mean I could easily update system frequently, build kernel, ...) when it was equiped with 512M RAM; it became not any more usable when I had to decrease this ram size to original one (i.e. 64M)?

Quoted 4 lines

cheers,
grant