SATA: Panic in SCSI subsystem

[Adrian Bunk <bunk@stusta.de>]

Jeff, do you have any idea what might cause Haakon's problem?

TIA
Adrian

On Mon, Jan 02, 2006 at 02:35:07PM +0100, Haakon Riiser wrote:
> First of all, a little information on my current system:
> 
>   Distro: Fedora Core 3 (fully updated)
>   Kernel: 2.6.12-1.1381_FC3 (the bug also occurs on the latest 2.6.14 kernel
>           from Fedora Core 4)
>   Motherboard: Asus K8V SE Deluxe (Socket 754, VIA K8T800)
>   CPU: Sempron 3000+
>   Memory: 2 x TwinMOS 256 MB DDR400 (CL2.5)
>   PATA disk: Maxtor 6Y160P0
>   SATA disks: 4 x 250 GB Seagate Barracuda 7200.8 SATA NCQ
>   SATA controller: Promise SATA-II 150 TX4 PCI
> 
> The system boots from the PATA disk, which among other things
> contains the OS.  The four SATA disks are set up in a software
> RAID5 array using mdadm, and this is where I store all my important
> data.
> 
> Until recently, this file server contained a 650 MHz Pentium III
> CPU and an Asus P3B-F motherboard.  This configuration worked
> flawlessly.
> 
> After upgrading the motherboard/CPU/memory on my file server to
> the configuration listed on top, I started getting kernel panics
> in the SCSI subsystem.  Once it happens, the machine freezes
> completely, so I only have the logs that appear on screen.
> The following is copied down by hand, so I left out the full
> memory adresses preceeding each line in the stack trace:
> 
>   ata7: called with no error (51)!
>   Kernel panic - not syncing: drivers/scsi/scsi.c:297: spin_is_locked
>    on uninitialized spinlock deadc014. (Not tainted)
> 
>   panic+0x42/0x1c0
>   scsi_put_command+0x19c/0x2bf [scsi_mod]
>   scsi_next_command+0xc/0x14 [scsi_mod]
>   scsi_end_request+0xed/0x200 [scsi_mod]
>   mempool_free+0x67/0x1aa
>   scsi_io_completion+0x151/0x4d4 [scsi_mod]
>   sd_rw_intr+0x156/0x30f [sd_mod]
>   scsi_finish_command+0x8e/0xc1 [scsi_mod]
>   net_rx_action+0xbb/0x2bc
>   scsi_softirq+0x9d/0xcd [scsi_mod]
>   __do_softirq+0x3e/0x8a
>   do_softirq+0x39/0x40
>   =======================================
>   do_IRQ+0x53/0x85
>   common_interrupt+0x1a/0x20
>   acpi_processor_idle+0x01/0x27f
>   acpi_processor_idle+0x101/0x27f
>   cpu_idle+0x3c/0x51
>   start_kernel+0x175/0x1b1
>   unknown_bootoption+0x0/0x1b0
> 
> The above log isn't the same every time, but it always includes
> SCSI related stuff like scsi_finish_command.  I upgraded around
> a month ago, and until yesterday, it only crashed three or four
> times.  Now, after the last crash, the time between crashes has
> been reduced from about a week to about five minutes -- the system
> is completely unusable!  I noticed that every time I boot the
> system, the RAID array starts the resyncing process.  It always
> crashes before finishing, forcing it to start from scratch on
> every boot.  I'm guessing that the stress from the resync operation
> is what's causing it to crash within five minutes.  I don't know
> what prompted it to start resyncing in the first place, though.
> (Btw, how dangerous is a crash in the resync process?  Is there
> a high risk of data corruption?)
> 
> Until I know more, I have downgraded to my old CPU/motherboard.
> It's still resyncing, so I don't know if the problem has gone away,
> but it's been up for almost 100 minutes, and I still haven't seen a
> single "ataN: called with no error (51)!" that usually preceeds the
> kernel panic, so I think it's still working with my old hardware.
> 
> One last thing:  The new motherboard actually has four SATA
> connectors (two that connects to an onboard Promise TX2 controller,
> and two that connects to an onboard VIA controller), so I tried
> taking out my Promise TX4 card, and connecting the disks to the
> onboard connectors.  This didn't make any difference -- the system
> panics in exactly the same way as before.
> 
> Any help is greatly appreciated!
> 
> -- 
>  Haakon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/