Re: ATAng probe updated please test

D. Rock schrieb:
> Soren Schmidt schrieb:
> 
>> I've gone over the probe code once again.
>>
>> Please test, and in case it fails to detect or misdetects anything,
>> mail me the output of dmesg from a verbose boot, and state what
>> devices actually are there.
>>
> 
> Hi,
> 
> again no luck. Same problem persists, the devices got probed correctly
> (two disks, each on its own channel), but cannot be accessed.
> 

Just an additional notice: Booting in PIO mode (by setting
hw.ata.ata_dma=0 in /boot/loader.conf):

[...]
GEOM: create disk ad0 dp=0xc10b3b70
ad0: 9671MB <IBM-DTTA-351010> [20960/15/63] at ata0-master PIO4
GEOM: create disk ad1 dp=0xc10b3470
ad1: 1221MB <Seagate Technology 1275MB - ST31276A> [2482/16/63] at 
ata1-master PIO4
Waiting 2 seconds for SCSI devices to settle
Mounting root from ufs:/dev/ad0a

But if I try to set DMA mode later via atacontrol, the problem
reappears:

# atacontrol mode 0 udma2 udma2
Master = UDMA33
Slave  = BIOSPIO
# atacontrol mode 1 udma2 udma2
Master = WDMA2
Slave  = BIOSPIO
ad0: WARNING - WRITE_DMA recovered from missing interrupt
ad1: WARNING - READ_DMA recovered from missing interrupt
/usr/local/squid: bad dir ino 22496 at offset 0: mangled entry
panic: ufs_dirbad: bad dir
Debugger("panic")
Stopped at      Debugger+0x45:  xchgl   %ebx,in_Debugger.0
db> where
Debugger(c04517f8) at Debugger+0x45
panic(c04682ea,c1281200,d5decb08,c039be8a,c129b08c) at panic+0xbb
ufs_dirbad(c129b08c,0,c04682a4,c103ce40,0) at ufs_dirbad+0x3d
ufs_lookup(d5decb38,d5decb74,c02b0005,d5decb38,287) at ufs_lookup+0x2be
ufs_vnoperate(d5decb38) at ufs_vnoperate+0x13
vfs_cache_lookup(d5decbac,d5decbc8,c02b45df,d5decbac,c103ce40) at 
vfs_cache_lookup+0x29d
ufs_vnoperate(d5decbac) at ufs_vnoperate+0x13
lookup(d5decc30,c103ce40,50,c110cc00,20) at lookup+0x2cb
namei(d5decc30) at namei+0x1b5
stat(c103ce40,d5decd14,2,84,216) at stat+0x4a
syscall(2f,2f,2f,0,81f4020) at syscall+0x233
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (188, FreeBSD ELF32, stat), eip = 0x2815c95b, esp = 
0xbfbffa6c, ebp = 0xbfbffc38 ---
db>

interestingly enough, a crash dump could be written on the dump device
(ad0b), but it was unusable:

Checking for core dump...
savecore: first and last dump headers disagree on /dev/ad0b
savecore: unsaved dumps found but not saved


Daniel