Opened 11 years ago

Closed 11 years ago

#1874 closed bug (fixed)

VIA Rhine-II not working

Reported by: scottmc Owned by: axeld
Priority: normal Milestone: R1
Component: Drivers/Network Version: R1/pre-alpha1
Keywords: Cc: scottmc, adek336@…, dwashington@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (3)

listdev (1.9 KB) - added by sklp 11 years ago.
listdev output from my machine
where_output (2.0 KB) - added by sklp 11 years ago.
listdev.2 (1.9 KB) - added by denisw 11 years ago.
listdev output (using hrev27214)

Download all attachments as: .zip

Change History (27)

comment:1 Changed 11 years ago by scottmc

Component: - GeneralDrivers/Network

comment:2 Changed 11 years ago by scottmc

Cc: scottmc added

Changed 11 years ago by sklp

Attachment: listdev added

listdev output from my machine

comment:3 Changed 11 years ago by 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).

Changed 11 years ago by sklp

Attachment: where_output added

comment:4 Changed 11 years ago by sklp

additional note: used hrev25075

comment:5 Changed 11 years ago by 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)?

comment:6 Changed 11 years ago by 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.

Changed 11 years ago by denisw

Attachment: listdev.2 added

listdev output (using hrev27214)

comment:7 Changed 11 years ago by 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]

comment:8 Changed 11 years ago by 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] 

comment:9 Changed 11 years ago by Adek336

Cc: adek336@… added

comment:10 Changed 11 years ago by denisw

Cc: dwashington@… added

comment:11 Changed 11 years ago by 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.

comment:12 Changed 11 years ago by 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.

comment:13 Changed 11 years ago by Adek336

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

comment:14 Changed 11 years ago by 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.

comment:15 Changed 11 years ago by denisw

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

comment:16 in reply to:  11 Changed 11 years ago by 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.

comment:17 Changed 11 years ago by 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!

comment:18 Changed 11 years ago by 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 .

comment:19 Changed 11 years ago by 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.

comment:20 Changed 11 years ago by 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?

comment:21 Changed 11 years ago by 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?

comment:22 Changed 11 years ago by axeld

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

comment:23 Changed 11 years ago by Adek336

it sure works!

comment:24 Changed 11 years ago by axeld

Resolution: fixed
Status: newclosed

Thanks for the update!

Note: See TracTickets for help on using tickets.