> > > > and/or CAM issues. > > > > > > Has anyone tried a CAMDEBUG kernel and camcontrol tracing on? > > > > I'll be glad to turn it on if you tell me how to do it on only that > > tape drive. I'm getting ready for another mt erase test and that > > will take about an hour and a half. > > > > > > I'm rebuilding the kernel now with camdebug turned on. I'll do the > > mt erase with -I -T -S -c 0:4 and see what happens. > > > Please. This is what I meant. This is a -current system, right? I > actually have an ancient 8200 so I should be able to replicate the problem > if we figure out the deal on this.
Let me know... I've hooked back up my 8200 for some testing again. There's a new variant to the 'mt stat' command in -current (it made it to 3.1-STABLE too): quarm.feral.com > mt -f /dev/rsa3.ctl stat Mode Density Blocksize bpi Compression Current: default variable 0 unsupported ---------available modes--------- 0: default variable 0 unsupported 1: default variable 0 unsupported 2: default variable 0 unsupported 3: default variable 0 unsupported --------------------------------- Current Driver State: Writing. --------------------------------- File Number: 0 Record Number: 7 so you can print out the driver's notion of what it is doing if things are mysteriously hung. That could give a clue where the breakage is (like, if the driver says it's state is 'at rest' the problem is possibly outside the sa driver). -matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
