Oops on alpha with 2.6.6 while loading aic7xxx driver

[Mathieu Chouquet-Stringer <mchouque@online.fr>]

[with the kernel version in the subject it's probably better]

	Hi,

I just freshly compiled 2.6.6 using gcc 3.4.0 (built as a cross-compiler on
i386) and the kernel oopses when it loads the module for the Adaptec scsi
card. As a side note, it works when the driver is built-in.

Here's the decoded oops:
=============>8=============>8=============>8=============>8=============>8
ksymoops 2.4.9 on alpha 2.6.6-rc3.  Options used
     -v vmlinux (specified)
     -k kallsyms (specified)
     -l modules (specified)
     -o /lib/modules/2.6.6 (specified)
     -m /boot/System-map-2.6.6 (specified)
     -x

Warning (read_ksyms): no kernel symbols in ksyms, is kallsyms a valid ksyms file?
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
1024K Bcache detected; load hit latency 30 cycles, load miss latency 121 cycles
Unable to handle kernel paging request at virtual address 47f10409b53e0008
modprobe(289): Oops 0
pc = [<fffffffc000beb74>]  ra = [<fffffffc000beb68>]  ps = 0000    Not tainted
Using defaults from ksymoops -t elf64-alpha -a alpha
v0 = 0000000000000001  t0 = 0000000000000010  t1 = 47f10409b53e0008
t2 = fffffc00011e0c00  t3 = 000000000000001e  t4 = 0000000000000020
t5 = 0000000000000000  t6 = fffffc00014616b0  t7 = fffffc003f7d4000
s0 = fffffc00011e0c00  s1 = fffffc003f545bc8  s2 = 0000000000000001
s3 = fffffffc000e0288  s4 = fffffc000077fb10  s5 = fffffc000073e688
s6 = fffffc003f7d7ab8
a0 = 00000000000003e8  a1 = fffffc003f7d7ab8  a2 = 000000000000000c
a3 = fffffc003f7d7a10  a4 = fffffc003f7d7a08  a5 = 0000000000000000
t8 = 0000000000000000  t9 = 00000000ffffffff  t10= 0000000000100100
t11= 0000000000200200  pv = fffffc000031e0e0  at = fffffc0000006d00
gp = fffffc000033ebd8  sp = fffffc003f7d7a48
Trace:fffffc00004abc78 fffffc00004da75c fffffc00004da974 fffffc00004dad84 fffffc00004db374 fffffc00004ab640 fffffc0000341868 fffffc0000312104 fffffc00003bc034 fffffc0000393944 fffffc000035aa6c 
Code: 47ff041f  345e0092  d35ffa0a  47e0040b  e4000030  a45d6c58 <a0220000> e4200006 


>>PC;  fffffffc000beb74 <END_OF_CODE+4380858791060/????>   <=====

Trace; fffffc00004abc78 <pci_device_probe+536/576>
Trace; fffffc00004da75c <bus_match+92/192>
Trace; fffffc00004da974 <driver_attach+148/272>
Trace; fffffc00004dad84 <bus_add_driver+180/320>
Trace; fffffc00004db374 <driver_register+52/80>
Trace; fffffc00004ab640 <pci_register_driver+112/240>
Trace; fffffc0000341868 <sys_init_module+472/6944>
Trace; fffffc0000312104 <entSys+164/192>
Trace; fffffc00003bc034 <ext3_dirty_inode+164/224>
Trace; fffffc0000393944 <__mark_inode_dirty+324/512>
Trace; fffffc000035aa6c <__vma_link_rb+60/80>

Code;  fffffffc000beb5c <END_OF_CODE+4380858791036/????>
0000000000000000 <_PC>:
Code;  fffffffc000beb5c <END_OF_CODE+4380858791036/????>
   0:   1f 04 ff 47       nop  
Code;  fffffffc000beb60 <END_OF_CODE+4380858791040/????>
   4:   92 00 5e 34       stw  t1,146(sp)
Code;  fffffffc000beb64 <END_OF_CODE+4380858791044/????>
   8:   0a fa 5f d3       bsr  ra,ffffffffffffe834 <_PC+0xffffffffffffe834>
Code;  fffffffc000beb68 <END_OF_CODE+4380858791048/????>
   c:   0b 04 e0 47       mov  v0,s2
Code;  fffffffc000beb6c <END_OF_CODE+4380858791052/????>
  10:   30 00 00 e4       beq  v0,d4 <_PC+0xd4>
Code;  fffffffc000beb70 <END_OF_CODE+4380858791056/????>
  14:   58 6c 5d a4       ldq  t1,27736(gp)
Code;  fffffffc000beb74 <END_OF_CODE+4380858791060/????>   <=====
  18:   00 00 22 a0       ldl  t0,0(t1)   <=====
Code;  fffffffc000beb78 <END_OF_CODE+4380858791064/????>
  1c:   06 00 20 e4       beq  t0,38 <_PC+0x38>


1 warning issued.  Results may not be reliable.
=============>8=============>8=============>8=============>8=============>8

Using objdump, kallsyms, I've been able to pinpoint the problem. The
closest function to fffffffc000beb74 is ahc_pci_config:
fffffffc000be5c0 t ahc_pci_config       [aic7xxx]
fffffffc000c02e0 t ahc_pci_intr [aic7xxx]

At the address fffffffc000beb74, we're in check_extport (called by
ahc_pci_config).

Here's the output of objdump (see how it matches the output of ksymoops):

/usr/src/kernel/linux-2.5/drivers/scsi/aic7xxx/aic7xxx_pci.c:1359
    22bc:       1f 04 ff 47     nop     
    22c0:       92 00 5e 34     stw     t1,146(sp)
/usr/src/kernel/linux-2.5/drivers/scsi/aic7xxx/aic7xxx_pci.c:1361
    22c4:       00 00 40 d3     bsr     ra,22c8 <ahc_pci_config+0x5a8>
    22c8:       0b 04 e0 47     mov     v0,s2
/usr/src/kernel/linux-2.5/drivers/scsi/aic7xxx/aic7xxx_pci.c:1362
    22cc:       30 00 00 e4     beq     v0,2390 <ahc_pci_config+0x670>
/usr/src/kernel/linux-2.5/drivers/scsi/aic7xxx/aic7xxx_pci.c:1364
    22d0:       00 00 5d a4     ldq     t1,0(gp)
    22d4:       00 00 22 a0     ldl     t0,0(t1)
    22d8:       06 00 20 e4     beq     t0,22f4 <ahc_pci_config+0x5d4>

fffffffc000beb74 is really 22d4. The interesting thing is the portion of C
code involved: 
1364:                if (bootverbose)
1365:                        printf("%s: Reading SEEPROM...", ahc_name(ahc));

So it looks like it chokes on bootverbose, any idea why?
-- 
Mathieu Chouquet-Stringer                 E-Mail: mchouque@online.fr
       Never attribute to malice that which can be adequately
                    explained by stupidity.
                     -- Hanlon's Razor --