Bug 978561 - [abrt] BUG: unable to handle kernel NULL pointer dereference at (null) [NEEDINFO]
[abrt] BUG: unable to handle kernel NULL pointer dereference at (null)
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
abrt_hash:49c5b9518a8f9b39ccd9669e44e...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-26 15:43 EDT by Bastiaan Jacques
Modified: 2014-03-10 10:39 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-10 10:39:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
michele: needinfo?


Attachments (Terms of Use)
File: dmesg (174.69 KB, text/plain)
2013-06-26 15:43 EDT, Bastiaan Jacques
no flags Details

  None (edit)
Description Bastiaan Jacques 2013-06-26 15:43:16 EDT
Description of problem:
I was away from the computer for about half an hour.

Additional info:
reporter:       libreport-2.1.5
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff81458d77>] hub_quiesce+0x57/0xc0
PGD 0 
Oops: 0000 [#1] SMP 
Modules linked in: usblp coretemp fuse nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_nat nf_nat_ipv6 ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm ebtable_filter ebtables ip6table_filter ip6_tables bnep iTCO_wdt iTCO_vendor_support hp_wmi sparse_keymap snd_hda_codec_hdmi snd_hda_codec_idt acpi_cpufreq mperf kvm_intel snd_hda_intel snd_hda_codec kvm snd_hwdep snd_seq crc32c_intel snd_seq_device microcode arc4 snd_pcm rt2800pci rt2800lib rt2x00pci rt2x00mmio rt2x00lib eeprom_93cx6 snd_page_alloc serio_raw mac80211 btusb bluetooth uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core snd_timer videodev snd r8169 media cfg80211 intel_ips lpc_ich rfkill mfd_core mii crc_ccitt mei soundcore wmi hp_accel lis3lv02d input_polldev uinput binfmt_misc i915 i2c_algo_bit drm_kms_helper drm i2c_core video [last unloaded: coretemp]
CPU 2 
Pid: 34, comm: khubd Not tainted 3.9.6-301.fc19.x86_64 #1 Hewlett-Packard HP ProBook 4520s/1413
RIP: 0010:[<ffffffff81458d77>]  [<ffffffff81458d77>] hub_quiesce+0x57/0xc0
RSP: 0018:ffff880131aff8d0  EFLAGS: 00010246
RAX: ffff88013019e4a0 RBX: 0000000000000000 RCX: ffff880131afffd8
RDX: 0000000000000000 RSI: 000000007fffffff RDI: 0000000000000000
RBP: ffff880131aff8e8 R08: 00000000ffffffb9 R09: 00000000000017fb
R10: 0000000000000000 R11: ffff880131aff53e R12: ffff88002c58f000
R13: ffff88010d1f7000 R14: ffff88002c58d800 R15: ffff88002c58d830
FS:  0000000000000000(0000) GS:ffff880137c80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000001c0c000 CR4: 00000000000007e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process khubd (pid: 34, threadinfo ffff880131afe000, task ffff880131992ee0)
Stack:
 ffff88002c58f058 ffff88002c58f000 ffff88010d1f7088 ffff880131aff920
 ffffffff81459084 ffff88002c58f000 ffff88002c58d800 ffff88010d1f7000
 0000000000000000 0000000000000064 ffff880131aff9c0 ffffffff8145bfea
Call Trace:
 [<ffffffff81459084>] hub_disconnect+0x84/0x140
 [<ffffffff8145bfea>] hub_probe+0x36a/0xea0
 [<ffffffff813f1a28>] ? __pm_runtime_set_status+0x128/0x1f0
 [<ffffffff81465384>] usb_probe_interface+0x1c4/0x2f0
 [<ffffffff813e5a57>] driver_probe_device+0x87/0x390
 [<ffffffff813e5d60>] ? driver_probe_device+0x390/0x390
 [<ffffffff813e5d9b>] __device_attach+0x3b/0x40
 [<ffffffff813e3b43>] bus_for_each_drv+0x63/0xa0
 [<ffffffff813e5958>] device_attach+0x88/0xa0
 [<ffffffff813e4cf8>] bus_probe_device+0x98/0xc0
 [<ffffffff813e2f2c>] device_add+0x61c/0x720
 [<ffffffff813ef66c>] ? device_set_wakeup_capable+0x4c/0x90
 [<ffffffff8146343b>] usb_set_configuration+0x4eb/0x820
 [<ffffffff8146d7ae>] generic_probe+0x2e/0xa0
 [<ffffffff81465172>] usb_probe_device+0x32/0x80
 [<ffffffff813e5a57>] driver_probe_device+0x87/0x390
 [<ffffffff813e5d60>] ? driver_probe_device+0x390/0x390
 [<ffffffff813e5d9b>] __device_attach+0x3b/0x40
 [<ffffffff813e3b43>] bus_for_each_drv+0x63/0xa0
 [<ffffffff813e5958>] device_attach+0x88/0xa0
 [<ffffffff813e4cf8>] bus_probe_device+0x98/0xc0
 [<ffffffff813e2f2c>] device_add+0x61c/0x720
 [<ffffffff81459360>] usb_new_device+0x220/0x3b0
 [<ffffffff8145b118>] hub_thread+0xeb8/0x1710
 [<ffffffff81080fb0>] ? wake_up_bit+0x30/0x30
 [<ffffffff8145a260>] ? hub_port_debounce+0x130/0x130
 [<ffffffff81080200>] kthread+0xc0/0xd0
 [<ffffffff81080140>] ? insert_kthread_work+0x40/0x40
 [<ffffffff8164e9ec>] ret_from_fork+0x7c/0xb0
 [<ffffffff81080140>] ? insert_kthread_work+0x40/0x40
Code: 00 00 02 83 fb 02 74 3a 41 8b 85 78 04 00 00 85 c0 7e 2f 31 db 0f 1f 80 00 00 00 00 49 8b 84 24 08 02 00 00 48 63 d3 48 8b 3c d0 <48> 83 3f 00 74 05 e8 ce fd ff ff 83 c3 01 41 39 9d 78 04 00 00 
RIP  [<ffffffff81458d77>] hub_quiesce+0x57/0xc0
 RSP <ffff880131aff8d0>

Potential duplicate: bug 926907
Comment 1 Bastiaan Jacques 2013-06-26 15:43:24 EDT
Created attachment 765765 [details]
File: dmesg
Comment 2 Josh Boyer 2013-09-16 09:22:14 EDT
Are you still seeing this with the 3.10.y kernel updates?
Comment 3 Josh Boyer 2013-09-18 16:22:26 EDT
*********** 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.
Comment 4 David Gibson 2013-09-23 01:14:02 EDT
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
Comment 5 Michele Baldessari 2013-11-02 06:04:30 EDT
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@podlesie.net>
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@podlesie.net>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Is anyone able to try their kernel plus the above patch and confirm or dispel this theory?

regards,
Michele
Comment 6 David Gibson 2013-11-10 21:40:51 EST
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.
Comment 7 Michele Baldessari 2013-11-26 16:04:45 EST
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
Comment 8 Justin M. Forbes 2014-03-10 10:39:12 EDT
*********** 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.

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