aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2008-10-13avr32: Add support for EVKLCD10X addon boardsHans-Christian Egtvedt
This patch lets the user enable support for EVKLCD100 and EVKLCD101 (refered to by EVKLCD10X). By enabling EVKLCD10X support the LCD controller and AC97 controller platform devices are added. The user can also choose between the EVKLCD100 (QVGA display) and the EVKLCD101 (VGA display), this is added to automagically select the correct panel timing and resolution parameters. Enabling support for EVKLCD10X addon board will cripple the MCI platform device a bit since they share two GPIO lines (detect and write-protect). These two lines are disabled when EVKLCD10X is enabled. The default configurations are based upon ATNGW100, but with added AC97C and LCDC driver. Virtual terminal is also enabled by default for EVKLCD10X boards. Verified on hardware with a NGW100 + EVKLCD100/101. Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-13avr32: Kconfig: Remove pointless if around atstk1000 includeHaavard Skinnemoen
The contents of the ATSTK1000 Kconfig file itself is completely conditional, so including it conditionally makes no sense and only adds clutter. Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-12avr32: Fix build failures in board codeHaavard Skinnemoen
Fix a few instances of board code breakage introduced by the atmel-mci platform interface changes. Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-12avr32: Allow selecting multiple pins at onceJulien May
at32_select_periph() now takes an u32 bitmask rather than a single pin. This allows to set multiple pins at once. Signed-off-by: Alex Raimondi <mailinglist@miromico.ch> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-12Merge branch 'master' of ↵Haavard Skinnemoen
git://git.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/atmel-mci-2.6.28
2008-10-08avr32: Minor pm_power_off cleanupHaavard Skinnemoen
Include <linux/pm.h> to see the declaration of pm_power_off, and remove unneeded NULL initializer. Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-08avr32: Implement {read,write}[bwl]_beHaavard Skinnemoen
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-05atmel-mci: Add missing flush_dcache_page() in PIO transfer codeHaavard Skinnemoen
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-05atmel-mci: Don't overwrite error bits when NOTBUSY is setHaavard Skinnemoen
After a data error, we wait for the NOTBUSY bit to be set so that we can be sure the data transfer is completely finished. However, when NOTBUSY is set, the interrupt handler copies the contents of SR into data_status, overwriting any error bits we may have detected earlier. To avoid this, initialize data_status to 0 before starting a request, and don't overwrite it unless it still contains 0. Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-05atmel-mci: Add experimental DMA supportHaavard Skinnemoen
This adds support for DMA transfers through the generic DMA engine framework with the DMA slave extensions. The driver has been tested using mmc-block and ext3fs on several SD, SDHC and MMC+ cards. Reads and writes work fine, with read transfer rates up to 7.5 MiB/s on fast cards with debugging disabled. Unfortunately, the driver has been known to lock up from time to time with DMA enabled, so DMA support is currently optional and marked EXPERIMENTAL. However, I didn't see any problems while testing 13 different cards (MMC, SD and SDHC of different brands and sizes), so I suspect the "Initialize BLKR before sending data transfer command" fix that was posted earlier fixed this as well. Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-05atmel-mci: support multiple mmc slotsHaavard Skinnemoen
The Atmel MCI controller can drive multiple cards through separate sets of pins, but only one at a time. This patch adds support for multiplexing access to the controller so that multiple card slots can be used as if they were hooked up to separate mmc controllers. The atmel-mci driver registers each slot as a separate mmc_host. Both access the same common controller state, but they also have some state on their own for card detection/write protect handling, and separate shadows of the MR and SDCR registers. When one of the slots receives a request from the mmc core, the common controller state is checked. If it's idle, the request is submitted immediately. If not, the request is added to a queue. When a request is done, the queue is checked and if there is a queued request, it is submitted before the completion callback is called. This patch also includes a few cleanups and fixes, including a locking overhaul. I had to change the locking extensively in any case, so I might as well try to get it right. The driver no longer takes any irq-safe locks, which may or may not improve the overall system performance. This patch also adds a bit of documentation of the internal data structures. Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-05atmel-mci: Platform code for supporting multiple mmc slotsHaavard Skinnemoen
Add the necessary platform infrastructure to support multiple mmc/sdcard slots all at once through a single controller. Currently, the driver will use the first valid slot it finds and stick with that, but later patches will add support for switching between several slots on the fly. Extend the platform data structure with per-slot information: MMC/SDcard bus width and card detect/write protect pins. This will affect the pin muxing as well as the capabilities announced to the mmc core. Note that board code is now required to supply a mci_platform_data struct to at32_add_device_mci(). Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-05atmel-mci: Don't stop the clock between transfersHaavard Skinnemoen
Some cards might get upset if we turn off the clock for extended periods of time. So keep the clock running until the mmc core tells us to turn it off. Also, don't reset the controller between each transfer. That was an attempt to work around earlier bugs, and it never really worked very well. Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-05atmel-mci: Implement tasklet as a state machineHaavard Skinnemoen
With the current system of completed/pending events, things may get handled in different order depending on which event triggers first. For example, if the data transfer is complete before the command, the stop command must be sent after the command is complete, not the data. This creates a bit of complexity around the stop command. By having the tasklet go through a sequence of clearly defined states, things always happen in a certain order even if the events come at different times, so the stop command can simply be sent when we exit the "sending data" state because we will never enter that state before the command has been sent successfully. Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-05atmel-mci: Initialize BLKR before sending data transfer commandHaavard Skinnemoen
The atmel-mci driver sometimes fails data transfers like this: mmcblk0: error -5 transferring data end_request: I/O error, dev mmcblk0, sector 2749769 end_request: I/O error, dev mmcblk0, sector 2749777 It turns out that this might be caused by the BLKR register (which contains the block size and the number of blocks being transfered) being initialized too late. This patch moves the initialization of BLKR so that it contains the correct value before the block transfer command is sent. This error is difficult to reproduce, but if you insert a long delay (mdelay(10) or thereabouts) between the calls to atmci_start_command() and atmci_submit_data(), all transfers seem to fail without this patch, while I haven't seen any failures with this patch. Reported-by: Hein_Tibosch <hein_tibosch@yahoo.es> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-05avr32: Replace static clock list with dynamic linked listAlex Raimondi
This replaces the at32_clock_list array with a linked list. Clocks can now be registered (added) to the list. Signed-off-by: Alex Raimondi <raimondi@miromico.ch> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
2008-10-04Merge branch 'timers-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: clockevents: check broadcast tick device not the clock events device
2008-10-04Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86 setup: correct segfault in generation of 32-bit reloc kernel
2008-10-04clockevents: check broadcast tick device not the clock events deviceThomas Gleixner
Impact: jiffies increment too fast. Hugh Dickins noted that with NOHZ=n and HIGHRES=n jiffies get incremented too fast. The reason is a wrong check in the broadcast enter/exit code, which keeps the local apic timer in periodic mode when the switch happens. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-10-03Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6: selinux: Fix an uninitialized variable BUG/panic in selinux_secattr_to_sid()
2008-10-03ACPI: Make /proc/acpi/wakeup interface handle PCI devices (again)Rafael J. Wysocki
Make the ACPI /proc/acpi/wakeup interface set the appropriate wake-up bits of physical devices corresponding to the ACPI devices and make those bits be set initially for devices that are enabled to wake up by default. This is needed to restore the 2.6.26 and earlier behavior for the PCI devices that were previously handled correctly with the help of the /proc/acpi/wakeup interface. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03leds-pca955x: add proper error handling and fix bogus memory handlingSven Wegener
Check the return value of led_classdev_register and unregister all registered devices, if registering one device fails. Also the dynamic memory handling is totally bogus. You can't allocate multiple chunks via kzalloc() and expect them to be in order later. I wonder how this ever worked. Signed-off-by: Sven Wegener <sven.wegener@stealer.net> Acked-by: Nate Case <ncase@xes-inc.com> Tested-by: Nate Case <ncase@xes-inc.com> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03leds-fsg: change order of initialization and deinitializationSven Wegener
On initialization, we first do the ioremap and then register the led devices. On deinitialization, we do it in reverse order. This prevents someone calling into the brightness_set functions with an invalid latch_address. Signed-off-by: Sven Wegener <sven.wegener@stealer.net> Acked-by: Rod Whitby <rod@whitby.id.au> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03dw_dmac: fix copy/paste bug in taskletHaavard Skinnemoen
The tasklet checks RAW.BLOCK twice, and does not check RAW.XFER. This is obviously wrong, and could theoretically cause the driver to hang. Reported-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03Documentation/HOWTO: info about interface changes should CC linux-api@vgerMichael Kerrisk
The "Documentation" section of this file mentions that when an interface change is made, I should be CCed with info about the change (so that man-pages can document it). Additionally request that this info be CCed to the new linux-api@vger.kernel.org list. Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03SubmitChecklist: interfaces changes should CC linux-api@Michael Kerrisk
Mention that patches that change the kernel-userland interface should be CCed to the new list linux-api@vger.kernel.org. Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03MAINTAINERS: add mailing list for man-pagesMichael Kerrisk
Nowadays, man-pages has an associated mailing list. Mention that list in MAINTAINERS. Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03cpusets: remove pj from cpuset maintainersPaul Jackson
Remove myself from the kernel MAINTAINERS file for cpusets. I am leaving SGI and probably will not be active in Linux kernel work. I can be reached at <pj@usa.net>. Contact Derek Fults <dfults@sgi.com> for future SGI+cpuset related issues. I'm off to the next chapter of this good life. Signed-off-by: Paul Jackson <pj@sgi.com> Cc: Paul Menage <menage@google.com> Cc: Derek Fults <dfults@sgi.com> Cc: John Hesterberg <jh@sgi.com> Cc: Paul Jackson <pj@usa.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03include/linux/stacktrace.h: declare struct task_structAndrew Morton
include/linux/stacktrace.h:13: warning: 'struct task_struct' declared inside parameter list (This might be a hard error on sparc64, which uses this header and has -Werror) Reported-by: "Randy.Dunlap" <rdunlap@xenotime.net> Acked-by: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03orion_spi: fix handling of default transfer speedLennert Buytenhek
Accept zero (the default!) as a per-transfer clock speed override. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03fbdev: fix recursive notifier and locking when fbdev console is blankedKrzysztof Helt
Fix infinite recursive notifier in the fbdev layer. This causes recursive locking. Dmitry Baryshkov found the problem and confirmed that the patch fixes the bug. After doing # echo 1 > /sys/class/graphics/fb0/blank I got the following in my kernel log: ============================================= [ INFO: possible recursive locking detected ] 2.6.27-rc6-00086-gda63874-dirty #97 --------------------------------------------- echo/1564 is trying to acquire lock: ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c but task is already holding lock: ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c other info that might help us debug this: 2 locks held by echo/1564: #0: (&buffer->mutex){--..}, at: [<c00ddde0>] sysfs_write_file+0x30/0x80 #1: ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c stack backtrace: [<c0029fe4>] (dump_stack+0x0/0x14) from [<c0060ce0>] (print_deadlock_bug+0xa4/0xd0) [<c0060c3c>] (print_deadlock_bug+0x0/0xd0) from [<c0060e54>] (check_deadlock+0x148/0x17c) r6:c397a1e0 r5:c397a530 r4:c04fcf98 [<c0060d0c>] (check_deadlock+0x0/0x17c) from [<c00637e8>] (validate_chain+0x3c4/0x4f0) [<c0063424>] (validate_chain+0x0/0x4f0) from [<c0063efc>] (__lock_acquire+0x5e8/0x6b4) [<c0063914>] (__lock_acquire+0x0/0x6b4) from [<c006402c>] (lock_acquire+0x64/0x78) [<c0063fc8>] (lock_acquire+0x0/0x78) from [<c0316ca8>] (down_read+0x4c/0x60) r7:00000009 r6:ffffffff r5:c0427a40 r4:c005a384 [<c0316c5c>] (down_read+0x0/0x60) from [<c005a384>] (__blocking_notifier_call_chain+0x38/0x6c) r5:c0427a40 r4:c0427a74 [<c005a34c>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c005a3d8>] (blocking_notifier_call_chain+0x20/0x28) r8:00000009 r7:c086d640 r6:c3967940 r5:00000000 r4:c38984b8 [<c005a3b8>] (blocking_notifier_call_chain+0x0/0x28) from [<c014baa0>] (fb_notifier_call_chain+0x1c/0x24) [<c014ba84>] (fb_notifier_call_chain+0x0/0x24) from [<c014c18c>] (fb_blank+0x64/0x70) [<c014c128>] (fb_blank+0x0/0x70) from [<c0155978>] (fbcon_blank+0x114/0x1bc) r5:00000001 r4:c38984b8 [<c0155864>] (fbcon_blank+0x0/0x1bc) from [<c0170ea8>] (do_blank_screen+0x1e0/0x2a0) [<c0170cc8>] (do_blank_screen+0x0/0x2a0) from [<c0154024>] (fbcon_fb_blanked+0x74/0x94) r5:c3967940 r4:00000001 [<c0153fb0>] (fbcon_fb_blanked+0x0/0x94) from [<c0154228>] (fbcon_event_notify+0x100/0x12c) r5:fffffffe r4:c39bc194 [<c0154128>] (fbcon_event_notify+0x0/0x12c) from [<c005a0d4>] (notifier_call_chain+0x38/0x7c) [<c005a09c>] (notifier_call_chain+0x0/0x7c) from [<c005a3a0>] (__blocking_notifier_call_chain+0x54/0x6c) r8:c3b51ea0 r7:00000009 r6:ffffffff r5:c0427a40 r4:c0427a74 [<c005a34c>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c005a3d8>] (blocking_notifier_call_chain+0x20/0x28) r8:00000001 r7:c3a7e000 r6:00000000 r5:00000000 r4:c38984b8 [<c005a3b8>] (blocking_notifier_call_chain+0x0/0x28) from [<c014baa0>] (fb_notifier_call_chain+0x1c/0x24) [<c014ba84>] (fb_notifier_call_chain+0x0/0x24) from [<c014c18c>] (fb_blank+0x64/0x70) [<c014c128>] (fb_blank+0x0/0x70) from [<c014e450>] (store_blank+0x54/0x7c) r5:c38984b8 r4:c3b51ec4 [<c014e3fc>] (store_blank+0x0/0x7c) from [<c017981c>] (dev_attr_store+0x28/0x2c) r8:00000001 r7:c042bf80 r6:c39eba10 r5:c3967c30 r4:c38e0140 [<c01797f4>] (dev_attr_store+0x0/0x2c) from [<c00ddaac>] (flush_write_buffer+0x54/0x68) [<c00dda58>] (flush_write_buffer+0x0/0x68) from [<c00dde08>] (sysfs_write_file+0x58/0x80) r8:c3b51f78 r7:c3bcb070 r6:c39eba10 r5:00000001 r4:00000001 [<c00dddb0>] (sysfs_write_file+0x0/0x80) from [<c009de04>] (vfs_write+0xb8/0x148) [<c009dd4c>] (vfs_write+0x0/0x148) from [<c009e384>] (sys_write+0x44/0x70) r7:00000004 r6:c3bcb070 r5:00000000 r4:00000000 [<c009e340>] (sys_write+0x0/0x70) from [<c0025d00>] (ret_fast_syscall+0x0/0x2c) r6:4001b000 r5:00000001 r4:401dc658 Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> Reported-by: Dmitry Baryshkov <dbaryshkov@gmail.com> Testted-by: Dmitry Baryshkov <dbaryshkov@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03rtc: fix kernel panic on second use of SIGIO nofiticationMarcin Slusarz
When userspace uses SIGIO notification and forgets to disable it before closing file descriptor, rtc->async_queue contains stale pointer to struct file. When user space enables again SIGIO notification in different process, kernel dereferences this (poisoned) pointer and crashes. So disable SIGIO notification on close. Kernel panic: (second run of qemu (requires echo 1024 > /sys/class/rtc/rtc0/max_user_freq)) general protection fault: 0000 [1] PREEMPT CPU 0 Modules linked in: af_packet snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq usbhid tuner tea5767 tda8290 tuner_xc2028 xc5000 tda9887 tuner_simple tuner_types mt20xx tea5761 tda9875 uhci_hcd ehci_hcd usbcore bttv snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer ir_common compat_ioctl32 snd_page_alloc videodev v4l1_compat snd_mpu401_uart snd_rawmidi v4l2_common videobuf_dma_sg videobuf_core snd_seq_device snd btcx_risc soundcore tveeprom i2c_viapro Pid: 5781, comm: qemu-system-x86 Not tainted 2.6.27-rc6 #363 RIP: 0010:[<ffffffff8024f891>] [<ffffffff8024f891>] __lock_acquire+0x3db/0x73f RSP: 0000:ffffffff80674cb8 EFLAGS: 00010002 RAX: ffff8800224c62f0 RBX: 0000000000000046 RCX: 0000000000000002 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800224c62f0 RBP: ffffffff80674d08 R08: 0000000000000002 R09: 0000000000000001 R10: ffffffff80238941 R11: 0000000000000001 R12: 0000000000000000 R13: 6b6b6b6b6b6b6b6b R14: ffff88003a450080 R15: 0000000000000000 FS: 00007f98b69516f0(0000) GS:ffffffff80623200(0000) knlGS:00000000f7cc86d0 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000a87000 CR3: 0000000022598000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process qemu-system-x86 (pid: 5781, threadinfo ffff880028812000, task ffff88003a450080) Stack: ffffffff80674cf8 0000000180238440 0000000200000002 0000000000000000 ffff8800224c62f0 0000000000000046 0000000000000000 0000000000000002 0000000000000002 0000000000000000 ffffffff80674d68 ffffffff8024fc7a Call Trace: <IRQ> [<ffffffff8024fc7a>] lock_acquire+0x85/0xa9 [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184 [<ffffffff80491d1f>] _read_lock+0x3e/0x4a [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184 [<ffffffff8029cb62>] send_sigio+0x2a/0x184 [<ffffffff8024fb97>] ? __lock_acquire+0x6e1/0x73f [<ffffffff8029cd4d>] ? kill_fasync+0x2c/0x4e [<ffffffff8029cd10>] __kill_fasync+0x54/0x65 [<ffffffff8029cd5b>] kill_fasync+0x3a/0x4e [<ffffffff80402896>] rtc_update_irq+0x9c/0xa5 [<ffffffff80404640>] cmos_interrupt+0xae/0xc0 [<ffffffff8025d1c1>] handle_IRQ_event+0x25/0x5a [<ffffffff8025e5e4>] handle_edge_irq+0xdd/0x123 [<ffffffff8020da34>] do_IRQ+0xe4/0x144 [<ffffffff8020bad6>] ret_from_intr+0x0/0xf <EOI> [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad [<ffffffff8033fe67>] ? clear_page_c+0x7/0x10 [<ffffffff8026fc10>] ? get_page_from_freelist+0x385/0x450 [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad [<ffffffff80280aac>] ? anon_vma_prepare+0x2e/0xf6 [<ffffffff80279400>] ? handle_mm_fault+0x227/0x6a5 [<ffffffff80494716>] ? do_page_fault+0x494/0x83f [<ffffffff8049251d>] ? error_exit+0x0/0xa9 Code: cc 41 39 45 28 74 24 e8 5e 1d 0f 00 85 c0 0f 84 6a 03 00 00 83 3d 8f a9 aa 00 00 be 47 03 00 00 0f 84 6a 02 00 00 e9 53 03 00 00 <41> ff 85 38 01 00 00 45 8b be 90 06 00 00 41 83 ff 2f 76 24 e8 RIP [<ffffffff8024f891>] __lock_acquire+0x3db/0x73f RSP <ffffffff80674cb8> ---[ end trace 431877d860448760 ]--- Kernel panic - not syncing: Aiee, killing interrupt handler! Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Acked-by: Alessandro Zummo <alessandro.zummo@towertech.it> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-04selinux: Fix an uninitialized variable BUG/panic in selinux_secattr_to_sid()Paul Moore
At some point during the 2.6.27 development cycle two new fields were added to the SELinux context structure, a string pointer and a length field. The code in selinux_secattr_to_sid() was not modified and as a result these two fields were left uninitialized which could result in erratic behavior, including kernel panics, when NetLabel is used. This patch fixes the problem by fully initializing the context in selinux_secattr_to_sid() before use and reducing the level of direct context manipulation done to help prevent future problems. Please apply this to the 2.6.27-rcX release stream. Signed-off-by: Paul Moore <paul.moore@hp.com> Signed-off-by: James Morris <jmorris@namei.org>
2008-10-03Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] SMTC: Fix SMTC dyntick support. [MIPS] SMTC: Close tiny holes in the SMTC IPI replay system. [MIPS] SMTC: Fix holes in SMTC and FPU affinity support. [MIPS] SMTC: Build fix: Fix filename in Makefile [MIPS] Build fix: Fix irq flags type
2008-10-03Merge branch 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6Linus Torvalds
* 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6: [S390] qdio: prevent stack clobber [S390] nohz: Fix __udelay.
2008-10-03x86 setup: correct segfault in generation of 32-bit reloc kernelH. Peter Anvin
Impact: segfault on build of a 32-bit relocatable kernel When converting arch/x86/boot/compressed/relocs.c to support unlimited sections, the computation of sym_strtab in walk_relocs() was done incorrectly. This causes a segfault for some people when building the relocatable 32-bit kernel. Pointed out by Anonymous <pageexec@freemail.hu>. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2008-10-03Fix init/main.c to use regular printk with '%pF' for initcall fnLinus Torvalds
.. small detail, but the silly e1000e initcall warning debugging caused me to look at this code. Rather than gouge my eyes out with a spoon, I just fixed it. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-03[S390] qdio: prevent stack clobberJan Glauber
Don't print more information than fits into the string on the stack. Combine the informational output of qdio to fit into one line. Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-10-03[S390] nohz: Fix __udelay.Heiko Carstens
This fixes a regression that came with 934b2857cc576ae53c92a66e63fce7ddcfa74691 ("[S390] nohz/sclp: disable timer on synchronous waits."). If udelay() gets called from a disabled context it sets the clock comparator to a value where it expects the next interrupt. When the interrupt happens the clock comparator gets not reset and therefore the interrupt condition doesn't get cleared. The result is an endless timer interrupt loop. In addition this patch fixes also the following: rcutorture reveals that our __udelay implementation is still buggy, since it might schedule tasklets, but prevents their execution: NOHZ: local_softirq_pending 42 NOHZ: local_softirq_pending 02 NOHZ: local_softirq_pending 142 NOHZ: local_softirq_pending 02 To fix this we make sure that only the clock comparator interrupt is enabled when the enabled wait psw is loaded. Also no code gets called anymore which might schedule tasklets. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-10-03[MIPS] SMTC: Fix SMTC dyntick support.Kevin D. Kissell
Rework of SMTC support to make it work with the new clock event system, allowing "tickless" operation, and to make it compatible with the use of the "wait_irqoff" idle loop. The new clocking scheme means that the previously optional IPI instant replay mechanism is now required, and has been made more robust. Signed-off-by: Kevin D. Kissell <kevink@paralogos.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-03[MIPS] SMTC: Close tiny holes in the SMTC IPI replay system.Kevin D. Kissell
Signed-off-by: Kevin D. Kissell <kevink@paralogos.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-03[MIPS] SMTC: Fix holes in SMTC and FPU affinity support.Kevin D. Kissell
Signed-off-by: Kevin D. Kissell <kevink@paralogos.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-03[MIPS] SMTC: Build fix: Fix filename in MakefileRalf Baechle
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-03[MIPS] Build fix: Fix irq flags typeRalf Baechle
Though from a hardware perspective it would be sensible to use only a 32-bit unsigned int type Linux defines interrupt flags to be stored in an unsigned long and nothing else. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-03e1000e: Fix incorrect debug warningLinus Torvalds
Doing 'WARN_ON(preempt_count())' was horribly horribly wrong, and would cause tons of warnings at bootup if PREEMPT was enabled because the initcalls currently run with the kernel lock, which increments the preempt count. At the same time, the warning was also insufficient, since it didn't check that interrupts were enabled. The proper debug function to use for something that can sleep and wants a warning if it's called in the wrong context is 'might_sleep()'. Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-02Check mapped ranges on sysfs resource filesLinus Torvalds
This is loosely based on a patch by Jesse Barnes to check the user-space PCI mappings though the sysfs interfaces. Quoting Jesse's original explanation: It's fairly common for applications to map PCI resources through sysfs. However, with the current implementation, it's possible for an application to map far more than the range corresponding to the resourceN file it opened. This patch plugs that hole by checking the range at mmap time, similar to what is done on platforms like sparc64 in their lower level PCI remapping routines. It was initially put together to help debug the e1000e NVRAM corruption problem, since we initially thought an X driver might be walking past the end of one of its mappings and clobbering the NVRAM. It now looks like that's not the case, but doing the check is still important for obvious reasons. and this version of the patch differs in that it uses a helper function to clarify the code, and does all the checks in pages (instead of bytes) in order to avoid overflows when doing "<< PAGE_SHIFT" etc. Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-02e1000e: update version from k4 to k6Jesse Brandeburg
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-02e1000e: debug contention on NVM SWFLAGThomas Gleixner
This patch adds a mutex to the e1000e driver that would help catch any collisions of two e1000e threads accessing hardware at the same time. description and patch updated by Jesse Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-02e1000e: drop stats lockJesse Brandeburg
the stats lock is left over from e1000, e1000e no longer has the adjust tbi stats function that required the addition of the stats lock to begin with. adding a mutex to acquire_swflag helped catch this one too. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-02e1000e: remove phy read from inside spinlockJesse Brandeburg
thanks to tglx, we're finding some interesting reentrancy issues. this patch removes the phy read from inside a spinlock, paving the way for removing the spinlock completely. The phy read was only feeding a statistic that wasn't used. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>