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

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

[Kernel Panic]

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

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

[erik quanstrom]

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

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.

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

good deal.  via's product page
www.via.com.tw/en/products/chipsets/southbridge/vt8237/specs.jsp
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

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

[Robert Raschke]

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 (www.viaarena.com) and look
for DMA related crashes being reported.  Maybe you've got one of those
troublesome models.

Robby

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

[Robert Raschke]

I wrote a bit hastily:
> 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 (www.viaarena.com) and look
> for DMA related crashes being reported.  Maybe you've got one of those
> troublesome models.

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

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

[Kernel Panic]

erik quanstrom wrote:

>>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...
>>    
>>
>
>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.
>  
>
ok, will lower that number and test...

>>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! :-)
>>    
>>
>
>good deal.  via's product page
>www.via.com.tw/en/products/chipsets/southbridge/vt8237/specs.jsp
>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?
>  
>
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:

http://9fans.net/archive/2008/02/128

But this had low priority for me, In the worst case, would install a 
3com PCI card before
using it in production.

>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;
>}
>
>  
>
thanks, i'll try!

>- erik
>  
>
cinap