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.
On Fri, 2002-10-25 at 16:00, Serge wrote:
> 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.
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
> On Fri, 2002-10-25 at 16:00, Serge wrote:
> > 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.
>
> 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
On Wed, 2002-10-30 at 22:13, H.Rosmanith (Kernel Mailing List) wrote:
> 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".
Can you forward another copy to the list if you have it handy ?
> On Wed, 2002-10-30 at 22:13, H.Rosmanith (Kernel Mailing List) wrote:
> > 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".
>
> 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.
--- via-rhine.c.p9-debug Thu Aug 29 07:14:12 2002
+++ via-rhine.c Thu Aug 29 07:12:43 2002
@@ -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",
On Thu, 31 Oct 2002 00:43:59 +0100, H.Rosmanith (Kernel Mailing List) wrote:
> 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.
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.
>
> 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.
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.
On Thu, 31 Oct 2002 12:36:20 +0100, H.Rosmanith (Kernel Mailing List) wrote:
> >
> > 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.
>
> okay, let's reopen the case. you want me to monitor this bit? perhaps
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.
> 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
What spec? It seems okay with the one I have.
> 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.
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
On Thursday 31 October 2002 02:43, H.Rosmanith (Kernel Mailing List) wrote:
>>SKIP
> 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.
>> SKIP
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.