linux-kernel mailing list

FromSubjectsort iconDate
Nick Piggin
Re: General slowness with using 64Gb HIGHMEM option on 32-bi...
If you have a gcc that can compile 64-bit code, then I found it was as simple as doing a 'make ARCH=x86_64' and building the kernel with 32-bit program support. -
Sep 27, 11:22 pm 2007
Nick Piggin
Re: [PATCH 05/12] mm: trylock_page
I have such a thing queued too, for the lock bitops patches for when 2.6.24 opens, Andrew promises me :). I guess they should be identical, except I don't like doing trylock_page in place of SetPageLocked, for memory ordering performance and aesthetic reasons... I've got an init_page_locked (or set_page_locked... I can't remember, the patch is at home). Fine idea to lockdep the page lock, anyway. Does it show up any of the buffered write deadlock possibilities? :) buffer lock is another nota...
Sep 27, 11:11 pm 2007
Anna Csilla
Anna, Csilla
Szia! Oszinte leszek! En egy spam vagyok ... igen megint egy levelszemet. Mar akinek szemet ... ha ugy erzed irj vissza, kuldj el a fenebe ... de kenyszert erzek hogy tudassam veled az alabbiakat: Van egy oldal ahol perverz szexfilmek vannak igen perverzek ... sot meg allatok is felbukkannak itt ott egy ket filmben ... ha erdekel klikk ra: http://xxx.bnh.hu ja igen es ha hiszed hanem tenyleg vannak fenn filmek rollam. Van egy par jo jatek is ami magyar nyelvu es erdekelhet: MAGY...
Sep 27, 9:52 am 2007
Neil Brown
Re: [patch 2/2] VFS: allow filesystem to override mknod capa...
I must admit that I don't feel very comfortable about this. I wonder how many more flags we might be tempted to add to allow user-controlled filesystems to do interesting things. Somehow I doubt this will be the last, so we should be very careful allowing it to be the first (or is it the second already?) A more concrete comment on the patch: Is it really necessary to introduce IS_MNT_NODEV?? Why not simply test both the flags (MS_MKNOD_NOCAP and MNT_NODEV) before allowing the mknod? That wou...
Sep 27, 10:40 pm 2007
linux
2.6.23-rc8 network problem. Mem leak? ip1000a?
Uniprocessor Althlon 64, 64-bit kernel, 2G ECC RAM, 2.6.23-rc8 + linuxpps (5.0.0) + ip1000a driver. (patch from http://marc.info/?l=linux-netdev&m=118980588419882) After a few hours of operation, ntp loses the ability to send packets. sendto() returns -EAGAIN to everything, including the 24-byte UDP packet that is a response to ntpq. -EAGAIN on a sendto() makes me think of memory problems, so here's meminfo at the time: ### FAILED state ### # cat /proc/meminfo MemTotal: 2059384 kB ...
Sep 27, 10:06 pm 2007
Dave Airlie
[PATCH] i915: make vbl interrupts work properly on i965g/gm
Hi Linus, The attached patch is to fix a bug reported on 965gm chipsets (lots of new laptops), I think distros will all have to patch this in to fix it, so can we get it into the 2.6.23 final? (Otherwise I'll wait until stable..) Dave.
Sep 27, 10:05 pm 2007
Jesse Barnes
Re: [PATCH] i915: make vbl interrupts work properly on i965g...
Without this patch, my 965GM drops vblank interrupts, so I'd really like to see it upstream ASAP too. Acked-by: Jesse Barnes <jesse.barnes@intel.com> -
Sep 27, 10:09 pm 2007
Benjamin Herrenschmidt
iwl4965 and driver merging policy
Hi ! Just a little question in the light of the discussion we had at Kernel Summit about merging drivers upstream (and here, I strongly agree with Linus, hence my message). I just got that new T61 laptop which happens to have an iwl4xxx chip. The distro I installed on it (ubuntu) has a driver for it. I suspect others do too and most users get it from some random external tree and use it. Thus my question, why are we about to release 2.6.23 without it ? It doesn't seem to pull any depedency ...
Sep 27, 9:39 pm 2007
John W. Linville
Re: iwl4965 and driver merging policy
You must not have been watching me SPAM netdev for the past two It is queued for 2.6.24. I'm not even sure it was originally posted in time for the 2.6.23 merge window, but even if it was there was a lot of opposition to merging it until fairly recently. In fact, I'm sure there are still some wireless developers that are less than happy about merging it now. Anyway, coming soon to a kernel near you... John -- John W. Linville linville@tuxdriver.com -
Sep 27, 10:30 pm 2007
Benjamin Herrenschmidt
Re: iwl4965 and driver merging policy
Allright, thanks. I was mostly trying to figure out where we standed with this whole idea that driver additions were not necessarily constrainted by the merge window (which I think is fair to do) and this looked like a good example to pick since it affects my new laptop :-) Out of curiosity, what's the main source of opposition ? Since it's being shipped by distro or built out of tree by most users -anyway-, I think it's pretty clear that we'd be better off having it merged asap rather than try...
Sep 27, 11:15 pm 2007
Theodore Tso
Re: iwl4965 and driver merging policy
Well, pulling in iwlwifi would require also pulling in the mac80211 subsystem, so it's not quite that simple (although I'm not sure what's holding back that going into the kernel.) I had no problem building my personal production kernel by taking 2.6.23-rc8, and doing a git pull from the everything branch in John Linville's wireless-dev git tree. It's probably too late to pull it for 2.6.23-rc8 (although if Linux wanted to do it it's only one git pull command away :-), but it would be really nic...
Sep 27, 10:47 pm 2007
Benjamin Herrenschmidt
Re: iwl4965 and driver merging policy
I though that was already in 2.6.23 ... my bad if I missed something Yes, I agree -rc8 seems to be a tad too late, I'm just surprised we didn't get it in earlier though since it seems it's been around and useable for some time. Cheers, Ben. -
Sep 27, 11:07 pm 2007
akepner
[4/4] mthca: allow setting "dmabarrier" on user-allocated me...
Use the dma_flags_set_dmabarrier() interface to allow a "dmabarrier" attribute to be associated with user-allocated memory. (For now, it's only implemented for mthca.) Signed-off-by: Arthur Kepner <akepner@sgi.com> --- drivers/infiniband/core/umem.c | 7 +++++-- drivers/infiniband/hw/amso1100/c2_provider.c | 2 +- drivers/infiniband/hw/cxgb3/iwch_provider.c | 2 +- drivers/infiniband/hw/ehca/ehca_mrmw.c | 2 +- drivers/infiniband/hw/ipath/ipath_mr.c ...
Sep 27, 9:13 pm 2007
akepner
[3/4] dma: document dma_flags_set_dmabarrier()
Document dma_flags_set_dmabarrier(). Signed-off-by: Arthur Kepner <akepner@sgi.com> --- DMA-API.txt | 26 ++++++++++++++++++++++++++ 1 files changed, 26 insertions(+) diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index cc7a8c3..5fc0bba 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -544,3 +544,29 @@ size is the size (and should be a page-sized multiple). The return value will be either a pointer to the processor virtual address of...
Sep 27, 9:13 pm 2007
Grant Grundler
Re: [3/4] dma: document dma_flags_set_dmabarrier()
This looks really good! thanks, grant -
Sep 27, 11:33 pm 2007
akepner
[2/4] dma: redefine dma_flags_set_dmabarrier() for sn-ia64
define dma_flags_set_dmabarrier() for sn-ia64 - it "borrows" bits from the direction argument (renamed "flags") to the dma_map_* routines to pass an additional "dmabarrier" attribute. Also define routines to retrieve the original direction and attribute from "flags". Signed-off-by: Arthur Kepner <akepner@sgi.com> --- arch/ia64/sn/pci/pci_dma.c | 35 ++++++++++++++++++++++++++--------- include/asm-ia64/sn/io.h | 24 ++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 9 del...
Sep 27, 9:12 pm 2007
akepner
[1/4] dma: add dma_flags_set_dmabarrier() to dma interface
Introduce the dma_flags_set_dmabarrier() interface and give it a default no-op implementation. Signed-off-by: Arthur Kepner <akepner@sgi.com> --- dma-mapping.h | 6 ++++++ 1 files changed, 6 insertions(+) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 2dc21cb..4d1d199 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -99,4 +99,10 @@ static inline void dmam_release_declared_memory(struct device *dev) } #endif /* ARCH...
Sep 27, 9:10 pm 2007
akepner
[PATCH 0/4] allow drivers to flush in-flight DMA v2
On Altix, DMA may be reordered between a device and host memory. This reordering can happen in the NUMA interconnect, and it usually results in correct operation and improved performance. In some situations it may be necessary to explicitly synchronize DMA from the device. This patchset allows a memory region to be mapped with a "dmabarrier". Writes to the memory region will cause in-flight DMA to be flushed, providing a mechanism to order DMA from a device. There are 4 patches in this p...
Sep 27, 9:09 pm 2007
roel
[PATCH] removes array_size duplicates
This patch removes some ARRAY_SIZE macro duplicates. There is also one in arch/um/include/user.h, which isn't fixed here because comments in that file explicitly state a preference for the 'less fancy' version. If that's the case as well for any of the other replacements please comment. Signed-off-by: Roel Kluin <12o3l@tiscali.nl> --- Documentation/spi/spidev_test.c | 2 -- arch/i386/boot/compressed/relocs.c | 1 - arch/m68k/amiga/amisound.c | 3 +-- arch/powerpc/boot...
Sep 27, 6:51 pm 2007
H. Peter Anvin
More E820 brokenness
As luck would have it, it's not just an obscure Geode system which has a broken E820 implementation. Today I received a bug report about a Dell system (XPS M1330) with broken E820. Unfortunately, the workaround for the Geode breaks this system, because x86-64 doesn't fall back to the e801/88 information like the i386 kernel does. I wonder if the relevant people could test out this patch to see how it works on their respective system. This patch reverts to 2.6.23-rc8 behaviour of simply truncat...
Sep 27, 6:17 pm 2007
Jordan Crouse
Re: More E820 brokenness
Breaks on the Geode - original behavior. I think that having boot_prams.e820_entries != 0 makes the kernel I'm inclined to agree. Jordan -
Sep 27, 6:33 pm 2007
H. Peter Anvin
Re: More E820 brokenness
Okay, now I'm utterly baffled how 2.6.22 ever worked on this Geode, because this, to the best of my reading, mimics the 2.6.22 behavior exactly. DID IT REALLY, and/or did you make any kind of configuration Arguably the right thing to do is to find the responsible BIOS engineer and shoot them, but that's hard to do without robotics. -hpa -
Sep 27, 6:47 pm 2007
Jordan Crouse
Re: More E820 brokenness
I copied in a 2.6.22 kernel to see that it really did work, and it did. But here's the crazy part - I did a dmesg, and it looks like it *is* using e820 data, and it looks complete (I see the entire map - including the ACPI and reserved blocks way up high). So apparently it was the 2.6.22 code that was buggy, but reading it, I don't immediately see how. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -
Sep 27, 7:15 pm 2007
H. Peter Anvin
Re: More E820 brokenness
Oh bugger, looks like this one might be genuinely my fault after all. The ID check in the new code is buggy. Can you please test this revised patch out (against current -git)? -hpa
Sep 27, 7:27 pm 2007
Jordan Crouse
Re: More E820 brokenness
That looks the same as the previous patch you sent? Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -
Sep 27, 7:34 pm 2007
H. Peter Anvin
Re: More E820 brokenness
Sorry, this is the right one... -hpa
Sep 27, 7:36 pm 2007
Jordan Crouse
Re: More E820 brokenness
Worked, but that just raises more questions. Why didn't more x86 boxes break or, alternatively, why did a new version of the BIOS fix the problem? I guess we shouldn't look a gift horse in the mouth. Or something. Thanks very much for your help. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -
Sep 27, 7:54 pm 2007
H. Peter Anvin
Re: More E820 brokenness
Why didn't more x86 boxes break... well, it's pretty natural an implementation of the BIOS to not clobber registers that aren't outputs. Arguably the BIOSes that do are still buggy, since there isn't a well-defined calling sequence for the BIOS and the convention that has evolved is "don't clobber anything unless it's an output." It's still wrong, however, especially since it means omitting the *real* SMAP check. -hpa -
Sep 27, 8:12 pm 2007
H. Peter Anvin
Re: More E820 brokenness
Was this a stock 2.6.22 kernel, or might it have been modified? There is, of course, also the possibility that triggering the BIOS bug in your case depends on some delicate combination of input state. -hpa -
Sep 27, 7:22 pm 2007
Thomas Gleixner
[PATCH] clockevents: fix bogus next_event reset for oneshot ...
In periodic broadcast mode the next_event member of the broadcast device structure is set to KTIME_MAX in the interrupt handler. This is wrong, as we calculate the next periodic interrupt with this variable. Remove it. Noticed by Ralf. MIPS is the first user of this mode, it does not affect existing users. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-and-tested-by: Ralf Baechle <ralf@linux-mips.org> --- diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-br...
Sep 27, 6:17 pm 2007
Zan Lynx
2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftru...
Kernel 2.6.23-rc8-mm2 on a AMD-64, filesystems mounted are reiserfs, reiser4 and tmpfs. netconsole dmesg output and .config are included below. Near the end of my boot sequence, there is a kernel error. I am not sure exactly what user-space is doing to make this happen, but I know that a simple shell and some filesystem operations do not cause it. This error also occurred in 2.6.23-rc8-mm1 but I didn't have time to post it and hoped it would just go away. I never tested 2.6.23-rc7-mm*, and the...
Sep 27, 5:54 pm 2007
roel
[PATCH] spin_lock_unlocked cleanups
Replace some SPIN_LOCK_UNLOCKED with DEFINE_SPINLOCK Signed-off-by: Roel Kluin <12o3l@tiscali.nl> --- diff --git a/arch/mips/pci/ops-pmcmsp.c b/arch/mips/pci/ops-pmcmsp.c index 09fa007..059eade 100644 --- a/arch/mips/pci/ops-pmcmsp.c +++ b/arch/mips/pci/ops-pmcmsp.c @@ -206,7 +206,7 @@ static void pci_proc_init(void) } #endif /* CONFIG_PROC_FS && PCI_COUNTERS */ -spinlock_t bpci_lock = SPIN_LOCK_UNLOCKED; +DEFINE_SPINLOCK(bpci_lock); /************************************...
Sep 27, 5:36 pm 2007
Mark Lord
Problems with SMP & ACPI powering off
Question: do we disable all CPUs except 0 when doing ACPI power off? Background: I have a machine here dedicated to running MythTV. It powers up to record, and then sets the RTC alarm for next time and powers down again in between recordings. It has an Intel Core2duo E6300 CPU, currently on an ICH8 motherboard. Previously it was on a completely different (vendor,bios,...) ICH7 motherboard. In both cases, "halt -p" sometimes fails to actually turn off the power, which means that it later then ...
Sep 27, 5:29 pm 2007
Rafael J. Wysocki
Re: Problems with SMP & ACPI powering off
May be. Same chipset, perchance? Greetings, Rafael -
Sep 27, 6:00 pm 2007
Mark Lord
Re: Problems with SMP & ACPI powering off
Latest 2.6.23-rc-git. Same problem from time to time on 2.6.17, as well. Dunno about in between those Revs., but it's much more common on the latest Mmmm I originally didn't think so. But actually one board is ICH8, the other ICH8R, so yes, they use the same chipset. Cheers -
Sep 27, 7:07 pm 2007
Mark Lord
Re: Problems with SMP & ACPI powering off
Oh, and two different power-supplies, too. -ml -
Sep 27, 5:30 pm 2007
Vegard Nossum
[RFC] New kernel-message logging API (take 2)
Hello, A big thanks to everybody who read and replied to my first e-mail; I have tried my best to incorporate your feedback and suggestions. I also added some CCs who recently participated in logging-related discussions. Changes (since Sept. 22): * Extensibility -> Allowing the compiler to eliminate messages below a certain threshold requires changing the API. * Add some special-purpose logging functions (printk_detected(), _registered(), _settings(), and _copyright()) * F...
Sep 27, 5:18 pm 2007
linux
Re: [RFC] New kernel-message logging API (take 2)
Assuming that kprint_block_flush() is a combination of kprint_block_printit() and kprint_block_abort(), you coulld make a macro wrapper for this to preclude leaks: #define KPRINT_BLOCK(block, level, code) \ do { \ struct kprint_block block; \ kprint_block_init(&block, KPRINT_##level); \ do { \ code ; \ kprint_block_printit(&block); \ while (0); \ kprint_block_abort(&block); \ } while(0) The inner do { } while(0) region is so you can abort with "break". (Or you can ...
Sep 27, 9:38 pm 2007
Rik van Riel
[PATCH] kswapd should only wait on IO if there is IO
The current kswapd (and try_to_free_pages) code has an oddity where the code will wait on IO, even if there is no IO in flight. This problem is notable especially when the system scans through many unfreeable pages, causing unnecessary stalls in the VM. Signed-off-by: Rik van Riel <riel@surriel.com> diff -up linux-2.6.22.x86_64/mm/vmscan.c.wait linux-2.6.22.x86_64/mm/vmscan.c --- linux-2.6.22.x86_64/mm/vmscan.c.wait 2007-09-25 11:33:30.000000000 -0400 +++ linux-2.6.22.x86_64/mm/vmscan.c 20...
Sep 27, 5:08 pm 2007
Andrew Morton
Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 17:08:16 -0400 The comparison with swap_cluster_max is unobvious, and merits a comment. What is the thinking here? Also, we now have this: if (total_scanned > sc.swap_cluster_max + sc.swap_cluster_max / 2) { wakeup_pdflush(laptop_mode ? 0 : total_scanned); sc.may_writepage = 1; } /* Take a nap, wait for some writeback to complete */ if (sc.nr_scanned && priority < DEF_PRIORITY - 2 && sc.nr_io_pages > sc.swap_cluste...
Sep 27, 5:47 pm 2007
Rik van Riel
Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 14:47:02 -0700 Kswapd was no longer sitting in "D" state as often and pages got freed more promptly. The test was done on a RHEL kernel with this change though - I guess I should redo it with a current upstream If the number of pages undergoing IO is really small, waiting for them may be a waste of time. Actually, nr_io_pages is also incremented when we run into pages that It is incrementing sc.nr_io_pages and will wait on IO to complete if the amount of pages in fligh...
Sep 27, 6:13 pm 2007
Andrew Morton
Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 18:13:25 -0400 The thinking sounds good to me, but I'm looking for weirdo side-effects in corner cases. And I'm trying to work out what actual design we want to Buggered if I know ;) It may have the accidental effect that it opens a window in which some may_enter_fs-capable process can get scheduled and do some writeout, OK, thanks. Perhaps a few words tacked onto the nr_io_pages definition yup, I didn't think of that. Hopefully someone else will be in there work...
Sep 27, 6:21 pm 2007
Rik van Riel
Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 15:21:21 -0700 if (PageDirty(page)) { if (sc->order <= PAGE_ALLOC_COSTLY_ORDER && referenced) goto keep_locked; if (!may_enter_fs) goto keep_locked; I think we can fix that problem by adding a sc->nr_io_pages++ between the last if and the goto keep_locked in shrink_page_list. That way !GFP_IO or !GFP_FS tasks will cause themselves ...
Sep 27, 6:50 pm 2007
Andrew Morton
Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 18:50:27 -0400 As did that one. Ho hum :( Maybe it's in the git history somewhere. -
Sep 27, 6:59 pm 2007
Rik van Riel
Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 15:59:07 -0700 Good point. The current kswapd (and try_to_free_pages) code has an oddity where the code will wait on IO, even if there is no IO in flight. This problem is notable especially when the system scans through many unfreeable pages, causing unnecessary stalls in the VM. Additionally, tasks without __GFP_FS or __GFP_IO in the direct reclaim path will sleep if a significant number of pages are encountered that should be written out. This gives kswapd a chance to w...
Sep 27, 7:08 pm 2007
David Rientjes
[patch 1/2] pci: use size stored in proc_dir_entry for proc ...
On pci_proc_attach_device(), the size of the PCI configuration space is stored in the proc_dir_entry as the size of the file. Thus, the procfs interface to PCI devices should use it instead of the device directly. Signed-off-by: David Rientjes <rientjes@google.com> --- drivers/pci/proc.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c --- a/drivers/pci/proc.c +++ b/drivers/pci/proc.c @@ -60,7 +60,7 @@ proc_bus_pci_read(...
Sep 27, 4:41 pm 2007
David Rientjes
[patch 2/2] pci: write file size to inode on proc bus file w...
When a /proc/bus/pci file is written to, the size of that PCI device's configuration space must be written to the inode. Otherwise, it is possible for the file to specify a size of 0 on stat if a task is holding the same file open. Signed-off-by: David Rientjes <rientjes@google.com> --- drivers/pci/proc.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c --- a/drivers/pci/proc.c +++ b/drivers/pci/proc.c @@ -129,7 +129,7 @...
Sep 27, 4:41 pm 2007
Administrator
[MailServer Notification]Attachment Blocking Notification
Warning to Recipient: Action taken by attachment blocking. -
Sep 27, 4:24 pm 2007
Dmitry Tyschenko
NO_HZ hangs up AMD MK-36
Hello, I have laptop Asus X50M. Using old Debian Etch from February. Kernel from 2.6.21 doesn't boot, hangs up just in 10seconds - 1minute after GRUB screen. I have tryed different versions of gcc (4.1.1, 4.1.2, 4.2.1) to build 2.6.22.8 kernel, but no results. But if I disable NO_HZ option 2.6.21 is working fine for me. I think this is important problem, because some of the project, Debian for example, are building kernel with this options enabled (in linux-image-2.6.22-1-k7 package it is en...
Sep 27, 4:28 pm 2007
Rafael J. Wysocki
Re: NO_HZ hangs up AMD MK-36
You can use the "nohz=off" kernel command line switch. Please check if it works for you. Greetings, Rafael -
Sep 27, 4:59 pm 2007
previous daytodaynext day
September 26, 2007September 27, 2007September 28, 2007