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


_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to