Red Hat Bugzilla – Bug 112427
Fix recounting of scatter-gather elements
Last modified: 2007-11-30 17:06:59 EST
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]
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 <firstname.lastname@example.org>@vger.kernel.org on
Sent by: email@example.com
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?
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.
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.
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
Should just work.
Setting state to modified since the proposed fix is already in the U1
If fix is in U1, bugzilla can be closed.
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!