First
|
Prev |
Next
|
Last
Pages: 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178
SB600 64-bit DMA BIOS misconfiguration (formerly RE: [PATCH 2.6.34] ehci-hcd: add option to enable 64-bit DMA support) On Tue, Feb 23, 2010 at 9:53 PM, Yuhong Bao <yuhongbao_386(a)hotmail.com> wrote: it doesn't work. Based on the libata experience with AHCI which has a similar 64-bit feature flag, there are some controllers that didn't do it properly, but not many (only ATI SB600 it appears, and only on certain boards,... 23 Feb 2010 23:50
[PATCH] x86: remove left over nr_legacy_irqs already in legacy_pic Singed-off-by: Yinghai Lu <yinghai(a)kernel.org> --- arch/x86/include/asm/irq.h | 1 - arch/x86/kernel/irqinit.c | 7 ++----- 2 files changed, 2 insertions(+), 6 deletions(-) Index: linux-2.6/arch/x86/include/asm/irq.h ========================================================... 23 Feb 2010 23:50
linux-next: manual merge of the staging tree with the wireless tree On Mon, Feb 22, 2010 at 04:31:34PM +1100, Stephen Rothwell wrote: Hi Greg, Today's linux-next merge of the staging tree got a conflict in drivers/staging/rtl8192su/ieee80211/ieee80211_rx.c between commit e2117cea27c6b27e1a379acac5eb0433eeb7033a ("staging: rtl8192su: fix compile error from wireless-te... 23 Feb 2010 22:44
linux-next: manual merge of the cpufreq tree with the acpi tree Hi Dave, Today's linux-next merge of the cpufreq tree got a conflict in drivers/acpi/processor_core.c between commit 5f45c35d7ede1c00cbaa3b09b8a84c425af81c4b ("ACPI: processor: mv processor_core.c processor_driver.c") from the acpi tree and commit 0f1d683fb35d6c6f49ef696c95757f3970682a0e ("[CPUFREQ] Processor Cl... 23 Feb 2010 22:44
[PATCH 05/15] readahead: limit readahead size for small memory systems When lifting the default readahead size from 128KB to 512KB, make sure it won't add memory pressure to small memory systems. For read-ahead, the memory pressure is mainly readahead buffers consumed by too many concurrent streams. The context readahead can adapt readahead size to thrashing threshold well. So in p... 23 Feb 2010 22:44
disk/crypto performance regression 2.6.31 -> 2.6.32 (mmap problem?) M> You're right, it doesn't say that anymore in 2.6.31, so I think I'm M> indeed running with barriers on. When barriers were added to ext4, I saw a similar slowdown on lock- and sync- heavy workloads. Based on a recent thread on the ext4 list I've started using deadline rather than cfq on that disk. There a... 23 Feb 2010 21:37
[patch 3/3] jffs2: Fixup rb_root initializations to use RB_ROOT jffs2 uses rb_node = NULL; to zero rb_root. The problem with this is that 17d9ddc72fb8bba0d4f678 in the linux-next tree adds a new field to that struct which needs to be NULLas well. This patch uses RB_ROOT as the intializer so all of the relevant fields will be NULL'd. Signed-off-by: Venkatesh Pallipadi <venkat... 23 Feb 2010 21:37
[patch 0/3] Fixup rb_root initializations to use RB_ROOT Eric Paris found a problem with rb_root initializations and sent a patch to fix it here: http://lkml.indiana.edu/hypermail/linux/kernel/1002.2/02946.html btrfs: use RB_ROOT to intialize rb_trees instead of setting rb_node to NULL Based on that, a simple grep for "rb_node = NULL" showed few more similar usages in... 23 Feb 2010 21:37
[patch 1/3] ext4: Fixup rb_root initializations to use RB_ROOT ext4 uses rb_node = NULL; to zero rb_root at few places. The problem with this is that 17d9ddc72fb8bba0d4f678 in the linux-next tree adds a new field to that struct which needs to be NULLas well. This patch uses RB_ROOT as the intializer so all of the relevant fields will be NULL'd. Signed-off-by: Venkatesh Pall... 23 Feb 2010 21:37
[patch 2/3] ext3: Fixup rb_root initializations to use RB_ROOT ext3 uses rb_node = NULL; to zero rb_root. The problem with this is that 17d9ddc72fb8bba0d4f678 in the linux-next tree adds a new field to that struct which needs to be NULLas well. This patch uses RB_ROOT as the intializer so all of the relevant fields will be NULL'd. Signed-off-by: Venkatesh Pallipadi <venkate... 23 Feb 2010 21:37 |