Posts from November 2010.

Solved: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang

On one amd64 machine running CentOS 5.5 x86_64 the e1000 network interfaces go down and up with the following messages:

e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
 Tx Queue             <0>
 TDH                  <62>
 TDT                  <8d>
 next_to_use          <8d>
 next_to_clean        <62>
buffer_info[next_to_clean]
 time_stamp           <10037f7b6>
 next_to_watch        <62>
 jiffies              <10037fcd4>
 next_to_watch.status <0>
NETDEV WATCHDOG: eth0: transmit timed out

This issue usually appears on machines with 4GB or more memory. I have tried a lot of things but no luck.

The fix comes with new Intel’s e1000 driver.

Download the latest driver from e1000 stable on SF (8.0.25 at the time of writing).

Build the RPM:

rpmbuild -tb /path/to/e1000-8.0.25.tar.gz

Install the new e1000 RPM driver:

rpm -ivh /usr/src/redhat/RPMS/x86_64/e1000-8.0.25-1.x86_64.rpm

Add ignore_64bit_dma=1 driver option in /etc/modprobe.conf:

options e1000 ignore_64bit_dma=1

Reboot and enjoy!

From e1000 README file:

ignore_64bit_dma
—————-
Valid Range:   0-xxxxxxx (0=off)
Default Value: 0
Usage: insmod e1000.ko ignore_64bit_dma=1

When non zero the driver will only request DMA mapping of host memory
in the lower 4GB region. This provides a workaround for users of AMD platforms
GA-MA78G-DS3H & SM4021M-T2R+ that have reported TXHangs on system that have
>4GB RAM, suspected caused by some (no deep root cause) issue in the Dual
Address Cycle (DAC) DMA mechanism needed to access addresses above 4GB.
Setting ignore_64bit_dma to 1 activates the workaround.

This parameter is different than other parameters, in that it is a
single (not 1,1,1 etc.) parameter applied to all driver instances and
it is also available during runtime at
/sys/module/e1000/parameters/ignore_64bit_dma

Update: if your newer kernel crashes with e1000 ElRepo driver version 8.0.30 or older (detailed here), please update to the latest version, currently 8.0.35. Thanks again ElRepo!

Installing Solaris 11 Express domU under CentOS 5 dom0

First, download Solaris 11 Express from Oracle.

Install Solaris 11 Express HVM domU with virt-install:

virt-install -n sx11 -r 2048 --vcpus=4 --os-type=solaris --os-variant=opensolaris \
-v -c /path/to/sol-11-exp-201011-text-x86.iso --disk path=sx11.img,size=20 \
-b br1 --vnc --noautoconsole

Of course, adjust domU memory (-r), vcpus, path to Solaris 11 Express DVD, disk path, network bridge (-b).

After installation has started, you can connect to the VNC display. First, determine which port:

virsh vncdisplay sx11
:8

Finish the installation as usual. After reboot, you can start the Solaris 11 Express domU:

virsh start sx11

or have the domain autostarted at dom0 boot:

virsh autostart sx11

Or disable autostarting

virsh autostart --disable sx11

Enjoy!

Fedora 14 pptpd RPMs

Fedora 14 source RPM:
pptpd-1.3.4-1.fc14.src.rpm MD5 8fe1eae2096eb387c74394618027dda1

Fedora 14 x86_64 RPM:
pptpd-1.3.4-1.fc14.x86_64.rpm MD5 17c9bf6473168b1b59ca331fb73b55b7

For more informations please see my previous posts here and here.

Enjoy!

Fedora 13 pptpd RPMs

Fedora 13 source RPM:
pptpd-1.3.4-1.fc13.src.rpm
MD5 8ccf41430af197e85ba7b67a0d6b95ea

Fedora 13 i386 RPM:
pptpd-1.3.4-1.fc13.i386.rpm MD5 904bcab3f58784a362499496ebdacb25

Fedora 13 x86_64 RPM:
pptpd-1.3.4-1.fc13.x86_64.rpm MD5 3d3209427d11981ef1827bd004e65736

I have commented out logwtmp in pptpd.conf, please see my previous post.

Tested with the following PPTP clients: Apple Mac OS X 10.6.4, Apple iPad (iOS 3.2.2), Apple iPhone 4 (iOS 4.1), Apple iPhone 3GS (iOS 4.1), Apple iPhone 3G (iOS 4.1), Microsoft Windows 7 Professional, Microsoft Windows XP Professional SP3, pptpclient 1.7.2, mpd 5.5.

Enjoy!