Kernel Panic on 10.6.7

[GoogleCodeExporter]

What steps will reproduce the problem?

Don't know.  Just happened while I was using my system browsing the web.

What is the expected output? What do you see instead?

I expect it not to panic.

What version of the product are you using? On what operating system?
74.0.0

Please provide any additional information below.
Mon Apr  4 10:25:08 2011
panic(cpu 0 caller 0x13e4034): "ZFS: I/O failure (write on <unknown> off 0: zio 
0x10f22ba8 [L0 persistent error log] 4000L/400P DVA[0]=<0:5f8c5a9000:800> 
DVA[1]=<0:1810f706800:800> DVA[2]=<0:254000c5800:800> fletcher4 lzjb LE 
contiguous birth=15189293 fill=1 
cksum=5f8734f25b:3e9b4cb90b59:1698abd2fba58d:5d521cb930999ac): error " 
"6"@/Users/alex/Projects/mac-zfs/usr/src/uts/common/fs/zfs/zio.c:918
Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)
0x738ebe58 : 0x21b510 (0x5d9514 0x738ebe8c 0x223978 0x0) 
0x738ebea8 : 0x13e4034 (0x13f6760 0x13f6754 0x13f67e8 0x13f4dc4) 
0x738ebf18 : 0x13e21a7 (0x10f22ba8 0xd137a00 0xeb0d64af 0x136c6) 
0x738ebf58 : 0x13e7b24 (0x10f22ba8 0xd137a00 0x209e9d8 0x13f4d08) 
0x738ebfc8 : 0x2a06dc (0x946d6b0 0x0 0x10 0xf025180) 
      Kernel Extensions in backtrace (with dependencies):
         com.bandlem.mac.zfs.fs(74.0.0)@0x1388000->0x1400fff

BSD process name corresponding to current thread: kernel_task

Mac OS version:
10J869

Kernel version:
Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; 
root:xnu-1504.9.37~1/RELEASE_I386

Decoded I get:

0x21b510 <panic+445>:   mov    0x8011d0,%eax
0x13e4034 <zio_done+498>:   inc    %esp
0x13e21a7 <zio_wait_children_ready+11>: add    %bh,0x1(%edx)
0x13e7b24 <taskq_d_thread+287>: mov    %ecx,(%eax)
0x2a06dc <call_continuation+28>:    add    $0x10,%esp

Original issue reported on code.google.com by mfelli...@gmail.com on 4 Apr 2011 at 5:54

[GoogleCodeExporter]

ZFS will panic when it identifies a request which cannot fail. In this case, it 
failed.

https://github.com/alblue/mac-zfs/blob/master/usr/src/uts/common/fs/zfs/zio.c#L9
12

Note that this is a documented behaviour of ZFS at the moment and there is no 
way to mark the pool as 'failed' if an error occurs. however, the write error 
will just trigger the zpool into read-only mode, so the cause is to solve the 
underlying hardware error.

Original comment by alex.ble...@gmail.com on 7 Mar 2012 at 12:10

• Changed state: Invalid