Bug 978561
| Summary: | [abrt] BUG: unable to handle kernel NULL pointer dereference at (null) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bastiaan Jacques <bastiaan> | ||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 19 | CC: | craigstep888, dgibson, drindt, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, michele | ||||
| Target Milestone: | --- | Flags: | michele:
needinfo?
|
||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | abrt_hash:49c5b9518a8f9b39ccd9669e44ee4da5bf90c75b | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-03-10 14:39:12 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
Bastiaan Jacques
2013-06-26 19:43:16 UTC
Created attachment 765765 [details]
File: dmesg
Are you still seeing this with the 3.10.y kernel updates? *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those. Description of problem: Occurred after hotplugging a USB mouse and keyboard sitting on a USB hub via a USB switch (like a KVM switch, but USB only). Version-Release number of selected component: kernel Additional info: reporter: libreport-2.1.7 cmdline: BOOT_IMAGE=/vmlinuz-3.10.11-200.fc19.x86_64 root=UUID=0f7e8c3d-421d-4894-8d77-f305ff382039 ro rootflags=subvol=root rd.md=0 rd.lvm=0 rd.dm=0 vconsole.keymap=us rd.luks.uuid=luks-62732f7f-f9a1-4cf3-8dbf-78ab04f6ab57 rd.luks.uuid=luks-d45f0022-3896-481e-8f84-9c0bf104332c rhgb rdblacklist=mei rdblacklist=mei_me kernel: 3.10.11-200.fc19.x86_64 runlevel: N 5 type: Kerneloops Truncated backtrace: #1 hub_quiesce #2 hub_disconnect #3 hub_probe #4 ? __pm_runtime_set_status #5 usb_probe_interface #6 driver_probe_device #7 ? driver_probe_device #8 __device_attach #9 bus_for_each_drv #10 device_attach Hi all,
can you reproduce this at will? The following patch (only present in the 3.12 series for now) could be relevant:
commit d0308d4b6b02597f39fc31a9bddf7bb3faad5622
Author: Krzysztof Mazur <krzysiek>
Date: Thu Aug 22 14:49:38 2013 +0200
usb: fix cleanup after failure in hub_configure()
If the hub_configure() fails after setting the hdev->maxchild
the hub->ports might be NULL or point to uninitialized kzallocated
memory causing NULL pointer dereference in hub_quiesce() during cleanup.
Now after such error the hdev->maxchild is set to 0 to avoid cleanup
of uninitialized ports.
Signed-off-by: Krzysztof Mazur <krzysiek>
Acked-by: Alan Stern <stern.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh>
Is anyone able to try their kernel plus the above patch and confirm or dispel this theory?
regards,
Michele
Unfortunately, I can't reproduce at will. I have a mildly complex USB setup:
Laptop dock -> USB "KVM" switch
(box with two USB "B" sockets and one "A" socket, with a physical switch to determine which host is connected to the downstream devices)
-> USB hub / memory card reader
-> USB mouse
-> USB->PS/2 convertor
-> PS/2 keyboard
When I use the switch to move the keyboard and mouse from one machine to another, I sometimes have trouble with the devices not being recognized. For the laptop side, I usually find undocking / redocking the laptop is the most effective way of fixing the situation.
On one occasion, rather than just a transient, unexplained fault however, I received the oops logged for this bug.
If anyone that can reproduce this issue here is willing to try 3.12.1-2: http://alt.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/x86_64/ that'd be great. thanks, Michele *********** MASS BUG UPDATE ************** This bug has been in a needinfo state for more than 1 month and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 19, please feel free to reopen the bug and provide the additional information requested. |