Bug 197092 - tc causes kernel panic with delay on lo
Summary: tc causes kernel panic with delay on lo
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-06-28 14:46 UTC by James Hunt
Modified: 2015-01-04 22:27 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-11 06:17:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.



Note You need to log in before you can comment on or make changes to this bug.