Re: sparc32: git SCSI and fs

Re: sparc32: git SCSI and fs

[David Miller]

From: Raymond Burns <rayburns@comcast.net>
Date: Wed, 19 Jul 2006 13:47:09 -0700 (PDT)

> Request for IRQ45 (ESP SCSI) SA_STATIC_ALLOC failed using kmalloc
> 
> appears benign, guess I'm sensative to the word failed.

This needs investigation.

> VFS: Mounted root (ext2 filesystem) readonly.
> 
> is fine but 
> 
> EXT2-fs error (device sdc3): ext2_check_page: bad entry in directory
> #2: unaligned directory entry - offset=0, inode ƒ918864,
> rec_lenB42, name_len=0
> 
> the file system itself should be fine, 2.4.32 is running on it
> currently

Looks like there is something wrong with ESP on your sun4d,
that error should never occur on a good filesystem.
I doubt anything is wrong with EXT2.

sparc32: git SCSI and fs

[Raymond Burns]

Hi

during scsi initialization the message 

Request for IRQ45 (ESP SCSI) SA_STATIC_ALLOC failed using kmalloc

appears benign, guess I'm sensative to the word failed.


VFS: Mounted root (ext2 filesystem) readonly.

is fine but 

EXT2-fs error (device sdc3): ext2_check_page: bad entry in directory
#2: unaligned directory entry - offset=0, inode ƒ918864,
rec_lenB42, name_len=0

the file system itself should be fine, 2.4.32 is running on it
currently

this is non-SMP and my erroneous slab path reversed.

access to the disks fail so user land is unreachable


I have the feeling ext2 is not a good choice for sparc, are there
suggestions.

the ext2 will probably still need to work, I'm digging.


Thanx
  Ray

Re: sparc32: git SCSI and fs

[David Miller]

From: Raymond Burns <rayburns@comcast.net>
Date: Wed, 19 Jul 2006 19:50:18 -0700 (PDT)

> there is one improper call to request_irq() in sunzilog_init() where
> it looks for zilog_irq != -1, it should be equal -1 to request

I think you have the understanding reversed.

The zilog_irq starts out with the value -1.  If we probe any zilog
devices it will be set to the IRQ of that device, and therefore it
will be something other than -1 if we have an IRQ handler to register.

Re: sparc32: git SCSI and fs

[Raymond Burns]

On Wed, 19 Jul 2006, David Miller wrote:

> > Request for IRQ45 (ESP SCSI) SA_STATIC_ALLOC failed using kmalloc
> 
> This needs investigation.

This is the fifth call to request_irq() so I guess it is correct
(esp2-5 get kmalloc())

there is one improper call to request_irq() in sunzilog_init() where
it looks for zilog_irq != -1, it should be equal -1 to request

> 
> > VFS: Mounted root (ext2 filesystem) readonly.
> > 
> > is fine but 
> > 
> > EXT2-fs error (device sdc3): ext2_check_page: bad entry in directory
> > #2: unaligned directory entry - offset=0, inode ƒ918864,
> > rec_lenB42, name_len=0
> > 
> Looks like there is something wrong with ESP on your sun4d,
> that error should never occur on a good filesystem.
> I doubt anything is wrong with EXT2.

I concur.
 
I'm digging.

Thanx
  Ray

Re: sparc32: git SCSI and fs

[Raymond Burns]

On Wed, 19 Jul 2006, David Miller wrote:

> From: Raymond Burns <rayburns@comcast.net>
> Date: Wed, 19 Jul 2006 19:50:18 -0700 (PDT)
> 
> The zilog_irq starts out with the value -1.  If we probe any zilog
> devices it will be set to the IRQ of that device, and therefore it
> will be something other than -1 if we have an IRQ handler to register.

Then should zs_probe not be calling request_irq() when it sets
zilog_irq to op->irqs[0]

currently zsprobe calls request_irq() when static_irq is 1 allocating 
static_irqaction[1] to the irq zilog_irq.

sunzilog_init() then calls request_irq() a second time assigning the
same irq with the next static_irq, static_irqaction[2]


Thanx
  Ray

Re: sparc32: git SCSI and fs

[David Miller]

From: Raymond Burns <rayburns@comcast.net>
Date: Wed, 19 Jul 2006 20:44:14 -0700 (PDT)

> Then should zs_probe not be calling request_irq() when it sets
> zilog_irq to op->irqs[0]

That's the bug, good spotting.  Just remove that call
in zs_probe().

Re: sparc32: git SCSI and fs

[Raymond Burns]

On Wed, 19 Jul 2006, David Miller wrote:

> > EXT2-fs error (device sdc3): ext2_check_page: bad entry in directory
> > #2: unaligned directory entry - offset=0, inode ƒ918864,
> > rec_lenB42, name_len=0
> > 
> Looks like there is something wrong with ESP on your sun4d,
> that error should never occur on a good filesystem.
> I doubt anything is wrong with EXT2.
> 

I enabled some of the esp debug facility, the only item that stands
out is:

esp_work_bus: esp_do_data_finale: trans_sz(4096), bytes_sent(4096),
!bogus_data, to new phase

It looks like !bogus_data occurs on all data requests

Is it a wild goose or something to check?

esp0: IRQ 44 SCSI ID 7 Clk 40MHz CCYC%000 CCF=8 TOut 167
NCR53C9XF(espfast)
esp0: FAST chip is fas236 (family=2, version=3)

drives are:
  Vendor: SEAGATE   Model: ST32550N SUN2.1G  Rev: 0416


Thanx
  Ray

Re: sparc32: git SCSI and fs

[David Miller]

From: Raymond Burns <rayburns@comcast.net>
Date: Fri, 21 Jul 2006 15:00:18 -0700 (PDT)

> On Wed, 19 Jul 2006, David Miller wrote:
> 
> > > EXT2-fs error (device sdc3): ext2_check_page: bad entry in directory
> > > #2: unaligned directory entry - offset=0, inode ƒ918864,
> > > rec_lenB42, name_len=0
> > > 
> > Looks like there is something wrong with ESP on your sun4d,
> > that error should never occur on a good filesystem.
> > I doubt anything is wrong with EXT2.
> > 
> 
> I enabled some of the esp debug facility, the only item that stands
> out is:
> 
> esp_work_bus: esp_do_data_finale: trans_sz(4096), bytes_sent(4096),
> !bogus_data, to new phase
> 
> It looks like !bogus_data occurs on all data requests
> 
> Is it a wild goose or something to check?

!bogus_data is a normal condition

Re: sparc32: git SCSI and fs

[David Miller]

I don't think you'll get very far debugging the ESP driver.
More likely DMA is being corrupted or similar, and this
means you should fiddle around in the sun4d IOMMU support
code for SBUS and make sure nothing fishy is going on there.

Re: sparc32: git SCSI and fs

[Chris Newport]

David Miller wrote:

>I don't think you'll get very far debugging the ESP driver.
>More likely DMA is being corrupted or similar, and this
>means you should fiddle around in the sun4d IOMMU support
>code for SBUS and make sure nothing fishy is going on there.
>-
>To unsubscribe from this list: send the line "unsubscribe sparclinux" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  
>
A year or so ago I did a few patches for Sun4d and there was a note in 
the iommu code about sun4d not having a register that was used for 
scratch data in sun4m.
Could this bug be back ?

Sorry to be vague, this is from memory.

Re: sparc32: git SCSI and fs

[Raymond Burns]

On Fri, 21 Jul 2006, David Miller wrote:

> 
> I don't think you'll get very far debugging the ESP driver.
> More likely DMA is being corrupted or similar, and this
> means you should fiddle around in the sun4d IOMMU support
> code for SBUS and make sure nothing fishy is going on there.

Thats the hint I'm looking for, Thank You  :)

Thanx
  Ray

Re: sparc32: git SCSI and fs

[David Miller]

From: Chris Newport <crn@netunix.com>
Date: Fri, 21 Jul 2006 23:03:31 +0100

> A year or so ago I did a few patches for Sun4d and there was a note in 
> the iommu code about sun4d not having a register that was used for 
> scratch data in sun4m.
> Could this bug be back ?
> 
> Sorry to be vague, this is from memory.

It would be nice to have something specific, I see nothing
explicit in the current tree:

arch/sparc/kernel/entry.S:	 * %l5 -- scratch for ld/st address
arch/sparc/kernel/entry.S:	 * %l7 -- scratch [floppy byte, ld/st address, aux. data]
arch/sparc/kernel/wuf.S:/* Now macros for the available scratch registers in this routine. */

Re: sparc32: git SCSI and fs

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Wed, 19 Jul 2006 13:42:05 -0700 (PDT)

> From: Raymond Burns <rayburns@comcast.net>
> Date: Wed, 19 Jul 2006 13:47:09 -0700 (PDT)
> 
> > Request for IRQ45 (ESP SCSI) SA_STATIC_ALLOC failed using kmalloc
> > 
> > appears benign, guess I'm sensative to the word failed.
> 
> This needs investigation.

The problem is that SA_STATIC_ALLOC aliases another irq flag
value, IRQF_SHARED, which is commonly used.

Let's just use the following fix for now.  We should kill this
thing off eventually.

diff --git a/include/asm-sparc/signal.h b/include/asm-sparc/signal.h
index 0ae5084..d03a21c 100644
--- a/include/asm-sparc/signal.h
+++ b/include/asm-sparc/signal.h
@@ -168,7 +168,7 @@ struct sigstack {
  * statically allocated data.. which is NOT GOOD.
  *
  */
-#define SA_STATIC_ALLOC		0x80
+#define SA_STATIC_ALLOC		0x8000
 #endif
 
 #include <asm-generic/signal.h>

Re: sparc32: git SCSI and fs

[Chris Newport]

David Miller wrote:

>From: Chris Newport <crn@netunix.com>
>Date: Fri, 21 Jul 2006 23:03:31 +0100
>
>  
>
>>A year or so ago I did a few patches for Sun4d and there was a note in 
>>the iommu code about sun4d not having a register that was used for 
>>scratch data in sun4m.
>>Could this bug be back ?
>>
>>Sorry to be vague, this is from memory.
>>    
>>
>
>It would be nice to have something specific, I see nothing
>explicit in the current tree:
>
>  
>
I have not been able to find the file with the relevant comment, but 
looking back in my mail archive, it seems to relate to this code in 
2.4.26 include/asm-sparc/winmacro.h, looks like jj has created a workaround.
Maybe need to look at earlier 2.4 versions before the comment got dropped.

#ifdef CONFIG_SMP
#define LOAD_CURRENT4M(dest_reg, idreg) \
        rd       %tbr, %idreg; \
        sethi    %hi(C_LABEL(current_set)), %dest_reg; \
        srl      %idreg, 10, %idreg; \
        or       %dest_reg, %lo(C_LABEL(current_set)), %dest_reg; \
        and      %idreg, 0xc, %idreg; \
        ld       [%idreg + %dest_reg], %dest_reg;

/* Sliiick. We have a Linux current register :) -jj */
#define LOAD_CURRENT4D(dest_reg) \
        lda      [%g0] ASI_M_VIKING_TMP2, %dest_reg;

/* Blackbox - take care with this... - check smp4m and smp4d before 
changing thi
s. */