[parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0

[parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0

[Joel Soete]

Hi all,

I know it shouldn't be the source of the pb but btw I noticed:

> ncr53c8xx.c:7594:	u_long baddr = map_scsi_single_data(np, cmd);

cmd is a "struct scsi_cmnd *" (the parameter of ncr_scatter)

> sym53c8xx_comm.h:699:static int __map_scsi_sg_data(struct device *dev,
Scsi_Cmnd *cmd)
...
sym53c8xx_comm.h:708:	use_sg = dma_map_sg(dev, cmd->buffer, cmd->use_sg,
dma_dir);

and here cmd is a "Scsi_Cmnd *" which is so of different type because of
"typedef struct scsi_cmnd Scsi_Cmnd"


What should it be done?

Thanks in advance for your attention,
    Joel



----------------------------------------------------------------------------------------
Tiscali ADSL: 35 €/mois, la meilleure offre du marché!
http://reg.tiscali.be/default.asp?lg=fr

[parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0

[Grant Grundler]

On Mon, Apr 26, 2004 at 06:52:40PM +0200, Joel Soete wrote:
> and here cmd is a "Scsi_Cmnd *" which is so of different type because of
> "typedef struct scsi_cmnd Scsi_Cmnd"

uhm...the typedef says Scsi_Cmnd *IS* struct scsi_cmnd.
Therefor "Scsi_Cmnd *"  is the same type as "struct scsi_cmnd *".

> What should it be done?

Get rid of Scsi_Cmnd typedef?
I personally consider it bad style to use both forms in the same
subsystem and don't really care which is used. But that's an
issue for the subsystem maintainer to decide. :^)

grant

Re: [parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0 [was: 2.6.5-rc2-pa2 boot panic on c110 :(]

[Joel Soete]

James ,

Thanks to your explanation, I become to have (step by step) a more detail
idea on what I did and its borther effect. (still have to confirm by test
:^)

 
>coalescing, so our SG lists were usually lots of page sized entities. 
>Now the individual entries can be up to 256k long.


Just to be sure we spoke about the same thing:
256k for you is it well the parisc_vmerge_max_size = IOVP_SIZE * BITS_PER_LONG?

as IOVP == PAGE_SIZE == 4k and BITS_PER_LONG == 32 for a 32bits kernel, so
parisc_vmerge_max_size= 128k

and BITS_PER_LONG == 64 for 64bit kernel, so parisc_vmerge_max_size= 256k.

Thanks in advance,
    Joel

PS: btw in dma.h I found "#define DMA_CHUNK_SIZE (BITS_PER_LONG*PAGE_SIZE)";
couldn't it used in ccio-dma.c and sba-iommu.c in parisc_vmerge_max_size
assignement?

----------------------------------------------------------------------------------------
Tiscali ADSL: 35 €/mois, la meilleure offre du marché!
http://reg.tiscali.be/default.asp?lg=fr

[parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0

[Grant Grundler]

On Sat, Apr 24, 2004 at 08:52:37PM +0000, Joel Soete wrote:
> Hello Grant,
> 
> Sorry in advance to disturbe you with this c110 pb but if I well understand 
> the physical connection (fine doc find on openpa.net :) and better 
> understand what james means, otc I past the full last week to study more 
> ccio-dma and ncr53c8xx but I don't reach to locate the part of code making 
>  the link between those 2 part (i mean where ncr call ccio and visversa). 
>  Could you help me a bit more.

Yup. Using 2.6.5-pa8 source tree, ncr53c8xx.c calls DMA services from
ncr_scatter():

ncr53c8xx.c:7594:	u_long baddr = map_scsi_single_data(np, cmd);

sym53c8xx_comm.h:699:static int __map_scsi_sg_data(struct device *dev, Scsi_Cmnd *cmd)
...
sym53c8xx_comm.h:708:	use_sg = dma_map_sg(dev, cmd->buffer, cmd->use_sg, dma_dir);


asm/dma-mapping.h:91:static inline int
asm/dma-mapping.h:92:dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
asm/dma-mapping.h:93:           enum dma_data_direction direction)
asm/dma-mapping.h:94:{
asm/dma-mapping.h:95:        return hppa_dma_ops->map_sg(dev, sg, nents, direction);
asm/dma-mapping.h:96:}

Then search for hppa_dma_ops in arch/parisc/kernel/* and drivers/parisc/*.c
to locate the various platform/chipset DMA support:

grundler <553>fgrep -n hppa_dma_ops arch/parisc/kernel/*c drivers/parisc/*
arch/parisc/kernel/drivers.c:30:struct hppa_dma_ops *hppa_dma_ops;
arch/parisc/kernel/drivers.c:31:EXPORT_SYMBOL(hppa_dma_ops);
arch/parisc/kernel/pci-dma.c:492:struct hppa_dma_ops pcxl_dma_ops = {
arch/parisc/kernel/pci-dma.c:533:struct hppa_dma_ops pcx_dma_ops = {
arch/parisc/kernel/setup.c:96:          hppa_dma_ops = &pcx_dma_ops;
arch/parisc/kernel/setup.c:101:         hppa_dma_ops = &pcxl_dma_ops;
drivers/parisc/ccio-dma.c:1009:static struct hppa_dma_ops ccio_ops = {
drivers/parisc/ccio-dma.c:1545: hppa_dma_ops = &ccio_ops;
drivers/parisc/ccio-rm-dma.c:183:       hppa_dma_ops = &ccio_ops;
drivers/parisc/sba_iommu.c:1177:static struct hppa_dma_ops sba_ops = {
drivers/parisc/sba_iommu.c:1809:        hppa_dma_ops = &sba_ops;

Ideally, "make" would detect when support for only one chipset is
needed and just do away with hppa_dma_ops completely (ie directly
call into the chipset specific function).

> Thanks in advance,
> 	Joel
> 
> PS: btw I noticed that ncr_attach() is still prefix by __init where 
> sym_attach() is now prefix by __devinit. I trust it is important but could 
> it be the simple reason of pb encounter?

IIRC, the difference is for hotplug.
__devinit section is preserved when CONFIG_HOTPLUG is enabled.
See linux/Documentation/pci.txt for the real description.

grant

[parisc-linux] Re: kernel>=2.6.4-rc3 hung or panic on C1[18]0

[Joel Soete]

Grant Grundler wrote:
> On Sat, Apr 24, 2004 at 08:52:37PM +0000, Joel Soete wrote:
> 
>>Hello Grant,
>>
>>Sorry in advance to disturbe you with this c110 pb but if I well understand 
>>the physical connection (fine doc find on openpa.net :) and better 
>>understand what james means, otc I past the full last week to study more 
>>ccio-dma and ncr53c8xx but I don't reach to locate the part of code making 
>> the link between those 2 part (i mean where ncr call ccio and visversa). 
>> Could you help me a bit more.
> 
> 
> Yup. Using 2.6.5-pa8 source tree, ncr53c8xx.c calls DMA services from
> ncr_scatter():
> 
> ncr53c8xx.c:7594:	u_long baddr = map_scsi_single_data(np, cmd);
> 
> sym53c8xx_comm.h:699:static int __map_scsi_sg_data(struct device *dev, Scsi_Cmnd *cmd)
> ...
> sym53c8xx_comm.h:708:	use_sg = dma_map_sg(dev, cmd->buffer, cmd->use_sg, dma_dir);
> 
> 
> asm/dma-mapping.h:91:static inline int
> asm/dma-mapping.h:92:dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
> asm/dma-mapping.h:93:           enum dma_data_direction direction)
> asm/dma-mapping.h:94:{
> asm/dma-mapping.h:95:        return hppa_dma_ops->map_sg(dev, sg, nents, direction);
> asm/dma-mapping.h:96:}
> 
> Then search for hppa_dma_ops in arch/parisc/kernel/* and drivers/parisc/*.c
> to locate the various platform/chipset DMA support:
> 
> grundler <553>fgrep -n hppa_dma_ops arch/parisc/kernel/*c drivers/parisc/*
> arch/parisc/kernel/drivers.c:30:struct hppa_dma_ops *hppa_dma_ops;
> arch/parisc/kernel/drivers.c:31:EXPORT_SYMBOL(hppa_dma_ops);
> arch/parisc/kernel/pci-dma.c:492:struct hppa_dma_ops pcxl_dma_ops = {
> arch/parisc/kernel/pci-dma.c:533:struct hppa_dma_ops pcx_dma_ops = {
> arch/parisc/kernel/setup.c:96:          hppa_dma_ops = &pcx_dma_ops;
> arch/parisc/kernel/setup.c:101:         hppa_dma_ops = &pcxl_dma_ops;
> drivers/parisc/ccio-dma.c:1009:static struct hppa_dma_ops ccio_ops = {
> drivers/parisc/ccio-dma.c:1545: hppa_dma_ops = &ccio_ops;
> drivers/parisc/ccio-rm-dma.c:183:       hppa_dma_ops = &ccio_ops;
> drivers/parisc/sba_iommu.c:1177:static struct hppa_dma_ops sba_ops = {
> drivers/parisc/sba_iommu.c:1809:        hppa_dma_ops = &sba_ops;
> 
> Ideally, "make" would detect when support for only one chipset is
> needed and just do away with hppa_dma_ops completely (ie directly
> call into the chipset specific function).
> 
> 
>>Thanks in advance,
>>	Joel
>>
>>PS: btw I noticed that ncr_attach() is still prefix by __init where 
>>sym_attach() is now prefix by __devinit. I trust it is important but could 
>>it be the simple reason of pb encounter?
> 
> 
> IIRC, the difference is for hotplug.
> __devinit section is preserved when CONFIG_HOTPLUG is enabled.
> See linux/Documentation/pci.txt for the real description.
> 
> grant
> 
Great.

Many thanks,
	Joel