- 22 Jan, 2005 1 commit
-
-
David S. Miller authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 21 Jan, 2005 1 commit
-
-
Pablo Neira authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 20 Jan, 2005 11 commits
-
-
Michael Chan authored
- Add nvram size detection - Add appropriate byte swapping to tg3_get_eeprom so that the same byte stream is read in all systems - Fix tg3_get_eeprom to read both eeprom and flash - Add tg3_set_eeprom to write eeprom and flash - Change tg3_nvram_init to detect all supported nvram devices - Change tg3_nvram_read to properly detect Atmel flash that requires address translation - Increase nvram polling delay to account for slower eeprom devices - Remove some of the flushing read that is not required for the production 5750 devices Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
-
Ingo Molnar authored
This renames the x86 implementation of the spinlock_t's 'lock' field to 'slock', to protect against spinlock_t/rwlock_t type mismatches. This way, if you use a spinlock where a rwlock is expected (or vice versa), you'll get an obvious compile failure. build- and boot-tested on x86 SMP+PREEMPT and SMP+!PREEMPT. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
-
Linus Torvalds authored
Trivial but untested (but also currently unused - wait for BKL PREEMPT to start using them soon).
-
Linus Torvalds authored
-
Ingo Molnar authored
This introduces the following 3 new locking primitives: spin_can_lock(lock) read_can_lock(lock) write_can_lock(lock) which are a nonintrusive test to check whether the real (intrusive) trylock op would succeed or not. Semantics and naming is completely symmetric to the trylock counterpart. Architectures that want to support PREEMPT will need to add these definitions. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Ingo Molnar authored
cleanup: remove stale semicolon from linux/spinlock.h and stale space from asm-i386/spinlock.h. Ingo Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
It's a bootup dependancy, you can't just increase it randomly, and it breaks booting with LILO. Pointed out by Janos Farkas and Adrian Bunk. Cset exclude: ak@suse.de[torvalds]|ChangeSet|20050115232300|01174
-
Linus Torvalds authored
rwlocks can't be "locked". They can be "locked for read", or "locked for write", but not both. The confusion this caused is evident in the long discussion about this on linux-kernel ;)
-
Linus Torvalds authored
They had their time and place, but right now they are using infrastructure that is getting re-done, and we're better off just dropping them.
-
- 19 Jan, 2005 23 commits
-
-
Linus Torvalds authored
The locking tests were wrong, and the fixes are up in the air. In the meantime, the get-it-working patch is to just not do this. Cset exclude: mingo@elte.hu[torvalds]|ChangeSet|20050115174045|30241
-
bk://kernel.bkbits.net/davem/net-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://linux-dj.bkbits.net/agpgartLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Peter Osterlund authored
My ALPS touchpad is not recognized because the device gets confused by the Kensington ThinkingMouse probe. It responds with "00 00 14" instead of the expected "00 00 64" to the "E6 report". Resetting the device before attempting the ALPS probe fixes the problem. Signed-off-by: Peter Osterlund <petero2@telia.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
We could screw up and warn for opcodes that weren't write-safe and the user tried to use without having write permissions. Not so bad in itself, but that also destroyed the cmd type information. Noticed by Michal Schmidt
-
Dave Jones authored
From: Christoph Hellwig Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
into delerium.kernelslacker.org:/mnt/data/src/bk/agpgart
-
Dave Jones authored
- any device teardown must happen between agp_remove_bridge and agp_put_bridge, before agp_remove_bridge users can still call into the code - it's releasing a reference to the wrong device Original patch from: Christoph Hellwig Further munging from Roland Dreier and myself. Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
From: Christoph Hellwig Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
From: Alan Hourihane Signed-off-by: Dave Jones <davej@redhat.com>
-
David S. Miller authored
When drivers other than loopback were using the LLTX feature a race window was present. While sending queued packets, the packet scheduler layer drops the queue lock then calls directly into the drivers xmit handler. The driver then grabs it's private TX lock and goes to work. However, as soon as we've dropped the queue lock another thread doing TX processing for that card can execute a netif_stop_queue() due to the TX queue filling up. This race window causes problems because a properly coded driver should never end up in it's ->hard_start_xmit() handler if the queue on the device has been stopped and we even BUG() trap for this condition in all of the device drivers. That is how this race window was discovered by Roland and the Infiniband folks. Various suggestions were made to close this race. One of which involved holding onto the queue lock all the way into the ->hard_start_xmit() routine. Then having the driver drop that lock only after taking it's private TX lock. This solution was deemed grotty because it is not wise to put queueing discipline internals into the device drivers. The solution taken here, which is based upon ideas from Stephen Hemminger, is twofold: 1) Leave LLTX around for purely software devices that need no locking at all for TX processing. The existing example is loopback, although all tunnel devices could be converted in this way too. 2) Stop trying to use LLTX for the other devices. Instead achieve the same goal using a different mechanism. For #2, the thing we were trying to achieve with LLTX was to eliminate excess locking. We accomplish that now by letting the device driver use dev->xmit_lock directly instead of a seperate priv->tx_lock of some sort. In order to allow that, we had to turn dev->xmit_lock into a hardware IRQ disabling lock instead of a BH disabling one. Signed-off-by: David S. Miller <davem@davemloft.net>
-
bk://kernel.bkbits.net/acme/connection_sock-2.6David S. Miller authored
into nuts.davemloft.net:/disk1/BK/net-2.6
-
Herbert Xu authored
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
bk://212.42.230.204/net-2.6-schedDavid S. Miller authored
into nuts.davemloft.net:/disk1/BK/net-2.6
-
Patrick McHardy authored
into coreworks.de:/home/kaber/src/net/net-2.6-sched
-
Patrick McHardy authored
Both HFSC and CBQ leak unclassified skbs with CONFIG_NET_CLS_ACT. Move freeing to enqueue where it belongs. Same change for in HTB/prio, they just don't leak because they don't have unclassified packets. Signed-off-by: Patrick McHardy <kaber@trash.net>
-
Patrick McHardy authored
handle is computed wrong, this makes creating a filter not using "from" fail. Signed-off-by: Patrick McHardy <kaber@trash.net>
-
Hideaki Yoshifuji authored
I believe that compilers are clever enough, but anyway... Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
Signed-off-by: Patrick McHardy <kaber@trash.net>
-
David S. Miller authored
into nuts.davemloft.net:/disk1/BK/net-2.6
-
Patrick McHardy authored
The continue is supposed to continue the outer loop, not break out of the do { } while (0) loop. cls_route.c is also changed in a similar way for clarity, although it behaved correctly. Signed-off-by: Patrick McHardy <kaber@trash.net>
-
http://lia64.bkbits.net/linux-ia64-release-2.6.11Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Linus Torvalds authored
From: Roland McGrath <roland@redhat.com> The fxsave instruction does not save the x87 tag word (only the empty bits), and we re-created the old-style x87 tags incorrectly. The registers are saved in "stack order" in the save area, but the tag word bits are in "hardware order", and we need to get the right register state. Both x86 and x86-64 needed this fix. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 18 Jan, 2005 4 commits
-
-
Chas Williams authored
Signed-off by: James Lamanna <jlamanna@gmail.com> Signed-off-by: Domen Puncer <domen@coderock.org> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chas Williams authored
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by: Domen Puncer <domen@coderock.org> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chas Williams authored
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chas Williams authored
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-