Just to add my 5 cents to this topic: I had similar READ_DMA_TIMEOUT
problems with a Promise Ultra100 controller with 2 PATA disks that
caused various problems including memory corruption under heavy use. As
soon as I replaced the controller with a cheap VIA 6421 controller all
problems went aw
On Wed, Mar 26, 2008 at 07:19:47AM +0100, Gianni wrote:
> On 25/mar/08, at 09:44, Jeremy Chadwick wrote:
>>
>> I re-read your mail -- sorry. You're using SATA.
>>
>> I'll update my Wiki page to state that the loader.conf DMA disable trick
>> only works for PATA.
>>
>> In the interim, I recommend y
On 25/mar/08, at 09:44, Jeremy Chadwick wrote:
I re-read your mail -- sorry. You're using SATA.
I'll update my Wiki page to state that the loader.conf DMA disable
trick
only works for PATA.
In the interim, I recommend you contact Scott Long, especially if your
problem is easily repeatable.
On Tue, Mar 25, 2008 at 01:43:30AM -0700, Jeremy Chadwick wrote:
> On Tue, Mar 25, 2008 at 08:32:07AM +0100, Gianni wrote:
> > On 22/mar/08, at 04:52, Jeremy Chadwick wrote:
> >> On Fri, Mar 21, 2008 at 06:27:19PM +0100, Gianni Doe wrote:
> >>> I'm also experiencing this issue after upgrading to 7.
On Tue, Mar 25, 2008 at 08:32:07AM +0100, Gianni wrote:
> On 22/mar/08, at 04:52, Jeremy Chadwick wrote:
>> On Fri, Mar 21, 2008 at 06:27:19PM +0100, Gianni Doe wrote:
>>> I'm also experiencing this issue after upgrading to 7.0-RELEASE from 6.3
>> The most I can provide is here:
>> http://wiki.free
On 22/mar/08, at 04:52, Jeremy Chadwick wrote:
On Fri, Mar 21, 2008 at 06:27:19PM +0100, Gianni Doe wrote:
I'm also experiencing this issue after upgrading to 7.0-RELEASE
from 6.3
The most I can provide is here:
http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues
Workaround: Set
On Fri, Mar 21, 2008 at 06:27:19PM +0100, Gianni Doe wrote:
> I'm also experiencing this issue after upgrading to 7.0-RELEASE from 6.3
The most I can provide is here:
http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues
--
| Jeremy Chadwickjdc at p
I'm also experiencing this issue after upgrading to 7.0-RELEASE from 6.3
I've got 2 Western Digital 5000YS hard drives in a GEOM Raid 1
configuration and connected to a Promise on-board SATA controller,
this has worked flawlessly under 6.3 but since upgrading to 7.0 I'm
getting the DMA time
Jeremy Chadwick wrote:
> On Wed, Feb 27, 2008 at 01:20:50PM -0700, Scott Long wrote:
> > I'd like to attack these driver problems. What I need is to spend a
> > couple of days with an affected system that can reliably reproduce the
> > problem, instrumenting and testing the driver. I have a numbe
Quoting Richard Tector <[EMAIL PROTECTED]>:
This is just a 'me too'.
I've experienced the following on 2 seperate and very different i386 systems:
An upgrade to RELENG_7 solved this problem. Whether there has actually
been a change in the code that has done it, or perhaps I had a faulty
i
This is just a 'me too'.
I've experienced the following on 2 seperate and very different i386
systems:
ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=1520671
ad4: TIMEOUT - READ_DMA retrying (0 retries left) LBA=1520671
ad4: FAILURE - READ_DMA timed out LBA=1520671
That was on an Intel i
On Wed, Feb 27, 2008 at 01:20:50PM -0700, Scott Long wrote:
> I'd like to attack these driver problems. What I need is to spend a
> couple of days with an affected system that can reliably reproduce the
> problem, instrumenting and testing the driver. I have a number of
> theories about what migh
Dick Hoogendijk wrote:
On Fri, 29 Feb 2008 15:39:11 -0800
Stephen Hurd <[EMAIL PROTECTED]> wrote:
As a workaround, adding the line:
hw.ata.ata_dma="0"
To /boot/loader.conf will disable DMA and prevent the hangs that are
caused by the DMA timeouts.
Yeah, but having dma=1 makes the syste
On Fri, 29 Feb 2008 15:39:11 -0800
Stephen Hurd <[EMAIL PROTECTED]> wrote:
> As a workaround, adding the line:
> hw.ata.ata_dma="0"
> To /boot/loader.conf will disable DMA and prevent the hangs that are
> caused by the DMA timeouts.
Yeah, but having dma=1 makes the system faster, doesn't it?
--
> > As a workaround, adding the line:
> > hw.ata.ata_dma="0"
> >
> > To /boot/loader.conf will disable DMA and prevent the hangs that are caused
> > by the DMA timeouts.
>
> Does that workaround work when the disks are sata?
Don't know. I personally would assume so, but I wouldn't be surprised
On 29/02/2008, Stephen Hurd <[EMAIL PROTECTED]> wrote:
> > last night. It's a MiniITX board, model EN1200. My system can't remain
> > up for more than 10minutes before something locks it up and frequently
> > the screen will output error messages relating to DMA.
>
> As a workaround, adding the lin
> last night. It's a MiniITX board, model EN1200. My system can't remain
> up for more than 10minutes before something locks it up and frequently
> the screen will output error messages relating to DMA.
As a workaround, adding the line:
hw.ata.ata_dma="0"
To /boot/loader.conf will disable DMA and
I'm having very similar problems on my system that I just upgraded
last night. It's a MiniITX board, model EN1200. My system can't remain
up for more than 10minutes before something locks it up and frequently
the screen will output error messages relating to DMA.
I'd love to be able to help and
On 28/02/2008, Mark Linimon <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 28, 2008 at 02:47:28PM +, Chris wrote:
> > Did they push ahead with release because waiting for the mia dev?
>
> There's a lot of things that go into deciding when to release. The
> release cycle this time was not supposed to
On Thu, Feb 28, 2008 at 02:47:28PM +, Chris wrote:
> Did they push ahead with release because waiting for the mia dev?
There's a lot of things that go into deciding when to release. The
release cycle this time was not supposed to be as long as it was.
We kept finding showstoppers and needing
>
> If you replace the disk and you still continue to see DMA errors, then
> my vote would be that you're experiencing the same thing others (and
> myself, on one occasion) are. I've done my best to bring this issue to
> the attention of proper people in recent days, and that's all I can say
> on
Scott Long wrote:
I'd like to attack these driver problems. What I need is to spend a
couple of days with an affected system that can reliably reproduce the
problem, instrumenting and testing the driver. I have a number of
theories about what might be going wrong, but nothing that I'm
definitel
Scott Long wrote:
I'm betting that it's a driver problem and not
a hardware problem, though you should probably think about migrating
your data off to a new drive sometime soon.
Yeah, ordered a replacement drive today.
I'd like to attack these driver problems. What I need is to spend a
coupl
Stephen Hurd wrote:
This shows you've had 4 reallocated sectors, meaning your disk does in
fact have bad blocks. In 90% of the cases out there, bad blocks
continue to "grow" over time, due to whatever reason (I remember reading
an article explaining it, but I can't for the life of me find the U
Stephen Hurd wrote:
Jeremy Chadwick wrote:
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 253 253 06
On Wed, Feb 27, 2008 at 10:32:48AM -0800, Stephen Hurd wrote:
> Booting the 6.3-RELEASE CD seems to make the problem go away... possibly
> 7.0 stresses the HD more?
We don't know. The author of the ATA subsystem is somewhat MIA, likely
busy with real-life things (jobs, etc.). My main point was
Jeremy Chadwick wrote:
And after the reboot, the READ_DMA timeouts were back.
You're not the only one seeing this behaviour. There are too many posts
in the past reporting similar. Here's the breakdown:
* Some have switched to alternate operating systems (usually Linux) for
a short wh
On Wed, Feb 27, 2008 at 01:11:36AM -0800, Stephen Hurd wrote:
> ... The corrupted sync message scared the heck out of me:
> Waiting (max 60 seconds) for system process `vnlru' to stop...done
> Waiti
> Synncgi n(gm adxi sk6s0, svencoodnedss )r efmoari nsiynsgte.m. .pr1o0c ess
> `syncer' to stop..
My system has been working reliably with 6.3 for quite some time... when
I rebooted into single user mode to do the installworld with the
7.0-RELEASE kernel, the install died about halfway through with READ_DMA
TIMEOUT errors. Since I had a mixed system at that point, I set
hw.ata.ata_dma="0"
29 matches
Mail list logo
