Description of problem: Status: 05.09.2003 someon else reported this problem on linux-scsi mailing list, posted our patch along with description, 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 RedHat ---------------------------------------------------------------------- ---------------- [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? regards, Martin >>>>> please find patch on mailing list } Sulamita Garcia <sulagarcia.br>@vger.kernel.org on 05/09/2003 11:01:00 Sent by: linux-scsi-owner.org To: linux-scsi.org cc: Subject: Kernel panic - Ththththaats all folks Hi 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 continue 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? Thanks Sulamita Garcia
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 rpm files.
Should just work.
Setting state to modified since the proposed fix is already in the U1 kernel.
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!