Bug 197092

Summary: tc causes kernel panic with delay on lo
Product: [Fedora] Fedora Reporter: James Hunt <jamesodhunt>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED WORKSFORME QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: pfrields, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-11 06:17:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description James Hunt 2006-06-28 14:46:10 UTC 
Description of problem:

I've been playing around with 'tc' for qos/traffic shaping, but causes kernel
panics with kernel 2.6.17-1.2139_FC5.

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

kernel-2.6.17-1.2139_FC5

How reproducible:

Every time.

Steps to Reproduce:
1. tc qdisc add dev lo root netem delay 1000ms
2. panic!
3.
  
Actual results:

BUG: unable to handle kernel paging request at virtual address 1a191817
 printing eip:
1a191817
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_setspeed
Modules linked in: sch_netem autofs4 hidp l2cap sunrpc sd_mod sg video ibm_acpi
button battery ac lp parport_pc parport hci_usb bluetooth usb_storage scsi_mod
joydev ehci_hcd uhci_hcd wlan_scan_sta(U) ath_rate_sample(U) wlan(U) ath_hal(U)
e1000 snd_intex8x0 intel8x0m snd_ac97_codec snd_ac97_bus snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss
snd_pcm snd_timer snd i2c_i801 i2c_core hw_random soundcore snd_page_alloc
dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd
CPU: 0
EIP: 0060:[<1a191817>] Tainted: PF VLI
EFLAGS: 00010296 (2.6.17-1.2139_FC5 #1)
EIP is at 0x1a191817
eax: c075a000 ebx: f5e42e00 ecx: c06bd940 edx: c06b6c80
esi: f5e43ec0 edi: f7f45040 ebp: c07ad100 esp: c075af18
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c075a000 task=c06b6c80)
Stack: <stack addresses>
Call Trace:
 <c05abb69> netif_receive_skb+0x20a/0x265 <c05ad2b3> process_backlog+0x6e/0x126
 <c05ad3e8> net_rx_action+0x7d/0x151 <c05ab925> net_tx_action+0xb0/0xcc
 <c042070b> __do_softirq+0x35/0x7f <c040508a> do_softirq+0x38/0x42
 =======================
 <c0405047> do_IRQ+0x75/0x80 <c04036f2> common_interrupt+0x1a/0x20
 <c0512e57> acpi_processor_idle+0x15a/0x32b <c0401f4d> cpu_idle+0x3a/0x4f
 <c071f724> start_kernel+0x2d7/0x2db <c071f249> unknown_bootoption+0x0/0x204
Code: Bad EIP value.
EIP: [<1a191817>] 0x1a191817 SS:ESP 0068:c075af18
 <0> Kernel panic - not syncing: Fatal exception in interrupt

<continues>

Note: I've had to copy this panic by hand as I don't have a serial cable.
However, I've checked the addresses, etc for correctness.


Expected results:

no panic!

Additional info:
Comment 1 James Hunt 2006-07-04 20:34:01 UTC 
I suspect this particular bug would hit RHEL customers quite hard if they're
running the box as a router... any ideas anyone?
Comment 2 James Hunt 2006-07-14 10:33:27 UTC 
This still panics my box using kernel 2.6.17-1.2145_FC5smp.
Comment 3 Dave Jones 2006-08-11 06:17:20 UTC 
Can't reproduce this here (after trying multiple boxes/configs).  I'm highly
suspicious of the binary modules you have loaded.  Please reopen if it's
reproducable without them ever having been loaded.