Bug 156241 - [mfi] 'zfs send' does not prevents disks to suspend if no other activity
Summary: [mfi] 'zfs send' does not prevents disks to suspend if no other activity
Status: Closed Feedback Timeout
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.2-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Mark Linimon
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-07 08:30 UTC by Mickaël Canévet
Modified: 2016-01-25 08:32 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mickaël Canévet 2011-04-07 08:30:10 UTC 
I have a backup server with almost no I/O activity on which I want to export a ZPOOL to a USB disk.

When I do a 'zfs send my_backup_pool| zfs receive my_usb_backup_pool', the process hangs after a few minutes and dmesg reports this error message:

mfi1: COMMAND 0xffffff80004fe268 TIMEOUT AFTER 59 SECONDS
mfi1: COMMAND 0xffffff80004fbcb0 TIMEOUT AFTER 59 SECONDS
mfi1: COMMAND 0xffffff80004fbcb0 TIMEOUT AFTER 89 SECONDS
mfi1: COMMAND 0xffffff80004fbcb0 TIMEOUT AFTER 120 SECONDS
..

The problem solves as soon as I do a read on the source.

Is it possible that 'zfs send' bypasses some low level layers that prevents disks to suspend ?

How-To-Repeat: If you do this on a server with no I/O activity:

zfs send a_big_zpool | cat - > /dev/null

after a few minutes, you should have:

mfi1: COMMAND 0xffffff80004fe268 TIMEOUT AFTER 59 SECONDS
mfi1: COMMAND 0xffffff80004fbcb0 TIMEOUT AFTER 59 SECONDS
mfi1: COMMAND 0xffffff80004fbcb0 TIMEOUT AFTER 89 SECONDS
mfi1: COMMAND 0xffffff80004fbcb0 TIMEOUT AFTER 120 SECONDS
..

And as soon as you do a 'ls' for example on the zpool, 'zfs send' continues.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2011-04-09 21:09:50 UTC 
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 Remko Lodder freebsd_committer freebsd_triage 2011-04-13 06:47:55 UTC 
Responsible Changed
From-To: freebsd-fs->freebsd-hardware

Pawel says this might be hardware related, assign it to that 
group and tag the ticket as [mfi].
Comment 3 Steven Hartland freebsd_committer freebsd_triage 2012-12-13 22:37:50 UTC 
State Changed
From-To: open->feedback

What MFI controller is this and what firmware version is it?
Comment 4 peuch 2012-12-17 11:05:40 UTC 
As a followup in the originator stead

> # mfiutil show firmware
> mfi0 Firmware Package Version: 12.10.0-0025
> mfi0 Firmware Images:
> Name  Version                        Date           Time      Status
> BIOS  3.18.00_4.09.05.00_0x0416A000  00_0x0416A000            active
> APP   2.100.03-1046                  Oct 24 2010    04:38:35  active
> PCLI  04.04-010:#%00008              May 31 2010    20:21:52  active
> CTLR  2.02-0025                      Aug 12 2010    14:46:17  active
> NVDT  2.07.03-0003                   Jul 14 2010    15:53:29  active
> BTBL  2.02.00.00-0000                Sep 16 2009    21:37:06  active
> BOOT  01.250.04.219                  4/28/2009      12:51:38  active
> 
> 
> # mfiutil show adapter
> mfi0 Adapter:
>     Product Name: PERC H700 Integrated
>    Serial Number: 0BC0310
>         Firmware: 12.10.0-0025
>      RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50
>   Battery Backup: present
>            NVRAM: 32K
>   Onboard Memory: 512M
>   Minimum Stripe: 8k
>   Maximum Stripe: 1M
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2015-03-10 02:45:37 UTC 
Reassign from non-responding assignee.

To submitter: does this problem still recur on recent versions of FreeBSD?