1. 24 Sep, 2009 10 commits
    • Roland McGrath's avatar
      binfmt_elf: fix PT_INTERP bss handling · 4e499625
      Roland McGrath authored
      commit 9f0ab4a3 upstream.
      
      In fs/binfmt_elf.c, load_elf_interp() calls padzero() for .bss even if
      the PT_LOAD has no PROT_WRITE and no .bss.  This generates EFAULT.
      
      Here is a small test case.  (Yes, there are other, useful PT_INTERP
      which have only .text and no .data/.bss.)
      
      	----- ptinterp.S
      	_start: .globl _start
      		 nop
      		 int3
      	-----
      	$ gcc -m32 -nostartfiles -nostdlib -o ptinterp ptinterp.S
      	$ gcc -m32 -Wl,--dynamic-linker=ptinterp -o hello hello.c
      	$ ./hello
      	Segmentation fault  # during execve() itself
      
      	After applying the patch:
      	$ ./hello
      	Trace trap  # user-mode execution after execve() finishes
      
      If the ELF headers are actually self-inconsistent, then dying is fine.
      But having no PROT_WRITE segment is perfectly normal and correct if
      there is no segment with p_memsz > p_filesz (i.e. bss).  John Reiser
      suggested checking for PROT_WRITE in the bss logic.  I think it makes
      most sense to simply apply the bss logic only when there is bss.
      
      This patch looks less trivial than it is due to some reindentation.
      It just moves the "if (last_bss > elf_bss) {" test up to include the
      partial-page bss logic as well as the more-pages bss logic.
      Reported-by: default avatarJohn Reiser <jreiser@bitwagon.com>
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4e499625
    • Bob Copeland's avatar
      ath5k: write PCU registers on initial reset · 3cfbbe0e
      Bob Copeland authored
      commit 3355443a upstream.
      
      "Ath5k: unify resets"
      introduced a regression into 2.6.28 where the PCU registers are never
      initialized, due to ath5k_reset() always passing true for change_channel.
      We subsequently program a lot of these registers but several may start
      in an unknown state.
      Reported-by: default avatarForrest Zhang <forrest@hifulltech.com>
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      3cfbbe0e
    • Bob Copeland's avatar
      cfg80211: fix looping soft lockup in find_ie() · 945797ee
      Bob Copeland authored
      commit fcc6cb0c upstream.
      
      The find_ie() function uses a size_t for the len parameter, and
      directly uses len as a loop variable.  If any received packets
      are malformed, it is possible for the decrease of len to overflow,
      and since the result is unsigned, the loop will not terminate.
      Change it to a signed int so the loop conditional works for
      negative values.
      
      This fixes the following soft lockup:
      
      [38573.102007] BUG: soft lockup - CPU#0 stuck for 61s! [phy0:2230]
      [38573.102007] Modules linked in: aes_i586 aes_generic fuse af_packet ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state iptable_filter ip_tables x_tables acpi_cpufreq binfmt_misc dm_mirror dm_region_hash dm_log dm_multipath dm_mod kvm_intel kvm uinput i915 arc4 ecb drm snd_hda_codec_idt ath5k snd_hda_intel hid_apple mac80211 usbhid appletouch snd_hda_codec snd_pcm ath cfg80211 snd_timer i2c_algo_bit ohci1394 video snd processor ieee1394 rfkill ehci_hcd sg sky2 backlight snd_page_alloc uhci_hcd joydev output ac thermal button battery sr_mod applesmc cdrom input_polldev evdev unix [last unloaded: scsi_wait_scan]
      [38573.102007] irq event stamp: 2547724535
      [38573.102007] hardirqs last  enabled at (2547724534): [<c1002ffc>] restore_all_notrace+0x0/0x18
      [38573.102007] hardirqs last disabled at (2547724535): [<c10038f4>] apic_timer_interrupt+0x28/0x34
      [38573.102007] softirqs last  enabled at (92950144): [<c103ab48>] __do_softirq+0x108/0x210
      [38573.102007] softirqs last disabled at (92950274): [<c1348e74>] _spin_lock_bh+0x14/0x80
      [38573.102007]
      [38573.102007] Pid: 2230, comm: phy0 Tainted: G        W  (2.6.31-rc7-wl #8) MacBook1,1
      [38573.102007] EIP: 0060:[<f8ea2d50>] EFLAGS: 00010292 CPU: 0
      [38573.102007] EIP is at cmp_ies+0x30/0x180 [cfg80211]
      [38573.102007] EAX: 00000082 EBX: 00000000 ECX: ffffffc1 EDX: d8efd014
      [38573.102007] ESI: ffffff7c EDI: 0000004d EBP: eee2dc50 ESP: eee2dc3c
      [38573.102007]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [38573.102007] CR0: 8005003b CR2: d8efd014 CR3: 01694000 CR4: 000026d0
      [38573.102007] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [38573.102007] DR6: ffff0ff0 DR7: 00000400
      [38573.102007] Call Trace:
      [38573.102007]  [<f8ea2f8d>] cmp_bss+0xed/0x100 [cfg80211]
      [38573.102007]  [<f8ea33e4>] cfg80211_bss_update+0x84/0x410 [cfg80211]
      [38573.102007]  [<f8ea3884>] cfg80211_inform_bss_frame+0x114/0x180 [cfg80211]
      [38573.102007]  [<f97255ff>] ieee80211_bss_info_update+0x4f/0x180 [mac80211]
      [38573.102007]  [<f972b118>] ieee80211_rx_bss_info+0x88/0xf0 [mac80211]
      [38573.102007]  [<f9739297>] ? ieee802_11_parse_elems+0x27/0x30 [mac80211]
      [38573.102007]  [<f972b224>] ieee80211_rx_mgmt_probe_resp+0xa4/0x1c0 [mac80211]
      [38573.102007]  [<f972bc59>] ieee80211_sta_rx_queued_mgmt+0x919/0xc50 [mac80211]
      [38573.102007]  [<c1009707>] ? sched_clock+0x27/0xa0
      [38573.102007]  [<c1009707>] ? sched_clock+0x27/0xa0
      [38573.102007]  [<c105ffd0>] ? mark_held_locks+0x60/0x80
      [38573.102007]  [<c1348be5>] ? _spin_unlock_irqrestore+0x55/0x70
      [38573.102007]  [<c134baa5>] ? sub_preempt_count+0x85/0xc0
      [38573.102007]  [<c1348bce>] ? _spin_unlock_irqrestore+0x3e/0x70
      [38573.102007]  [<c12c1c0f>] ? skb_dequeue+0x4f/0x70
      [38573.102007]  [<f972c021>] ieee80211_sta_work+0x91/0xb80 [mac80211]
      [38573.102007]  [<c1009707>] ? sched_clock+0x27/0xa0
      [38573.102007]  [<c134baa5>] ? sub_preempt_count+0x85/0xc0
      [38573.102007]  [<c10479af>] worker_thread+0x18f/0x320
      [38573.102007]  [<c104794e>] ? worker_thread+0x12e/0x320
      [38573.102007]  [<c1348be5>] ? _spin_unlock_irqrestore+0x55/0x70
      [38573.102007]  [<f972bf90>] ? ieee80211_sta_work+0x0/0xb80 [mac80211]
      [38573.102007]  [<c104cbb0>] ? autoremove_wake_function+0x0/0x50
      [38573.102007]  [<c1047820>] ? worker_thread+0x0/0x320
      [38573.102007]  [<c104c854>] kthread+0x84/0x90
      [38573.102007]  [<c104c7d0>] ? kthread+0x0/0x90
      [38573.102007]  [<c1003ab7>] kernel_thread_helper+0x7/0x10
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      945797ee
    • Bart Van Assche's avatar
      SCSI: libsrp: fix memory leak in srp_ring_free() · 328b1e3d
      Bart Van Assche authored
      commit afffd3da upstream.
      
      This patch fixes a memory leak in the libsrp function srp_ring_free().
      It is not documented whether or not this function should free the ring
      pointer itself. But the source code of the callers of this function
      (srp_target_alloc() and srp_target_free()) makes it clear that
      srp_ring_free() should deallocate the ring pointer itself. Furthermore,
      the patch below makes srp_ring_free() deallocate all memory allocated by
      srp_ring_alloc().
      
      This patch affects the ibmvstgt driver, which is the only in-tree driver
      that calls the srp_ring_free() function (indirectly).
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@gmail.com>
      Acked-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      328b1e3d
    • James Bottomley's avatar
      SCSI: fix oops during scsi scanning · 0ce24e27
      James Bottomley authored
      commit ea038f63 upstream.
      
      Chris Webb reported:
        p0# uname -a
        Linux f7ea8425-d45b-490f-a738-d181d0df6963.host.elastichosts.com 2.6.30.4-elastic-lon-p #2 SMP PREEMPT Thu Aug 20 14:30:50 BST 2009 x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
        p0# zgrep SCAN_ASYNC /proc/config.gz
        # CONFIG_SCSI_SCAN_ASYNC is not set
      
        p0# cat /var/log/kern/2009-08-20
        [...]
        15:27:10.485 kernel: scsi9 : iSCSI Initiator over TCP/IP
        15:27:11.493 kernel: scsi 9:0:0:0: RAID              IET      Controller       0001 PQ: 0 ANSI: 5
        15:27:11.493 kernel: scsi 9:0:0:0: Attached scsi generic sg6 type 12
        15:27:11.495 kernel: scsi 9:0:0:1: Direct-Access     IET      VIRTUAL-DISK     0001 PQ: 0 ANSI: 5
        15:27:11.495 kernel: sd 9:0:0:1: Attached scsi generic sg7 type 0
        15:27:11.495 kernel: sd 9:0:0:1: [sdg] 4194304 512-byte hardware sectors: (2.14 GB/2.00 GiB)
        15:27:11.495 kernel: sd 9:0:0:1: [sdg] Write Protect is off
        15:27:11.495 kernel: sd 9:0:0:1: [sdg] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
        15:27:13.012 kernel: sdg:<6>scsi 9:0:0:1: [sdg] Unhandled error code
        15:27:13.012 kernel: scsi 9:0:0:1: [sdg] Result: hostbyte=0x07 driverbyte=0x00
        15:27:13.012 kernel: end_request: I/O error, dev sdg, sector 0
        15:27:13.012 kernel: Buffer I/O error on device sdg, logical block 0
        15:27:13.012 kernel: ldm_validate_partition_table(): Disk read failed.
        15:27:13.012 kernel: unable to read partition table
        15:27:13.014 kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
        15:27:13.014 kernel: IP: [<ffffffff803f0d77>] disk_part_iter_next+0x74/0xfd
        15:27:13.014 kernel: PGD 82ad0b067 PUD 82cd7e067 PMD 0
        15:27:13.014 kernel: Oops: 0000 [#1] PREEMPT SMP
        15:27:13.014 kernel: last sysfs file: /sys/devices/platform/host9/session4/iscsi_session/session4/ifacename
        15:27:13.014 kernel: CPU 5
        15:27:13.014 kernel: Modules linked in:
        15:27:13.014 kernel: Pid: 13999, comm: async/0 Not tainted 2.6.30.4-elastic-lon-p #2 X7DBN
        15:27:13.014 kernel: RIP: 0010:[<ffffffff803f0d77>]  [<ffffffff803f0d77>] disk_part_iter_next+0x74/0xfd
        15:27:13.014 kernel: RSP: 0018:ffff88066afa3dd0  EFLAGS: 00010246
        15:27:13.014 kernel: RAX: ffff88082b58a000 RBX: ffff88066afa3e00 RCX: 0000000000000000
        15:27:13.014 kernel: RDX: 0000000000000000 RSI: ffff88082b58a000 RDI: 0000000000000000
        15:27:13.014 kernel: RBP: ffff88066afa3df0 R08: ffff88066afa2000 R09: ffff8806a204f000
        15:27:13.014 kernel: R10: 000000fb12c7d274 R11: ffff8806c2bf0628 R12: ffff88066afa3e00
        15:27:13.014 kernel: R13: ffff88082c829a00 R14: 0000000000000000 R15: ffff8806bc50c920
        15:27:13.014 kernel: FS:  0000000000000000(0000) GS:ffff88002818a000(0000) knlGS:0000000000000000
        15:27:13.014 kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
        15:27:13.014 kernel: CR2: 0000000000000010 CR3: 000000082ade3000 CR4: 00000000000426e0
        15:27:13.014 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        15:27:13.014 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        15:27:13.014 kernel: Process async/0 (pid: 13999, threadinfo ffff88066afa2000, task ffff8806c2bf05e0)
        15:27:13.014 kernel: Stack:
        15:27:13.014 kernel: 0000000000000000 ffff88066afa3e00 ffff88066afa3e00 ffff88082c829a00
        15:27:13.014 kernel: ffff88066afa3e40 ffffffff80306feb ffff88082b58a000 0000000000000000
        15:27:13.014 kernel: 0000000000000001 ffff8806bc50c920 ffff88066afa3e40 ffff88082b58a000
        15:27:13.014 kernel: Call Trace:
        15:27:13.014 kernel: [<ffffffff80306feb>] register_disk+0x122/0x13a
        15:27:13.014 kernel: [<ffffffff803f0b0f>] add_disk+0xaa/0x106
        15:27:13.014 kernel: [<ffffffff80493609>] sd_probe_async+0x198/0x25b
        15:27:13.014 kernel: [<ffffffff80270482>] async_thread+0x10c/0x20d
        15:27:13.014 kernel: [<ffffffff802545ff>] ? default_wake_function+0x0/0xf
        15:27:13.014 kernel: [<ffffffff80270376>] ? async_thread+0x0/0x20d
        15:27:13.014 kernel: [<ffffffff8026ad89>] kthread+0x55/0x80
        15:27:13.014 kernel: [<ffffffff8022be6a>] child_rip+0xa/0x20
        15:27:13.014 kernel: [<ffffffff8026ad34>] ? kthread+0x0/0x80
        15:27:13.014 kernel: [<ffffffff8022be60>] ? child_rip+0x0/0x20
        15:27:13.014 kernel: Code: c8 ff 80 e1 0c b9 00 00 00 00 0f 44 c1 41 83 cd ff 48 8d 7a 20 48 be ff ff ff ff 08 00 00 00 48 b9 00 00 00 00 08 00 00 00 eb 50 <8b> 42 10 41 bd 01 00 00 00 eb db 4c 63 c2 4e 8d 04 c7 4d 8b 20
        15:27:13.015 kernel: RIP  [<ffffffff803f0d77>] disk_part_iter_next+0x74/0xfd
        15:27:13.015 kernel: RSP <ffff88066afa3dd0>
        15:27:13.015 kernel: CR2: 0000000000000010
        15:27:13.015 kernel: ---[ end trace 6104b56ef5590e25 ]---
      
      The problem is caused because the async scanning split in sd.c doesn't hold
      any reference to the device when it kicks off the async piece.  What's
      happening is that an iSCSI disconnect is destorying the device again *before*
      the async sd scanning thread even starts.  Fix this by taking a reference
      before starting the thread and dropping it again when the thread completes.
      Reported-by: default avatarChris Webb <chris@arachsys.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0ce24e27
    • Kashyap, Desai's avatar
      mpt2sas: Raid 10 Volume is showing as Raid 1E in dmesg · f045fdff
      Kashyap, Desai authored
      commit ed79f128 upstream.
      
      This patch modifies the slave_configure callback so the messages that get sent
      to system log for RAID1E volumes contain the string "RAID10" instead of
      "RAID1E". These messages contain information regarding what kind of scsi device
      is being added. Certain OEMS can enable displaying the RAID10 string instead of
      RAID1E via manufacturing page 10.   The driver will read this config page at
      driver load time, then determine from the GenericFlags0 bits whether display
      the RAID10 or RAID1E string, also even drive count is taken into consideration.
      Signed-off-by: default avatarKashyap Desai <kashyap.desai@lsi.com>
      Reviewed-by: default avatarEric Moore <Eric.moore@lsi.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      f045fdff
    • Kashyap, Desai's avatar
      mpt2sas: setting SDEV into RUNNING state from Interrupt context · ab58d16b
      Kashyap, Desai authored
      commit 34a03bef upstream.
      
      Changing SDEV Running state from interrupt context. Previously It was
      handle in work queue thread. With this change It will not wait for work
      queue thread to execute scsih_ublock_io_device to put SDEV into Running
      state. This will reduce delay for Device becoming RUNNING.
      
      Modified this patch considering James comment "Not to change SDEV state
      using  scsi_device_set_state API, instead use scsi_internal_device_unblock
      scsi_internal_device_block API"
      Signed-off-by: default avatarKashyap Desai <kashyap.desai@lsi.com>
      Reviewed-by: default avatarEric Moore <Eric.moore@lsi.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      ab58d16b
    • Kashyap, Desai's avatar
      mpt2sas: Prevent sending command to FW while Host Reset · fa278da6
      Kashyap, Desai authored
      commit 155dd4c7 upstream.
      
      This patch renames the flag for indicating host reset from
      ioc_reset_in_progress to shost_recovery. It also removes the spin locks
      surrounding the setting of this flag, which are unnecessary.   Sanity checks on
      the shost_recovery flag were added thru out the code so as to prevent sending
      firmware commands during host reset.  Also, the setting of the shost state to
      SHOST_RECOVERY was removed to prevent deadlocks, this is actually better
      handled by the shost_recovery flag.
      Signed-off-by: default avatarKashyap Desai <kashyap.desai@lsi.com>
      Reviewed-by: default avatarEric Moore <Eric.moore@lsi.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      fa278da6
    • Kashyap, Desai's avatar
      mpt2sas : Rescan topology from Interrupt context instead of work thread · 38032be1
      Kashyap, Desai authored
      commit cd4e12e8 upstream.
      
      Following host reset its possible that the controller firmware could
      assign new handles for devices, as well as adding or deleting devices. There is
      code in the driver that will rescan the topology folowing host reset; updating
      device handles, and remove devices that are no longer responding. This patch
      will improve the responsivness by moving this rescaning from the delayed hotplug
      worker thread to immediately following the host reset.
      Signed-off-by: default avatarKashyap Desai <kashyap.desai@lsi.com>
      Reviewed-by: default avatarEric Moore <Eric.moore@lsi.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      38032be1
    • Michal Schmidt's avatar
      sg: fix oops in the error path in sg_build_indirect() · 57f4fc5e
      Michal Schmidt authored
      commit e71044ee upstream.
      
      When the allocation fails in sg_build_indirect(), an oops happens in
      the error path. It's caused by an obvious typo.
      Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Reported-by: default avatarBob Tracy <rct@gherkin.frus.com>
      Acked-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      57f4fc5e
  2. 09 Sep, 2009 3 commits
    • Linus Torvalds's avatar
      Linux 2.6.31 · 74fca6a4
      Linus Torvalds authored
      74fca6a4
    • Ed Cashin's avatar
      aoe: allocate unused request_queue for sysfs · 7135a71b
      Ed Cashin authored
      Andy Whitcroft reported an oops in aoe triggered by use of an
      incorrectly initialised request_queue object:
      
        [ 2645.959090] kobject '<NULL>' (ffff880059ca22c0): tried to add
      		an uninitialized object, something is seriously wrong.
        [ 2645.959104] Pid: 6, comm: events/0 Not tainted 2.6.31-5-generic #24-Ubuntu
        [ 2645.959107] Call Trace:
        [ 2645.959139] [<ffffffff8126ca2f>] kobject_add+0x5f/0x70
        [ 2645.959151] [<ffffffff8125b4ab>] blk_register_queue+0x8b/0xf0
        [ 2645.959155] [<ffffffff8126043f>] add_disk+0x8f/0x160
        [ 2645.959161] [<ffffffffa01673c4>] aoeblk_gdalloc+0x164/0x1c0 [aoe]
      
      The request queue of an aoe device is not used but can be allocated in
      code that does not sleep.
      
      Bruno bisected this regression down to
      
        cd43e26f
      
        block: Expose stacked device queues in sysfs
      
      "This seems to generate /sys/block/$device/queue and its contents for
       everyone who is using queues, not just for those queues that have a
       non-NULL queue->request_fn."
      
      Addresses http://bugs.launchpad.net/bugs/410198
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13942
      
      Note that embedding a queue inside another object has always been
      an illegal construct, since the queues are reference counted and
      must persist until the last reference is dropped. So aoe was
      always buggy in this respect (Jens).
      Signed-off-by: default avatarEd Cashin <ecashin@coraid.com>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Bruno Premont <bonbons@linux-vserver.org>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      7135a71b
    • Linus Torvalds's avatar
      i915: disable interrupts before tearing down GEM state · e6890f6f
      Linus Torvalds authored
      Reinette Chatre reports a frozen system (with blinking keyboard LEDs)
      when switching from graphics mode to the text console, or when
      suspending (which does the same thing). With netconsole, the oops
      turned out to be
      
      	BUG: unable to handle kernel NULL pointer dereference at 0000000000000084
      	IP: [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
      
      and it's due to the i915_gem.c code doing drm_irq_uninstall() after
      having done i915_gem_idle(). And the i915_gem_idle() path will do
      
        i915_gem_idle() ->
          i915_gem_cleanup_ringbuffer() ->
            i915_gem_cleanup_hws() ->
              dev_priv->hw_status_page = NULL;
      
      but if an i915 interrupt comes in after this stage, it may want to
      access that hw_status_page, and gets the above NULL pointer dereference.
      
      And since the NULL pointer dereference happens from within an interrupt,
      and with the screen still in graphics mode, the common end result is
      simply a silently hung machine.
      
      Fix it by simply uninstalling the irq handler before idling rather than
      after. Fixes
      
          http://bugzilla.kernel.org/show_bug.cgi?id=13819Reported-and-tested-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e6890f6f
  3. 08 Sep, 2009 1 commit
  4. 07 Sep, 2009 7 commits
  5. 06 Sep, 2009 1 commit
    • David S. Miller's avatar
      gianfar: Fix build. · d9d8e041
      David S. Miller authored
      Reported by Michael Guntsche <mike@it-loops.com>
      
      --------------------
      Commit
      38bddf04 gianfar: gfar_remove needs to call unregister_netdev()
      
      breaks the build of the gianfar driver because "dev" is undefined in
      this function. To quickly test rc9 I changed this to priv->ndev but I do
      not know if this is the correct one.
      --------------------
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9d8e041
  6. 05 Sep, 2009 18 commits