From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040626 Firefox/0.9.1

Description of problem:
YUM upgraded to the 2.6.7-1.494.2.2 kernel, and now tc filter commands
return:    RTNETLINK answers: Invalid argument

I'm on a P4 so it naturally uses the smp version of the kernel. tc
filter commands that once worked now fail. Returning to the
2.6.6-1.435.2.3smp kernel allows tc filter commands to work once again.

I can't find any messages (dmesg or messages) that hint at a problem


Version-Release number of selected component (if applicable):
2.6.7-1.494.2.2

How reproducible:
Always

Steps to Reproduce:
1.Boot 2.6.7-1.494.2.2smp kernel
2.Run a typical set of tc commands via a script and all tc filter
commands fail.
3.Boot the older 2.6.6-1.435.2.3smp kernel and the exact same script
works.
    

Actual Results:  Here is the actual script output via #!/bin/bash -x
+ tc qdisc del dev eth1 root
+ tc qdisc add dev eth1 root handle 1: htb default 100
+ tc class add dev eth1 parent 1: classid 1:1 htb rate 150kbit ceil
150kbit
+ tc class add dev eth1 parent 1:1 classid 1:10 htb rate 140kbit ceil
150kbit
+ tc class add dev eth1 parent 1:1 classid 1:100 htb rate 10kbit ceil
150kbit
+ tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
+ tc qdisc add dev eth1 parent 1:100 handle 100: sfq perturb 10
+ tc filter add dev eth1 protocol ip parent 1:0 prio 10 u32 match ip
dport 53 0xffff flowid 1:10
RTNETLINK answers: Invalid argument
+ tc filter add dev eth1 protocol ip parent 1:0 prio 20 u32 match ip
dport 22 0xffff flowid 1:10
RTNETLINK answers: Invalid argument
+ tc filter add dev eth1 protocol ip parent 1:0 prio 30 u32 match ip
dport 80 0xffff flowid 1:10
RTNETLINK answers: Invalid argument
+ tc filter add dev eth1 protocol ip parent 1:0 prio 40 u32 match ip
dport 25 0xffff flowid 1:10
RTNETLINK answers: Invalid argument
+ tc filter add dev eth1 protocol ip parent 1:0 prio 40 u32 match ip
dport 110 0xffff flowid 1:10
RTNETLINK answers: Invalid argument


Expected Results:  tc filter commands were accepted via the prior kernel

Additional info:

mobo is an ASUS P4P800-VM, but I've never had a problem installing any
Redhat or Fedora versions on over a dozen of these boards, unlike the
reports of failures I've heard about. This is the -VM version, not the
plain P4P800, so that may make the difference. Every kernel prior to
2.6.7-1.494.2.2 has worked without a problem. The NIC I'm using the tc
commands on is a 3COM 3c59x, not the NIC built into the mobo.

I'm experimenting on tc so the script I'm using may not make logical
sense, but the commands were accepted via the older kernel and the
newer one fails on them.