I should also add this may be related to bug #438605.

I replicated the problem with another disk (500MB seagate barracuda 7200.10) in another enclosure of the same model (Macally G-S350SUA).

I tried running smartctl -a -d sat /dev/sdb and it locked up.  ctrl-C and kill -9 were unable to kill the process, but when I turned off the drive (already unmounted) then it exited, with the following in /var/log/messages:

Oct  4 15:24:07 ginger kernel: [ 9467.000117] ieee1394: sbp2: aborting sbp2 command
Oct  4 15:26:09 ginger kernel: [ 9467.000146] sd 7:0:0:0: [sdb] CDB: ATA command pass through(16): 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 ec 00
Oct  4 15:26:09 ginger kernel: [ 9467.007586] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO
Oct  4 15:26:09 ginger kernel: [ 9528.000141] ieee1394: sbp2: aborting sbp2 command
Oct  4 15:26:09 ginger kernel: [ 9528.000170] sd 7:0:0:0: [sdb] CDB: ATA command pass through(16): 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 ec 00
Oct  4 15:26:09 ginger kernel: [ 9589.000410] ieee1394: sbp2: aborting sbp2 command
Oct  4 15:26:20 ginger kernel: [ 9589.000439] sd 7:0:0:0: [sdb] CDB: ATA command pass through(16): 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 ec 00
Oct  4 15:26:20 ginger kernel: [ 9600.424528] INFO: task smartctl:4707 blocked for more than 120 seconds.
Oct  4 15:26:20 ginger kernel: [ 9600.424547] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct  4 15:26:20 ginger kernel: [ 9600.424561] smartctl      D c080b3a0     0  4707   4574 0x00000004
Oct  4 15:26:20 ginger kernel: [ 9600.424583]  db7d1c38 00000082 db4ab960 c080b3a0 c1925a88 c080b3a0 35a0fd6c 0000089c
Oct  4 15:26:20 ginger kernel: [ 9600.424610]  c080b3a0 c080b3a0 c1925a88 c080b3a0 359e31f9 0000089c c080b3a0 cbaf6a80
Oct  4 15:26:20 ginger kernel: [ 9600.424635]  c19257f0 db7d1ce8 7fffffff db7d1cec db7d1c94 c0569b15 db7d1c4c 00000096
Oct  4 15:26:20 ginger kernel: [ 9600.424660] Call Trace:
Oct  4 15:26:20 ginger kernel: [ 9600.424700]  [<c0569b15>] schedule_timeout+0x185/0x200
Oct  4 15:26:20 ginger kernel: [ 9600.424728]  [<c02fe95e>] ? __blk_run_queue+0x6e/0x120
Oct  4 15:26:20 ginger kernel: [ 9600.424750]  [<c02f4206>] ? elv_insert+0x116/0x1f0
Oct  4 15:26:20 ginger kernel: [ 9600.424767]  [<c0569832>] wait_for_common+0xa2/0x120
Oct  4 15:26:20 ginger kernel: [ 9600.424783]  [<c0137c50>] ? default_wake_function+0x0/0x10
Oct  4 15:26:20 ginger kernel: [ 9600.424799]  [<c0569942>] wait_for_completion+0x12/0x20
Oct  4 15:26:20 ginger kernel: [ 9600.424814]  [<c03017f5>] blk_execute_rq+0x75/0xd0
Oct  4 15:26:20 ginger kernel: [ 9600.424827]  [<c03016b0>] ? blk_end_sync_rq+0x0/0x30
Oct  4 15:26:20 ginger kernel: [ 9600.424842]  [<c0301a3e>] ? blk_recount_segments+0x1e/0x40
Oct  4 15:26:20 ginger kernel: [ 9600.424857]  [<c02fd81a>] ? blk_rq_bio_prep+0x6a/0x80
Oct  4 15:26:20 ginger kernel: [ 9600.424876]  [<c03012ef>] ? blk_rq_append_bio+0x1f/0x60
Oct  4 15:26:20 ginger kernel: [ 9600.424892]  [<c03013ee>] ? blk_rq_map_kern+0xbe/0x120
Oct  4 15:26:20 ginger kernel: [ 9600.424909]  [<c030500f>] sg_scsi_ioctl+0x20f/0x330
Oct  4 15:26:20 ginger kernel: [ 9600.424926]  [<c030534f>] scsi_cmd_ioctl+0x21f/0x480
Oct  4 15:26:20 ginger kernel: [ 9600.424941]  [<c030d3c2>] ? kobject_get+0x12/0x20
Oct  4 15:26:20 ginger kernel: [ 9600.424962]  [<c056b2f8>] ? _spin_lock+0x8/0x10
Oct  4 15:26:20 ginger kernel: [ 9600.424981]  [<c03bd39d>] sd_ioctl+0x8d/0xe0
Oct  4 15:26:20 ginger kernel: [ 9600.425006]  [<c01aff28>] ? filemap_fault+0xa8/0x340
Oct  4 15:26:20 ginger kernel: [ 9600.425020]  [<c030287a>] __blkdev_driver_ioctl+0x6a/0x80
Oct  4 15:26:20 ginger kernel: [ 9600.425035]  [<c0302db1>] blkdev_ioctl+0x91/0x610
Oct  4 15:26:20 ginger kernel: [ 9600.425055]  [<c020965f>] block_ioctl+0x2f/0x50
Oct  4 15:26:20 ginger kernel: [ 9600.425068]  [<c0209630>] ? block_ioctl+0x0/0x50
Oct  4 15:26:20 ginger kernel: [ 9600.425084]  [<c01f030c>] vfs_ioctl+0x1c/0x90
Oct  4 15:26:20 ginger kernel: [ 9600.425097]  [<c01f0631>] do_vfs_ioctl+0x71/0x310
Oct  4 15:26:20 ginger kernel: [ 9600.425113]  [<c056d77b>] ? do_page_fault+0x19b/0x380
Oct  4 15:27:18 ginger kernel: [ 9600.425126]  [<c01f092f>] sys_ioctl+0x5f/0x80
Oct  4 15:27:18 ginger kernel: [ 9600.425142]  [<c010334c>] syscall_call+0x7/0xb

I have checked that I don't have smartd running (both via ps and checking /etc/smartd.conf), and also I don't normally see the "deprecated SCSI ioctl" warning during I/O stalls, which I would guess smartd would also trigger assuming they mostly use the same underlying code, so this leads me to believe this isn't coming from a smartmontools based check, but then I still don't know what might be sending these SAT passthrough commands.