New: kernel panic in stex modules (?)

Bugme-new Andrew Morton 3 participants 3 messages Feb 6, 2008 – Feb 7, 2008 1 message not in the archive

Subsystems (2)

SCSI libata

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author

2008-02-06 18:15 UTC #1 lore raw

Quoted 36 lines · On Wed, 6 Feb 2008 09:40:15 -0800 (PST) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=9901
Summary: kernel panic in stex modules (?)
Product: IO/Storage
Version: 2.5
KernelVersion: 2.6.24
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Serial ATA
AssignedTo: [email protected]
ReportedBy: [email protected]
Latest working kernel version: 2.6.23-r6
Earliest failing kernel version: 2.6.24
Distribution: Gentoo
Hardware Environment: Core2D E6600, Asus p5B Dlx, 2G DDR2 667, Promise ST EX4350
Software Environment: GCC 4.2.3/4.1.2, CFLAGS="-O2"
Problem Description:
The problem is frequent kernel panics within the same module. Can't say what it is, but looks like it is related to dma and promise driver.
The first culprit, the memory, is ok, 8 hours of memtest passed without errors. Before, kernel 2.6.23-gentoo-r6, compiled with GCC 4.1.2 worked just fine, then after upgrade to 4.2.2 th bug appeared. Upgrade to 2.6.24 didn't solve the problem. Switching back to GCC 4.1.2 made things better for a moment, crashes became less frequent and I thought compiler was the cause. But today system crashed again with same symptoms.
Sorry, but I can't save crash log, so I'll provide screen "shot":
http://img238.imageshack.us/my.php?image=p2030030ki1.jpg

Quoted 5 lines

Steps to reproduce:
Boot, start FTP-server, load RAID with heavy input, in some hours it will crash. With pure reads system can run several days, heavy write load kills it much too easier.

The supertrak driver has regressed in 2.6.24. And

commit 9cb83c7529d929c00f37d821daed1942a1b20602

Author: FUJITA Tomonori <[email protected]>
Date:   Tue Oct 16 11:24:32 2007 +0200

[SCSI] add use_sg_chaining option to scsi_host_template

looks a likely candidate.

And this:

commit d3f46f39b7092594b498abc12f0c73b0b9913bde

Author: James Bottomley <[email protected]>
Date:   Tue Jan 15 11:11:46 2008 -0600

[SCSI] remove use_sg_chaining

from 2.6.25 looks to be a likely fix for it. Should it be backported?

James Bottomley

maintainer

2008-02-06 18:26 UTC #2 lore raw

Quoted 56 lines · Andrew Morton

Quoted 36 lines · On Wed, 6 Feb 2008 09:40:15 -0800 (PST) [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9901
Summary: kernel panic in stex modules (?)
Product: IO/Storage
Version: 2.5
KernelVersion: 2.6.24
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Serial ATA
AssignedTo: [email protected]
ReportedBy: [email protected]
Latest working kernel version: 2.6.23-r6
Earliest failing kernel version: 2.6.24
Distribution: Gentoo
Hardware Environment: Core2D E6600, Asus p5B Dlx, 2G DDR2 667, Promise ST EX4350
Software Environment: GCC 4.2.3/4.1.2, CFLAGS="-O2"
Problem Description:
The problem is frequent kernel panics within the same module. Can't say what it is, but looks like it is related to dma and promise driver.
The first culprit, the memory, is ok, 8 hours of memtest passed without errors. Before, kernel 2.6.23-gentoo-r6, compiled with GCC 4.1.2 worked just fine, then after upgrade to 4.2.2 th bug appeared. Upgrade to 2.6.24 didn't solve the problem. Switching back to GCC 4.1.2 made things better for a moment, crashes became less frequent and I thought compiler was the cause. But today system crashed again with same symptoms.
Sorry, but I can't save crash log, so I'll provide screen "shot":
http://img238.imageshack.us/my.php?image=p2030030ki1.jpg
Quoted 5 lines
Steps to reproduce:
Boot, start FTP-server, load RAID with heavy input, in some hours it will crash. With pure reads system can run several days, heavy write load kills it much too easier.
The supertrak driver has regressed in 2.6.24. And
commit 9cb83c7529d929c00f37d821daed1942a1b20602
Author: FUJITA Tomonori <[email protected]>
Date:   Tue Oct 16 11:24:32 2007 +0200
[SCSI] add use_sg_chaining option to scsi_host_template
looks a likely candidate.
And this:

Quoted 7 lines

commit d3f46f39b7092594b498abc12f0c73b0b9913bde
Author: James Bottomley <[email protected]>
Date:   Tue Jan 15 11:11:46 2008 -0600
[SCSI] remove use_sg_chaining
from 2.6.25 looks to be a likely fix for it. Should it be backported?

If the patch you identify is the culprit, mine can't be the fix ... and it should also be present in git head.

The BUG_ON is here: isn't it?

static inline void
dma_unmap_sg(struct device *hwdev, struct scatterlist *sg, int nents,
int direction)

{
	BUG_ON(!valid_dma_direction(direction));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	dma_ops->unmap_sg(hwdev, sg, nents, direction);
}

stex only does scsi_dma_unmap(), so something looks to have tampered with the cmnd->sc_data_direction somehow ... and I can't see how.

James

FUJITA Tomonori

2008-02-07 01:02 UTC #3 lore raw

Quoted 73 lines · On Wed, 06 Feb 2008 12:26:39 -0600 James Bottomley…

Quoted 56 lines · Andrew Morton
Quoted 36 lines · On Wed, 6 Feb 2008 09:40:15 -0800 (PST) [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9901
Summary: kernel panic in stex modules (?)
Product: IO/Storage
Version: 2.5
KernelVersion: 2.6.24
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Serial ATA
AssignedTo: [email protected]
ReportedBy: [email protected]
Latest working kernel version: 2.6.23-r6
Earliest failing kernel version: 2.6.24
Distribution: Gentoo
Hardware Environment: Core2D E6600, Asus p5B Dlx, 2G DDR2 667, Promise ST EX4350
Software Environment: GCC 4.2.3/4.1.2, CFLAGS="-O2"
Problem Description:
The problem is frequent kernel panics within the same module. Can't say what it is, but looks like it is related to dma and promise driver.
The first culprit, the memory, is ok, 8 hours of memtest passed without errors. Before, kernel 2.6.23-gentoo-r6, compiled with GCC 4.1.2 worked just fine, then after upgrade to 4.2.2 th bug appeared. Upgrade to 2.6.24 didn't solve the problem. Switching back to GCC 4.1.2 made things better for a moment, crashes became less frequent and I thought compiler was the cause. But today system crashed again with same symptoms.
Sorry, but I can't save crash log, so I'll provide screen "shot":
http://img238.imageshack.us/my.php?image=p2030030ki1.jpg
Quoted 5 lines
Steps to reproduce:
Boot, start FTP-server, load RAID with heavy input, in some hours it will crash. With pure reads system can run several days, heavy write load kills it much too easier.
The supertrak driver has regressed in 2.6.24. And
commit 9cb83c7529d929c00f37d821daed1942a1b20602
Author: FUJITA Tomonori <[email protected]>
Date:   Tue Oct 16 11:24:32 2007 +0200
[SCSI] add use_sg_chaining option to scsi_host_template
looks a likely candidate.
And this:
Quoted 7 lines
commit d3f46f39b7092594b498abc12f0c73b0b9913bde
Author: James Bottomley <[email protected]>
Date:   Tue Jan 15 11:11:46 2008 -0600
[SCSI] remove use_sg_chaining
from 2.6.25 looks to be a likely fix for it. Should it be backported?
If the patch you identify is the culprit, mine can't be the fix ... and it should also be present in git head.
The BUG_ON is here: isn't it?
static inline void
dma_unmap_sg(struct device *hwdev, struct scatterlist *sg, int nents,
int direction)

Quoted 8 lines

{
	BUG_ON(!valid_dma_direction(direction));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	dma_ops->unmap_sg(hwdev, sg, nents, direction);
}
stex only does scsi_dma_unmap(), so something looks to have tampered with the cmnd->sc_data_direction somehow ... and I can't see how.

Surely, someone changes the cmnd->sc_data_direction, or else we should be hit by dma_map_sg before dma_unmap_sg:

static inline int
dma_map_sg(struct device *hwdev, struct scatterlist *sg, int nents, int direction)

{
	BUG_ON(!valid_dma_direction(direction));
	return dma_ops->map_sg(hwdev, sg, nents, direction);
}