DragonFlyBSD

:Hi,
:
:During boot of the live cd this shows up:
:
:Mounting root from cd9660:cd0c
:ata1: FAILURE - zero length DMA transfer attempted
:acd0: setting up DMA failed
:ata1: FAILURE - zero length DMA transfer attempted
:acd0: setting up DMA failed
:ata1: FAILURE - zero length DMA transfer attempted
:acd0: setting up DMA failed
:ata1: FAILURE - zero length DMA transfer attempted
:acd0: setting up DMA failed
:ata1: FAILURE - zero length DMA transfer attempted
:acd0: setting up DMA failed

That is definitely not correct.  If you don't mind burning another dead
    CD could you please try this patch?  It will force the system to panic
    when it tries to do a 0-length I/O.  Then get a backtrace from the DDB
    prompt so we can see the call chain that leads up to the problem.

-Matt

Index: ata-dma.c ===================================================================
RCS file: /cvs/src/sys/dev/disk/nata/ata-dma.c,v
retrieving revision 1.4
diff u -p -r1.4 ata-dma.c
-- ata-dma.c 5 Jun 2007 18:30:40 0000 1.4
++ ata-dma.c 22 Jul 2007 19:32:04 -0000
@ -227,6 +227,7 @ return EIO;
}
if (!count) {
device_printf(dev, "FAILURE - zero length DMA transfer attempted\n");
panic("zero length DMA transfer");
return EIO;
}
if (((uintptr_t)data & (ch>dma->alignment - 1)) ||
Index: atapi-cd.c ===================================================================
RCS file: /cvs/src/sys/dev/disk/nata/atapi-cd.c,v
retrieving revision 1.7
diff u -p -r1.7 atapi-cd.c
-- atapi-cd.c 3 Jun 2007 04:48:29 -0000 1.7
+++ atapi-cd.c 22 Jul 2007 19:35:03 -0000
@ -785,6 +785,8 @ biodone(bp);
return 0;
}

+ KASSERT);
+
bp->bio_driver_info = cdev;
bbp->b_resid = bbp->b_bcount;

@ -842,6 +844,8 @ lba = (bp->bio_offset & 0x00FFFFFFFFFFF
}

count = bbp->b_bcount / blocksize;
+    KASSERT(count != 0, ("acd_strategy: 0-length I/O %d bytes vs %d blksize",
+        bbp->b_bcount, blocksize));

if (bbp->b_cmd == BUF_CMD_READ) {
     /* if transfer goes beyond range adjust it to be within limits */

Snapshot from 22th July and basically the same problems:

WinFast K7S741M Series 426XP215 072204
XP2400+

Samsung CRRW+DVD-R

acd0: FAILURE - READ_BIG HARDWARE ERROR asc=0x08 ascq=0x03
vm_fault: pager read error, pid 1 (init)

This string is common on Google so I decided to disable UDMA on secondary channel and got this:

ata1: FAILURE - zero length DMA transfer attempted
acd0: setting up DMA failed
(cd0:ata1:0:0:0): READ. CDB: 28 0 0 0 0 10 0 0 0 0
(cd0:ata1:0:0:0): error code 0
(cd0:ata1:0:0:0): cddone: got error 0x5 back
Root mount failed: 5
Mounting root from cd9660:acd0c
cd9660: RockRidge Extension
acd0: FAILURE - READ_BIG HARDWARE ERROR asc=0x08 ascq=0x03
vm_fault: pager read error, pid 1 (swapper)
init died (signal 6, exit 0)
panic: Going nowhere without my init!

With CD-R I got the same results as in the first place (which was done on CD-RW).

I got one backtrace, but did not write it down :(

Tomaž

Is this sufficient?

(kgdb) bt
#0 dumpsys () at thread.h:83
#1 0xc02eb11b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc02eb8a4 in panic (fmt=0xc0562c05 "from debugger") at
/usr/src/sys/kern/kern_shutdown.c:796
#3 0xc0166a66 in db_panic (addr=-1068477435, have_addr=0, count=-1,
modif=0xc07d6604 "") at /usr/src/sys/ddb/db_command.c:447
#4 0xc01669fb in db_command (last_cmdp=0xc0634690, cmd_table=0x0,
aux_cmd_tablep=0xc05be6f8, aux_cmd_tablep_end=0xc05be714) at
/usr/src/sys/ddb/db_command.c:343
#5 0xc0166adb in db_command_loop () at /usr/src/sys/ddb/db_command.c:469
#6 0xc0169670 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71
#7 0xc05050a8 in kdb_trap (type=3, code=0, regs=0xc07d6728) at
/usr/src/sys/platform/pc32/i386/db_interface.c:148
#8 0xc0517f20 in trap (frame=0xc07d6728) at
/usr/src/sys/platform/pc32/i386/trap.c:804
#9 0xc05060f6 in calltrap () at /usr/src/sys/platform/pc32/i386/exception.s:783
#10 0xc0505405 in Debugger (msg=0x12 <Address 0x12 out of bounds>) at
cpufunc.h:73
#11 0xc02eb89c in panic (fmt=0xc05652e4 "zero length DMA transfer") at
/usr/src/sys/kern/kern_shutdown.c:794
#12 0xc01a04c8 in ata_dmaload (dev=0xc622bb28, data=0xc0c14000 "",
count=0, dir=2, addr=0x12, entries=0x0) at
/usr/src/sys/dev/disk/nata/ata-dma.c:230
#13 0xc01a0ca0 in ata_begin_transaction (request=0xc0b2b190) at
/usr/src/sys/dev/disk/nata/ata-lowlevel.c:180
#14 0xc01a4710 in ata_start (dev=0xc622bb28) at
/usr/src/sys/dev/disk/nata/ata-queue.c:214
#15 0xc01a4376 in ata_queue_request (request=0xc0b2b190) at
/usr/src/sys/dev/disk/nata/ata-queue.c:95
#16 0xc01b386d in atapi_action (sim=0xc0b03ba8, ccb=0x0) at
/usr/src/sys/dev/disk/nata/atapi-cam.c:602
#17 0xc014be68 in xpt_run_dev_sendq (bus=0xc0af2c90) at
/usr/src/sys/bus/cam/cam_xpt.c:3640
#18 0xc014b111 in xpt_action (start_ccb=0xca67a140) at
/usr/src/sys/bus/cam/cam_xpt.c:2809
#19 0xc015c90b in cdstart (periph=0xc0b03bf8, start_ccb=0xca67a140) at
/usr/src/sys/bus/cam/scsi/scsi_cd.c:1584
#20 0xc014bbfc in xpt_run_dev_allocq (bus=0xc0af2c90) at
/usr/src/sys/bus/cam/cam_xpt.c:3507
#21 0xc014baa1 in xpt_schedule (perph=0xc0b03bf8,
new_priority=3232705680) at /usr/src/sys/bus/cam/cam_xpt.c:3402
#22 0xc015c5d2 in cdstrategy (ap=0x12) at
/usr/src/sys/bus/cam/scsi/scsi_cd.c:1496
#23 0xc02d456d in dev_dstrategy (dev=0xc0b25fe8, bio=0x20) at
/usr/src/sys/kern/kern_device.c:238
#24 0xc030094e in diskstrategy (ap=0x12) at /usr/src/sys/kern/subr_disk.c:423
#25 0xc02d456d in dev_dstrategy (dev=0xc0b26f18, bio=0x20) at
/usr/src/sys/kern/kern_device.c:238
#26 0xc034824d in spec_strategy (ap=0xc65f5d18) at
/usr/src/sys/vfs/specfs/spec_vnops.c:544
#27 0xc034328b in vop_strategy (ops=0x0, vp=0xc0b6b188,
bio=0xc0ba3e30) at /usr/src/sys/kern/vfs_vopops.c:659
#28 0xc0329357 in vn_strategy (vp=0xc0b6b188, bio=0x20) at
/usr/src/sys/kern/vfs_bio.c:2779
#29 0xc0326140 in bread (vp=0xc0b6b188, loffset=) at
/usr/src/sys/kern/vfs_bio.c:630
#30 0xc02c2f4e in iso_mountfs (devvp=0xc0b6b188, mp=0xc0b84020,
argp=0xc07d6b64) at /usr/src/sys/vfs/isofs/cd9660/cd9660_vfsops.c:321
#31 0xc02c2ad8 in iso_mountroot (mp=0xc0b84020) at
/usr/src/sys/vfs/isofs/cd9660/cd9660_vfsops.c:165
#32 0xc02c2b36 in cd9660_mount (mp=0xc0b84020, path=0x0, data=0x12
<Address 0x12 out of bounds>, cred=0xc0b16120) at
/usr/src/sys/vfs/isofs/cd9660/cd9660_vfsops.c:189
#33 0xc032f650 in vfs_mountroot_try (mountfrom=0xc0577e53
"cd9660:cd0c") at /usr/src/sys/kern/vfs_conf.c:244
#34 0xc032f3f4 in vfs_mountroot (junk=0x0) at /usr/src/sys/kern/vfs_conf.c:143
#35 0xc02c7cd1 in mi_startup () at /usr/src/sys/kern/init_main.c:234
#36 0xc014098b in begin () at /usr/src/sys/platform/pc32/i386/locore.s:337

:Is this sufficient?

This helps.  I'm researching it now.  Somehow a 2K read got turned
    into a 0 block read.

-Matt

Ok, all the live CD problems should now theoretically be fixed. I'm
doing a full nrelease build to test it.

I found numerous additional bugs while tracking down this one,
    including problems tracking the open count on the device.  This
    typically prevented the CD from being ejected.  /dev/cd0 also had the
    wrong minor number, and the generic disk layer also failed to properly
    track opens when an open failed (which I found when I couldn't
    eject the CD after trying to open the incorrect /dev/cd0 device).

The main issue was that the CAM layer failed to set the si_iosize_max
    field in the device structure.  This caused the strategy code to
    try to break I/O's down into 0-sized chunks, resulting in an endless
    loop and/or panic.

NATA's CAM interface also failed to properly set transfer length
    limits based on the DMA transfer limit and instead just used 65535
    unconditionally.  This resulted in accesses via the SCSI device
    (/dev/cd0) potentially making I/O requests that were too large.

-Matt

...

-Matt

I did one too and it seems to work. Thanks!

Max

Commit msgs:
http://leaf.dragonflybsd.org/mailarchive/commits/2007-07/msg00198.html
http://leaf.dragonflybsd.org/mailarchive/commits/2007-07/msg00200.html