Bug 502097
Summary: | crash when nm_supplicant_interface_add_cb() fails | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Woodhouse <dwmw2> | ||||||
Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||||
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 11 | CC: | arxs, danw, dcbw | ||||||
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: | 2009-11-27 11:02:26 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: | |||||||||
Attachments: |
|
Description
David Woodhouse
2009-05-21 20:35:03 UTC
Thank you for taking the time to report this bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash, because there is not a symbolic stack trace. In order to get a symbolic stack trace, the appropriate debuginfo packages need to be installed. In order to accomplish this, you can run the command: debuginfo-install NetworkManager Please see http://fedoraproject.org/wiki/StackTraces for more information about stack traces. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Need to verify that error path in nm_supplicant_interface_add_cb(). Any chance you could attach your usbdevfs_reset script so I can use that to test and verify? I think it's related to that specifically. This is /usr/lib/pm-utils/sleep.d/99usb: #!/bin/sh . "${PM_FUNCTIONS}" case "$1" in hibernate|suspend) rmmod rt73usb /usr/sbin/hciconfig hci0 down ; rmmod btusb || : ;; thaw|resume) lsusb | egrep 0411:00f4\|0bf8:1003\|1131:1004\|0403:abcf | sed 's/Bus \(...\) Device \(...\):.*/\1 \2/' | while read A B ; do logger Resetting USB bus $A dev $B /root/usbreset /proc/bus/usb/$A/$B ; done /sbin/modprobe rt73usb /sbin/modprobe btusb ifconfig wlan0 ;; *) exit $NA ;; esac Created attachment 369263 [details]
usbreset.c
I assume the wifi connection is a system connection, right? I can't reproduce this with latest F11 updates (2.6.30.9-96.fc11.i686.PAE), current NM 0.7.x git, an rt73usb device, and about 10 hibernate/thaw cycles on my Dell D410. Can you try latest updates-testing NM update and see if you can still reproduce the issue? I updated, then set things up so I could SSH into the box over a Bluetooth RFCOMM socket without needing networking, and did some controlled tests -- and everything worked fine. I don't see this crash anywhere in the last month's logs, either. Will re-open if I ever see it again. Created attachment 374217 [details]
typescript
Heh, as soon as it's not being watched, it misbehaves. Not the original crash, but a failure to connect. The wireless device is working correctly after the resume, but NetworkManager doesn't use it.
When I turned it on at about 1pm, it failed to connect to the wireless. I was able to SSH in and poke at it, without much enlightenment. Restarting NetworkManager made it connect.
Nov 27 07:29:04 audi NetworkManager: <info> Marking connection 'Auto Baythorne Wavelan' invalid. Perhaps I upset it by turning the car on and then immediately leaving the vicinity of the access point :) Looking at the code, the INVALID_TAG ought to be cleared on all connections after a suspend/resume though. So why, when it comes back up at 13:00, does it not connect? Btw, shouldn't it clear the INVALID_TAG if the network in question disappears from the scan for a while, then turns up again? Or just after a timeout if it _is_ constantly visible in scan. Surely it's better to try again than to just remain disconnected? |