via_rhine II ethernet controller: svn hangs

[Adek336]

Ethernet controller is via_rhine II, I can begin a svn checkout of the haiku sources, it downloads some files and hangs (I waited for a few minutes but it didn't continue). After killing svn and removing the partial downloads, I can again try to checkout but only a few files download (sometimes 800, sometimes 5000); it stops on different files.

Sometimes but rarely, after killing svn and trying to rm -r trunk causes rm: FATAL: directory trunk//src/build/.svn changed dev/ino, different directories get mentioned here.

In KDL I can see that the svn thread is waiting for a semaphore called "tcp receive" during the hang.

[Adek336]

svn 1.4.6, haiku hrev28099

[Adek336]

just as a note, svn worked here flawlessly just about 2 weeks ago

[Adek336]

When the network is heavily loaded, svn (although more slowly) is able to download a lot more files. After downloading about 30,000 files the network load (previously caused by additional downloads on another computer in the LAN) decreased, and then svn hung.

[Adek336]

This happens on a via_rhine II and does not happen on a broadcom tigon3 adapter.

[bbjimmy]

Replying to Adek336:

This happens on a via_rhine II and does not happen on a broadcom tigon3 adapter.

I have the same issue with via_rhine and rtl8139. I cannot so an SVN checkout without killing the stalled SVN and restarting it. Needed to run svn cleanup possibly delete some files or directories to get it to start again. SVN usually stops about four times doing a complete checkout of the haiku trunk.

[Adek336]

patch

[Adek336]

compat_read() was conscious only of the first mbuf in a mbuf chain. Actually not all drivers seem to create long mbuf chains, and in practice, only packets small enough to fit in MHLEN bytes and trigger (totlen + off + max_linkhdr <= MLEN) in m_devget() but big enough to have (total_len >= MHLEN - max_linkhdr) would be broken into two mbufs.

patch fixes this and #2908.

[axeld]

Nice catch! I've applied it in hrev28599.