Bug 20882 - [2.6.36-rc5] r8169 regression...
Summary: [2.6.36-rc5] r8169 regression...
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Network (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_network@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks: 16444
  Show dependency tree
 
Reported: 2010-10-21 18:14 UTC by Maciej Rutecki
Modified: 2011-03-30 22:12 UTC (History)
8 users (show)

See Also:
Kernel Version: 2.6.36-rc5
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
801e147cde02f04b5c2f42764cd43a89fc7400a2 revert me please (1.67 KB, patch)
2010-11-07 22:08 UTC, Francois Romieu
Details | Diff

Description Maciej Rutecki 2010-10-21 18:14:00 UTC
Subject    : [2.6.36-rc5] r8169 regression...
Submitter  : Daniel J Blueman <daniel.blueman@gmail.com>
Date       : 2010-10-19 17:01
Message-ID : AANLkTimdrM0H=b1OzmJ_mxMFqe-Y-Hxs5Lof5PAmVdbj@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=128750771109738&w=2

This entry is being used for tracking a regression from 2.6.35. Please don't
close it until the problem is fixed in the mainline.
Comment 1 Andreas Radke 2010-10-29 19:20:58 UTC
Not sure if this is the same in final 2.6.36:

r8169 0000:04:00.0: eth0: link up
NOHZ: local_softirq_pending 08
NOHZ: local_softirq_pending 08
r8169 0000:04:00.0: eth0: link up
NOHZ: local_softirq_pending 08
r8169 0000:04:00.0: eth0: link up
NOHZ: local_softirq_pending 08
r8169 0000:04:00.0: eth0: link up
NOHZ: local_softirq_pending 08
NOHZ: local_softirq_pending 08
NOHZ: local_softirq_pending 08
NOHZ: local_softirq_pending 08
NOHZ: local_softirq_pending 08
NOHZ: local_softirq_pending 08
r8169 0000:04:00.0: eth0: link up
r8169 0000:04:00.0: eth0: link up
r8169 0000:04:00.0: eth0: link up
...

r8169 0000:04:00.0: eth0: link up
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:258 dev_watchdog+0x273/0x280()
Hardware name: OEM
NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
Modules linked in: fuse rfcomm sco bnep l2cap cpufreq_ondemand nfsd
exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc w83627ehf
hwmon_vid microcode btusb bluetooth rfkill gspca_sonixb gspca_main
videodev v4l1_compat v4l2_compat_ioctl32 joydev reiserfs usbhid hid
acpi_cpufreq freq_table mperf nouveau snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device ttm drm_kms_helper drm eeprom
i2c_algo_bit video snd_pcm_oss sr_mod output snd_mixer_oss cdrom
snd_hda_codec_realtek snd_hda_intel abituguru3 snd_hda_codec snd_hwdep
snd_pcm coretemp snd_timer i2c_i801 snd r8169 soundcore iTCO_wdt evdev
uhci_hcd psmouse mii snd_page_alloc thermal button ehci_hcd processor
shpchp sg iTCO_vendor_support usbcore pci_hotplug i2c_core serio_raw
pcspkr intel_agp tpm_tis tpm tpm_bios pata_jmicron rtc_cmos sd_mod ahci
libahci libata scsi_mod ext4 mbcache jbd2 crc16 Pid: 0, comm:
kworker/0:1 Not tainted 2.6.36-ARCH #1 Call Trace: <IRQ>
[<ffffffff81054eea>] warn_slowpath_common+0x7a/0xb0
[<ffffffff81054fc1>] warn_slowpath_fmt+0x41/0x50 [<ffffffff812f6563>]
dev_watchdog+0x273/0x280 [<ffffffff810da6e8>] ?
perf_event_task_tick+0x148/0x180 [<ffffffff81064327>]
run_timer_softirq+0x157/0x3b0 [<ffffffff8104f845>] ?
scheduler_tick+0xe5/0x2a0 [<ffffffff812f62f0>] ? dev_watchdog+0x0/0x280
[<ffffffff81012fd9>] ? read_tsc+0x9/0x20 [<ffffffff8105c013>]
__do_softirq+0xc3/0x220 [<ffffffff81084c48>] ?
tick_dev_program_event+0x48/0x100 [<ffffffff81084d25>] ?
tick_program_event+0x25/0x30 [<ffffffff8100be5c>]
call_softirq+0x1c/0x30 [<ffffffff8100e155>] do_softirq+0x65/0xa0
[<ffffffff8105c26d>] irq_exit+0x8d/0x90 [<ffffffff810287ab>]
smp_apic_timer_interrupt+0x6b/0xa0 [<ffffffff8100b913>]
apic_timer_interrupt+0x13/0x20 <EOI>  [<ffffffff81014090>] ?
mwait_idle+0x80/0x110 [<ffffffff8107b7e1>] ?
atomic_notifier_call_chain+0x11/0x20 [<ffffffff81009236>]
cpu_idle+0xa6/0x170 [<ffffffff8138266a>] start_secondary+0x215/0x21c
---[ end trace 5e822bdbeb9e75f4 ]--- r8169 0000:04:00.0: eth0: link up
r8169 0000:04:00.0: eth0: link up



Any idea? Something different?
Comment 2 Francois Romieu 2010-11-07 22:07:26 UTC
It looks the same.

Can you try reverting 801e147cde02f04b5c2f42764cd43a89fc7400a2 ?

-- 
Ueimor
Comment 3 Francois Romieu 2010-11-07 22:08:58 UTC
Created attachment 36602 [details]
801e147cde02f04b5c2f42764cd43a89fc7400a2 revert me please
Comment 4 Andreas Radke 2010-11-08 21:12:22 UTC
Applied it with patch -R and got a clean dmesg again. Seems solved. Thanks.

Will it also go into the .36.x stable series?
Comment 5 Florian Mickler 2010-11-16 16:41:25 UTC
Patch: http://www.spinics.net/lists/netdev/msg146247.html
Comment 6 Rafael J. Wysocki 2010-11-18 23:44:52 UTC
Fixed by commit 53f57357ff0afc37804f4e82ee3123e0c0a2cad6 .
Comment 7 Andreas Radke 2010-11-23 06:13:37 UTC
The fix is not in 2.6.36.1 and so far not in the stable staging commits for 36.2 - please send it to Grek for the stable tree!
Comment 8 Florian Mickler 2011-03-30 22:12:16 UTC
This has been applied to 2.6.36.2 .

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