cvs commit: src/sys/dev/ata ata-dma.c ata-pci.c

[Alexander Leidinger]

On Thu, 23 Oct 2003 11:19:03 +0200 (CEST)
Soren Schmidt <sos at spider.deepcore.dk> wrote:

> > > Hmm, are you sure those drives are OK ? have you tested them on another
> > > system/controller ?
> > 
> > I've only one system with a SATA controller. The drives are new.
> 
> OK, have it ever worked for you ? can you test it in some other way ?

I've only tested a recent -current on the system, as I got it just some
days ago. What other way do you have in mind? I have no idea how to test
it further.

> > ata3: spurious interrupt - status=0x50 error=0x00   [a lot of them]
> > as2: FAILURE - already active DMA on this device
> > ad2: setting up DMA failed
> > 
> > Fatal trap 12: page fault...
> > Fault virtual address = 0x8
> > Fault code = supervisor read, page not present
> > instruction pointer = 0x8:0xc042d4bb
> > stack pointer = 0x10:0xe008ccac
> > frame pointer = 0x10:0xe008ccb0
> > code segment = base 0x0, limit 0xfffff, type 0x1b
> >               = DPL 0, pres 1, def32 1, gran 1
> > processor eflags = interrupt enabled, resume, IOPL = 0
> > current process = 27 (irq5: uhci2 atapci1)
> > kernel: type 12 trap, code=0
> > Stopped at ata_prtdev+0x7: movl 0x8(%ecx),%eax
> > db> trace
> > ata_prtdev
> > ata_interrupt
> > ata_generic_intr
> > ithread_loopp
> > fork_exit
> > fork_trampoline
> > --- trap 0x1, eip = 0, esp = 0xe008cd7c, ebp = 0 ---
> 
> Hmm, this looks as if interrupts are not delivered to the right channel
> or something, does it work if you only attach one drive ?

Running "iozone -a" on one drive while the other drive is still attached
results in spurious interrupts, and after a while in a panic too:
---snip---
ata2: resetting devices...
ad1: FAILURE - already active DMA on this device
ad1: Setting up DMA failed
done
ad1: TIMEOUT - WRITE_DMA retrying (2 retries left)
ata2: resetting devices...
FEOM: destroy disk ad1
handle workitem freeblocks: block count
ad1: WARNING - removed from confguration
done
ata2-master: FAILURE - WRITE_DMA device lockup/removed

Fatal trap 12: page fault
Fatal virtual address = 0xff
Fault code = supervisor read, page not present
...
current process = 41 (bufdaemon)
kernel: type 12 trap, code 0
Stopped at<hard hang>
---snip---

I open the case, remove one drive and test again...

> > You are aware of the fact, that this is an ICH5R system (RAID BIOS 
> > disabled; the RAID isn't supposed to be supported with the actual code, 
> > correct?)?
> 
> Yes, and I know of at least a handfull of other ich5 based system that
> runs just fine, so I'm a bit puzzled here.

Can I enable some kind of debug code to find the cause?

Bye,
Alexander.

-- 
                       There's no place like ~

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7