DMA timeouts with JM20330 based SATA<->IDE bridge

DMA timeouts with JM20330 based SATA<->IDE bridge

[Florian Zumbiehl]

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

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

[Rafal Prylowski]

Hi,

I have similar problem with JM20330, but in my case it's connected
to arm board ide port (Cirrus Logic ep9315 SoC).
I'm using pata driver written long time ago by Alessandro Zumo
and Lennert Buytenhek, to which I added dma functionality (the driver
is not in mainline).

> At the other end, it's connected to a Seagate ST31500341AS
> SATA harddisk (well, that's kinda redundant ... ;-).
In my case, it's Seagate ST9120822AS.

> 
> 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).
I can observe dma timeouts only when reading from disk, never when
writing.

> 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.
> 

My kernel log:

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: failed command: READ DMA
ata1.00: cmd c8/00:08:70:39:a3/00:00:00:00:00/e3 tag 0 dma 4096 in
         res 40/00:80:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: failed command: READ DMA EXT
ata1.00: cmd 25/00:00:d0:2e:27/00:02:04:00:00/e0 tag 0 dma 262144 in
         res 40/00:80:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: failed command: READ DMA EXT
ata1.00: cmd 25/00:00:d0:28:9b/00:02:04:00:00/e0 tag 0 dma 262144 in
         res 40/00:80:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }

Kernel version doesn't have any impact (it was first observed about
two years ago, and with 2.6.32.8 behaviour is the same, during this
time I've never had any problems with ide drives connected directly).
I also tested jm20330 connected to old Celeron box (with VIA VT82C596B) and
it works reliably.

I think that the problem is with ep93xx ide controller (maybe working
too close to ide specs or so..), or maybe between drive and jm20330
(however I don't have any non-Seagate sata drive to test it).
Reading is probably much faster in my configuration (the green led
on converter board is constantly turned on during read, then suddenly
turns off and timeout occurs, during write I can only observe fast blinking,
maybe this is normal).

If there is any interest, I can post ep93xx pata driver to the list,
but it depends on ep93xx-dma-m2m patch, which is not in mainline too.

Rafał

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

[Florian Zumbiehl]

Hi,

> 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 :-)

FYI: I just tried forcing the device to MWDMA2, and that seems to work
well, too - wrote some 10 GB without any errors.

Any hints as to how to further debug this would be appreciated.

Florian

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

[Florian Zumbiehl]

Hi,

> > 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 :-)
> 
> FYI: I just tried forcing the device to MWDMA2, and that seems to work
> well, too - wrote some 10 GB without any errors.

Yet another piece of information: Writing in 4 KiB or 8 KiB blocks
in UDMA/66 mode (using dd if=/dev/zero of=/dev/sdc bs=4k oflag=direct)
seems to work well, too, 16 KiB causes the problems described.

Florian

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

[Fontana Cristian]

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

> 
> Hi,
> 
> > > 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 
> > 
> > FYI: I just tried forcing the device to MWDMA2, and that seems to work
> > well, too - wrote some 10 GB without any errors.
> 
> Yet another piece of information: Writing in 4 KiB or 8 KiB blocks
> in UDMA/66 mode (using dd if=/dev/zero of=/dev/sdc bs=4k oflag=direct)
> seems to work well, too, 16 KiB causes the problems described.
> 
> 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
> 
> 


Hello, I have exactly the same problem as yours using JM20330. I tried to 
force the device to MWDMA2 but I had success.
you could solve the problem?
could be done to limit the maximum kb block?

I appreciate any help the
(sorry for my English)

fontana cristian

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

[Fontana Cristian]

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