- 13 Nov, 2003 1 commit
-
-
James Bottomley authored
-
- 12 Nov, 2003 8 commits
-
-
bk://gkernel.bkbits.net/net-drivers-2.5Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Jeff Garzik authored
into redhat.com:/spare/repo/net-drivers-2.5
-
Stephen Hemminger authored
-
Herbert Xu authored
(fixes crash)
-
David S. Miller authored
into hera.kernel.org:/home/davem/BK/net-2.5
-
Jan Oravec authored
-
Ivan Kokshaysky authored
This forward-ports some more of the ALI IDE sanity checks from the 2.4.x tree. In particular, we only do the enable bits for revisions < 0xC5
-
Wei Ni authored
We've resolved some bugs in legacy ALi5455 audio driver.
-
- 11 Nov, 2003 16 commits
-
-
http://lia64.bkbits.net/to-linus-2.5Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Linus Torvalds authored
This leaves just the minimal oops protection in place, and maintains the logic that "if we have a non-ALI northbridge, we shouldn't touch any of the GPIOs because we don't know what they might be connected to".
-
David S. Miller authored
- Mucking with the original skb pointers with push/pull around the packet quoting was wrong, muching with these pointers could cause problems with others using the SKB. It was also buggy, it only handled the case where skb->nh.raw was ahead of or equal to skb->data - The fix is to record skb->nh.raw - skb->data and use this as a base offset in calls to skb_copy_and_csum_bits(). This is what the pre-IPSEC code did. This fixes IPV6 oopses and packet corruption on 64-bit platforms when sending UDP port unreachable ICMP messages. Reported and analyzed by Jan Oravec (jan.oravec@6com.sk)
-
David Mosberger authored
signal handler. Otherwise, a restarted system call that gets interrupted before the restart has taken effect by _another_ signal will potentially restart the wrong system call.
-
Linus Torvalds authored
Otherwise, a restarted system call that gets interrupted before the restart has taken effect by _another_ signal will potentially restart the wrong system call.
-
Linus Torvalds authored
It would oops on any machines that had an ALI northbridge but didn't have the exact ISA bridge we expected.
-
Julian Anastasov authored
-
Andrew Morton authored
-
Julian Anastasov authored
-
George Anzinger authored
The problem with clock_nanosleep() restarting was that the address of the users return timespec was being saved at the wrong place. In needs to be saved in the sys call interface code rather than the do_clock_nanosleep(). My original tests were a bit weak as they only did one signal rather than two or more which were required to break it. The attached patch fixes the problem. I also added a few comments about how restart works, and added my name to the MAINTAINERS list.
-
Jack Steiner authored
Without this patch, SN machines which have nodes that contain memory only (no CPUs will hang.
-
Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Linus Torvalds authored
The bug is probably impossible to trigger on x86, due to its fairly strong coherency model (the SMP-safe bitops end up being memory barriers etc), but other architectures - notably ppc64 - can apparently trigger a race whereby the signal sender doesn't wake up the target because it doesn't notice that it has gone to sleep. The optimization also optimizes only what appears to be the uncommon case, where the signal happens for an already-running process.
-
Daniel McNeil authored
This makes the AIO submit path holds an extra reference until just before returning. This fixes the referencing a free kiocb. Without this patch the kernel will oops if the AIO completes early.
-
Linus Torvalds authored
Noticed by Petr Vandrovec. In the out-of-memory case, do_wp_page() would unlock page_table_lock twice - once before allocating, and once in the exit path. Rewrite the exit paths to be more readable, and don't try to share the code between all the exit cases, since they are very different.
-
- 10 Nov, 2003 12 commits
-
-
David S. Miller authored
- Delete fd_{enable,disable}_irq() interfaces, never used. - Move ebus_dma_irq_enable() calls into sun_pci_fd_{request,free}_irq().
-
Hideaki Yoshifuji authored
-
Hideaki Yoshifuji authored
-
http://lia64.bkbits.net/to-linus-2.5Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
David Mosberger authored
-
Paul Jackson authored
Display of cpumask for /proc/irq/prof_cpu_mask has a botch in the print loop - should consume 2 bytes per loop.
-
http://lia64.bkbits.net/to-linus-2.5Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
David Mosberger authored
Found by Russell King.
-
Andries E. Brouwer authored
Since 2.6.x by default does not remap the disk partitions any more, it would be a good idea to warn when we see EZD or DM signatures. That informs the user to fix his setup (or pass in "hdx=remap" on the kernel command line).
-
bk://gkernel.bkbits.net/net-drivers-2.5Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
bk://gkernel.bkbits.net/libata-2.5Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Jeff Garzik authored
* flush host FIFO after sending data to DIMM window * don't set SCR addresses, as the hardware doesn't have SCRs (cosmetic)
-
- 09 Nov, 2003 3 commits
-
-
Andrew Morton authored
From: James Bottomley <James.Bottomley@SteelEye.com> The cpu_callout_map differs from the prototype in asm-i386/smp.h by a volatile. gcc-3.3 now treats this as an error, so voyager support will only compile with older gcc's. The fix is to remove the spurious volatile.
-
Andrew Morton authored
This fixes a JBD assertion failure (goes BUG) in __journal_remove_journal_head(). When the journal had aborted due to earlier internal consistency errors (or I/O errors) it is possible that we free journal_heads which still have attached copyout buffers. So just free them up.
-
Andrew Morton authored
From: Mike Tran <mhtran@us.ibm.com> This fixes the RAID1 recovery problems; it seems to be a simple thinko: sync_request_write() is passing "ok=0" into md_done_sync(). Clearly, `ok' should be true here. (acked by neilb)
-