/dev/sdd:
ATA device, with non-removable media
Model Number: WDC WD1000BB-00CAA0
Serial Number: WD-WMA8C1134895
Firmware Revision: 16.06V16
Standards:
Supported: 5 4 3 2
Likely used: 6
Configuration:
Logical max current
cylinders 16383 0
heads 16 0
sectors/track 63 0
--
LBA user addressable sectors: 195371568
device size with M = 1024*1024: 95396 MBytes
device size with M = 1000*1000: 100030 MBytes (100 GB)
Capabilities:
LBA, IORDY(can be disabled)
bytes avail on r/w long: 40 Queue depth: 1
Standby timer values: spec'd by Standard, with device specific minimum
R/W multiple sector transfer: Max = 16 Current = 1
Recommended acoustic management value: 128, current value: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* Look-ahead
* Write cache
* Power Management feature set
Security Mode feature set
* SMART feature set
* Device Configuration Overlay feature set
* Automatic Acoustic Management feature set
SET MAX security extension
* DOWNLOAD MICROCODE cmd
Security:
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
HW reset results:
CBLID- above Vih
Device num = 1 determined by the jumper
Checksum: correct
On Tue, 2006-03-21 at 18:18 -0500, Ed Sweetman wrote:
> I've seen some traffic here to suggest that the problem was tracked
> down, but I saw nothing about it being solved completely. Currently my
> system hangs whenever an irq trap message appears, usually after some
> sort of disk io on SATA drives. Is it fixed in the GIT patchset recently
> posted or is this still open?
Are you referring to the "Losing ticks" bug? What is the exact error
message that you get? Does the system hang momentarily or have to be
rebooted?
Lee
Lee Revell wrote:
>On Tue, 2006-03-21 at 18:18 -0500, Ed Sweetman wrote:
>
>
>>I've seen some traffic here to suggest that the problem was tracked
>>down, but I saw nothing about it being solved completely. Currently my
>>system hangs whenever an irq trap message appears, usually after some
>>sort of disk io on SATA drives. Is it fixed in the GIT patchset recently
>>posted or is this still open?
>>
>>
>
>Are you referring to the "Losing ticks" bug? What is the exact error
>message that you get? Does the system hang momentarily or have to be
>rebooted?
>
>Lee
>
>
>
>
No not the ticks bug.
ata3: irq trap
ata3: command 0x25 timeout, stat 0x50 host_stat 0x60
ata4: irq trap
ata4: command 0x25 timeout, stat 0x50 host_stat 0x20
ata4: irq trap
ata4: command 0x35 timeout, stat 0x50 host_stat 0x20
ata3: irq trap
ata3: command 0x35 timeout, stat 0x50 host_stat 0x60
Over and over in random orientations. System hangs on io momentarily,
usually a few seconds. No fs errors, no other errors given. System
also seems to have been kicked out of DMA mode at least for disks.
Ed Sweetman wrote:
> Lee Revell wrote:
>
>> On Tue, 2006-03-21 at 18:18 -0500, Ed Sweetman wrote:
>>
>>
>>> I've seen some traffic here to suggest that the problem was tracked
>>> down, but I saw nothing about it being solved completely. Currently
>>> my system hangs whenever an irq trap message appears, usually after
>>> some sort of disk io on SATA drives. Is it fixed in the GIT patchset
>>> recently posted or is this still open?
>>
>>
>> Are you referring to the "Losing ticks" bug? What is the exact error
>> message that you get? Does the system hang momentarily or have to be
>> rebooted?
>>
>> Lee
>>
>>
>>
>>
> No not the ticks bug.
>
> ata3: irq trap
> ata3: command 0x25 timeout, stat 0x50 host_stat 0x60
> ata4: irq trap
> ata4: command 0x25 timeout, stat 0x50 host_stat 0x20
> ata4: irq trap
> ata4: command 0x35 timeout, stat 0x50 host_stat 0x20
> ata3: irq trap
> ata3: command 0x35 timeout, stat 0x50 host_stat 0x60
>
>
> Over and over in random orientations. System hangs on io
> momentarily, usually a few seconds. No fs errors, no other errors
> given. System also seems to have been kicked out of DMA mode at
> least for disks.
This has been fixed in the actual release of 2.6.16-ide1 which i've just
booted into. DMA seems active (as you'd expect since non-dma isn't
supported) and no irq trap delays. Everything is working good again,
Now if there was a way to get the CF disk (doesn't do dma) working in
pata, I'd be set.
ps. Thanks for the help, I wasn't aware of the ide1 patch to 2.6.16
before.