Re: 2.6.18-stable release plans?
On 22/01/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote: Is there going to be another 2.6.18-stable release? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Now that 2.6.19 is out, most likely not. -stable releases are made for the latest stable 2.6.x kernel, once 2.6.x+1 is out that's the one -stable patches are made for (2.6.16 is an exception).. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How can I create or read/write a file in linux device driver?
On 12/01/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: On Jan 12 2007 11:27, Jesper Juhl wrote: > On 12/01/07, congwen <[EMAIL PROTECTED]> wrote: >> Hello everyone, I want to create and read/write a file in Linux kernel or >> device driver, > > Don't read/write user space files from kernel space. > > Please search the archives, this get asked a lot and it has been > explained a million times why it's a bad idea. > You can also read http://www.linuxjournal.com/article/8110 The article does it the bad way. IMHO filp_open() and vfs_read/vfs_write() are much less problematic wrt. to userspace. FWIW see ftp://ftp-1.gwdg.de/pub/linux/misc/suser-jengelh/kernel/quad_dsp-1.5.1.tar.bz2 There is no good way. You simply should NOT do it. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How can I create or read/write a file in linux device driver?
On 12/01/07, congwen <[EMAIL PROTECTED]> wrote: Hello everyone, I want to create and read/write a file in Linux kernel or device driver, Don't read/write user space files from kernel space. Please search the archives, this get asked a lot and it has been explained a million times why it's a bad idea. You can also read http://www.linuxjournal.com/article/8110 -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Jumping into Kernel development: About -rc kernels...
On 09/01/07, Akula2 <[EMAIL PROTECTED]> wrote: Hello All, This question might sound dumb for many, and to some annoying too ;-) Am enterting into -rc Kernel (testing & analysis) & involvement with the kernel (contributing to patches). I have this doubt. I did refer to applying-patches in the kernel documentation, this is what I got:- > These are the base stable releases released by Linus. The highest numbered > release is the most recent. > If regressions or other serious flaws are found, then a -stable fix patch > will be released (see below) on top of this base. Once a new 2.6.x base > kernel is released, a patch is made available that is a delta between the > previous 2.6.x kernel and the new one. > To apply a patch moving from 2.6.11 to 2.6.12, you'd do the following (note > that such patches do *NOT* apply on top of 2.6.x.y kernels but on top of the > base 2.6.x kernel -- if you need to move from 2.6.x.y to 2.6.x+1 you need to > first revert the 2.6.x.y patch). I did understand till here. Should I start compile/test/debug one-after-one in this fashion:- 2.6.19 source + patch-2.6.20-rc1 2.6.19 source + patch-2.6.20-rc2 2.6.19 source + patch-2.6.20-rc3 2.6.19 source + patch-2.6.20-rc4 OR Pick the latest release number? Depends on what you want to do. If you want a stable kernel to use in production you should probably pick the latest stable kernel (currently that's 2.6.19.1). If you want to help fix bugs, develop features, test etc, then it is usually best to use the latest development snapshot available. An easy way to always have the tip of the tree available is to use git - see this document for more info : http://linux.yyz.us/git-howto.html -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gaming Interface
On 09/01/07, Dirk <[EMAIL PROTECTED]> wrote: Jan Dittmer wrote: > Dirk wrote: >> Alright. I came to discuss an idea I had because I realized that >> installing Windows and running Linux in VMware is the only _fun_ way to >> play "real" Games and have Linux at the same time. >> >> And everyone who says I'm a troll doesn't like Games or simple things. > > That's not true, see wine/cedega for a linux direct-x implementation. > Works wonders with most of the current games and copy protections. > I tried to get WoW installed with Cedega 5.2.9 for two days now. Cedega is not a replacement for ports. And it does not encourage ports. I'm playing WoW on Slackware Linux 11 with a 2.6.18.6 kernel and wine 0.9.28 and it works just fine. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux/slab.h: new KFREE() macro.
On 08/01/07, Amit Choudhary <[EMAIL PROTECTED]> wrote: --- Pekka Enberg <[EMAIL PROTECTED]> wrote: > On 1/8/07, Hua Zhong <[EMAIL PROTECTED]> wrote: > > > And as I explained, it can result in longer code too. So, why > > > keep this value around. Why not re-initialize it to NULL. > > > > Because initialization increases code size. > > And it also effectively blocks the slab debugging code from doing its > job detecting double-frees. > Man, so you do want someone to set 'x' to NULL after freeing it, so that the slab debugging code can catch double frees. If you set it to NULL then double free is harmless. No, setting the pointer to NULL doesn't make a double free harmless it just hides a bug. The real fix would be to remove the double free. If you just set the pointer to NULL and ignore the double free then you've just bloated the kernel with an extra pointless assignment and left a kfree() call in the kernel that should not be there. In my book that's a bug. If instead you rework the code to avoid the double free, then you avoid the pointless NULL assignment and you get rid of a kfree call, and you also get to review the logic and find the flaw that lead to a double free in the first place. A double free is not something we should just sweep under the carpet and forget about, it's very likely an indication that some logic is flawed and should be fixed. This KFREE macro does not belong in the kernel IMHO. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove a couple final references to obsolete verify_area().
On 08/01/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: Remove a couple final references to the obsolete verify_area() call, which was long ago replaced by access_ok(). Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- it *appears* that these last two references can be removed, unless there's something really strange i'm not seeing here. The AVR32 code went in roughly a month after I did the last verify_area() cleanup patch, so I missed these bits. The patch looks sane to me, so feel free to add Acked-by: Jesper Juhl <[EMAIL PROTECTED]> -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups
On 07/01/07, Ahmed S. Darwish <[EMAIL PROTECTED]> wrote: On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote: > On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote: > > > Hi all, > > I'm not able to find the DAC960 block driver maintainer. If someones knows > > please reply :). > > It's orphaned. Andrew can decide to merge this, or one of the > storage or block maintainers could possibly do that. > or it could go thru KJ, but then Andrew may still end up > merging it. Should Kernel janitors then care of cleaning orphaned files ?. If so, I should forward it to Andrew Morton without CCing LKML again, right ? Sending the patch to LKML and Cc'ing Andrew and KJ would be my approach. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups
On 07/01/07, Ahmed S. Darwish <[EMAIL PROTECTED]> wrote: On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote: > On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote: > > > Hi all, > > I'm not able to find the DAC960 block driver maintainer. If someones knows > > please reply :). > > It's orphaned. Andrew can decide to merge this, or one of the > storage or block maintainers could possibly do that. > or it could go thru KJ, but then Andrew may still end up > merging it. Should Kernel janitors then care of cleaning orphaned files ?. If so, I should forward it to Andrew Morton without CCing LKML again, right ? Sending the patch to LKML and Cc'ing Andrew and KJ would be my approach. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: open(O_DIRECT) on a tmpfs?
On 05/01/07, Jesper Juhl <[EMAIL PROTECTED]> wrote: On 04/01/07, Hua Zhong <[EMAIL PROTECTED]> wrote: > > I see that as a good argument _not_ to allow O_DIRECT on > > tmpfs, which inevitably impacts cache, even if O_DIRECT were > > requested. > > > > But I'd also expect any app requesting O_DIRECT in that way, > > as a caring citizen, to fall back to going without O_DIRECT > > when it's not supported. > > According to "man 2 open" on my system: > >O_DIRECT > Try to minimize cache effects of the I/O to and from this file. > In general this will degrade performance, but it is useful in > special situations, such as when applications do their own > caching. File I/O is done directly to/from user space buffers. > The I/O is synchronous, i.e., at the completion of the read(2) > or write(2) system call, data is guaranteed to have been trans- > ferred. Under Linux 2.4 transfer sizes, and the alignment of > user buffer and file offset must all be multiples of the logi- > cal block size of the file system. Under Linux 2.6 alignment to > 512-byte boundaries suffices. > A semantically similar interface for block devices is described > in raw(8). > > This says nothing about (probably disk based) persistent backing store. I don't see why tmpfs has to conflict with it. > > So I'd argue that it makes more sense to support O_DIRECT on tmpfs as the memory IS the backing store. > I'd agree. O_DIRECT means data will go direct to backing store, so if RAM *is* the backing store as in the tmpfs case, then I see why O_DIRECT should fail for it... Whoops, that should of course have read " then I *DON'T* see why O_DIRECT should fail" . -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: open(O_DIRECT) on a tmpfs?
On 04/01/07, Hua Zhong <[EMAIL PROTECTED]> wrote: > I see that as a good argument _not_ to allow O_DIRECT on > tmpfs, which inevitably impacts cache, even if O_DIRECT were > requested. > > But I'd also expect any app requesting O_DIRECT in that way, > as a caring citizen, to fall back to going without O_DIRECT > when it's not supported. According to "man 2 open" on my system: O_DIRECT Try to minimize cache effects of the I/O to and from this file. In general this will degrade performance, but it is useful in special situations, such as when applications do their own caching. File I/O is done directly to/from user space buffers. The I/O is synchronous, i.e., at the completion of the read(2) or write(2) system call, data is guaranteed to have been trans- ferred. Under Linux 2.4 transfer sizes, and the alignment of user buffer and file offset must all be multiples of the logi- cal block size of the file system. Under Linux 2.6 alignment to 512-byte boundaries suffices. A semantically similar interface for block devices is described in raw(8). This says nothing about (probably disk based) persistent backing store. I don't see why tmpfs has to conflict with it. So I'd argue that it makes more sense to support O_DIRECT on tmpfs as the memory IS the backing store. I'd agree. O_DIRECT means data will go direct to backing store, so if RAM *is* the backing store as in the tmpfs case, then I see why O_DIRECT should fail for it... I often use tmpfs when I want to test new setups - it's easy to get rid of again and it's fast during testing. Why shouldn't I be able to test apps that use O_DIRECT this way? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
I get this message in my webservers (with NFS mounted homedirs) logs once in a while : kernel: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... It doesn't seem to have any bad effect on anything, but it would be nice to know if there is any cause for concern. The NFS server is running 2.6.18.1 and the webservers are running 2.6.17.8 -- Jesper Juhl <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NMI Watchdog detected LOCKUP
: 0 siblings: 2 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr bogomips: 6400.68 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: # cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 15 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: ProcessorANSI SCSI revision: 02 Host: scsi0 Channel: 02 Id: 08 Lun: 00 Vendor: IBM Model: 39M6750a S320 0 Rev: 1 Type: ProcessorANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 02 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 03 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 15 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: ProcessorANSI SCSI revision: 02 Host: scsi1 Channel: 01 Id: 15 Lun: 00 Vendor: IBM Model: EXP400 S320Rev: D110 Type: ProcessorANSI SCSI revision: 03 Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 01 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 02 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 03 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 04 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 05 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 06 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 15 Lun: 00 Vendor: IBM Model: SERVERAIDRev: 1.00 Type: ProcessorANSI SCSI revision: 02 Host: scsi2 Channel: 01 Id: 15 Lun: 00 Vendor: IBM Model: EXP400 S320Rev: D110 Type: ProcessorANSI SCSI revision: 03 -- Kind regards, Jesper Juhl <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Kernel Hacker's guide to git
On 21/12/06, Jeff Garzik <[EMAIL PROTECTED]> wrote: I refreshed my git intro/cookbook for kernel hackers, at http://linux.yyz.us/git-howto.html This describes most of the commands I use in day-to-day kernel hacking. Let me know if there are glaring errors or missing key commands. Very nice. A bit on how to revert a commit and how to rebase a branch would make it even nicer :) Thank you for a very good document, Jeff. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On 20/12/06, Peter Zijlstra <[EMAIL PROTECTED]> wrote: On Wed, 2006-12-20 at 12:39 +0100, Jesper Juhl wrote: > Having the assignment of "ret = 1;" inside the loop seems a little > pointless. Perhaps gcc can optimize it, but still, that assignment > really only needs to happen once outside the loop. Sure, but I was hoping gcc was smart enough. Placing it outside the loop would require an extra if stmt. Also the chance this loop will actually be traversed more than once is _very_ small. allright - I just spotted it and thought I'd point it out :-) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On 20/12/06, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
fix page_mkclean_one()
it had several issues:
- it failed to flush the cache
- it failed to flush the tlb
- it failed to do s390 (s390 guys, please verify this is now correct)
Also, clear in a loop to ensure SMP safeness as suggested by Arjan.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
mm/rmap.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
Index: linux-2.6/mm/rmap.c
===
--- linux-2.6.orig/mm/rmap.c
+++ linux-2.6/mm/rmap.c
@@ -432,7 +432,7 @@ static int page_mkclean_one(struct page
{
struct mm_struct *mm = vma->vm_mm;
unsigned long address;
- pte_t *pte, entry;
+ pte_t *ptep;
spinlock_t *ptl;
int ret = 0;
@@ -440,22 +440,23 @@ static int page_mkclean_one(struct page
if (address == -EFAULT)
goto out;
- pte = page_check_address(page, mm, address, &ptl);
- if (!pte)
+ ptep = page_check_address(page, mm, address, &ptl);
+ if (!ptep)
goto out;
- if (!pte_dirty(*pte) && !pte_write(*pte))
- goto unlock;
-
- entry = ptep_get_and_clear(mm, address, pte);
- entry = pte_mkclean(entry);
- entry = pte_wrprotect(entry);
- ptep_establish(vma, address, pte, entry);
- lazy_mmu_prot_update(entry);
- ret = 1;
+ while (pte_dirty(*ptep) || pte_write(*ptep)) {
+ pte_t entry = ptep_get_and_clear(mm, address, ptep);
+ flush_cache_page(vma, address, pte_pfn(entry));
+ flush_tlb_page(vma, address);
+ (void)page_test_and_clear_dirty(page); /* do the s390 thing */
+ entry = pte_wrprotect(entry);
+ entry = pte_mkclean(entry);
+ set_pte_at(vma, address, ptep, entry);
+ lazy_mmu_prot_update(entry);
+ ret = 1;
+ }
Having the assignment of "ret = 1;" inside the loop seems a little
pointless. Perhaps gcc can optimize it, but still, that assignment
really only needs to happen once outside the loop.
-unlock:
- pte_unmap_unlock(pte, ptl);
+ pte_unmap_unlock(ptep, ptl);
out:
return ret;
}
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] NFS: Kill the obsolete NFS_PARANOIA
Linus,
This patch has been both compile and run-time tested.
It has been in -mm for quite a while without problems.
Trond & Andrew have both signed off on it.
Please apply.
Remove obsolete NFS_PARANOIA.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Acked-by: Trond Myklebust <[EMAIL PROTECTED]>
---
fs/nfs/dir.c | 17 ++---
fs/nfs/getroot.c |1 -
fs/nfs/inode.c|3 ---
fs/nfs/nfs2xdr.c |1 -
fs/nfs/pagelist.c |7 ---
5 files changed, 2 insertions(+), 27 deletions(-)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index dee3d6c..8b71075 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -38,7 +38,6 @@ #include "nfs4_fs.h"
#include "delegation.h"
#include "iostat.h"
-#define NFS_PARANOIA 1
/* #define NFS_DEBUG_VERBOSE 1 */
static int nfs_opendir(struct inode *, struct file *);
@@ -1322,11 +1321,6 @@ static int nfs_sillyrename(struct inode
atomic_read(&dentry->d_count));
nfs_inc_stats(dir, NFSIOS_SILLYRENAME);
-#ifdef NFS_PARANOIA
-if (!dentry->d_inode)
-printk("NFS: silly-renaming %s/%s, negative dentry??\n",
-dentry->d_parent->d_name.name, dentry->d_name.name);
-#endif
/*
* We don't allow a dentry to be silly-renamed twice.
*/
@@ -1641,16 +1635,9 @@ static int nfs_rename(struct inode *old_
new_inode = NULL;
/* instantiate the replacement target */
d_instantiate(new_dentry, NULL);
- } else if (atomic_read(&new_dentry->d_count) > 1) {
- /* dentry still busy? */
-#ifdef NFS_PARANOIA
- printk("nfs_rename: target %s/%s busy, d_count=%d\n",
- new_dentry->d_parent->d_name.name,
- new_dentry->d_name.name,
- atomic_read(&new_dentry->d_count));
-#endif
+ } else if (atomic_read(&new_dentry->d_count) > 1)
+ /* dentry still busy? */
goto out;
- }
} else
drop_nlink(new_inode);
diff --git a/fs/nfs/getroot.c b/fs/nfs/getroot.c
index 8391bd7..4dc193f 100644
--- a/fs/nfs/getroot.c
+++ b/fs/nfs/getroot.c
@@ -42,7 +42,6 @@ #include "delegation.h"
#include "internal.h"
#define NFSDBG_FACILITYNFSDBG_CLIENT
-#define NFS_PARANOIA 1
/*
* get an NFS2/NFS3 root dentry from the root filehandle
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 63e4702..d29dfe0 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -48,7 +48,6 @@ #include "iostat.h"
#include "internal.h"
#define NFSDBG_FACILITYNFSDBG_VFS
-#define NFS_PARANOIA 1
static void nfs_invalidate_inode(struct inode *);
static int nfs_update_inode(struct inode *, struct nfs_fattr *);
@@ -1022,10 +1021,8 @@ static int nfs_update_inode(struct inode
/*
* Big trouble! The inode has become a different object.
*/
-#ifdef NFS_PARANOIA
printk(KERN_DEBUG "%s: inode %ld mode changed, %07o to %07o\n",
__FUNCTION__, inode->i_ino, inode->i_mode, fattr->mode);
-#endif
out_err:
/*
* No need to worry about unhashing the dentry, as the
diff --git a/fs/nfs/nfs2xdr.c b/fs/nfs/nfs2xdr.c
index 3be4e72..1fc757b 100644
--- a/fs/nfs/nfs2xdr.c
+++ b/fs/nfs/nfs2xdr.c
@@ -26,7 +26,6 @@ #include
#include "internal.h"
#define NFSDBG_FACILITYNFSDBG_XDR
-/* #define NFS_PARANOIA 1 */
/* Mapping from NFS error code to "errno" error code. */
#define errno_NFSERR_IOEIO
diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c
index ca4b1d4..7e32bf3 100644
--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -19,8 +19,6 @@ #include
#include
#include
-#define NFS_PARANOIA 1
-
static struct kmem_cache *nfs_page_cachep;
static inline struct nfs_page *
@@ -172,11 +170,6 @@ nfs_release_request(struct nfs_page *req
if (!atomic_dec_and_test(&req->wb_count))
return;
-#ifdef NFS_PARANOIA
- BUG_ON (!list_empty(&req->wb_list));
- BUG_ON (NFS_WBACK_BUSY(req));
-#endif
-
/* Release struct file or cached credential */
nfs_clear_request(req);
put_nfs_open_context(req->wb_context);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Open letter to Linux kernel developers (was Re: Binary Drivers)
On 18/12/06, Hannu Savolainen <[EMAIL PROTECTED]> wrote: Marek Wawrzyczny wrote: > Dear Linux Kernel ML, > > I am writing as a Linux-only user of over 2 years to express my concern with > the recent proposal to block out closed source modules from the kernel. > > While, I understand and share your sentiments over open source software and > drivers. I fear however, that trying to steamroll the industry into > developing open source drivers by banning closed source drivers is going to > have a completely different result. They will simply abandon Linux support > for some of their products altogether. > As a developer of some "closed source" drivers I can confirm that this is exactly the case. I would never consider open sourcing my work just because somebody is pointing pistol to my neck. I would leave the whole IT business and start doing something else rather than accept this kind of mafia-like negotiation methods. Why is this dead horse still kicking? Linus already spoke on this issue ( http://lkml.org/lkml/2006/12/13/370 , http://lkml.org/lkml/2006/12/14/218 ) and Greg KH already withdrew his patch ( http://lkml.org/lkml/2006/12/14/63 ), so could we please just let this dead horse rest in peace? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VFS: turn off FL_SLEEP when calling do_vfs_lock() just in case and get rid of "VFS is out of sync with lock manager" messages
Convert "VFS is out of sync with lock manager!" printk() in
do_vfs_lock() to dprintk() since the message is useless in normal use
but could possibly be useful as a debugging aid.
Also turn off FL_SLEEP when calling do_vfs_lock() just in case, after
getting -EINTR or -ERESTARTSYS.
Patch has been tested on a production webserver and works just fine.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
fs/nfs/file.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index 0dd6be3..4cf4166 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -434,8 +434,8 @@ static int do_vfs_lock(struct file *file
BUG();
}
if (res < 0)
- printk(KERN_WARNING "%s: VFS is out of sync with lock
manager!\n",
- __FUNCTION__);
+ dprintk("%s: VFS is out of sync with lock manager (res =
%d)!\n",
+ __FUNCTION__, res);
return res;
}
@@ -485,10 +485,13 @@ static int do_setlk(struct file *filp, i
* we clean up any state on the server. We therefore
* record the lock call as having succeeded in order to
* ensure that locks_remove_posix() cleans it out when
-* the process exits.
+* the process exits. Make sure not to sleep if
+* someone else holds the lock.
*/
- if (status == -EINTR || status == -ERESTARTSYS)
+ if (status == -EINTR || status == -ERESTARTSYS) {
+ fl->fl_flags &= ~FL_SLEEP;
do_vfs_lock(filp, fl);
+ }
} else
status = do_vfs_lock(filp, fl);
unlock_kernel();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Will there be security updates for 2.6.17 kernels?
On 14/12/06, Manuel Reimer <[EMAIL PROTECTED]> wrote: Hello, my problem is, that the slackware maintainers decided to use kernel 2.6.17. Here is their comment, they posted to the changelog: They had a 2.6.16 kernel in /extra before and as far as I know the 2.6.16 kernel series still gets security updates. Is this also the case for 2.6.17 kernels? No, that is not planned. 2.6.16.x is an exception.-stable kernels (those with 2.6.x.y versions) are only released for the latest stable 2.6.x kernel. So currently that's 2.6.19 and as soon as 2.6.20 comes out there will not be any more 2.6.19.x, only 2.6.20.x - I hope that's clear... will there be an update if there is an security hole in the latest 2.6.17 kernel? No. If the problem was also in the latest stable kernel (currently 2.6.19.1) then a fix would go into 2.6.19.2 and users can then upgrade to that kernel. If 2.6.19.1 is not vulnerable, then everything is fine as users of old 2.6.17 kernels can just upgrade to 2.6.19.1 The problem is, that the slackware team doesn't patch anything on their own. They always wait for the update done by the author, if the bug isn't very critical. This means they will stay forever with their current version of the 2.6.17 kernel, if there will be no updates in future. Not true. Slackware updates the kernel to fix security issues - this has been the case in the past and i don't see why it would change in the future. If there will be no updates for 2.6.17 in future: Are there already security holes in 2.6.17? probably. Could someone please give two examples? I need informations, to be able to contact the slackware team, to request a "downgrade" to 2.6.16. Ehh, you wouldn't want to do that. You'd want to encourage an upgrade to 2.6.19.1 instead. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel compilation on windows XP using cygwin
On 11/12/06, kalyan kumar <[EMAIL PROTECTED]> wrote: I am not able to compile latest kernel code in cygwin environment. It fails for not ELF error always and exits. Any suggestions please? One suggestion: Don't do that. That's not a supported way to build the kernel. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Lots of "swapper: page allocation failure" and other memory related messages - 2.6.16-xen0
On 11/12/06, Keir Fraser <[EMAIL PROTECTED]> wrote: On 8/12/06 12:36, "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > (please keep me on Cc when replying) > > I have a server running Xen that regularly spews the following. > The box seems to survive fine regardless - just thought I'd let everyone know. Harmless and not entirely unexpected. I'll add __GFP_NOWARN to the allocations to quieten things down. Ok, great. Thank you. :-) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: why are some of my patches being credited to other "authors"?
On 09/12/06, Robert P. J. Day <[EMAIL PROTECTED]> wrote: On Sat, 9 Dec 2006, Tim Schmielau wrote: > i wrote: > > but given that i'm trying to follow the kernel guidelines and keep > > each submission as a logically-related chunk, in many cases, i > > have to wait for one patch to be applied before i can submit the > > next one. and, at the moment, there's no way of knowing what's > > going on. > > Well, you can send out a patch series: > [patch 01/02] Prepare foo for blah > [patch 02/02] Apply blah to foo > Ideally you would finish the patch description for patch 02 with something > like > > --- > This patch depends on [patch 01/02] Prepare foo for blah ... snip ... wait a minute. that's not what i've understood all this time as the rationale for a multi-part patch -- to show dependency. certainly, that's not what you read in "SubmittingPatches": "If one patch depends on another patch in order for a change to be complete, that is OK. Simply note "this patch depends on patch X" in your patch description." that doesn't say anything about using the multi-part notation. are you sure about this? I've done this several times. It's quite a common way of doing it. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS related BUGs at shutdown - do_exit() + lock held at task exit time - 2.6.17.8
On 08/12/06, Trond Myklebust <[EMAIL PROTECTED]> wrote: On Fri, 2006-12-08 at 12:41 +0100, Jesper Juhl wrote: > Greetings, > > I just got a kernel crash when shutting down a webserver. Nothing made > it to the logs, but I managed to get a photo of the dump on screen : > http://www.kernel.org/pub/linux/kernel/people/juhl/images/2.6.17.8-kernel-crash.jpg It is hard to see what is going on there. AFAICS, the more interesting stuff to do with the Oops itself has scrolled off the screen. Any chance it may have been syslogged? Unfortunately no - I checked. All I have is that photo :-( -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let's get rid of those annoying "VFS is out of sync with lock manager" messages (includes proposed patch)
On 08/12/06, Jesper Juhl <[EMAIL PROTECTED]> wrote: On 08/12/06, Neil Brown <[EMAIL PROTECTED]> wrote: > On Thursday December 7, [EMAIL PROTECTED] wrote: > > > > So I took Neils patch, made the change Trond suggested and the result is > > below. > > > > Comments? Ok to merge? > > Yes, except that you need a changelog comment at the top. Possibly > based very heavily on the text I wrote, but written to justify the > patch rather than to explain the bug. > > NeilBrown > How about this for a changelog entry? : Convert "VFS is out of sync with lock manager!" printk in do_vfs_lock() to dprintk() since the message is useless in normal use but could possibly be useful as a debugging aid. Also turn off FL_SLEEP when calling do_vfs_lock() just in case after getting -EINTR or -ERESTARTSYS. Ohh and btw, I forgot to mention that the patch has been tested and resolves my original issue. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let's get rid of those annoying "VFS is out of sync with lock manager" messages (includes proposed patch)
On 08/12/06, Neil Brown <[EMAIL PROTECTED]> wrote:
On Thursday December 7, [EMAIL PROTECTED] wrote:
>
> So I took Neils patch, made the change Trond suggested and the result is
> below.
>
> Comments? Ok to merge?
Yes, except that you need a changelog comment at the top. Possibly
based very heavily on the text I wrote, but written to justify the
patch rather than to explain the bug.
NeilBrown
How about this for a changelog entry? :
Convert "VFS is out of sync with lock manager!" printk in
do_vfs_lock() to dprintk() since the message is useless in normal use
but could possibly be useful as a debugging aid.
Also turn off FL_SLEEP when calling do_vfs_lock() just in case after
getting -EINTR or -ERESTARTSYS.
>
>
> Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> ---
>
> fs/nfs/file.c | 11 +++
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/fs/nfs/file.c b/fs/nfs/file.c
> index cc93865..22572af 100644
> --- a/fs/nfs/file.c
> +++ b/fs/nfs/file.c
> @@ -428,8 +428,8 @@ static int do_vfs_lock(struct file *file
> BUG();
> }
> if (res < 0)
> - printk(KERN_WARNING "%s: VFS is out of sync with lock
manager!\n",
> - __FUNCTION__);
> + dprintk("%s: VFS is out of sync with lock manager (res =
%d)!\n",
> + __FUNCTION__, res);
> return res;
> }
>
> @@ -479,10 +479,13 @@ static int do_setlk(struct file *filp, i
>* we clean up any state on the server. We therefore
>* record the lock call as having succeeded in order to
>* ensure that locks_remove_posix() cleans it out when
> - * the process exits.
> + * the process exits. Make sure not to sleep if
> + * someone else holds the lock.
>*/
> - if (status == -EINTR || status == -ERESTARTSYS)
> + if (status == -EINTR || status == -ERESTARTSYS) {
> + fl->fl_flags &= ~FL_SLEEP;
> do_vfs_lock(filp, fl);
> + }
> } else
> status = do_vfs_lock(filp, fl);
> unlock_kernel();
>
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Lots of "swapper: page allocation failure" and other memory related messages - 2.6.16-xen0
(please keep me on Cc when replying) I have a server running Xen that regularly spews the following. The box seems to survive fine regardless - just thought I'd let everyone know. Dec 8 12:19:26 server kernel: 0x47/0x7a Dec 8 12:19:26 server kernel: [alloc_skb_from_cache+70/243] alloc_skb_from_cache+0x46/0xf3 Dec 8 12:19:26 server kernel: [__dev_alloc_skb+70/92] __dev_alloc_skb+0x46/0x5c Dec 8 12:19:26 server kernel: [netif_be_start_xmit+166/431] netif_be_start_xmit+0xa6/0x1af Dec 8 12:19:26 server kernel: [dev_queue_xmit+520/679] dev_queue_xmit+0x208/0x2a7 Dec 8 12:19:26 server kernel: [br_forward_finish+0/65] br_forward_finish+0x0/0x41 Dec 8 12:19:26 server kernel: [br_dev_queue_push_xmit+216/223] br_dev_queue_push_xmit+0xd8/0xdf Dec 8 12:19:26 server kernel: [br_forward_finish+61/65] br_forward_finish+0x3d/0x41 Dec 8 12:19:26 server kernel: [br_nf_forward_finish+199/204] br_nf_forward_finish+0xc7/0xcc Dec 8 12:19:26 server kernel: [br_nf_forward_arp+274/285] br_nf_forward_arp+0x112/0x11d Dec 8 12:19:26 server kernel: [nf_iterate+63/109] nf_iterate+0x3f/0x6d Dec 8 12:19:26 server kernel: [br_forward_finish+0/65] br_forward_finish+0x0/0x41 Dec 8 12:19:26 server kernel: [nf_hook_slow+71/193] nf_hook_slow+0x47/0xc1 Dec 8 12:19:26 server kernel: [br_forward_finish+0/65] br_forward_finish+0x0/0x41 Dec 8 12:19:26 server kernel: [__br_forward+70/87] __br_forward+0x46/0x57 Dec 8 12:19:26 server kernel: [br_forward_finish+0/65] br_forward_finish+0x0/0x41 Dec 8 12:19:26 server kernel: [br_flood+116/207] br_flood+0x74/0xcf Dec 8 12:19:26 server kernel: [__br_forward+0/87] __br_forward+0x0/0x57 Dec 8 12:19:26 server kernel: [br_flood_forward+22/27] br_flood_forward+0x16/0x1b Dec 8 12:19:26 server kernel: [__br_forward+0/87] __br_forward+0x0/0x57 Dec 8 12:19:26 server kernel: [br_handle_frame_finish+134/252] br_handle_frame_finish+0x86/0xfc Dec 8 12:19:26 server kernel: [br_handle_frame+358/421] br_handle_frame+0x166/0x1a5 Dec 8 12:19:26 server kernel: [netif_receive_skb+333/538] netif_receive_skb+0x14d/0x21a Dec 8 12:19:26 server kernel: [tg3_rx+732/957] tg3_rx+0x2dc/0x3bd Dec 8 12:19:26 server kernel: [tg3_poll+119/356] tg3_poll+0x77/0x164 Dec 8 12:19:26 server kernel: [net_rx_action+164/368] net_rx_action+0xa4/0x170 Dec 8 12:19:27 server kernel: [__do_softirq+116/240] __do_softirq+0x74/0xf0 Dec 8 12:19:27 server kernel: [do_softirq+63/99] do_softirq+0x3f/0x63 Dec 8 12:19:27 server kernel: [do_IRQ+31/37] do_IRQ+0x1f/0x25 Dec 8 12:19:27 server kernel: [evtchn_do_upcall+132/192] evtchn_do_upcall+0x84/0xc0 Dec 8 12:19:27 server kernel: [hypervisor_callback+44/52] hypervisor_callback+0x2c/0x34 Dec 8 12:19:27 server kernel: [xen_idle+97/127] xen_idle+0x61/0x7f Dec 8 12:19:27 server kernel: [cpu_idle+76/97] cpu_idle+0x4c/0x61 Dec 8 12:19:27 server kernel: [start_kernel+370/372] start_kernel+0x172/0x174 Dec 8 12:19:27 server kernel: Mem-info: Dec 8 12:19:27 server kernel: DMA per-cpu: Dec 8 12:19:27 server kernel: cpu 0 hot: high 90, batch 15 used:14 Dec 8 12:19:27 server kernel: cpu 0 cold: high 30, batch 7 used:25 Dec 8 12:19:27 server kernel: cpu 1 hot: high 90, batch 15 used:56 Dec 8 12:19:27 server kernel: cpu 1 cold: high 30, batch 7 used:1 Dec 8 12:19:27 server kernel: DMA32 per-cpu: empty Dec 8 12:19:27 server kernel: Normal per-cpu: empty Dec 8 12:19:27 server kernel: HighMem per-cpu: empty Dec 8 12:19:27 server kernel: Free pages: 776kB (0kB HighMem) Dec 8 12:19:27 server kernel: Active:12194 inactive:16772 dirty:70 writeback:0 unstable:0 free:194 slab:17017 mapped:5214 pagetables:115 Dec 8 12:19:27 server kernel: DMA free:776kB min:2076kB low:2592kB high:3112kB active:48776kB inactive:67088kB present:270336kB pages_scanned:0 all_unreclaimable? no Dec 8 12:19:27 server kernel: lowmem_reserve[]: 0 0 0 0 Dec 8 12:19:27 server kernel: DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no Dec 8 12:19:27 server kernel: lowmem_reserve[]: 0 0 0 0 Dec 8 12:19:27 server kernel: Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no Dec 8 12:19:27 server kernel: lowmem_reserve[]: 0 0 0 0 Dec 8 12:19:27 server kernel: HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no Dec 8 12:19:27 server kernel: lowmem_reserve[]: 0 0 0 0 Dec 8 12:19:27 server kernel: DMA: 0*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 776kB Dec 8 12:19:27 server kernel: DMA32: empty Dec 8 12:19:27 server kernel: Normal: empty Dec 8 12:19:27 server kernel: HighMem: empty Dec 8 12:19:27 server kernel: Swap cache: add 635, delete 635, find 0/0, race 0+0 Dec 8 12:19:27 server kernel: Free swap = 3901244kB Dec 8 12:19:27 server kernel: Total swap = 3903784kB Dec 8 12:19:27 server kernel: Free swap:
Re: additional oom-killer tuneable worth submitting?
On 07/12/06, Chris Friesen <[EMAIL PROTECTED]> wrote: Jesper Juhl wrote: >> Jesper Juhl wrote: >> > What happens in the case where the OOM killer really, really needs to >> > kill one or more processes since there is not a single drop of memory >> > available, but all processes are below their configured thresholds? > I realize that if this case happens the system is misconfigured as far > as oomthresh goes, but if this is a knob that we put in the mainline > kernel then I believe there should be some sort of emergency handling > code that takes this situation into account. Perhaps throw some very > nasty looking log messages and then fall back to the classic OOM > killer behaviour..? Yeah, I can see that the reboot might be a bit drastic for mainline. I think the fallback to classic behaviour might work okay. Anyway, the chances of hitting that case are likely pretty slim. The way we've been using this is to only set the threshold for fairly important long-lived daemons. Much of the "standard" stuff (shell, cat, cp, mv, etc.) is left unprotected. Sure, that's sensible, to only protect the important stuff. But even if the chances of hitting this are slim, we still need a way out. For most people anything is better than a hung box. Some examples; For a desktop (where people may be experimenting with the feature) - seeing your firefox process evaporate due to the OOM killer and then finding a message explaining what happened in dmesg is a lot less frustrating than a hang or sudden reboot. For a server - If you mis-configure the new feature you may be in for a long drive to reboot a box whereas falling back to the classic OOM killer (+ nasty messages in dmesg) will likely save you the trip and clue you in as to what you mis-configured. For an embedded box - triggering a reboot would probably be better than both a hang or classic OOM kill in many cases (better to have the device reboot and come back working than to hang or start malfunctioning due to a missing process). So maybe what's needed is an additional knob for people to tweak - one that selects what should happen in this rare case: 1) fallback to classic OOM (default), 2) reboot, 3) hang. In all cases messages should be logged explaining what happened. Or is that overkill? If so I'd personally prefer just falling back to classic OOM kill in this case. A way out for the "OOM but all processes below threshold" case + perhaps coupled with oomthresh applying to process groups instead of just processes and I personally start to like this feature. Let's see some code... -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: additional oom-killer tuneable worth submitting?
On 07/12/06, Chris Friesen <[EMAIL PROTECTED]> wrote: Jesper Juhl wrote: > What happens in the case where the OOM killer really, really needs to > kill one or more processes since there is not a single drop of memory > available, but all processes are below their configured thresholds? Then the system wasn't properly engineered. I had a feeling you'd say that. In this case you reboot. I realize that if this case happens the system is misconfigured as far as oomthresh goes, but if this is a knob that we put in the mainline kernel then I believe there should be some sort of emergency handling code that takes this situation into account. Perhaps throw some very nasty looking log messages and then fall back to the classic OOM killer behaviour..? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Let's get rid of those annoying "VFS is out of sync with lock manager" messages (includes proposed patch)
Hi,
A while back I reported that I had a bunch of servers that started
complaining about VFS being out of sync with lock manager -
the thread title was
"[NFS] 2.6.17.8 - do_vfs_lock: VFS is out of sync with lock manager!"
During the course of that thread Neil Brown proposed a patch to resolve the
issue with the following description:
"
- do_vfs_lock is only called when the filesystem was mounted with
-o nolock EXCEPT
- If a lock request to the server in interrupted (when mounted with
-o intr) then do_vfs_lock is called to try to get the lock
locally. Normally equivalent code will be called inside
fs/lockd/clntproc.c when the server replies that the lock has been
gained. In the case of an interrupt though this doesn't happen
but the lock may still have happened on the server. So we record
locally that the lock was gained, to ensure that it gets unlocked
when the process exits.
As you don't have '-o nolocks' you must be hitting the second case.
The lock call to the server returns -EINTR or -ERESTARTSYS and
do_vfs_lock is called just-in-case.
As this is a just-in-case call, it is quite possible that the lock is
held by some other process, so getting an error is entirely possible.
So printing the message in this case seems wrong.
On the other hand, printing the message in any other case seems wrong
too, as server locking is not being used, so there is nothing to get
out of sync with.
As a further complication, I don't think that in the just-in-case
situation that it should risk waiting for the lock.
Now maybe we can be sure there is a pending signal which will break
out of any wait (though I'm worried about -ERESTARTSYS - that doesn't
imply a signal does it?), but I would feel more comfortable if
FL_SLEEP were turned off in that path.
"
To which Trond Myklebust replied:
"
Could we instead replace it with a dprintk() that returns the value of
"res"? That will keep it useful for debugging purposes.
"
So I took Neils patch, made the change Trond suggested and the result is
below.
Comments? Ok to merge?
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
fs/nfs/file.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index cc93865..22572af 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -428,8 +428,8 @@ static int do_vfs_lock(struct file *file
BUG();
}
if (res < 0)
- printk(KERN_WARNING "%s: VFS is out of sync with lock
manager!\n",
- __FUNCTION__);
+ dprintk("%s: VFS is out of sync with lock manager (res =
%d)!\n",
+ __FUNCTION__, res);
return res;
}
@@ -479,10 +479,13 @@ static int do_setlk(struct file *filp, i
* we clean up any state on the server. We therefore
* record the lock call as having succeeded in order to
* ensure that locks_remove_posix() cleans it out when
-* the process exits.
+* the process exits. Make sure not to sleep if
+* someone else holds the lock.
*/
- if (status == -EINTR || status == -ERESTARTSYS)
+ if (status == -EINTR || status == -ERESTARTSYS) {
+ fl->fl_flags &= ~FL_SLEEP;
do_vfs_lock(filp, fl);
+ }
} else
status = do_vfs_lock(filp, fl);
unlock_kernel();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: additional oom-killer tuneable worth submitting?
A few questions below. On 07/12/06, Chris Friesen <[EMAIL PROTECTED]> wrote: The kernel currently has a way to adjust the oom-killer score via /proc//oomadj. However, to adjust this effectively requires knowledge of the scores of all the other processes on the system. I'd like to float an idea (which we've implemented and been using for some time) where the semantics are slightly different: We add a new "oom_thresh" member to the task struct. We introduce a new proc entry "/proc//oomthresh" to control it. How does "oomthresh" and "oomadj" affect each other? The "oom-thresh" value maps to the max expected memory consumption for that process. As long as a process uses less memory than the specified threshold, then it is immune to the oom-killer. Default "oomthresh" value for a new process is 0 (zero) I assume - right? If not, then I'd suggest that it should be. What happens when a process fork()s? Does the child enherit the parents "oomthresh" value? Would it make sense to make "oomthresh" apply to process groups instead of processes? On an embedded platform this allows the designer to engineer the system and protect critical apps based on their expected memory consumption. If one of those apps goes crazy and starts chewing additional memory then it becomes vulnerable to the oom killer while the other apps remain protected. What happens in the case where the OOM killer really, really needs to kill one or more processes since there is not a single drop of memory available, but all processes are below their configured thresholds? If a patch for the above feature was submitted, would there be any chance of getting it included? Maybe controlled by a config option? Impossible to know without posting the patch for review :) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drivers/net/chelsio/my3126.c: inconsequent NULL checking
On 07/12/06, Adrian Bunk <[EMAIL PROTECTED]> wrote:
The Coverity checker spotted the following inconsequent NULL checking
introduced by commit f1d3d38af75789f1b82969b83b69cab540609789:
<-- snip -->
...
static struct cphy *my3126_phy_create(adapter_t *adapter,
int phy_addr, struct mdio_ops *mdio_ops)
{
struct cphy *cphy = kzalloc(sizeof (*cphy), GFP_KERNEL);
if (cphy)
cphy_init(cphy, adapter, phy_addr, &my3126_ops, mdio_ops);
INIT_WORK(&cphy->phy_update, my3216_poll, cphy);
cphy->bmsr = 0;
return (cphy);
}
...
<-- snip -->
It doesn't make sense to first check whether "cphy" is NULL and
dereference it unconditionally later.
How about simply changing
if (cphy)
cphy_init(cphy, adapter, phy_addr, &my3126_ops, mdio_ops);
into
if (!cphy)
return NULL;
callers need to be able to handle that ofcourse, but I haven't checked that yet.
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] CodingStyle updates
On 07/12/06, Randy Dunlap <[EMAIL PROTECTED]> wrote: From: Randy Dunlap <[EMAIL PROTECTED]> Add some kernel coding style comments, mostly pulled from emails by Andrew Morton, Jesper Juhl, and Randy Dunlap. - add paragraph on switch/case indentation - add paragraph on multiple-assignments - add more on Braces - add section on Spaces - add paragraph on function breaks in source files - add paragraph on EXPORT_SYMBOL placement - add section on /*-comment style, long-comment style, and data declarations and comments - correct some chapter number references that were missed when chapters were renumbered Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Acked-by: Jesper Juhl <[EMAIL PROTECTED]> -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] A few small additions and corrections to README
On Thursday 07 December 2006 01:07, Ben Nizette wrote: > Jesper Juhl wrote: [...] > > @@ -22,15 +22,17 @@ ON WHAT HARDWARE DOES IT RUN? > > > >Although originally developed first for 32-bit x86-based PCs (386 or > > higher), > >today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and > > - UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, > > + UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, > > Cell, > > > And AVR32 as of 2.6.19 :) Well, the list does say "(at least)" ;-) But sure, find an add-on patch below. > >IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS, > > - and Renesas M32R architectures. > > + Cris, Xtensa and Renesas M32R architectures. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- diff --git a/README b/README index b656f00..c055615 100644 --- a/README +++ b/README @@ -24,7 +24,7 @@ ON WHAT HARDWARE DOES IT RUN? today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS, - Cris, Xtensa and Renesas M32R architectures. + Cris, Xtensa, AVR32 and Renesas M32R architectures. Linux is easily portable to most general-purpose 32- or 64-bit architectures as long as they have a paged memory management unit (PMMU) and a port of the -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] A few small additions and corrections to README
Hi, here's a small patch which - adds a few archs to the current list of supported platforms. - adds a few missing slashes at the end of URLs. - adds a few references to additional documentation. - adds "make config" to the list of possible configuration targets. - makes a few other minor changes. Please consider for inclusion. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- README | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile diff --git a/README b/README index 3e26472..b656f00 100644 --- a/README +++ b/README @@ -1,4 +1,4 @@ - Linux kernel release 2.6.xx <http://kernel.org> + Linux kernel release 2.6.xx <http://kernel.org/> These are the release notes for Linux version 2.6. Read them carefully, as they tell you what this is all about, explain how to install the @@ -22,15 +22,17 @@ ON WHAT HARDWARE DOES IT RUN? Although originally developed first for 32-bit x86-based PCs (386 or higher), today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and - UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, + UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS, - and Renesas M32R architectures. + Cris, Xtensa and Renesas M32R architectures. Linux is easily portable to most general-purpose 32- or 64-bit architectures as long as they have a paged memory management unit (PMMU) and a port of the GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has also been ported to a number of architectures without a PMMU, although functionality is then obviously somewhat limited. + Linux has also been ported to itself. You can now run the kernel as a + userspace application - this is called UserMode Linux (UML). DOCUMENTATION: @@ -113,6 +115,7 @@ INSTALLING the kernel: version 2.6.12.2 and want to jump to 2.6.12.3, you must first reverse the 2.6.12.2 patch (that is, patch -R) _before_ applying the 2.6.12.3 patch. + You can read more on this in Documentation/applying-patches.txt - Make sure you have no stale .o files and dependencies lying around: @@ -161,6 +164,7 @@ CONFIGURING the kernel: only ask you for the answers to new questions. - Alternate configuration commands are: + "make config" Plain text interface. "make menuconfig" Text based color menus, radiolists & dialogs. "make xconfig" X windows (Qt) based configuration tool. "make gconfig" X windows (Gtk) based configuration tool. @@ -303,8 +307,9 @@ IF SOMETHING GOES WRONG: - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump as is, otherwise you will have to use the "ksymoops" program to make - sense of the dump. This utility can be downloaded from - ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops. + sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred). + This utility can be downloaded from + ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ . Alternately you can do the dump lookup by hand: - In debugging dumps like the above, it helps enormously if you can @@ -336,7 +341,7 @@ IF SOMETHING GOES WRONG: If you for some reason cannot do the above (you have a pre-compiled kernel image or similar), telling me as much about your setup as - possible will help. + possible will help. Please read the REPORTING-BUGS document for details. - Alternately, you can use gdb on a running kernel. (read-only; i.e. you cannot change values or set break points.) To do this, first compile the - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][resend] Clean up 'make help' output for documentation targets.
Here's a patch that cleans up the "make help" output a bit for the documentation targets. Currently the documentation targets are listed completely different than all the other targets : Documentation targets: Linux kernel internal documentation in different formats: xmldocs (XML DocBook), psdocs (Postscript), pdfdocs (PDF) htmldocs (HTML), mandocs (man pages, use installmandocs to install) with this patch they are more in line with the rest of the output : Documentation targets: Linux kernel internal documentation in different formats: htmldocs- HTML installmandocs - install man pages generated by mandocs mandocs - man pages pdfdocs - PDF psdocs - Postscript xmldocs - XML DocBook Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> Acked-by: Randy Dunlap <[EMAIL PROTECTED]> --- Documentation/DocBook/Makefile | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index db9499a..36526a1 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -190,9 +190,13 @@ # Rule to convert a .c file to inline XM ### # Help targets as used by the top-level makefile dochelp: - @echo ' Linux kernel internal documentation in different formats:' - @echo ' xmldocs (XML DocBook), psdocs (Postscript), pdfdocs (PDF)' - @echo ' htmldocs (HTML), mandocs (man pages, use installmandocs to install)' + @echo ' Linux kernel internal documentation in different formats:' + @echo ' htmldocs- HTML' + @echo ' installmandocs - install man pages generated by mandocs' + @echo ' mandocs - man pages' + @echo ' pdfdocs - PDF' + @echo ' psdocs - Postscript' + @echo ' xmldocs - XML DocBook' ### # Temporary files left by various tools - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
vmscan.c:196: bad pmd (kernel 2.4.25)
001e3. vmscan.c:196: bad pmd 254001e3. vmscan.c:196: bad pmd 258001e3. vmscan.c:196: bad pmd 25c001e3. vmscan.c:196: bad pmd 260001e3. vmscan.c:196: bad pmd 264001e3. vmscan.c:196: bad pmd 268001e3. vmscan.c:196: bad pmd 26c001e3. vmscan.c:196: bad pmd 270001e3. vmscan.c:196: bad pmd 274001e3. vmscan.c:196: bad pmd 278001e3. vmscan.c:196: bad pmd 27c001e3. vmscan.c:196: bad pmd 280001e3. vmscan.c:196: bad pmd 284001e3. vmscan.c:196: bad pmd 288001e3. vmscan.c:196: bad pmd 28c001e3. vmscan.c:196: bad pmd 290001e3. vmscan.c:196: bad pmd 294001e3. vmscan.c:196: bad pmd 298001e3. vmscan.c:196: bad pmd 29c001e3. vmscan.c:196: bad pmd 2a0001e3. vmscan.c:196: bad pmd 2a4001e3. vmscan.c:196: bad pmd 2a8001e3. vmscan.c:196: bad pmd 2ac001e3. vmscan.c:196: bad pmd 2b0001e3. vmscan.c:196: bad pmd 2b4001e3. vmscan.c:196: bad pmd 2b8001e3. vmscan.c:196: bad pmd 2bc001e3. vmscan.c:196: bad pmd 2c0001e3. vmscan.c:196: bad pmd 2c4001e3. vmscan.c:196: bad pmd 2c8001e3. vmscan.c:196: bad pmd 2cc001e3. vmscan.c:196: bad pmd 2d0001e3. vmscan.c:196: bad pmd 2d4001e3. vmscan.c:196: bad pmd 2d8001e3. vmscan.c:196: bad pmd 2dc001e3. vmscan.c:196: bad pmd 2e0001e3. vmscan.c:196: bad pmd 2e4001e3. vmscan.c:196: bad pmd 2e8001e3. vmscan.c:196: bad pmd 2ec001e3. vmscan.c:196: bad pmd 2f0001e3. vmscan.c:196: bad pmd 2f4001e3. vmscan.c:196: bad pmd 2f8001e3. vmscan.c:196: bad pmd 2fc001e3. vmscan.c:196: bad pmd 31e3. vmscan.c:196: bad pmd 304001e3. vmscan.c:196: bad pmd 308001e3. vmscan.c:196: bad pmd 30c001e3. vmscan.c:196: bad pmd 310001e3. vmscan.c:196: bad pmd 314001e3. vmscan.c:196: bad pmd 318001e3. vmscan.c:196: bad pmd 31c001e3. vmscan.c:196: bad pmd 320001e3. vmscan.c:196: bad pmd 324001e3. vmscan.c:196: bad pmd 328001e3. vmscan.c:196: bad pmd 32c001e3. vmscan.c:196: bad pmd 330001e3. vmscan.c:196: bad pmd 334001e3. vmscan.c:196: bad pmd 338001e3. vmscan.c:196: bad pmd 33c001e3. vmscan.c:196: bad pmd 340001e3. vmscan.c:196: bad pmd 344001e3. vmscan.c:196: bad pmd 348001e3. vmscan.c:196: bad pmd 34c001e3. vmscan.c:196: bad pmd 350001e3. vmscan.c:196: bad pmd 354001e3. vmscan.c:196: bad pmd 358001e3. vmscan.c:196: bad pmd 35c001e3. vmscan.c:196: bad pmd 360001e3. vmscan.c:196: bad pmd 364001e3. vmscan.c:196: bad pmd 368001e3. vmscan.c:196: bad pmd 36c001e3. vmscan.c:196: bad pmd 370001e3. vmscan.c:196: bad pmd 374001e3. vmscan.c:196: bad pmd 378001e3. vmscan.c:196: bad pmd 37c001e3. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/12] IPMI: add poll delay
On 05/12/06, Corey Minyard <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
> On Fri, 1 Dec 2006 22:35:20 -0600
> Corey Minyard <[EMAIL PROTECTED]> wrote:
>
>
>> Make sure to delay a little in the IPMI poll routine so we can pass in
>> a timeout time and thus time things out.
>>
>> Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
>>
>> Index: linux-2.6.19-rc6/drivers/char/ipmi/ipmi_si_intf.c
>> ===
>> --- linux-2.6.19-rc6.orig/drivers/char/ipmi/ipmi_si_intf.c
>> +++ linux-2.6.19-rc6/drivers/char/ipmi/ipmi_si_intf.c
>> @@ -807,7 +807,12 @@ static void poll(void *send_info)
>> {
>> struct smi_info *smi_info = send_info;
>>
>> -smi_event_handler(smi_info, 0);
>> +/*
>> + * Make sure there is some delay in the poll loop so we can
>> + * drive time forward and timeout things.
>> + */
>> +udelay(10);
>> +smi_event_handler(smi_info, 10);
>> }
>>
>
> I don't understand what this patch is doing. It looks fishy. More
> details, please?
>
Yeah, it does look a little fishy. This is a poll routine that is only
called at panic
time; it is used to force things to happen in the driver without
scheduling or
timers. The driver does this so it can set watchdog parameters and store
panic information in the event log at panic time.
Without this change, if something goes wrong in the BMC the driver will
never
time out the operation since it doesn't see time being driven forward.
So this
makes sure the driver sees time advancing as it should.
Hmm, I wonder if this could explain why some of my IBM servers become
unreachable via IPMI after a kernel crash.
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Be a bit defensive in quirk_nvidia_ck804() so we don't risk dereferencing a NULL pdev.
pci_get_slot() may return NULL if nothing was found.
quirk_nvidia_ck804() does not check the value returned from pci_get_slot(),
so it may end up causing a NULL pointer deref.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/pci/quirks.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 5b44838..d3dcbda 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1741,6 +1741,8 @@ static void __devinit quirk_nvidia_ck804
* a single one having MSI is enough to be sure that MSI are supported.
*/
pdev = pci_get_slot(dev->bus, 0);
+ if (!pdev)
+ return;
if (dev->subordinate && !msi_ht_cap_enabled(dev)
&& !msi_ht_cap_enabled(pdev)) {
printk(KERN_WARNING "PCI: MSI quirk detected. "
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] Tigran Aivazian: remove bouncing email addresses
On 01/12/06, Hua Zhong <[EMAIL PROTECTED]> wrote: I am curious, what's the point? These email addresses serve a "historical" purpose: they tell when the contribution was made, what the author's email addresses were at that point. It's not MAINTAINERS. If people want to contact someone, go find the latest address there. Yes, MAINTAINERS is the preferred location for maintainer info, but when there is no entry in maintainers (or when the person listed there is not responsive), many people (including me) use the names or email addresses listed in source files as people to contact. So it's nice when the email addresses are up to date. In my opinion the addresses should be working ones or not present at all (or at the very least there should be a note that the email address is outdated). -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Core file size?
On 30/11/06, linux err <[EMAIL PROTECTED]> wrote: Does anyone know what determines the size of a core dump? I have a process running out of memory (it allocates about 3GB) - but the size of core varies (between 2-3GB) depending on how much the process wrote on the allocated memory. Makes perfect sense. The core dump contains the memory of the process, so if the process has 3GB in use then the core file will be 3GB. You can limit the size of core dumps with "ulimit -c" Also, the time it takes to write the core (same size) varies?? Could be many reasons for that. If the load on the machine varies the time to perform any given action will vary as well. I briefly looked at elf_core_dump and get_user_pages() in binfmt_elf.c. Is there any documentation on this? Or anyone knows how it works? http://x86.ddj.com/ftp/manuals/tools/elf.pdf http://en.wikipedia.org/wiki/Core_dump -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c (kernel 2.6.18.1)
On 30/11/06, David Chinner <[EMAIL PROTECTED]> wrote: On Wed, Nov 29, 2006 at 10:17:25AM +0100, Jesper Juhl wrote: > On 29/11/06, David Chinner <[EMAIL PROTECTED]> wrote: > >On Tue, Nov 28, 2006 at 04:49:00PM +0100, Jesper Juhl wrote: > >> Filesystem "dm-1": XFS internal error xfs_trans_cancel at line 1138 of > >> file fs/xfs/xfs_trans.c. Caller 0x8034b47e > >> > >> Call Trace: > >> [] show_trace+0xb2/0x380 > >> [] dump_stack+0x15/0x20 > >> [] xfs_error_report+0x3c/0x50 > >> [] xfs_trans_cancel+0x6e/0x130 > >> [] xfs_create+0x5ee/0x6a0 > >> [] xfs_vn_mknod+0x156/0x2e0 > >> [] xfs_vn_create+0xb/0x10 > >> [] vfs_create+0x8c/0xd0 > >> [] nfsd_create_v3+0x31a/0x560 > >> [] nfsd3_proc_create+0x148/0x170 > >> [] nfsd_dispatch+0xf9/0x1e0 > >> [] svc_process+0x437/0x6e0 > >> [] nfsd+0x1cd/0x360 > >> [] child_rip+0xa/0x12 > >> xfs_force_shutdown(dm-1,0x8) called from line 1139 of file > >> fs/xfs/xfs_trans.c. Return address = 0x80359daa > > > >We shut down the filesystem because we cancelled a dirty transaction. > >Once we start to dirty the incore objects, we can't roll back to > >an unchanged state if a subsequent fatal error occurs during the > >transaction and we have to abort it. > > > So you are saying that there's nothing I can do to prevent this from > happening in the future? Pretty much - we need to work out what is going wrong and we can't from teh shutdown message above - the error has occurred in a path that doesn't have error report traps in it. Is this reproducable? Not on demand, no. It has happened only this once as far as I know and for unknown reasons. > >If I understand historic occurrences of this correctly, there is > >a possibility that it can be triggered in ENOMEM situations. Was your > >machine running out of memoy when this occurred? > > > Not really. I just checked my monitoring software and, at the time > this happened, the box had ~5.9G RAM free (of 8G total) and no swap > used (but 11G available). Ok. Sounds like we need more error reporting points inserted into that code so we dump an error earlier and hence have some hope of working out what went wrong next time. OOC, there weren't any I/O errors reported before this shutdown? No. I looked but found none. Let me know if there's anything I can do to help. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c (kernel 2.6.18.1)
On 29/11/06, David Chinner <[EMAIL PROTECTED]> wrote: On Tue, Nov 28, 2006 at 04:49:00PM +0100, Jesper Juhl wrote: > Hi, > > One of my NFS servers just gave me a nasty surprise that I think it is > relevant to tell you about: Thanks, Jesper. > Filesystem "dm-1": XFS internal error xfs_trans_cancel at line 1138 of > file fs/xfs/xfs_trans.c. Caller 0x8034b47e > > Call Trace: > [] show_trace+0xb2/0x380 > [] dump_stack+0x15/0x20 > [] xfs_error_report+0x3c/0x50 > [] xfs_trans_cancel+0x6e/0x130 > [] xfs_create+0x5ee/0x6a0 > [] xfs_vn_mknod+0x156/0x2e0 > [] xfs_vn_create+0xb/0x10 > [] vfs_create+0x8c/0xd0 > [] nfsd_create_v3+0x31a/0x560 > [] nfsd3_proc_create+0x148/0x170 > [] nfsd_dispatch+0xf9/0x1e0 > [] svc_process+0x437/0x6e0 > [] nfsd+0x1cd/0x360 > [] child_rip+0xa/0x12 > xfs_force_shutdown(dm-1,0x8) called from line 1139 of file > fs/xfs/xfs_trans.c. Return address = 0x80359daa We shut down the filesystem because we cancelled a dirty transaction. Once we start to dirty the incore objects, we can't roll back to an unchanged state if a subsequent fatal error occurs during the transaction and we have to abort it. So you are saying that there's nothing I can do to prevent this from happening in the future? If I understand historic occurrences of this correctly, there is a possibility that it can be triggered in ENOMEM situations. Was your machine running out of memoy when this occurred? Not really. I just checked my monitoring software and, at the time this happened, the box had ~5.9G RAM free (of 8G total) and no swap used (but 11G available). > Filesystem "dm-1": Corruption of in-memory data detected. Shutting > down filesystem: dm-1 > Please umount the filesystem, and rectify the problem(s) > nfsd: non-standard errno: 5 EIO gets returned in certain locations once the filesystem has been shutdown. Makes sense. > I unmounted the filesystem, ran xfs_repair which told me to try an > mount it first to replay the log, so I did, unmounted it again, ran > xfs_repair (which didn't find any problems) and finally mounted it and > everything is good - the filesystem seems intact. Yeah, the above error report typically is due to an in-memory problem, not an on disk issue. Good to know. > The server in question is running kernel 2.6.18.1 Can happen to XFS on any kernel version - got a report of this from someone running a 2.4 kernel a couple of weeks ago Ok. Thank you for your reply David. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Don't compare unsigned variable for <0 in sys_prctl()
On 29/11/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Wed, 29 Nov 2006, Jesper Juhl wrote: > > I would venture that "-Wshadow" is another one of those. I'd agree, except for the fact that gcc does a horribly _bad_ job of -Wshadow, making it (again) totally unusable. For example, it's often entirely interesting to hear about local variables that shadow each other. No question about it. HOWEVER. It's _not_ really interesting to hear about a local variable that happens to have a common name that is also shared by a extern function. There just isn't any room for confusion, and it's actually not even that unusual - I tried using -Wshadow on real programs, and it was just horribly irritating. In the kernel, we had obvious things like local use of "jiffies" that just make _total_ sense in a small inline function, and the fact that there happens to be an extern declaration for "jiffies" just isn't very interesting. Similarly, with nested macro expansion, even the "local variable shadows another local variable" case - that looks like it should have an obvious warning on the face of it - really isn't always necessarily that interesting after all. Maybe it is a bug, maybe it isn't, but it's no longer _obviously_ bogus any more. So I'm not convinced about the usefulness of "-Wshadow". ESPECIALLY the way that gcc implements it, it's almost totally useless in real life. For example, I tried it on "git" one time, and this is a perfect example of why "-Wshadow" is totally broken: diff-delta.c: In function 'create_delta_index': diff-delta.c:142: warning: declaration of 'index' shadows a global declaration (and there's a _lot_ of those). If I'm not allowed to use "index" as a local variable and include at the same time, something is simply SERIOUSLY WRONG with the warning. So the fact is, the C language has scoping rules for a reason. Can you screw yourself by usign them badly? Sure. But that does NOT mean that the same name in different scopes is a bad thing that should be warned about. If I wanted a language that didn't allow me to do anything wrong, I'd be using Pascal. As it is, it turns out that things that "look" wrong on a local level are often not wrong after all. I can't really say anything else at this point but, point conceded... -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Don't compare unsigned variable for <0 in sys_prctl()
On 29/11/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Tue, 28 Nov 2006, Jesper Juhl wrote: > > > Friends don't let friends use "-W". > > Hehe, ok, I'll stop cleaning this stuff up then. > Nice little hobby out the window there ;) You might want to look at some of the other warnings gcc spits out, but this class isn't one of them. Other warnings we have added over the years (and that really _are_ good warnings) have included the "-Wstrict-prototypes", and some other ones. If you can pinpoint _which_ gcc warning flag it is that causes gcc to emit the bogus ones, you _could_ try "-W -Wno-xyz-warning", which should cause gcc to enable all the "other" warnings, but then not the "xyz-warning" that causes problems. Of course, there is often a reason why a warning is in "-W" but not in "-Wall". Most of the time it's sign that the warning is bogus. Not always, though - we do tend to want to be fairly strict, and Wstrict-prototypes is an example of a _good_ warning that is not in -Wall. I would venture that "-Wshadow" is another one of those. I've, in the past, submitted quite a few patches to clean up shadow warnings (some accepted, some not) and I'll probably try going down that path again in the near future. It's a class of warnings that have the potential to uncover real bugs (even if we don't currently have any) and it would be a nice one to be able to enable by default in the Makefile. I agree with you though that the "expression always false|true due to unsigned" type of warnings are usually bogus - although there have actually been real bugs hiding behind some of those warnings in the past. But, I'll make sure to only submit patches for that type of warnings in the future if I can prove that the warning actually uncovered a real bug. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Don't compare unsigned variable for <0 in sys_prctl()
On 28/11/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Tue, 28 Nov 2006, Jesper Juhl wrote: > > In kernel/sys.c::sys_prctl() the argument named 'arg2' is very clearly > of type 'unsigned long', and when compiling with "gcc -W" gcc also warns : > kernel/sys.c:2089: warning: comparison of unsigned expression < 0 is always false > > So this patch removes the test of "arg2 < 0". No, we don't do this. This is why we don't compile with "-W". Gcc is crap. The fact is, if it's unsigned, it's not something that the programmer should have to care about. We should write our code to be readable and obviously safe, and that means that if (x < 0 || x > MAX) return -ERROR; is the _right_ way to do things, without having to carry stupid context around in our heads. If the compiler (whose _job_ it is to carry all that context and use it to generate good code) notices that the fact that "x" is unsignes means that one of the tests is unnecessary, that does not make it wrong. Gcc warns for a lot of wrong things. This is one of them. Friends don't let friends use "-W". Hehe, ok, I'll stop cleaning this stuff up then. Nice little hobby out the window there ;) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Don't compare unsigned variable for <0 in sys_prctl()
In kernel/sys.c::sys_prctl() the argument named 'arg2' is very clearly
of type 'unsigned long', and when compiling with "gcc -W" gcc also warns :
kernel/sys.c:2089: warning: comparison of unsigned expression < 0 is always
false
So this patch removes the test of "arg2 < 0".
For those of us who compile their kernels with "-W" this gets rid of an
annoying warning. For the rest of you it saves a few bytes of source code ;-)
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
diff --git a/kernel/sys.c b/kernel/sys.c
index 98489d8..086ea37 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2086,7 +2086,7 @@ asmlinkage long sys_prctl(int option, un
error = current->mm->dumpable;
break;
case PR_SET_DUMPABLE:
- if (arg2 < 0 || arg2 > 1) {
+ if (arg2 > 1) {
error = -EINVAL;
break;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] REPORTING-BUGS: request .config file
On 28/11/06, Randy Dunlap <[EMAIL PROTECTED]> wrote: From: Randy Dunlap <[EMAIL PROTECTED]> Add kernel .config file to REPORTING-BUGS. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Given how often people ask for the config, it makes good sense to have that in the document. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c (kernel 2.6.18.1)
Hi, One of my NFS servers just gave me a nasty surprise that I think it is relevant to tell you about: Filesystem "dm-1": XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0x8034b47e Call Trace: [] show_trace+0xb2/0x380 [] dump_stack+0x15/0x20 [] xfs_error_report+0x3c/0x50 [] xfs_trans_cancel+0x6e/0x130 [] xfs_create+0x5ee/0x6a0 [] xfs_vn_mknod+0x156/0x2e0 [] xfs_vn_create+0xb/0x10 [] vfs_create+0x8c/0xd0 [] nfsd_create_v3+0x31a/0x560 [] nfsd3_proc_create+0x148/0x170 [] nfsd_dispatch+0xf9/0x1e0 [] svc_process+0x437/0x6e0 [] nfsd+0x1cd/0x360 [] child_rip+0xa/0x12 xfs_force_shutdown(dm-1,0x8) called from line 1139 of file fs/xfs/xfs_trans.c. Return address = 0x80359daa Filesystem "dm-1": Corruption of in-memory data detected. Shutting down filesystem: dm-1 Please umount the filesystem, and rectify the problem(s) nfsd: non-standard errno: 5 nfsd: non-standard errno: 5 nfsd: non-standard errno: 5 nfsd: non-standard errno: 5 nfsd: non-standard errno: 5 (the above message repeates 1670 times, then the following) xfs_force_shutdown(dm-1,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return address = 0x80359daa I unmounted the filesystem, ran xfs_repair which told me to try an mount it first to replay the log, so I did, unmounted it again, ran xfs_repair (which didn't find any problems) and finally mounted it and everything is good - the filesystem seems intact. Filesystem "dm-1": Disabling barriers, not supported with external log device XFS mounting filesystem dm-1 Starting XFS recovery on filesystem: dm-1 (logdev: /dev/Log1/ws22_log) Ending XFS recovery on filesystem: dm-1 (logdev: /dev/Log1/ws22_log) Filesystem "dm-1": Disabling barriers, not supported with external log device XFS mounting filesystem dm-1 Ending clean XFS mount for filesystem: dm-1 The server in question is running kernel 2.6.18.1 -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reserving a fixed physical address page of RAM.
On 28/11/06, Fawad Lateef <[EMAIL PROTECTED]> wrote: On 11/28/06, Dave Airlie <[EMAIL PROTECTED]> wrote: > On 11/28/06, Jon Ringle <[EMAIL PROTECTED]> wrote: > > It looks promising, however, I need to reserve a physical address area > > that is well known (so that the code running on the other processor > > knows where in PCI memory to write to). It appears that > > dma_alloc_coherent returns the address that it allocated. Instead I need > > something where I can tell it what physical address and range I want to use. > > > > I've seen other projects just boot a 128M board with mem=120M and just > use the 8MB at 120 to talk to the other processor.. > Yes, this can be used if required physical-memory exists in the last part of RAM as if you use mem= then kernel will only use memory less than or equal-to and above can be used by drivers (or any kernel module) might be through ioremap which takes physical-address. But if lets say we need only 1MB portion of specific physical-memory region then AFAIK it must be done by hacking in kernel code during memory-initialization (mem_init function) where it is marking/checking pages as/are reserved; you can simply mark you required pages as reserved too and set their count to some-value if you want to know later which pages are reserved by you. (can do this reservation work here: http://lxr.free-electrons.com/source/arch/i386/mm/init.c#605). CMIIW Can you not use the 'memmap=' kernel option to reserve the specific area you need? (See Documentation/kernel-parameters.txt for details) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Clean up "make help" output for documentation targets
Here's a patch that cleans up the "make help" output a bit for the documentation targets. Surrently the documentation targets are listed completely different than all the other targets : Documentation targets: Linux kernel internal documentation in different formats: xmldocs (XML DocBook), psdocs (Postscript), pdfdocs (PDF) htmldocs (HTML), mandocs (man pages, use installmandocs to install) with this patch they are more in line with the rest of the output : Documentation targets: Linux kernel internal documentation in different formats: htmldocs- HTML installmandocs - install man pages generated by mandocs mandocs - man pages pdfdocs - PDF psdocs - Postscript xmldocs - XML DocBook Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- Documentation/DocBook/Makefile | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index db9499a..36526a1 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -190,9 +190,13 @@ # Rule to convert a .c file to inline XM ### # Help targets as used by the top-level makefile dochelp: - @echo ' Linux kernel internal documentation in different formats:' - @echo ' xmldocs (XML DocBook), psdocs (Postscript), pdfdocs (PDF)' - @echo ' htmldocs (HTML), mandocs (man pages, use installmandocs to install)' + @echo ' Linux kernel internal documentation in different formats:' + @echo ' htmldocs- HTML' + @echo ' installmandocs - install man pages generated by mandocs' + @echo ' mandocs - man pages' + @echo ' pdfdocs - PDF' + @echo ' psdocs - Postscript' + @echo ' xmldocs - XML DocBook' ### # Temporary files left by various tools - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] potential NULL pointer deref in net/key/af_key.c
On 27/11/06, David Miller <[EMAIL PROTECTED]> wrote: From: Jesper Juhl <[EMAIL PROTECTED]> Date: Mon, 27 Nov 2006 22:44:07 +0100 > In net/key/af_key.c::pfkey_send_policy_notify() there's a check at the > beginning of the function : > > if (xp && xp->type != XFRM_POLICY_TYPE_MAIN) > > this implies that 'xp' may be null when the function is called. But later > on in the function we have this code : > > return key_notify_policy(xp, dir, c); > > key_notify_policy() passes 'xp' to pfkey_xfrm_policy2msg_prep() that pass > it on to pfkey_xfrm_policy2msg_size() which dereferences it. > key_notify_policy() also passes 'xp' to pfkey_xfrm_policy2msg() which > also dereferences it. > > So, in pfkey_send_policy_notify() in the cases where we end up calling > key_notify_policy(), we should test 'xp' for NULL. > > (note: patch is compile tested only) > > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> We really need to teach your automated tool about context. The NULL case can only occur for XFRM_MSG_FLUSHPOLICY. Look at the km_policy_notify() call sites. You can even see from the net/xfrm/xfrm_user.c:xfrm_send_policy_notify() implementation of this callback that for XFRM_MSG_FLUSHPOLICY the "xp" argument is ignored. Arrgh, you are right. I really need to check call sites more carefully :( -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IDE: typo in ide-io.c leads to faulty assignment
On 27/11/06, Elias Oltmanns <[EMAIL PROTECTED]> wrote: Due to a typo in ide_start_power_step, the result of a function rather than its pointer is assigned to args->handler. The patch applies to 2.6.19-rc6 but the problem exists in the stable branch as well. These two lines : - args->handler = task_no_data_intr; + args->handler = &task_no_data_intr; do the same thing. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel: Please report the result to linux-kernel to fix this permanently
On 27/11/06, Hanno Böck <[EMAIL PROTECTED]> wrote: My kernel says Oct 7 18:25:00 laverne kernel: Please report the result to linux-kernel to fix this permanently so I do this. Replys CC to me, cause I'm not on this list. ... Oct 7 18:25:00 laverne kernel: PCI: Bus #04 (-#07) is hidden behind transparent bridge #02 (-#04) (try 'pci=assign-busses') Oct 7 18:25:00 laverne kernel: Please report the result to linux-kernel to fix this permanently And what are the results when you use "pci=assign-busses" as your kernel asks you to do ? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] 2.6.17.8 - do_vfs_lock: VFS is out of sync with lock manager!
Any chance we could get the patch below (or something similar) pushed
into 2.6.19?
On 21/11/06, Jesper Juhl <[EMAIL PROTECTED]> wrote:
On 21/08/06, Trond Myklebust <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-08-21 at 13:34 +1000, Neil Brown wrote:
> > Looking in fs/nfs/file.c (at 2.6.18-rc4-mm1 if it matters, but 2.6.17
> > is much the same)
> >
> > - do_vfs_lock is only called when the filesystem was mounted with
> > -o nolock EXCEPT
> > - If a lock request to the server in interrupted (when mounted with
> > -o intr) then do_vfs_lock is called to try to get the lock
> > locally. Normally equivalent code will be called inside
> > fs/lockd/clntproc.c when the server replies that the lock has been
> > gained. In the case of an interrupt though this doesn't happen
> > but the lock may still have happened on the server. So we record
> > locally that the lock was gained, to ensure that it gets unlocked
> > when the process exits.
> >
> > As you don't have '-o nolocks' you must be hitting the second case.
> > The lock call to the server returns -EINTR or -ERESTARTSYS and
> > do_vfs_lock is called just-in-case.
> > As this is a just-in-case call, it is quite possible that the lock is
> > held by some other process, so getting an error is entirely possible.
> > So printing the message in this case seems wrong.
> >
> > On the other hand, printing the message in any other case seems wrong
> > too, as server locking is not being used, so there is nothing to get
> > out of sync with.
> >
> > As a further complication, I don't think that in the just-in-case
> > situation that it should risk waiting for the lock.
> > Now maybe we can be sure there is a pending signal which will break
> > out of any wait (though I'm worried about -ERESTARTSYS - that doesn't
> > imply a signal does it?), but I would feel more comfortable if
> > FL_SLEEP were turned off in that path.
> >
> > So: Trond: Any obvious errors in the above?
> > Is the following patch ok?
>
> Could we instead replace it with a dprintk() that returns the value of
> "res"? That will keep it useful for debugging purposes.
>
How about the below?
(compile tested only)
Neil: I left your Signed-off-by line since I just modified your patch slightly.
Since Gmail will probably mangle the inline patch, it is attached as well.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--
fs/nfs/file.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index cc93865..22572af 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -428,8 +428,8 @@ static int do_vfs_lock(struct file *file
BUG();
}
if (res < 0)
- printk(KERN_WARNING "%s: VFS is out of sync with lock
manager!\n",
- __FUNCTION__);
+ dprintk("%s: VFS is out of sync with lock manager (res
= %d)!\n",
+ __FUNCTION__, res);
return res;
}
@@ -479,10 +479,13 @@ static int do_setlk(struct file *filp, i
* we clean up any state on the server. We therefore
* record the lock call as having succeeded in order to
* ensure that locks_remove_posix() cleans it out when
-* the process exits.
+* the process exits. Make sure not to sleep if
+* someone else holds the lock.
*/
- if (status == -EINTR || status == -ERESTARTSYS)
+ if (status == -EINTR || status == -ERESTARTSYS) {
+ fl->fl_flags &= ~FL_SLEEP;
do_vfs_lock(filp, fl);
+ }
} else
status = do_vfs_lock(filp, fl);
unlock_kernel();
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
IPv4: ip_options_compile() how can we avoid blowing up on a NULL skb???
Hi,
In net/ipv4/ip_options.c::ip_options_compile() we have the following
code at the start of the function :
int ip_options_compile(struct ip_options * opt, struct sk_buff * skb)
{
int l;
unsigned char * iph;
unsigned char * optptr;
int optlen;
unsigned char * pp_ptr = NULL;
struct rtable *rt = skb ? (struct rtable*)skb->dst : NULL;
if (!opt) {
opt = &(IPCB(skb)->opt);
iph = skb->nh.raw;
opt->optlen = ((struct iphdr *)iph)->ihl*4 -
sizeof(struct iphdr);
optptr = iph + sizeof(struct iphdr);
opt->is_data = 0;
} else {
optptr = opt->is_data ? opt->__data : (unsigned
char*)&(skb->nh.iph[1]);
iph = optptr - sizeof(struct iphdr);
}
...
I don't see how that avoids blowing up if we get passed a NULL skb.
From the line
struct rtable *rt = skb ? (struct rtable*)skb->dst : NULL;
it is clear that we /may/ get passed a null skb.
Then a bit further down in the if (!opt) bit we dereference 'skb' :
opt = &(IPCB(skb)->opt);
and we also may dereference it in the else part :
optptr = opt->is_data ? opt->__data : (unsigned char*)&(skb->nh.iph[1]);
So if 'skb' is NULL, the only route I see that doesn't cause a NULL
pointer deref is if (opt != NULL) and at the same time
(opt->is_data != NULL) . Is that guaranteed in any way? If now,
how come we don't blow up regularly?
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC][resend] potential NULL pointer deref in XFS on failed mount
On 16/11/06, David Chinner <[EMAIL PROTECTED]> wrote: On Thu, Nov 16, 2006 at 10:18:26PM +0100, Jesper Juhl wrote: > (got no reply on this when I originally send it on 20061031, so resending > now that a bit of time has passed. The patch still applies cleanly to > Linus' git tree as of today.) > > > The Coverity checker spotted a potential problem in XFS. > > The problem is that if, in xfs_mount(), this code triggers: > > ... > if (!mp->m_logdev_targp) > goto error0; > ... > > Then we'll end up calling xfs_unmountfs_close() with a NULL > 'mp->m_logdev_targp'. > This in turn will result in a call to xfs_free_buftarg() with its 'btp' > argument == NULL. xfs_free_buftarg() dereferences 'btp' leading to > a NULL pointer dereference and crash. Interesting that coverity found that, but failed to find the other leaks in that function from exactly the same code and error case. > I think this can happen, since the fatal call to xfs_free_buftarg() > happens when 'm_logdev_targp != m_ddev_targp' and due to a check of > 'm_ddev_targp' against NULL in xfs_mount() (and subsequent return if it is > NULL) the two will never both be NULL when we hit the error0 label from > the two lines cited above. > > Comments welcome (please keep me on Cc: on replies). > > Here's a proposed patch to fix this by testing 'btp' against NULL in > xfs_free_buftarg(). Not the right fix - we should only be trying to free valid buftargs, which means xfs_unmountfs_close() is the correct place to fix this Ok. e.g: - if (mp->m_logdev_targp != mp->m_ddev_targp) + if (mp->m_logdev_targp && (mp->m_logdev_targp != mp->m_ddev_targp)) As to the afore-mentioned leaks, if we fail to allocate a realtime buftarg, then we will leak a reference to both the rtdev and logdev, and if we fail to allocate an external log buftarg we'll leak a reference to the logdev. i.e., we fail to do one or both of: xfs_blkdev_put(logdev); xfs_blkdev_put(rtdev); To remove the bdev references we may have gained earlier. Normally, these references are released by xfs_free_buftarg(), but because we failed to allocate the buftarg, we can't drop the references via that method Thanks a lot for commenting Dave. I don't have time to look more at this tonight or tomorrow, but I'll try to cook up a proper fix covering all cases during the weekend. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC][resend] potential NULL pointer deref in XFS on failed mount
On 16/11/06, Shailendra Tripathi <[EMAIL PROTECTED]> wrote:
Hey Jesper,
Rather, it can be done as below. Nothing to say that
your code wouldn't work. Just that catch it early, so that potential
function call overhead to call xfs_free_buftarg can be avoided.
Hi Shailendra,
The reason I want to fix it in the freeing function is that many other
functions in the kernel that free resources are safe to call with NULL
pointers and this would make xfs_free_buftarg() follow that
convention. This would perhaps also allow for some cleanups in other
places that call the function since then there's no longer a need for
explicit NULL checks any more (haven't checked if there's anything to
gain there though).
I don't think the function call overhead matters much since this is in
a case of a failed mount, so it should happen very rarely.
void
xfs_unmountfs_close(xfs_mount_t *mp, struct cred *cr)
{
if (mp->m_logdev_targp && (mp->m_logdev_targp != mp->m_ddev_targp))
xfs_free_buftarg(mp->m_logdev_targp, 1);
if (mp->m_rtdev_targp)
xfs_free_buftarg(mp->m_rtdev_targp, 1);
xfs_free_buftarg(mp->m_ddev_targp, 0);
}
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to go about debuging a system lockup?
On 16/11/06, Lennart Sorensen <[EMAIL PROTECTED]> wrote: On Thu, Nov 16, 2006 at 09:49:06PM +0100, Jesper Juhl wrote: ... > - You could also try kdb (http://oss.sgi.com/projects/kdb/) or kgdb > (http://kgdb.linsyssoft.com/). That might help you pinpoint the > failure. Can I run that remotely somehow? I never really looked at kdb or kgdb before. Yes you can. kgdb is run on a separate machine from the one you are debugging. > - If you have (or can identify) an older, working, kernel version and > you are confident that you can reproduce the problem reliably, then > doing a git bisection search starting with your newest "known good" > and oldest "known bad" kernel versions, should help you pinpoint the > commit causing the breakage. I don't know of a good version yet. I so far don't know if there ever was one. This could even be a bug in the PCI hardware, or the way the BIOS on this system on a board configured the PCI controller. Maybe I should go back and try a 2.4 kernel. Or just try a few random older 2.6 kernels like 2.6.14, 2.6.9, 2.6.whatever (of course it needs to be a version that git knows about). -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][RFC][resend] potential NULL pointer deref in XFS on failed mount
(got no reply on this when I originally send it on 20061031, so resending
now that a bit of time has passed. The patch still applies cleanly to
Linus' git tree as of today.)
The Coverity checker spotted a potential problem in XFS.
The problem is that if, in xfs_mount(), this code triggers:
...
if (!mp->m_logdev_targp)
goto error0;
...
Then we'll end up calling xfs_unmountfs_close() with a NULL
'mp->m_logdev_targp'.
This in turn will result in a call to xfs_free_buftarg() with its 'btp'
argument == NULL. xfs_free_buftarg() dereferences 'btp' leading to
a NULL pointer dereference and crash.
I think this can happen, since the fatal call to xfs_free_buftarg()
happens when 'm_logdev_targp != m_ddev_targp' and due to a check of
'm_ddev_targp' against NULL in xfs_mount() (and subsequent return if it is
NULL) the two will never both be NULL when we hit the error0 label from
the two lines cited above.
Comments welcome (please keep me on Cc: on replies).
Here's a proposed patch to fix this by testing 'btp' against NULL in
xfs_free_buftarg().
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
fs/xfs/linux-2.6/xfs_buf.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/xfs/linux-2.6/xfs_buf.c b/fs/xfs/linux-2.6/xfs_buf.c
index db5f5a3..6ef1860 100644
--- a/fs/xfs/linux-2.6/xfs_buf.c
+++ b/fs/xfs/linux-2.6/xfs_buf.c
@@ -1450,6 +1450,9 @@ xfs_free_buftarg(
xfs_buftarg_t *btp,
int external)
{
+ if (unlikely(!btp))
+ return;
+
xfs_flush_buftarg(btp, 1);
if (external)
xfs_blkdev_put(btp->bt_bdev);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to go about debuging a system lockup?
On 16/11/06, Lennart Sorensen <[EMAIL PROTECTED]> wrote: We have a router with a Geode SC1200 cpu, with 4 AMD 972 ethernet ports (pcnet32) behind a PLX 6152 PCI-PCI bridge, which quite regularly locks up completely if we try to do simultanius traffic on all 4 ports (our test case sends data from port 1 to port 2, and back and from port 3 to port 4 and back at a rate of 8000 packets per second using 1500byte packets). We usually manage to run the test for about 1 minute before the system hangs. This happens on every one of the systems we have tried so far. If we only run 2 ports, it seems to never die, and with 3 ports we haven't seen any failures yet, although maybe we just haven't tested long enough. If we just receive the packets but don't forward them out again, then we never crash, so it seems to be related to simultanious transmit on the pcnet32s. So far I have tried printing a message everytime the pcnet32 driver enables and disables interrupts to find out if it hangs somewhere with interrupts disabled, but that didn't seem to indicate anything meaningful. So far I have tried this with 2.6.8, 2.6.16.22, and 2.6.18.2 and no difference so far. I can't think of what kind of even could cause the system to just hang with no further console output or a kernel panic or oops or anything. Usually most errors produce some kind of message. Does anyone have any suggestions for where I go from here to find out what is happening and where to look? I don't even know if I should suspect the hardware or the software at this point. I want to know if the program counter is still changing, or if the cpu is simply hung or something, but I have no idea how to get at that. Well, I have a few ideas that are hopefully useul. - If you have not done so already, then go in to the "Kernel Hacking" section of the kernel configuration and enable some (all?) of the debug options and see if that produces anything that will help you track down the problem. - You could enable 'magic sysrq' and see if you can manage to get a backtrace with it when it hangs (see Documentation/sysrq.txt) (ohh and raise the console log level so you get all messages, including debug ones). - You could also try kdb (http://oss.sgi.com/projects/kdb/) or kgdb (http://kgdb.linsyssoft.com/). That might help you pinpoint the failure. See also : http://kerneltrap.org/node/112 - If you have (or can identify) an older, working, kernel version and you are confident that you can reproduce the problem reliably, then doing a git bisection search starting with your newest "known good" and oldest "known bad" kernel versions, should help you pinpoint the commit causing the breakage. Hope some of that helps :) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
the Month of Kernel Bugs (MoKB) archive
I just stumbled across "the Month of Kernel Bugs (MoKB) archive" - http://projects.info-pull.com/mokb/ It's a page that will release 1 kernel bug each day for all of this month. There are some Linux kernel bugs listed as well as bugs for other OS kernels. Just wanted to bring it to the attention of a wider audience in case he lists some new/unknown bugs that we ought to fix. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rmmod notifier chain
On 9/9/05, Jan Beulich <[EMAIL PROTECTED]> wrote: [snip] > > First, I rarely saw any kind of positive review feedback from lkml > besides the notification that you added something to your -mm tree > (negative things of course always arrive), yet no feedback at all is far [snip] I wouldn't say only negative feedback is the general rule. I've posted lots of patches where people have send comments like "looks good", "thanks, applied", "generally OK, but please change this or that little bit", etc... And I see the same for many other peoples patches. Positive feedback does happen. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to plan a kernel update ?
On 9/8/05, Weber Ress <[EMAIL PROTECTED]> wrote: > Hi, > > I'm responsible to planning a kernel upgrade in many servers, from 2.4 > version to 2.6.13 (last stable version), using Debian 3.1r0a > > My team has good technical skills, but they need to be led. I would > like know, what's the best pratices and recommendations that a project > manager need think BEFORE an kernel upgrade. > > A technical guy have a particular vision about this upgrade, but I > will be very been thankful if I receive from this community another > vision.. a vision centered in the project process (planning, > executing, controlling) to make this activity successfully. > Ok, I'm no project manager, I guess I'd be clasified as one of the "technical guys", but I do upgrade a lot of kernels, so I'll tell you a little about what I do and what I'd recommend. Then you can do with that info what you like :) The very first thing you want to do is to ensure that all core utilities/tools are up-to-date to versions that will work with your new kernel. If you download a copy of the 2.6.13 kernel source, extract it, and look in the file Documentation/Changes you'll see a list of tools and utils along with the minimum required version for them to work properly with that kernel. Ensure those tools are OK. Once you are sure the core utils are up-to-date you need to go check whatever other important programs you have on the machine(s) and check that those are also able to run OK with the new kernel. Once you are satisfied that everything is up to a level that'll work with the new kernel you can go build the new 2.6.13 kernel and drop it in place. You don't need to remove your existing kernel first, you can just install the 2.6.13 kernel side by side with the old one and test boot it, then if it doesn't work right you can always reboot back to the old one. Most likely you can find documentation for your distribution stating what version of it is "2.6 ready" - I use Slackware for example, and Slackware 10.1 is completely 2.6 kernel ready, so on a Slackware 10.1 box there's no hassle at all, I just drop in a 2.6 kernel in place of the 2.4 one it installs by default and everything is good - all tools are already ready to cope. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1
On 9/7/05, Paul Jackson <[EMAIL PROTECTED]> wrote: > Andrew wrote" > > So then I was asked to include an explanation > > with the drop message and that all got too hard so I turned them off. > > > > > > > Dang it, Andrew. It didn't have to be hard. Just adding a > boiler plate sentence to all the drop messages saying something > like: > > If I just sent the patch to Linus, that is > probably why I dropped it here. > > That should be enough of a clue for most folks. I agree completely. Something like that would be just fine for the patches that have been sent on to Linus. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild & C++
On 9/7/05, Esben Nielsen <[EMAIL PROTECTED]> wrote: > On Tue, 6 Sep 2005, Jesper Juhl wrote: > > > On 9/6/05, Budde, Marco <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > for one of our customers I have to port a Windows driver to > > > Linux. Large parts of the driver's backend code consists of > > > C++. > > > > > > How can I compile this code with kbuild? The C++ support > > > (I have tested with 2.6.11) of kbuild seems to be incomplete / > > > not working. > > > > > > > That would be because the kernel is written in *C* (and some asm), *not* > > C++. > > There /is/ no C++ support. > > Which is too bad. You can do stuff much more elegant, effectively and > safer in C++ than in C. Yes, you can do inheritance in C, but it leaves > it up to the user to make sure the type-casts are done OK every time. You > can with macros do some dynamic typing, but not nearly as effectively as > with templates, and those macros always comes very, very ugly. (Some say > templates are ugly, but they first become ugly when they are used > way beyond what you can do with macros.) > > I think it can only be a plus to Linux to add C++ support for at least > out-of-mainline drivers. Adding drivers written in C++ into the mainline > is another thing. > I was not trying to start a discussion about the merrits of C vs C++. I was simply responding to marco's comment that "C++ support ... of kbuild seems to be incomplete / not working". As for C++ vs C. I don't have anything against C++. I use it a lot for userspace programs. I'm not sure I agree that it would be appropriate for the kernel though, but that's a whole other discussion. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild & C++
On 9/6/05, Budde, Marco <[EMAIL PROTECTED]> wrote: > Hi, > > for one of our customers I have to port a Windows driver to > Linux. Large parts of the driver's backend code consists of > C++. > > How can I compile this code with kbuild? The C++ support > (I have tested with 2.6.11) of kbuild seems to be incomplete / > not working. > That would be because the kernel is written in *C* (and some asm), *not* C++. There /is/ no C++ support. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] wrong firmware location in IPW2100 Kconfig entry (Was: IPW2100 Kconfig)
On Tuesday 06 September 2005 20:32, Alejandro Bonilla wrote: > Hi, > > I checked the IPW2100 in the current git from linux-2.6 and the > menuconfig > help (Kconfig) says you need to put the firmware in /etc/firmware, it should > be /lib/firmware. > > Who should I send the "patch" to? Or can someone simply change that? > Firmware should go into /lib/firmware, not /etc/firmware. Found by Alejandro Bonilla. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/net/wireless/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.13-mm1-orig/drivers/net/wireless/Kconfig 2005-09-02 23:59:51.0 +0200 +++ linux-2.6.13-mm1/drivers/net/wireless/Kconfig 2005-09-06 20:39:45.0 +0200 @@ -152,7 +152,7 @@ In order to use this driver, you will need a firmware image for it. You can obtain the firmware from <http://ipw2100.sf.net/>. Once you have the firmware image, you - will need to place it in /etc/firmware. + will need to place it in /lib/firmware. You will also very likely need the Wireless Tools in order to configure your card: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nfs4 client bug
On 9/5/05, Bret Towe <[EMAIL PROTECTED]> wrote: > On 9/4/05, J. Bruce Fields <[EMAIL PROTECTED]> wrote: > > On Sun, Sep 04, 2005 at 08:08:22PM -0700, Bret Towe wrote: > > > On 9/4/05, J. Bruce Fields <[EMAIL PROTECTED]> wrote: > > > > Do you get anything from alt-sysrq-T? > > > > > > no i havent used that im usally in x when its freezing > > > x wont even switch to console would it still give me anything then? > > > > Well, you can try something like: > > alt-sysrq-T > > wait a couple seconds, then > > alt-sysrq-S > > alt-sysrq-U > > alt-sysrq-B > > with maybe a second between each to give stuff a chance to get to disk. > > > > Then if you're lucky you may find the stack dumps in your log after you > > reboot. > > tried it and so far no luck ill keep trying a few more times and see > if i can get it > to spit somethin out to disk but i dont think ill be that lucky as that would > prob make life to easy wouldnt it? How about serial console over a cross-over cable to a second box. netconsole will let you put the console on a different box over the network. console on line printer will let you have a permanent record of the console output on paper. See Documentation/serial-console.txt Documentation/networking/netconsole.txt the help entry for "config LP_CONSOLE" (in drivers/char/Kconfig) Would any of those perhaps help you in capturing anything ? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Omnikey Cardman 4000 driver
On 9/6/05, Harald Welte <[EMAIL PROTECTED]> wrote: > Hi! > [snip] > > Please consider mergin mainline, thanks. > [snip] Wouldn't it be better to first merge it in -mm and get some wider testing before pushing for mainline? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Omnikey Cardman 4000 driver
On 9/6/05, Harald Welte <[EMAIL PROTECTED]> wrote: > Hi! > > Following-up to the Cardman 4040 driver, I'm now sumitting a driver for > the Cardman 4000 reader. It is, too, a PCMCIA smartcard reader and the > predecessor of the 4040. > > From a technical point of view, the two devices have nothing in common, > so there is no possibility of code sharing. > > Please consider mergin mainline, thanks. > > Note: The patch is incremental to the Cardman 4040 driver that has > already been submitted. > [snip] Please see my CodingStyle comments for your previous driver as well as the cleanup patch I just posted for that one. A lot of those issues apply to your new driver as well - care to clean that up? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Omnikey Cardman 4040 driver
On Monday 05 September 2005 22:05, Jesper Juhl wrote:
> On Monday 05 September 2005 21:54, Harald Welte wrote:
> > Hi!
> >
> > I've now incorporated all the suggested changes (thanks once again on
> > the many comments received). The resulting driver has been tested and
> > works fine.
> >
> > Please consider applying the driver to the mainline tree, thanks.
> >
> What did you diff this against? When I applied it to the 2.6.13 source I got
> :
>
> patching file MAINTAINERS
> Hunk #1 succeeded at 1730 (offset -7 lines).
> patching file drivers/char/pcmcia/Kconfig
> patching file drivers/char/pcmcia/Makefile
> patching file drivers/char/pcmcia/cm4040_cs.c
> patching file drivers/char/pcmcia/cm4040_cs.h
>
> Anyway, I did a small cleanup.
> Removed all instances of trailing whitespace ( sed -r s/"[ \t]+$"/""/ ).
> Removed some excessive (IMHO) use of blank lines.
> A few CodingStyle related whitespace fixes (spaces after "," etc).
> Removed some pointless casts.
>
> Hope this is useful to you (applies on top of the version you just posted).
>
Actually, forget the previous patch, I forgot a few things. Improved patch can
be found below (a few extra cleanups of spacing and make the header look a
little more pretty).
/Jesper Juhl
--- drivers/char/pcmcia/cm4040_cs.c.orig2005-09-05 21:39:05.0
+0200
+++ drivers/char/pcmcia/cm4040_cs.c 2005-09-05 22:20:38.0 +0200
@@ -1,4 +1,4 @@
- /*
+/*
* A driver for the Omnikey PCMCIA smartcard reader CardMan 4040
*
* (c) 2000-2004 Omnikey AG (http://www.omnikey.com/)
@@ -68,28 +68,25 @@ static char *version =
static void reader_release(dev_link_t *link);
static void reader_detach(dev_link_t *link);
-static int major;
+static int major;
#defineBS_READABLE 0x01
#defineBS_WRITABLE 0x02
struct reader_dev {
- dev_link_t link;
- dev_node_t node;
- wait_queue_head_t devq;
-
+ dev_link_t link;
+ dev_node_t node;
+ wait_queue_head_t devq;
wait_queue_head_t poll_wait;
wait_queue_head_t read_wait;
wait_queue_head_t write_wait;
-
unsigned intbuffer_status;
-
unsigned inttimer_expired;
struct timer_list timer;
unsigned long timeout;
unsigned char s_buf[READ_WRITE_BUFFER_SIZE];
unsigned char r_buf[READ_WRITE_BUFFER_SIZE];
- struct task_struct *owner;
+ struct task_struct *owner;
};
static dev_info_t dev_info = MODULE_NAME;
@@ -104,7 +101,7 @@ static struct timer_list cm4040_poll_tim
static inline void xoutb(unsigned char val, unsigned short port)
{
DEBUG(7, "outb(val=%.2x,port=%.4x)\n", val, port);
- outb(val,port);
+ outb(val, port);
}
static inline unsigned char xinb(unsigned short port)
@@ -122,7 +119,7 @@ static inline unsigned char xinb(unsigne
static void cm4040_do_poll(unsigned long dummy)
{
unsigned int i;
- /* walk through all devices */
+ /* walk through all devices */
for (i = 0; dev_table[i]; i++) {
dev_link_t *dl = dev_table[i];
struct reader_dev *dev = dl->priv;
@@ -156,7 +153,7 @@ static int wait_for_bulk_out_ready(struc
int i, rc;
int iobase = dev->link.io.BasePort1;
- for (i=0; i < POLL_LOOP_COUNT; i++) {
+ for (i = 0; i < POLL_LOOP_COUNT; i++) {
if ((xinb(iobase + REG_OFFSET_BUFFER_STATUS)
& BSR_BULK_OUT_FULL) == 0) {
DEBUG(4, "BulkOut empty (i=%d)\n", i);
@@ -191,7 +188,7 @@ static int write_sync_reg(unsigned char
if (rc <= 0)
return rc;
- xoutb(val,iobase + REG_OFFSET_SYNC_CONTROL);
+ xoutb(val, iobase + REG_OFFSET_SYNC_CONTROL);
rc = wait_for_bulk_out_ready(dev);
if (rc <= 0)
return rc;
@@ -204,7 +201,7 @@ static int wait_for_bulk_in_ready(struct
int i, rc;
int iobase = dev->link.io.BasePort1;
- for (i=0; i < POLL_LOOP_COUNT; i++) {
+ for (i = 0; i < POLL_LOOP_COUNT; i++) {
if ((xinb(iobase + REG_OFFSET_BUFFER_STATUS)
& BSR_BULK_IN_FULL) == BSR_BULK_IN_FULL) {
DEBUG(3, "BulkIn full (i=%d)\n", i);
@@ -215,7 +212,7 @@ static int wait_for_bulk_in_ready(struct
DEBUG(4, "wait_event_interruptible_timeout(timeout=%ld\n",
dev->timeout);
rc = wait_event_interruptible_timeout(dev->read_wait,
- test_and_clear_bit(BS_READABLE,
+
Re: [PATCH] Omnikey Cardman 4040 driver
On Monday 05 September 2005 21:54, Harald Welte wrote:
> Hi!
>
> I've now incorporated all the suggested changes (thanks once again on
> the many comments received). The resulting driver has been tested and
> works fine.
>
> Please consider applying the driver to the mainline tree, thanks.
>
What did you diff this against? When I applied it to the 2.6.13 source I got :
patching file MAINTAINERS
Hunk #1 succeeded at 1730 (offset -7 lines).
patching file drivers/char/pcmcia/Kconfig
patching file drivers/char/pcmcia/Makefile
patching file drivers/char/pcmcia/cm4040_cs.c
patching file drivers/char/pcmcia/cm4040_cs.h
Anyway, I did a small cleanup.
Removed all instances of trailing whitespace ( sed -r s/"[ \t]+$"/""/ ).
Removed some excessive (IMHO) use of blank lines.
A few CodingStyle related whitespace fixes (spaces after "," etc).
Removed some pointless casts.
Hope this is useful to you (applies on top of the version you just posted).
/Jesper Juhl
--- drivers/char/pcmcia/cm4040_cs.c.orig2005-09-05 21:39:05.0
+0200
+++ drivers/char/pcmcia/cm4040_cs.c 2005-09-05 22:01:19.0 +0200
@@ -1,4 +1,4 @@
- /*
+/*
* A driver for the Omnikey PCMCIA smartcard reader CardMan 4040
*
* (c) 2000-2004 Omnikey AG (http://www.omnikey.com/)
@@ -68,28 +68,25 @@ static char *version =
static void reader_release(dev_link_t *link);
static void reader_detach(dev_link_t *link);
-static int major;
+static int major;
#defineBS_READABLE 0x01
#defineBS_WRITABLE 0x02
struct reader_dev {
- dev_link_t link;
- dev_node_t node;
- wait_queue_head_t devq;
-
+ dev_link_t link;
+ dev_node_t node;
+ wait_queue_head_t devq;
wait_queue_head_t poll_wait;
wait_queue_head_t read_wait;
wait_queue_head_t write_wait;
-
unsigned intbuffer_status;
-
unsigned inttimer_expired;
struct timer_list timer;
unsigned long timeout;
unsigned char s_buf[READ_WRITE_BUFFER_SIZE];
unsigned char r_buf[READ_WRITE_BUFFER_SIZE];
- struct task_struct *owner;
+ struct task_struct *owner;
};
static dev_info_t dev_info = MODULE_NAME;
@@ -104,7 +101,7 @@ static struct timer_list cm4040_poll_tim
static inline void xoutb(unsigned char val, unsigned short port)
{
DEBUG(7, "outb(val=%.2x,port=%.4x)\n", val, port);
- outb(val,port);
+ outb(val, port);
}
static inline unsigned char xinb(unsigned short port)
@@ -122,7 +119,7 @@ static inline unsigned char xinb(unsigne
static void cm4040_do_poll(unsigned long dummy)
{
unsigned int i;
- /* walk through all devices */
+ /* walk through all devices */
for (i = 0; dev_table[i]; i++) {
dev_link_t *dl = dev_table[i];
struct reader_dev *dev = dl->priv;
@@ -156,7 +153,7 @@ static int wait_for_bulk_out_ready(struc
int i, rc;
int iobase = dev->link.io.BasePort1;
- for (i=0; i < POLL_LOOP_COUNT; i++) {
+ for (i = 0; i < POLL_LOOP_COUNT; i++) {
if ((xinb(iobase + REG_OFFSET_BUFFER_STATUS)
& BSR_BULK_OUT_FULL) == 0) {
DEBUG(4, "BulkOut empty (i=%d)\n", i);
@@ -191,7 +188,7 @@ static int write_sync_reg(unsigned char
if (rc <= 0)
return rc;
- xoutb(val,iobase + REG_OFFSET_SYNC_CONTROL);
+ xoutb(val, iobase + REG_OFFSET_SYNC_CONTROL);
rc = wait_for_bulk_out_ready(dev);
if (rc <= 0)
return rc;
@@ -204,7 +201,7 @@ static int wait_for_bulk_in_ready(struct
int i, rc;
int iobase = dev->link.io.BasePort1;
- for (i=0; i < POLL_LOOP_COUNT; i++) {
+ for (i = 0; i < POLL_LOOP_COUNT; i++) {
if ((xinb(iobase + REG_OFFSET_BUFFER_STATUS)
& BSR_BULK_IN_FULL) == BSR_BULK_IN_FULL) {
DEBUG(3, "BulkIn full (i=%d)\n", i);
@@ -215,7 +212,7 @@ static int wait_for_bulk_in_ready(struct
DEBUG(4, "wait_event_interruptible_timeout(timeout=%ld\n",
dev->timeout);
rc = wait_event_interruptible_timeout(dev->read_wait,
- test_and_clear_bit(BS_READABLE,
+ test_and_clear_bit(BS_READABLE,
&dev->buffer_status),
dev->timeout);
if (rc > 0)
@@ -231,7 +228,7 @@ static int wait_for_bulk_in_ready(struct
static ssize_t cm4040_read(struct file *filp, char __user *buf,
Re: (alpha) process_reloc_for_got confuses r_offset and r_addend
On 9/5/05, Chaskiel Grundman <[EMAIL PROTECTED]> wrote: > arch/alpha/kernel/module.c:process_reloc_for_got(), which figures out how > big the .got section for a module should be, appears to be confusing > r_offset (the file offset that the relocation needs to be applied to) with > r_addend (the offset of the relocation's actual target address from the > address of the relocation's symbol). Because of this, one .got entry is > allocated for each relocation instead of one each unique symbol/addend. > > In the module I am working with, this causes the .got section to be almost > 10 times larger than it needs to be (75544 bytes instead of 7608 bytes). > As the .got is accessed with global-pointer-relative instructions, it > needs to be within the 64k gp "zone", and a 75544 byte .got clearly does > not fit. The result of this is that relocation overflows are detected > during module load and the load is aborted. > > Does anyone see anything wrong with this analysis? I tested a patch that > makes the obvious change to struct got_entry/process_reloc_for_got and it > seems to work ok. > > (Please cc me on replies. thanks) Why not post the patch you made for review as well? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: igmp problem
On 9/5/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi! > > I wrote a few multicast tools, which use these multicast groups: > > 225.109.99.112 > ff02::6d63:7030 > 224.110.99.112 > ff02::6e63:7030 > > I have a Cisco in the middle, and both boxes are in different VLANs. > The Cisco is sending out igmp queries. The kernel never answers, even > after subscribing to these multicast groups. > > The kernel version is 2.4.26. What could be the problem here? > > I found no netfilter rules, and the kernel has multicast support (at > least several igmp related sysctls exist). > I'm unfortunately not able to help you with your specific problem, but a few words of advice: you really ought to start by reproducing the problem with a recent kernel - like 2.4.31 or 2.6.13. 2.4.26 is really ancient and noone really cares about it any more. You should probably also talk to the netdev people (CC'ed). -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6.13 hangs / freezes with nvidia kernel module on switch to virtual console (also 2.6.12)
On 9/5/05, hanasaki <[EMAIL PROTECTED]> wrote: > kernel 2.6.13 hangs / freezes with nvidia > kernel module on switch to virtual console > > Running Debian testing and stable and built the kernel with the attached > config. Then the NVidia installer was run. Everything boots and runs > fine. X and Gnome come up and run. Switching to a Virtual Console > locks up the system and shows some crazy colors. > > The system ran fine with the same configs until ~kernel 2.6.12.x and has > exhibited this failing behavior since then with multiple kernels. > > The graphics card is a shown below and has two outputs both in use for > two monitors. Thus the actual driver from NV is needed. I do not > believe the Xfree nv driver supports dual head. > > == > NVidia version > NVIDIA-Linux-x86-1.0-7676-pkg1.run <= from nvidia.com > Reproduce the problem without a binary only kernel module. Or in this case, complain to nvidia. It's impossible for kernel developers to debug a problem involving a closed source module. The authors of that module will have to do the fixing. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11.11 and rsync oops (SATA related?)
On 9/5/05, Kalin KOZHUHAROV <[EMAIL PROTECTED]> wrote: > Hi, there. > Long time no posting - didn't have kernel problems for long time :-) > > That is why I am still running 2.6.11.11 (2.6.12 elsewhere). Will move > to 2.6.13 soon. > > Yesterday just bought a new SATAII drive (Seagate Barracuda 7200.8 > ST3300831AS) and while trying to rsync some data from the old drives the > rsync process died with segfault. My SiI3112 controller is not SATAII, > but it should work in SATA mode, have another drive for year+. Looking > at the dmesg I saw 3 oopses (see the shortened .dmesg file). Run the > ksymoops and got some output (see .ksymoops.bz2). > It seems you forgot to include the data. Nothing inline in the email, nor any attachments. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] disable_local_APIC() is only available when CONFIG_X86_LOCAL_APIC is defined
`disable_local_APIC' is only available when CONFIG_X86_LOCAL_APIC is defined : arch/i386/kernel/crash.c: In function `crash_nmi_callback': arch/i386/kernel/crash.c:153: warning: implicit declaration of function `disable_local_APIC' arch/i386/kernel/crash.c: In function `nmi_shootdown_cpus': arch/i386/kernel/crash.c:195: warning: implicit declaration of function `disable_local_APIC' There may be a better fix, but the below seems to do the trick. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- linux-2.6.13-mm1-orig/arch/i386/kernel/crash.c 2005-09-02 23:59:27.0 +0200 +++ linux-2.6.13-mm1/arch/i386/kernel/crash.c 2005-09-05 01:54:21.0 +0200 @@ -150,7 +150,9 @@ static int crash_nmi_callback(struct pt_ regs = &fixed_regs; } crash_save_this_cpu(regs, cpu); +#ifdef CONFIG_X86_LOCAL_APIC disable_local_APIC(); +#endif atomic_dec(&waiting_for_crash_ipi); /* Assume hlt works */ halt(); @@ -190,7 +192,9 @@ static void nmi_shootdown_cpus(void) } /* Leave the nmi callback set */ +#ifdef CONFIG_X86_LOCAL_APIC disable_local_APIC(); +#endif } #else static void nmi_shootdown_cpus(void) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] disable_local_APIC() is only available when CONFIG_X86_LOCAL_APIC is defined
On 9/5/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > > `disable_local_APIC' is only available when CONFIG_X86_LOCAL_APIC is defined : > > arch/i386/kernel/crash.c: In function `crash_nmi_callback': > arch/i386/kernel/crash.c:153: warning: implicit declaration of function > `disable_local_APIC' > arch/i386/kernel/crash.c: In function `nmi_shootdown_cpus': > arch/i386/kernel/crash.c:195: warning: implicit declaration of function > `disable_local_APIC' > > There may be a better fix, but the below seems to do the trick. > [snip] I guess the better fix is to just provide a dummy function in the case of CONFIG_X86_LOCAL_APIC not being defined. If so, just let me know and I'll cook up a patch to do that, instead of the ugly ifdef's. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: quiet-non-x86-option-rom-warnings.patch added to -mm tree
On 9/4/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > The patch titled > > quiet non-x86 option ROM warnings > > has been added to the -mm tree. Its filename is [...] > > From: Olaf Hering <[EMAIL PROTECTED]> > > Quiet an incorrect warning in aty128fb and radeonfb about the PCI ROM > content. Macs work just find without that signature. > [...] If everything is fine, then why not just remove the printk() entirely instead of just changing the level to KERN_DEBUG ? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potential IPSec DoS/Kernel Panic with 2.6.13
On 9/5/05, Matt LaPlante <[EMAIL PROTECTED]> wrote: > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:linux-kernel- > > [EMAIL PROTECTED] On Behalf Of Jesper Juhl > > Sent: Sunday, September 04, 2005 2:49 PM > > To: Matt LaPlante > > Cc: Herbert Xu; linux-kernel@vger.kernel.org > > Subject: Re: Potential IPSec DoS/Kernel Panic with 2.6.13 > > > > > > > serial console over a cross-over cable to a second box. > > netconsole will let you put the console on a different box over the > > network. > > console on line printer will let you have a permanent record of the > > console output on paper. > > > > See > > Documentation/serial-console.txt > > Documentation/networking/netconsole.txt > > the help entry for "config LP_CONSOLE" (in drivers/char/Kconfig) > > > > Well I've tried for several hours now to get netconsole working, but it just > won't give me output. I've tried using both built in as well as module, and > I've tried two different clients using both netcat and syslogd on different > ports. The most output I ever get is when loading the module I manage to > receive one message saying "netconsole: network logging started". I've > verified all the netconsole settings are correct in the kernel logs when it > loads. I'm not one to give up easily, but this one's got me stumped. > > I know the option to use a printer is out...I might be able to manage a > serial connection, but I'll have to rebuild my kernel to support it. I'll > look into that later... > Hmm, just a guess; since your bug kills networking I'd suspect that perhaps netconsole is not the best option. Serial console or printer (if you have one obviously) would probably be better options. If you can't get netconsole to work even for stuff prior to triggering the oops, then that's a bit odd. Perhaps if you posted a description of exactely what it is you are doing someone could point out the error... Personally I haven't used netconsole for quite a while, so my memory of how to set it up is a bit rusty, but I don't recall it being /that/ tricky. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On 9/4/05, Horst von Brand <[EMAIL PROTECTED]> wrote: > Jesper Juhl <[EMAIL PROTECTED]> wrote: > > On 9/4/05, Harald Welte <[EMAIL PROTECTED]> wrote: > > > On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote: > > > > Hi! > > > > > > > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA > > > > Smartcard Reader. > > > > > > Sorry, the patch was missing a "cg-add" of the header file. Please use > > > the patch below. > > > > It would be so much nicer if the patch actually was "below" - that is > > "inline in the email as opposed to as an attachment". Having to first > > save an attachment and then cut'n'paste from it is a pain. > > > > Anyway, a few comments below : > > [...] > > > + unsigned long ulBytesToRead; > > > > > > lowercase prefered also for variables. > > Also, "encoding" the type (ul) into the variable name is nonsense. > Agreed, and it's even mentioned in CodingStyle (ok, it talks about functions, but the same goes for variables): ... Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs. LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, if there is no chance of it being mis-understood. Similarly, "tmp" can be just about any type of variable that is used to hold a temporary value. ... -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1
On 9/4/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > Jesper Juhl <[EMAIL PROTECTED]> wrote: > > > > I'm wondering if it would be too much trouble to have a mm-drops list > > similar to the mm-commits list. > > Well I was sending drop messages to mm-commits, but lots of people went > "Waah, why did you drop my patch?". A few hours after they'd been cc'ed as > the patch went in to Linus! So then I was asked to include an explanation > with the drop message and that all got too hard so I turned them off. > If patches dropped due to being merged in mainline were then commented with a simple "merged in mainline" note, surely that would keep the "Waah .." mails out of your mailbox. :-) > > > > I also like to keep track of what patches of mine get accepted and > > subsequently dropped. > > As I say, the way to do this is via your quilt series file. > Hmm, I've been looking at quilt, but never really got to the point of actually starting to use it - guess I should get started on that. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1
On 9/3/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote: > > > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Andrew, > > > > > > > > it seems you dropped > > > > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's > > > > zero mentioning of this dropping in the changelog of 2.6.13-mm1. > > > > > > > > Can you explain why you did silently drop it? > > > > > > It spat rejects and when I looked at the putative removal date I just > > > didn't believe it anyway. Send a rediffed one if you like, but > > > October 2005 is unrealistic. > > > > That the date is no longer realistic is clear. What disappoints me is > > that you didn't mention in the changelog of 2.6.13-mm1 where I'd have > > noticed it. > > Sometimes I can't be bothered getting into email threads over relatively > unimportant stuff. Usually it's related to the number of bugs we have. > > > It semms I need my own bookkeeping of patches I sent that are in -mm to > > notice when they get lost. > > This is called "quilt". > I'm wondering if it would be too much trouble to have a mm-drops list similar to the mm-commits list. I also like to keep track of what patches of mine get accepted and subsequently dropped. What I'm thinking is that it seems you have the mails to mm-commit pretty much automated (I may be wrong, but it seems that way to me). If they are indeed automated, then how hard would it be to set your end up to automatically send a mail to the same people who got the original mm-commits mail + send it to a central mm-drops list that those of us who care about this could subscribe to? As far as I'm concerned the mails wouldn't even need to contain a reason (although one would of course be nice) - just a mail stating the fact that patch xyz was dropped from the mm tree would be great. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potential IPSec DoS/Kernel Panic with 2.6.13
On 9/4/05, Matt LaPlante <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:linux-kernel- > > [EMAIL PROTECTED] On Behalf Of Herbert Xu > > Sent: Sunday, September 04, 2005 4:24 AM > > To: Matt LaPlante > > Cc: linux-kernel@vger.kernel.org > > Subject: Re: Potential IPSec DoS/Kernel Panic with 2.6.13 > > > > Matt LaPlante <[EMAIL PROTECTED]> wrote: > > > > > > network connectivity on my router. Upon further inspection I noticed > > the > > > packet had actually caused a kernel panic (visible only on the monitor, > > now > > > also unresponsive). > > > > Thanks for the report. I'll try to track it down. > > > > If you could jot down the important bits of the panic message > > (IP, Call-Trace) it would help me find the problem much quicker. > > I'd be more than happy to help you track this one down. The problem here is > that the panic scrolls up and off the screen after which the system is > unusable. Is there a way for me to capture it or redirect it somewhere that > I can read it? I can also include my kernel config or any other system > details of interest. Thanks. > serial console over a cross-over cable to a second box. netconsole will let you put the console on a different box over the network. console on line printer will let you have a permanent record of the console output on paper. See Documentation/serial-console.txt Documentation/networking/netconsole.txt the help entry for "config LP_CONSOLE" (in drivers/char/Kconfig) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On 9/4/05, Harald Welte <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> > Hi!
> >
> > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > Smartcard Reader.
>
> Sorry, the patch was missing a "cg-add" of the header file. Please use
> the patch below.
It would be so much nicer if the patch actually was "below" - that is
"inline in the email as opposed to as an attachment". Having to first
save an attachment and then cut'n'paste from it is a pain.
Anyway, a few comments below :
+#define DEBUG(n, x, args...) do { if (pc_debug >= (n))
\
line longer than 80 chars. Please adhere to CodingStyle and keep lines
<80 chars.
There's more than one occourance of this.
+static inline int cmx_waitForBulkOutReady(reader_dev_t *dev)
Why TheStudlyCaps ? Please keep function names lowercase. There are
more instances of this, only pointing out one.
+register int i;
+ register int iobase = dev->link.io.BasePort1;
Please use only tabs for indentation (line 1 of the above is indented
with spaces).
+ for (i=0; i < POLL_LOOP_COUNT; i++) {
for (i = 0; i < POLL_LOOP_COUNT; i++) {
+if (rc != 1)
Again spaces used for indentation, please fix all that up to use tabs.
+ unsigned long ulBytesToRead;
lowercase prefered also for variables.
+ for (i=0; i<5; i++) {
for (i = 0; i < 5; i++) {
+ DEBUG(5,"cmx_waitForBulkInReady rc=%.2x\n",rc);
Space after ","s please : DEBUG(5, "cmx_waitForBulkInReady rc=%.2x\n", rc);
+ ulMin = (count < (ulBytesToRead+5))?count:(ulBytesToRead+5);
needs spaces :
ulMin = (count < (ulBytesToRead + 5)) ? count : (ulBytesToRead + 5);
+ reader_dev_t *dev=(reader_dev_t *)filp->private_data;
reader_dev_t *dev = (reader_dev_t *)filp->private_data;
+static int cmx_open (struct inode *inode, struct file *filp)
get rid of the space before the opening paren :
static int cmx_open(struct inode *inode, struct file *filp)
+ for (rc = pcmcia_get_first_tuple(handle, &tuple);
+rc == CS_SUCCESS;
+rc = pcmcia_get_next_tuple(handle, &tuple)) {
...
+ if (parse.cftable_entry.io.nwin) {
+ link->io.BasePort1 = parse.cftable_entry.io.win[0].base;
+ link->io.NumPorts1 = parse.cftable_entry.io.win[0].len;
+ link->io.Attributes1 = IO_DATA_PATH_WIDTH_AUTO;
+ if(!(parse.cftable_entry.io.flags & CISTPL_IO_8BIT))
+ link->io.Attributes1 = IO_DATA_PATH_WIDTH_16;
...
+ }
+ }
How about not having to indent so deep by rewriting that as
for (rc = pcmcia_get_first_tuple(handle, &tuple);
rc == CS_SUCCESS;
rc = pcmcia_get_next_tuple(handle, &tuple)) {
...
if (!parse.cftable_entry.io.nwin)
continue;
link->io.BasePort1 = parse.cftable_entry.io.win[0].base;
link->io.NumPorts1 = parse.cftable_entry.io.win[0].len;
link->io.Attributes1 = IO_DATA_PATH_WIDTH_AUTO;
if(!(parse.cftable_entry.io.flags & CISTPL_IO_8BIT))
link->io.Attributes1 = IO_DATA_PATH_WIDTH_16;
...
}
+link->conf.IntType = 0002;
more spaces used for indentation. Not going to point out any more of these.
+ cmx_poll_timer.function = &cmx_do_poll;
shouldn't this be
cmx_poll_timer.function = cmx_do_poll;
???
+ int i;
+ DEBUG(3, "-> reader_detach(link=%p\n", link);
please have a blank line between variable declarations and other statements.
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Q] how to use syslogd to debug kernel ?
On 9/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi, everyone. > > I know kernel oops can be seen by run 'dmesg', but if > kernel crashed, we can not run it. so I reconfigure syslogd > to support remote forward, the debug machine content of When the kernel crashes there's no guarantee that messages will reach syslog. Actually there's no guarantee of anything - the kernel is dead. If you want to capture Oops messages in a more reliable fashion, then use a serial console, netconsole or console on line-printer. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mail list broken?
On 9/2/05, Phy Prabab <[EMAIL PROTECTED]> wrote: > Hello, > > Does anyone know why all of a sudden I have stopped > receiving LK mailings? The last email was yesterday > mornig around 02.00 US PST. I see the archives are > continuing to get mail. hmmm. > > Any help is appreciated. > See http://vger.kernel.org/majordomo-info.html - there's a test address listed you can try. IIRC you can also send a mail to majordomo and ask if you are still subscribed. Also try vgers mxverify tool : http://vger.kernel.org/mxverify.html Hope that's useful. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
On 9/2/05, Ion Badulescu <[EMAIL PROTECTED]> wrote: > Hi David, > > On Thu, 1 Sep 2005, David S. Miller wrote: > > > Thanks for the empty posting. Please provide the content you > > intended to post, and furthermore please post it to the network > > developer mailing list, netdev@vger.kernel.org > > First of all, thanks for the reply (even to an empty posting :). > > The posting wasn't actually empty, it was probably too long (94K according Two solutions commonly applied to that problem : - put the big file(s) online somewhere and include an URL in the email - compress the file(s) and attach the compressed files to the email -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto_free_tfm callers no longer need to check for NULL
On 9/2/05, David S. Miller <[EMAIL PROTECTED]> wrote: > > Applied, thanks Jesper. > > Can you avoid those "/./" things from showing up in the file paths of > the patches you post? They upset the GIT patch application scripts > and diff verifiers, so I had to edit them out by hand. > No problem, I actually saw those (an unfortunate biproduct of a script I used to diff the individual files) and told myself that I should remember to remove them before sending the final patch, but obviously I forgot. > Thanks again. > You are most welcome. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
On 9/2/05, David S. Miller <[EMAIL PROTECTED]> wrote: > > Thanks for the empty posting. Please provide the content you > intended to post, and furthermore please post it to the network > developer mailing list, netdev@vger.kernel.org > Hmm, I see plenty of content in the post. Want me to farward you a copy off list ? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Resend: [PATCH] crypto_free_tfm callers no longer need to check for NULL
Apologies if you recieve this twice, but I sent it yesterday and haven't
seen it make it to LKML yet, so I'm unsure if it reached any other
recipients.
Trying once more :-)
-- Forwarded Message --
Subject: [PATCH] crypto_free_tfm callers no longer need to check for NULL
Date: Wednesday 31 August 2005 22:20
From: Jesper Juhl <[EMAIL PROTECTED]>
To: Andrew morton <[EMAIL PROTECTED]>
Cc: linux-kernel@vger.kernel.org,
Herbert Xu <[EMAIL PROTECTED]>,
Sridhar Samudrala <[EMAIL PROTECTED]>,
J. Bruce Fields <[EMAIL PROTECTED]>,
YOSHIFUJI Hideaki <[EMAIL PROTECTED]>,
"David S. Miller" <[EMAIL PROTECTED]>,
Benjamin Reed <[EMAIL PROTECTED]>,
Andy Adamson <[EMAIL PROTECTED]>,
Alexey Dobriyan <[EMAIL PROTECTED]>
Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
there's no longer any need for callers of that function to check for NULL.
This patch removes the redundant NULL checks and also a few similar checks
for NULL before calls to kfree() that I ran into while doing the
crypto_free_tfm bits.
I've succesfuly compile tested this patch, and a kernel with the patch
applied boots and runs just fine.
When I posted the patch to LKML (and other lists/people on Cc) it drew the
following comments :
J. Bruce Fields commented
"I've no problem with the auth_gss or nfsv4 bits.--b."
Sridhar Samudrala said
"sctp change looks fine."
Herbert Xu signed off on the patch.
So, I guess this is ready to be dropped into -mm and eventually mainline.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
---
./drivers/net/wireless/airo.c |3 +--
./fs/nfsd/nfs4recover.c |3 +--
./net/ipv4/ah4.c| 18 ++
./net/ipv4/esp4.c | 24
./net/ipv4/ipcomp.c |3 +--
./net/ipv6/addrconf.c |6 ++
./net/ipv6/ah6.c| 18 ++
./net/ipv6/esp6.c | 24
./net/ipv6/ipcomp6.c|3 +--
./net/sctp/socket.c |3 +--
./net/sunrpc/auth_gss/gss_krb5_crypto.c |3 +--
./net/sunrpc/auth_gss/gss_krb5_mech.c |9 +++--
./net/sunrpc/auth_gss/gss_spkm3_mech.c | 12
net/sctp/endpointola.c |3 +--
14 files changed, 44 insertions(+), 88 deletions(-)
--- linux-2.6.13-orig/./drivers/net/wireless/airo.c 2005-08-29
01:41:01.0 +0200
+++ linux-2.6.13/./drivers/net/wireless/airo.c 2005-08-30 18:08:15.0
+0200
@@ -2403,8 +2403,7 @@ void stop_airo_card( struct net_device *
}
}
#ifdef MICSUPPORT
- if (ai->tfm)
- crypto_free_tfm(ai->tfm);
+ crypto_free_tfm(ai->tfm);
#endif
del_airo_dev( dev );
free_netdev( dev );
--- linux-2.6.13-orig/./fs/nfsd/nfs4recover.c 2005-08-29 01:41:01.0
+0200
+++ linux-2.6.13/./fs/nfsd/nfs4recover.c2005-08-30 18:08:25.0
+0200
@@ -114,8 +114,7 @@ nfs4_make_rec_clidname(char *dname, stru
kfree(cksum.data);
status = nfs_ok;
out:
- if (tfm)
- crypto_free_tfm(tfm);
+ crypto_free_tfm(tfm);
return status;
}
--- linux-2.6.13-orig/./net/ipv4/ah4.c 2005-08-29 01:41:01.0 +0200
+++ linux-2.6.13/./net/ipv4/ah4.c 2005-08-30 18:10:10.0 +0200
@@ -263,10 +263,8 @@ static int ah_init_state(struct xfrm_sta
error:
if (ahp) {
- if (ahp->work_icv)
- kfree(ahp->work_icv);
- if (ahp->tfm)
- crypto_free_tfm(ahp->tfm);
+ kfree(ahp->work_icv);
+ crypto_free_tfm(ahp->tfm);
kfree(ahp);
}
return -EINVAL;
@@ -279,14 +277,10 @@ static void ah_destroy(struct xfrm_state
if (!ahp)
return;
- if (ahp->work_icv) {
- kfree(ahp->work_icv);
- ahp->work_icv = NULL;
- }
- if (ahp->tfm) {
- crypto_free_tfm(ahp->tfm);
- ahp->tfm = NULL;
- }
+ kfree(ahp->work_icv);
+ ahp->work_icv = NULL;
+ crypto_free_tfm(ahp->tfm);
+ ahp->tfm = NULL;
kfree(ahp);
}
--- linux-2.6.13-orig/./net/ipv4/esp4.c 2005-08-29 01:41:01.0 +0200
+++ linux-2.6.13/./net/ipv4/esp4.c 2005-08-30 18:10:49.0 +0200
@@ -343,22 +343,14 @@ static void esp_destroy(struct xfrm_stat
if (!esp)
return;
- if (esp->conf.tfm) {
- crypto_free_tfm(esp->conf.tfm);
- esp->conf.tfm = NULL;
- }
- if (esp->conf.ivec)
Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On 9/1/05, Chris Wedgwood <[EMAIL PROTECTED]> wrote: > On Thu, Sep 01, 2005 at 12:12:00AM +0200, Jesper Juhl wrote: > > > b) add a new boot option telling the kernel the name of some file in > > initrd or similar from which to load additional options. > > a file in initrd isn't a good choice; as the initrd is generally a fix > image > > the point is some bootloaders might want to pass quite a bit of state > to the kernel at times (i actually have this for a mip32 target where > i construct a table and pass a pointer to that in, a tad icky but for > lack of options) > Well, it wouldn't have to be initrd specifically. Generally what's needed is *some* way to tell the kernel "please read more options from location ". The interresting bit is what 's supposed to be. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On 9/1/05, Chris Wedgwood <[EMAIL PROTECTED]> wrote: > On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote: > > > Maybe not. Another option would simply be to bump it up > > significantly (2x isn't really that much.) 4096, maybe. > > I wonder if we're not at the point where we need something different > to what we have now. The concept of a command-line works for passing > simple state but for more complex things it's too cumbersome. How about a) bump the limit on the cmd line - it's still useful, and 256 really is quite small for some things. b) add a new boot option telling the kernel the name of some file in initrd or similar from which to load additional options. I don't know if b is feasible at all. It would mean that the kernel would need to get a hold of the initrd or whatever quite early to be able to process options from it, but if it's doable somehow it would be a really neat thing. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Resend: [PATCH] remove EXPORT_SYMBOL(strtok) from frv_ksyms.c
Andrew, Got some feedback on this one from David Howells > Looks okay to me. > > David so I'm resending it in the hope that you'll drop it into -mm (or NACK it if you don't like it) :-) -- Forwarded Message -- Subject: [PATCH] remove EXPORT_SYMBOL(strtok) from frv_ksyms.c Date: Monday 29 August 2005 17:35 From: Jesper Juhl <[EMAIL PROTECTED]> To: Andrew Morton <[EMAIL PROTECTED]> Cc: "linux-kernel" Hi Andrew, I hessitated a bit before sending this patch to you since it is untested. This is due to the fact that I don't have the hardware, nor a suitable cross compiler to do so. I sent the patch to LKML a few days ago in the hope that someone else could test/validate this change for me, but unfortunately I got no replies. That left me with the option of just forgetting about the patch or send it on to you. Although the patch has not been tested I have a hard time imagining that it could be anything but correct since strtok() was removed from the kernel back in 2002. Remove export of strtok(). strtok() has not been available in the kernel since 2002. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- arch/frv/kernel/frv_ksyms.c |1 - 1 files changed, 1 deletion(-) --- linux-2.6.13-rc6-mm2-orig/arch/frv/kernel/frv_ksyms.c 2005-06-17 21:48:29.0 +0200 +++ linux-2.6.13-rc6-mm2/arch/frv/kernel/frv_ksyms.c2005-08-24 18:58:14.0 +0200 @@ -71,7 +71,6 @@ EXPORT_SYMBOL(memset); EXPORT_SYMBOL(memcmp); EXPORT_SYMBOL(memscan); EXPORT_SYMBOL(memmove); -EXPORT_SYMBOL(strtok); EXPORT_SYMBOL(get_wchan); --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13 and the IRQs
On 8/31/05, Stephan Grein <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, i updated my laptop to 2.6.13 vanilla kernel. > When i booted up it gave me some strange irq messages (debug) which > showed not up on 2.6.12.2 vanilla. I added irqpoll to lilo.conf, and > it removed some output. However before i did add irqpoll to lilo my > pcmcia cards worked also, after adding also. > Here is the output, maybe you can help me. (I did not change .config > from 2.6.12.2 to 2.6.13, just did a make oldconfig.) > cheers. > It seems you forgot to include the output. full dmesg output and also a diff -u of lspci -vvx output from 2.6.12 and 2.6.13 would most likely be useful. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Telecom Clock driver for MPCBL0010 ATCA compute blade.
On 8/31/05, Mark Gross <[EMAIL PROTECTED]> wrote: > On Tuesday 30 August 2005 14:19, Jesper Juhl wrote: > > On 8/30/05, Mark Gross <[EMAIL PROTECTED]> wrote: > > > On Tuesday 30 August 2005 13:31, Mark Gross wrote: > > > > On Tuesday 30 August 2005 12:16, Marcelo Tosatti wrote: > > > > > > > > > > Mark, > > > > > > > > > > Please fix identation accordingly to CodingStyle and repost, it > > > > > looks quite ugly at the moment. > > > > > > > > > Sorry about that. > > > > > > > > > > My email client is f-ing with me. See attached. > > > > > > > ok, a few small comments : > > [snip] > Thank you for your input. See attached. > You're welcome. I see you fixed some of it, but I wonder why you didn't bother to fix the spelling errors in the comments while you were at it? :-) - "Uppon", "interaces" ... No big deal though. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto_free_tfm callers do not need to check for NULL
On 8/30/05, Sridhar Samudrala <[EMAIL PROTECTED]> wrote: > On Tue, 2005-08-30 at 22:45 +0200, Jesper Juhl wrote: > > Since the patch to add a NULL short-circuit to crypto_free_tfm() went in, > > there's no longer any need for callers of that function to check for NULL. > > This patch removes the redundant NULL checks and also a few similar checks > > for NULL before calls to kfree() that I ran into while doing the > > crypto_free_tfm bits. > > > > I've posted similar patches in the past, but was asked to first until the > > short-circuit patch moved from -mm to mainline - and since it is now > > firmly there in 2.6.13 I assume there's no problem there anymore. > > I was also asked previously to make the patch against mainline and not -mm, > > so this patch is against 2.6.13. > > > > Feedback, ACK, NACK, etc welcome. > > sctp change looks fine. > A similar check in sctp_endpoint_destroy() can also be removed. > Thanks, I'll remember that and either update the patch or send a small incremental one later. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Telecom Clock driver for MPCBL0010 ATCA compute blade.
On 8/30/05, Mark Gross <[EMAIL PROTECTED]> wrote: > On Tuesday 30 August 2005 13:31, Mark Gross wrote: > > On Tuesday 30 August 2005 12:16, Marcelo Tosatti wrote: > > > > > > Mark, > > > > > > Please fix identation accordingly to CodingStyle and repost, it > > > looks quite ugly at the moment. > > > > > Sorry about that. > > > > My email client is f-ing with me. See attached. > ok, a few small comments : +/* sysFS interface definition: Isn't it just called "sysfs" without the caps? +Uppon loading the driver will create a sysfs directory under class/misc/tlclk. s/Uppon/Upon/ +This directory exports the following interfaces. There opperation is documented Line is longer than 80 chars - there are a few more such long lines, not going to point them all out, just one example. Ohh, and "opperation" should be "operation". +All sysfs interaces are integers in hex format, i.e echo 99 > refalign s/interaces/interfaces/ +#if CONFIG_DEBUG_KERNEL I believe this should be "#ifdef CONFIG_DEBUG_KERNEL" or "#if defined(CONFIG_DEBUG_KERNEL)" or you'll run afoul of the -Wundef crowd. + int ret_val = 0; There seems to be a preference for the name "retval" in the kernel source. + val = (unsigned char)arg; That cast looks pointless. +tlclk_read(struct file * filp, char __user * buf, size_t count, loff_t * f_pos) tlclk_read(struct file *filp, char __user *buf, size_t count, loff_t *f_pos) "*" next to the variable name is generally the preffered coding style (several cases of this, only pointing out one). + val = (unsigned char)tmp; pointless cast. Do take a look at all your casts and check if they are really needed and remove them if not. + * This is also the probe opperation to avoid driver use on s/opperation/operation/ +/* switchover_timer.function = switchover_timeout; */ +/* switchover_timer.data = 0; */ Why submit a driver with commented out code? If this is not supposed to be there, then just remove it. If it needs to be added later, then submit a patch later to add it. Some people may disagree with me here, but that's my oppinion. + out3: labels belong at column 0 (zero). -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] crypto_free_tfm callers do not need to check for NULL
Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
there's no longer any need for callers of that function to check for NULL.
This patch removes the redundant NULL checks and also a few similar checks
for NULL before calls to kfree() that I ran into while doing the
crypto_free_tfm bits.
I've posted similar patches in the past, but was asked to first until the
short-circuit patch moved from -mm to mainline - and since it is now
firmly there in 2.6.13 I assume there's no problem there anymore.
I was also asked previously to make the patch against mainline and not -mm,
so this patch is against 2.6.13.
Feedback, ACK, NACK, etc welcome.
Sorry about the large Cc list, but I wanted to include everyone involved
with the code I change.
Please keep me on Cc.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
./drivers/net/wireless/airo.c |3 +--
./fs/nfsd/nfs4recover.c |3 +--
./net/ipv4/ah4.c| 18 ++
./net/ipv4/esp4.c | 24
./net/ipv4/ipcomp.c |3 +--
./net/ipv6/addrconf.c |6 ++
./net/ipv6/ah6.c| 18 ++
./net/ipv6/esp6.c | 24
./net/ipv6/ipcomp6.c|3 +--
./net/sctp/socket.c |3 +--
./net/sunrpc/auth_gss/gss_krb5_crypto.c |3 +--
./net/sunrpc/auth_gss/gss_krb5_mech.c |9 +++--
./net/sunrpc/auth_gss/gss_spkm3_mech.c | 12
13 files changed, 43 insertions(+), 86 deletions(-)
--- linux-2.6.13-orig/./drivers/net/wireless/airo.c 2005-08-29
01:41:01.0 +0200
+++ linux-2.6.13/./drivers/net/wireless/airo.c 2005-08-30 18:08:15.0
+0200
@@ -2403,8 +2403,7 @@ void stop_airo_card( struct net_device *
}
}
#ifdef MICSUPPORT
- if (ai->tfm)
- crypto_free_tfm(ai->tfm);
+ crypto_free_tfm(ai->tfm);
#endif
del_airo_dev( dev );
free_netdev( dev );
--- linux-2.6.13-orig/./fs/nfsd/nfs4recover.c 2005-08-29 01:41:01.0
+0200
+++ linux-2.6.13/./fs/nfsd/nfs4recover.c2005-08-30 18:08:25.0
+0200
@@ -114,8 +114,7 @@ nfs4_make_rec_clidname(char *dname, stru
kfree(cksum.data);
status = nfs_ok;
out:
- if (tfm)
- crypto_free_tfm(tfm);
+ crypto_free_tfm(tfm);
return status;
}
--- linux-2.6.13-orig/./net/ipv4/ah4.c 2005-08-29 01:41:01.0 +0200
+++ linux-2.6.13/./net/ipv4/ah4.c 2005-08-30 18:10:10.0 +0200
@@ -263,10 +263,8 @@ static int ah_init_state(struct xfrm_sta
error:
if (ahp) {
- if (ahp->work_icv)
- kfree(ahp->work_icv);
- if (ahp->tfm)
- crypto_free_tfm(ahp->tfm);
+ kfree(ahp->work_icv);
+ crypto_free_tfm(ahp->tfm);
kfree(ahp);
}
return -EINVAL;
@@ -279,14 +277,10 @@ static void ah_destroy(struct xfrm_state
if (!ahp)
return;
- if (ahp->work_icv) {
- kfree(ahp->work_icv);
- ahp->work_icv = NULL;
- }
- if (ahp->tfm) {
- crypto_free_tfm(ahp->tfm);
- ahp->tfm = NULL;
- }
+ kfree(ahp->work_icv);
+ ahp->work_icv = NULL;
+ crypto_free_tfm(ahp->tfm);
+ ahp->tfm = NULL;
kfree(ahp);
}
--- linux-2.6.13-orig/./net/ipv4/esp4.c 2005-08-29 01:41:01.0 +0200
+++ linux-2.6.13/./net/ipv4/esp4.c 2005-08-30 18:10:49.0 +0200
@@ -343,22 +343,14 @@ static void esp_destroy(struct xfrm_stat
if (!esp)
return;
- if (esp->conf.tfm) {
- crypto_free_tfm(esp->conf.tfm);
- esp->conf.tfm = NULL;
- }
- if (esp->conf.ivec) {
- kfree(esp->conf.ivec);
- esp->conf.ivec = NULL;
- }
- if (esp->auth.tfm) {
- crypto_free_tfm(esp->auth.tfm);
- esp->auth.tfm = NULL;
- }
- if (esp->auth.work_icv) {
- kfree(esp->auth.work_icv);
- esp->auth.work_icv = NULL;
- }
+ crypto_free_tfm(esp->conf.tfm);
+ esp->conf.tfm = NULL;
+ kfree(esp->conf.ivec);
+ esp->conf.ivec = NULL;
+ crypto_free_tfm(esp->auth.tfm);
+ esp->auth.tfm = NULL;
+ kfree(esp->auth.work_icv);
+ esp->auth.work_icv = NULL;
kfree(esp);
}
--- linux-2.6.13-orig/./net/ipv4/ipcomp.c 2005-08-29 01:41:01.0
+0200
+++ linux-2.6.13/./net/ipv4/ipcomp.c2005-08-30 18:11:14.0 +0200
@@ -345,8 +345,7 @@ static void ipcomp_free_tfms(struct cryp
for_each_cpu(cpu
