System freezed with network cable attached, with rtl81xx driver

[jackburton]

I have an Intel Core 2 Duo system, the NIC is a rtl8101 (id 8136). As soon as I connect the network cable, the cpu activity goes to 100% (only for one cpu, the other is idle) and the system becomes completely unresponsive (yeah, not even F12 works anymore). Top shows that the thread "fast taskq" is getting all the cpu load. The driver uses the freebsd compat layer. Disabling one core makes the system work correctly.

[jackburton]

Reassigning to me, at least for now.

[jackburton]

If I enter KDL and "unreal" the fast taskq thread, the system also goes back to normal. So this might be a scheduler issue ?

[axeld]

Unlikely, this rather seems to be a problem of the driver's interrupt handler: the fast taskq thread should be a high priority thread. If it's using too much CPU time, it has a problem.

[jprostko]

I have an MSI Wind U100 laptop with Realtek ethernet (Device ID: 8136), which uses the rtl81xx driver. If I exclude OpenSound, no freezes occur whatsoever, no matter which other packages I include. This is with both cores enabled, and I had Haiku up and running for about 2 hours at one point, so it seems stable. For reference, I have a GCC 2/4 hybrid build, with all the GPL addons and third party stuff, as well as ATA and FreeType enabled. I am typing this message from within Haiku, and have all packages installed except OpenSound. I also tried a bunch of other builds (like the one for the pre-alpha, and other variants), but adding OpenSound is the only thing that causes the freeze you described. In that case, OpenSound enables my Realtek ALC 888S, and I see "Intel HD" under the media preferences.

So yes, can you try running a build without OpenSound (like the pre-alpha at haiku-files.org) and see if you notice the freeze issue go away? Maybe that could help the problem get narrowed down anyways.

[umccullough]

OpenSound is currently not capable of detecting if another sound driver is already loaded for a given sound device, thus you should not use it if another driver already supports your sound chip.

In the case of Intel HDA - Haiku has an incomplete driver already for these devices, but it may or may not work properly - but if you're seeing it loaded, I personally wouldn't recommend using OpenSound with it as well, unless you remove the intel HDA driver manually from your image.

Whether this can cause the issues you're experiencing or not, i'm not sure, although interrupt sharing seems to be an issue currently as well, so perhaps your sound and network hardware are sharing an interrupt.

[jprostko]

Urias, you are correct. When I have use OpenSound, it ends up sharing IRQ 11 with the ethernet adapter. The two must get in each other's way and cause the hang. Like jackburton though, I can disable a core (only disabling the first core will work) and get around the issue. I tried disabling SMP via the "kernel" file, but that ended up making it impossible for the rtl81xx driver to load, as I was getting a "PHY write failed" when looking at the syslog.

In any case, for now I added "hda" to HaikuImage, and built the image without OpenSound. hda shares IRQ 11 again with the ethernet driver, but they seem to get along just fine, even with both cores active. Granted, I don't get any sound at all with hda (as compared with the garbly mess that OpenSound provided), but I suppose that is outside the scope of this bug.

[jackburton]

I can confirm that disabling OSS makes the system work correctly, even with both cores enabled. IRQ 11 is shared also on my system between the sound card and the ethernet adapter.

[jackburton]

Replying to jackburton:

I can confirm that disabling OSS makes the system work correctly, even with both cores enabled. IRQ 11 is shared also on my system between the sound card and the ethernet adapter.

Actually, recent tests showed that even without OSS, the problem persists.

[jackburton]

BTW, this and #2084 seems to be the same problem, only with different NIC drivers.

[jackburton]

I was able to test this and doesn't seem to happen anymore. I think the winning change was introduced by Michael Lotz in hrev29242. Closing. Should we close #2084 as well, since from the comment there it appears to have been fixed ?