From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chiaki Subject: Re: TMSCSIM [2.6] Date: Wed, 26 Nov 2003 07:44:38 +0900 Sender: linux-scsi-owner@vger.kernel.org Message-ID: <3FC3DB56.6020104@yk.rim.or.jp> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from pl901.nas911.n-yokohama.nttpc.ne.jp ([210.139.42.133]:38349 "EHLO standard.erephon") by vger.kernel.org with ESMTP id S263274AbTKYWpE (ORCPT ); Tue, 25 Nov 2003 17:45:04 -0500 Received: from (client is using the wrong hostname!) yk.rim.or.jp (really [127.0.0.1]) by yk.rim.or.jp via smail with esmtp id (Debian Smail3.2.0.115) for ; Wed, 26 Nov 2003 07:44:57 +0900 (JST) In-Reply-To: List-Id: linux-scsi@vger.kernel.org To: Guennadi Liakhovetski Cc: linux-scsi@vger.kernel.org Guennadi Liakhovetski wrote: > On Wed, 26 Nov 2003, Chiaki wrote: > > >>I am using TEKRAM dc390. I use tmscsim driver as a module. >>There is a PD/CD combo on the dc390 scsi bus. (PD is >>a somewhat outdated optomagnetic drive. The drive has >>two LUNs, one for CD, and one for PD. PD side is recognized as >>rewritable removable media at least under 2.4.22.) >> >>With the modified tmscsim driver under 2.6.0-test10, >>(the bzipped patch submitted to linux-scsi worked without rejection) >>I got a panic after module insertion during booting. >>tmscsim is mentioned in /etc/modules and so inserted automatically >>during booting. >> >>(More background: related stuff I can think of. >> kernel 2.6.0-test10. >> tmscsim ... used as module >> sr ... module as sr_mod >> event mechanism enabled in the kernel. >> gcc 3.3 used...) >> >>Here is the panic message left on the screen which I scribbed down >>manually. >> >> ... anything above is scrolled and disappeared but I saw the >> module insertion began. ... >>esi: ef63a2f0 edi: 00000001 ebp: c03a5e4c esp: c03a5e3c >>ds: 007b es: 007b ss: 0068 >> >>Process swapper (pid:0, threadinfo = c03a4000, task=c0338680) >> >>Stack: 00000000 ef63a2f0 efc617c0 ef5e92c0 c0ea5e8c f09451d1 ef63a2f0 >>ef63a2f0 >> ef5e92c0 ef5e92c0 c03a5ea4 f09451d1 ef63a2f0 4f89f21d 00000021 >>00000001 >> cc000092 ef63a2f0 efc617c0 ef63a208 c03a5ec4 f0946e36 ef63a208 >>ef5e92c0 >> >>Call trace: >> [] dc390_StartSCCSI+0x41/0x330 [tmscsim] >> [] dc390_StartSCCSI+0x41/0x330 [tmscsim] >> [] dc390_SRBdone+0x306/0x5b0 [tmscsim] >> [] dc390_RequestSense+0x53/0x90 [tmscsim] >> [] dc390_Disconnect+0x104/0x160 [tmscsim] >> [] do_DC390_Interrupt:0x28d/0x350 [tmscsim] >> [] scsi_softirq+0xe8/0x240 >> [] handle_IRQ_event:0x3b/0x70 >> [] do_IRQ+0x140/0x390 >> [] _stext+0x0/0xf0 >> [] common_interrupt:0x18/0x20 >> [] _stext+0x0/0xf0 >> [] default_idel+0x26/0x30 >> [] cpu_idle+0x34/0x40 >> [] start_kernel+0x1e7/0x270 >> [] unknown_bootoption+0x0/0x100 >> >>Code: 0f 0b 28 00 77 9d 94 f0 eb c5 0f 0b 25 00 77 9d 94 f0 eb e8 >> >><0> Kernel panic: Fatal exception in interrupt >> In interrupt handler --- not syncing > > > Aha, now that's getting interesting - or I was started to feel borref > already:-) A couple of things, that would definitely help: > Hi, > 1) is this the only computer you have? If you had another one - could you > attach a serial console and get a complete Oops? I will try this later today. > 2) gcc-3.3 could be ok, but I don't really feel quite secure about it... > If we don't find an obvious bug somewhere, I'll ask you to try recompile > it with 2.95.3, ok? No problem. I will try this also. > 3) are you sure you copied the Oops exactly from the terminal? It didn't > get into /var/log/messages, I presume. Some things in that Oops above look > a bit strange... E.g. the double As far as manual copying goes, I did my best. Indeed, I noticed the duplicate lines and I thought that was quite strange! I suspect that it might lead to the cause of the problem. > I'll try to think about it a bit, but without a complete and exact Oops it > is a bit difficult, also, that the code, generated by your 3.3 seems to be > very different, from what 2.95.3 produces. Your .config (bzipped) could be > useful too. I guess, you have the multiple LUNs option enabled, I'll try > that too, but my hardware is very different from what you have there - > just a AM53C974 and a single hard-drive on it. > I will try to capture the complete oops and send it as well as the .config file together. Yes, my hardware is a rather quirky kind for home use and it has found a few problems in the kernel and driver before. I will get back with the information hopefully in 24 hours. >>OBSERVATION: >> >> alt sysreq magic key combination worked. >> I could run emergency sync and reboot. >> >> From the kernel panic message, and the call trace, it looks to >> me that the interrupt is recursively entered somehow. >> (Or unexpected interrupt came in.) >> >> >>So what next? >>I can enable debugging macro if necessary and re-try. >> >>Or, I can disable tmscsim module insertion during booting, >>and try "insmod tmscsim" after the kernel is up and running and >>see if it makes difference. >> >>(Under 2.6.0-test9, and manually fixed patched tmscsim files (due to >>whitespace problems of the patch), I could insert the tmscsim module >>but "insmod tmscsim" took unusually long time, but eventually >>returned. However, /proc/scsi/ didn't show the 2nd LUN of the >>PD/CD combo I have on dc390 bus. Maybe it was a problem of >>insertion of sr_mod due to my misconfiguration of module set up >>for 2.6.0-testXX which I believe is now corrected. >>Since immediately >>afterward when I tried automatic insertion of dc390 during booting, >>I got a similar panic which I reported above, I didn't pursue >>the insertion testing after the kernel is up and running. >>I thought fixing the panic of auto insertion needs to be handled first. >>But maybe I should re-try under test10 if this gives more insight.) > > > -- int main(void){int j=2003;/*(c)2003 cishikawa. */ char t[] =" @abcdefghijklmnopqrstuvwxyz.,\n\""; char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz"; while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1), (putchar(t[j])));return 0;}/* under GPL */