Bug 437677 - iwl4965 doesn't work after suspend/resume cycle
iwl4965 doesn't work after suspend/resume cycle
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i686 Linux
low Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-16 03:08 EDT by John F
Modified: 2008-10-05 16:38 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-19 14:35:33 EDT
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 John F 2008-03-16 03:08:51 EDT
Description of problem:
When I suspend my laptop and resume, my iwl4965 doesn't resume operation.  If I
rmmod iwl4965 then modprobe iwl4965 it immediately resumes operation and works
fine with NetworkManager again.

Version-Release number of selected component (if applicable):
Driver built into the kernel.  My uname -a is "Linux dv2727ca 2.6.24.3-12.fc8 #1
SMP Tue Feb 26 14:58:29 EST 2008 i686 i686 i386 GNU/Linux".  DV2727CA is my
laptop model and hostname

How reproducible:
100%

Steps to Reproduce:
1.suspend laptop
2.resume laptop
3.notice lack of network
4.rmmod iwl4965 then modprobe it
5.notice fully working network
  
Actual results:
Network doesn't work

Expected results:
Network works

Additional info:
Comment 1 John F 2008-03-16 15:12:27 EDT
As well, when the network is in a non working state, NetworkManager shows other
SSIDs, but they are all secured and not mine, so i can't check if they are
connectable.  I tried manually adding my network, which didn't work.  It is also
now happening when i log out then log back in.  Basically, any time i leave my
desktop, the driver dies
Comment 2 John F 2008-03-16 16:33:08 EDT
I just updated to a new kernel "Linux dv2727ca 2.6.24.3-34.fc8 #1 SMP Wed Mar 12
18:17:20 EDT 2008 i686 i686 i386 GNU/Linux" and it seems to fix my problem.  It
takes about 30 seconds, but my network comes back.  I have only tested it once
though
Comment 3 John F 2008-03-19 00:28:03 EDT
Issue still seems to be present when I logout and login.  
Comment 4 Dan Williams 2008-03-31 12:12:35 EDT
Can you attach some logs from /var/log/messages from the period of time during a
connection attempt?
Comment 5 François Kooman 2008-04-08 08:31:00 EDT
Same issue here, once you've been successfully connected to a (in my case
WPA2-PSK) network it doesn't work automatically anymore after disconnecting
(restarting NetworkManager is enough). My own network doesn't show up in
NM-applet anymore while others (but not all that were available before...) do. I
can however reconnect by providing the essid and psk manually using "connect to
other network".

"iwlist wlan0 scan" also doesn't show the network anymore, also not after a
successful manual reconnect with nm-applet. It looks like scanning is broken
somehow after a disassociation from an AP. But not for all networks, maybe just
for the same channel / frequency? 

Kernel: kernel-2.6.24.4-64.fc8.x86_64

I restarted NetworkManager -> sudo /etc/init.d/NetworkManager restart -> My own
network is not there anymore... -> connect by using "connect to other network".

wlan0: switched to short barker preamble (BSSID=00:14:bf:a5:05:78)
b44: eth0: powering down PHY
wlan0: disassociate(reason=3)
wlan0: disassociate(reason=3)
ACPI: PCI interrupt for device 0000:0c:00.0 disabled
ADDRCONF(NETDEV_UP): eth0: link is not ready
ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
Registered led device: iwl-phy0:radio
Registered led device: iwl-phy0:assoc
Registered led device: iwl-phy0:RX
Registered led device: iwl-phy0:TX
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:14:bf:a5:05:78
wlan0: RX authentication from 00:14:bf:a5:05:78 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:14:bf:a5:05:78
wlan0: RX AssocResp from 00:14:bf:a5:05:78 (capab=0x411 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: no IPv6 routers present
[fkooman@dilithium ~]$ 

nm-tool dump

- Device: wlan0 ----------------------------------------------------------------
  Type:              802.11 Wireless
  Driver:            iwl4965
  Active:            yes
  HW Address:        00:1F:3B:07:91:91

  Capabilities:
    Supported:       yes
    Speed:           54 Mb/s

  Wireless Settings
    WEP Encryption:  yes
    WPA Encryption:  yes
    WPA2 Encryption: yes

  Wireless Access Points(* = Current AP)
    WLAN VDV:        Infra, 00:14:BF:48:80:6A, Freq 2462 MHz, Rate 54 Mb/s,
Strength 49 WPA WPA2
    WLAN MKOX:       Infra, 00:1D:7E:4B:3F:F4, Freq 2412 MHz, Rate 54 Mb/s,
Strength 37 WPA2
    Linnie:          Infra, 00:18:39:33:AF:24, Freq 2462 MHz, Rate 54 Mb/s,
Strength 38 WEP
    *pltln:          Infra, 00:14:BF:A5:05:78, Freq 2432 MHz, Rate 54 Mb/s,
Strength 100 WPA2
    Greatfield:      Infra, 00:17:3F:46:FA:4A, Freq 2462 MHz, Rate 54 Mb/s,
Strength 77 WEP
    lievejoost:      Infra, 00:06:25:F9:D4:FA, Freq 2462 MHz, Rate 11 Mb/s,
Strength 33 WEP
    springbokken:    Infra, 00:50:18:54:54:E8, Freq 2462 MHz, Rate 54 Mb/s,
Strength 28 WPA

  IP Settings:
    IP Address:      192.168.1.50
    Subnet Mask:     255.255.255.0
    Broadcast:       192.168.1.255
    Gateway:         192.168.1.1
    DNS:             192.168.1.1

Not sure what else I can report. When the network is not found it doesn't try to
connect, so no failed connection attempts in my case...
Comment 6 François Kooman 2008-04-08 08:32:50 EDT
Also interesting, when I'm reconnected to my own network (manually) all networks
are found again after a short time. After disassociation it doesn't scan
anymore? or not completely at least... ? 
Comment 7 John F 2008-04-08 09:56:32 EDT
the switch to turn off the wifi card also does the same thing to my card, 
except that it forces me to reboot to get internet back
Comment 8 Dan Williams 2008-04-10 12:34:32 EDT
Could be the hardware scanning bug that's been going around; does it seem like
that john?  Comment 1 seems to indicate the hw_scan bug.
Comment 9 James 2008-04-13 10:00:53 EDT
I see this as well. Extract from dmesg:

iwl4965: Wait for START_ALIVE timeout after 2000ms.
ACPI: PCI interrupt for device 0000:02:00.0 disabled
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 17
iwl4965: Wait for START_ALIVE timeout after 2000ms.
ACPI: PCI interrupt for device 0000:02:00.0 disabled

and then I have to reload the module.
Comment 10 Mike Hanby 2008-04-17 16:40:53 EDT
I have this problem too, it all started after an update sometime in March. I
have a Dell XPS m1330 laptop with the iwl4965

Here's /var/log/messages from a resume from suspend where the card failed to
reconnect to my WPA wifi network:

Mar 29 18:43:25 ratbook kernel: ALSA sound/pci/hda/patch_sigmatel.c:1241:
hda_codec: pin nid 22 pin config 40000100
Mar 29 18:43:25 ratbook kernel: ALSA sound/pci/hda/patch_sigmatel.c:1241:
hda_codec: pin nid 23 pin config 00000000
Mar 29 18:43:25 ratbook NetworkManager: <info> Waking up from sleep.
Mar 29 18:43:25 ratbook NetworkManager: <info> eth0: Device is fully-supported
using driver 'tg3'.
Mar 29 18:43:25 ratbook NetworkManager: <info> Now managing wired Ethernet
(802.3) device 'eth0'.
Mar 29 18:43:25 ratbook NetworkManager: <info> Bringing up device eth0
Mar 29 18:43:25 ratbook kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Mar 29 18:43:25 ratbook NetworkManager: <info> Deactivating device eth0.
Mar 29 18:43:25 ratbook acpid: client connected from 2635[0:0]
Mar 29 18:43:25 ratbook NetworkManager: <info> (eth0): exporting device as
/org/freedesktop/Hal/devices/net_00_15_c5_81_35_00
Mar 29 18:43:25 ratbook NetworkManager: <info> wlan0: Device is fully-supported
using driver 'iwl4965'.
Mar 29 18:43:25 ratbook NetworkManager: <info> wlan0: driver supports SSID scans
(scan_capa 0x01).
Mar 29 18:43:25 ratbook NetworkManager: <info> Now managing wireless (802.11)
device 'wlan0'.
Mar 29 18:43:25 ratbook NetworkManager: <info> Bringing up device wlan0
Mar 29 18:43:25 ratbook kernel: PCI: Enabling device 0000:0c:00.0 (0000 -> 0002)
Mar 29 18:43:25 ratbook kernel: ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17
(level, low) -> IRQ 17
Mar 29 18:43:25 ratbook kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Mar 29 18:43:25 ratbook NetworkManager: <info> Deactivating device wlan0.
Mar 29 18:43:25 ratbook NetworkManager: <WARN>
nm_device_802_11_wireless_disable_encryption(): error setting key for device
wlan0: No such file or directory
Mar 29 18:43:25 ratbook NetworkManager: <info> (wlan0): exporting device as
/org/freedesktop/Hal/devices/net_00_1d_e0_28_bd_cd
Mar 29 18:43:25 ratbook NetworkManager: <info> (eth0) supplicant interface is
now in state 2 (from 1).
Mar 29 18:43:25 ratbook NetworkManager: <info> (wlan0) supplicant interface is
now in state 2 (from 1).
Mar 29 18:43:25 ratbook kernel: uvcvideo: Failed to query (135) UVC control 1
(unit 0) : -110 (exp. 26).
Mar 29 18:43:25 ratbook kernel: usb 7-1: USB disconnect, address 2
Mar 29 18:43:26 ratbook kernel: usb 7-1: new full speed USB device using
uhci_hcd and address 3
Mar 29 18:43:26 ratbook kernel: usb 7-1: configuration #1 chosen from 1 choice
Mar 29 18:43:45 ratbook ntpd[6391]: ntpd 4.2.4p2@1.1495-o Mon Sep 24 14:40:07
UTC 2007 (1)
Comment 11 Mike Hanby 2008-04-25 20:51:57 EDT
I should add that, as the original bug report states, the wireless starts
working on my laptop if I execute:
$ sudo /sbin/modprobe --remove iwl4965
$ sudo /sbin/modprobe iwl4965

Another observation, every time I have to use the above commands, the Network
Manager prompts me for the WPA passphrase again. Normally, this passphrase is
remembered by NM and I don't have to enter it (upon bootup or when resume from
suspend works properly).

I have the following versions:
NetworkManager-0.7.0-0.6.7.svn3235.fc8
Kernel 2.6.24.4-64.fc8
Comment 12 John W. Linville 2008-04-29 16:37:56 EDT
I think this may relate to bug 438613 (or vice versa).
Comment 13 François Kooman 2008-05-02 10:47:12 EDT
It seems fixed now for me, although reconnecting after suspend is still a bit
slow (15 seconds after unlocking by typing password).

kernel-2.6.25-14.fc9.x86_64

* Fri Apr 25 2008 John W. Linville <linville@redhat.com> 2.6.25-10
- mac80211: Fix n-band association problem

^^^ This fixed it? I have a Intel 4965 btw.
Comment 14 John W. Linville 2008-05-06 10:21:25 EDT
Do you find that it works after a hibernate (aka suspend-to-disk) as well?  Or 
does it still fail then?
Comment 15 François Kooman 2008-05-06 17:00:26 EDT
That also works here... how about the bug reporter?
Comment 16 James 2008-05-10 08:12:28 EDT
Still present in kernel-2.6.24.7-92.fc8. Any plans to backport the fix?

ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 17
iwl4965: Microcode HW error detected.  Restarting.
iwl4965: Microcode HW error detected.  Restarting.
iwl4965: Wait for START_ALIVE timeout after 2000ms.
iwl4965: Microcode HW error detected.  Restarting.
ACPI: PCI interrupt for device 0000:02:00.0 disabled
Comment 17 John W. Linville 2008-05-12 11:22:34 EDT
F8 kernels currently have later wireless code than the F9 kernels have, so I'm 
not sure there is a fix to backport... :-(
Comment 18 John W. Linville 2008-05-29 16:42:13 EDT
Are current F9 kernels exhibiting this behavior?

   http://koji.fedoraproject.org/koji/buildinfo?buildID=50712
Comment 19 James 2008-05-30 20:03:59 EDT
Still no luck with kernel-2.6.25.4-14.fc8.
Comment 20 James 2008-06-05 15:54:02 EDT
Ditto kernel-2.6.25.4-16.fc8.
Comment 21 James 2008-06-13 05:44:37 EDT
And kernel-2.6.25.6-24.fc8, interrupt disabled. Might add in a pm hook to reload
the module...
Comment 22 John F 2008-06-15 00:19:30 EDT
this seems to work for me in fedora 9 (2.6.25-14.fc9.x86_64)
Comment 23 James 2008-06-16 14:28:19 EDT
Seems fixed in kernel-2.6.25.6-27.fc8...
Comment 24 Will Kemp 2008-06-21 01:56:36 EDT
It still doesn't work for me in kernel 2.6.25.6-55.fc9.x86_64

Thinkpad R61, Intel 4965. Fedora 9 x86_64. All packages up to date.
Comment 25 James 2008-06-25 06:49:02 EDT
I think my Comment #23 was a fluke. I see some major unhappiness with
kernel-2.6.25.8-35.fc8. Got this on resume --- although this was with
ieee80211_regdom="EU" for cfg80211 (which has other problems). I'll test again
later with the default regdom.

PCI: Enabling device 0000:02:00.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16
iwl4965: Microcode HW error detected.  Restarting.
iwl4965: Microcode HW error detected.  Restarting.
iwl4965: START_ALIVE timeout after 2000ms.
irq 16: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Not tainted 2.6.25.8-35.fc8 #1
 [<c045b7e0>] __report_bad_irq+0x2e/0x6f
 [<c045ba01>] note_interrupt+0x1e0/0x217
 [<c045aef3>] ? handle_IRQ_event+0x2a/0x5a
 [<c045c12f>] handle_fasteoi_irq+0x8b/0xac
 [<c045c0a4>] ? handle_fasteoi_irq+0x0/0xac
 [<c0407ea7>] do_IRQ+0x8c/0xb9
 [<c0406563>] common_interrupt+0x23/0x28
 [<c062a890>] ? _spin_unlock_irqrestore+0xa/0x14
 [<c043ab73>] pm_qos_requirement+0x26/0x2b
 [<c05a0fd8>] menu_select+0x55/0x79
 [<c05a058d>] ? cpuidle_idle_call+0x0/0x8b
 [<c05a05ce>] cpuidle_idle_call+0x41/0x8b
 [<c05a058d>] ? cpuidle_idle_call+0x0/0x8b
 [<c04046d6>] cpu_idle+0xa4/0xc4
 [<c061bc85>] rest_init+0x49/0x4b
 =======================
handlers:
[<c05791d4>] (usb_hcd_irq+0x0/0x51)
[<f8ae08e4>] (sdhci_irq+0x0/0x4dd [sdhci])
[<f8ae08e4>] (sdhci_irq+0x0/0x4dd [sdhci])
Disabling IRQ #16
Comment 26 John W. Linville 2008-06-25 08:42:57 EDT
That trace doesn't look to be related to iwl4965.  Also FWIW the kernel in
question doesn't support the "EU" regdom.  You might try "JP" for now.
Comment 27 James 2008-06-25 14:15:19 EDT
Re: comment #26: this was a deduction based on the observations that iwl4965 was
on IRQ 16 before the suspend/resume, and immediately afterwards was the only
module that had disappeared from IRQ 16 in /proc/interrupts. Could be an ACPI
bug. Either way, I've not seen it in kernel-2.6.25.9-37.fc8, in which the
connection simply doesn't come back.
Comment 28 James 2008-06-28 06:21:12 EDT
Still no luck with kernel-2.6.25.9-38.fc8, I see a "iwl4965: START_ALIVE timeout
after 2000ms." and then the interrupt is disabled. Normal service after reload.
Comment 29 Will Kemp 2008-06-28 15:12:35 EDT
I'm gradually coming to the conclusion that NetworkManager *does* work - if i'm
patient enough. It can take quite a while, after resuming from a suspend to RAM,
for it to come back to life again - and i've been giving up on it before that
point. Now i switch it on and just ignore it for several minutes and it seems it
will snap out of its slumber and connect ok.

The first time after a reboot it seems to wake up much faster - but gets slower
after that. I haven't timed it, that's just the way it seems.

I'm not 100% certain that this is what the problem has been, but i've resumed
several times over the last few days and it connects every time - eventually.

I'm running 2.6.25.6-55.fc9.x86_64 kernel.

I'm not sure if it worked this way before the update to that kernel version or
not - as i probably never gave it long enough to find out.
Comment 30 James 2008-07-04 14:04:14 EDT
I've now seen an Oops in iwl4965 following suspend/resume with
kernel-2.6.25.9-42.fc8. Again, I see the "irq 16: nobody cared" message followed
by the same trace (I stand by comment #27). I then tried modprobe -r to try and
reload it and got an oops:

iwl4965: Can't stop Rx DMA.
BUG: unable to handle kernel paging request at 768d6cac
IP: [<f8bc2fe1>] :iwl4965:iwl4965_pci_remove+0x27d/0x34f
*pde = 00000000 
Oops: 0000 [#1] SMP 
Modules linked in: cpufreq_stats i915 drm coretemp hwmon rfcomm l2cap bluetooth
autofs4 fuse nf_conntrack_ipv4 ipt_REJECT iptable_filter ip_tables
nf_conntrack_ftp nf_conntrack_ipv6 xt_state nf_conntrack xt_tcpudp
ip6t_ipv6header ip6t_REJECT ip6table_filter ip6_tables x_tables ipv6
cpufreq_ondemand acpi_cpufreq loop dm_multipath snd_hda_intel snd_seq_dummy arc4
snd_seq_oss snd_seq_midi_event snd_seq ecb crypto_blkcipher snd_seq_device
snd_pcm_oss snd_mixer_oss snd_pcm iwl4965(-) iwlcore firewire_ohci snd_timer
firewire_core video snd_page_alloc rfkill uvcvideo compat_ioctl32 snd_hwdep
sdhci crc_itu_t output snd mac80211 mmc_core i2c_i801 battery soundcore videodev
wmi ac r8169 button v4l1_compat pcspkr joydev i2c_core iTCO_wdt cfg80211
serio_raw iTCO_vendor_support sr_mod sg cdrom dm_snapshot dm_zero dm_mirror
dm_mod ata_generic ata_piix pata_acpi libata sd_mod scsi_mod ext3 jbd mbcache
uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode]

Pid: 15062, comm: modprobe Not tainted (2.6.25.9-42.fc8 #1)
EIP: 0060:[<f8bc2fe1>] EFLAGS: 00210247 CPU: 0
EIP is at iwl4965_pci_remove+0x27d/0x34f [iwl4965]
EAX: 00000000 EBX: 768d6cac ECX: 00200246 EDX: 00200246
ESI: f8bd0110 EDI: f68d0e60 EBP: f6f81ee4 ESP: f6f81ec4
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process modprobe (pid: 15062, ti=f6f81000 task=f6896000 task.ti=f6f81000)
Stack: f68d6cac f78ef800 f68d1448 00000000 00200246 f78ef800 f8bd0110 f8bd0110 
       f6f81ef0 c0501c45 f78ef854 f6f81f00 c056652b f78ef854 f78ec054 f6f81f14 
       c0566997 f8bd0110 00000000 c07260c0 f6f81f28 c0565f58 00000000 f8bd0110 
Call Trace:
 [<c0501c45>] ? pci_device_remove+0x19/0x39
 [<c056652b>] ? __device_release_driver+0x5b/0x78
 [<c0566997>] ? driver_detach+0xa3/0xe0
 [<c0565f58>] ? bus_remove_driver+0x63/0x7f
 [<c0566a1d>] ? driver_unregister+0x2a/0x2e
 [<c0501df2>] ? pci_unregister_driver+0x1e/0x4f
 [<f8bc2d5d>] ? iwl4965_exit+0xd/0x14 [iwl4965]
 [<c044563c>] ? sys_delete_module+0x172/0x1aa
 [<c0455ffb>] ? audit_syscall_entry+0x101/0x12b
 [<c0405b7e>] ? syscall_call+0x7/0xb
 =======================
Code: 00 e8 84 82 89 c7 8d 87 b4 60 00 00 e8 ee 77 86 c7 8d 87 4c 5e 00 00 c7 45
ec 00 00 00 00 89 45 e0 8b 45 ec 8b 9c c7 4c 5e 00 00 <8b> 33 eb 13 89 d8 e8 54
84 93 c7 8d 43 f0 89 f3 e8 70 a1 8b c7 
EIP: [<f8bc2fe1>] iwl4965_pci_remove+0x27d/0x34f [iwl4965] SS:ESP 0068:f6f81ec4
---[ end trace 4710fb3b54aa1c01 ]---
Comment 31 István Tóth 2008-07-19 02:37:42 EDT
I've had the same problems, with a HP 8510W notebook, but the latest updates
(Linux version 2.6.25.10-86.fc9.x86_64) seems to have fixed this particular
problem. The wireless connection comes back up both after a suspend/resume, as
well as a hibernate/restore.

I've still got IRQ 19: nobody cared, and swapper tainted  after resume, and
hibernate/resume makes X (nvidia binary) eat CPU, but the wifi does comes back.
Comment 32 John W. Linville 2008-07-28 13:44:30 EDT
Can anyone else confirm comment 31 with -86 or -97?
Comment 33 Will Kemp 2008-07-30 04:57:10 EDT
I can neither really confirm nor deny, but i'm running 2.6.25.11-97.fc9.x86_64
and NetworkManager has come back ok from suspend twice now. Its behaviour is a
bit inconsistent so far though.

Yesterday morning it just came back up and connected to the wireless network.
This morning, though, it asked for the network password - and then connected ok.

That's not a very representative sample, i know. But i'll post again here if
anything worth mentioning happens.
Comment 34 Will Kemp 2008-07-30 04:58:00 EDT
I should have mentioned it's a Thinkpad R61.
Comment 35 John W. Linville 2008-07-30 09:12:29 EDT
On my T61 I was able to suspend/resume (and hibertnate/resume) multiple times on
F9 and it always came back, albeit with occasionaly NM delays.

Anyone still having problems needs to speak-up quickly.
Comment 36 James 2008-07-30 09:27:43 EDT
Ditto, it seems to be working without any error messages for me with kernel
2.6.25.13-65.fc8 (modulo NM timeouts).
Comment 37 Will Kemp 2008-10-05 15:28:32 EDT
Well, i'm very sorry to have to report that this issue appears to have come back!

Yesterday, i updated to the 2.6.26.5-45.fc9.x86_64 and this morning, when i woke my laptop up from suspend, the wireless network didn't come back. I had to stop NetworkManager, unload and reload the modules, and restart NetworkManager, and then it worked ok.

I'll let yous know if it's any different tomorrow morning.
Comment 38 John F 2008-10-05 16:38:29 EDT
this is back for me as well.  I am experiencing it on the latest kernel and using x86-64 and i386

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