VIA EPIA problem

Mainboard VIA EPIA mini-ITX with VIA C3 800 Mhz or 500 Mhz

I faced with strange problem connected to this mainboard.

Kernel crashed when attempt to configrue net interface.

I tried to make linux terminal based on this mainboard.
I use diet-pc project as base for this approach - diet-pc.sourceforge.net. Kernel crashed when 'pump' tried to configure eth0 via dhcp. Kernel also crashed when it tried to configure eth0 via dhcp ( CONFIG_IP_PNP & CONFIG_IP_PNP_DHCP ).

This problem occured _very_ rarely. ( about 1 time of 12-20 start/reboots of computer)
Driver used : via-rhine.
I also tried driver from VIA (linuxfet.c) . Result is same.
I tried various 2.2 - 2.4 kernels ( including last pre11 patch ). And when net interface configured it works fine.
I tried 4(!) mainboards.

The problem disappeared when I disabled on board LAN and install Realtek 8139C NIC.

So I think that problem in driver. Am I right ?

Can somebody help me or comment this problem?

Regards,
Serge.

Are you using an early cubid 2677 case or another very small power supply. There are known problems with the ethernet if you are under current

please see my posts to lkml some months (2, 3?) ago. there's a problem which stops the via-rhine. a small two-line patch will solve the problem. search in the archives for "via" and "path", because I made a typo and wrote "path" instead of "patch".

hth,
herp

Can you forward another copy to the list if you have it handy ?

okay. please note it's a workaround. but it worked at least for my board (and I have a via epia itx 500Mhz). this board seems to be the only one which had the problems with the vt6103 onboard ethernet-chip.

@@ -100,6 +100,15 @@
      - allow selecting backoff algorithm (module parameter)
      - cosmetic cleanups, remove 3 unused members of struct netdev_private
 
+     preliminary: (Herbert Rosmanith):
+     - for some yet unknown reason (which seems to be collision-related),
+      TX DMA is off in via_rhine_interrupt in the ChipCmd register. this
+      leads to an entry in the ringbuffer which is never processed and
+      therefore blocks the ringbuffer. the hack provided sets the TxRingPtr
+      in the chip to the entry blocking the ringbuffer, marking it for
+      being processed again. this error seems to happen only with the VT6103.> +
 */
 
 #define DRV_NAME     "via-rhine"

@@ -474,6 +483,8 @@
 
 #define MAX_MII_CNT  4
 struct netdev_private {
+     // XXX hack hack hack
+     int intr_cmd;
      /* Descriptor rings */
      /* Descriptor rings */
      struct rx_desc *rx_ring;

      struct tx_desc *tx_ring;
@@ -1294,11 +1305,13 @@
 static void via_rhine_interrupt(int irq, void *dev_instance, struct pt_regs *rgs)
 {
      struct net_device *dev = dev_instance;
+     struct netdev_private *np=dev->priv;
      long ioaddr;
      u32 intr_status;
      int boguscnt = max_interrupt_work;

      ioaddr = dev->base_addr;

+ np->intr_cmd=readw(ioaddr+ChipCmd); // needed later in via_rhine_tx

      while ((intr_status = readw(ioaddr + IntrStatus))) {
              /* Acknowledge all of the current interrupt sources ASAP. */
@@ -1350,8 +1363,12 @@
              if (debug > 6)
                      printk(KERN_DEBUG " Tx scavenge %d status %8.8x.\n",
                                 entry, txstatus);

- if (txstatus & DescOwn)
+ if (txstatus & DescOwn) {
+ if ((np->intr_cmd&0x0010)==0) // Gack! DMA is off
+ writel(np->tx_ring_dma + entry * sizeof(struct tx_desc),

+                                     dev->base_addr+TxRingPtr);
                      break;
+             }
              if (txstatus & 0x8000) {
                      if (debug > 1)
                              printk(KERN_DEBUG "%s: Transmit error, Tx status %8.8x.\n",

I remember going over some logs you sent me. As I said back then, the proper fix will most certainly deal with the error that turned off the Tx engine to begin with. Assuming that it's not a major "invisible error" bug in some Rhine chips, it must be an error that is currently invisible to the _driver_. Stands to reason :-).

My favorite suspect is currently byte 84 bit 3 in the configuration registers. It does not exist in VT86C100A (which would explain why it's not handled in Donald Becker's original code). According to VT6102 specs, it indicates an error condition, according to VT6105 specs, it is reserved and always reads 0.

The MAC you find on VIA EPIAs integrated into VT8231 is a VT6102, so that might actually be the culprit. I haven't been able to reproduce the error on a VT6102 based PCI-card, though.

As for the EPIA, my testing environment is somewhat limited since there seems some trick involved in getting certain VIA hardware around here. My usual contacts couldn't sell me a VIA EPIA, not even the P4PB400 (VT6105M based), let alone the mysterious, fascinating Rhine-III based PCI-card [1].

If anybody knows a reliable VIA vendor who does international delivery I'd be interested (off-list, of course, I'm not soliciting commercial email to the list <g>).

Roger

PS: Seems to be a VIA OEM card with PCI strings 1106:3106 (rev 85)

    Subsystem: 1106:0105.

okay, let's reopen the case. you want me to monitor this bit? perhaps it will be 1 in case of an error condition. for the via epia board, this would contradict with the specs, right? but *maybe* the bit is indeed 1 in case of an error, so we could possibly fix the problem just in time, instead of (ugly) storing some temporary value globally across functions.

Bit 3 in 0x84 and 0x86 are those I'm most interested in. If the chip has 0x86 bit 3 cleared, try with having it set.

If that doesn't yield anything, you may want to monitor bytes 0x08, 0x09, 0x0c, 0x0d, 0x80, 0x81, 0x84 and 0x86. Just in case.

What spec? It seems okay with the one I have.

That bit is just the obvious candidate, there might be others. Here's hoping that Rhine chips don't turn off the TxEngine without setting a flag to inform the driver.

Roger

Patch did not help.
Here is "screenshot" of kernel dump.
I'm not kernel driver programmer so I don't know whether it will be helpful to solve the problem.

Regards,
Serge.