Bug 112427 - Fix recounting of scatter-gather elements
Summary: Fix recounting of scatter-gather elements
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: s390
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-19 16:09 UTC by Ingolf Salm
Modified: 2007-11-30 22:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-02 21:58:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ingolf Salm 2003-12-19 16:09:21 UTC
Description of problem:

Status:		05.09.2003	someon else reported this problem on 
linux-scsi mailing list,
				posted our patch along with 
		11.09.2003	neither was the problem reproduced 
nor was our fix tested by community
				-> no response on fix from linux-scsi 
mailing list even after
				    further enquiries from IBM and 

[prev in list] [next in list] [prev in thread] [next in thread] 

List:     linux-scsi
Subject:  Re: Kernel panic - Ththththaats all folks
From:     "Martin Peschke3" <MPESCHKE () de ! ibm ! com>
Date:     2003-09-05 20:47:16
[Download message RAW]

We have also seen that panic sporadically with the zfcp lldd
on zSeries. We tracked it down as a situation when a data buffer
is only partially transferred and the request is being requeued
to retrieve the remaining data. Then segment counting needs to
be done before adding a request to the block layer queue again.
The following patch moves segment recounting.
Could you give it a try?


>>>>> please find patch on mailing list


Sulamita Garcia <sulagarcia@yahoo.com.br>@vger.kernel.org on 

Sent by:    linux-scsi-owner@vger.kernel.org

To:    linux-scsi@vger.kernel.org
Subject:    Kernel panic - Ththththaats all folks


I have a RocketRAID 404 (HPT374) controller adapter on
a RedHat 9.0 box. I compiled a new fresh kernel
2.4.22, because errors I get with 2.4.20 from
instalation default, and rebuild module from source
because kernel module didn't work. Now I have a Raid 0
by hardware, which is a 800Gb partition. I formated
this as ext3, and for while, was good.
But I doing this for a high availabity cluster, with
drbd (mirroring). And I can't sync machines, I get
this kernel panic:

Incorrect number of segments after building list
nr_segments is 10
counted segments is 1
Flags 0 0
Kernel Panic: Ththththaats all folks. To dangerous to
In interrupt handler - not syncing.

I found this message in scsi_merge, and I don't know
that did it mean. It's kernel problem, scsi problem,
chipset problem, or what?


Sulamita Garcia

Comment 2 Pete Zaitcev 2004-01-08 04:30:12 UTC
Doug's mqueue update fixed this for Taroon U1, I am pretty sure.
It was in the huge pile of "38". Either Martin P. is confused,
or Ingolf, or both. I'll dig out how it works from my records.

Comment 3 Tim Burke 2004-01-08 12:59:24 UTC
Ingolf: which version of the kernel is this problem exhibited on? 
Have you tried the latest U1 kernel?  If the problem did reproduce on
the latest kernel, did you then apply the specific patch you refer to,
rebuild and demonstrate that this patch addresses the problem?  Reason
I ask, is because there were changes along the lines of this issue
which did go into U1.  

Comment 5 Doug Ledford 2004-01-08 14:58:32 UTC
This should already be fixed in the U1 kernel.  The fix is contained
in the linux-2.4.18-smallpatches.patch patch file in the U1 kernel src
rpm files.

Comment 7 Doug Ledford 2004-01-08 19:43:25 UTC
Should just work.

Comment 8 Doug Ledford 2004-01-08 19:44:14 UTC
Setting state to modified since the proposed fix is already in the U1

Comment 9 Ingolf Salm 2004-01-16 14:26:04 UTC
If fix is in U1, bugzilla can be closed.

Comment 10 Suzanne Hillman 2004-03-02 21:58:18 UTC
It has been over a month since the last comment in here, so I'm going
to presume that IBM is happy with this, and close it. If not, please
reopen with additional information!

Note You need to log in before you can comment on or make changes to this bug.