Re: DMA timeouts with JM20330 based SATA<->IDE bridge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Florian Zumbiehl <florz <at> florz.de> writes:

> 
> Hi,
> 
> I have here a SATA<->IDE bridge based on a JM20330 connected to
> what the old IDE driver reported like this:
> 
> | via82cxxx 0000:00:07.1: VIA vt82c686a (rev 22) IDE UDMA66
> | via82cxxx 0000:00:07.1: IDE controller (0x1106:0x0571 rev 0x10)
> 
> At the other end, it's connected to a Seagate ST31500341AS
> SATA harddisk (well, that's kinda redundant ... .
> 
> Now, reading from the disk seems to work perfectly, but writing
> (dding /dev/zero to the block device) causes DMA timeouts every
> few hundred megabytes - in between the timeouts, though,
> throughput seems to be ok (~ 20 MB/s).
> 
> Once the fallback mechanism has switched back to PIO4, things seem
> to work perfectly, albeit slowly 
> 
> In the kernel log, the errors look something like this, with
> small variations (at least to my eyes :
> 
> | ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> | ata2.00: failed command: WRITE DMA EXT
> | ata2.00: cmd 35/00:00:67:19:4f/00:04:00:00:00/e0 tag 0 dma 524288 out
> |          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> | ata2.00: status: { DRDY }
> | ata2: link is slow to respond, please be patient (ready=0)
> | ata2: device not ready (errno=-16), forcing hardreset
> | ata2: soft resetting link
> | ata2.00: configured for UDMA/66
> | ata2.00: device reported invalid CHS sector 0
> | ata2: EH complete
> 
> That's all happening with a vanilla 2.6.33 (plus tuxonice, in case that
> could have any effect on this). The legacy IDE drivers behave similarly.
> 
> So: Is there anything one could do about that, other than forcing
> PIO-only operation? If you need any further information, please let
> me know.
> 
> BTW, the datasheet of the JM20330 can be found at
> http://www.mcuol.com/aspx/down.aspx?id=1266, just in case you didn't
> know that yet ...
> 
> Florian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

I have a motherboard brand CV860c LEX (1r53) (Light embedded PC) (12vdc)
with an ide-sata adapter JM20330 (as331 v1.3) and a hard disk 2.5 "ide 500gb
in secondary.

Illustrative picture of motherboard
http://i.imgur.com/pLAs7.jpg

The same had a fault identical to the above you mentioned.

ata2.00: exception Emask 0x0 0x0 SACT Serr 0x0 action 0x6 frozen
ata2.00: failed command: WRITE DMA EXT
ata2.00: cmd 35/00: 00:30:07:8 a/00: 04:57:00:00 / e0 tag 0 dma 524288 out
         res 40/00: ff: 00:00:00 / 00:00:00:00:00 / 40 Emask 0x4 (timeout)
ata2.00: status: {DRDY}
ata2: link is slow to respond, please be patient (ready = 0)
ata2: device not ready (errno = -16), forcing hardreset
ata2: soft resetting link
ata2.00: configured for UDMA/25
ata2.00: device Reported invalid CHS sector 0 of
ata2: EH complete

The problem occurred when copying a few megabytes to affected pc (via samba
or ssh).

Writing data blocks with dd no problems. Even with different block sizes.

Several theories were presented to me in my mind and I discarded one by one
the possibilities.

n ° 1. Cable Fault: Replace the cable for another 2 without achieving
positive results.
No. 2. HDD bad: The disc was new, 3 months, so check anyway smart and gave
the ok
No. 3. JM20330 bad adapter: I could verify the operation connecting the
adapter to a desktop pc and getting good transfer rates
No. 4. EXT4. had the same fault with ext3 so I've ruled out any possible
problem with the file system.
No. 5. Bios. The bios upgrade notes ensured that could read discs up to
200GB, this gave me to understand that supported 48bit. overcoming the
barrier of 137GB.
No. 6. Kernel. I updated the kernel to different versions, without positive
results.
No. 7. Libata. Try with many commands without achieving positive results.
7 .. 8 .. 9 .. 10 .. 15 ..

After a while, I realized that there was something he had not done. USE THE
PRIMARY IDE PORT (ide 40) and not the secondary ide (ide 44).

And Surprise!. transfers changed and to this day I HAVE NOT SEEN MORE FAILURES.

(The how to use the primary port on this motherboard needs a special section
because to use it you must take 5VDC to power the hard disk from the COM1
for example.)

The problem may be located on a hardware incompatibility problem between
VT82C686B + JM20330 using them in the SECONDARY IDE channel.

Hopefully will be useful to someone!

Sorry for my bad English

Greetings from Argentina, Entre Rios, Paraná
Fontana Cristian


--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux