Re: [9fans] VIA VT8237 SATA/RAID i/o errors, dma doesnt work

Found out that the I/O errors can be triggerd by network traffic.

I was able to kill a dd by pingflooding the machine remotly :-)
This also explains why my dd script had not triggerd errors, but copying
arenas and vacing from remote machine did. I guess this is interrupt load
dependend.

I changed sdata.c to:

return SDretry if starting dmarequest fails,
return SDretry and reseting controller if dma times out,
return SDretry on request is done and error signaled,

and added a counter that resets the controller if a request
was 1000 times retried...

The machine ran the whole night with bodth drives in DMA and heavy load.
vacing, pingflooded from outside, ddtest on both drives and still alive! :-)

futher testing this weekend...

cinap

> I changed sdata.c to:[color=blue]
>
> return SDretry if starting dmarequest fails,
> return SDretry and reseting controller if dma times out,
> return SDretry on request is done and error signaled,
>
> and added a counter that resets the controller if a request
> was 1000 times retried...[/color]

you might want to loop internally instead of counting to 1000.
(which may be too high. i would think that 2 or 4 would do it.
have you seen differently?) if more than one thread is doing i/o
to the disk and you have a bad sector, it may take an arbitrary
amount of time before you discover this fact.
[color=blue]
> The machine ran the whole night with bodth drives in DMA and heavy load.
> vacing, pingflooded from outside, ddtest on both drives and still alive! :-)[/color]

good deal. via's product page
[url]www.via.com.tw/en/products/chipsets/southbridge/vt8237/specs.jsp[/url]
indicates that the nic & sata controller are both integrated into the sb.
perhaps this extra southbridge configuration (pci.c) would make the
sdata hack unnecessary?

static void
viaset(Pcidev *p, uchar link, uchar irq)
{
uchar pirq;

pirq = pcicfgr8(p, 0x55 + (link >> 1));
pirq &= (link & 1)? 0x0f: 0xf0;
pirq |= (link & 1)? (irq << 4): (irq & 15);
pcicfgw8(p, 0x55 + (link>>1), pirq);
if(p->vid != 0x3177 && p->vid != 0x3227)
return;

/* Set transition time to max */
pcicfgw8(p, 0xec, pcicfgr8(p, 0xec) & ~4);
pcicfgw8(p, 0xe4, pcicfgr8(p, 0xe4) & ~0x80);
pcicfgw8(p, 0xe5, pcicfgr8(p, 0xe5) | 0x80);

// if(pcicfgr8(p, 0x81) & 0x80)
// acpiregs = pcicfgr32(p, 0x88) & 0xff00;
}

- erik

At the risk of repeating myself, there are several VIA boards that
have issues with DMA (not necessarily isolated to HDD). Your best bet
is to have a trawl through the VIA forums ([url]www.viaarena.com[/url]) and look
for DMA related crashes being reported. Maybe you've got one of those
troublesome models.

Robby

I wrote a bit hastily:[color=blue]
> At the risk of repeating myself, there are several VIA boards that
> have issues with DMA (not necessarily isolated to HDD). Your best bet
> is to have a trawl through the VIA forums ([url]www.viaarena.com[/url]) and look
> for DMA related crashes being reported. Maybe you've got one of those
> troublesome models.[/color]

Sorry, wrote this before I spotted your other emails about working
around the issue using retries. I should try again to get my VIAs to
work with a similar workaround.

Robby

erik quanstrom wrote:
[color=blue][color=green]
>>I changed sdata.c to:
>>
>>return SDretry if starting dmarequest fails,
>>return SDretry and reseting controller if dma times out,
>>return SDretry on request is done and error signaled,
>>
>>and added a counter that resets the controller if a request
>>was 1000 times retried...
>>
>>[/color]
>
>you might want to loop internally instead of counting to 1000.
>(which may be too high. i would think that 2 or 4 would do it.
>have you seen differently?) if more than one thread is doing i/o
>to the disk and you have a bad sector, it may take an arbitrary
>amount of time before you discover this fact.
>
>[/color]
ok, will lower that number and test...
[color=blue][color=green]
>>The machine ran the whole night with bodth drives in DMA and heavy load.
>>vacing, pingflooded from outside, ddtest on both drives and still alive! :-)
>>
>>[/color]
>
>good deal. via's product page
>[url]www.via.com.tw/en/products/chipsets/southbridge/vt8237/specs.jsp[/url]
>indicates that the nic & sata controller are both integrated into the sb.
>perhaps this extra southbridge configuration (pci.c) would make the
>sdata hack unnecessary?
>
>[/color]
I'm using a famous/cheap/bad realtek PCI card.
The driver (ethervt6102.c) for the internal nic assumes that his
Ringdescriptor-structures
fit into the cache line size of the card and that is not met:

if((cls = pcicfgr8(p, PciCLS)) == 0 || cls == 0xFF)
cls = 0x10;
ctlr->cls = cls*4;
if(ctlr->cls < sizeof(Ds)){
print("vt6102: cls %d < sizeof(Ds)\n", ctlr->cls);
free(ctlr);
continue;
}

pci -v

0.18.0: net 02.00.00 1106/3065 10 0:0000f001 256 1:fdffe000 256
VIA Technology VT6102 Rhine II PCI Fast Ethernet Controller


I think LluÃ*s Batlle <viriketo@gmail.com> has the exact same problem:

[url]http://9fans.net/archive/2008/02/128[/url]

But this had low priority for me, In the worst case, would install a
3com PCI card before
using it in production.
[color=blue]
>static void
>viaset(Pcidev *p, uchar link, uchar irq)
>{
> uchar pirq;
>
> pirq = pcicfgr8(p, 0x55 + (link >> 1));
> pirq &= (link & 1)? 0x0f: 0xf0;
> pirq |= (link & 1)? (irq << 4): (irq & 15);
> pcicfgw8(p, 0x55 + (link>>1), pirq);
> if(p->vid != 0x3177 && p->vid != 0x3227)
> return;
>
> /* Set transition time to max */
> pcicfgw8(p, 0xec, pcicfgr8(p, 0xec) & ~4);
> pcicfgw8(p, 0xe4, pcicfgr8(p, 0xe4) & ~0x80);
> pcicfgw8(p, 0xe5, pcicfgr8(p, 0xe5) | 0x80);
>
>// if(pcicfgr8(p, 0x81) & 0x80)
>// acpiregs = pcicfgr32(p, 0x88) & 0xff00;
>}
>
>
>[/color]
thanks, i'll try!
[color=blue]
>- erik
>
>[/color]
cinap