[mythtv-users] Kernel Crashes using anything over 2.6.35

[f-myth-users at media.mit.edu]

    > Date: Sat, 20 Aug 2011 16:04:16 -0500
    > From: Rob Davis <rob at davis-family.info>

    > I seem to remember reading something on the list here about people
    > having problems with the rtl8139 gigabit driver and thought that might
    > be the reason why my system won't work with anything over 2.6.35.

I have absolutely had problems with the 8139, on twin identical
systems where it was built into the motherboard, running Ubuntu
11.04 with Ubuntu's drivers.  They vanished permanently when I
put Intel gigabit NICs into available PCI slots.  [IIRC, I also
tried stepping back to 10.10 or 10.04 or something like that and
had identical problems; it also failed on LiveCDs in either 32-
or 64-bit mode.]

The fastest way to make it fail is to raise the bitrate; the time
to failure decreases exponentially with increaing interrupt density.

In my case, the failure -did not- manifest without PCI bus activity;
I could saturate either NIC completely and see no failures unless I
also had PCI going on.  But once I did, either machine would wedge
(or toss lots of kernel oopses into the logs) within a few minutes.

The PCI activity, in my case, was to PCI-based multiport SATA
controllers, so the advice below (to involve disks in the test) may
only apply if you have similar PCI issues, but you get the idea.

Either way, use "nc" (alias "netcat") to pump data to the machine from
elsewhere at high rate.  Don't use scp or rsync or anything like that,
because ssh will consume lots of cycles running the crypto and will
slow you down enough to mask the failures.

If your machine can be made to wedge without disk activity, then just
doing something like "dd if=/dev/zero | nc -w 3 othermachine 1324"
at one end and "nc -l 1234 > /dev/null" is probably enough.  (Beware:
untested -and- nc's args are different between the older version and
the OpenBSD-like version.)

If that doesn't work, substitute /some/file for /dev/null on the
suspect machine.  Or, if it's easier, make the suspect machine the
transmitter with "dd if=/dev/sda" feeding the nc.  Etc.  (Just make
sure that's an "if" and not an "of"!)

If you already have NFS installed, you can also just copy giant things
around that way.

It's possible that using Realtek's own drivers make their hardware
reliable, but by the time I'd worked up a reliable test case, I
decided I'd just had it with their hardware and didn't want to take
the risk that some system update would replace their driver with
Ubuntu's again and I wouldn't notice until the machine flaked out.
A $15 Intel gigabit NIC was a much cheaper solution when factoring
in my time, and I had the spare slot.

If you go that route, remember to update your udev rules to use
the correct NIC.