Bug 245105 - iwl3945 oopses when resuming from hibernate
iwl3945 oopses when resuming from hibernate
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
x86_64 Linux
high Severity high
: ---
: ---
Assigned To: Dave Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-21 01:06 EDT by Bryan O'Sullivan
Modified: 2015-01-04 17:29 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-09 09:59:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bryan O'Sullivan 2007-06-21 01:06:54 EDT
Description of problem:

I have a Thinkpad X60.  Recent kernels oops when resuming from a suspend to
disk, requiring a "reboot -f".  This is a regression from earlier kernels, I
believe.

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

kernel-2.6.21-1.3228.fc7.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Suspend to disk from, say, gnome-power-manager.
2. Resume.
3. Oops!
  
Actual results:

kernel BUG at net/core/dev.c:2860!
invalid opcode: 0000 [1] SMP 
last sysfs file: /power/state
CPU 0 
Modules linked in: i915 drm autofs4 hidp rfcomm l2cap bluetooth sunrpc ipv6
nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink
xt_tcpudp ipt_REJECT iptable_filter ip_tables x_tables cpufreq_ondemand
acpi_cpufreq dm_mirror dm_multipath dm_mod sbs ibm_acpi i2c_ec button bay dock
battery ac parport_pc lp parport loop uinput arc4 ecb blkcipher snd_hda_intel
snd_hda_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device iwl3945 snd_pcm_oss snd_mixer_oss mac80211 e1000 snd_pcm sdhci
fw_ohci mmc_core cfg80211 snd_timer fw_core snd i2c_i801 soundcore serio_raw
i2c_core iTCO_wdt snd_page_alloc iTCO_vendor_support shpchp sg ata_generic
pcspkr ata_piix ahci libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd
uhci_hcd
Pid: 1129, comm: iwl3945/0 Not tainted 2.6.21-1.3228.fc7 #1
RIP: 0010:[<ffffffff803f0378>]  [<ffffffff803f0378>] register_netdevice+0x60/0x302
RSP: 0000:ffff81007ea75d00  EFLAGS: 00010206
RAX: 0000000000000000 RBX: ffff81007eb18320 RCX: ffff81007c7b71a8
RDX: ffff81007ea75fd8 RSI: 0000000000000b29 RDI: ffffffff8051fba4
RBP: ffff81007c7b7000 R08: ffff81007c7b7000 R09: 9380e2009480e200
R10: ffff81007eb1d4e0 R11: ffffffff8030b3e3 R12: 0000000000000000
R13: ffff81007eb1d4e0 R14: ffffffff881e2909 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff8059d000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00002aaaaaaac000 CR3: 000000002f7eb000 CR4: 00000000000006e0
Process iwl3945/0 (pid: 1129, threadinfo ffff81007ea74000, task ffff81007ed6d820)
Stack:  ffff81007eb18320 0000000000000000 0000000000000000 ffffffff8819f9c5
 ffff81007eb1d4e0 ffff81007eb1a3c8 ffff81007eb19ae0 ffffffff881e36c1
 0000000000000000 0000000000000018 0000000000000018 0000000000000100
Call Trace:
 [<ffffffff8819f9c5>] :mac80211:ieee80211_register_hw+0x11b/0x201
 [<ffffffff881e36c1>] :iwl3945:iwl_bg_alive_start+0xdb8/0xfc5
 [<ffffffff8025bde7>] thread_return+0x0/0xe8
 [<ffffffff881e2909>] :iwl3945:iwl_bg_alive_start+0x0/0xfc5
 [<ffffffff802482f7>] run_workqueue+0x8f/0x137
 [<ffffffff80244e7b>] worker_thread+0x0/0x14a
 [<ffffffff80292f90>] keventd_create_kthread+0x0/0x65
 [<ffffffff80244f8f>] worker_thread+0x114/0x14a
 [<ffffffff802819c3>] default_wake_function+0x0/0xe
 [<ffffffff8023023b>] kthread+0xd0/0xff
 [<ffffffff80257f38>] child_rip+0xa/0x12
 [<ffffffff80292f90>] keventd_create_kthread+0x0/0x65
 [<ffffffff8023016b>] kthread+0x0/0xff
 [<ffffffff80257f2e>] child_rip+0x0/0x12


Code: 0f 0b eb fe 48 8b 45 50 c7 85 00 02 00 00 01 00 00 00 c7 85 
RIP  [<ffffffff803f0378>] register_netdevice+0x60/0x302
 RSP <ffff81007ea75d00>
Comment 1 Paul T. Darga 2007-07-12 13:08:40 EDT
I get the same oops occasionally when resuming from suspend-to-ram.  Same line
of code, same stack, everything.
Comment 2 Christopher Brown 2007-09-17 07:40:57 EDT
Hello Paul,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris
Comment 3 Christopher Brown 2008-01-09 09:59:34 EST
As indicated previously there has been no update on the progress of this bug
therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue
still occurs for you and I will try to assist in its resolution. Thank you for
taking the time to report the initial bug.

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