ng
> (0 retries left) LBA=1087300992
>
> Mar 29 10:57:34 hamstor kernel: ad10: FAILURE - WRITE_DMA48
> status=ff
> error=ff
> LBA=1087300992
>
> Mar 29 10:57:34 hamstor root: ZFS: vdev I/O failure,
> zpool=gedaerm path=/dev/ad10 offset=556698042368 size=131072 erro
4 hamstor kernel: ad10: TIMEOUT - WRITE_DMA48 retrying (0
retries left) LBA=1087300992
Mar 29 10:57:34 hamstor kernel: ad10: FAILURE - WRITE_DMA48
status=ff
error=ff
LBA=1087300992
Mar 29 10:57:34 hamstor root: ZFS: vdev I/O failure,
zpool=gedaerm path=/dev/ad10 offset=556698042368 size=
) LBA=882778752
Jan 19 19:51:23 hamstor kernel:
ad10: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout -
completing request directly
Jan 19 19:51:27 hamstor kernel: ad10:
WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing
request directly
Jan 19 19:51:31 hamstor
On Tue, 20 Jan 2009 09:39:51 +1100
Andrew Snow wrote:
>
> I think that if you use eSATA you probably need dedicated eSATA
> controller ports. eSATA standard specifies a higher voltage for the
> longer cable distances.
>
> Judging from the sporadic problem reports, Promise TX4 is probably
> n
19 19:51:23 hamstor kernel:
ad10: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout -
completing request directly
Jan 19 19:51:27 hamstor kernel: ad10:
WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing
request directly
Jan 19 19:51:31 hamstor kernel: ad10: WA
I've fiddled with the cables, which seemed to help, but I've been
unable to completely eliminate the errors. The disks are two Western
Digital MyBooks Home Edition (1 TB per disk), connected to a Promise TX
4 SATA Controller:
atap...@pci0:1:6:0: class=0x018000 card=0x3d17105a chip=0x3d17105a
rev
I think that if you use eSATA you probably need dedicated eSATA
controller ports. eSATA standard specifies a higher voltage for the
longer cable distances.
Judging from the sporadic problem reports, Promise TX4 is probably not
the best at signal purity to begin with so using it for eSATA pu
Jan 19 19:51:23 hamstor kernel:
ad10: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout -
completing request directly
Jan 19 19:51:27 hamstor kernel: ad10:
WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing
request directly
Jan 19 19:51:31 hamstor kernel: ad10: WARNING
Jan 19 19:51:23 hamstor kernel:
ad10: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout -
completing request directly
Jan 19 19:51:27 hamstor kernel: ad10:
WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing
request directly
Jan 19 19:51:31 hamstor kernel: ad10: WARNING
I have made some changes, and provided requested details.
Issue is still occuring, so if it looks like it's going to be more trouble
than it's worth I will probably just replace 3 of the PATA IDE disks with a
SATA disk and just throw the remaining PATA on the Nvidia ATA controller?
Thanks for your
On Sun, Oct 19, 2008 at 03:32:29AM +1100, Kristian Rooke wrote:
> Thanks for the quick response!
>
> Please see requested output below:
Cool, thanks. One thing I forgot to ask for was "vmstat -i" output.
For now, let's break it down for ease of understanding:
FreeBSD 7.0-RELEASE i386, built Fe
aded I had to
>> use a PCI IDE controller, due to the lack of PATA ports on the new
>> motherboard.
>> Now when I am attempting to write files, or do anything more than just
>> browse filesystems on the drives ad4-ad7, I get multiple occurrences
>> of the errors below. Aft
multiple occurrences
> of the errors below. After these errors occur the kernel panics and I
> need to perform a hard reset to get the server back up again.
>
> Sep 28 11:40:28 FileServer kernel: ad6: WARNING - SETFEATURES SET
> TRANSFER MODE taskqueue timeout - completing request dire
reset to get the server back up again.
Sep 28 11:40:28 FileServer kernel: ad6: WARNING - SETFEATURES SET
TRANSFER MODE taskqueue timeout - completing request directly
Sep 28 11:40:28 FileServer kernel: ad6: WARNING - SETFEATURES SET
TRANSFER MODE taskqueue timeout - completing request directly
Sep 28
> Steve Bertrand wrote:
> The only other box I have with four SATA ports on it is my actual
> workstation. The board is ASUS P5GD1, and has an Intel 82801FR SATA
> controller.
I transferred the SATA disks to the above board, loaded up the zpool, and
I can not reproduce the problem :)
Currently,
Steve Bertrand wrote:
I'm wondering if the problems described in the following link have been
resolved:
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-02/msg00211.html
I've got four 500GB SATA disks in a ZFS raidz pool, and all four of them
are experiencing the behavior.
Th
Matthew Dillon wrote:
This issue is vexing a lot of people.
Heh... I can appreciate this. I would like someone to inform me that
this can't be guaranteed to be a ZFS problem... if I can get
confirmation that others have this issue aside from ZFS, I would feel
content.
Setting the
Andrew Snow wrote:
From Western Digital's line of "enterprise" drives:
"RAID-specific time-limited error recovery (TLER) - Pioneered by WD,
this feature prevents drive fallout caused by the extended hard drive
error-recovery processes common to desktop drives."
Therefore I think the FreeBS
:...
:> and see if the problem reoccurs with just two drives.
:
:... I knew that was going to come up... my response is "I worked so hard
:to get this system with ZFS all configured *exactly* how I wanted it".
:
:To test, I'm going to flip to 30 as per Matthews recommendation, and see
:how f
Jeremy Chadwick wrote:
On Tue, Jul 15, 2008 at 10:29:28PM -0400, Steve Bertrand wrote:
Is there anyone interested to the point where remote login would be helpful?
I believe my FreeBSD Wiki page documents what to do if your problem
is easily reproducable: contact Scott Long, who has offered to
Alex Trull wrote:
Don't want to give conflicting advice, and would suggest you certainly
try the 30 sec thing first. I'm already on 10 myself but haven't pushed
further.
What were you doing, and what did you notice when the problem started?
As much as it seems silly, I'm mostly interested in w
On Tue, Jul 15, 2008 at 10:29:28PM -0400, Steve Bertrand wrote:
> Is there anyone interested to the point where remote login would be helpful?
I believe my FreeBSD Wiki page documents what to do if your problem
is easily reproducable: contact Scott Long, who has offered to help
track down the sour
Matthew Dillon wrote:
:Went from 10->15, and it took quite a bit longer into the backup before
:the problem cropped back up.
Jumping right into it, there is another post after this one, but I'm
going to try to reply inline:
Try 30 or longer. See if you can make the problem go away enti
Matthew Dillon wrote:
Try that first. If it helps then it is a known issue. Basically
a combination of the on-disk write cache and possible ECC corrections,
remappings, or excessive remapped sectors can cause the drive to take
much longer then normal to complete a request. The
Don't want to give conflicting advice, and would suggest you certainly
try the 30 sec thing first. I'm already on 10 myself but haven't pushed
further.
In my own case I've not had any issue with zfs in particular since I
applied the ZFS zil/prefetch disable loader.conf tunables 10 hours ago.
I am
:Went from 10->15, and it took quite a bit longer into the backup before
:the problem cropped back up.
Try 30 or longer. See if you can make the problem go away entirely.
then fall back to 5 and see if the problem resumes at its earlier
pace.
--
It could be temperature rela
Steve Bertrand wrote:
Matthew Dillon wrote:
If you are getting DMA timeouts, go to this URL:
http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting
Then I would suggest going into /usr/src/sys/dev/ata (I think, on
FreeBSD), locate all instances where request->ti
Matthew Dillon wrote:
If you are getting DMA timeouts, go to this URL:
http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting
Then I would suggest going into /usr/src/sys/dev/ata (I think, on
FreeBSD), locate all instances where request->timeout is set to 5,
Matthew Dillon wrote:
If you are getting DMA timeouts, go to this URL:
Yes, I am.
http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting
I fall under the category of "ATA/SATA DMA timeout issues".
Then I would suggest going into /usr/src/sys/dev/ata (I think, o
:Hi everyone,
:
:I'm wondering if the problems described in the following link have been
:resolved:
:
:http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-02/msg00211.html
:
:I've got four 500GB SATA disks in a ZFS raidz pool, and all four of them
:are experiencing the behavior.
:
:The p
Hi everyone,
I'm wondering if the problems described in the following link have been
resolved:
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-02/msg00211.html
I've got four 500GB SATA disks in a ZFS raidz pool, and all four of them
are experiencing the behavior.
The problem on
On Mon, May 12, 2008 at 3:00 PM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> 1) Have you checked SMART statistics of the drive, or run SMART tests?
> Install ports/sysutils/smartmontools and use smartctl -a /dev/ad4, and
> provide the output.
>
> 2) Is the error always on ad4? If so, is the error
t, there you go. :-)
> BUT sometimes I still getting:
> ad4: warning - setfeatures set transfer mode taskqueue timeout -completing
> request directly
> ad4: warning - setfeatures enable rcache taskqueue timeout - completing
> request directly
> ad4: warning - setfeatures e
On Mon, May 12, 2008 at 02:14:37PM +0900, dikshie wrote:
> On Mon, May 12, 2008 at 2:11 PM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> > On Mon, May 12, 2008 at 01:17:16PM +0900, dikshie wrote:
> >> and strange output from dmesg:
> >> ad4: 305245MB at ata2-master UDMA33
> >>
dikshie wrote:
atapci1: port
0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem
0xefff8000-0xefff9fff irq 20 at device 14.0 on pci0
It seems your controller detected as generic ATA.
Can you show `pciconf -l` output from your system?
--
WBR, Andrey V. Elsukov
___
On Mon, May 12, 2008 at 01:17:16PM +0900, dikshie wrote:
> and strange output from dmesg:
> ad4: 305245MB at ata2-master UDMA33
> ^^^
> any available patches ?
What's strange about this?
--
| Jeremy Chadwickjdc at parodiu
Hi,
I got :
ad4: warning - setfeatures set transfer mode taskqueue timeout -
completing request directly
ad4: warning - setfeatures enable rcache taskqueue timeout -
completing request directly
ad4: warning - setfeatures enable wcache taskqueue timeout -
completing
work):
Oct 18 23:15:02 saturn kernel: ad6: WARNING - SETFEATURES SET TRANSFER
MODE taskqueue timeout - completing request
directly
Oct 18 23:15:02 saturn kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE
taskqueue timeout - completing request dire
ctly
O
work):
Oct 18 23:15:02 saturn kernel: ad6: WARNING - SETFEATURES SET TRANSFER
MODE taskqueue timeout - completing request
directly
Oct 18 23:15:02 saturn kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE
taskqueue timeout - completing request dire
ctly
Oct 18 23:15:02 saturn k
to a
6-STABLE kernel, running the box in 'safe' mode to do so. I now,
however, get a slightly different error message:
ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout -
completing request directly
ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout -
a slightly different error message:
ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout -
completing request directly
ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout -
completing request directly
ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing
reques
41 matches
Mail list logo