ATA Promisc SX4 Controller Null Pointer deference at boot

From: Benjamin Close <cisbjc_at_cs.unisa.edu.au>
Date: Mon, 16 Aug 2004 13:50:52 +0930
Hi All,
    Working on a new machine I get a crash at boot time with sources 
from < 1 day old.
I've traced it down to a null pointer deference:

File: ata-chipset.c
Method:

static int
ata_promise_sx4_command(struct ata_device *atadev, u_int8_t command,
                        u_int64_t lba, u_int16_t count, u_int16_t feature)
{
    struct ata_channel *ch = atadev->channel;
    struct ata_dma_prdentry *prd = ch->dma->dmatab;
    struct ata_pci_controller *ctlr =
        device_get_softc(device_get_parent(ch->dev));
    caddr_t window = rman_get_virtual(ctlr->r_res1);
    u_int32_t *wordp;
    int i, idx, length = 0;

    if (command == ATA_ATA_IDENTIFY) {
        ATA_OUTL(ctlr->r_res2, 0x000c0400 + ((ch->unit + 1) << 2), 
0x00000001);
        return ata_generic_command(atadev, command, lba, count, feature);
    }

    if (ch->running->flags & ATA_R_CONTROL) {
    ...
    ...

Here "running" is NULL causing an obvious null pointer dereference.
Below is a hand transcribed report:

Fatal Trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x40
fault code = supervisor read, page not present
instruction pointer = 0x8:0c04bffd6
stack pointer = 0x10:0xc0c21be0
frame pointer = 0x10:0xc0c21bfc
code segment = base 0x0, limit 0xfffff, type 0x1b
    = DPL 0, pres1, def32 1, gran 1
processor eflags = interrupt enabled, resume IOPL=0
current process = 0 (swapper)
[thread 0]
stopped at ata_promise_sx4_command+0xf6: testb $0x1,0x40(%eax)

The Trace:
    ata_promise_sx4_command(c238c0a8,ef,0,0,c,3) at 
ata_promise_sx4_command+0xf6
    ata_generic_transaction(c26c82d0) at ata_generic_transaction+0xb7
    ata_start(c238c00,c238c120,0,c07c7068,57) at ata_start+0x17f
    ata_queue_request(c26c82d0,c,370b8,c238c000,c238c0a8) at 
ata_queue_request+0x185
    ata_controlcmd(c238c0a8,ef,3,0,0) at ata_controlcmd+07a
    ata_promise_setmode(c238c0a8,f) at ata_promise_setmode+0x29d
    ata_identify_devices(c238c000) at ata_identify_devices+0x1b8
    ata_boot_attach(0) at ata_boot_attach+0x27
    run_interrupt_driven_config_hooks......
    mi_startup()....
    begin()

The machine is an amd64 with a Gigabit GA-K8NS Pro motherboard:
    - Silicon Image sil3512 controller
    -  GigaRaid ATA 133 Raid controller
    - 4xSerial ATA
    -4 x Parallel ATA 133

It also has in it a Promise SX4/4000 Card which is the one complaining.
The card is detected as ata2 and I see the line
ata2-master: pio=0x0c wdma=0x22 udma=0x45 cable=40pin
It's actually on an 80pin cable but sure that's not the killer.

After a few printf's thrown in the code:
printf("ch = %p\n", ch )
printf("ch->running = %p\n", ch->running)

I get:
ch = 0xc238c000
ch->running = 0

Then a crash.
I can't report on the io ports for ide as there's too many lock order 
reversals for networking:

    lock order reversal:
       1st skc0 ( network driver) if_sk.c:673
       2nd kernel environment kern_environment.c:285

ata0 & 1 attach fine finding the hdd and the cdrom.

"show locks" only shows a sleep mutex on giant by the nfs_srvsubs.c:526
"show intrcnt" has
    irq14 ata0    7
    irq15 ata1   14

plus other stuff in it.
      
"show irqs" has
    irq16   atapci1 (pid26) {ENTROPY}
plus other stuff in it

"show pci regs" has
atapci0:pci0:8:0: class 0x01018a card=0x50021458 chip=0x00e510de 
rev=0xa2 hdr=0x00
plus other stuff in it

Thats about all I can give as the hdd i've got is way smaller than the 
memory so I can't give a full dump.

Hope this helps. Please let me know if you have any patches for testing 
as I want to get this box up asap (well at least booting :)

Cheers,
    Benjamin

-- 
3D Research Associate / System Administrator     +61 8 8302 3669
School of Computer and Information Science       Room D1-07, ML Campus
University of South Australia                    Mawson Lakes Blvd.
Benjamin.Close_at_cs.unisa.edu.au                   South Australia, 5095
F00D C83D 5F7E 5561 DF91  B74D E602 CAA3 4842 B5B4
Received on Mon Aug 16 2004 - 02:23:37 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:06 UTC