VIA Rhine-II not working

[scottmc]

From the listdev output:

device Network controller (Ethernet controller) [2|0|0] vendor 1106: VIA Technologies, Inc. device 3065: VT6102 [Rhine-II]

As of hrev24128 it is not yet working on my eMachine M6805 laptop. If further debug info is needed just ask.

[sklp]

listdev output from my machine

[sklp]

I can confirm this bug.

I can set an IP, etc, but when i try to use the networking, e.g. ping some computer, It won't work. And I've noticed that when I ping the haiku box from another machine the haiku machine will get a kernel panic. I've attached output from kernel debugger from the ping crash ('where' command) and the listdev output of the machine. Another thing that might be useful info(?), I had to disable APIC in the BIOS in order for the machine to boot haiku(ticket #2111).

[sklp]

additional note: used hrev25075

[denisw]

I can confirm this too. Because many VIA-based motherboards ship with this chipset on-board (I have an AsRock board, for instance), I think this problem is quite important. Maybe make it a blocker for a second Alpha (if not Alpha 1)?

[scottmc]

@denisw Can you post the output of listdev run from your terminal? Also where Haiku revision? Listdev was fixed again in hrev27195

The laptop I had with the VIA RhineII is now dead, so hopefully between denisw and sklp we will have some hardware to try out possible fixes.

[denisw]

listdev output (using hrev27214)

[Adek336]

confirmed on hrev27217, grep via_rhine /var/log/syslog says

KERN: KDiskDeviceManager::_AddDiskS<TRUNC>K[via_rhine] (vr) restarting KERN: /dev/net/via_rhine/0: media change, media 0x900026 quality 1000 speed 10000 KERN: [via_rhine] (vr) tx shutdown timeout KERN: [via_rhine] (vr) restarting KERN: [via_rhine] (vr) tx shutdown timeout KERN: [via_rhine] (vr) restarting [many more copies of tx shutdown timeout / restarting messages]

[Adek336]

reposted for better formatting:

KERN: KDiskDeviceManager::_AddDiskS<TRUNC>K[via_rhine] (vr) restarting
KERN: /dev/net/via_rhine/0: media change, media 0x900026 quality 1000 speed 10000
KERN: [via_rhine] (vr) tx shutdown timeout
KERN: [via_rhine] (vr) restarting
KERN: [via_rhine] (vr) tx shutdown timeout
KERN: [via_rhine] (vr) restarting
[many more copies of tx shutdown timeout / restarting messages] 

[denisw]

I added some device_printf() calls to ciphy_attach() and ukphy_attach() and noticed that these messages don't seem to appear in the syslog; the MII bus driver doesn't seem to be loaded at all. Furthermore, I uncommented some debug output statements in the FreeBSD compatibility layer's device.c, which gave me the following syslog output (lines about other components stripped out:

KERN: [net/via_rhine/0] compat_write(592, 0x933fa0ee, [296])
KERN: [via_rhine] (vr) tx shutdown timeout
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
KERN: [via_rhine] (vr) restarting
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
KERN: Last message repeated 4 times.
KERN: [net/via_rhine/0] compat_write(888, 0x933fa0ee, [296])
KERN: [via_rhine] (vr) tx shutdown timeout
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
[and so on]

It might maybe also help that the "tx shutdown timeout" is triggered from the interrupt handler (vr_intr() in if_vr.c) which repeatedly receives VR_ISR_TX_ABRT as status.

[Adek336]

The mii files are not linked in the via_rhine module: (trunk/src/add-ons/kernel/drivers/network/via_rhine/pci/Jamfile)

KernelAddon via_rhine :
	if_vr.c
	glue.c
	: libfreebsd_network.a via_rhine_mii.a

so either they're not loaded at all or via_rhine_mii.a is linked to something else (which I doubt - the only Jamfiles mentioning the file are via_rhine/pci/Jamfile and via_rhine/dev/mii/Jamfile).

And, via_rhine_mii.a is not copied onto the Haiku partition.

[Adek336]

silly me, I thought that colon was a semicolon starting a comment ! it is linked in after all.

[Adek336]

If I add

char *c; c= (char*)0x303; *c=0;

to the top of ukphy_attach(), on the next boot I get a kdl read fault at 0x303 so I believe ukphy_attach() is called; cipy_attach() probably as well.

[denisw]

You're right, your code "works" for me to, so ukphy_attach() is indeed called.

[denisw]

Replying to denisw:

[...] Furthermore, I uncommented some debug output statements in the FreeBSD compatibility layer's device.c, which gave me the following syslog output (lines about other components stripped out:

KERN: [net/via_rhine/0] compat_write(592, 0x933fa0ee, [296])
KERN: [via_rhine] (vr) tx shutdown timeout
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
KERN: [via_rhine] (vr) restarting
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
KERN: Last message repeated 4 times.
KERN: [net/via_rhine/0] compat_write(888, 0x933fa0ee, [296])
KERN: [via_rhine] (vr) tx shutdown timeout
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
KERN: [net/via_rhine/0] compat_control(op 10007, 0x909f6f88, [16])
[and so on]

One thing about the recurring compat_control() calls that might help: "op 10007" seems to be the ETHER_GET_LINK_STATE ioctl command (defined in headers/private/net/ether_driver.h) which is sent by update_link_state() in add-ons/kernel/network/devices/ethernet/ethernet.cpp. update_link_state() is in turned called by ethernet_up() in the same file.

[Adek336]

As for syslog losing messages: it happens only if the via_rhine driver is available at boot-time. So, delete the driver (/boot/beos/system/add-ons/kernel/drivers/bin/via_rhine and the /boot/home/config/... equivalent) and boot without it. After boot place the driver file where it should be and, voila. Driver will be loaded and all debugging messages will be available to see!

[Adek336]

The driver comes from FreeBSD 7 so I tried to add dprintfs in the code and see if the outputs differ on Haiku and FreeBSD, but I didn't yet find much. The driver works fine under FreeBSD.

This seem to be the proper specs ​http://joostm.nl/solaris/vr/doc/VT86C100A03.pdf .

[Adek336]

So cool, I actually made Haiku to sent exactly one frame to the link partner for inspection in WireShark. Changes in if_vr.c:

added:

static void tx_trash(struct ifnet *ifp);
static void tx_trash(struct ifnet *ifp)
{
    struct vr_softc   *sc = ifp->if_softc;
    uint32_t   cval;

    sc->vr_tx_prod->vr_data = 0;

    cval = 100;
    cval |= VR_TXCTL_TLINK;
    cval |= VR_TXCTL_FIRSTFRAG;
    cval |= VR_TXCTL_LASTFRAG;
    cval |= VR_TXCTL_FINT;
    sc->vr_tx_prod->vr_ctl = cval;

    sc->vr_tx_prod->vr_status = 0;

    atomic_set_acq_32(&sc->vr_tx_prod->vr_status, VR_TXSTAT_OWN);

    VR_SETBIT16(sc, VR_COMMAND, VR_CMD_TX_GO);
}

changed:

...
int ya=0;
static void
vr_tick(void *xsc)
{
   struct vr_softc *sc = xsc;
   struct mii_data *mii;

   ya++;
   if (ya == 5)
       tx_trash(sc->vr_ifp);

   VR_LOCK_ASSERT(sc);
....

tx_trash is a stripped down from vr_start_locked to the minimum to send a frame; it is invoked after a few ticks from vr_tick.

I added a dprintf to vr_start and it seems that in FreeBSD it is called when a new frame is to be sent, however on Haiku vr_start didn't seem to be called at all.

[axeld]

Have you tried to add a panic() instead? It's definitely called within the compatibility layer, at least.

When writing a frame, ether_output() is called, which uses the IFQ_HANDOFF() macro to call if_start() (which calls ifnet::if_start(), which is set to vr_start() in the VIA Rhine driver). Since the macro checks the error argument as well as IFF_DRV_OACTIVE: have you checked what values they contain?

[Adek336]

Yay I solved it!

static void
vr_start_locked(struct ifnet *ifp)
{
  ...
  for ( cur_tx = sc->vr_tx_prod;
        cur_tx->vr_next != sc->vr_tx_cons; )
  {
     IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head);
     if (m_head == NULL)
             break;
+     m_head->m_pkthdr.len = m_head->m_len;
//or
+     m_head->m_pkthdr.len = 200;
//both seem to work.
      VR_LOCK_ASSERT(sc);
...

You're right! vr_start is called indeed. I didn't look at the logs closely enough.

Now after dequeueing m_head it's got m_pkthdr.len == 0. Looking at

    if (m_head->m_pkthdr.len < VR_MIN_FRAMELEN) {

a few lines lower suggest that ==0 is not right. Do other drivers on FreeBSD compat work? Is m_pkthdr.len set to 0 in them as well?

[axeld]

Does hrev27674 help, too? In any case, thanks a lot for finding the cause of this!

[Adek336]

it sure works!

[axeld]

Thanks for the update!