[parisc-linux] Re: NCR53c720

[parisc-linux] Re: NCR53c720

[Matthew Wilcox]

On Mon, Sep 29, 2003 at 02:53:16PM +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 29 Sep 2003, Geert Uytterhoeven wrote:
> 
> > > Are there any Amiga cards that are 720 based?
> > 
> > I don't know for sure. Probably not (cfr. above).
> 
> The ppc boards have a 770. In the APUS tree we currently have a modified 
> ncr53c8xx driver, that sort of seems to work. The biggest problem seems to 
> be the incoherent memory interface.

... Ah ;-)  So where do I find the APUS tree?  From digging around on
the web (man, there's a lot of broken links in the APUS faq ...), it
seems to be its own sourceforge project that hasn't switched to working
on 2.6 yet, is this correct?

Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum
of wailing & gnashing of teeth to convert it to use the non-coherent
dma device API.  It would benefit PA-RISC too as we have two models
(735 and 755) that have NCR720 chips and a non-coherent architecture.
Right now, they use the 53c700 driver, but it'd be better to use the
ncr53c8xx driver, of course.

Are any APUS people interested in working on this?  

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

[parisc-linux] Re: NCR53c720

[Geert Uytterhoeven]

On Mon, 29 Sep 2003, Matthew Wilcox wrote:
> On Mon, Sep 29, 2003 at 02:53:16PM +0200, Roman Zippel wrote:
> > The ppc boards have a 770. In the APUS tree we currently have a modified 
> > ncr53c8xx driver, that sort of seems to work. The biggest problem seems to 
> > be the incoherent memory interface.
> 
> ... Ah ;-)  So where do I find the APUS tree?  From digging around on
> the web (man, there's a lot of broken links in the APUS faq ...), it
> seems to be its own sourceforge project that hasn't switched to working
> on 2.6 yet, is this correct?

The APUS tree is indeed at SourceForge. Most recent version (not counting
Roman's hard disk :-) is 2.4.22.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[parisc-linux] Re: NCR53c720

[Roman Zippel]

Hi,

On Mon, 29 Sep 2003, Matthew Wilcox wrote:

> ... Ah ;-)  So where do I find the APUS tree?  From digging around on
> the web (man, there's a lot of broken links in the APUS faq ...), it

It's also quite old... :)

> seems to be its own sourceforge project that hasn't switched to working
> on 2.6 yet, is this correct?

Yes. My 2.6 tree currently dies at the first exec.

> Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum
> of wailing & gnashing of teeth to convert it to use the non-coherent
> dma device API.

Um, which one is the current right dma device API?

bye, Roman

[parisc-linux] Re: NCR53c720

[Matthew Wilcox]

On Mon, Sep 29, 2003 at 06:24:14PM +0200, Roman Zippel wrote:
> > Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum
> > of wailing & gnashing of teeth to convert it to use the non-coherent
> > dma device API.
> 
> Um, which one is the current right dma device API?

The one in Documentation/DMA-API.txt.  It looks like PowerPC hasn't got
an implementation of this yet -- is APUS the only non-coherent PowerPC
subport?

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Re: NCR53c720

[Grant Grundler]

On Mon, Sep 29, 2003 at 05:27:49PM +0100, Matthew Wilcox wrote:
> > Um, which one is the current right dma device API?
> 
> The one in Documentation/DMA-API.txt.

Matthew, which version of the source tree?
2.4.22 and 2.6.x versions of this file are not identical.

grundler@gsyprf3:/usr/src$ diff linux-2.?/Documentation/DMA-mapping.txt | wc -l
   117
grundler@gsyprf3:/usr/src$ wc -l linux-2.?/Documentation/DMA-mapping.txt
    798 linux-2.4/Documentation/DMA-mapping.txt
    828 linux-2.5/Documentation/DMA-mapping.txt
   1626 total

thanks,
grant

Re: [parisc-linux] Re: NCR53c720

[James Bottomley]

On Mon, 2003-09-29 at 15:55, Grant Grundler wrote:
> On Mon, Sep 29, 2003 at 05:27:49PM +0100, Matthew Wilcox wrote:
> > > Um, which one is the current right dma device API?
> > 
> > The one in Documentation/DMA-API.txt.
> 
> Matthew, which version of the source tree?
> 2.4.22 and 2.6.x versions of this file are not identical.
> 
> grundler@gsyprf3:/usr/src$ diff linux-2.?/Documentation/DMA-mapping.txt | wc -l
>    117
> grundler@gsyprf3:/usr/src$ wc -l linux-2.?/Documentation/DMA-mapping.txt
>     798 linux-2.4/Documentation/DMA-mapping.txt
>     828 linux-2.5/Documentation/DMA-mapping.txt
>    1626 total

DMA-mapping.txt is only the pci_ DMA API.  The ncr53c8xx doesn't use
that any more.  It only uses the generic DMA API, which is documented in
DMA-API.txt like willy said, and is only in 2.6 (not 2.4).

James

[parisc-linux] Re: NCR53c720

[Rene Brothuhn]

On 2003.09.29 15:33 Matthew Wilcox wrote:
> ... Ah ;-)  So where do I find the APUS tree?  From digging around on
> the web (man, there's a lot of broken links in the APUS faq ...), it
> seems to be its own sourceforge project that hasn't switched to working
> on 2.6 yet, is this correct?
> 
> Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum
> of wailing & gnashing of teeth to convert it to use the non-coherent
> dma device API.  It would benefit PA-RISC too as we have two models
> (735 and 755) that have NCR720 chips and a non-coherent architecture.
> Right now, they use the 53c700 driver, but it'd be better to use the
> ncr53c8xx driver, of course.
> 
> Are any APUS people interested in working on this?

Hello!

I'm the one who getting the 53c770 driver working on APUS. The driver is 
based on the code from the ncr53c8xx driver which I found on a 2.4.16 
kernel (maybe it was an other kernel version, I'm not really sure 
anymore). In newer kernels the ncr53c8xx drivers are replaced by sym53c8xx 
which uses a different and more complicated architecture.
In my opinion, the best is to create a seperate 53c720/770 driver based on 
the 53c770 from APUS or ncr53c8xx. I guess the 53c770 from APUS should 
work (with some changes) on a 720 (or similar), because the 770 was 
designed to replace the 720. But I don't know anything about 735 and 755.
But the APUS driver is a really big "patchwork", has some problems and 
needs a clean-up. And I haven't worked on the driver since a year due to 
lack of time, sorry.

I still have lack of time, but if there are any questions, I will help. It 
will be nice to have a native 720/770 driver... And maybe, if someone 
tries to port this driver to a PA, I have to go for it...


Ciao, Renè

[parisc-linux] Re: NCR53c720

[Matthew Wilcox]

On Mon, Sep 29, 2003 at 11:25:01PM +0200, Rene Brothuhn wrote:
> I'm the one who getting the 53c770 driver working on APUS. The driver is 

Good to hear from you.  Let me just clear up a couple of
misunderstandings...

> based on the code from the ncr53c8xx driver which I found on a 2.4.16 
> kernel (maybe it was an other kernel version, I'm not really sure 
> anymore). In newer kernels the ncr53c8xx drivers are replaced by sym53c8xx 
> which uses a different and more complicated architecture.

The sym53c8xx driver doesn't support all the chips that ncr53c8xx
supported (mostly earlier chips like 810).  Now there's the sym53c8xx_2
driver that supports all the 8xx chips.  In 2.6, we've now eliminated all
PCI stuff from ncr53c8xx (and it should probably be renamed to ncr53c7xx,
but I actually have a slightly different plan for renaming it that needs
other work to happen first).

> In my opinion, the best is to create a seperate 53c720/770 driver based on 
> the 53c770 from APUS or ncr53c8xx. I guess the 53c770 from APUS should 
> work (with some changes) on a 720 (or similar), because the 770 was 
> designed to replace the 720. But I don't know anything about 735 and 755.

The HP 735/755 workstations have an NCR720 chip as part of their `core
IO'.  It appears as a parisc_device.  They have a PCX-T CPU which has
no way to allocate coherent memory.

> But the APUS driver is a really big "patchwork", has some problems and 
> needs a clean-up. And I haven't worked on the driver since a year due to 
> lack of time, sorry.
> 
> I still have lack of time, but if there are any questions, I will help. It 
> will be nice to have a native 720/770 driver... And maybe, if someone 
> tries to port this driver to a PA, I have to go for it...

OK.  I think the right path forward here is:

 - I port the ncr53c8xx to use the non-coherent DMA interfaces.
 - Someone converts the zorro device to embed the struct device.
 - Someone implements the non-coherent DMA interfaces for PowerPC.
 - Someone adds a zorro720 driver (see NCR_Q720 and zalon for inspiration)
   that's simply a glue layer from zorro to ncr720.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

[parisc-linux] Re: NCR53c720

[Geert Uytterhoeven]

On Tue, 30 Sep 2003, Matthew Wilcox wrote:
>  - Someone converts the zorro device to embed the struct device.

I'm working on this. I have code that works on UML using a fake list of Zorro
devices, but so far I haven't modified any Zorro driver code.

BTW, A4000T SCSI is builtin, not Zorro, so we need a platform device for that.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [parisc-linux] Re: NCR53c720

[James Bottomley]

On Tue, 2003-09-30 at 03:21, Geert Uytterhoeven wrote:
> BTW, A4000T SCSI is builtin, not Zorro, so we need a platform device for that.

That depends on how you want it to work.  On parisc, the Lasi (SCSI and
other) devices are technically "platform" in that they're all ASIC'd
together and soldered on to the main board.  However, it was easier to
create a parisc_bus type and lump them all under it than to use a
platform device....however, we did this in the very early days of the
generic device, a platform device might be more appropriate now.

James

Re: [parisc-linux] Re: NCR53c720

[Matthew Wilcox]

On Tue, Sep 30, 2003 at 08:47:11AM -0500, James Bottomley wrote:
> On Tue, 2003-09-30 at 03:21, Geert Uytterhoeven wrote:
> > BTW, A4000T SCSI is builtin, not Zorro, so we need a platform device for that.
> 
> That depends on how you want it to work.  On parisc, the Lasi (SCSI and
> other) devices are technically "platform" in that they're all ASIC'd
> together and soldered on to the main board.  However, it was easier to
> create a parisc_bus type and lump them all under it than to use a
> platform device....however, we did this in the very early days of the
> generic device, a platform device might be more appropriate now.

It makes a lot of sense to treat all the devices that firmware tells us
about as parisc_devices since we treat them all the same way.  If we
were stepping over ourselves saying "well, yes, this is a pluggable
device and therefore we have to access it like that, but this one's
on the motherboard and therefore we treat it like that", I'd agree.
But all these devices are in the same namespace, firmware tells us
about all of them in the same way, so I think we should continue with
the parisc_device.

[parisc-linux] Re: NCR53c720

[Rene Brothuhn]

On 2003.09.30 04:21 Matthew Wilcox wrote:
> The sym53c8xx driver doesn't support all the chips that ncr53c8xx
> supported (mostly earlier chips like 810).  Now there's the sym53c8xx_2
> driver that supports all the 8xx chips.  In 2.6, we've now eliminated all
> PCI stuff from ncr53c8xx (and it should probably be renamed to ncr53c7xx,
> but I actually have a slightly different plan for renaming it that needs
> other work to happen first).

Fine, the pci-stuff is removed from the driver. This makes it easier to 
adapt the driver to non-pci machines.

I have looked in the ncr53c8xx driver from 2.6 and there is mentioned that 
"interrupt on the fly" is not working correctly for 720. Also 
sym53c8xx_defs.h is included and so the registerset from a 810 is used, 
but the 720/770 registers are slightly different.
Is the NCR_Q720 or zalon driver working?

> 
> OK.  I think the right path forward here is:
> 
>  - I port the ncr53c8xx to use the non-coherent DMA interfaces.
>  - Someone converts the zorro device to embed the struct device.
>  - Someone implements the non-coherent DMA interfaces for PowerPC.

So, maybe I can do that at least for APUS, because some of the needed 
interfaces I already created as a "dirty-hack" inside the 53c770 driver. 
But the mean problem is, that there is no working 2.6 kernel for APUS... 
The other problem is time, but maybe I find some hours on weekend...

>  - Someone adds a zorro720 driver (see NCR_Q720 and zalon for
> inspiration)
>    that's simply a glue layer from zorro to ncr720.

If the rest is working, something like this should not be a big problem...


Ciao, Renè

[parisc-linux] Re: NCR53c720

[Matthew Wilcox]

On Tue, Sep 30, 2003 at 03:59:32PM +0200, Rene Brothuhn wrote:
> I have looked in the ncr53c8xx driver from 2.6 and there is mentioned that 
> "interrupt on the fly" is not working correctly for 720. Also 
> sym53c8xx_defs.h is included and so the registerset from a 810 is used, 
> but the 720/770 registers are slightly different.
> Is the NCR_Q720 or zalon driver working?

Yes, they're both working fine.

I went over the 770 register definitions the other night and only found
one difference between the names of the definitions in the sym53c8xx_defs
file and the 770 PDF and that was:

-/*3a*/  u_char    nc_sbr;
+/*3a*/  u_char    nc_sbr; /* dwt on 720 */

This is the DMA watchdog timer, but it's not actually used by the driver.
It's a `scratch byte register' on the 895.  Some of the `reserved'
fields in the 770 register definition have names, but they were only
ever touched if the chip was a sufficiently recent revision.

BTW, I couldn't see a document for the 720 chip on the LSI site -- only
the 710 and 770.  I presume I won't go far wrong treating them the same.

> > - Someone implements the non-coherent DMA interfaces for PowerPC.
> 
> So, maybe I can do that at least for APUS, because some of the needed 
> interfaces I already created as a "dirty-hack" inside the 53c770 driver. 
> But the mean problem is, that there is no working 2.6 kernel for APUS... 
> The other problem is time, but maybe I find some hours on weekend...

Yeah, no hurry.  I don't think we have to get this done before 2.6.0 is
out -- after all, it's only a driver.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

[parisc-linux] Re: NCR53c720

[Roman Zippel]

Hi,

On Tue, 30 Sep 2003, Rene Brothuhn wrote:

> But the mean problem is, that there is no working 2.6 kernel for APUS... 

That's not really true anymore, it boots here now. :-)

bye, Roman

Re: [parisc-linux] Re: NCR53c720

[James Bottomley]

On Tue, 2003-09-30 at 08:59, Matthew Wilcox wrote:
> It makes a lot of sense to treat all the devices that firmware tells us
> about as parisc_devices since we treat them all the same way.  If we
> were stepping over ourselves saying "well, yes, this is a pluggable
> device and therefore we have to access it like that, but this one's
> on the motherboard and therefore we treat it like that", I'd agree.
> But all these devices are in the same namespace, firmware tells us
> about all of them in the same way, so I think we should continue with
> the parisc_device.

Yes, I was just musing about the way we did it.  In theory, the
difference between a "platform" device and a generic device is that a
generic device has a bus, and a platform one doesn't.  The
platform_device also has a resource pointer and a few other bits and
pieces the generic device doesn't.

What I did for PA was to create a parisc bus type, and attach all the
inventoried hardware to it.  This blurs the bus distinction in generic
device because we have several inventoried buses: Runway, GSC, LASI etc.
that are all lumped under the parisc bus.

I was just wondering if it wouldn't make more sense now for us to be
using platform devices too...

James


> >From a historical perspective, we've had parisc_devices in
> one form or another since the very start of the project.
> They were called hp_devices until about August 2001.  See
> http://ftp.parisc-linux.org/patches/parisc_device-2.diff for the
> conversion.
> 
> I don't know much about Amiga/Zorro.  Maybe it'd make sense for Amiga
> platform devices to be faked as zorro_devices, but I doubt it.  In
> any case, the 4000T SCSI is a 53c710, not a 720.
> 
> -- 
> "It's not Hollywood.  War is real, war is primarily not about defeat or
> victory, it is about death.  I've seen thousands and thousands of dead bodies.
> Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Re: NCR53c720

[Grant Grundler]

On Mon, Sep 29, 2003 at 04:00:10PM -0500, James Bottomley wrote:
> DMA-mapping.txt is only the pci_ DMA API.

Doh! yes...misread willy's comment. sorry.

grant

Re: [parisc-linux] Re: NCR53c720

[Grant Grundler]

On Tue, Sep 30, 2003 at 10:32:23AM -0500, James Bottomley wrote:
> What I did for PA was to create a parisc bus type, and attach all the
> inventoried hardware to it.  This blurs the bus distinction in generic
> device because we have several inventoried buses: Runway, GSC, LASI etc.
> that are all lumped under the parisc bus.

All those busses conform to the HP IO ADC and thus could be
considered the same type of bus. Except for LASI, the above makes
sense to me.

LASI isn't a bus. This would be a candidate for "platform device"
since it's bridge-like device with integrate sub-devices.
EISA bridge chips might be a similar case.

> I was just wondering if it wouldn't make more sense now for us to be
> using platform devices too...

I don't understand "platform devices" vs "PCI devices" unless we
are talking about "custom", arch specific bridge chips.
A GSC device is a GSC device regardless of which board it's soldered to.
That's not the case for PCI?

grant

[parisc-linux] Re: NCR53c720

[Rene Brothuhn]

Hello!

On 2003.09.30 16:32 Matthew Wilcox wrote:
> On Tue, Sep 30, 2003 at 03:59:32PM +0200, Rene Brothuhn wrote:
> > but the 720/770 registers are slightly different.
> > Is the NCR_Q720 or zalon driver working?
> 
> Yes, they're both working fine.
> 
> I went over the 770 register definitions the other night and only found
> one difference between the names of the definitions in the sym53c8xx_defs
> file and the 770 PDF and that was:
> 
> -/*3a*/  u_char    nc_sbr;
> +/*3a*/  u_char    nc_sbr; /* dwt on 720 */
> 
> This is the DMA watchdog timer, but it's not actually used by the driver.
> It's a `scratch byte register' on the 895.  Some of the `reserved'
> fields in the 770 register definition have names, but they were only
> ever touched if the chip was a sufficiently recent revision.
> 
> BTW, I couldn't see a document for the 720 chip on the LSI site -- only
> the 710 and 770.  I presume I won't go far wrong treating them the same.

Sorry for reacting so late. I also have no doc for the 720, but I think 
the differences between 770 and 720 are not so big.
I'm sure there are a lot more differences between the 8xx and 720/770. Not 
only the registers or register names but also the bits inside some 
registers are slightly different.
I have some PDF's on which the differences between the chips are 
described. It seems that these docs are not available anymore on the LSI 
site. I'll send it directly to you, because the size is to much for the 
list.
I hope this will help you.

I have looked into the driver a little bit last weekend and I guess it 
should be possible to provide a 770 definition into the driver. But first 
I have to got a workable 2.6 kernel...


Ciao, Renè

[parisc-linux] Re: NCR53c720

[Rene Brothuhn]

Hello!

On 2003.09.30 16:55 Roman Zippel wrote:
> Hi,
> 
> On Tue, 30 Sep 2003, Rene Brothuhn wrote:
> 
> > But the mean problem is, that there is no working 2.6 kernel for
> APUS...
> 
> That's not really true anymore, it boots here now. :-)

Sounds nice! Where can I get the working sources?


Ciao, Renè

[parisc-linux] Re: NCR53c720

[Joel Soete]

Hello all,

There was a thread:: <http://lists.parisc-linux.org/pipermail/parisc-linux/2003-September/021172.html>

which would help me to find the right direction to solve this pb:
<http://lists.parisc-linux.org/pipermail/parisc-linux/2004-April/022968.html>

The only new think I discover became when I reboot a kernel build with gcc-3.0:
[snip]
: arq->state 2
Badness in as_requeue_request at drivers/block/as-iosched.c:1479
Kernel addresses on the stack:
 [<10127830>] printk+0x12c/0x1b0
 [<10107d64>] dump_stack+0x18/0x24
 [<1022b21c>] as_requeue_request+0x64/0x108
 [<102225c0>] elv_requeue_request+0x3c/0x64
 [<102250a8>] blk_insert_request+0x4c/0xf8
 [<1024f418>] scsi_queue_insert+0x6c/0xa0
 [<102642d8>] ncr_wakeup_done+0x90/0xc0
 [<1024b578>] scsi_softirq+0xcc/0x128
 [<1024b498>] scsi_done+0x5c/0x70
 [<1012b504>] __do_softirq+0x60/0xcc
 [<10109428>] do_irq+0xa4/0x160
 [<1010231c>] __scheduling_functions_end_here+0x3c/0x48
 [<10109574>] do_cpu_irq_mask+0x90/0xf0
 [<1010d068>] intr_return+0x0/0x14
 [<102632a4>] ncr_start_next_ccb+0xdc/0x104
 [<10145e6c>] kmem_cache_alloc+0x3c/0x4c
 [<1015d69c>] get_empty_filp+0x64/0x11c
 [<1015bc80>] dentry_open+0x12c/0x1b4
 [<1016f8b0>] locate_fd+0xfc/0x190
 [<10145e64>] kmem_cache_alloc+0x34/0x4c
 [<10140530>] mempool_alloc+0xac/0x184
 [<10225fcc>] generic_make_request+0x15c/0x1fc
 [<101ab458>] __journal_remove_journal_head+0x144/0x1e4
 [<10162b28>] bio_alloc+0x14c/0x1bc
 [<102260e0>] submit_bio+0x74/0x154
 [<10162234>] submit_bh+0x8c/0x16c
 [<10162388>] ll_rw_block+0x74/0x140
 [<101a6fc4>] journal_brelse_array+0x2c/0x44
 [<101a6f04>] journal_commit_transaction+0xfdc/0x1070
 [<101ee0cc>] vsnprintf+0x6a4/0x8cc
 [<101a94ac>] kjournald+0xc8/0x220
 [<1015cb58>] sys_write+0x4c/0x84
 [<10129b34>] do_group_exit+0x84/0xbc
 [<1010a35c>] tracesys_exit+0x0/0x34
 [<1010cc5c>] ret_from_kernel_thread+0x1c/0x24

kernel BUG at include/linux/blkdev.h:562!
Kernel addresses on the stack:
 [<10127830>] printk+0x12c/0x1b0
 [<10107d64>] dump_stack+0x18/0x24
 [<10250630>] scsi_request_fn+0x2b4/0x388
 [<102225c0>] elv_requeue_request+0x3c/0x64
 [<10225110>] blk_insert_request+0xb4/0xf8
 [<1024f418>] scsi_queue_insert+0x6c/0xa0
 [<102642d8>] ncr_wakeup_done+0x90/0xc0
 [<1024b578>] scsi_softirq+0xcc/0x128
 [<1024b498>] scsi_done+0x5c/0x70
 [<1012b504>] __do_softirq+0x60/0xcc
 [<10109428>] do_irq+0xa4/0x160
 [<1010231c>] __scheduling_functions_end_here+0x3c/0x48
 [<10109574>] do_cpu_irq_mask+0x90/0xf0
 [<1010d068>] intr_return+0x0/0x14
 [<102632a4>] ncr_start_next_ccb+0xdc/0x104
 [<10145e6c>] kmem_cache_alloc+0x3c/0x4c
 [<1015d69c>] get_empty_filp+0x64/0x11c
 [<1015bc80>] dentry_open+0x12c/0x1b4
 [<1016f8b0>] locate_fd+0xfc/0x190
 [<10145e64>] kmem_cache_alloc+0x34/0x4c
 [<10140530>] mempool_alloc+0xac/0x184
 [<10225fcc>] generic_make_request+0x15c/0x1fc
 [<101ab458>] __journal_remove_journal_head+0x144/0x1e4
 [<10162b28>] bio_alloc+0x14c/0x1bc
 [<102260e0>] submit_bio+0x74/0x154
 [<10162234>] submit_bh+0x8c/0x16c
 [<10162388>] ll_rw_block+0x74/0x140
 [<101a6fc4>] journal_brelse_array+0x2c/0x44
 [<101a6f04>] journal_commit_transaction+0xfdc/0x1070
 [<101ee0cc>] vsnprintf+0x6a4/0x8cc
 [<101a94ac>] kjournald+0xc8/0x220
 [<1015cb58>] sys_write+0x4c/0x84
 [<10129b34>] do_group_exit+0x84/0xbc
 [<1010a35c>] tracesys_exit+0x0/0x34
 [<1010cc5c>] ret_from_kernel_thread+0x1c/0x24

[snip]

which makes appear ncr_wakeup_done() and ncr_start_next_ccb() but I don't
yet reach to figure out why the work-around which consist of commenting 'parisc_vmerge_max_size
= ...' into ccio-dma.c make the stuff working (that just let parisc_vmerge_max_size
=0 as initialized in gsc.c)

I also try to compare ncr_start_next_ccb with its sister sym_ and discover
that there was a improved way to manage requeing but I don't find how to
manage such changes (new ncr53720 files, a sym53c7xx_2 tree, ...). 

Any idea?

Thanks for yoyr attention,
    Joel

----------------------------------------------------------------------------------------
Tiscali ADSL, 27,50 €/mois...pendant 6 mois. 
La meilleure offre du marché !
http://reg.tiscali.be/default.asp?lg=fr