Re: linux-next: Tree for Feb 20
On Tue, Feb 19, 2008 at 09:50:55PM -0800, Greg KH wrote: > What's the best way to constantly follow this tree? I had cloned it > a while ago, but now if I 'git pull' it wants to merge things, which > isn't right. I would guess: $ git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git $ git fetch linux-next then use the remote branch names when poking about: $ git log -p linux-next/master etc? Or is there a better way? -- 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: linux-next: Tree for Feb 20
On Tue, Feb 19, 2008 at 09:50:55PM -0800, Greg KH wrote: What's the best way to constantly follow this tree? I had cloned it a while ago, but now if I 'git pull' it wants to merge things, which isn't right. I would guess: $ git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git $ git fetch linux-next then use the remote branch names when poking about: $ git log -p linux-next/master etc? Or is there a better way? -- 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] kill hotplug init/exit section annotations
On Thu, Jan 31, 2008 at 07:55:43PM +0200, Adrian Bunk wrote: > Who was talking about laptops? If laptops are mostly MP these days, then 'desktops' and 'servers' certainly are --- so pretty much everyone needs CPU hotplug. -- 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] kill hotplug init/exit section annotations
On Thu, Jan 31, 2008 at 07:14:36PM +0200, Adrian Bunk wrote: > > cpuhotplug is required for suspend/resume. > > Not on UP computers. those are less and less common now, most modern laptops are dual core -- 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] kill hotplug init/exit section annotations
On Thu, Jan 31, 2008 at 07:14:36PM +0200, Adrian Bunk wrote: cpuhotplug is required for suspend/resume. Not on UP computers. those are less and less common now, most modern laptops are dual core -- 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] kill hotplug init/exit section annotations
On Thu, Jan 31, 2008 at 07:55:43PM +0200, Adrian Bunk wrote: Who was talking about laptops? If laptops are mostly MP these days, then 'desktops' and 'servers' certainly are --- so pretty much everyone needs CPU hotplug. -- 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] xfs: revert to double-buffering readdir
On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote: > Looks like the readdir is in the bowels of the btree code when > filldir gets called here, there are probably locks on several > buffers in the btree at this point. This will only show up for large > directories I bet. I see it for fairly small directories. Larger than what you can stuff into an inode but less than a block (I'm not checking but fairly sure that's the case). > Just rambling, not a single line of code was consulted in writing > this message. Can you explain why the offset is capped and treated in an 'odd way' at all? + curr_offset = filp->f_pos; + if (curr_offset == 0x7fff) + offset = 0x; + else + offset = filp->f_pos; and later the offset to filldir is masked. Is that some restriction in filldir? - 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] xfs: revert to double-buffering readdir
On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote: Looks like the readdir is in the bowels of the btree code when filldir gets called here, there are probably locks on several buffers in the btree at this point. This will only show up for large directories I bet. I see it for fairly small directories. Larger than what you can stuff into an inode but less than a block (I'm not checking but fairly sure that's the case). Just rambling, not a single line of code was consulted in writing this message. Can you explain why the offset is capped and treated in an 'odd way' at all? + curr_offset = filp-f_pos; + if (curr_offset == 0x7fff) + offset = 0x; + else + offset = filp-f_pos; and later the offset to filldir is masked. Is that some restriction in filldir? - 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] xfs: revert to double-buffering readdir
On Sun, Nov 25, 2007 at 04:30:14PM +, Christoph Hellwig wrote: > The current readdir implementation deadlocks on a btree buffers > locks because nfsd calls back into ->lookup from the filldir > callback. The only short-term fix for this is to revert to the old > inefficient double-buffering scheme. This seems to work really well here. > This patch does exactly that and reverts xfs_file_readdir to what's > basically the 2.6.23 version minus the uio and vnops junk. This should probably be submitted for inclusion stable-2.6.24. Perhaps a version with the #if 0 [...] stuff dropped? (I'm happy to send a patch for that if you prefer). - 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] xfs: revert to double-buffering readdir
On Sun, Nov 25, 2007 at 04:30:14PM +, Christoph Hellwig wrote: The current readdir implementation deadlocks on a btree buffers locks because nfsd calls back into -lookup from the filldir callback. The only short-term fix for this is to revert to the old inefficient double-buffering scheme. This seems to work really well here. This patch does exactly that and reverts xfs_file_readdir to what's basically the 2.6.23 version minus the uio and vnops junk. This should probably be submitted for inclusion stable-2.6.24. Perhaps a version with the #if 0 [...] stuff dropped? (I'm happy to send a patch for that if you prefer). - 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.24-rc2 XFS nfsd hang
On Fri, Nov 16, 2007 at 09:19:32AM -0500, Trond Myklebust wrote: > Very funny, but disabling XFS on the client won't help. Oops, I meant it for NFSD... and I'm somewhat serious. I'm not saying it's a good long term solution, but a potentially safer short-term workaround. - 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.24-rc2 XFS nfsd hang
On Fri, Nov 16, 2007 at 10:17:17AM +0100, Christian Kujau wrote: > OK, I'll try this. I hope this can be fixed somehow before 2.6.24... Well, one simple nasty idea would be something like: diff --git a/fs/Kconfig b/fs/Kconfig index 429a002..da231fd 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -1604,7 +1604,7 @@ config NFS_FS config NFS_V3 bool "Provide NFSv3 client support" - depends on NFS_FS + depends on NFS_FS && !XFS help Say Y here if you want your NFS client to be able to speak version 3 of the NFS protocol. So people who are likely to be affect just side-step the issue until it's resolved. - 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.24-rc2 XFS nfsd hang
On Fri, Nov 16, 2007 at 10:17:17AM +0100, Christian Kujau wrote: OK, I'll try this. I hope this can be fixed somehow before 2.6.24... Well, one simple nasty idea would be something like: diff --git a/fs/Kconfig b/fs/Kconfig index 429a002..da231fd 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -1604,7 +1604,7 @@ config NFS_FS config NFS_V3 bool Provide NFSv3 client support - depends on NFS_FS + depends on NFS_FS !XFS help Say Y here if you want your NFS client to be able to speak version 3 of the NFS protocol. So people who are likely to be affect just side-step the issue until it's resolved. - 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.24-rc2 XFS nfsd hang
On Fri, Nov 16, 2007 at 09:19:32AM -0500, Trond Myklebust wrote: Very funny, but disabling XFS on the client won't help. Oops, I meant it for NFSD... and I'm somewhat serious. I'm not saying it's a good long term solution, but a potentially safer short-term workaround. - 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.24-rc2 XFS nfsd hang / smbd too
On Thu, Nov 15, 2007 at 08:51:36AM +0100, Christian Kujau wrote: > [] mutex_lock_nested+0xcc/0x2c0 > [] do_lookup+0xa4/0x190 > [] __link_path_walk+0x749/0xd10 > [] link_path_walk+0x44/0xc0 > [] path_walk+0x18/0x20 > [] do_path_lookup+0x78/0x1c0 > [] __user_walk_fd+0x38/0x60 > [] vfs_stat_fd+0x21/0x50 > [] vfs_stat+0x11/0x20 > [] sys_stat64+0x14/0x30 > [] sysenter_past_esp+0x5f/0xa5 nfsd already wedged up and holds a lock, this is expected. I'm not sure what you're doing here, but a viable work-around for now might be to use nfsv2 mounts, something like mount -o vers=2 ... or to keep v3 and disable readdirplus doing something like: mount -o vers=3,nordirplus ... The later I didn't test but was suggested on #linuxfs. - 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.24-rc2 XFS nfsd hang / smbd too
On Thu, Nov 15, 2007 at 08:51:36AM +0100, Christian Kujau wrote: [c040914c] mutex_lock_nested+0xcc/0x2c0 [c016dc64] do_lookup+0xa4/0x190 [c016f6f9] __link_path_walk+0x749/0xd10 [c016fd04] link_path_walk+0x44/0xc0 [c016fd98] path_walk+0x18/0x20 [c016ff98] do_path_lookup+0x78/0x1c0 [c0170998] __user_walk_fd+0x38/0x60 [c0169bd1] vfs_stat_fd+0x21/0x50 [c0169ca1] vfs_stat+0x11/0x20 [c0169cc4] sys_stat64+0x14/0x30 [c01028d6] sysenter_past_esp+0x5f/0xa5 nfsd already wedged up and holds a lock, this is expected. I'm not sure what you're doing here, but a viable work-around for now might be to use nfsv2 mounts, something like mount -o vers=2 ... or to keep v3 and disable readdirplus doing something like: mount -o vers=3,nordirplus ... The later I didn't test but was suggested on #linuxfs. - 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/
2.6.24-rc2 XFS nfsd hang --- filldir change responsible?
On Tue, Nov 13, 2007 at 11:04:00PM -0800, Chris Wedgwood wrote: > With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always) > see a hang when accessing some NFS exported XFS filesystems. Local > access to these filesystems ahead of time works without problems. > > This does not occur with 2.6.23.1. The filesystem does not appear > to be corrupt. After some bisection pain (sg broken in the middle and XFS not compiling in other places) the regression seems to be: commit 051e7cd44ab8f0f7c2958371485b4a1ff64a8d1b Author: Christoph Hellwig <[EMAIL PROTECTED]> Date: Tue Aug 28 13:58:24 2007 +1000 [XFS] use filldir internally There have been a lot of changes since this so reverting it and retesting as-is won't work. I'll have to see what I can come up with after some sleep. I'm not building/testing with dmapi --- perhaps that makes a difference here? I would think it would have broken with xfsqa but the number of bug reports seems small so far. - 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/
2.6.24-rc2 XFS nfsd hang --- filldir change responsible?
On Tue, Nov 13, 2007 at 11:04:00PM -0800, Chris Wedgwood wrote: With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always) see a hang when accessing some NFS exported XFS filesystems. Local access to these filesystems ahead of time works without problems. This does not occur with 2.6.23.1. The filesystem does not appear to be corrupt. After some bisection pain (sg broken in the middle and XFS not compiling in other places) the regression seems to be: commit 051e7cd44ab8f0f7c2958371485b4a1ff64a8d1b Author: Christoph Hellwig [EMAIL PROTECTED] Date: Tue Aug 28 13:58:24 2007 +1000 [XFS] use filldir internally There have been a lot of changes since this so reverting it and retesting as-is won't work. I'll have to see what I can come up with after some sleep. I'm not building/testing with dmapi --- perhaps that makes a difference here? I would think it would have broken with xfsqa but the number of bug reports seems small so far. - 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/
2.6.24-rc2 XFS nfsd hang
With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always) see a hang when accessing some NFS exported XFS filesystems. Local access to these filesystems ahead of time works without problems. This does not occur with 2.6.23.1. The filesystem does not appear to be corrupt. The call chain for the wedged process is: [ 1462.911256] nfsd D 80547840 4760 2966 2 [ 1462.911283] 81010414d4d0 0046 81010414d610 [ 1462.911322] 810104cbc6e0 81010414d480 80746dc0 80746dc0 [ 1462.911360] 80744020 80746dc0 81010129c140 8101000ad100 [ 1462.911391] Call Trace: [ 1462.911417] [] __down+0xe9/0x101 [ 1462.911437] [] default_wake_function+0x0/0xe [ 1462.911458] [] __down_failed+0x35/0x3a [ 1462.911480] [] _xfs_buf_find+0x84/0x24d [ 1462.911501] [] _xfs_buf_find+0x193/0x24d [ 1462.911522] [] xfs_buf_lock+0x43/0x45 [ 1462.911543] [] _xfs_buf_find+0x1ba/0x24d [ 1462.911564] [] xfs_buf_get_flags+0x5a/0x14b [ 1462.911586] [] xfs_buf_read_flags+0x12/0x86 [ 1462.911607] [] xfs_trans_read_buf+0x4c/0x2cf [ 1462.911629] [] xfs_da_do_buf+0x41b/0x65b [ 1462.911652] [] xfs_da_read_buf+0x24/0x29 [ 1462.911673] [] xfs_dir2_block_lookup_int+0x4d/0x1ab [ 1462.911694] [] xfs_dir2_block_lookup_int+0x4d/0x1ab [ 1462.911717] [] xfs_dir2_block_lookup+0x15/0x8e [ 1462.911738] [] xfs_dir_lookup+0xd2/0x12c [ 1462.911761] [] submit_bio+0x10d/0x114 [ 1462.911781] [] xfs_dir_lookup_int+0x2c/0xc5 [ 1462.911802] [] lockdep_init_map+0x90/0x495 [ 1462.911823] [] xfs_lookup+0x44/0x6f [ 1462.911843] [] xfs_vn_lookup+0x29/0x60 [ 1462.915246] [] __lookup_hash+0xe5/0x109 [ 1462.915267] [] lookup_one_len+0x41/0x4e [ 1462.915289] [] compose_entry_fh+0xc1/0x117 [ 1462.915311] [] encode_entry+0x17c/0x38b [ 1462.915333] [] find_or_create_page+0x3f/0xc9 [ 1462.915355] [] _xfs_buf_lookup_pages+0x2c1/0x2f6 [ 1462.915377] [] _spin_unlock+0x1f/0x49 [ 1462.915399] [] cache_alloc_refill+0x1ba/0x4b9 [ 1462.915424] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915448] [] nfs3svc_encode_entry_plus+0x10/0x13 [ 1462.915469] [] xfs_dir2_block_getdents+0x15b/0x1e2 [ 1462.915491] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915514] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915534] [] xfs_readdir+0x91/0xb6 [ 1462.915557] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915579] [] xfs_file_readdir+0x31/0x40 [ 1462.915599] [] vfs_readdir+0x61/0x93 [ 1462.915619] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915642] [] nfsd_readdir+0x6d/0xc5 [ 1462.915663] [] nfsd3_proc_readdirplus+0x114/0x204 [ 1462.915686] [] nfsd_dispatch+0xde/0x1b6 [ 1462.915706] [] svc_process+0x3f8/0x717 [ 1462.915729] [] nfsd+0x1a9/0x2c1 [ 1462.915749] [] child_rip+0xa/0x12 [ 1462.915769] [] __svc_create_thread+0xea/0x1eb [ 1462.915792] [] nfsd+0x0/0x2c1 [ 1462.915812] [] child_rip+0x0/0x12 Over time other processes pile up beind this. [ 1462.910728] nfsd D 5440 2965 2 [ 1462.910769] 8101040cdd40 0046 0001 810103471900 [ 1462.910812] 8101029a72c0 8101040cdcf0 80746dc0 80746dc0 [ 1462.910852] 80744020 80746dc0 81010008e0c0 8101012a1040 [ 1462.910882] Call Trace: [ 1462.910909] [] nfsd_permission+0x95/0xeb [ 1462.910931] [] vfs_readdir+0x46/0x93 [ 1462.910950] [] mutex_lock_nested+0x165/0x27c [ 1462.910971] [] _spin_unlock+0x1f/0x49 [ 1462.910994] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.911015] [] vfs_readdir+0x46/0x93 [ 1462.911037] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.911057] [] nfsd_readdir+0x6d/0xc5 [ 1462.911079] [] nfsd3_proc_readdirplus+0x114/0x204 [ 1462.911102] [] nfsd_dispatch+0xde/0x1b6 [ 1462.911122] [] svc_process+0x3f8/0x717 [ 1462.911143] [] nfsd+0x1a9/0x2c1 [ 1462.911165] [] child_rip+0xa/0x12 [ 1462.911184] [] __svc_create_thread+0xea/0x1eb [ 1462.911206] [] nfsd+0x0/0x2c1 [ 1462.911225] [] child_rip+0x0/0x12 Any suggestions other than to bisect this? (Bisection might be painful as it crosses the x86-merge.) - 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/
2.6.24-rc2 XFS nfsd hang
With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always) see a hang when accessing some NFS exported XFS filesystems. Local access to these filesystems ahead of time works without problems. This does not occur with 2.6.23.1. The filesystem does not appear to be corrupt. The call chain for the wedged process is: [ 1462.911256] nfsd D 80547840 4760 2966 2 [ 1462.911283] 81010414d4d0 0046 81010414d610 [ 1462.911322] 810104cbc6e0 81010414d480 80746dc0 80746dc0 [ 1462.911360] 80744020 80746dc0 81010129c140 8101000ad100 [ 1462.911391] Call Trace: [ 1462.911417] [8052e638] __down+0xe9/0x101 [ 1462.911437] [8022cc80] default_wake_function+0x0/0xe [ 1462.911458] [8052e275] __down_failed+0x35/0x3a [ 1462.911480] [8035ac25] _xfs_buf_find+0x84/0x24d [ 1462.911501] [8035ad34] _xfs_buf_find+0x193/0x24d [ 1462.911522] [803599b1] xfs_buf_lock+0x43/0x45 [ 1462.911543] [8035ad5b] _xfs_buf_find+0x1ba/0x24d [ 1462.911564] [8035ae48] xfs_buf_get_flags+0x5a/0x14b [ 1462.911586] [8035b490] xfs_buf_read_flags+0x12/0x86 [ 1462.911607] [8034ecf6] xfs_trans_read_buf+0x4c/0x2cf [ 1462.911629] [803292be] xfs_da_do_buf+0x41b/0x65b [ 1462.911652] [80329568] xfs_da_read_buf+0x24/0x29 [ 1462.911673] [8032be40] xfs_dir2_block_lookup_int+0x4d/0x1ab [ 1462.911694] [8032be40] xfs_dir2_block_lookup_int+0x4d/0x1ab [ 1462.911717] [8032c718] xfs_dir2_block_lookup+0x15/0x8e [ 1462.911738] [8032b8e1] xfs_dir_lookup+0xd2/0x12c [ 1462.911761] [8036d658] submit_bio+0x10d/0x114 [ 1462.911781] [8034fb56] xfs_dir_lookup_int+0x2c/0xc5 [ 1462.911802] [802507a2] lockdep_init_map+0x90/0x495 [ 1462.911823] [80353436] xfs_lookup+0x44/0x6f [ 1462.911843] [8035e364] xfs_vn_lookup+0x29/0x60 [ 1462.915246] [8028856c] __lookup_hash+0xe5/0x109 [ 1462.915267] [802893dd] lookup_one_len+0x41/0x4e [ 1462.915289] [80303d05] compose_entry_fh+0xc1/0x117 [ 1462.915311] [80303f4c] encode_entry+0x17c/0x38b [ 1462.915333] [80261e4e] find_or_create_page+0x3f/0xc9 [ 1462.915355] [8035a2c0] _xfs_buf_lookup_pages+0x2c1/0x2f6 [ 1462.915377] [8052ec6b] _spin_unlock+0x1f/0x49 [ 1462.915399] [8027e632] cache_alloc_refill+0x1ba/0x4b9 [ 1462.915424] [8030415b] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915448] [8030416b] nfs3svc_encode_entry_plus+0x10/0x13 [ 1462.915469] [8032c67c] xfs_dir2_block_getdents+0x15b/0x1e2 [ 1462.915491] [8030415b] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915514] [8030415b] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915534] [8032b6da] xfs_readdir+0x91/0xb6 [ 1462.915557] [8030415b] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915579] [8035be9d] xfs_file_readdir+0x31/0x40 [ 1462.915599] [8028c9f8] vfs_readdir+0x61/0x93 [ 1462.915619] [8030415b] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915642] [802fc78e] nfsd_readdir+0x6d/0xc5 [ 1462.915663] [80303158] nfsd3_proc_readdirplus+0x114/0x204 [ 1462.915686] [802f8b82] nfsd_dispatch+0xde/0x1b6 [ 1462.915706] [805215cd] svc_process+0x3f8/0x717 [ 1462.915729] [802f9148] nfsd+0x1a9/0x2c1 [ 1462.915749] [8020c648] child_rip+0xa/0x12 [ 1462.915769] [80520af8] __svc_create_thread+0xea/0x1eb [ 1462.915792] [802f8f9f] nfsd+0x0/0x2c1 [ 1462.915812] [8020c63e] child_rip+0x0/0x12 Over time other processes pile up beind this. [ 1462.910728] nfsd D 5440 2965 2 [ 1462.910769] 8101040cdd40 0046 0001 810103471900 [ 1462.910812] 8101029a72c0 8101040cdcf0 80746dc0 80746dc0 [ 1462.910852] 80744020 80746dc0 81010008e0c0 8101012a1040 [ 1462.910882] Call Trace: [ 1462.910909] [802fbadf] nfsd_permission+0x95/0xeb [ 1462.910931] [8028c9dd] vfs_readdir+0x46/0x93 [ 1462.910950] [8052d729] mutex_lock_nested+0x165/0x27c [ 1462.910971] [8052ec6b] _spin_unlock+0x1f/0x49 [ 1462.910994] [8030415b] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.911015] [8028c9dd] vfs_readdir+0x46/0x93 [ 1462.911037] [8030415b] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.911057] [802fc78e] nfsd_readdir+0x6d/0xc5 [ 1462.911079] [80303158] nfsd3_proc_readdirplus+0x114/0x204 [ 1462.911102] [802f8b82] nfsd_dispatch+0xde/0x1b6 [ 1462.911122]
Re: [00/50] 2.6.22-stable review
> (to make it easier for people to click) actually, it's not a tarball either... am I seeing something stale or perhaps the result of slow 'kernel.org replication? - 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: [00/50] 2.6.22-stable review
On Mon, Sep 24, 2007 at 09:31:48AM -0700, Greg KH wrote: > A tarball of the patches can be found at: > kernel.org/pub/linux/kernel/v2.6/stable-testing/patch-2.6.22.8-rc1.gz ^^^ s/testing/review/ http://kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.22.8-rc1.gz (to make it easier for people to click) - 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: [00/50] 2.6.22-stable review
On Mon, Sep 24, 2007 at 09:31:48AM -0700, Greg KH wrote: A tarball of the patches can be found at: kernel.org/pub/linux/kernel/v2.6/stable-testing/patch-2.6.22.8-rc1.gz ^^^ s/testing/review/ http://kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.22.8-rc1.gz (to make it easier for people to click) - 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: [00/50] 2.6.22-stable review
(to make it easier for people to click) actually, it's not a tarball either... am I seeing something stale or perhaps the result of slow 'kernel.org replication? - 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: [RFC PATCH] Add a 'minimal tree install' target
On Thu, Sep 13, 2007 at 10:17:27PM +0200, Oleg Verych wrote: > That particular one-line `ALTARCH := i386' of course can be matched > simpler, because there's only *one* (as written above) whitespace and no > make's assignment variations, The goal is to extract the RHS from ALTARCH := ... > Also, please take a look on man isspace(). It matches much more > characters, than necessary for ordinary syntax whitespace. Good point. > Using [:blank:] (i.e. tab and space, with no options) is OK. Last > thing: i'm not sure, what that `+' is. I stick to BRE in sed, as it > should be, so just don't know what it does. The \+ was misplaced :-) I typed that very quickly and didn't think to hard. - 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: [RFC PATCH] Add a 'minimal tree install' target
On Thu, Sep 13, 2007 at 08:34:00PM +0200, Sam Ravnborg wrote:
> A few. Please address them and resubmit with full changelog and
> proper attribution (if possible) and a signed-of-by.
sure
> I would strongly prefer the name "build-pkg".
right
> The prefix -pkg is just to use the magic in top-level Makefile to
> dicert it to the right Makefile.
yeah, i had something a bit like originally but didn't like the name
so changed it and poked the top-level Makefile
> I would like to attribute whoever made this somehow.
so would i, i assume it was davej + others so i cc'd him on this
hoping for feedback
> This becomes obsolete when target is named -pkg
yes
> Here we could do a $(MAKE) KBUILD_SRC= clean
> This will leave all files needed for building external modules
> but delete the rest (almost).
ok, i'll try that
> set -e to bail out on error could do it for now.
will do
> kbuild will not like it either so you can drop this FIXME
ok
> > +# This relies on the following environment variables being sane and
> > +# passed in from the Makefiles:
> > +#
> > +#INSTALL_MINTREE_PATH
> > +#KERNELVERSION
> Could we pass this as parameters. This makes it explicit.
> You do not need to check them since this script is not
> supposed to be used stand-alone.
can do
> > +if [ "$srctree" != "$objtree" ] ; then
> > +cp --parents $(find -type f -name "Makefile*" -o -name "Kconfig*" -not
> > -ipath "$objtree/*Makefile" ) ${tgtdir}
>
> ^
> Why this wildcard??? (objtree/>* Seems to be a typing error.
no, it's so we catch things like
linux/build/Makefile
*and*
linux/build/foo/bar/Makefile
> > +#rm -rf ${tgtdir}/Documentation
> Remove this line since it is commented out
right, actually, it can be uncommented but the 'make help' fails; i'm
not sure if we need make help to work since most of the other targets
won't anyhow
so should i remove it (leaving 'make help' as usable) or remove it?
> > +rm -f ${tgtdir}/scripts/*.o
> > +rm -f ${tgtdir}/scripts/*/*.o
> If we do the make clean this is not needed.
ok
> Something less hardcoded are preferred. Maybe like:
> cp -a `ls | grep -v ^asm` asm-generic $(tgtdir}/include
ok (though i'm not a big fan of ls | grep as a rule, it tends to be
fragile when people do dumb things)
> Here we use readlink but in next line we use $ARCH.
> We should be consitent and use ARCH all over.
i tried to preserve as much logic as possible from the original
script, at least initially
i'll change that
> > +if [ "$ARCH" = "x86_64" ]; then
> > +cp -a asm-i386 ${tgtdir}/include
> > +fi
> Too hardcoded.
> Here we could use some sed magic to extract a potential ALTARCH from
> asm-${ARCH}/Kbuild
> My sed skills are too limited to do this in a minute... :-(
what about something like?
sed -n "s/^ALTARCH[[:space:]]:=[[:space:]]\(.*$\)\+/\1/p"
(i'm sure there is a better way though)
> This part I did not check up on - I assume it is correct.
it all seems to work
-
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: [RFC PATCH] Add a 'minimal tree install' target
On Thu, Sep 13, 2007 at 08:34:00PM +0200, Sam Ravnborg wrote:
A few. Please address them and resubmit with full changelog and
proper attribution (if possible) and a signed-of-by.
sure
I would strongly prefer the name build-pkg.
right
The prefix -pkg is just to use the magic in top-level Makefile to
dicert it to the right Makefile.
yeah, i had something a bit like originally but didn't like the name
so changed it and poked the top-level Makefile
I would like to attribute whoever made this somehow.
so would i, i assume it was davej + others so i cc'd him on this
hoping for feedback
This becomes obsolete when target is named -pkg
yes
Here we could do a $(MAKE) KBUILD_SRC= clean
This will leave all files needed for building external modules
but delete the rest (almost).
ok, i'll try that
set -e to bail out on error could do it for now.
will do
kbuild will not like it either so you can drop this FIXME
ok
+# This relies on the following environment variables being sane and
+# passed in from the Makefiles:
+#
+#INSTALL_MINTREE_PATH
+#KERNELVERSION
Could we pass this as parameters. This makes it explicit.
You do not need to check them since this script is not
supposed to be used stand-alone.
can do
+if [ $srctree != $objtree ] ; then
+cp --parents $(find -type f -name Makefile* -o -name Kconfig* -not
-ipath $objtree/*Makefile ) ${tgtdir}
^
Why this wildcard??? (objtree/*Makefile)
Seems to be a typing error.
no, it's so we catch things like
linux/build/Makefile
*and*
linux/build/foo/bar/Makefile
+#rm -rf ${tgtdir}/Documentation
Remove this line since it is commented out
right, actually, it can be uncommented but the 'make help' fails; i'm
not sure if we need make help to work since most of the other targets
won't anyhow
so should i remove it (leaving 'make help' as usable) or remove it?
+rm -f ${tgtdir}/scripts/*.o
+rm -f ${tgtdir}/scripts/*/*.o
If we do the make clean this is not needed.
ok
Something less hardcoded are preferred. Maybe like:
cp -a `ls | grep -v ^asm` asm-generic $(tgtdir}/include
ok (though i'm not a big fan of ls | grep as a rule, it tends to be
fragile when people do dumb things)
Here we use readlink but in next line we use $ARCH.
We should be consitent and use ARCH all over.
i tried to preserve as much logic as possible from the original
script, at least initially
i'll change that
+if [ $ARCH = x86_64 ]; then
+cp -a asm-i386 ${tgtdir}/include
+fi
Too hardcoded.
Here we could use some sed magic to extract a potential ALTARCH from
asm-${ARCH}/Kbuild
My sed skills are too limited to do this in a minute... :-(
what about something like?
sed -n s/^ALTARCH[[:space:]]:=[[:space:]]\(.*$\)\+/\1/p
(i'm sure there is a better way though)
This part I did not check up on - I assume it is correct.
it all seems to work
-
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: [RFC PATCH] Add a 'minimal tree install' target
On Thu, Sep 13, 2007 at 10:17:27PM +0200, Oleg Verych wrote: That particular one-line `ALTARCH := i386' of course can be matched simpler, because there's only *one* (as written above) whitespace and no make's assignment variations, The goal is to extract the RHS from ALTARCH := ... Also, please take a look on man isspace(). It matches much more characters, than necessary for ordinary syntax whitespace. Good point. Using [:blank:] (i.e. tab and space, with no options) is OK. Last thing: i'm not sure, what that `+' is. I stick to BRE in sed, as it should be, so just don't know what it does. The \+ was misplaced :-) I typed that very quickly and didn't think to hard. - 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/
[RFC PATCH] Add a 'minimal tree install' target
This is a somewhat rough first-pass at making a 'minimal tree'
installation target. This installs a partial source-tree which you
can use to build external modules against. It feels pretty unclean
but I'm not aware of a much better way to do some of this.
This patch works for me, even when using O=. It probably
needs further cleanups.
Comments?
-
Add a 'mintree-install' makefile target.
Red Hat and other distributions typically have some logic in their
kernel package build system to create/install 'minimalist source tree'
which contains enough state to build external modules against but is
much smaller than the entire build-tree.
This introduces similar logic, the guts of this was taken from a
Fedora Core spec file and mutilated to make it work for O=<...>
builds.
-
diff --git a/Makefile b/Makefile
index 3067f6a..1246939 100644
--- a/Makefile
+++ b/Makefile
@@ -1085,6 +1085,11 @@ package-dir := $(srctree)/scripts/package
$(Q)$(MAKE) $(build)=$(package-dir) $@
rpm: include/config/kernel.release FORCE
$(Q)$(MAKE) $(build)=$(package-dir) $@
+# /usr/src/linux to match what most distro's do
+#export INSTALL_MINTREE_PATH ?= /usr/src/linux
+export INSTALL_MINTREE_PATH ?= /tmp/mt-test/
+mintree-install: include/config/kernel.release FORCE
+ $(Q)$(MAKE) $(build)=$(package-dir) $@
# Brief documentation of the typical targets used
diff --git a/scripts/package/Makefile b/scripts/package/Makefile
index 7c434e0..0c5f07d 100644
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -86,6 +86,12 @@ tar%pkg: FORCE
clean-dirs += $(objtree)/tar-install/
+# minimal tree installation target
+# ---
+mintree-install: FORCE
+ $(MAKE) KBUILD_SRC=
+ $(CONFIG_SHELL) $(srctree)/scripts/package/mintree-install
+
# Help text displayed when executing 'make help'
# ---
help: FORCE
@@ -96,4 +102,6 @@ help: FORCE
@echo ' tar-pkg - Build the kernel as an uncompressed tarball'
@echo ' targz-pkg - Build the kernel as a gzip compressed
tarball'
@echo ' tarbz2-pkg - Build the kernel as a bzip2 compressed
tarball'
+ @echo ' mintree-install - Build the kernel and install a
minimal-build-tree'
+ @echo 'that can be used to build external modules
against'
diff --git a/scripts/package/mintree-install b/scripts/package/mintree-install
new file mode 100644
index 000..1362cc2
--- /dev/null
+++ b/scripts/package/mintree-install
@@ -0,0 +1,87 @@
+#!/bin/bash
+
+# miniman-tree-install
+#
+# This should install necessary the headers, makefiles and
+# configuration files in a location so that you can use kbuild to
+# build external (out of tree) modules without needing the entire
+# kernel build tree.
+#
+
+# This has been shamelessly taken from a Red Hat's spec file,
+#
http://cvs.fedora.redhat.com/viewcvs/devel/kernel/kernel.spec?rev=1.145=markup
+
+# FIXME:cw Some parts of this are still icky, it's not clear how best
+# to clean some of this up. Error handling is more or less
+# non-existent. You could argue that this entire process should be
+# done differently (ie. using kbuild knowledge instead of a whole lot
+# of hard-coded magic here).
+
+# FIXME:cw If any of srctree, objtree or INSTALL_MINTREE_PATH have
+# spaces in them some parts of this will fail as-is, it shouldn't be
+# that hard to fix (it's not clear if the rest of t kbuild is clean in
+# that respect though)
+
+# This relies on the following environment variables being sane and
+# passed in from the Makefiles:
+#
+#INSTALL_MINTREE_PATH
+#KERNELVERSION
+
+
+# target directory
+tgtdir="${INSTALL_MINTREE_PATH}"/${KERNELVERSION}/
+
+
+# And save the headers/makefiles etc for building modules against
+#
+# This all looks scary, but the end result is supposed to be:
+# * all arch relevant include/ files
+# * all Makefile/Kconfig files
+# * all script/ files
+
+cd "$srctree" || exit $?
+
+mkdir -p ${tgtdir}
+
+# first copy everything. If objtree differs from srctree (ie. O=<...>
+# is used) then make sure we don't copy the Makefile(s) from inside
+# $objtree
+if [ "$srctree" != "$objtree" ] ; then
+cp --parents $(find -type f -name "Makefile*" -o -name "Kconfig*" -not
-ipath "$objtree/*Makefile" ) ${tgtdir}
+else
+cp --parents $(find -type f -name "Makefile*" -o -name "Kconfig*")
${tgtdir}
+fi
+
+cp "${objtree}/Module.symvers" ${tgtdir}
+# then drop all but the needed Makefiles/Kconfig files
+#rm -rf ${tgtdir}/Documentation
+rm -rf "${tgtdir}/scripts"
+rm -rf "${tgtdir}/include"
+cp "${objtree}/.config" ${tgtdir}
+cp -a scripts ${tgtdir}
+if [ -d ${srctree}/arch/${ARCH}/scripts ]; then
+cp -a ${srctree}/arch/${ARCH}/scripts ${tgtdir}/arch/${ARCH} || :
+fi
+if [ -f ${objtree}/arch/${ARCH}/*lds ]; then
+cp -a ${objtree}/arch/${ARCH}/*lds ${tgtdir}/arch/${ARCH}/
[RFC PATCH] Add a 'minimal tree install' target
This is a somewhat rough first-pass at making a 'minimal tree'
installation target. This installs a partial source-tree which you
can use to build external modules against. It feels pretty unclean
but I'm not aware of a much better way to do some of this.
This patch works for me, even when using O=buildtree. It probably
needs further cleanups.
Comments?
-
Add a 'mintree-install' makefile target.
Red Hat and other distributions typically have some logic in their
kernel package build system to create/install 'minimalist source tree'
which contains enough state to build external modules against but is
much smaller than the entire build-tree.
This introduces similar logic, the guts of this was taken from a
Fedora Core spec file and mutilated to make it work for O=...
builds.
-
diff --git a/Makefile b/Makefile
index 3067f6a..1246939 100644
--- a/Makefile
+++ b/Makefile
@@ -1085,6 +1085,11 @@ package-dir := $(srctree)/scripts/package
$(Q)$(MAKE) $(build)=$(package-dir) $@
rpm: include/config/kernel.release FORCE
$(Q)$(MAKE) $(build)=$(package-dir) $@
+# /usr/src/linux to match what most distro's do
+#export INSTALL_MINTREE_PATH ?= /usr/src/linux
+export INSTALL_MINTREE_PATH ?= /tmp/mt-test/
+mintree-install: include/config/kernel.release FORCE
+ $(Q)$(MAKE) $(build)=$(package-dir) $@
# Brief documentation of the typical targets used
diff --git a/scripts/package/Makefile b/scripts/package/Makefile
index 7c434e0..0c5f07d 100644
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -86,6 +86,12 @@ tar%pkg: FORCE
clean-dirs += $(objtree)/tar-install/
+# minimal tree installation target
+# ---
+mintree-install: FORCE
+ $(MAKE) KBUILD_SRC=
+ $(CONFIG_SHELL) $(srctree)/scripts/package/mintree-install
+
# Help text displayed when executing 'make help'
# ---
help: FORCE
@@ -96,4 +102,6 @@ help: FORCE
@echo ' tar-pkg - Build the kernel as an uncompressed tarball'
@echo ' targz-pkg - Build the kernel as a gzip compressed
tarball'
@echo ' tarbz2-pkg - Build the kernel as a bzip2 compressed
tarball'
+ @echo ' mintree-install - Build the kernel and install a
minimal-build-tree'
+ @echo 'that can be used to build external modules
against'
diff --git a/scripts/package/mintree-install b/scripts/package/mintree-install
new file mode 100644
index 000..1362cc2
--- /dev/null
+++ b/scripts/package/mintree-install
@@ -0,0 +1,87 @@
+#!/bin/bash
+
+# miniman-tree-install
+#
+# This should install necessary the headers, makefiles and
+# configuration files in a location so that you can use kbuild to
+# build external (out of tree) modules without needing the entire
+# kernel build tree.
+#
+
+# This has been shamelessly taken from a Red Hat's spec file,
+#
http://cvs.fedora.redhat.com/viewcvs/devel/kernel/kernel.spec?rev=1.145view=markup
+
+# FIXME:cw Some parts of this are still icky, it's not clear how best
+# to clean some of this up. Error handling is more or less
+# non-existent. You could argue that this entire process should be
+# done differently (ie. using kbuild knowledge instead of a whole lot
+# of hard-coded magic here).
+
+# FIXME:cw If any of srctree, objtree or INSTALL_MINTREE_PATH have
+# spaces in them some parts of this will fail as-is, it shouldn't be
+# that hard to fix (it's not clear if the rest of t kbuild is clean in
+# that respect though)
+
+# This relies on the following environment variables being sane and
+# passed in from the Makefiles:
+#
+#INSTALL_MINTREE_PATH
+#KERNELVERSION
+
+
+# target directory
+tgtdir=${INSTALL_MINTREE_PATH}/${KERNELVERSION}/
+
+
+# And save the headers/makefiles etc for building modules against
+#
+# This all looks scary, but the end result is supposed to be:
+# * all arch relevant include/ files
+# * all Makefile/Kconfig files
+# * all script/ files
+
+cd $srctree || exit $?
+
+mkdir -p ${tgtdir}
+
+# first copy everything. If objtree differs from srctree (ie. O=...
+# is used) then make sure we don't copy the Makefile(s) from inside
+# $objtree
+if [ $srctree != $objtree ] ; then
+cp --parents $(find -type f -name Makefile* -o -name Kconfig* -not
-ipath $objtree/*Makefile ) ${tgtdir}
+else
+cp --parents $(find -type f -name Makefile* -o -name Kconfig*)
${tgtdir}
+fi
+
+cp ${objtree}/Module.symvers ${tgtdir}
+# then drop all but the needed Makefiles/Kconfig files
+#rm -rf ${tgtdir}/Documentation
+rm -rf ${tgtdir}/scripts
+rm -rf ${tgtdir}/include
+cp ${objtree}/.config ${tgtdir}
+cp -a scripts ${tgtdir}
+if [ -d ${srctree}/arch/${ARCH}/scripts ]; then
+cp -a ${srctree}/arch/${ARCH}/scripts ${tgtdir}/arch/${ARCH} || :
+fi
+if [ -f ${objtree}/arch/${ARCH}/*lds ]; then
+cp -a ${objtree}/arch/${ARCH}/*lds ${tgtdir}/arch/${ARCH}/ || :
+fi
+rm -f
Re: RFC: drop support for gcc < 4.0
On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote: > Are there any architectures still requiring a gcc < 4.0 ? Yes, sadly in some places (embedded) there are people with older compiler who want newer kernels. - 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: RFC: drop support for gcc 4.0
On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote: Are there any architectures still requiring a gcc 4.0 ? Yes, sadly in some places (embedded) there are people with older compiler who want newer kernels. - 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 1/3] Fix XFS_IOC_FSGEOMETRY_V1 in compat mode
On Wed, May 30, 2007 at 02:59:55PM +0200, Michal Marek wrote:
> +typedef struct xfs_fsop_geom_v132 {
wouldn't xfs_fsop_geom_v1_32
^
> + __u32 blocksize; /* filesystem (data) block size */
[...]
> + __u32 dirblocksize; /* directory block size, bytes */
> +} __attribute__((packed)) xfs_fsop_geom_v132_t;
and xfs_fsop_geom_v1_32_t
^
read better there?
-
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 1/3] Fix XFS_IOC_FSGEOMETRY_V1 in compat mode
On Wed, May 30, 2007 at 02:59:55PM +0200, Michal Marek wrote:
+typedef struct xfs_fsop_geom_v132 {
wouldn't xfs_fsop_geom_v1_32
^
+ __u32 blocksize; /* filesystem (data) block size */
[...]
+ __u32 dirblocksize; /* directory block size, bytes */
+} __attribute__((packed)) xfs_fsop_geom_v132_t;
and xfs_fsop_geom_v1_32_t
^
read better there?
-
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/
(hacky) [PATCH] silence MODPOST section mismatch warnings
MODPOST seems to be spewing bogus warnings. It's not clear how best to fix it so perhaps we should silence it for now? diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 113dc77..bd6fe7b 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -872,6 +872,10 @@ static void warn_sec_mismatch(const char *modname, const char *fromsec, sechdrs[hdr->e_shstrndx].sh_offset; const char *secname = secstrings + sechdrs[sym->st_shndx].sh_name; + /* FIXME: this function doesn't work correctly anymore, it's +* not clear if it should be fixed or removed. */ + return; + find_symbols_between(elf, r.r_offset, fromsec, , ); refsym = find_elf_symbol(elf, r.r_addend, sym); - 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/
[RFC] nfs: memclear_highpage_flush -> zero_user_page conversion
Does this look correct?
diff --git a/fs/nfs/read.c b/fs/nfs/read.c
index 9a55807..7bd7cb9 100644
--- a/fs/nfs/read.c
+++ b/fs/nfs/read.c
@@ -79,7 +79,7 @@ void nfs_readdata_release(void *data)
static
int nfs_return_empty_page(struct page *page)
{
- memclear_highpage_flush(page, 0, PAGE_CACHE_SIZE);
+ zero_user_page(page, 0, PAGE_CACHE_SIZE, KM_USER0);
SetPageUptodate(page);
unlock_page(page);
return 0;
@@ -103,10 +103,10 @@ static void
nfs_readpage_truncate_uninitialised_page(struct nfs_read_data *data)
pglen = PAGE_CACHE_SIZE - base;
for (;;) {
if (remainder <= pglen) {
- memclear_highpage_flush(*pages, base, remainder);
+ zero_user_page(*pages, base, remainder, KM_USER0);
break;
}
- memclear_highpage_flush(*pages, base, pglen);
+ zero_user_page(*pages, base, pglen, KM_USER0);
pages++;
remainder -= pglen;
pglen = PAGE_CACHE_SIZE;
@@ -130,7 +130,7 @@ static int nfs_readpage_async(struct nfs_open_context *ctx,
struct inode *inode,
return PTR_ERR(new);
}
if (len < PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, len, PAGE_CACHE_SIZE - len);
+ zero_user_page(page, len, PAGE_CACHE_SIZE - len, KM_USER0);
nfs_list_add_request(new, _request);
if (NFS_SERVER(inode)->rsize < PAGE_CACHE_SIZE)
@@ -532,7 +532,7 @@ readpage_async_filler(void *data, struct page *page)
return PTR_ERR(new);
}
if (len < PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, len, PAGE_CACHE_SIZE - len);
+ zero_user_page(page, len, PAGE_CACHE_SIZE - len, KM_USER0);
nfs_pageio_add_request(desc->pgio, new);
return 0;
}
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index de92b95..211d0b1 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -168,7 +168,7 @@ static void nfs_mark_uptodate(struct page *page, unsigned
int base, unsigned int
if (count != nfs_page_length(page))
return;
if (count != PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, count, PAGE_CACHE_SIZE - count);
+ zero_user_page(page, count, PAGE_CACHE_SIZE - count, KM_USER0);
SetPageUptodate(page);
}
-
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/
[RFC] nfs: memclear_highpage_flush - zero_user_page conversion
Does this look correct?
diff --git a/fs/nfs/read.c b/fs/nfs/read.c
index 9a55807..7bd7cb9 100644
--- a/fs/nfs/read.c
+++ b/fs/nfs/read.c
@@ -79,7 +79,7 @@ void nfs_readdata_release(void *data)
static
int nfs_return_empty_page(struct page *page)
{
- memclear_highpage_flush(page, 0, PAGE_CACHE_SIZE);
+ zero_user_page(page, 0, PAGE_CACHE_SIZE, KM_USER0);
SetPageUptodate(page);
unlock_page(page);
return 0;
@@ -103,10 +103,10 @@ static void
nfs_readpage_truncate_uninitialised_page(struct nfs_read_data *data)
pglen = PAGE_CACHE_SIZE - base;
for (;;) {
if (remainder = pglen) {
- memclear_highpage_flush(*pages, base, remainder);
+ zero_user_page(*pages, base, remainder, KM_USER0);
break;
}
- memclear_highpage_flush(*pages, base, pglen);
+ zero_user_page(*pages, base, pglen, KM_USER0);
pages++;
remainder -= pglen;
pglen = PAGE_CACHE_SIZE;
@@ -130,7 +130,7 @@ static int nfs_readpage_async(struct nfs_open_context *ctx,
struct inode *inode,
return PTR_ERR(new);
}
if (len PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, len, PAGE_CACHE_SIZE - len);
+ zero_user_page(page, len, PAGE_CACHE_SIZE - len, KM_USER0);
nfs_list_add_request(new, one_request);
if (NFS_SERVER(inode)-rsize PAGE_CACHE_SIZE)
@@ -532,7 +532,7 @@ readpage_async_filler(void *data, struct page *page)
return PTR_ERR(new);
}
if (len PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, len, PAGE_CACHE_SIZE - len);
+ zero_user_page(page, len, PAGE_CACHE_SIZE - len, KM_USER0);
nfs_pageio_add_request(desc-pgio, new);
return 0;
}
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index de92b95..211d0b1 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -168,7 +168,7 @@ static void nfs_mark_uptodate(struct page *page, unsigned
int base, unsigned int
if (count != nfs_page_length(page))
return;
if (count != PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, count, PAGE_CACHE_SIZE - count);
+ zero_user_page(page, count, PAGE_CACHE_SIZE - count, KM_USER0);
SetPageUptodate(page);
}
-
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/
(hacky) [PATCH] silence MODPOST section mismatch warnings
MODPOST seems to be spewing bogus warnings. It's not clear how best to fix it so perhaps we should silence it for now? diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 113dc77..bd6fe7b 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -872,6 +872,10 @@ static void warn_sec_mismatch(const char *modname, const char *fromsec, sechdrs[hdr-e_shstrndx].sh_offset; const char *secname = secstrings + sechdrs[sym-st_shndx].sh_name; + /* FIXME: this function doesn't work correctly anymore, it's +* not clear if it should be fixed or removed. */ + return; + find_symbols_between(elf, r.r_offset, fromsec, before, after); refsym = find_elf_symbol(elf, r.r_addend, sym); - 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] [x86-64] Add getcpu and epoll_pwait system calls.
On Wed, May 09, 2007 at 12:24:32AM +0200, Andi Kleen wrote: > Somehow yes. But i'm not going to add a useless syscall just to > shut it up. It turns out this has come up in other places. Sam has a suggestion on how to silence this per-arch so I'll post a patch once that change is in. - 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] [x86-64] Add getcpu and epoll_pwait system calls.
On Wed, May 09, 2007 at 12:13:48AM +0200, Andi Kleen wrote: > Nope. There already is a getcpu vsyscall. This is not needed. The kbuild magic that checks for missing syscalls needs to be taught about this then I take it? - 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] [x86-64] Add getcpu and epoll_pwait system calls.
On Tue, May 08, 2007 at 11:37:26AM -0700, Chris Wedgwood wrote: > +#define __NR_getcpu 280 I see something was merged just now that uses 280. Should I resubmit this using 281 & 282? - 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] Type cast some size_t arguments to 'unsigned int' to avoid (harmless) gcc printk warnings.
On Wed, May 09, 2007 at 12:03:19AM +0400, Alexey Dobriyan wrote: > For one, size_t should be printed with %zu. thanks, i wasn't aware of this > For two, this is already fixed in mainline. this was against mainline that wasn't more than an hour old when i sent the patch - 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] Type cast some size_t arguments to 'unsigned int' to avoid (harmless) gcc printk warnings.
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
---
net/sunrpc/sched.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
index 4a53e94..60df3c1 100644
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -764,7 +764,7 @@ void *rpc_malloc(struct rpc_task *task, size_t size)
buf = kmalloc(size, gfp);
*buf = size;
dprintk("RPC: %5u allocated buffer of size %u at %p\n",
- task->tk_pid, size, buf);
+ task->tk_pid, (unsigned int)size, buf);
return (void *) ++buf;
}
@@ -783,7 +783,7 @@ void rpc_free(void *buffer)
buf--;
dprintk("RPC: freeing buffer of size %u at %p\n",
- size, buf);
+ (unsigned int)size, buf);
if (size <= RPC_BUFFER_MAXSIZE)
mempool_free(buf, rpc_buffer_mempool);
else
--
1.5.1.3
-
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] [x86-64] Add getcpu and epoll_pwait system calls.
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]> --- include/asm-x86_64/unistd.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/asm-x86_64/unistd.h b/include/asm-x86_64/unistd.h index 26e23e0..aa7d4bf 100644 --- a/include/asm-x86_64/unistd.h +++ b/include/asm-x86_64/unistd.h @@ -619,6 +619,10 @@ __SYSCALL(__NR_sync_file_range, sys_sync_file_range) __SYSCALL(__NR_vmsplice, sys_vmsplice) #define __NR_move_pages279 __SYSCALL(__NR_move_pages, sys_move_pages) +#define __NR_getcpu280 +__SYSCALL(__NR_getcpu, sys_getcpu) +#define __NR_epoll_pwait 281 +__SYSCALL(__NR_epoll_pwait, sys_epoll_pwait) #ifndef __NO_STUBS #define __ARCH_WANT_OLD_READDIR -- 1.5.1.3 - 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] Remove unused device_probe_drivers function.
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
---
drivers/base/dd.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 92428e5..b0088b0 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -207,19 +207,6 @@ static int __device_attach(struct device_driver * drv,
void * data)
return driver_probe_device(drv, dev);
}
-static int device_probe_drivers(void *data)
-{
- struct device *dev = data;
- int ret = 0;
-
- if (dev->bus) {
- down(>sem);
- ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
- up(>sem);
- }
- return ret;
-}
-
/**
* device_attach - try to attach device to a driver.
* @dev: device.
--
1.5.1.3
-
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] Remove unused device_probe_drivers function.
Signed-off-by: Chris Wedgwood [EMAIL PROTECTED]
---
drivers/base/dd.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 92428e5..b0088b0 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -207,19 +207,6 @@ static int __device_attach(struct device_driver * drv,
void * data)
return driver_probe_device(drv, dev);
}
-static int device_probe_drivers(void *data)
-{
- struct device *dev = data;
- int ret = 0;
-
- if (dev-bus) {
- down(dev-sem);
- ret = bus_for_each_drv(dev-bus, NULL, dev, __device_attach);
- up(dev-sem);
- }
- return ret;
-}
-
/**
* device_attach - try to attach device to a driver.
* @dev: device.
--
1.5.1.3
-
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] Type cast some size_t arguments to 'unsigned int' to avoid (harmless) gcc printk warnings.
Signed-off-by: Chris Wedgwood [EMAIL PROTECTED] --- net/sunrpc/sched.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c index 4a53e94..60df3c1 100644 --- a/net/sunrpc/sched.c +++ b/net/sunrpc/sched.c @@ -764,7 +764,7 @@ void *rpc_malloc(struct rpc_task *task, size_t size) buf = kmalloc(size, gfp); *buf = size; dprintk(RPC: %5u allocated buffer of size %u at %p\n, - task-tk_pid, size, buf); + task-tk_pid, (unsigned int)size, buf); return (void *) ++buf; } @@ -783,7 +783,7 @@ void rpc_free(void *buffer) buf--; dprintk(RPC: freeing buffer of size %u at %p\n, - size, buf); + (unsigned int)size, buf); if (size = RPC_BUFFER_MAXSIZE) mempool_free(buf, rpc_buffer_mempool); else -- 1.5.1.3 - 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] [x86-64] Add getcpu and epoll_pwait system calls.
Signed-off-by: Chris Wedgwood [EMAIL PROTECTED] --- include/asm-x86_64/unistd.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/asm-x86_64/unistd.h b/include/asm-x86_64/unistd.h index 26e23e0..aa7d4bf 100644 --- a/include/asm-x86_64/unistd.h +++ b/include/asm-x86_64/unistd.h @@ -619,6 +619,10 @@ __SYSCALL(__NR_sync_file_range, sys_sync_file_range) __SYSCALL(__NR_vmsplice, sys_vmsplice) #define __NR_move_pages279 __SYSCALL(__NR_move_pages, sys_move_pages) +#define __NR_getcpu280 +__SYSCALL(__NR_getcpu, sys_getcpu) +#define __NR_epoll_pwait 281 +__SYSCALL(__NR_epoll_pwait, sys_epoll_pwait) #ifndef __NO_STUBS #define __ARCH_WANT_OLD_READDIR -- 1.5.1.3 - 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] Type cast some size_t arguments to 'unsigned int' to avoid (harmless) gcc printk warnings.
On Wed, May 09, 2007 at 12:03:19AM +0400, Alexey Dobriyan wrote: For one, size_t should be printed with %zu. thanks, i wasn't aware of this For two, this is already fixed in mainline. this was against mainline that wasn't more than an hour old when i sent the patch - 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] [x86-64] Add getcpu and epoll_pwait system calls.
On Tue, May 08, 2007 at 11:37:26AM -0700, Chris Wedgwood wrote: +#define __NR_getcpu 280 I see something was merged just now that uses 280. Should I resubmit this using 281 282? - 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] [x86-64] Add getcpu and epoll_pwait system calls.
On Wed, May 09, 2007 at 12:13:48AM +0200, Andi Kleen wrote: Nope. There already is a getcpu vsyscall. This is not needed. The kbuild magic that checks for missing syscalls needs to be taught about this then I take it? - 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] [x86-64] Add getcpu and epoll_pwait system calls.
On Wed, May 09, 2007 at 12:24:32AM +0200, Andi Kleen wrote: Somehow yes. But i'm not going to add a useless syscall just to shut it up. It turns out this has come up in other places. Sam has a suggestion on how to silence this per-arch so I'll post a patch once that change is in. - 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 0/5] fallocate system call
On Mon, Apr 30, 2007 at 03:56:32PM +1000, David Chinner wrote: > On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote: > IIRC, the argument for FA_ALLOCATE changing file size is that > posix_fallocate() is supposed to change the file size. But it's not posix_fallocate; it's something more generic. glibc can do posix_fallocate using truncate + fallocate. > Note that the way XFS implements growing the file size after the > allocation is via a truncate What's wrong with that? That seems very reasonable. > That's would what I did because otherwise you'd use ftruncate64(). > Without documented behaviour or an ext4 implementation, I have to > ask what it's supposed to do, though ;) How many *real* users are there for ext4? Why does 'what ext4 does' define 'the semantics'? Surely semantics should be decided either by precedent (if there is an existing relevant userbase) or sensible thought and some debate? - 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 0/5] fallocate system call
On Mon, Apr 30, 2007 at 03:56:32PM +1000, David Chinner wrote: On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote: IIRC, the argument for FA_ALLOCATE changing file size is that posix_fallocate() is supposed to change the file size. But it's not posix_fallocate; it's something more generic. glibc can do posix_fallocate using truncate + fallocate. Note that the way XFS implements growing the file size after the allocation is via a truncate What's wrong with that? That seems very reasonable. That's would what I did because otherwise you'd use ftruncate64(). Without documented behaviour or an ext4 implementation, I have to ask what it's supposed to do, though ;) How many *real* users are there for ext4? Why does 'what ext4 does' define 'the semantics'? Surely semantics should be decided either by precedent (if there is an existing relevant userbase) or sensible thought and some debate? - 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 0/5] fallocate system call
On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote: > For FA_ALLOCATE, it's supposed to change the file size if we > allocate past EOF, right? I would argue no. Use truncate for that. > For FA_DEALLOCATE, does it change the filesize at all? Same as above. > Or does > it just punch a hole in the file? Yes. > FWIW, we definitely need a FA_PREALLOCATE mode (FA_ALLOCATE but does > not change file size) so we can preallocate beyond EOF for apps > which use O_APPEND (i.e. changing file size would cause problems for > them). FA_ALLOCATE should be able to allocate past-EOF I would argue. - 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 0/5] fallocate system call
On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote: For FA_ALLOCATE, it's supposed to change the file size if we allocate past EOF, right? I would argue no. Use truncate for that. For FA_DEALLOCATE, does it change the filesize at all? Same as above. Or does it just punch a hole in the file? Yes. FWIW, we definitely need a FA_PREALLOCATE mode (FA_ALLOCATE but does not change file size) so we can preallocate beyond EOF for apps which use O_APPEND (i.e. changing file size would cause problems for them). FA_ALLOCATE should be able to allocate past-EOF I would argue. - 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 0/5] fallocate system call
On Fri, Apr 27, 2007 at 07:46:13PM +0200, Heiko Carstens wrote: > If one insists to have fd at first argument, what is wrong with > having u32 arguments only? Well, I was one of those who objected as it seems *UGLY* to me. > It's not that this syscall comes even close to what can be > considered performance critical... Right. > It adds userspace overhead for one architecture. Every *trace and > *libc needs special handling on s390 for this syscall. I would > prefer to avoid this. I'm not that bothered about it. I would prefer it did use clean 64-bit arguments, but given it's a non-critical syscall I'm don't think the aesthetics are worth impossing crud on s390 for. - 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 0/5] fallocate system call
On Fri, Apr 27, 2007 at 07:46:13PM +0200, Heiko Carstens wrote: If one insists to have fd at first argument, what is wrong with having u32 arguments only? Well, I was one of those who objected as it seems *UGLY* to me. It's not that this syscall comes even close to what can be considered performance critical... Right. It adds userspace overhead for one architecture. Every *trace and *libc needs special handling on s390 for this syscall. I would prefer to avoid this. I'm not that bothered about it. I would prefer it did use clean 64-bit arguments, but given it's a non-critical syscall I'm don't think the aesthetics are worth impossing crud on s390 for. - 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: Linux 2.6.21-rc6
On Sun, Apr 08, 2007 at 08:59:03PM -0400, Jeff Garzik wrote: > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch > > It sounded this was specific to Ingo. I'm not sure, it sounds a bit like something I saw a while ago. I would have to check for sure, I made a quick debugging patch (sent to netdev) and it went away so I think my last though was a miscompilation. - 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: Linux 2.6.21-rc6
On Sun, Apr 08, 2007 at 08:59:03PM -0400, Jeff Garzik wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch It sounded this was specific to Ingo. I'm not sure, it sounds a bit like something I saw a while ago. I would have to check for sure, I made a quick debugging patch (sent to netdev) and it went away so I think my last though was a miscompilation. - 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: Warning: unable to open an initial console.
On Mon, Apr 02, 2007 at 12:04:56PM -0700, Tom Strader wrote: > I have seen quite a few posts regarding unable to open an initial > console, but my system seems to have the necessary things in place > so I come looking for help. your rootfs/initramfs/initrd is missing a valid working /dev/console > VFS: Mounted root (jffs2 filesystem). check /dev/ on this filesystem - 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: Warning: unable to open an initial console.
On Mon, Apr 02, 2007 at 12:04:56PM -0700, Tom Strader wrote: I have seen quite a few posts regarding unable to open an initial console, but my system seems to have the necessary things in place so I come looking for help. your rootfs/initramfs/initrd is missing a valid working /dev/console VFS: Mounted root (jffs2 filesystem). check /dev/ on this filesystem - 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: Interface for the new fallocate() system call
On Thu, Mar 29, 2007 at 05:21:26PM +0530, Amit K. Arora wrote: >int fallocate(int fd, loff_t offset, loff_t len, int mode) Right now there are only two possible values for mode --- it's not clear what additional values there will be in the future. How about two syscalls? If we decide later on we need something more complicated we can revisit this and *THEN* add another system call which may end up being a superset of the other two. I know that sounds somewhat icky but: * it's fairly simple * we get nice argument handling on all arches by dropping u32 mode (don't we?) * syscalls don't really cost a lot to keep about, they do cost in terms on maintenance though, but in this case i don't see it being all that much of a problem * IMO badly/over designed syscalls are going to be a bigger problem long term Given that *NO* single fs in mainline right now can *reliably* use this functionality for a while maybe whatever solution people come up with next should sit in -mm for a while? At least that gives people exposure to it and a chance to make some changes as once it's merged to mainline it's pretty hard to change. - 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: Interface for the new fallocate() system call
On Thu, Mar 29, 2007 at 05:21:26PM +0530, Amit K. Arora wrote: int fallocate(int fd, loff_t offset, loff_t len, int mode) Right now there are only two possible values for mode --- it's not clear what additional values there will be in the future. How about two syscalls? If we decide later on we need something more complicated we can revisit this and *THEN* add another system call which may end up being a superset of the other two. I know that sounds somewhat icky but: * it's fairly simple * we get nice argument handling on all arches by dropping u32 mode (don't we?) * syscalls don't really cost a lot to keep about, they do cost in terms on maintenance though, but in this case i don't see it being all that much of a problem * IMO badly/over designed syscalls are going to be a bigger problem long term Given that *NO* single fs in mainline right now can *reliably* use this functionality for a while maybe whatever solution people come up with next should sit in -mm for a while? At least that gives people exposure to it and a chance to make some changes as once it's merged to mainline it's pretty hard to change. - 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: [RFC][PATCH] sys_fallocate() system call
I hate to comment at this late stage, especially on something that I think is really a great idea (I did similar more complex, sys_blkalloc with even more arguments time ago --- I'm glad given how complex this thread has become I didn't post them now). In the past there wasn't that much incentive to get this functionality exposed because of various other issues (mmap + page dirty didn't flush reliably) which are close to being resolve, so I think the timing of this is really great On Wed, Mar 21, 2007 at 05:34:25PM +0530, Amit K. Arora wrote: > As suggested by you and Russel, I have made this change to the > patch. Here is how it looks like now. Please let me know if anyone > has concerns about passing arguments this way (breaking each > "loff_t" into two "u32"s). I really dislike breaking 64-bit args up unless it's necessary. I guess it doesn't really hurt, but it feels needlessly ugly. > + .long sys_fallocate /* 320 */ > +/* > + * fallocate() modes > + */ > +#define FA_ALLOCATE 0x1 > +#define FA_DEALLOCATE0x2 > + given there are the only TWO modes right now, why not leave the arguments as 64-bit sane and simply have two syscalls, one for each? - 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: [RFC][PATCH] sys_fallocate() system call
I hate to comment at this late stage, especially on something that I think is really a great idea (I did similar more complex, sys_blkalloc with even more arguments time ago --- I'm glad given how complex this thread has become I didn't post them now). In the past there wasn't that much incentive to get this functionality exposed because of various other issues (mmap + page dirty didn't flush reliably) which are close to being resolve, so I think the timing of this is really great On Wed, Mar 21, 2007 at 05:34:25PM +0530, Amit K. Arora wrote: As suggested by you and Russel, I have made this change to the patch. Here is how it looks like now. Please let me know if anyone has concerns about passing arguments this way (breaking each loff_t into two u32s). I really dislike breaking 64-bit args up unless it's necessary. I guess it doesn't really hurt, but it feels needlessly ugly. + .long sys_fallocate /* 320 */ +/* + * fallocate() modes + */ +#define FA_ALLOCATE 0x1 +#define FA_DEALLOCATE0x2 + given there are the only TWO modes right now, why not leave the arguments as 64-bit sane and simply have two syscalls, one for each? - 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] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set
On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote: > This patch allows for ibm-acpi to coexist (with diminished > functionality) with other drivers like ACPI_BAY. Given the ACP_IBM_BAY implementation is more complete (or seems to be, please comment if that isn't the case) we should probably actually make sure that is the *preferred* code used (on suitable hardware) at run time surely? That way distributions can build both options and on IBM/Lenovo hardware it will use the IBM ACPI code and otherwise will use the generic ACPI BAY code? Perhaps the IBM_ACPI_BAY code should go away and any missing functionality provided there should be merged into ACPI_BAY? - 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] ACPI_IBM_BAY can not coexist with ACPI_BAY
ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI code to fail to initialize so all the IBM ACPI functionality is missing. The simplest fix is to just make sure the Kconfig magic disallows ACPI_IBM_BAY when ACPI_BAY is enabled. Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index e2ce4a9..1a83fc6 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -246,7 +246,7 @@ config ACPI_IBM_DOCK config ACPI_IBM_BAY bool "Legacy Removable Bay Support" - depends on ACPI_IBM + depends on ACPI_IBM && !ACPI_BAY default y ---help--- Allows the ibm_acpi driver to handle removable bays. It will allow - 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] ACPI_IBM_BAY can not coexist with ACPI_BAY
ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI code to fail to initialize so all the IBM ACPI functionality is missing. The simplest fix is to just make sure the Kconfig magic disallows ACPI_IBM_BAY when ACPI_BAY is enabled. Signed-off-by: Chris Wedgwood [EMAIL PROTECTED] diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index e2ce4a9..1a83fc6 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -246,7 +246,7 @@ config ACPI_IBM_DOCK config ACPI_IBM_BAY bool Legacy Removable Bay Support - depends on ACPI_IBM + depends on ACPI_IBM !ACPI_BAY default y ---help--- Allows the ibm_acpi driver to handle removable bays. It will allow - 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] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set
On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote: This patch allows for ibm-acpi to coexist (with diminished functionality) with other drivers like ACPI_BAY. Given the ACP_IBM_BAY implementation is more complete (or seems to be, please comment if that isn't the case) we should probably actually make sure that is the *preferred* code used (on suitable hardware) at run time surely? That way distributions can build both options and on IBM/Lenovo hardware it will use the IBM ACPI code and otherwise will use the generic ACPI BAY code? Perhaps the IBM_ACPI_BAY code should go away and any missing functionality provided there should be merged into ACPI_BAY? - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thu, Jan 18, 2007 at 10:29:14AM +0100, joachim wrote: > Not only has it only been on Nvidia chipsets but we have only seen > reports on the Nvidia CK804 SATA controller. People have reported problems with other controllers. I have one here I can test given a day or so. I don't think it's SATA related, it just happens that it shows up well there, for networking you would end up with the odd corrupted packet probably and end up just dropping those so it might not be noticeable. - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thu, Jan 18, 2007 at 04:00:28AM -0700, Erik Andersen wrote: > I just tried again and while using iommu=soft does avoid the > corruption problem, as with previous kernels with 2.6.20-rc5 using > iommu=soft still makes my pcHDTV HD5500 DVB cards not work. i would file a separate bug about that, presumably it won't work in intel based machines too if the driver has dma api bugs - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thu, Jan 18, 2007 at 04:00:28AM -0700, Erik Andersen wrote: I just tried again and while using iommu=soft does avoid the corruption problem, as with previous kernels with 2.6.20-rc5 using iommu=soft still makes my pcHDTV HD5500 DVB cards not work. i would file a separate bug about that, presumably it won't work in intel based machines too if the driver has dma api bugs - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thu, Jan 18, 2007 at 10:29:14AM +0100, joachim wrote: Not only has it only been on Nvidia chipsets but we have only seen reports on the Nvidia CK804 SATA controller. People have reported problems with other controllers. I have one here I can test given a day or so. I don't think it's SATA related, it just happens that it shows up well there, for networking you would end up with the odd corrupted packet probably and end up just dropping those so it might not be noticeable. - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Tue, Jan 16, 2007 at 09:31:31PM +0100, Krzysztof Halasa wrote: > Do you (someone) have (maintain) a list of affected systems, > including motherboard type and possibly version, BIOS version and > CPU type? A similar list of unaffected systems with 4GB+ RAM could > be useful, too. All I know is that some system hit this and some don't seem to. Why it's not clear. > I'm afraid with default iommu=soft it will be a mystery forever. Right, but given windows doesn't use the iommu at all and that a lot of newer hardware/drivers doesn't need it it might be the safest option since it clearly has been causing corruption for a number of people for well over a year now. - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote: > I agree,... it seems drastic, but this is the only really secure > solution. I'd like to here from Andi how he feels about this? It seems like a somewhat drastic solution in some ways given a lot of hardware doesn't seem to be affected (or maybe in those cases it's just really hard to hit, I don't know). > Well we can hope that Nvidia will find out more (though I'm not too > optimistic). Ideally someone from AMD needs to look into this, if some mainboards really never see this problem, then why is that? Is there errata that some BIOS/mainboard vendors are dealing with that others are not? > But we should not forget about the issue, just because SATA is not > longer affected. Right. - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote: > >If one use iommu=soft the sata_nv will continue to use the new code > >for the ADMA, right? > > Right, that shouldn't affect it. right now i'm thinking if we can't figure out which cpu/bios combinations are safe we might almost be better off doing iommu=soft for *all* k8 stuff except for those that are whitelisted; though this seems extremely drastic it's not clear if this only affect nvidia based chipsets, the nature of the corruption makes me think it's not an iommu software bug (we see a few bytes not entire pages corrupted, it's not even clear if it's entire cachelines trashed) --- perhaps other vendors have more recent bios errata or maybe it's just that nvidia has sold a lot of these so they are more visible? (i'm assuming at this point it might be some kind of cpu errata that some bioses deal with because some mainboards don't ever seem to see this whilst others do) in some ways the problem is worse with recent kernels --- because the ethernet and sata can address over 4GB and don't use the iommu anymore the problem is going to be *much* harder to hit, but still here lurking to cause problems for people. with ethernet you'll probably end up getting the odd trashed tcp frame and dropping it, so those will go mostly unnoticed, so this is why sata seems to be the easier way to show it - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote: If one use iommu=soft the sata_nv will continue to use the new code for the ADMA, right? Right, that shouldn't affect it. right now i'm thinking if we can't figure out which cpu/bios combinations are safe we might almost be better off doing iommu=soft for *all* k8 stuff except for those that are whitelisted; though this seems extremely drastic it's not clear if this only affect nvidia based chipsets, the nature of the corruption makes me think it's not an iommu software bug (we see a few bytes not entire pages corrupted, it's not even clear if it's entire cachelines trashed) --- perhaps other vendors have more recent bios errata or maybe it's just that nvidia has sold a lot of these so they are more visible? (i'm assuming at this point it might be some kind of cpu errata that some bioses deal with because some mainboards don't ever seem to see this whilst others do) in some ways the problem is worse with recent kernels --- because the ethernet and sata can address over 4GB and don't use the iommu anymore the problem is going to be *much* harder to hit, but still here lurking to cause problems for people. with ethernet you'll probably end up getting the odd trashed tcp frame and dropping it, so those will go mostly unnoticed, so this is why sata seems to be the easier way to show it - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote: I agree,... it seems drastic, but this is the only really secure solution. I'd like to here from Andi how he feels about this? It seems like a somewhat drastic solution in some ways given a lot of hardware doesn't seem to be affected (or maybe in those cases it's just really hard to hit, I don't know). Well we can hope that Nvidia will find out more (though I'm not too optimistic). Ideally someone from AMD needs to look into this, if some mainboards really never see this problem, then why is that? Is there errata that some BIOS/mainboard vendors are dealing with that others are not? But we should not forget about the issue, just because SATA is not longer affected. Right. - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Tue, Jan 16, 2007 at 09:31:31PM +0100, Krzysztof Halasa wrote: Do you (someone) have (maintain) a list of affected systems, including motherboard type and possibly version, BIOS version and CPU type? A similar list of unaffected systems with 4GB+ RAM could be useful, too. All I know is that some system hit this and some don't seem to. Why it's not clear. I'm afraid with default iommu=soft it will be a mystery forever. Right, but given windows doesn't use the iommu at all and that a lot of newer hardware/drivers doesn't need it it might be the safest option since it clearly has been causing corruption for a number of people for well over a year now. - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: > Please don't use that name, it strikes me as much more confusing > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite > convey what it means, either. Calling internal symbols _INTERNAL is confusing? > EXPORT_SYMBOL_RESTRICTED? EXPORT_SYMBOL_DERIVED? At least > something which is not internally inconsistent would be good (how is > something which is exported "internal?") But those symbols aren't, they're about internal interfaces that might change. > And, as long as EXPORT_SYMBOL_GPL continues to check that the module > using it has a GPL license, then it really -is- exactly descriptive > of what it's doing and probably shouldn't be changed. IIMHO. Well, if EXPORT_SYMBOL_GPL / EXPORT_SYMBOL_INTERNAL is about documenting things, why restrict who can use them based on the license? Surely the licence is more about tainting the kernel and debugging not politics? Do we even need to check the license at all in that case? Maybe a better idea would be to embed where the source code is located and use the non-existence of that for a tainting? - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, Dec 14, 2006 at 05:38:27PM +, Christoph Hellwig wrote: > Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. A quick grep shows that changing this now would require updating nearly 1900 instances, so patches to do this would be pretty large and disruptive (though we could support both during a transition and migrate them over time). - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote: > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if > done properly (and I think we use it fairly well). > > I think we _can_ do things where we give clear hints to people that > "we think this is such an internal Linux thing that you simply > cannot use this without being considered a derived work". Then why not change the name to something more along those lines? - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Wed, Dec 13, 2006 at 09:11:29PM +0100, Christoph Anton Mitterer wrote: > - error in the Opteron (memory controller) > - error in the Nvidia chipsets > - error in the kernel My guess without further information would be that some, but not all BIOSes are doing some work to avoid this. Does anyone have an amd64 with an nforce4 chipset and >4GB that does NOT have this problem? If so it might be worth chasing the BIOS vendors to see what errata they are dealing with. - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Wed, Dec 13, 2006 at 09:11:29PM +0100, Christoph Anton Mitterer wrote: - error in the Opteron (memory controller) - error in the Nvidia chipsets - error in the kernel My guess without further information would be that some, but not all BIOSes are doing some work to avoid this. Does anyone have an amd64 with an nforce4 chipset and 4GB that does NOT have this problem? If so it might be worth chasing the BIOS vendors to see what errata they are dealing with. - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote: I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if done properly (and I think we use it fairly well). I think we _can_ do things where we give clear hints to people that we think this is such an internal Linux thing that you simply cannot use this without being considered a derived work. Then why not change the name to something more along those lines? - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, Dec 14, 2006 at 05:38:27PM +, Christoph Hellwig wrote: Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. A quick grep shows that changing this now would require updating nearly 1900 instances, so patches to do this would be pretty large and disruptive (though we could support both during a transition and migrate them over time). - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: Please don't use that name, it strikes me as much more confusing than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite convey what it means, either. Calling internal symbols _INTERNAL is confusing? EXPORT_SYMBOL_RESTRICTED? EXPORT_SYMBOL_DERIVED? At least something which is not internally inconsistent would be good (how is something which is exported internal?) But those symbols aren't, they're about internal interfaces that might change. And, as long as EXPORT_SYMBOL_GPL continues to check that the module using it has a GPL license, then it really -is- exactly descriptive of what it's doing and probably shouldn't be changed. IIMHO. Well, if EXPORT_SYMBOL_GPL / EXPORT_SYMBOL_INTERNAL is about documenting things, why restrict who can use them based on the license? Surely the licence is more about tainting the kernel and debugging not politics? Do we even need to check the license at all in that case? Maybe a better idea would be to embed where the source code is located and use the non-existence of that for a tainting? - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Wed, Dec 13, 2006 at 08:18:21PM +0100, Christoph Anton Mitterer wrote: > booting with iommu=soft => works fine > booting with iommu=noagp => DOESN'T solve the error > booting with iommu=off => the system doesn't even boot and panics > When I set IOMMU to disabled in the BIOS the error is not solved- > I tried to set bigger space for the IOMMU in the BIOS (256MB instead of > 64MB),.. but it does not solve the problem. > Any ideas why iommu=disabled in the bios does not solve the issue? The kernel will still use the IOMMU if the BIOS doesn't set it up if it can, check your dmesg for IOMMU strings, there might be something printed to this effect. > 1) And does this now mean that there's an error in the hardware > (chipset or CPU/memcontroller)? My guess is it's a kernel bug, I don't know for certain. Perhaps we shaould start making a more comprehensive list of affected kernels & CPUs? - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Wed, Dec 13, 2006 at 08:20:59PM +0100, Christoph Anton Mitterer wrote: > Did anyone made any test under Windows? I cannot set there > iommu=soft, can I? Windows never uses the hardware iommu, so it's always doing the equivalent on iommu=soft - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Wed, Dec 13, 2006 at 08:20:59PM +0100, Christoph Anton Mitterer wrote: Did anyone made any test under Windows? I cannot set there iommu=soft, can I? Windows never uses the hardware iommu, so it's always doing the equivalent on iommu=soft - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Wed, Dec 13, 2006 at 08:18:21PM +0100, Christoph Anton Mitterer wrote: booting with iommu=soft = works fine booting with iommu=noagp = DOESN'T solve the error booting with iommu=off = the system doesn't even boot and panics When I set IOMMU to disabled in the BIOS the error is not solved- I tried to set bigger space for the IOMMU in the BIOS (256MB instead of 64MB),.. but it does not solve the problem. Any ideas why iommu=disabled in the bios does not solve the issue? The kernel will still use the IOMMU if the BIOS doesn't set it up if it can, check your dmesg for IOMMU strings, there might be something printed to this effect. 1) And does this now mean that there's an error in the hardware (chipset or CPU/memcontroller)? My guess is it's a kernel bug, I don't know for certain. Perhaps we shaould start making a more comprehensive list of affected kernels CPUs? - 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/
amd64 iommu causing corruption? (was Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!)
On Mon, Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote: > We could not reproduce the data corruption anymore if we boot the > machines with the kernel parameter "iommu=soft" i.e. if we use > software bounce buffering instead of the hw-iommu. (As mentioned > before, booting with mem=2g works fine, too, because this disables > the iommu altogether.) I can confirm this also seems to be the case for me, I'm still doing more testing to confirm this. But it would seem: nforce4, transfer of a large mount of data with 4GB+ of RAM I get some corruption. This is present on both the nv SATA and also Sil 3112 connected drives. Using iommu=soft so far seems to be working without any corruption. I still need to do more testing on other machines which have less memory (so the IOMMU won't be in use there either) and see if there are problems there. - 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/
amd64 iommu causing corruption? (was Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!)
On Mon, Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote: We could not reproduce the data corruption anymore if we boot the machines with the kernel parameter iommu=soft i.e. if we use software bounce buffering instead of the hw-iommu. (As mentioned before, booting with mem=2g works fine, too, because this disables the iommu altogether.) I can confirm this also seems to be the case for me, I'm still doing more testing to confirm this. But it would seem: nforce4, transfer of a large mount of data with 4GB+ of RAM I get some corruption. This is present on both the nv SATA and also Sil 3112 connected drives. Using iommu=soft so far seems to be working without any corruption. I still need to do more testing on other machines which have less memory (so the IOMMU won't be in use there either) and see if there are problems there. - 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: data corruption with nvidia chipsets and IDE/SATA drives
On Wed, Dec 06, 2006 at 12:11:38PM +0100, Christian wrote: > I copied a massive amount of data (more than 500GB) several times > between the HDDs and ran md5sum each time, but it found no errors. It might be a known problem that your BIOS addresses already, or maybe it's restricted to some revisions of the chip(s)? - 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: data corruption with nvidia chipsets and IDE/SATA drives
On Wed, Dec 06, 2006 at 12:11:38PM +0100, Christian wrote: I copied a massive amount of data (more than 500GB) several times between the HDDs and ran md5sum each time, but it found no errors. It might be a known problem that your BIOS addresses already, or maybe it's restricted to some revisions of the chip(s)? - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Sat, Dec 02, 2006 at 01:56:06AM +0100, Christoph Anton Mitterer wrote: > I found a severe bug mainly by fortune because it occurs very > rarely. My test looks like the following: I have about 30GB of > testing data on my harddisk,... I repeat verifying sha512 sums on > these files and check if errors occur. Heh, I see this also with an Tyan S2866 (nforce4 chipset). I've been aware something is a miss for a while because if I transfer about 40GB of data from one machine to another there are checksum mismatches and some files have to be transfered again. I've kept quite about it so far because it's not been clear what the cause is and because i can mostly ignore it now that I checksum all my data and check after xfer that it's sane (so I have 2+ copies of all this stuff everywhere). > One test pass verifies the 30GB 50 times,... about one to four > differences are found in each pass. Sounds about the same occurance rate I see, 30-40GB xfer, one or two pages (4K) are wrong. > The corrupted data is not one single completely wrong block of data > or so,.. but if you look at the area of the file where differences > are found,.. than some bytes are ok,.. some are wrong,.. and so on > (seems to be randomly). For me it seems that a single block in the file would be bad and the rest OK --- we I'm talking about 2 random blocks in 30BG or so. - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Sat, Dec 02, 2006 at 01:56:06AM +0100, Christoph Anton Mitterer wrote: I found a severe bug mainly by fortune because it occurs very rarely. My test looks like the following: I have about 30GB of testing data on my harddisk,... I repeat verifying sha512 sums on these files and check if errors occur. Heh, I see this also with an Tyan S2866 (nforce4 chipset). I've been aware something is a miss for a while because if I transfer about 40GB of data from one machine to another there are checksum mismatches and some files have to be transfered again. I've kept quite about it so far because it's not been clear what the cause is and because i can mostly ignore it now that I checksum all my data and check after xfer that it's sane (so I have 2+ copies of all this stuff everywhere). One test pass verifies the 30GB 50 times,... about one to four differences are found in each pass. Sounds about the same occurance rate I see, 30-40GB xfer, one or two pages (4K) are wrong. The corrupted data is not one single completely wrong block of data or so,.. but if you look at the area of the file where differences are found,.. than some bytes are ok,.. some are wrong,.. and so on (seems to be randomly). For me it seems that a single block in the file would be bad and the rest OK --- we I'm talking about 2 random blocks in 30BG or so. - 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: RFC: i386: kill !4KSTACKS
On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote: > 4Kb kernel stacks are the future on i386, and it seems the problems > it initially caused are now sorted out. Not entirely. XFS when mixed with raid/lvm/nfs still blows up. It's probably not alone in this respect but worse than ext2/3. - 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: RFC: i386: kill !4KSTACKS
On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote: 4Kb kernel stacks are the future on i386, and it seems the problems it initially caused are now sorted out. Not entirely. XFS when mixed with raid/lvm/nfs still blows up. It's probably not alone in this respect but worse than ext2/3. - 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/
