Re: [Scst-devel] Kernel Oops with qla2xxx

[Timm E. <Tim...@un...>]

Hi Vlad,

thanks, now it is clear for me and I think I can do it.

Since I didn't report the isp_mod bug so far properly, here is what I do:

rmmod qla2xxx
# no other qla* modules loaded, Qlogic firmware  5.03.07 as before
modprobe isp_scst
modprobe isp_mod isp_roles="800=initiator"
# probably I can leave the isp_roles parameter away, it is compiled with
# EXTRA_CFLAGS            +=      -DISP_TARGET_MODE=1 
-DISP_DEFAULT_ROLES=ISP_ROLE_INITIATOR
# in qla_isp/linux-2.6/build/Makefile

The kernel.log is attached again. I ran it through gdb with:

make perf2debug
make qla_isp

gdb /home/essigke/scst/trunk/qla_isp/linux-2.6/build/isp_mod.ko
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/essigke/scst/trunk/qla_isp/linux-2.6/build/isp_mod.ko...done.
(gdb) l isplinux_pci_probe+0xd15
Junk at end of line specification.
(gdb) l *isplinux_pci_probe+0xd15
0x21b45 is in isplinux_pci_probe (/home/essigke/scst/trunk/qla_isp/linux-2.6/build/isp_pci.c:957).
952     #if BYTE_ORDER == LITTLE_ENDIAN
953                 if (IS_24XX(isp)) {
954                     uint32_t *ptr = (uint32_t *)isp->isp_osinfo.fwp->data;
955                     int i;
956                     for (i = 0; i<  isp->isp_osinfo.fwp->size>>  2; i++) {
957                         ptr[i] = ISP_SWAP32(isp, ptr[i]);
958                     }
959                 } else {
960                     uint16_t *ptr = (uint16_t *)isp->isp_osinfo.fwp->data;
961                     int i;

Maybe you see a parallel to the qla2xxx problem and it helps you therefore.

Thanks,

Timm


On 08/25/2010 01:01 PM, Vladislav Bolkhovitin wrote:
> Hi Timm,
>
> Timm Essigke, on 08/25/2010 02:43 PM wrote:
>>> Could you do a bisecting and find on which revision was it broken?
>> What do you mean exactly?
>> I do not have the kernel on the server currently, because I completely
>> reinstalled it. Probably I could get the old kernel out of the backup.
>
> I mean, you know the version which works, so you know SVN revision 
> which works. Or we can find it. For instance, 1.0.0 is r439. You can 
> find SCST versions and revisions in the TAGS file in trunk/.
>
> You also know the revision which doesn't work. So, you can find 
> revision, which is responsible for the breakage. For that you should 
> take revision in the middle of the working and not working versions. 
> For instance, (1984(the latest) + 439(1.0.0))/2 = 1211. After you 
> check with it you will find if it works or not. Then, depending from 
> it the next revision to try would be either (1211+439)/2 = 825, or 
> (1211+1984)/2 = 1597. And so on until you know the breaking revision.
>
> I'll also take a look on the code based on the gdb output you sent me.
>
> Thanks!
> Vlad


-- 

========================================
Dr. Timm Essigke
Structural Biology/Bioinformatics
University of Bayreuth
Universitätsstr. 30, BGI
95447 Bayreuth
Germany

Telephone: +49-921-55-3547
Fax: +49-921-55-3071
e-mail: Tim...@un...
http://www.bisb.uni-bayreuth.de/
========================================