Jens Axboe [Mon, 27 Jun 2005 12:49:39 +0000 (14:49 +0200)]
[PATCH] CFQ io scheduler: scheduler switch oops
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.
Jens Axboe [Mon, 27 Jun 2005 08:56:24 +0000 (10:56 +0200)]
[PATCH] CFQ io scheduler updates
- 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.
Jens Axboe [Mon, 27 Jun 2005 08:55:49 +0000 (10:55 +0200)]
[PATCH] Fix cfq_find_next_crq()
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.
Jens Axboe [Mon, 27 Jun 2005 08:55:12 +0000 (10:55 +0200)]
[PATCH] Update cfq io scheduler to time sliced design
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.
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 [Mon, 27 Jun 2005 10:12:54 +0000 (11:12 +0100)]
[PATCH] Serial: Split 8250 port table
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 [Mon, 27 Jun 2005 09:29:26 +0000 (10:29 +0100)]
[PATCH] Serial: Remove {un,}register_serial from 68328serial.c
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 [Sat, 28 May 2005 23:17:29 +0000 (01:17 +0200)]
[PATCH] sound/oss/via82cxxx_audio: Use the DMA_32BIT_MASK constant
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>
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>
Olaf Hering [Wed, 25 May 2005 23:16:51 +0000 (01:16 +0200)]
[PATCH] uninitialized variable in prism54 isl38xx_trigger_device
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
Nicolas Pitre [Mon, 20 Jun 2005 03:56:21 +0000 (23:56 -0400)]
[PATCH] smc91x: plug race between TX tasklet and driver reset
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.
Malli Chilakala [Sat, 18 Jun 2005 00:27:41 +0000 (17:27 -0700)]
[PATCH] e100: fixed e100 MDI/MDI-X issues
Added patch from Eran Mann to fix following e100 MDI/MDI-X issues
* MDI/MDI-X autodetection should never be enabled for 82551ER/QM chips
* enabling this feature based on eeprom settings
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>
[PATCH] orinoco: always use 802.11 header for rx processing
If the frame has ToDS flag set, mark it by setting skb->pkt_type to
PACKET_OTHERHOST, so that applications unaware of promiscous mode won't get
uplink (STA->AP) packets for STA->STA transmissions relayed by the AP.
Thanks to John Denker and David Gibson for finding the problem and the
solution.
Tobias Klauser [Mon, 20 Jun 2005 21:49:08 +0000 (23:49 +0200)]
[PATCH] drivers/block/sx8.c: Use the DMA_{64, 32}BIT_MASK constants
Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h when calling
pci_set_dma_mask() or pci_set_consistent_dma_mask()
These patches include dma-mapping.h explicitly because it caused errors
on some architectures otherwise.
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>
[PATCH] net/farsync: add set_current_state() before schedule_timeout()
Insert set_current_state() before schedule_timeout() so the
function delays as expected. Without the addition, schedule_timeout()
will return immediately.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by: Maximilian Attems <janitor@sternwelten.at> Signed-off-by: Domen Puncer <domen@coderock.org>
[PATCH] net/sb1000: replace nicedelay() with ssleep()
Use ssleep() instead of nicedelay()
to guarantee the task delays as expected. Remove the prototype and
definition of nicedelay(). This is a very weird function, because it is
called to sleep in terms of usecs, but always sleeps for 1 second,
completely ignoring the parameter. I have gone ahead and followed suit,
just sleeping for a second in all cases, but maybe someone with the
hardware could tell me if perhaps the paramter *should* matter. Additionally,
nicedelay() is called in TASK_INTERRUPTIBLE state, but doesn't deal with signals
in case these longer delays do not complete, so I believe ssleep() is more
appropriate.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by: Domen Puncer <domen@coderock.org>
more outputs from Alexey Dobriyan:
2.95.3:
text data bss dec hex filename
before 51118 2156 160 53434 d0ba drivers/net/wireless/airo.o
after 51118 2156 160 53434 d0ba drivers/net/wireless/airo.o
3.3.5-20050130:
before 46999 2156 160 49315 c0a3 drivers/net/wireless/airo.o
after 46994 2156 160 49310 c09e drivers/net/wireless/airo.o
4.1.0-20050522:
before 45555 2220 160 47935 bb3f drivers/net/wireless/airo.o
after 45550 2220 160 47930 bb3a drivers/net/wireless/airo.o
pageexec [Sun, 26 Jun 2005 23:00:19 +0000 (16:00 -0700)]
[IPVS]: Fix for overflows
From: <pageexec@freemail.hu>
$subject was fixed in 2.4 already, 2.6 needs it as well.
The impact of the bugs is a kernel stack overflow and privilege escalation
from CAP_NET_ADMIN via the IP_VS_SO_SET_STARTDAEMON/IP_VS_SO_GET_DAEMON
ioctls. People running with 'root=all caps' (i.e., most users) are not
really affected (there's nothing to escalate), but SELinux and similar
users should take it seriously if they grant CAP_NET_ADMIN to other users.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Ismail Donmez [Mon, 20 Jun 2005 22:32:52 +0000 (15:32 -0700)]
[PATCH] Documentation/networking/dmfe.txt: Make documentation nicer
Patch indents dmfe.txt to look like other docs. It adds a tip about CNET
cards using Davicom chipsets. Also it removes parts where it refers to how
to build driver out-of-kernel which seems to be cruft from times where the
driver was out of the kernel.
Signed-off-by: Ismail Donmez <ismail@kde.org.tr> Signed-off-by: Domen Puncer <domen@coderock.org> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
[PATCH] defxx: Use irqreturn_t for the interrupt handler
This is a fix for the interrupt handler in the defxx driver to use
irqreturn_t. Beside the obvious fix of returning a proper status at all,
it actually checks board registers as appropriate for determining if an
interrupt has been recorded in the bus-specific interface logic.
The patch also includes an obvious one-line fix for SET_NETDEV_DEV needed
for the EISA variation, for which I've decided there is no point in sending
separately.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Mon, 20 Jun 2005 22:32:59 +0000 (15:32 -0700)]
[PATCH] dmfe warning fix
drivers/net/tulip/dmfe.c: In function `dmfe_parse_srom':
drivers/net/tulip/dmfe.c:1805: warning: passing arg 1 of `__le16_to_cpup' from incompatible pointer type
drivers/net/tulip/dmfe.c:1817: warning: passing arg 1 of `__le32_to_cpup' from incompatible pointer type
drivers/net/tulip/dmfe.c:1817: warning: passing arg 1 of `__le32_to_cpup' from incompatible pointer type
This is basically a guess:
Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
2) netlink_autobind() needs to propagate the error return from
netlink_insert(). Otherwise, callers will not see the error
as they should and thus try to operate on a socket with a zero pid,
which is very bad.
However, it should not propagate -EBUSY. If two threads race
to autobind the socket, that is fine. This is consistent with the
autobind behavior in other protocols.
So bug #1 above, combined with this one, resulted in hangs
on netlink_sendmsg() calls to the rtnetlink socket. We'd try
to do the user sendmsg() with the socket's pid set to zero,
later we do a socket lookup using that pid (via the value we
stashed away in NETLINK_CB(skb).pid), but that won't give us the
user socket, it will give us the rtnetlink socket. So when we
try to wake up the receive queue, we dive back into rtnetlink_rcv()
which tries to recursively take the rtnetlink semaphore.
Thanks to Jakub Jelink for providing backtraces. Also, thanks to
Herbert Xu for supplying debugging patches to help track this down,
and also finding a mistake in an earlier version of this fix.
Signed-off-by: David S. Miller <davem@davemloft.net>
Andreas Mohr [Mon, 11 Apr 2005 23:47:43 +0000 (16:47 -0700)]
[PATCH] pcnet_cs.c: IRQ handler optimization
During some performance diagnostics I stumbled on this slightly wasteful
code in pcnet_cs.c which I made the patch included at the bottom for (two
minor comment fixes included).
Improvement:
instead of *always* calculating
lea 0x2c0(%edx),%ebx
and then additionally doing the
mov %edx,0xc0(%ebx)
addition *if we need it*,
we now do the *whole* calculation of
mov %edx,0x380(%ebx)
*only* if we need it.
This even manages to save us a whole 16-byte alignment buffer loss
in this compilation case.
Result: slightly improves IRQ handler performance in both shared and
non-shared IRQ case, which should make my rusty P3/700 a slight bit happier.
Magnus Damm [Tue, 5 Apr 2005 18:05:50 +0000 (20:05 +0200)]
[PATCH] arlan: module parameter fixes
Make sure the code compiles with and without ARLAN_ENTRY_EXIT_DEBUGGING.
Only provide parameter descriptions when parameters are defined.
Remove "arlan_"-prefix to shape up built-in parameter names:
[PATCH] net/sis900: Use the DMA_32BIT_MASK constant
Use the DMA_32BIT_MASK constant from dma-mapping.h when calling
pci_set_dma_mask() or pci_set_consistent_dma_mask() instead of custom
macros.
This patch includes dma-mapping.h explicitly because it caused errors
on some architectures otherwise.
See http://marc.theaimsgroup.com/?t=108001993000001&r=1&w=2 for details
The spin loop in 8139cp is limited to 100 iterations when pulling hardware
stats. There is no allowance for processor speed so on a fast machine, the
stats may not be available that fast. Also, if the board doesn't return
soon enough make sure turn the address back off to prevent later updates
when memory has gone away.
Jay Vosburgh [Sun, 26 Jun 2005 21:54:11 +0000 (17:54 -0400)]
bonding: xor/802.3ad improved slave hash
Add support for alternate slave selection algorithms to bonding
balance-xor and 802.3ad modes. Default mode (what we have now: xor of
MAC addresses) is "layer2", new choice is "layer3+4", using IP and port
information for hashing to select peer.
Originally submitted by Jason Gabler for balance-xor mode;
modified by Jay Vosburgh to additionally support 802.3ad mode. Jason's
original comment is as follows:
The attached patch to the Linux Etherchannel Bonding driver modifies the
driver's "balance-xor" mode as follows:
- alternate hashing policy support for mode 2
* Added kernel parameter "xmit_policy" to allow the specification
of different hashing policies for mode 2. The original mode 2
policy is the default, now found in xmit_hash_policy_layer2().
* Added xmit_hash_policy_layer34()
This patch was inspired by hashing policies implemented by Cisco,
Foundry and IBM, which are explained in
Foundry documentation found at:
http://www.foundrynet.com/services/documentation/sribcg/Trunking.html#112750
Signed-off-by: Jason Gabler <jygabler@lbl.gov> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
projects / linux-beck.git / log