- 27 Jun, 2005 40 commits
-
-
Benjamin Herrenschmidt authored
The Power Management Unit on PowerMacs is very sensitive to timeouts during async message exchanges. It uses rather crude protocol based on a shift register with an interrupt and is almost continuously exchanging messages with the host CPU on laptops. This patch adds a routine to the open_pic driver to be able to select a PMU driver so that it bumps it's interrupt priority to above the normal level. This will allow PMU interrupts to occur while another interrupt is pending, and thus reduce the risk of machine beeing abruptly shutdown by the PMU due to a timeout in PMU communication caused by excessive interrupt latency. The problem is very rare, and usually just doesn't happen, but it is still useful to make things even more robust. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Marcelo Tosatti authored
The proposed _tlbie call at update_mmu_cache() is safe because: Addresses for which update_mmu_cache() gets invocated are never inside the static kernel virtual mapping, meaning that there is no risk for the _tlbie() here to be thrashing the pinned entry, as Dan suspected. The intermediate TLB state in which this bug can be triggered is not visible by userspace or any other contexts, except the page fault handling path. So there is no need to worry about userspace dcbxxx users. The other solution to this is to avoid dcbst misbehaviour in the first place, which involves changing in-kernel "dcbst" callers to use 8xx specific SPR's. Summary: On 8xx, cache control instructions (particularly "dcbst" from flush_dcache_icache) fault as write operation if there is an unpopulated TLB entry for the address in question. To workaround that, we invalidate the TLB here, thus avoiding dcbst misbehaviour. Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Yoichi Yuasa authored
arch/mips/kernel/signal.c: In function 'do_signal': arch/mips/kernel/signal.c:460: error: too many arguments to function 'try_to_freeze' Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Bob Picco authored
I spotted this issue while in memmap_init last week. I can't say the change has any test coverage by me. start_pfn was formerly used in main "for" loop. The fix is replace start_pfn with pfn. Signed-off-by: Bob Picco <bob.picco@hp.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Kumar Gala authored
Lost a curly brace in translation. Everything is better now. Signed-off-by: Matt McClintock <msm@freescale.com> Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
-
Linus Torvalds authored
-
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/dtor/input.gitLinus Torvalds authored
Some manual fixups required due to clashes with the PF_FREEZE cleanups.
-
Dave Jones authored
CONFIG_CONFIG_TUNER_MULTI_I2C probably isn't what the author meant to create. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jens Axboe authored
If cfq is managing a queue and a new scheduler is later selected, it is possible for the cfqd unplug_work work to be queued after the kblockd work struct has been flushed. The problem is the ordering of cfq_shutdown_timer_wq() and blk_put_queue() in cfq_put_cfqd(). The latter may rearm the work, leaving cfq_kick_queue() with dead data. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jens Axboe authored
Add ioprio documentation Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jens Axboe authored
- Adjust slice values - Instead of one async queue, one is defined per priority level. This prevents kernel threads (such as reiserfs/x and others) that run at higher io priority from conflicting with others. Previously, it was a coin toss what io prio the async queue got, it was defined by who first set up the queue. - Let a time slice only begin, when the previous slice is completely done. Previously we could be somewhat unfair to a new sync slice, if the previous slice was async and had several ios queued. This might need a little tweaking if throughput suffers a little due to this, allowing perhaps an overlap of a single request or so. - Optimize the calling of kblockd_schedule_work() by doing it only when it is strictly necessary (no requests in driver and work left to do). - Correct sync vs async logic. A 'normal' process can be purely async as well, and a flusher can be purely sync as well. Sync or async is now a property of the class defined and requests pending. Previously writers could be considered sync, when they were really async. - Get rid of the bit fields in cfqq and crq, use flags instead. - Various other cleanups and fixes Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jens Axboe authored
In cfq_find_next_crq(), cfq tries to find the next request by choosing one of two requests before and after the current one. Currently, when choosing the next request, if there's no next request, the next candidate is NULL, resulting in selection of the previous request. This results in weird scheduling. Once we reach the end, we always seek backward. The correct behavior is using the first request as the next candidate. cfq_choose_req() already has logics for handling wrapped requests. Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jens Axboe authored
This updates the CFQ io scheduler to the new time sliced design (cfq v3). It provides full process fairness, while giving excellent aggregate system throughput even for many competing processes. It supports io priorities, either inherited from the cpu nice value or set directly with the ioprio_get/set syscalls. The latter closely mimic set/getpriority. This import is based on my latest from -mm. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Deepak Saxena authored
Patch from Deepak Saxena Accidently swapped the order of movne and orrne. Bad. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Michael Burian authored
Patch from Michael Burian This does not look like an include file for "i386", so use "ARM" instead. Signed-off-by: Michael Burian <dynmail1@gassner-waagen.at> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
It doesn't make sense for this to be in mm-armv.c now that 26-bit ARM support is no longer integrated into arch/arm. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
It doesn't make sense to have the PGD kernel pointers initialisation separate from the PGD user pointers, especially when we clean the data cache over the whole range. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
This call allows the dynamic tick support to reprogram the timer immediately before the CPU idles. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
My scripts missed committing this file. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Add separate files for the different 8250 ISA-based serial boards. Looking across all the various architectures, it seems reasonable that we can key the availability of the configuration options for these beasts to the bus-related symbols (iow, CONFIG_ISA). We also standardise the base baud/uart clock rate for these boards - I'm sure that isn't architecture specific, but is solely dependent on the crystal fitted on the board (which should be the same no matter what type of machine its fitted into.) Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
68328serial.c does not make use of register_serial/unregister_serial, which is traditionally used to register 8250-compatible UARTs with the 8250-compatible serial driver. Acked-by: David McCullough Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Tobias Klauser authored
Use the DMA_32BIT_MASK constant from dma-mapping.h when calling pci_set_dma_mask() or pci_set_consistent_dma_mask() See http://marc.theaimsgroup.com/?t=108001993000001&r=1&w=2 for details Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch> Signed-off-by: Domen Puncer <domen@coderock.org>
-
Philip Pokorny authored
This is a multi-part message in MIME format.
-
John W. Linville authored
Check the link state during b44_open. This closes a 1 HZ window that existed after b44_open ran but before the b44_timer handler ran, during which ethtool would report "Link detected: yes" no matter what the link state actually was. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Adam Belay authored
This patch allows the tulip driver to suspend and resume properly. It was originally written by Karsten Keil and then modified by Adam Belay. Signed-off-by: Karsten Keil <kkeil@suse.de> Signed-off-by: Adam Belay <abelay@novell.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
-
Olaf Hering authored
drivers/net/wireless/prism54/isl_38xx.c:131: warning: 'current_time.tv_sec' is used uninitialized in this function drivers/net/wireless/prism54/isl_38xx.c:131: warning: 'current_time.tv_usec' is used uninitialized in this function Signed-off-by: Olaf Hering <olh@suse.de>
-
YOSHIFUJI Hideaki authored
Some USB ethernet drivers did not accept multicast frames appropriately. IPv6 did not work with those drivers without this patch. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-
YOSHIFUJI Hideaki authored
Elecom (Laneed) LD-USBL/TX support. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-
Randy Dunlap authored
Module needs a license to prevent kernel tainting. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> diffstat:= drivers/net/3c523.c | 1 + 1 files changed, 1 insertion(+)
-
Kumar Gala authored
Jeff, Just incase this got lost in the recent netdev mailing list transition here is a nicer version of Andy's patch for gianfar. - kumar * TCP/IP/UDP checksumming and verification * VLAN tag insertion/extraction * Larger multicast hash-table * Padding to align IP headers Also added: * msg lvl support * Some whitespace cleanup Signed-off-by: Andy Fleming <afleming@freescale.com> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
-
Nicolas Pitre authored
The race causes a kernel oops when smc_hardware_send_pkt() tries to dereference pending_tx_skb which would have been freed from one of the driver reset paths just after the tx_task tasklet has been scheduled. This race is possible on SMP but was uncovered by the kernel RT work. Signed-off-by: Nicolas Pitre <nico@cam.org>
-
Denis Vlasenko authored
--Boundary-00=_F5lsC5eH1wGW5o9 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jeff, In some messages in via-rhine.c there is a leading space for no apparent reason. This patch removes it. -- vda --Boundary-00=_F5lsC5eH1wGW5o9 Content-Type: text/x-diff; charset="koi8-r"; name="via-rhine.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="via-rhine.c.diff"
-
Malli Chilakala authored
Driver version, white space, comments & other Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com> Signed-off-by: Ganesh Venkatesan <ganesh.venkatesan@intel.com> Signed-off-by: John Ronciak <john.ronciak@intel.com>
-
Malli Chilakala authored
Included proposals to false late collisions due to H/W latencies Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com> Signed-off-by: Ganesh Venkatesan <ganesh.venkatesan@intel.com> Signed-off-by: John Ronciak <john.ronciak@intel.com>
-