- 20 Feb, 2013 30 commits
-
-
Marcin Slusarz authored
- record channel owner process name - add some helpers for accessing this information - let nouveau_enum hold additional value (will be needed in the next patch) Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Marcin Slusarz authored
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Marcin Slusarz authored
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
This should avoid the situation where a user gets its kernel logs flooded when temperature oscillates around a threshold with 0°C hysteresis. This patch is just meant to fix broken vbios (as reported on a nv4e on sysfs hwmon interface. Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Emil Velikov authored
Commit 767baf82 drm/nouveau: remove some more unnecessary legacy bios code has introduced a regression my misplacing the code that sets the major/chip versions, which are used whist parsing the bmp/bit structure in vbios Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
My GTX660 has the GPIO_FAN function, but it's configured in input-mode; presumably to monitor the frequency set by an I2C fan controller? Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
From browsing my /sys, a few other things seem to do this, and it looks cleaner this way too :) Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Fan speed info now shown by sensors. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Martin Peres authored
Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
Expose all the hysteresis parameters + shutdown (emergency) + fan_boost (fixed pwm trip point). Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
For now, we only boost the fan speed to the maximum and auto-mode when hitting the FAN_BOOST threshold and halt the computer when it reaches the shutdown temperature. The downclock and critical thresholds do nothing. On nv43:50 and nva3+, temperature is polled because of the limited hardware. I'll improve the nva3+ situation by implementing alarm management in PDAEMON whenever I can but polling once every second shouldn't be such a problem. v2 (Ben Skeggs): - rebased v3: fixed false-detections and threshold reprogrammation handling on nv50:nvc0 Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Martin Peres authored
Based on Ben Skeggs's nvc0 patch. Tested on my nv4b, 84 and 92. Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
We are going to use PTHERM's IRQs for thermal monitoring but we need to route them first. On nv31-50, PBUS's IRQ line is shared with GPIOs IRQs. It seems like nv10-31 GPIO interruptions aren't well handled. I kept the original behaviour but it is wrong and may lead to an IRQ storm. Since we enable all PBUS IRQs, we need a way to avoid being stormed if we don't handle them. The solution I used was to mask the IRQs that have not been handled. This will also print one message in the logs to let us know. v2: drop the shared intr handler because of was racy v3: style fixes v4: drop a useless construct in the chipset-dependent INTR v5: add BUS to the disable mask v6 (Ben Skeggs): - general tidy to match the rest of the driver's style - nva3->nvc0, nva3 can be serviced just fine with nv50.c, rnndb even notes that the THERM_ALARM bit got left in the hw until fermi anyway.. so, it's not going to conflict - removed the peephole and user stuff, for the moment.. will handle them later if we find a good reason to actually care.. - limited INTR_EN to just what we can handle for now, mostly to prevent spam of unknown status bits (seen on at least nv4x) Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Martin Peres authored
v2: improved design but drops safety monitoring (to be in a later patch) v3: fix locking and mode management v4: gently fallback to the no-control mode when temperature cannot be got and use kernel-provided min/max macros v5 (Ben Skeggs): - rebased on my previous patches v6: fix hysterisis management in trip-based auto fan management This commit also forbids access to fan management to nvc0+ chipsets as fan management is already taken care of my PDAEMON's default fw. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Martin Peres authored
v2 (Ben Skeggs): - split from larger patch - fixed to not require alarm resched patch Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Martin Peres authored
Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
v2: change percent from int to atomic_t v3: random fixes v4 (Ben Skeggs): - adapted for split-out fan-control "protocol" structure - removed need for timer resched - support for forcing 'toggle' control on PWM boards Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Mostly to allow for the possibility of testing 'toggle' fan control easily. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This info will be used by two more implementations in upcoming commits. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
- 01 Feb, 2013 2 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dmLinus Torvalds authored
Pull more device-mapper fixes from Alasdair G Kergon: "A fix for stacked dm thin devices and a fix for the new dm WRITE SAME support." * tag 'dm-3.8-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm: dm: fix write same requests counting dm thin: fix queue limits stacking
-
- 31 Jan, 2013 8 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hidLinus Torvalds authored
PullHID fixes from Jiri Kosina: - fix i2c-hid and hidraw interaction, by Benjamin Tissoires - a quirk to make a particular device (Formosa IR receiver) work properly, by Nicholas Santos * 'for-3.8/upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: HID: i2c-hid: fix i2c_hid_output_raw_report HID: usbhid: quirk for Formosa IR receiver HID: remove x bit from sensor doc
-
git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds authored
Pull NFS client bugfixes from Trond Myklebust: - Error reporting in nfs_xdev_mount incorrectly maps all errors to ENOMEM - Fix an NFSv4 refcounting issue - Fix a mount failure when the server reboots during NFSv4 trunking discovery - NFSv4.1 mounts may need to run the lease recovery thread. - Don't silently fail setattr() requests on mountpoints - Fix a SUNRPC socket/transport livelock and priority queue issue - We must handle NFS4ERR_DELAY when resetting the NFSv4.1 session. * tag 'nfs-for-3.8-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFSv4.1: Handle NFS4ERR_DELAY when resetting the NFSv4.1 session SUNRPC: When changing the queue priority, ensure that we change the owner NFS: Don't silently fail setattr() requests on mountpoints NFSv4.1: Ensure that nfs41_walk_client_list() does start lease recovery NFSv4: Fix NFSv4 trunking discovery NFSv4: Fix NFSv4 reference counting for trunked sessions NFS: Fix error reporting in nfs_xdev_mount
-
git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds authored
Pull MIPS updates from Ralf Baechle: "A number of fixes all across the MIPS tree. No area is particularly standing out and things have cooled down quite nicely for a release." * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: Function tracer: Fix broken function tracing mips: Move __virt_addr_valid() to a place for MIPS 64 MIPS: Netlogic: Fix UP compilation on XLR MIPS: AR71xx: Fix AR71XX_PCI_MEM_SIZE MIPS: AR724x: Fix AR724X_PCI_MEM_SIZE MIPS: Lantiq: Fix cp0_perfcount_irq mapping MIPS: DSP: Fix DSP mask for registers. MIPS: Fix build failure by adding definition of pfn_pmd(). MIPS: Octeon: Fix warning. MIPS: delay.c: Check BITS_PER_LONG instead of __SIZEOF_LONG__ MIPS: PNX833x: Fix comment. MIPS: Add struct p_format to union mips_instruction. MIPS: Export <asm/break.h>. MIPS: BCM47xx: Enable SSB prerequisite SSB_DRIVER_PCICORE. MIPS: BCM47xx: Select GPIOLIB for BCMA on bcm47xx platform MIPS: vpe.c: Fix null pointer dereference in print arguments.
-
Benjamin Tissoires authored
i2c_hid_output_raw_report is used by hidraw to forward set_report requests. The current implementation of i2c_hid_set_report needs to take the report_id as an argument. The report_id is stored in the first byte of the buffer in argument of i2c_hid_output_raw_report. Not removing the report_id from the given buffer adds this byte 2 times in the command, leading to a non working command. Reported-by: Andrew Duggan <aduggan@synaptics.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Al Cooper authored
Function tracing is currently broken for all 32 bit MIPS platforms. When tracing is enabled, the kernel immediately hangs on boot. This is a result of commit b732d439 that changes the kernel/trace/Kconfig file so that is no longer forces FRAME_POINTER when FUNCTION_TRACING is enabled. MIPS frame pointers are generally considered to be useless because they cannot be used to unwind the stack. Unfortunately the MIPS function tracing code has bugs that are masked by the use of frame pointers. This commit fixes the bugs so that MIPS frame pointers don't need to be enabled. The bugs are a result of the odd calling sequence used to call the trace routine. This calling sequence is inserted into every traceable function when the tracing CONFIG option is enabled. This sequence is generated for 32bit MIPS platforms by the compiler via the "-pg" flag. Part of the sequence is "addiu sp,sp,-8" in the delay slot after every call to the trace routine "_mcount" (some legacy thing where 2 arguments used to be pushed on the stack). The _mcount routine is expected to adjust the sp by +8 before returning. So when not disabled, the original jalr and addiu will be there, so _mcount has to adjust sp. The problem is that when tracing is disabled for a function, the "jalr _mcount" instruction is replaced with a nop, but the "addiu sp,sp,-8" is still executed and the stack pointer is left trashed. When frame pointers are enabled the problem is masked because any access to the stack is done through the frame pointer and the stack pointer is restored from the frame pointer when the function returns. This patch writes two nops starting at the address of the "jalr _mcount" instruction whenever tracing is disabled. This means that the "addiu sp,sp.-8" will be converted to a nop along with the "jalr". When disabled, there will be two nops. This is SMP safe because the first time this happens is during ftrace_init() which is before any other processor has been started. Subsequent calls to enable/disable tracing when other CPUs ARE running will still be safe because the enable will only change the first nop to a "jalr" and the disable, while writing 2 nops, will only be changing the "jalr". This patch also stops using stop_machine() to call the tracer enable/disable routines and calls them directly because the routines are SMP safe. When the kernel first boots we have to be able to handle the gcc generated jalr, addui sequence until ftrace_init gets a chance to run and change the sequence. At this point mcount just adjusts the stack and returns. When ftrace_init runs, we convert the jalr/addui to nops. Then whenever tracing is enabled we convert the first nop to a "jalr mcount+8". The mcount+8 entry point skips the stack adjust. [ralf@linux-mips.org: Folded in Steven Rostedt's build fix.] Signed-off-by: Al Cooper <alcooperx@gmail.com> Cc: rostedt@goodmis.org Cc: ddaney.cavm@gmail.com Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/4806/ Patchwork: https://patchwork.linux-mips.org/patch/4841/Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Alasdair G Kergon authored
When processing write same requests, fix dm to send the configured number of WRITE SAME requests to the target rather than the number of discards, which is not always the same. Device-mapper WRITE SAME support was introduced by commit 23508a96 ("dm: add WRITE SAME support"). Signed-off-by: Alasdair G Kergon <agk@redhat.com> Acked-by: Mike Snitzer <snitzer@redhat.com>
-
Steven Rostedt authored
Commit d3ce8843 "MIPS: Fix modpost error in modules attepting to use virt_addr_valid()" moved __virt_addr_valid() from a macro in a header file to a function in ioremap.c. But ioremap.c is only compiled for MIPS 32, and not for MIPS 64. When compiling for my yeeloong2, which supposedly supports hibernation, which compiles kernel/power/snapshot.c which calls virt_addr_valid(), I got this error: LD init/built-in.o kernel/built-in.o: In function `memory_bm_free': snapshot.c:(.text+0x4c9c4): undefined reference to `__virt_addr_valid' snapshot.c:(.text+0x4ca58): undefined reference to `__virt_addr_valid' kernel/built-in.o: In function `snapshot_write_next': (.text+0x4e44c): undefined reference to `__virt_addr_valid' kernel/built-in.o: In function `snapshot_write_next': (.text+0x4e890): undefined reference to `__virt_addr_valid' make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2 I suspect that __virt_addr_valid() is fine for mips 64. I moved it to mmap.c such that it gets compiled for mips 64 and 32. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/4842/Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Mike Snitzer authored
thin_io_hints() is blindly copying the queue limits from the thin-pool which can lead to incorrect limits being set. The fix here simply deletes the thin_io_hints() hook which leaves the existing stacking infrastructure to set the limits correctly. When a thin-pool uses an MD device for the data device a thin device from the thin-pool must respect MD's constraints about disallowing a bio from spanning multiple chunks. Otherwise we can see problems. If the raid0 chunksize is 1152K and thin-pool chunksize is 256K I see the following md/raid0 error (with extra debug tracing added to thin_endio) when mkfs.xfs is executed against the thin device: md/raid0:md99: make_request bug: can't convert block across chunks or bigger than 1152k 6688 127 device-mapper: thin: bio sector=2080 err=-5 bi_size=130560 bi_rw=17 bi_vcnt=32 bi_idx=0 This extra DM debugging shows that the failing bio is spanning across the first and second logical 1152K chunk (sector 2080 + 255 takes the bio beyond the first chunk's boundary of sector 2304). So the bio splitting that DM is doing clearly isn't respecting the MD limits. max_hw_sectors_kb is 127 for both the thin-pool and thin device (queue_max_hw_sectors returns 255 so we'll excuse sysfs's lack of precision). So this explains why bi_size is 130560. But the thin device's max_hw_sectors_kb should be 4 (PAGE_SIZE) given that it doesn't have a .merge function (for bio_add_page to consult indirectly via dm_merge_bvec) yet the thin-pool does sit above an MD device that has a compulsory merge_bvec_fn. This scenario is exactly why DM must resort to sending single PAGE_SIZE bios to the underlying layer. Some additional context for this is available in the header for commit 8cbeb67a ("dm: avoid unsupported spanning of md stripe boundaries"). Long story short, the reason a thin device doesn't properly get configured to have a max_hw_sectors_kb of 4 (PAGE_SIZE) is that thin_io_hints() is blindly copying the queue limits from the thin-pool device directly to the thin device's queue limits. Fix this by eliminating thin_io_hints. Doing so is safe because the block layer's queue limits stacking already enables the upper level thin device to inherit the thin-pool device's discard and minimum_io_size and optimal_io_size limits that get set in pool_io_hints. But avoiding the queue limits copy allows the thin and thin-pool limits to be different where it is important, namely max_hw_sectors_kb. Reported-by: Daniel Browning <db@kavod.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Alasdair G Kergon <agk@redhat.com>
-