Re: [patch] Mark rdtsc as sync only for netburst, not for core2
Arjan van de Ven wrote: Zhang, Yanmin wrote: If it's a single processor, the go backwards issue doesn't exist. Below is my patch based on Arjan's. It's against 2.6.19-rc5-mm2. Hi, this patch is incorrect --- linux-2.6.19-rc5-mm2_arjan/arch/x86_64/kernel/setup.c 2006-11-29 10:41:21.0 +0800 +++ linux-2.6.19-rc5-mm2_arjan_fix/arch/x86_64/kernel/setup.c 2006-11-29 10:42:28.0 +0800 @@ -861,7 +861,7 @@ static void __cpuinit init_intel(struct set_bit(X86_FEATURE_CONSTANT_TSC, &c->x86_capability); if (c->x86 == 6) set_bit(X86_FEATURE_REP_GOOD, &c->x86_capability); -if (c->x86 == 15) +if (c->x86 == 15 && num_possible_cpus() != 1) set_bit(X86_FEATURE_SYNC_RDTSC, &c->x86_capability); first of all, you probably meant "|| num_possible_cpus() == 1" but second of all, the core2 cpus are dual core so.. .what does it bring you at all? I guess you could boot with a UP kernel or maxcpus=1? -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] char: drivers use/need PCI
Randy Dunlap wrote: > From: Randy Dunlap <[EMAIL PROTECTED]> > > With CONFIG_PCI=n: > drivers/char/mxser_new.c: In function 'mxser_release_res': > drivers/char/mxser_new.c:2383: warning: implicit declaration of function > 'pci_release_region' > drivers/char/mxser_new.c: In function 'mxser_probe': > drivers/char/mxser_new.c:2578: warning: implicit declaration of function > 'pci_request_region' > drivers/built-in.o: In function `sx_remove_card': > sx.c:(.text.sx_remove_card+0x65): undefined reference to `pci_release_region' > drivers/char/isicom.c: In function 'isicom_probe': > drivers/char/isicom.c:1793: warning: implicit declaration of function > 'pci_request_region' > drivers/char/isicom.c:1827: warning: implicit declaration of function > 'pci_release_region' > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> > --- > drivers/char/Kconfig |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > --- linux-2.6.19-rc6-mm2.orig/drivers/char/Kconfig > +++ linux-2.6.19-rc6-mm2/drivers/char/Kconfig > @@ -203,7 +203,7 @@ config MOXA_SMARTIO > > config MOXA_SMARTIO_NEW > tristate "Moxa SmartIO support v. 2.0 (EXPERIMENTAL)" > - depends on SERIAL_NONSTANDARD > + depends on SERIAL_NONSTANDARD && PCI > help > Say Y here if you have a Moxa SmartIO multiport serial card and/or > want to help develop a new version of this driver. > @@ -218,7 +218,7 @@ config MOXA_SMARTIO_NEW > > config ISI > tristate "Multi-Tech multiport card support (EXPERIMENTAL)" > - depends on SERIAL_NONSTANDARD > + depends on SERIAL_NONSTANDARD && PCI > select FW_LOADER > help > This is a driver for the Multi-Tech cards which provide several > @@ -312,7 +312,7 @@ config SPECIALIX_RTSCTS > > config SX > tristate "Specialix SX (and SI) card support" > - depends on SERIAL_NONSTANDARD > + depends on SERIAL_NONSTANDARD && PCI > help > This is a driver for the SX and SI multiport serial cards. > Please read the file for details. Nack. I have to correct the mxser and sx code. Thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: A commit between 2.6.16.4 and 2.6.16.5 failed crashme
On 11/28/06, Andi Kleen <[EMAIL PROTECTED]> wrote: > I first need to contact the author of test case if we could send the > test case to open source. The test case is called "crashme", Is that the classical crashme as found in LTP or an enhanced one? Do you run it in a special way? Is the crash reproducible? We normally run crashme regularly as part of LTP, Cerberus etc. so at least any obvious bugs should in theory be caught. Let me change the subject of this thread. I just read our private version of crashme. It's based on crashme version 2.4 and add some logging capability, no other enhancement. So it should be the same as crashme in LTP. It is solidly reproducible within 3 minutes of running crashme. The current status is: we know it's a commit between 2.6.16.4 and 2.6.16.5 that introduce this bug. Our network is very slow(only 5-6K/second). So we'll start the git-bisect tomorrow after finishing downloading the 2.6.16 stable git tree. Thanks, Forrest - 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 patch] fs/sysv/: remove obsolete documents
This patch removes two different changelog files from fs/sysv/ and moves the INTRO file to Documentation/filesystems/sysv-fs-intro.txt Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- Documentation/filesystems/00-INDEX |2 Documentation/filesystems/sysv-fs-intro.txt | 182 fs/sysv/CHANGES | 60 -- fs/sysv/ChangeLog | 106 --- fs/sysv/INTRO | 182 5 files changed, 2 insertions(+), 530 deletions(-) --- linux-2.6.19-rc6-mm2/fs/sysv/CHANGES2006-09-20 05:42:06.0 +0200 +++ /dev/null 2006-09-19 00:45:31.0 +0200 @@ -1,60 +0,0 @@ -Mon, 15 Dec 1997 Krzysztof G. Baranowski <[EMAIL PROTECTED]> - *namei.c: struct sysv_dir_inode_operations updated to use dentries. - -Fri, 23 Jan 1998 Krzysztof G. Baranowski <[EMAIL PROTECTED]> - *inode.c: corrected 1 track offset setting (in sb->sv_block_base). - Originally it was overridden (by setting to zero) - in detected_[xenix,sysv4,sysv2,coherent]. Thanks - to Andrzej Krzysztofowicz <[EMAIL PROTECTED]> - for identifying the problem. - -Tue, 27 Jan 1998 Krzysztof G. Baranowski <[EMAIL PROTECTED]> -*inode.c: added 2048-byte block support to SystemV FS. - Merged detected_bs[512,1024,2048]() into one function: - void detected_bs (u_char type, struct super_block *sb). - Thanks to Andrzej Krzysztofowicz <[EMAIL PROTECTED]> - for the patch. - -Wed, 4 Feb 1998 Krzysztof G. Baranowski <[EMAIL PROTECTED]> - *namei.c: removed static subdir(); is_subdir() from dcache.c - is used instead. Cosmetic changes. - -Thu, 3 Dec 1998 Al Viro ([EMAIL PROTECTED]) - *namei.c (sysv_rmdir): - Bugectomy: old check for victim being busy - (inode->i_count) wasn't replaced (with checking - dentry->d_count) and escaped Linus in the last round - of changes. Shot and buried. - -Wed, 9 Dec 1998 AV - *namei.c (do_sysv_rename): - Fixed incorrect check for other owners + race. - Removed checks that went to VFS. - *namei.c (sysv_unlink): - Removed checks that went to VFS. - -Thu, 10 Dec 1998 AV - *namei.c (do_mknod): - Removed dead code - mknod is never asked to - create a symlink or directory. Incidentially, - it wouldn't do it right if it would be called. - -Sat, 26 Dec 1998 KGB - *inode.c (detect_sysv4): - Added detection of expanded s_type field (0x10, - 0x20 and 0x30). Forced read-only access in this case. - -Sun, 21 Mar 1999 AV - *namei.c (sysv_link): - Fixed i_count usage that resulted in dcache corruption. - *inode.c: - Filled ->delete_inode() method with sysv_delete_inode(). - sysv_put_inode() is gone, as it tried to do ->delete_ - _inode()'s job. - *ialloc.c: (sysv_free_inode): - Fixed race. - -Sun, 30 Apr 1999 AV - *namei.c (sysv_mknod): - Removed dead code (S_IFREG case is now passed to - ->create() by VFS). --- linux-2.6.19-rc6-mm2/fs/sysv/ChangeLog 2006-09-20 05:42:06.0 +0200 +++ /dev/null 2006-09-19 00:45:31.0 +0200 @@ -1,106 +0,0 @@ -Thu Feb 14 2002 Andrew Morton <[EMAIL PROTECTED]> - - * dir_commit_chunk(): call writeout_one_page() as well as - waitfor_one_page() for IS_SYNC directories, so that we - actually do sync the directory. (forward-port from 2.4). - -Thu Feb 7 2002 Alexander Viro <[EMAIL PROTECTED]> - - * super.c: switched to ->get_sb() - * ChangeLog: fixed dates ;-) - -2002-01-24 David S. Miller - - * inode.c: Include linux/init.h - -Mon Jan 21 2002 Alexander Viro <[EMAIL PROTECTED]> - * ialloc.c (sysv_new_inode): zero SYSV_I(inode)->i_data out. - * i_vnode renamed to vfs_inode. Sorry, but let's keep that - consistent. - -Sat Jan 19 2002 Christoph Hellwig <[EMAIL PROTECTED]> - - * include/linux/sysv_fs.h (SYSV_I): Get fs-private inode data using - list_entry() instead of inode->u. - * include/linux/sysv_fs_i.h: Add 'struct inode i_vnode' field to - sysv_inode_info structure. - * inode.c: Include , implement alloc_inode/destroy_inode - sop methods, add infrastructure for per-fs inode slab cache. - * super.c (init_sysv_fs): Initialize inode cache, recover properly - in the case of failed register_fi
Re: [2.6 patch] fs/sysv/: remove obsolete documents
On Wed, Nov 29, 2006 at 09:20:19AM +0100, Adrian Bunk wrote: > This patch removes two different changelog files from fs/sysv/ and moves > the INTRO file to Documentation/filesystems/sysv-fs-intro.txt ACK on removing the changlogs. NACK on moving the INTO file. It should be merged into Documentation/filesystems/sysv-fs.txt, creating a single document instead. - 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: A commit between 2.6.16.4 and 2.6.16.5 failed crashme
On Wed, Nov 29, 2006 at 12:18:18AM -0800, Zhao Forrest wrote: > On 11/28/06, Andi Kleen <[EMAIL PROTECTED]> wrote: > > > >> I first need to contact the author of test case if we could send the > >> test case to open source. The test case is called "crashme", > > > >Is that the classical crashme as found in LTP or an enhanced one? > >Do you run it in a special way? Is the crash reproducible? > > > >We normally run crashme regularly as part of LTP, Cerberus etc. > >so at least any obvious bugs should in theory be caught. > > > > Let me change the subject of this thread. > I just read our private version of crashme. It's based on crashme > version 2.4 and add some logging capability, no other enhancement. So > it should be the same as crashme in LTP. > > It is solidly reproducible within 3 minutes of running crashme. > > The current status is: we know it's a commit between 2.6.16.4 and > 2.6.16.5 that introduce this bug. > > Our network is very slow(only 5-6K/second). So we'll start the > git-bisect tomorrow after finishing downloading the 2.6.16 stable git > tree. Thanks for your report. A git-bisect might be a bit of overkill considering that there were only two patches applied beween 2.6.16.4 and 2.6.16.5: Andi Kleen (2): x86_64: Clean up execve x86_64: When user could have changed RIP always force IRET (CVE-2006-0744) I've attached both patches. Could you manually bisect first applying "x86_64: Clean up execve" (patch-2.6.16.4-5-1) against 2.6.16.4? Then we'll know which of Andi's pacthes caused this bug. > Thanks, > Forrest cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed commit 59b2832a31ae2f3279bb5b16ae9b1c4e38e40dea Author: Andi Kleen <[EMAIL PROTECTED]> Date: Wed Apr 12 08:18:46 2006 +0200 [PATCH] x86_64: Clean up execve Just call IRET always, no need for any special cases. Needed for the next bug fix. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> diff --git a/arch/x86_64/kernel/entry.S b/arch/x86_64/kernel/entry.S index 7c10e90..25dcb77 100644 --- a/arch/x86_64/kernel/entry.S +++ b/arch/x86_64/kernel/entry.S @@ -408,25 +408,9 @@ ENTRY(stub_execve) CFI_ADJUST_CFA_OFFSET -8 CFI_REGISTER rip, r11 SAVE_REST - movq %r11, %r15 - CFI_REGISTER rip, r15 FIXUP_TOP_OF_STACK %r11 call sys_execve - GET_THREAD_INFO(%rcx) - bt $TIF_IA32,threadinfo_flags(%rcx) - CFI_REMEMBER_STATE - jc exec_32bit RESTORE_TOP_OF_STACK %r11 - movq %r15, %r11 - CFI_REGISTER rip, r11 - RESTORE_REST - pushq %r11 - CFI_ADJUST_CFA_OFFSET 8 - CFI_REL_OFFSET rip, 0 - ret - -exec_32bit: - CFI_RESTORE_STATE movq %rax,RAX(%rsp) RESTORE_REST jmp int_ret_from_sys_call commit 6b12095a4a0e1f21bbf83f95f13299ca99d758fe Author: Andi Kleen <[EMAIL PROTECTED]> Date: Wed Apr 12 08:19:29 2006 +0200 [PATCH] x86_64: When user could have changed RIP always force IRET (CVE-2006-0744) Intel EM64T CPUs handle uncanonical return addresses differently from AMD CPUs. The exception is reported in the SYSRET, not the next instruction. Thgis leads to the kernel exception handler running on the user stack with the wrong GS because the kernel didn't expect exceptions on this instruction. This version of the patch has the teething problems that plagued an earlier version fixed. This is CVE-2006-0744 Thanks to Ernie Petrides and Asit B. Mallick for analysis and initial patches. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> diff --git a/arch/x86_64/kernel/entry.S b/arch/x86_64/kernel/entry.S index 25dcb77..ab6e44d 100644 --- a/arch/x86_64/kernel/entry.S +++ b/arch/x86_64/kernel/entry.S @@ -180,6 +180,10 @@ rff_trace: * * XXX if we had a free scratch register we could save the RSP into the stack frame * and report it properly in ps. Unfortunately we haven't. + * + * When user can change the frames always force IRET. That is because + * it deals with uncanonical addresses better. SYSRET has trouble + * with them due to bugs in both AMD and Intel CPUs. */ ENTRY(system_call) @@ -254,7 +258,10 @@ sysret_signal: xorl %esi,%esi # oldset -> arg2 call ptregscall_common 1: movl $_TIF_NEED_RESCHED,%edi - jmp sysret_check + /* Use IRET because user could have changed frame. This + works because ptregscall_common has called FIXUP_TOP_OF_STACK. */ + cli + jmp int_with_check badsys: movq $-ENOSYS,RAX-ARGOFFSET(%rsp) @@ -280,7 +287,8 @@ tracesys:
Re: [patch] Mark rdtsc as sync only for netburst, not for core2
Zhang, Yanmin wrote: but second of all, the core2 cpus are dual core so.. .what does it bring you at all? When there is only one cpu (or UP), the go backwards issue doesn't exist, it does exist for single-socket dual core already. And core2 is dual core... so don't use cpuid here for UP. Another function init_amd already does so. not anymore.. that got fixed very recently... (but you are right; on AMD the speculation is even bigger so there even on single core you need cpuid) - 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/2] lib + ntfs: let modules force HWEIGHT
On Tue, Nov 28, 2006 at 02:08:40PM -0800, Randy Dunlap wrote: > From: Randy Dunlap <[EMAIL PROTECTED]> > > NTFS (=m) uses hweight32(), but that function is only linked > into the kernel image if it is used inside the kernel image, > not in loadable modules. Let modules force HWEIGHT to be > built into the kernel image. Otherwise build fails: > > Building modules, stage 2. > MODPOST 94 modules > WARNING: "hweight32" [fs/ntfs/ntfs.ko] undefined! > > Yes, I'd certainly prefer for this to be more automated rather than > forced by each module that needs it. Please just make it builtin-in always and remove it from lib-y. Bonus points for killing of the lib-y braindamage entirely. - 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 patch] fs/sysv/: doc cleanup
On Wed, Nov 29, 2006 at 08:25:36AM +, Christoph Hellwig wrote: > On Wed, Nov 29, 2006 at 09:20:19AM +0100, Adrian Bunk wrote: > > This patch removes two different changelog files from fs/sysv/ and moves > > the INTRO file to Documentation/filesystems/sysv-fs-intro.txt > > ACK on removing the changlogs. > NACK on moving the INTO file. It should be merged into > Documentation/filesystems/sysv-fs.txt, creating a single document instead. Updated patch below. cu Adrian <-- snip --> This patch removes two different changelog files from fs/sysv/ and merges the INTRO file into Documentation/filesystems/sysv-fs.txt Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- Documentation/filesystems/sysv-fs.txt | 177 - fs/sysv/CHANGES | 60 fs/sysv/ChangeLog | 106 --- fs/sysv/INTRO | 182 -- 4 files changed, 168 insertions(+), 357 deletions(-) --- linux-2.6.19-rc6-mm2/Documentation/filesystems/sysv-fs.txt.old 2006-11-29 09:34:23.0 +0100 +++ linux-2.6.19-rc6-mm2/Documentation/filesystems/sysv-fs.txt 2006-11-29 09:36:00.0 +0100 @@ -1,11 +1,8 @@ -This is the implementation of the SystemV/Coherent filesystem for Linux. It implements all of - Xenix FS, - SystemV/386 FS, - Coherent FS. -This is version beta 4. - To install: * Answer the 'System V and Coherent filesystem support' question with 'y' when configuring the kernel. @@ -28,11 +25,173 @@ for this FS on hard disk yet. -Please report any bugs and suggestions to - Bruno Haible <[EMAIL PROTECTED]> - Pascal Haible <[EMAIL PROTECTED]> - Krzysztof G. Baranowski <[EMAIL PROTECTED]> +These filesystems are rather similar. Here is a comparison with Minix FS: + +* Linux fdisk reports on partitions + - Minix FS 0x81 Linux/Minix + - Xenix FS ?? + - SystemV FS ?? + - Coherent FS 0x08 AIX bootable + +* Size of a block or zone (data allocation unit on disk) + - Minix FS 1024 + - Xenix FS 1024 (also 512 ??) + - SystemV FS 1024 (also 512 and 2048) + - Coherent FS 512 + +* General layout: all have one boot block, one super block and + separate areas for inodes and for directories/data. + On SystemV Release 2 FS (e.g. Microport) the first track is reserved and + all the block numbers (including the super block) are offset by one track. + +* Byte ordering of "short" (16 bit entities) on disk: + - Minix FS little endian 0 1 + - Xenix FS little endian 0 1 + - SystemV FS little endian 0 1 + - Coherent FS little endian 0 1 + Of course, this affects only the file system, not the data of files on it! + +* Byte ordering of "long" (32 bit entities) on disk: + - Minix FS little endian 0 1 2 3 + - Xenix FS little endian 0 1 2 3 + - SystemV FS little endian 0 1 2 3 + - Coherent FS PDP-11 2 3 0 1 + Of course, this affects only the file system, not the data of files on it! + +* Inode on disk: "short", 0 means non-existent, the root dir ino is: + - Minix FS1 + - Xenix FS, SystemV FS, Coherent FS 2 + +* Maximum number of hard links to a file: + - Minix FS 250 + - Xenix FS ?? + - SystemV FS ?? + - Coherent FS >=1 + +* Free inode management: + - Minix FS a bitmap + - Xenix FS, SystemV FS, Coherent FS + There is a cache of a certain number of free inodes in the super-block. + When it is exhausted, new free inodes are found using a linear search. + +* Free block management: + - Minix FS a bitmap + - Xenix FS, SystemV FS, Coherent FS + Free blocks are organized in a "free list". Maybe a misleading term, + since it is not true that every free block contains a pointer to + the next free block. Rather, the free blocks are organized in chunks + of limited size, and every now and then a free block contains pointers + to the free blocks pertaining to the next chunk; the first of these + contains pointers and so on. The list terminates with a "block number" + 0 on Xenix FS and SystemV FS, with a block zeroed out on Coherent FS. + +* Super-block location: + - Minix FS block 1 = bytes 1024..2047 + - Xenix FS block 1 = bytes 1024..2047 + - SystemV FS bytes 512..1023 + - Coherent FS block 1 = bytes 512..1023 + +* Super-block layout: + - Minix FS +unsigned short s_ninodes; +unsigned short s_nzones; +unsigned short s_imap_blocks; +unsigned short s_zmap_blocks; +unsigned short s_firstdatazone; +unsigned short s_log_zone_size; +unsigned long s_max_size; +unsigned short s_magic; + - Xenix FS, SystemV FS, Coherent FS +unsigned short s_firstdatazone; +unsigned long s_nzones;
Re: [stable] [PATCH 46/61] fix Intel RNG detection
>>> Dave Jones <[EMAIL PROTECTED]> 24.11.06 21:27 >>>
>On Wed, Nov 22, 2006 at 08:53:08AM +0100, Jan Beulich wrote:
> > >It does appear to work w/out the patch. I've asked for a small bit
> > >of diagnostics (below), perhaps you've got something you'd rather see?
> > >I expect this to be a 24C0 LPC Bridge.
> >
> > Yes, that's what I'd have asked for. If it works, I expect the device
> > code to be different, or both manufacturer and device code to be
> > invalid. Depending on the outcome, perhaps we'll need an override
> > option so that this test can be partially (i.e. just the device code
> > part) or entirely (all the FWH detection) skipped.
> > The base problem is the vague documentation of the whole
> > detection mechanism - a lot of this I had to read between the lines.
>
>The bug report I referenced came back with this from that debug patch..
>
>intel_rng: no version for "struct_module" found: kernel tainted.
>intel_rng: pci vendor:device 8086:24c0 fwh_dec_en1 80 bios_cntl_val 2 mfc cb
>dvc 88
>intel_rng: FWH not detected
Any chance you could have them test below patch (perhaps before I
actually submit it)? They should see the warning message added when
not using any options, and they should then be able to use the
no_fwh_detect option to get the thing to work again.
I'll meanwhile ask Intel about how they suppose to follow the RNG
detection sequence when the BIOS locks out write access to the
FWH interface.
Jan
Index: head-2006-11-21/drivers/char/hw_random/intel-rng.c
===
--- head-2006-11-21.orig/drivers/char/hw_random/intel-rng.c 2006-11-21
10:36:15.0 +0100
+++ head-2006-11-21/drivers/char/hw_random/intel-rng.c 2006-11-29
09:09:21.0 +0100
@@ -143,6 +143,8 @@ static const struct pci_device_id pci_tb
};
MODULE_DEVICE_TABLE(pci, pci_tbl);
+static __initdata int no_fwh_detect;
+module_param(no_fwh_detect, int, 0);
static inline u8 hwstatus_get(void __iomem *mem)
{
@@ -240,6 +242,11 @@ static int __init mod_init(void)
if (!dev)
goto out; /* Device not found. */
+ if (no_fwh_detect < 0) {
+ pci_dev_put(dev);
+ goto fwh_done;
+ }
+
/* Check for Intel 82802 */
if (dev->device < 0x2640) {
fwh_dec_en1_off = FWH_DEC_EN1_REG_OLD;
@@ -252,6 +259,23 @@ static int __init mod_init(void)
pci_read_config_byte(dev, fwh_dec_en1_off, &fwh_dec_en1_val);
pci_read_config_byte(dev, bios_cntl_off, &bios_cntl_val);
+ if ((bios_cntl_val &
+(BIOS_CNTL_LOCK_ENABLE_MASK|BIOS_CNTL_WRITE_ENABLE_MASK))
+ == BIOS_CNTL_LOCK_ENABLE_MASK) {
+ static __initdata /*const*/ char warning[] =
+ KERN_WARNING PFX "Firmware space is locked read-only.
If you can't or\n"
+ KERN_WARNING PFX "don't want to disable this in
firmware setup, and if\n"
+ KERN_WARNING PFX "you are certain that your system has
a functional\n"
+ KERN_WARNING PFX "RNG, try using the 'no_fwh_detect'
option.\n";
+
+ pci_dev_put(dev);
+ if (no_fwh_detect)
+ goto fwh_done;
+ printk(warning);
+ err = -EBUSY;
+ goto out;
+ }
+
mem = ioremap_nocache(INTEL_FWH_ADDR, INTEL_FWH_ADDR_LEN);
if (mem == NULL) {
pci_dev_put(dev);
@@ -280,8 +304,7 @@ static int __init mod_init(void)
pci_write_config_byte(dev,
fwh_dec_en1_off,
fwh_dec_en1_val | FWH_F8_EN_MASK);
- if (!(bios_cntl_val &
- (BIOS_CNTL_LOCK_ENABLE_MASK|BIOS_CNTL_WRITE_ENABLE_MASK)))
+ if (!(bios_cntl_val & BIOS_CNTL_WRITE_ENABLE_MASK))
pci_write_config_byte(dev,
bios_cntl_off,
bios_cntl_val |
BIOS_CNTL_WRITE_ENABLE_MASK);
@@ -315,6 +338,8 @@ static int __init mod_init(void)
goto out;
}
+fwh_done:
+
err = -ENOMEM;
mem = ioremap(INTEL_RNG_ADDR, INTEL_RNG_ADDR_LEN);
if (!mem)
-
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/
realtime-preempt and arm
Hi all,
I'm trying the realtime-preempt patch-2.6.18-rt6 on
lh7a400 arm system with little success. In a test
program I try 5 ms timeout with select() but get 20 ms
avg or 26 ms max. When the framebuffer scrolls, the
max delay goes up to 59 ms. With a vanilla kernel I
get 10 ms (because of tick resolution?), 11 ms and 39
ms.
My question is, is the realtime-preempt patch supposed
to work on arm architecture and/or without high
resolution timer (which lh7a40x seems to lack) at all
or should I just try to be more clever.
Relevant code:
prio.sched_priority = 99;
if (sched_setscheduler(0, SCHED_RR, &prio) < 0) ...
if (mlockall(MCL_CURRENT | MCL_FUTURE) < 0) ...
while (1) {
t = raw_timer();
tv.tv_usec = 5000;
tv.tv_sec = 0;
select(0, 0, 0, 0, &tv);
t = raw_timer() - t;
if (max_t < t) max_t = t;
if (min_t > t) min_t = t;
avg_t += t;
++n;
if (n < 100) continue;
printf("%i revs; min: %i max: %i avg: %i\n",
n,
min_t,
max_t,
(avg_t + n / 2) / n);
Relevant config: PREEMPT_RT, PREEMPT_SOFTIRQS,
PREEMPT_HARDIRQS
I didnt' enable HIGH_RES_TIMERS because lh7a40x seems
not to support it.
--
tike
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com
-
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] Mark rdtsc as sync only for netburst, not for core2
On Wed, 2006-11-29 at 19:05 +1100, Nick Piggin wrote: > Arjan van de Ven wrote: > > Zhang, Yanmin wrote: > > > >> If it's a single processor, the go backwards issue doesn't exist. > >> Below is > >> my patch based on Arjan's. It's against 2.6.19-rc5-mm2. > > > > Hi, > > > > this patch is incorrect > > > >> --- linux-2.6.19-rc5-mm2_arjan/arch/x86_64/kernel/setup.c > >> 2006-11-29 10:41:21.0 +0800 > >> +++ linux-2.6.19-rc5-mm2_arjan_fix/arch/x86_64/kernel/setup.c > >> 2006-11-29 10:42:28.0 +0800 > >> @@ -861,7 +861,7 @@ static void __cpuinit init_intel(struct > >> set_bit(X86_FEATURE_CONSTANT_TSC, &c->x86_capability); > >> if (c->x86 == 6) > >> set_bit(X86_FEATURE_REP_GOOD, &c->x86_capability); > >> -if (c->x86 == 15) > >> +if (c->x86 == 15 && num_possible_cpus() != 1) > >> set_bit(X86_FEATURE_SYNC_RDTSC, &c->x86_capability); > > > > > > first of all, you probably meant "|| num_possible_cpus() == 1" > > > > but second of all, the core2 cpus are dual core so.. .what does it bring > > you at all? > > I guess you could boot with a UP kernel or maxcpus=1? Yes, with the new patch. My reply email to Arjan was lost in LKML because my email client was crazy to set the email as HTML format. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away
On Wed, Nov 29, 2006 at 02:56:20PM +1100, Keith Owens wrote:
> Nicholas Miell (on Tue, 28 Nov 2006 19:08:25 -0800) wrote:
> >On Wed, 2006-11-29 at 13:22 +1100, Keith Owens wrote:
> >> Compiling 2.6.19-rc6 with gcc version 4.1.0 (SUSE Linux),
> >> wait_hpet_tick is optimized away to a never ending loop and the kernel
> >> hangs on boot in timer setup.
> >>
> >> 001a :
> >> 1a: 55 push %ebp
> >> 1b: 89 e5 mov%esp,%ebp
> >> 1d: eb fe jmp1d
> >>
> >> This is not a problem with gcc 3.3.5. Adding barrier() calls to
> >> wait_hpet_tick does not help, making the variables volatile does.
> >>
> >> Signed-off-by: Keith Owens
> >>
> >> ---
> >> arch/i386/kernel/time_hpet.c |2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> Index: linux-2.6/arch/i386/kernel/time_hpet.c
> >> ===
> >> --- linux-2.6.orig/arch/i386/kernel/time_hpet.c
> >> +++ linux-2.6/arch/i386/kernel/time_hpet.c
> >> @@ -51,7 +51,7 @@ static void hpet_writel(unsigned long d,
> >> */
> >> static void __devinit wait_hpet_tick(void)
> >> {
> >> - unsigned int start_cmp_val, end_cmp_val;
> >> + unsigned volatile int start_cmp_val, end_cmp_val;
> >>
> >>start_cmp_val = hpet_readl(HPET_T0_CMP);
> >>do {
> >
> >When you examine the inlined functions involved, this looks an awful lot
> >like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
> >
> >Perhaps SUSE should fix their gcc instead of working around compiler
> >problems in the kernel?
>
> Firstly, the fix for 22278 is included in gcc 4.1.0.
This actually sounds more like http://gcc.gnu.org/PR27236
And that one is broken in 4.1.0, fixed in 4.1.1.
Jakub
-
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.19-rc6-mm2
On Tue, 2006-11-28 at 14:30 -0800, Greg KH wrote:
> On Tue, Nov 28, 2006 at 12:35:43PM +0100, Mariusz Kozlowski wrote:
> > Hello,
> >
> > When CONFIG_MODULE_UNLOAD is not set then this happens:
> >
> > CC kernel/module.o
> > kernel/module.c:852: error: `initstate' undeclared here (not in a function)
> > kernel/module.c:852: error: initializer element is not constant
> > kernel/module.c:852: error: (near initialization for `modinfo_attrs[2]')
> > make[1]: *** [kernel/module.o] Error 1
> > make: *** [kernel] Error 2
> >
> > Reference to 'initstate' should stay under #ifdef CONFIG_MODULE_UNLOAD
> > as its definition I guess.
> >
> > Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
> >
> > --- linux-2.6.19-rc6-mm2-a/kernel/module.c 2006-11-28
> > 12:17:09.0 +0100
> > +++ linux-2.6.19-rc6-mm2-b/kernel/module.c 2006-11-28
> > 12:05:01.0 +0100
> > @@ -849,8 +849,8 @@ static inline void module_unload_init(st
> > static struct module_attribute *modinfo_attrs[] = {
> > &modinfo_version,
> > &modinfo_srcversion,
> > - &initstate,
> > #ifdef CONFIG_MODULE_UNLOAD
> > + &initstate,
> > &refcnt,
> > #endif
>
> Kay, is this correct? I think we still need this information exported
> to userspace, even if we can't unload modules, right?
Yes, instead we should move the attribute out of the ifdef, so
it will be there, even when modules can't be unloaded.
Thanks,
Kay
diff --git a/kernel/module.c b/kernel/module.c
index f016656..0648f5d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -811,9 +811,34 @@ static inline void module_unload_init(st
}
#endif /* CONFIG_MODULE_UNLOAD */
+static ssize_t show_initstate(struct module_attribute *mattr,
+ struct module *mod, char *buffer)
+{
+ const char *state = "unknown";
+
+ switch (mod->state) {
+ case MODULE_STATE_LIVE:
+ state = "live";
+ break;
+ case MODULE_STATE_COMING:
+ state = "coming";
+ break;
+ case MODULE_STATE_GOING:
+ state = "going";
+ break;
+ }
+ return sprintf(buffer, "%s\n", state);
+}
+
+static struct module_attribute initstate = {
+ .attr = { .name = "initstate", .mode = 0444, .owner = THIS_MODULE },
+ .show = show_initstate,
+};
+
static struct module_attribute *modinfo_attrs[] = {
&modinfo_version,
&modinfo_srcversion,
+ &initstate,
#ifdef CONFIG_MODULE_UNLOAD
&refcnt,
#endif
Re: [patch] Mark rdtsc as sync only for netburst, not for core2
On Wed, 2006-11-29 at 09:35 +0100, Arjan van de Ven wrote: > Zhang, Yanmin wrote: > >> but second of all, the core2 cpus are dual core so.. .what does it > >> bring you at all? > > > > When there is only one cpu (or UP), the go backwards issue doesn't exist, > > it does exist for single-socket dual core already. And core2 is dual > core... > > > so > > don't use cpuid here for UP. Another function init_amd already does so. > > > not anymore.. that got fixed very recently... Thanks. > (but you are right; on AMD the speculation is even bigger so there > even on single core you need cpuid) - 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: Help for kernel module programming
> Hi: > I am writing a kernel module for assging an ip address to an interface. > I have included linux/igmp.h but still whenever i use the function ...What function? > declared in igmp.h file, it says unresolved symbol for that function. ...What symbol? > I am new to this programming. > i use the following command to compile it: > gcc -c -D__KERNEL__ -DMODULE > -I/home/newkernelsource/linux-2.4.22/include hello.c Please read the files in Documentation/kbuild/. -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c (kernel 2.6.18.1)
On 29/11/06, David Chinner <[EMAIL PROTECTED]> wrote: On Tue, Nov 28, 2006 at 04:49:00PM +0100, Jesper Juhl wrote: > Hi, > > One of my NFS servers just gave me a nasty surprise that I think it is > relevant to tell you about: Thanks, Jesper. > Filesystem "dm-1": XFS internal error xfs_trans_cancel at line 1138 of > file fs/xfs/xfs_trans.c. Caller 0x8034b47e > > Call Trace: > [] show_trace+0xb2/0x380 > [] dump_stack+0x15/0x20 > [] xfs_error_report+0x3c/0x50 > [] xfs_trans_cancel+0x6e/0x130 > [] xfs_create+0x5ee/0x6a0 > [] xfs_vn_mknod+0x156/0x2e0 > [] xfs_vn_create+0xb/0x10 > [] vfs_create+0x8c/0xd0 > [] nfsd_create_v3+0x31a/0x560 > [] nfsd3_proc_create+0x148/0x170 > [] nfsd_dispatch+0xf9/0x1e0 > [] svc_process+0x437/0x6e0 > [] nfsd+0x1cd/0x360 > [] child_rip+0xa/0x12 > xfs_force_shutdown(dm-1,0x8) called from line 1139 of file > fs/xfs/xfs_trans.c. Return address = 0x80359daa We shut down the filesystem because we cancelled a dirty transaction. Once we start to dirty the incore objects, we can't roll back to an unchanged state if a subsequent fatal error occurs during the transaction and we have to abort it. So you are saying that there's nothing I can do to prevent this from happening in the future? If I understand historic occurrences of this correctly, there is a possibility that it can be triggered in ENOMEM situations. Was your machine running out of memoy when this occurred? Not really. I just checked my monitoring software and, at the time this happened, the box had ~5.9G RAM free (of 8G total) and no swap used (but 11G available). > Filesystem "dm-1": Corruption of in-memory data detected. Shutting > down filesystem: dm-1 > Please umount the filesystem, and rectify the problem(s) > nfsd: non-standard errno: 5 EIO gets returned in certain locations once the filesystem has been shutdown. Makes sense. > I unmounted the filesystem, ran xfs_repair which told me to try an > mount it first to replay the log, so I did, unmounted it again, ran > xfs_repair (which didn't find any problems) and finally mounted it and > everything is good - the filesystem seems intact. Yeah, the above error report typically is due to an in-memory problem, not an on disk issue. Good to know. > The server in question is running kernel 2.6.18.1 Can happen to XFS on any kernel version - got a report of this from someone running a 2.4 kernel a couple of weeks ago Ok. Thank you for your reply David. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The VFS cache is not freed when there is not enough free memory to allocate
On 11/29/06, Sonic Zhang <[EMAIL PROTECTED]> wrote: Forward to the mailing list. > On 11/27/06, Nick Piggin <[EMAIL PROTECTED]> wrote: >> I haven't actually written any nommu userspace code, but it is obvious >> that you must try to keep malloc to <= PAGE_SIZE (although order 2 and >> even 3 allocations seem to be reasonable, from process context)... Then >> you would use something a bit more advanced than a linear array to store >> data (a pagetable-like radix tree would be a nice, easy idea). >> > > But, even we split the 8M memory into 2048 x 4k blocks, we still face > this failure. The key problem is that available memory is small than > 2048 x 4k, while there are still a lot of VFS cache. The VFS cache can > be freed, but kernel allocation function ignores it. See the new test > application. Which kernel allocation function? If you can provide more details I'd like to get to the bottom of this. I posted it here, I think you missed it. So forwarded it to you. Because the anonymous memory allocation in mm/nommu.c is all allocated with GFP_KERNEL from process context, and in that case, the allocator should not fail but call into page reclaim which in turn will free VFS caches. > What's a better way to free the VFS cache in memory allocator? It should be freeing it for you, so I'm not quite sure what is going on. Can you send over the kernel messages you see when the allocation fails? I don't think so. The kernel doesn't attempt to free it. The log is included in the mail I forwarded to you. Also, do you happen to know of a reasonable toolchain + emulator setup that I could test the nommu kernel with? A project named skyeye. http://www.skyeye.org/index.shtml -Aubrey - 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] i386-pda UP optimization
On Wednesday 29 November 2006 00:12, Jeremy Fitzhardinge wrote: > Hi Eric, > > Could you try this patch out and see if it makes much performance > difference for you. You should apply this on top of the %fs patch I > posted earlier (and use the %fs patch as the baseline for your > comparisons). Hi Jeremy I will try this as soon as possible, thank you. However I have some remarks browsing your patch. > +#ifdef CONFIG_SMP > +#define LOAD_PDA_SEG(reg)\ > + movl $(__KERNEL_PDA), reg; \ > + movl reg, %fs > +#define CUR_CPU(reg) movl %fs:PDA_cpu, reg > +#else > +#define LOAD_PDA_SEG(reg) > +#define CUR_CPU(reg) movl boot_pda+PDA_cpu, reg if !CONFIG_SMP, why even dereferencing boot_pda+PDA_cpu to get 0 ? and as PER_CPU(cpu_gdt_descr, %ebx) in !CONFIG_SMP doesnt need the a value in ebx, you can just do : #define CUR_CPU(reg) /* nothing */ > --- a/include/asm-i386/pda.h Tue Nov 21 18:54:56 2006 -0800 > +++ b/include/asm-i386/pda.h Wed Nov 22 02:35:24 2006 -0800 > @@ -22,6 +22,16 @@ extern struct i386_pda *_cpu_pda[]; > My patch was better IMHO : we dont need to force asm () instructions to perform regular C variable reading/writing in !CONFIG_SMP case. Using plain C allows compiler to generate a better code. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The VFS cache is not freed when there is not enough free memory to allocate
Aubrey wrote: On 11/29/06, Sonic Zhang <[EMAIL PROTECTED]> wrote: Forward to the mailing list. > On 11/27/06, Nick Piggin <[EMAIL PROTECTED]> wrote: >> I haven't actually written any nommu userspace code, but it is obvious >> that you must try to keep malloc to <= PAGE_SIZE (although order 2 and >> even 3 allocations seem to be reasonable, from process context)... Then >> you would use something a bit more advanced than a linear array to store >> data (a pagetable-like radix tree would be a nice, easy idea). >> > > But, even we split the 8M memory into 2048 x 4k blocks, we still face > this failure. The key problem is that available memory is small than > 2048 x 4k, while there are still a lot of VFS cache. The VFS cache can > be freed, but kernel allocation function ignores it. See the new test > application. Which kernel allocation function? If you can provide more details I'd like to get to the bottom of this. I posted it here, I think you missed it. So forwarded it to you. That was the order-9 allocation failure. Which is not going to be solved properly by just dropping caches. But Sonic apparently saw failures with 4K allocations, where the caches weren't getting shrunk properly. This would be more interesting because it would indicate a real problem with the kernel. Also, do you happen to know of a reasonable toolchain + emulator setup that I could test the nommu kernel with? A project named skyeye. http://www.skyeye.org/index.shtml Thanks, I'll give that one a try. Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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: A commit between 2.6.16.4 and 2.6.16.5 failed crashme
On 11/29/06, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Wed, Nov 29, 2006 at 12:18:18AM -0800, Zhao Forrest wrote: > On 11/28/06, Andi Kleen <[EMAIL PROTECTED]> wrote: > > > >> I first need to contact the author of test case if we could send the > >> test case to open source. The test case is called "crashme", > > > >Is that the classical crashme as found in LTP or an enhanced one? > >Do you run it in a special way? Is the crash reproducible? > > > >We normally run crashme regularly as part of LTP, Cerberus etc. > >so at least any obvious bugs should in theory be caught. > > > > Let me change the subject of this thread. > I just read our private version of crashme. It's based on crashme > version 2.4 and add some logging capability, no other enhancement. So > it should be the same as crashme in LTP. > > It is solidly reproducible within 3 minutes of running crashme. > > The current status is: we know it's a commit between 2.6.16.4 and > 2.6.16.5 that introduce this bug. > > Our network is very slow(only 5-6K/second). So we'll start the > git-bisect tomorrow after finishing downloading the 2.6.16 stable git > tree. Thanks for your report. A git-bisect might be a bit of overkill considering that there were only two patches applied beween 2.6.16.4 and 2.6.16.5: Andi Kleen (2): x86_64: Clean up execve x86_64: When user could have changed RIP always force IRET (CVE-2006-0744) I've attached both patches. Could you manually bisect first applying "x86_64: Clean up execve" (patch-2.6.16.4-5-1) against 2.6.16.4? Hi Adrian It's the second patch(x86_64: When user could have changed RIP always force IRET (CVE-2006-0744)) that trigger this bug. We have run crashme on a IBM server with 2 Intel dual-core CPU, a SUN server with 2 AMD Opteron single-core CPU and a SUN server with 8 AMD Opteron dual-core CPU. Running crashme can trigger kernel panic on all platforms after the second patch is applied to 2.6.16.4. And when kernel panic happens, there's only "Kernel panic - not syncing: Attempted to kill init" on the screen. Please let me know if you need any further information. Thanks, Forrest - 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] genapic: default to physical mode on hotplug CPU kernels
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm - indeed. Then we can indeed do the patch below. Nice simplification!
forgot to convert a few more places - full patch below.
Ingo
->
From: Ingo Molnar <[EMAIL PROTECTED]>
Subject: [patch] genapic: default to physical mode on hotplug CPU kernels
default to physical mode on hotplug CPU kernels. Furher simplify and
clean up the APIC initialization code.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/i386/kernel/acpi/boot.c |2 +-
arch/i386/kernel/mpparse.c|2 +-
arch/x86_64/kernel/genapic.c | 20 +++-
arch/x86_64/kernel/mpparse.c |2 +-
include/asm-i386/genapic.h|4 ++--
include/asm-i386/mach-bigsmp/mach_apic.h |2 +-
include/asm-i386/mach-default/mach_apic.h |2 +-
include/asm-i386/mach-es7000/mach_apic.h |2 +-
include/asm-i386/mach-generic/mach_apic.h |2 +-
include/asm-i386/mach-numaq/mach_apic.h |2 +-
include/asm-i386/mach-summit/mach_apic.h |2 +-
include/asm-i386/mach-visws/mach_apic.h |2 +-
include/asm-x86_64/apic.h |2 +-
13 files changed, 16 insertions(+), 30 deletions(-)
Index: linux/arch/i386/kernel/acpi/boot.c
===
--- linux.orig/arch/i386/kernel/acpi/boot.c
+++ linux/arch/i386/kernel/acpi/boot.c
@@ -921,7 +921,7 @@ static void __init acpi_process_madt(voi
acpi_ioapic = 1;
smp_found_config = 1;
- clustered_apic_check();
+ setup_apic_routing();
}
}
if (error == -EINVAL) {
Index: linux/arch/i386/kernel/mpparse.c
===
--- linux.orig/arch/i386/kernel/mpparse.c
+++ linux/arch/i386/kernel/mpparse.c
@@ -479,7 +479,7 @@ static int __init smp_read_mpc(struct mp
}
++mpc_record;
}
- clustered_apic_check();
+ setup_apic_routing();
if (!num_processors)
printk(KERN_ERR "SMP mptable: no processors registered!\n");
return num_processors;
Index: linux/arch/x86_64/kernel/genapic.c
===
--- linux.orig/arch/x86_64/kernel/genapic.c
+++ linux/arch/x86_64/kernel/genapic.c
@@ -33,25 +33,11 @@ u8 x86_cpu_to_log_apicid[NR_CPUS] = { [0
struct genapic __read_mostly *genapic = &apic_flat;
/*
- * Check the APIC IDs in bios_cpu_apicid and choose the APIC mode.
+ * Choose the APIC routing mode:
*/
-void __init clustered_apic_check(void)
+void __init setup_apic_routing(void)
{
- unsigned int i, max_apic = 0;
- u8 id;
-
- /*
-* Determine the maximum APIC ID in use:
-*/
- for (i = 0; i < NR_CPUS; i++) {
- id = bios_cpu_apicid[i];
- if (id == BAD_APICID)
- continue;
- if (id > max_apic)
- max_apic = id;
- }
-
- if (max_apic < 8)
+ if (cpus_weight(cpu_possible_map) <= 8)
genapic = &apic_flat;
else
genapic = &apic_physflat;
Index: linux/arch/x86_64/kernel/mpparse.c
===
--- linux.orig/arch/x86_64/kernel/mpparse.c
+++ linux/arch/x86_64/kernel/mpparse.c
@@ -302,7 +302,7 @@ static int __init smp_read_mpc(struct mp
}
}
}
- clustered_apic_check();
+ setup_apic_routing();
if (!num_processors)
printk(KERN_ERR "MPTABLE: no processors registered!\n");
return num_processors;
Index: linux/include/asm-i386/genapic.h
===
--- linux.orig/include/asm-i386/genapic.h
+++ linux/include/asm-i386/genapic.h
@@ -36,7 +36,7 @@ struct genapic {
void (*init_apic_ldr)(void);
physid_mask_t (*ioapic_phys_id_map)(physid_mask_t map);
- void (*clustered_apic_check)(void);
+ void (*setup_apic_routing)(void);
int (*multi_timer_check)(int apic, int irq);
int (*apicid_to_node)(int logical_apicid);
int (*cpu_to_logical_apicid)(int cpu);
@@ -99,7 +99,7 @@ struct genapic {
APICFUNC(check_apicid_present) \
APICFUNC(init_apic_ldr) \
APICFUNC(ioapic_phys_id_map) \
- APICFUNC(clustered_apic_check) \
+ APICFUNC(setup_apic_routing) \
APICFUNC(multi_timer_check) \
APICFUNC(apicid_to_node) \
APICFUNC(cpu_to_logical_apicid) \
Index: linux/include/asm-i386/mach-bigsmp/mach_apic.h
===
--- linux.orig/include/asm-i386/mach-bigsmp/mach_apic.h
+++ linux/include/asm-i386/mach-bigsmp/mach_apic.h
@@ -71,7 +71,7 @@ s
Re: Boot failure with ext2 and initrds
Yet another attempt to get a response from Andrew. It is rather
important that you DO respond to this.
On Sat, Nov 25, 2006 at 02:59:16PM +, Russell King wrote:
> On Thu, Nov 16, 2006 at 12:34:48PM +, Russell King wrote:
> > On Wed, Nov 15, 2006 at 11:22:28PM -0800, Andrew Morton wrote:
> > > On Wed, 15 Nov 2006 22:55:43 -0800
> > > Mingming Cao <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > > > number of the range to search, not the lengh of the range. maxblocks
> > > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > > > _size_ of the range to search instead...
> > > >
> > > > Something like this: (this is not a patch)
> > > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > > > ext2_grpblk_t next;
> > > >
> > > >-next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > > >+next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1,
> > > > start);
> > > > if (next >= maxblocks)
> > > > return -1;
> > > > return next;
> > > >}
> > >
> > > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > > to scan at `offset'.
> >
> > Are you sure? That's not the way it's implemented in many architectures.
> > find_next_*_bit() has always taken "address, maximum offset, starting
> > offset"
> > and always has returned "next offset".
> >
> > Just look at arch/i386/lib/bitops.c:
> >
> > int find_next_zero_bit(const unsigned long *addr, int size, int offset)
> > {
> > unsigned long * p = ((unsigned long *) addr) + (offset >> 5);
> > int set = 0, bit = offset & 31, res;
> > ...
> > /*
> > * No zero yet, search remaining full bytes for a zero
> > */
> > res = find_first_zero_bit (p, size - 32 * (p - (unsigned long *)
> > addr));
> > return (offset + set + res);
> > }
> >
> > So for the case that "offset" is aligned to a "long" boundary, that gives
> > us:
> >
> > res = find_first_zero_bit(addr + (offset>>5),
> > size - 32 * (addr + (offset>>5) - addr));
> >
> > or:
> >
> > res = find_first_zero_bit(addr + (offset>>5), size - (offset & ~31));
> >
> > So, size _excludes_ offset.
> >
> > Now, considering the return value, "res" above will be relative to
> > "addr + (offset>>5)". However, we add "offset" on to that, so it's
> > relative to addr + (offset bits).
>
> Andrew,
>
> Please respond to the above. If what you say is correct then all
> architectures need their bitops fixing to fit ext2's requirements.
>
> --
> Russell King
> Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of:
> -
> 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/
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
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: Boot failure with ext2 and initrds
On Wed, 29 Nov 2006 07:40:00 + Russell King <[EMAIL PROTECTED]> wrote: > Yet another attempt to get a response from Andrew. It is rather > important that you DO respond to this. You can read the code as easily as I can? I'm not really sure what you're asking - I thought Mingming cleared things up. - 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.18 - AHCI detection pauses excessively
Berck E. Nash wrote:
Tejun Heo wrote:
Yeah, I did and forgot about this thread too. Sorry. This is on the
top of my to-do list now. I'm attaching the patch. TIA.
That didn't fix the problem, but did change the messages. I've attached
the entire log, including the weird errors on power-off from the same
device that gives problems on boot, which I suspect are related.
Hmm... this is difficult. The problem is that everything looks normal
until command is issued. My primary suspect still is ahci powering down
phy during initialization. Can you please test the attached patch again?
[--snip--]
Mounting root filesystem read-only...done.
Will now halt.
[ 9371.896444] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 9371.903036] ata2.00: (irq_stat 0x4001)
[ 9371.907228] ata2.00: cmd e0/00:00:00:00:00/00:00:00:00:00/00 tag 0 data 0 in
[ 9371.907229] res 51/04:00:01:01:80/00:00:00:00:00/a0 Emask 0x1
(device error)
[ 9371.931688] ata2.00: configured for UDMA/133
[ 9371.936073] ata2: EH complete
Weird, the drive is failing STANDBY IMMEDIATE.
[--snip--]
[ 9372.152310] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 9372.158882] ata2.00: (irq_stat 0x4001)
[ 9372.163079] ata2.00: cmd 94/00:00:00:00:00/00:00:00:00:00/00 tag 0 data 0 in
[ 9372.163080] res 51/04:00:01:01:80/00:00:00:00:00/a0 Emask 0x1
(device error)
[ 9372.187505] ata2.00: configured for UDMA/133
Then, a series of obsolete STANDBY failures. Who's issuing these
commands? It's not libata, libata uses STANDBY (0xe2). Is it some kind
of gentoo thing? Anyways, doesn't really matter although it's
surprising that the drive fails STANDBY IMMEDIATE.
Thanks.
--
tejun
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 8f75c60..6100cbc 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -612,9 +612,6 @@ static void ahci_power_down(void __iomem
static void ahci_init_port(void __iomem *port_mmio, u32 cap,
dma_addr_t cmd_slot_dma, dma_addr_t rx_fis_dma)
{
- /* power up */
- ahci_power_up(port_mmio, cap);
-
/* enable FIS reception */
ahci_start_fis_rx(port_mmio, cap, cmd_slot_dma, rx_fis_dma);
@@ -640,9 +637,6 @@ static int ahci_deinit_port(void __iomem
return rc;
}
- /* put device into slumber mode */
- ahci_power_down(port_mmio, cap);
-
return 0;
}
@@ -1321,7 +1315,9 @@ static int ahci_port_suspend(struct ata_
int rc;
rc = ahci_deinit_port(port_mmio, hpriv->cap, &emsg);
- if (rc) {
+ if (rc == 0)
+ ahci_power_down(port_mmio, hpriv->cap);
+ else {
ata_port_printk(ap, KERN_ERR, "%s (%d)\n", emsg, rc);
ahci_init_port(port_mmio, hpriv->cap,
pp->cmd_slot_dma, pp->rx_fis_dma);
@@ -1337,6 +1333,7 @@ static int ahci_port_resume(struct ata_p
void __iomem *mmio = ap->host->mmio_base;
void __iomem *port_mmio = ahci_port_base(mmio, ap->port_no);
+ ahci_power_up(port_mmio, hpriv->cap);
ahci_init_port(port_mmio, hpriv->cap, pp->cmd_slot_dma, pp->rx_fis_dma);
return 0;
@@ -1443,6 +1440,9 @@ static int ahci_port_start(struct ata_po
ap->private_data = pp;
+ /* power up port */
+ ahci_power_up(port_mmio, hpriv->cap);
+
/* initialize port */
ahci_init_port(port_mmio, hpriv->cap, pp->cmd_slot_dma, pp->rx_fis_dma);
Re: Boot failure with ext2 and initrds
On Wed, Nov 29, 2006 at 12:30:36AM -0800, Andrew Morton wrote: > On Wed, 29 Nov 2006 07:40:00 + > Russell King <[EMAIL PROTECTED]> wrote: > > > Yet another attempt to get a response from Andrew. It is rather > > important that you DO respond to this. > > You can read the code as easily as I can? Sigh. Please don't cut the relevant part of my _first_ email message where it can be clearly seen that I _have_ read the code and interpreted it _differently_ from you. > I'm not really sure what you're asking - I thought Mingming cleared > things up. Which message did this happen? What I'm looking for is confirmation of the semantics of find_next_zero_bit(), which is a fairly simple question to ask, and certainly does not justify this rather obtuse and difficult thread. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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: Boot failure with ext2 and initrds
On Wed, 29 Nov 2006 09:20:24 + Russell King <[EMAIL PROTECTED]> wrote: > What I'm looking for is confirmation of the semantics of > find_next_zero_bit() What are the existing semantics? I see no documentation in any of the architectures I've looked at. That's my point. >From a quick read of fs/ext2/balloc.c ext2_find_next_zero_bit(base, size, offset) appears to expect that base is the start of the memory buffer, size is the number of bits at *base and offset is the bit at which to start the search, relative to base. If a zero bit is found it will return the offset of that bit relative to base. It will return some number greater than `size' if no zero-bit was found. Whether that's how all the implementors interpreted it is anyone's guess. Presumably the architectures all do roughly the same thing. > Well likewise. It appears that nobody (and about 20 people have implemented these things) could be bothered getting off ass and documenting the pathetic thing. - 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] i386-pda UP optimization
Eric Dumazet wrote: > if !CONFIG_SMP, why even dereferencing boot_pda+PDA_cpu to get 0 ? > and as PER_CPU(cpu_gdt_descr, %ebx) in !CONFIG_SMP doesnt need the a value in > ebx, you can just do : > > #define CUR_CPU(reg) /* nothing */ > Yep. On the other hand, I think that's an incredibly rare path anyway, so it won't make any difference either way. >> --- a/include/asm-i386/pda.h Tue Nov 21 18:54:56 2006 -0800 >> +++ b/include/asm-i386/pda.h Wed Nov 22 02:35:24 2006 -0800 >> @@ -22,6 +22,16 @@ extern struct i386_pda *_cpu_pda[]; >> >> > > My patch was better IMHO : we dont need to force asm () instructions to > perform regular C variable reading/writing in !CONFIG_SMP case. > > Using plain C allows compiler to generate a better code. > Probably, but I'm interested in comparing apples with apples; how much do the actual segment prefixes make a difference? J - 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: [GFS2] Fix Kconfig wrt CRC32 [8/9]
Hi, On Tue, 2006-11-28 at 10:33 -0800, Randy Dunlap wrote: > Steven Whitehouse wrote: [bits snipped to cut down size of reply] > > You'll need the patch: > > http://www.kernel.org/git/?p=linux/kernel/git/steve/gfs2-2.6-nmw.git;a=commitdiff;h=4a28fda50d864ede7d2724723949407e0e4043b8 > > as well. I'm also slightly surprised that you managed to get the errors > > that you did, since most of those symbols appear to be networking > > related and the DLM depends on INET which is clearly not set since NET > > is not set. > > Thanks, I'll apply that patch also and test again. > > Part of the problem (IMO) is that kconfig s/w doesn't follow dependency > chains when applying "select"s. > Ah, light begins to dawn :-) Sorry for being a bit slow on the uptake... I think I see what the problem might be now. I've attached a patch as a possible solution, let me know if you agree. Its against my -nmw tree, so for the current upstream it would be the same except for not needing the "if DLM_SCTP" on the end of the select line, Steve. diff --git a/fs/dlm/Kconfig b/fs/dlm/Kconfig index b5654a2..a1d083d 100644 --- a/fs/dlm/Kconfig +++ b/fs/dlm/Kconfig @@ -1,5 +1,5 @@ menu "Distributed Lock Manager" - depends on EXPERIMENTAL && INET + depends on EXPERIMENTAL && NET && INET config DLM tristate "Distributed Lock Manager (DLM)" diff --git a/fs/gfs2/Kconfig b/fs/gfs2/Kconfig index c0791cb..6a2ffa2 100644 --- a/fs/gfs2/Kconfig +++ b/fs/gfs2/Kconfig @@ -34,7 +34,9 @@ config GFS2_FS_LOCKING_NOLOCK config GFS2_FS_LOCKING_DLM tristate "GFS2 DLM locking module" - depends on GFS2_FS + depends on GFS2_FS && NET && INET && (IPV6 || IPV6=n) + select IP_SCTP if DLM_SCTP + select CONFIGFS_FS select DLM help Multiple node locking module for GFS2
[2.6 patch] remove drivers/char/riscom8.c:baud_table[]
Commit c7bce3097c0f9bbed76ee6fd03742f2624031a45 removed all usages of
baud_table[] but not the array itself.
Spotted by the GNU C compiler.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.19-rc6-mm2/drivers/char/riscom8.c.old 2006-11-29
09:55:13.0 +0100
+++ linux-2.6.19-rc6-mm2/drivers/char/riscom8.c 2006-11-29 09:55:23.0
+0100
@@ -82,11 +82,6 @@
static struct riscom_board * IRQ_to_board[16];
static struct tty_driver *riscom_driver;
-static unsigned long baud_table[] = {
- 0, 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800,
- 9600, 19200, 38400, 57600, 76800, 0,
-};
-
static struct riscom_board rc_board[RC_NBOARD] = {
{
.base = RC_IOBASE1,
-
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 patch] fs/sysv/: proper prototypes for 2 functions
This patch adds proper prototypes for sysv_{init,destroy}_icache()
in sysv.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
fs/sysv/super.c |3 ---
fs/sysv/sysv.h |3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.19-rc6-mm2/fs/sysv/sysv.h.old 2006-11-29 09:21:02.0
+0100
+++ linux-2.6.19-rc6-mm2/fs/sysv/sysv.h 2006-11-29 09:21:52.0 +0100
@@ -143,6 +143,9 @@
extern int sysv_sync_file(struct file *, struct dentry *, int);
extern void sysv_set_inode(struct inode *, dev_t);
extern int sysv_getattr(struct vfsmount *, struct dentry *, struct kstat *);
+int sysv_init_icache(void);
+void sysv_destroy_icache(void);
+
/* dir.c */
extern struct sysv_dir_entry *sysv_find_entry(struct dentry *, struct page **);
--- linux-2.6.19-rc6-mm2/fs/sysv/super.c.old2006-11-29 09:21:55.0
+0100
+++ linux-2.6.19-rc6-mm2/fs/sysv/super.c2006-11-29 09:22:04.0
+0100
@@ -528,9 +528,6 @@
.fs_flags = FS_REQUIRES_DEV,
};
-extern int sysv_init_icache(void) __init;
-extern void sysv_destroy_icache(void);
-
static int __init init_sysv_fs(void)
{
int error;
-
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 patch] proper prototype for remove_inode_dquot_ref()
This patch adds a proer prototype for remove_inode_dquot_ref() in
include/linux/quotaops.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
fs/inode.c |3 ---
include/linux/quotaops.h |3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.19-rc6-mm2/include/linux/quotaops.h.old 2006-11-29
09:43:03.0 +0100
+++ linux-2.6.19-rc6-mm2/include/linux/quotaops.h 2006-11-29
09:43:21.0 +0100
@@ -37,6 +37,9 @@
extern int dquot_commit_info(struct super_block *sb, int type);
extern int dquot_mark_dquot_dirty(struct dquot *dquot);
+int remove_inode_dquot_ref(struct inode *inode, int type,
+ struct list_head *tofree_head);
+
extern int vfs_quota_on(struct super_block *sb, int type, int format_id, char
*path);
extern int vfs_quota_on_mount(struct super_block *sb, char *qf_name,
int format_id, int type);
--- linux-2.6.19-rc6-mm2/fs/inode.c.old 2006-11-29 09:43:40.0 +0100
+++ linux-2.6.19-rc6-mm2/fs/inode.c 2006-11-29 09:43:50.0 +0100
@@ -1249,9 +1249,6 @@
*/
#ifdef CONFIG_QUOTA
-/* Function back in dquot.c */
-int remove_inode_dquot_ref(struct inode *, int, struct list_head *);
-
void remove_dquot_ref(struct super_block *sb, int type,
struct list_head *tofree_head)
{
-
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/
[-mm patch] #if 0 fs/gfs2/acl.c:gfs2_check_acl()
On Tue, Nov 28, 2006 at 02:02:46AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc6-mm1:
>...
> git-gfs2-nmw.patch
>...
> git trees
>...
This patch #if 0's the no longer used gfs2_check_acl().
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
fs/gfs2/acl.c |2 ++
fs/gfs2/acl.h |1 -
2 files changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.19-rc6-mm2/fs/gfs2/acl.h.old 2006-11-29 08:49:13.0
+0100
+++ linux-2.6.19-rc6-mm2/fs/gfs2/acl.h 2006-11-29 08:49:22.0 +0100
@@ -32,7 +32,6 @@
int *remove, mode_t *mode);
int gfs2_acl_validate_remove(struct gfs2_inode *ip, int access);
int gfs2_check_acl_locked(struct inode *inode, int mask);
-int gfs2_check_acl(struct inode *inode, int mask);
int gfs2_acl_create(struct gfs2_inode *dip, struct gfs2_inode *ip);
int gfs2_acl_chmod(struct gfs2_inode *ip, struct iattr *attr);
--- linux-2.6.19-rc6-mm2/fs/gfs2/acl.c.old 2006-11-29 08:49:31.0
+0100
+++ linux-2.6.19-rc6-mm2/fs/gfs2/acl.c 2006-11-29 08:49:45.0 +0100
@@ -170,6 +170,7 @@
return -EAGAIN;
}
+#if 0
int gfs2_check_acl(struct inode *inode, int mask)
{
struct gfs2_inode *ip = GFS2_I(inode);
@@ -184,6 +185,7 @@
return error;
}
+#endif /* 0 */
static int munge_mode(struct gfs2_inode *ip, mode_t mode)
{
-
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 patch] arch/i386/kernel/reboot.c should #include
Every file should #include the headers containing the prototypes for its global functions. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.19-rc6-mm2/arch/i386/kernel/reboot.c.old 2006-11-29 10:06:47.0 +0100 +++ linux-2.6.19-rc6-mm2/arch/i386/kernel/reboot.c 2006-11-29 10:06:59.0 +0100 @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] fs/sysv/: proper prototypes for 2 functions
On Wed, Nov 29, 2006 at 11:04:05AM +0100, Adrian Bunk wrote:
> This patch adds proper prototypes for sysv_{init,destroy}_icache()
> in sysv.h
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> fs/sysv/super.c |3 ---
> fs/sysv/sysv.h |3 +++
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> --- linux-2.6.19-rc6-mm2/fs/sysv/sysv.h.old 2006-11-29 09:21:02.0
> +0100
> +++ linux-2.6.19-rc6-mm2/fs/sysv/sysv.h 2006-11-29 09:21:52.0
> +0100
> @@ -143,6 +143,9 @@
> extern int sysv_sync_file(struct file *, struct dentry *, int);
> extern void sysv_set_inode(struct inode *, dev_t);
> extern int sysv_getattr(struct vfsmount *, struct dentry *, struct kstat *);
> +int sysv_init_icache(void);
> +void sysv_destroy_icache(void);
Please follow the style used in the rest of the file and add the
extern keyword.
> +
And don't add a superflous blank line.
Except for that the patch is fine.
-
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/
[SOLVED] Re: [discuss] 2.6.19-rc5: known regressions (v2)
On Tue, 14 Nov 2006 17:44:51 +0100 Paolo Ornati <[EMAIL PROTECTED]> wrote: > > > Okay, please let us know if it survives the next several cycles. > > > > > > OTOH, the problem may be hiding. > > > > Ok, and if it survives againg and again I can do a partial bisection... > > "-rc5" is still alive: 6 days of uptime using suspend/resume many times > every day... > > so if the problem is there it's hiding very well. > > > Now I'll slowly go back with older kernels and see what happens... SHORT CONCLUSION: it was just a kernel miscompilation (I usually do "make oldconfig; make clean; make" so I don't know if I missed "make clean" or if it was caused by ccache...). The fact that it's a miscompilation is "proved" by 3 simple things: 1) I've only seen the problem with that particular version 2) slow bisection pointed that the ipotetic bug was fixed between 4b1c46a3..d1ed6a3e, but I don't see any change that matters (on x86_64). 3) I'm running a clean recompiled 2.6.19-rc4-g4b1c46a3, that doesn't have any problem. :D -- Paolo Ornati Linux 2.6.19-rc4-g4b1c46a3 on x86_64 - 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: [-mm patch] #if 0 fs/gfs2/acl.c:gfs2_check_acl()
Hi,
A better solution is just to remove it I think, so thats what I'll do in
my git tree. Thanks for pointing it out,
Steve.
On Wed, 2006-11-29 at 11:04 +0100, Adrian Bunk wrote:
> On Tue, Nov 28, 2006 at 02:02:46AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.19-rc6-mm1:
> >...
> > git-gfs2-nmw.patch
> >...
> > git trees
> >...
>
>
> This patch #if 0's the no longer used gfs2_check_acl().
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> fs/gfs2/acl.c |2 ++
> fs/gfs2/acl.h |1 -
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> --- linux-2.6.19-rc6-mm2/fs/gfs2/acl.h.old2006-11-29 08:49:13.0
> +0100
> +++ linux-2.6.19-rc6-mm2/fs/gfs2/acl.h2006-11-29 08:49:22.0
> +0100
> @@ -32,7 +32,6 @@
> int *remove, mode_t *mode);
> int gfs2_acl_validate_remove(struct gfs2_inode *ip, int access);
> int gfs2_check_acl_locked(struct inode *inode, int mask);
> -int gfs2_check_acl(struct inode *inode, int mask);
> int gfs2_acl_create(struct gfs2_inode *dip, struct gfs2_inode *ip);
> int gfs2_acl_chmod(struct gfs2_inode *ip, struct iattr *attr);
>
> --- linux-2.6.19-rc6-mm2/fs/gfs2/acl.c.old2006-11-29 08:49:31.0
> +0100
> +++ linux-2.6.19-rc6-mm2/fs/gfs2/acl.c2006-11-29 08:49:45.0
> +0100
> @@ -170,6 +170,7 @@
> return -EAGAIN;
> }
>
> +#if 0
> int gfs2_check_acl(struct inode *inode, int mask)
> {
> struct gfs2_inode *ip = GFS2_I(inode);
> @@ -184,6 +185,7 @@
>
> return error;
> }
> +#endif /* 0 */
>
> static int munge_mode(struct gfs2_inode *ip, mode_t mode)
> {
>
-
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] devices.txt - LANANA merge
Here's a merge with the latest from LANANA. Its been a while, so _please_ let me know if anyone sees unwanted changes. A few whitespaces and formatting changes included too. Thanks, Torben --- linux-2.6.19-rc6/Documentation/devices.txt 2006-11-16 05:03:40.0 +0100 +++ linux-2.6.19-rc6new/Documentation/devices.txt 2006-11-29 10:43:41.0 +0100 @@ -3,7 +3,7 @@ Maintained by Torben Mathiasen <[EMAIL PROTECTED]> - Last revised: 15 May 2006 + Last revised: 27 October 2006 This list is the Linux Device List, the official registry of allocated device numbers and /dev directory nodes for the Linux operating @@ -122,7 +122,7 @@ devices are on major 128 and above and use the PTY master multiplex (/dev/ptmx) to acquire a PTY on demand. - + 2 block Floppy disks 0 = /dev/fd0 Controller 0, drive 0, autodetect 1 = /dev/fd1 Controller 0, drive 1, autodetect @@ -257,7 +257,7 @@ 129 = /dev/vcsa1tty1 text/attribute contents ... 191 = /dev/vcsa63 tty63 text/attribute contents - + NOTE: These devices permit both read and write access. 7 block Loopback devices @@ -411,7 +411,7 @@ 207 = /dev/video/em8300_sp EM8300 DVD decoder subpicture 208 = /dev/compaq/cpqphpc Compaq PCI Hot Plug Controller 209 = /dev/compaq/cpqridCompaq Remote Insight Driver - 210 = /dev/impi/bt IMPI coprocessor block transfer + 210 = /dev/impi/bt IMPI coprocessor block transfer 211 = /dev/impi/smicIMPI coprocessor stream interface 212 = /dev/watchdogs/0 First watchdog device 213 = /dev/watchdogs/1 Second watchdog device @@ -582,7 +582,7 @@ This device is used on the ARM-based Acorn RiscPC. Partitions are handled the same way as for IDE disks - (see major number 3). + (see major number 3). 22 char Digiboard serial card 0 = /dev/ttyD0First Digiboard port @@ -591,7 +591,7 @@ 22 block Second IDE hard disk/CD-ROM interface 0 = /dev/hdc Master: whole disk (or CD-ROM) 64 = /dev/hdd Slave: whole disk (or CD-ROM) - + Partitions are handled the same way as for the first interface (see major number 3). @@ -801,7 +801,7 @@ 34 block Fourth IDE hard disk/CD-ROM interface 0 = /dev/hdg Master: whole disk (or CD-ROM) 64 = /dev/hdh Slave: whole disk (or CD-ROM) - + Partitions are handled the same way as for the first interface (see major number 3). @@ -939,7 +939,7 @@ 16 = /dev/ftlb FTL on second Memory Technology Device 32 = /dev/ftlc FTL on third Memory Technology Device ... - 240 = /dev/ftlp FTL on 16th Memory Technology Device + 240 = /dev/ftlp FTL on 16th Memory Technology Device Partitions are handled in the same way as for IDE disks (see major number 3) except that the partition @@ -1695,7 +1695,7 @@ 1 = /dev/ipnatNAT control device/log file 2 = /dev/ipstate State information log file 3 = /dev/ipauth Authentication control device/log file - ... + ... 96 char Parallel port ATAPI tape devices 0 = /dev/pt0 First parallel port ATAPI tape @@ -2427,7 +2427,7 @@ Partitions are handled in the same way as for IDE disks (see major number 3) except that the limit on - partitions is 31. + partitions is 31. 162 char Raw block device interface 0 = /dev/rawctl Raw I/O control device @@ -2543,9 +2543,6 @@ 64 = /dev/usb/rio500 Diamond Rio 500 65 = /dev/usb/usblcd USBLCD Interface ([EMAIL PROTECTED]) 66 = /dev/usb/cpad0Synaptics cPad (mouse/LCD) -67 = /dev/usb/adutux0 1st Ontrak ADU device - ... -76 = /dev/usb/adutux10 10th Ontrak ADU device 96 = /dev/usb/hiddev0 1st USB HID device ... 111 = /dev/usb/hiddev15 16th USB HID device @@ -2571,7 +2568,7 @@ 0 = /dev/uba First USB block device 8 = /dev/ubb Second USB block device 16 = /dev/ubc Third USB block device - ... +
[PATCH -mm 2/5][AIO] - fix aio.h includes
Fix the double inclusion of linux/uio.h in linux/aio.h aio.h |1 - 1 file changed, 1 deletion(-) Signed-off-by: Sébastien Dugué <[EMAIL PROTECTED]> Index: linux-2.6.19-rc6-mm2/include/linux/aio.h === --- linux-2.6.19-rc6-mm2.orig/include/linux/aio.h 2006-11-16 05:03:40.0 +0100 +++ linux-2.6.19-rc6-mm2/include/linux/aio.h 2006-11-28 12:51:41.0 +0100 @@ -7,7 +7,6 @@ #include #include -#include #define AIO_MAXSEGS4 #define AIO_KIOGRP_NR_ATOMIC 8 - 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 -mm 3/5][AIO] - export good_sigevent()
Export good_sigevent()
Move good_sigevent() from posix-timers.c to signal.c where it belongs,
and export it so that it can be used by other subsystems.
include/linux/signal.h |1 +
kernel/posix-timers.c | 17 -
kernel/signal.c| 23 +++
3 files changed, 24 insertions(+), 17 deletions(-)
Signed-off-by: Sébastien Dugué <[EMAIL PROTECTED]>
Index: linux-2.6.19-rc6-mm2/include/linux/signal.h
===
--- linux-2.6.19-rc6-mm2.orig/include/linux/signal.h2006-11-28
12:49:40.0 +0100 +++ linux-2.6.19-rc6-mm2/include/linux/signal.h
2006-11-28 12:51:43.0 +0100 @@ -240,6 +240,7 @@ extern int
sigprocmask(int, sigset_t *,
struct pt_regs;
extern int get_signal_to_deliver(siginfo_t *info, struct k_sigaction
*return_ka, struct pt_regs *regs, void *cookie); +extern struct task_struct *
good_sigevent(sigevent_t *);
extern struct kmem_cache *sighand_cachep;
Index: linux-2.6.19-rc6-mm2/kernel/posix-timers.c
===
--- linux-2.6.19-rc6-mm2.orig/kernel/posix-timers.c 2006-11-28
12:49:40.0 +0100 +++ linux-2.6.19-rc6-mm2/kernel/posix-timers.c
2006-11-28 12:51:43.0 +0100 @@ -367,23 +367,6 @@ static enum
hrtimer_restart posix_timer_ return ret;
}
-static struct task_struct * good_sigevent(sigevent_t * event)
-{
- struct task_struct *rtn = current->group_leader;
-
- if ((event->sigev_notify & SIGEV_THREAD_ID ) &&
- (!(rtn = find_task_by_pid(event->sigev_notify_thread_id)) ||
-rtn->tgid != current->tgid ||
-(event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_SIGNAL))
- return NULL;
-
- if (((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) &&
- ((event->sigev_signo <= 0) || (event->sigev_signo > SIGRTMAX)))
- return NULL;
-
- return rtn;
-}
-
void register_posix_clock(const clockid_t clock_id, struct k_clock *new_clock)
{
if ((unsigned) clock_id >= MAX_CLOCKS) {
Index: linux-2.6.19-rc6-mm2/kernel/signal.c
===
--- linux-2.6.19-rc6-mm2.orig/kernel/signal.c 2006-11-28
12:49:40.0 +0100 +++ linux-2.6.19-rc6-mm2/kernel/signal.c
2006-11-28 12:51:43.0 +0100 @@ -1189,6 +1189,29 @@ int
group_send_sig_info(int sig, struct return ret;
}
+/***
+ * good_sigevent - check and get target task from a sigevent.
+ * @event: the sigevent to be checked
+ *
+ * This function must be called with tasklist_lock held for reading.
+ */
+struct task_struct * good_sigevent(sigevent_t * event)
+{
+ struct task_struct *rtn = current->group_leader;
+
+ if ((event->sigev_notify & SIGEV_THREAD_ID ) &&
+ (!(rtn = find_task_by_pid(event->sigev_notify_thread_id)) ||
+rtn->tgid != current->tgid ||
+(event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_SIGNAL))
+ return NULL;
+
+ if (((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) &&
+ ((event->sigev_signo <= 0) || (event->sigev_signo > SIGRTMAX)))
+ return NULL;
+
+ return rtn;
+}
+
/*
* kill_pgrp_info() sends a signal to a process group: this is what the tty
* control characters do (^C, ^Z etc)
-
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 -mm 5/5][AIO] - Listio support
POSIX listio support
This patch adds POSIX listio completion notification support. It builds
on support provided by the aio signal notification patch and adds an
IOCB_CMD_GROUP command to io_submit().
The purpose of IOCB_CMD_GROUP is to group together the following requests in
the list up to the end of the list sumbitted to io_submit.
As io_submit already accepts an array of iocbs, as part of listio submission,
the user process prepends to a list of requests an empty special aiocb with
an aio_lio_opcode of IOCB_CMD_GROUP, filling only the aio_sigevent fields.
An IOCB_CMD_GROUP is added to the IOCB_CMD enum in include/linux/aio_abi.h
A struct lio_event is added in include/linux/aio.h
A struct lio_event *ki_lio is added to struct iocb in include/linux/aio.h
In io_submit(), upon detecting such an IOCB_CMD_GROUP marker iocb, an
lio_event is created in lio_create() which contains the necessary information
for signaling a thread (signal number, pid, notify type and value) along with
a count of requests attached to this event.
The following depicts the lio_event structure:
struct lio_event {
atomic_tlio_users;
struct aio_notify lio_notify;
};
lio_users holds an atomic counter of the number of requests attached to this
lio. It is incremented with each request submitted and decremented at each
request completion. When the counter reaches 0, we send the notification.
Each subsequent submitted request is attached to this lio_event by setting
the request kiocb->ki_lio to that lio_event (in io_submit_one()) and
incrementing the lio_users count.
In aio_complete(), if the request is attached to an lio (ki_lio <> 0),
then lio_check() is called to decrement the lio_users count and eventually
signal the user process when all the requests in the group have completed.
The IOCB_CMD_GROUP semantic is as follows:
- if the associated sigevent is NULL then we want to group
requests for the purpose of blocking on the group completion
(LIO_WAIT sync behavior).
- if the associated sigevent is valid (not NULL) then we want to
group requests for the purpose of being notified upon that
group of requests completion (LIO_NOWAIT async behaviour).
fs/aio.c| 123 ++--
fs/compat.c | 62 +++-
include/linux/aio.h | 15 +
include/linux/aio_abi.h |1
4 files changed, 192 insertions(+), 9 deletions(-)
Signed-off-by: Sébastien Dugué <[EMAIL PROTECTED]>
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Index: linux-2.6.19-rc6-mm2/fs/aio.c
===
--- linux-2.6.19-rc6-mm2.orig/fs/aio.c 2006-11-28 12:51:45.0
+0100 +++ linux-2.6.19-rc6-mm2/fs/aio.c 2006-11-28 12:51:48.0
+0100 @@ -414,6 +414,7 @@ static struct kiocb fastcall *__aio_get_
req->ki_cancel = NULL;
req->ki_retry = NULL;
req->ki_dtor = NULL;
+ req->ki_lio = NULL;
req->private = NULL;
req->ki_iovec = NULL;
req->ki_notify.sigq = NULL;
@@ -1009,6 +1010,53 @@ out_unlock:
return -EINVAL;
}
+void lio_check(struct lio_event *lio)
+{
+ int ret;
+
+ ret = atomic_dec_and_test(&lio->lio_users);
+
+ if (unlikely(ret) && lio->lio_notify.notify != SIGEV_NONE) {
+ /* last one -> notify process */
+ aio_send_signal(&lio->lio_notify);
+ kfree(lio);
+ }
+}
+
+struct lio_event *lio_create(struct sigevent __user *user_event)
+{
+ int ret = 0;
+ struct lio_event *lio = NULL;
+
+ lio = kzalloc(sizeof(*lio), GFP_KERNEL);
+
+ if (!lio)
+ return ERR_PTR(-EAGAIN);
+
+ /*
+* Grab an initial ref on the lio to avoid races between
+* submission and completion.
+*/
+ atomic_set(&lio->lio_users, 1);
+
+ lio->lio_notify.notify = SIGEV_NONE;
+
+ if (user_event) {
+ /*
+* User specified an event for this lio,
+* he wants to be notified upon lio completion.
+*/
+ ret = aio_setup_sigevent(&lio->lio_notify, user_event);
+
+ if (ret) {
+ kfree(lio);
+ return ERR_PTR(ret);
+ }
+ }
+
+ return lio;
+}
+
/* aio_complete
* Called when the io request on the given iocb is complete.
* Returns true if this is the last user of the request. The
@@ -1057,8 +1105,12 @@ int fastcall aio_complete(struct kiocb *
* when the event got cancelled.
*/
if (kiocbIsCancelled(iocb)) {
+ if (iocb->ki_lio)
+ lio_check(iocb->ki_lio);
+
if (iocb->ki_notify.sigq)
sigqueue_free(iocb->ki_notify.sigq);
+
[PATCH -mm 4/5][AIO] - AIO completion signal notification
AIO completion signal notification
The current 2.6 kernel does not support notification of user space via
an RT signal upon an asynchronous IO completion. The POSIX specification
states that when an AIO request completes, a signal can be delivered to
the application as notification.
This patch adds a struct sigevent *aio_sigeventp to the iocb.
The relevant fields (pid, signal number and value) are stored in the kiocb
for use when the request completes.
That sigevent structure is filled by the application as part of the AIO
request preparation. Upon request completion, the kernel notifies the
application using those sigevent parameters. If SIGEV_NONE has been specified,
then the old behaviour is retained and the application must rely on polling
the completion queue using io_getevents().
A struct sigevent *aio_sigeventp field is added to struct iocb in
include/linux/aio_abi.h
A struct aio_notify containing the sigevent parameters is defined in aio.h:
struct aio_notify {
struct task_struct *target;
__u16 signo;
__u16 notify;
sigval_tvalue;
};
A struct aio_notify ki_notify is added to struct kiocb in include/linux/aio.h
In io_submit_one(), if the application provided a sigevent then
setup_sigevent() is called which does the following:
- check access to the user sigevent and make a local copy
- if the requested notification is SIGEV_NONE, then nothing to do
- fill in the kiocb->ki_notify fields (notify, signo, value)
- check sigevent consistency, get the signal target task and
save it in kiocb->ki_notify.target
- preallocate a sigqueue for this event using sigqueue_alloc()
Upon request completion, in aio_complete(), if notification is needed for
this request (iocb->ki_notify.notify != SIGEV_NONE), then aio_send_signal()
is called to signal the target task as follows:
- fill in the siginfo struct to be sent to the task
- if notify is SIGEV_THREAD_ID then send signal to specific task
using send_sigqueue()
- else send signal to task group using send_5group_sigqueue()
Notes concerning sigqueue preallocation:
To ensure reliable delivery of completion notification, the sigqueue is
preallocated in the submission path so that there is no chance it can fail
in the completion path.
Unlike the posix-timers case (currently the single other user of sigqueue
preallocation), where the sigqueue is allocated for the lifetime of the timer
and freed at timer destruction time, the aio case is a bit more tricky due to
the async nature of the whole thing.
In the aio case, the sigqueue exists for the lifetime of the request,
therefore it must be freed only once the signal for the request completion has
been delivered. This involves changing __sigqueue_free() to free the sigqueue
when the signal is collected if si_code is SI_ASYNCIO even if it was
preallocated as well as explicitly calling sigqueue_free() in submission and
completion error paths.
fs/aio.c| 115 ++--
fs/compat.c | 18 +++
include/linux/aio.h | 12 +
include/linux/aio_abi.h |3 -
kernel/signal.c |2
5 files changed, 144 insertions(+), 6 deletions(-)
Signed-off-by: Sébastien Dugué <[EMAIL PROTECTED]>
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Index: linux-2.6.19-rc6-mm2/fs/aio.c
===
--- linux-2.6.19-rc6-mm2.orig/fs/aio.c 2006-11-28 12:49:40.0
+0100 +++ linux-2.6.19-rc6-mm2/fs/aio.c 2006-11-29 10:14:47.0
+0100 @@ -416,6 +416,7 @@ static struct kiocb fastcall *__aio_get_
req->ki_dtor = NULL;
req->private = NULL;
req->ki_iovec = NULL;
+ req->ki_notify.sigq = NULL;
INIT_LIST_HEAD(&req->ki_run_list);
/* Check if the completion queue has enough free space to
@@ -463,6 +464,11 @@ static inline void really_put_req(struct
req->ki_dtor(req);
if (req->ki_iovec != &req->ki_inline_vec)
kfree(req->ki_iovec);
+
+ /* Release task ref */
+ if (req->ki_notify.notify == (SIGEV_SIGNAL|SIGEV_THREAD_ID))
+ put_task_struct(req->ki_notify.target);
+
kmem_cache_free(kiocb_cachep, req);
ctx->reqs_active--;
@@ -929,6 +935,80 @@ void fastcall kick_iocb(struct kiocb *io
}
EXPORT_SYMBOL(kick_iocb);
+static int aio_send_signal(struct aio_notify *notify)
+{
+ struct sigqueue *sigq = notify->sigq;
+ struct siginfo *info = &sigq->info;
+ int ret;
+
+ memset(info, 0, sizeof(struct siginfo));
+
+ info->si_signo = notify->signo;
+ info->si_errno = 0;
+ info->si_code = SI_ASYNCIO;
+ info->si_pid = 0;
+ info->si_uid = 0;
+ info->si_value = notify->value;
+
+ if (notify->notify
[PATCH -mm 1/5][AIO] - Rework compat_sys_io_submit
compat_sys_io_submit() cleanup
Cleanup compat_sys_io_submit by duplicating some of the native syscall
logic in the compat layer and directly calling io_submit_one() instead
of fooling the syscall into thinking it is called from a native 64-bit
caller.
This is needed for the completion notification patch to avoid having
to rewrite each iocb on the caller stack for sys_io_submit() to find the
sigevents.
compat.c | 61 +++--
1 file changed, 35 insertions(+), 26 deletions(-)
Signed-off-by: Sébastien Dugué <[EMAIL PROTECTED]>
Index: linux-2.6.19-rc6-mm2/fs/compat.c
===
--- linux-2.6.19-rc6-mm2.orig/fs/compat.c 2006-11-28 12:49:40.0
+0100 +++ linux-2.6.19-rc6-mm2/fs/compat.c 2006-11-28 12:51:35.0
+0100 @@ -642,40 +642,49 @@ out:
return ret;
}
-static inline long
-copy_iocb(long nr, u32 __user *ptr32, struct iocb __user * __user *ptr64)
+asmlinkage long
+compat_sys_io_submit(aio_context_t ctx_id, int nr, u32 __user *iocb)
{
- compat_uptr_t uptr;
+ struct kioctx *ctx;
+ long ret = 0;
int i;
- for (i = 0; i < nr; ++i) {
- if (get_user(uptr, ptr32 + i))
- return -EFAULT;
- if (put_user(compat_ptr(uptr), ptr64 + i))
- return -EFAULT;
- }
- return 0;
-}
+ if (unlikely(nr < 0))
+ return -EINVAL;
-#define MAX_AIO_SUBMITS(PAGE_SIZE/sizeof(struct iocb *))
+ if (unlikely(!access_ok(VERIFY_READ, iocb, (nr * sizeof(u32)
+ return -EFAULT;
-asmlinkage long
-compat_sys_io_submit(aio_context_t ctx_id, int nr, u32 __user *iocb)
-{
- struct iocb __user * __user *iocb64;
- long ret;
+ ctx = lookup_ioctx(ctx_id);
- if (unlikely(nr < 0))
+ if (unlikely(!ctx))
return -EINVAL;
+ for (i=0; i MAX_AIO_SUBMITS)
- nr = MAX_AIO_SUBMITS;
-
- iocb64 = compat_alloc_user_space(nr * sizeof(*iocb64));
- ret = copy_iocb(nr, iocb, iocb64);
- if (!ret)
- ret = sys_io_submit(ctx_id, nr, iocb64);
- return ret;
+ if (get_user(uptr, iocb + i)) {
+ ret = -EFAULT;
+ break;
+ }
+
+ user_iocb = compat_ptr(uptr);
+
+ if (unlikely(copy_from_user(&tmp, user_iocb, sizeof(tmp {
+ ret = -EFAULT;
+ break;
+ }
+
+ ret = io_submit_one(ctx, user_iocb, &tmp);
+
+ if (ret)
+ break;
+ }
+
+ put_ioctx(ctx);
+
+ return i? i: ret;
}
struct compat_ncp_mount_data {
-
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 -mm 0/5][AIO] - AIO completion signal notification v3
Hi Here is the latest rework of the AIO completion signal notification patches. This set consists in 5 patches: 1. rework-compat-sys-io-submit: rework the sys_io_submit() compat layer, laying out the base for the following patches 2. aio-header-fix-includes: fixes the double inclusion of uio.h in aio.h 3. export-good_sigevent: move good_sigevent into signal.c and export it 4. aio-notify-sig: the AIO completion signal notification 5. listio: adds listio support Description are in the individual patches. Changes from v2: - rebased to 2.6.19-rc6-mm2 - reworked the sys_io_submit() compat layer as suggested by Zach Brown - fixed saving of a pointer to a task struct in aio-notify-sig as pointed out by Andrew Morton Changes from v1: - cleanups suggested by Christoph Hellwig, Badari Pulavarty and Zach Brown - added lisio patch Comments welcomed, as usual. Thanks, Sébastien. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 3/5][AIO] - export good_sigevent()
On Wed, Nov 29, 2006 at 11:32:34AM +0100, S?bastien Dugu? wrote: > > Export good_sigevent() > > > Move good_sigevent() from posix-timers.c to signal.c where it belongs, > and export it so that it can be used by other subsystems. A little nitpick about the subject: we usually use the term 'export' when adding an EXPORT_SYMBOL. What would better describe your patch is 'make good_sigevent non-static' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 3/5][AIO] - export good_sigevent()
On Wed, 29 Nov 2006 10:38:25 + Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Wed, Nov 29, 2006 at 11:32:34AM +0100, S?bastien Dugu? wrote: > > > > Export good_sigevent() > > > > > > Move good_sigevent() from posix-timers.c to signal.c where it belongs, > > and export it so that it can be used by other subsystems. > > A little nitpick about the subject: we usually use the term 'export' when > adding an EXPORT_SYMBOL. What would better describe your patch is > > 'make good_sigevent non-static' > No problem. Thanks, Sébastien. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 4/5][AIO] - AIO completion signal notification
I'm a little bit unhappy about the usage of the notify flag. The usage
seems correct but very confusing:
In io_submit_one we set ki_notify.notify to SIGEV_NONE and possibly
call aio_setup_sigevent:
> + /* handle setting up the sigevent for POSIX AIO signals */
> + req->ki_notify.notify = SIGEV_NONE;
> +
> + if (iocb->aio_sigeventp) {
> + ret = aio_setup_sigevent(&req->ki_notify,
> + (struct sigevent __user *)(unsigned
> long)
> + iocb->aio_sigeventp);
> + if (ret)
> + goto out_put_req;
> + }
> +
aio_setup_sigevent then checks the user passed even for which notify type
we have, and returns if it's none or otherwise sets notify->notify to it.
> + if (event.sigev_notify == SIGEV_NONE)
> + return 0;
> +
> + notify->notify = event.sigev_notify;
Later aio_setup_sigevent gets a reference to the target task_structure
if notify->notify is (SIGEV_SIGNAL|SIGEV_THREAD_ID) but _always_ stores
the target pointer.
> + if (notify->notify == (SIGEV_SIGNAL|SIGEV_THREAD_ID)) {
> + /*
> + * This reference will be dropped in really_put_req() when
> + * we're done with the request.
> + */
> + get_task_struct(target);
> + }
> +
> + notify->target = target;
Once we're done with the iocb aio_complete aclls aio_send_signal if
notify.notify is not SIGEV_NONE.
> + if (iocb->ki_notify.notify != SIGEV_NONE) {
> + ret = aio_send_signal(&iocb->ki_notify);
> +
> + /* If signal generation failed, release the sigqueue */
> + if (ret)
> + sigqueue_free(iocb->ki_notify.sigq);
> + }
> +
Which then uses notify->target to send the signal:
> + if (notify->notify & SIGEV_THREAD_ID)
> + ret = send_sigqueue(notify->signo, sigq, notify->target);
> + else
> + ret = send_group_sigqueue(notify->signo, sigq, notify->target);
And finally really_put_req puts the target if notify.notify contains
either SIGEV_SIGNAL or SIGEV_THREAD_ID.
> + /* Release task ref */
> + if (req->ki_notify.notify == (SIGEV_SIGNAL|SIGEV_THREAD_ID))
> + put_task_struct(req->ki_notify.target);
Do you see the confusing? I think all the notify.notify != SIGEV_NONE
in the above code should be replaces by the much more descriptive
notify.notify == (SIGEV_SIGNAL|SIGEV_THREAD_ID). In addition we should
only store the target pointer inside the (SIGEV_SIGNAL|SIGEV_THREAD_ID)
if block that gets a reference to 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/
Linux 2.6.16.34
New drivers since 2.6.16.33: - Echoaudio sound drivers - driver for HighPoint RocketRAID 3xxx Controllers - AdvanSys SCSI driver (actually the semi-working driver that was previously marked as broken) Location: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ git tree: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git RSS feed of the git tree: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss Changes since 2.6.16.33: Adrian Bunk (3): update the OBSOLETE_OSS_DRIVER help text Linux 2.6.16.34-rc1 Linux 2.6.16.34 Al Viro (1): [IPX]: Annotate and fix IPX checksum Alan Stern (1): USB: UHCI: Increase port-reset completion delay for HP controllers Alexey Dobriyan (2): i2c-ixp4xx: fix ") != 0))" typo [IPX]: Correct return type of ipx_map_frame_type(). Christoph Hellwig (1): [SCSI] hptiop: backout ioctl mess Dave Jones (1): [SCSI] advansys pci tweaks. David L Stevens (1): [IGMP]: Fix IGMPV3_EXP() normalization bit shift value. David S. Miller (1): [IPX]: Fix typo, ipxhdr() --> ipx_hdr() Giuliano Pochini [EMAIL PROTECTED] (1): [ALSA] Add echoaudio sound drivers Hidetoshi Seto (1): sysfs: remove duplicated dput in sysfs_update_file HighPoint Linux Team (3): [SCSI] hptiop: HighPoint RocketRAID 3xxx controller driver [SCSI] hptiop: HighPoint RocketRAID 3xxx controller driver [SCSI] hptiop: wrong register used in hptiop_reset_hba() James Bottomley (1): [SCSI] hptiop: don't use cmnd->bufflen Jean Delvare (1): Fix i2c-ixp4xx compilation breakage Kirill Korotaev (1): fix sys_getppid oopses on debug kernel Linus Torvalds (1): [SCSI] advansys driver: limp along on x86 Mark M. Hoffman (1): i2c: Handle i2c_add_adapter failure in i2c algorithm drivers Randy Dunlap (1): advansys section fixes Stephen Hemminger (2): [IPX]: Header length validation needed [IPX]: Another nonlinear receive fix Steve French (1): CIFS: report rename failure when target file is locked by Windows Takashi Iwai (3): [ALSA] Fix a typo in echoaudio/midi.c [ALSA] echoaudio - Fix Makefile [ALSA] echoaudio - Remove kfree_nocheck() Documentation/scsi/hptiop.txt | 92 Documentation/sound/alsa/ALSA-Configuration.txt | 96 MAINTAINERS |6 Makefile|2 drivers/i2c/algos/i2c-algo-bit.c|3 drivers/i2c/algos/i2c-algo-ite.c|4 drivers/i2c/algos/i2c-algo-pca.c|6 drivers/i2c/algos/i2c-algo-pcf.c|8 drivers/i2c/algos/i2c-algo-sibyte.c |4 drivers/i2c/busses/i2c-ixp4xx.c |3 drivers/scsi/Kconfig| 14 drivers/scsi/Makefile |1 drivers/scsi/advansys.c | 98 drivers/scsi/hptiop.c | 943 ++ drivers/scsi/hptiop.h | 465 +++ drivers/usb/host/uhci-hub.c | 21 fs/cifs/inode.c | 14 fs/sysfs/file.c |5 include/linux/igmp.h|2 include/net/ipx.h |4 kernel/timer.c | 41 net/ipx/af_ipx.c| 45 net/ipx/ipx_route.c |4 sound/oss/Kconfig |7 sound/pci/Kconfig | 137 sound/pci/Makefile |1 sound/pci/echoaudio/Makefile| 30 sound/pci/echoaudio/darla20.c | 99 sound/pci/echoaudio/darla20_dsp.c | 125 sound/pci/echoaudio/darla24.c | 106 sound/pci/echoaudio/darla24_dsp.c | 156 + sound/pci/echoaudio/echo3g.c| 118 sound/pci/echoaudio/echo3g_dsp.c| 131 sound/pci/echoaudio/echoaudio.c | 2196 sound/pci/echoaudio/echoaudio.h | 590 sound/pci/echoaudio/echoaudio_3g.c | 431 +++ sound/pci/echoaudio/echoaudio_dsp.c | 1125 sound/pci/echoaudio/echoaudio_dsp.h | 694 + sound/pci/echoaudio/echoaudio_gml.c | 198 + sound/pci/echoaudio/gina20.c| 103 sound/pci/echoaudio/gina20_dsp.c| 215 + sound/pci/echoaudio/gina24.c| 123 sound/pci/echoaudio/gina24_dsp.c| 346 ++ sound/pci/echoaudio/indigo.c| 104 sound/pci/echoaudio/indigo_dsp.c| 170 + sound/pci/echoaudio/indigodj.c | 104 sound/pci/echoaudio/indigodj_dsp.c |
Re: [patch] PM: suspend/resume debugging should depend on SOFTWARE_SUSPEND
On Tue, 2006-11-28 at 11:01 +0100, Mike Galbraith wrote: > On Sun, 2006-11-26 at 05:53 +0100, Mike Galbraith wrote: > > On Sat, 2006-11-25 at 18:12 +0100, Rafael J. Wysocki wrote: > > > > > Hm, could you please file a bugzilla report regarding the serial console > > > for > > > the information of its maintainer(s)? > > > > Yeah, I'll rummage around a bit first though. > > The serial console appears to be innocent. The suspend/resume methods > for my 16550A serial port aren't even being _called_, apparently because > pnp swiped ttyS0. Well, after further rummaging, the suspend/reCONFIG_PNPsume methods aren't being called because we're using 8250_pnp.c when doesn't have any :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] fs/sysv/: proper prototypes for 2 functions
On Wed, Nov 29, 2006 at 10:06:00AM +, Christoph Hellwig wrote:
> On Wed, Nov 29, 2006 at 11:04:05AM +0100, Adrian Bunk wrote:
> > This patch adds proper prototypes for sysv_{init,destroy}_icache()
> > in sysv.h
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > ---
> >
> > fs/sysv/super.c |3 ---
> > fs/sysv/sysv.h |3 +++
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > --- linux-2.6.19-rc6-mm2/fs/sysv/sysv.h.old 2006-11-29 09:21:02.0
> > +0100
> > +++ linux-2.6.19-rc6-mm2/fs/sysv/sysv.h 2006-11-29 09:21:52.0
> > +0100
> > @@ -143,6 +143,9 @@
> > extern int sysv_sync_file(struct file *, struct dentry *, int);
> > extern void sysv_set_inode(struct inode *, dev_t);
> > extern int sysv_getattr(struct vfsmount *, struct dentry *, struct kstat
> > *);
> > +int sysv_init_icache(void);
> > +void sysv_destroy_icache(void);
>
> Please follow the style used in the rest of the file and add the
> extern keyword.
Is it acceptable to remove all the extern's instead?
> > +
>
> And don't add a superflous blank line.
>
> Except for that the patch is fine.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The return of the dreaded "nobody cared" message with a Promise Card
On Wed, 29 Nov 2006 04:01:30 -0200 Rogério Brito <[EMAIL PROTECTED]> wrote: >> The problem is that whenever I plug the Quantum drive, I get stack > traces like this one (with a bit of context, so that you can get sense of > what I am talking about): Ok IRQ routing problem on what seems to be an external IRQ. > ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 > PCI: setting IRQ 10 as level-triggered > ACPI: PCI Interrupt :00:11.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> > IRQ 10 Do your working kernels also have ACPI enabled and what do they say here ? > I am willing to do a git bisect to see which may be a problematic patch > or not, but the "irq 10: nobody cared (try booting with the "irqpoll" > option)" is one that I reported to Andrew quite some time ago (I thought > that it had gone away), and it didn't manifest itself until I had to > reuse this extra drive, since I am doing a work that is producing a lot > of data. Ok I have a guess here - what does 2.6.19-rc6-mm2 do ? I've been working on fixing up the VIA IRQ routing bugs as it happens. full dmesg of the work/fail cases and an lspci -vxxx would be useful so I can see how the hardware thinks it is configured. - 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] Re: [patch] PM: suspend/resume debugging should depend on SOFTWARE_SUSPEND
On Wed, 2006-11-29 at 11:21 +0100, Mike Galbraith wrote:
> > The serial console appears to be innocent. The suspend/resume methods
> > for my 16550A serial port aren't even being _called_, apparently because
> > pnp swiped ttyS0.
(ahem, bad aim with mouse, resuming)
Well, after further rummaging, the suspend/resume methods aren't being
called because we're using 8250_pnp.c when CONFIG_PNP is set, and it
doesn't have any :) The below works for me, though I'm not sure it's
sufficient. If it is deemed sufficient, I'll submit it to Andrew.
Add suspend/resume methods to 8250_pnp driver.
--- linux-2.6.19-rc6-mm2/drivers/serial/8250_pnp.c.org 2006-11-29
07:14:15.0 +0100
+++ linux-2.6.19-rc6-mm2/drivers/serial/8250_pnp.c 2006-11-29
10:55:17.0 +0100
@@ -464,11 +464,38 @@ static void __devexit serial_pnp_remove(
serial8250_unregister_port(line - 1);
}
+#ifdef CONFIG_PM
+static int serial_pnp_suspend(struct pnp_dev *dev, pm_message_t state)
+{
+ long line = (long)pnp_get_drvdata(dev);
+
+ if (!line)
+ return -ENODEV;
+ serial8250_suspend_port(line - 1);
+ return 0;
+}
+
+static int serial_pnp_resume(struct pnp_dev *dev)
+{
+ long line = (long)pnp_get_drvdata(dev);
+
+ if (!line)
+ return -ENODEV;
+ serial8250_resume_port(line - 1);
+ return 0;
+}
+
+#endif /* CONFIG_PM */
+
static struct pnp_driver serial_pnp_driver = {
.name = "serial",
- .id_table = pnp_dev_table,
.probe = serial_pnp_probe,
.remove = __devexit_p(serial_pnp_remove),
+#ifdef CONFIG_PM
+ .suspend= serial_pnp_suspend,
+ .resume = serial_pnp_resume,
+#endif
+ .id_table = pnp_dev_table,
};
static int __init serial8250_pnp_init(void)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] use probe_kernel_address in Dwarf2 unwinder
Use probe_kernel_address() instead of __get_user() in Dwarf2 unwinder.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.19-rc6/kernel/unwind.c2006-11-29 10:04:11.0 +0100
+++ 2.6.19-rc6-unwind-probe_kernel_address/kernel/unwind.c 2006-11-29
10:22:16.0 +0100
@@ -14,8 +14,8 @@
#include
#include
#include
+#include
#include
-#include
#include
extern char __start_unwind[], __end_unwind[];
@@ -550,7 +550,7 @@ static unsigned long read_pointer(const
return 0;
}
if ((ptrType & DW_EH_PE_indirect)
- && __get_user(value, (unsigned long *)value))
+ && probe_kernel_address((unsigned long *)value, value))
return 0;
*pLoc = ptr.p8;
@@ -981,18 +981,18 @@ int unwind(struct unwind_frame_info *fra
& (sizeof(unsigned long) - 1))) {
unsigned long link;
- if (!__get_user(link,
- (unsigned long *)(UNW_FP(frame)
- + FRAME_LINK_OFFSET))
+ if (!probe_kernel_address((unsigned long
*)(UNW_FP(frame)
+ +
FRAME_LINK_OFFSET),
+ link)
# if FRAME_RETADDR_OFFSET < 0
&& link > bottom && link < UNW_FP(frame)
# else
&& link > UNW_FP(frame) && link < bottom
# endif
&& !(link & (sizeof(link) - 1))
- && !__get_user(UNW_PC(frame),
- (unsigned long *)(UNW_FP(frame)
- +
FRAME_RETADDR_OFFSET))) {
+ && !probe_kernel_address((unsigned long
*)(UNW_FP(frame)
+ +
FRAME_RETADDR_OFFSET))
+ UNW_PC(frame)) {
UNW_SP(frame) = UNW_FP(frame) +
FRAME_RETADDR_OFFSET
# if FRAME_RETADDR_OFFSET < 0
-
@@ -1103,7 +1103,7 @@ int unwind(struct unwind_frame_info *fra
return -EIO;
switch(reg_info[i].width) {
#define CASE(n) case sizeof(u##n): \
- __get_user(FRAME_REG(i, u##n), (u##n
*)addr); \
+ probe_kernel_address((u##n *)addr,
FRAME_REG(i, u##n)); \
break
CASES;
#undef CASE
-
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] more sanity checks in Dwarf2 unwinder
Tighten the requirements on both input to and output from the Dwarf2
unwinder.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.19-rc6/arch/i386/kernel/traps.c 2006-11-29 10:03:03.0
+0100
+++ 2.6.19-rc6-unwind-more-sanity-checks/arch/i386/kernel/traps.c
2006-11-28 17:18:45.0 +0100
@@ -159,12 +159,19 @@ dump_trace_unwind(struct unwind_frame_in
{
struct ops_and_data *oad = (struct ops_and_data *)data;
int n = 0;
+ unsigned long sp = UNW_SP(info);
+ if (arch_unw_user_mode(info))
+ return -1;
while (unwind(info) == 0 && UNW_PC(info)) {
n++;
oad->ops->address(oad->data, UNW_PC(info));
if (arch_unw_user_mode(info))
break;
+ if ((sp & ~(PAGE_SIZE - 1)) == (UNW_SP(info) & ~(PAGE_SIZE - 1))
+ && sp > UNW_SP(info))
+ break;
+ sp = UNW_SP(info);
}
return n;
}
--- linux-2.6.19-rc6/arch/x86_64/kernel/traps.c 2006-11-29 10:03:18.0
+0100
+++ 2.6.19-rc6-unwind-more-sanity-checks/arch/x86_64/kernel/traps.c
2006-11-28 17:18:28.0 +0100
@@ -225,12 +225,19 @@ static int dump_trace_unwind(struct unwi
{
struct ops_and_data *oad = (struct ops_and_data *)context;
int n = 0;
+ unsigned long sp = UNW_SP(info);
+ if (arch_unw_user_mode(info))
+ return -1;
while (unwind(info) == 0 && UNW_PC(info)) {
n++;
oad->ops->address(oad->data, UNW_PC(info));
if (arch_unw_user_mode(info))
break;
+ if ((sp & ~(PAGE_SIZE - 1)) == (UNW_SP(info) & ~(PAGE_SIZE - 1))
+ && sp > UNW_SP(info))
+ break;
+ sp = UNW_SP(info);
}
return n;
}
--- linux-2.6.19-rc6/include/asm-i386/unwind.h 2006-11-29 10:04:04.0
+0100
+++ 2.6.19-rc6-unwind-more-sanity-checks/include/asm-i386/unwind.h
2006-11-28 17:20:26.0 +0100
@@ -78,17 +78,13 @@ extern asmlinkage int arch_unwind_init_r
void
*arg),
void *arg);
-static inline int arch_unw_user_mode(const struct unwind_frame_info *info)
+static inline int arch_unw_user_mode(/*const*/ struct unwind_frame_info *info)
{
-#if 0 /* This can only work when selector register and EFLAGS saves/restores
- are properly annotated (and tracked in UNW_REGISTER_INFO). */
- return user_mode_vm(&info->regs);
-#else
- return info->regs.eip < PAGE_OFFSET
+ return user_mode_vm(&info->regs)
+ || info->regs.eip < PAGE_OFFSET
|| (info->regs.eip >= __fix_to_virt(FIX_VDSO)
- && info->regs.eip < __fix_to_virt(FIX_VDSO) + PAGE_SIZE)
+ && info->regs.eip < __fix_to_virt(FIX_VDSO) + PAGE_SIZE)
|| info->regs.esp < PAGE_OFFSET;
-#endif
}
#else
--- linux-2.6.19-rc6/include/asm-x86_64/unwind.h2006-11-29
10:04:06.0 +0100
+++ 2.6.19-rc6-unwind-more-sanity-checks/include/asm-x86_64/unwind.h
2006-11-28 17:18:08.0 +0100
@@ -87,14 +87,10 @@ extern int arch_unwind_init_running(stru
static inline int arch_unw_user_mode(const struct unwind_frame_info *info)
{
-#if 0 /* This can only work when selector register saves/restores
- are properly annotated (and tracked in UNW_REGISTER_INFO). */
- return user_mode(&info->regs);
-#else
- return (long)info->regs.rip >= 0
+ return user_mode(&info->regs)
+ || (long)info->regs.rip >= 0
|| (info->regs.rip >= VSYSCALL_START && info->regs.rip <
VSYSCALL_END)
|| (long)info->regs.rsp >= 0;
-#endif
}
#else
--- linux-2.6.19-rc6/kernel/unwind.c2006-11-29 10:04:11.0 +0100
+++ 2.6.19-rc6-unwind-more-sanity-checks/kernel/unwind.c2006-11-28
16:35:58.0 +0100
@@ -94,6 +94,7 @@ static const struct {
typedef unsigned long uleb128_t;
typedef signed long sleb128_t;
+#define sleb128abs __builtin_labs
static struct unwind_table {
struct {
@@ -786,7 +787,7 @@ int unwind(struct unwind_frame_info *fra
#define FRAME_REG(r, t) (((t *)frame)[reg_info[r].offs])
const u32 *fde = NULL, *cie = NULL;
const u8 *ptr = NULL, *end = NULL;
- unsigned long pc = UNW_PC(frame) - frame->call_frame;
+ unsigned long pc = UNW_PC(frame) - frame->call_frame, sp;
unsigned long startLoc = 0, endLoc = 0, cfa;
unsigned i;
signed ptrType = -1;
@@ -935,6 +936,9 @@ int unwind(struct unwind_frame_info *fra
state.dataAlign = get_sleb128(&ptr, end);
if (state.codeAlign == 0 || state.dataAlign == 0 || ptr >= end)
cie = NULL;
+ else if (UNW_PC(frame) % state.codeAlign
+|
Re: [2.6 patch] proper prototype for remove_inode_dquot_ref()
> This patch adds a proer prototype for remove_inode_dquot_ref() in
> include/linux/quotaops.h
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Fine with me, if you find it better this way (but that function is not
really supposed to be called from anywhere else).
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
Honza
> ---
>
> fs/inode.c |3 ---
> include/linux/quotaops.h |3 +++
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> --- linux-2.6.19-rc6-mm2/include/linux/quotaops.h.old 2006-11-29
> 09:43:03.0 +0100
> +++ linux-2.6.19-rc6-mm2/include/linux/quotaops.h 2006-11-29
> 09:43:21.0 +0100
> @@ -37,6 +37,9 @@
> extern int dquot_commit_info(struct super_block *sb, int type);
> extern int dquot_mark_dquot_dirty(struct dquot *dquot);
>
> +int remove_inode_dquot_ref(struct inode *inode, int type,
> +struct list_head *tofree_head);
> +
> extern int vfs_quota_on(struct super_block *sb, int type, int format_id,
> char *path);
> extern int vfs_quota_on_mount(struct super_block *sb, char *qf_name,
> int format_id, int type);
> --- linux-2.6.19-rc6-mm2/fs/inode.c.old 2006-11-29 09:43:40.0
> +0100
> +++ linux-2.6.19-rc6-mm2/fs/inode.c 2006-11-29 09:43:50.0 +0100
> @@ -1249,9 +1249,6 @@
> */
> #ifdef CONFIG_QUOTA
>
> -/* Function back in dquot.c */
> -int remove_inode_dquot_ref(struct inode *, int, struct list_head *);
> -
> void remove_dquot_ref(struct super_block *sb, int type,
> struct list_head *tofree_head)
> {
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
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.18 tsc clocksource + ntp = excessive drift; acpi_pm does fine.
[cut] Also does booting w/ "noapic" change the behavior? No, it didn't. It behaves exactly as before. - Alexandre - 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 2/2] readahead nfsd case: fix uninitialized ra_min/ra_max
ra_min/ra_max are not initialized, fix it.
New benchmark numbers on
hda: ST3250820A, ATA DISK drive
hda: max request size: 512KiB
hda: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63,
UDMA(100)
with nfs mount
mount -o tcp,rsize=$((rsize<<10)) localhost:$EXPORT $MNT
rsize stock adaptive
==
f
8k 3.072.51-18.2%
32k 2.402.17 -9.6%
128k 2.402.35 -2.1%
ff
8k 12.446.40-48.6%
32k 14.625.46-62.7%
128k 15.795.19-67.1%
d
8k 2.842.48-12.7%
32k 2.531.99-21.3%
128k 2.182.00 -8.3%
dd
8k 8.167.99 -2.1%
32k 8.276.88-16.8%
128k 7.756.97-10.1%
The 4 patterns tested are:
f: single file read
ff: double file parallel read
d: single dir read
dd: double dir parallel read
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
--- linux-2.6.19-rc6-mm1.orig/mm/readahead.c
+++ linux-2.6.19-rc6-mm1/mm/readahead.c
@@ -1616,6 +1616,10 @@ page_cache_readahead_adaptive(struct add
unsigned long ra_max;
int ret;
+ /* no read-ahead */
+ if (!ra->ra_pages)
+ return 0;
+
if (page) {
ClearPageReadahead(page);
@@ -1635,9 +1639,6 @@ page_cache_readahead_adaptive(struct add
offset + LAPTOP_POLL_INTERVAL))
return 0;
}
- } else if (ra->flags & RA_FLAG_NFSD) { /* nfsd read */
- ra_size = max_sane_readahead(req_size);
- goto readit;
}
if (page)
@@ -1647,11 +1648,13 @@ page_cache_readahead_adaptive(struct add
get_readahead_bounds(ra, &ra_min, &ra_max);
- /* read-ahead disabled? */
- if (unlikely(!ra_max || !readahead_ratio)) {
- ra_size = max_sane_readahead(req_size);
+ /* read as is */
+ if (!readahead_ratio)
+ goto readit;
+
+ /* nfsd read */
+ if (!page && (ra->flags & RA_FLAG_NFSD))
goto readit;
- }
/*
* Start of file.
@@ -1698,11 +1701,11 @@ page_cache_readahead_adaptive(struct add
return 0;
}
+readit:
/*
* Random read.
*/
ra_size = min(req_size, ra_max);
-readit:
ra_size = __do_page_cache_readahead(mapping, filp, offset, ra_size, 0);
ra_account(ra, RA_EVENT_RANDOM_READ, ra_size);
--
-
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 1/2] readahead sysctl parameters fix
- do no extra readahead when (readahead_ratio == 1)
- define readahead_hit_rate inside CONFIG_ADAPTIVE_READAHEAD ifdefs
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
--- linux-2.6.19-rc6-mm1.orig/include/linux/mm.h
+++ linux-2.6.19-rc6-mm1/include/linux/mm.h
@@ -1074,7 +1074,7 @@ extern int readahead_ratio;
static inline int prefer_adaptive_readahead(void)
{
- return readahead_ratio > 1;
+ return readahead_ratio != 1;
}
/* Do stack extension */
--- linux-2.6.19-rc6-mm1.orig/Documentation/sysctl/vm.txt
+++ linux-2.6.19-rc6-mm1/Documentation/sysctl/vm.txt
@@ -234,7 +234,7 @@ plenty of memory(>>2MB per reader), a bi
readahead_ratio also selects the readahead logic:
VALUE CODE PATH
---
- 0 disable readahead totally
+ 0 read as is, no extra readahead
1 select the stock readahead logic
2-100 select the adaptive readahead logic
--- linux-2.6.19-rc6-mm1.orig/mm/readahead.c
+++ linux-2.6.19-rc6-mm1/mm/readahead.c
@@ -40,10 +40,10 @@
/* Set read-ahead size to ##% of the thrashing-threshold. */
int readahead_ratio = 50;
EXPORT_SYMBOL_GPL(readahead_ratio);
-#endif
/* Readahead as long as cache hit ratio keeps above 1/##. */
int readahead_hit_rate = 0;
+#endif /* CONFIG_ADAPTIVE_READAHEAD */
/*
* Detailed classification of read-ahead behaviors.
--
-
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 0/2] adaptive readahead fixes
Andrew, Here are two bug fix patches against -mm, with their recommended placement: readahead-events-accounting.patch readahead-rescue_pages.patch readahead-sysctl-parameters.patch +readahead-sysctl-parameters-fix.patch readahead-min-max-sizes.patch readahead-state-based-method-aging-accounting.patch readahead-state-based-method-routines.patch readahead-loop-case.patch readahead-nfsd-case.patch readahead-nfsd-case-fix.patch +readahead-nfsd-case-fix-uninitialized-ra_min-ra_max.patch readahead-turn-on-by-default.patch readahead-remove-size-limit-on-read_ahead_kb.patch readahead-remove-size-limit-of-max_sectors_kb-on-read_ahead_kb.patch readahead-sysctl-parameters-fix.patch = Two trivial fixes. // Was three, but you were so swift on CTL_UNNUMBERED :-) readahead-nfsd-case-fix-uninitialized-ra_min-ra_max.patch = The NFS benchmark is ran again with the bug fixed. The summary is included in the patch as changelog. The raw numbers are here: pattern=f rsize=8k ratio=1 3.04s clock 0.64s kernel 0.01s user 224+1987 cs ratio=1 3.06s clock 0.66s kernel 0.02s user 199+2340 cs ratio=1 3.10s clock 0.63s kernel 0.02s user 254+2264 cs ratio=502.59s clock 0.60s kernel 0.02s user 106+1180 cs ratio=502.43s clock 0.59s kernel 0.01s user 94+1189 cs ratio=502.50s clock 0.59s kernel 0.02s user 98+1174 cs pattern=f rsize=32k ratio=1 2.39s clock 0.29s kernel 0.02s user 1046+59 cs ratio=1 2.40s clock 0.29s kernel 0.01s user 1040+69 cs ratio=1 2.41s clock 0.28s kernel 0.02s user 1114+55 cs ratio=502.18s clock 0.32s kernel 0.02s user 227+213 cs ratio=502.15s clock 0.32s kernel 0.02s user 230+215 cs ratio=502.17s clock 0.33s kernel 0.01s user 225+208 cs pattern=f rsize=128k ratio=1 2.42s clock 0.32s kernel 0.01s user 436+131 cs ratio=1 2.38s clock 0.33s kernel 0.02s user 441+128 cs ratio=1 2.39s clock 0.31s kernel 0.01s user 448+122 cs ratio=502.36s clock 0.30s kernel 0.01s user 202+67 cs ratio=502.21s clock 0.31s kernel 0.02s user 194+72 cs ratio=502.47s clock 0.30s kernel 0.01s user 201+63 cs pattern=ff rsize=8k ratio=1 12.19s clock 1.18s kernel 0.38s user 4152+13042 cs ratio=1 12.88s clock 1.21s kernel 0.33s user 4564+12574 cs ratio=1 12.26s clock 1.22s kernel 0.38s user 4857+12453 cs ratio=506.53s clock 1.27s kernel 0.32s user 174+2256 cs ratio=506.33s clock 1.27s kernel 0.33s user 164+2252 cs ratio=506.35s clock 1.24s kernel 0.35s user 151+2264 cs pattern=ff rsize=32k ratio=1 14.49s clock 0.90s kernel 0.37s user 2904+9906 cs ratio=1 14.55s clock 1.00s kernel 0.34s user 2899+9803 cs ratio=1 14.81s clock 1.00s kernel 0.31s user 2910+10147 cs ratio=505.48s clock 0.65s kernel 0.30s user 177+512 cs ratio=505.42s clock 0.68s kernel 0.29s user 181+509 cs ratio=505.47s clock 0.65s kernel 0.29s user 175+521 cs pattern=ff rsize=128k ratio=1 15.87s clock 0.90s kernel 0.32s user 1496+8738 cs ratio=1 15.33s clock 0.89s kernel 0.34s user 1718+8350 cs ratio=1 16.17s clock 0.91s kernel 0.32s user 1706+7959 cs ratio=505.18s clock 0.56s kernel 0.28s user 175+255 cs ratio=505.22s clock 0.57s kernel 0.30s user 172+258 cs ratio=505.16s clock 0.54s kernel 0.30s user 168+260 cs pattern=d rsize=8k ratio=1 2.86s clock 0.45s kernel 0.07s user 7961+729 cs ratio=1 2.87s clock 0.50s kernel 0.07s user 8036+627 cs ratio=1 2.80s clock 0.51s kernel 0.07s user 7986+640 cs ratio=502.58s clock 0.51s kernel 0.07s user 8873+177 cs ratio=502.39s clock 0.51s kernel 0.05s user 8782+194 cs ratio=502.48s clock 0.51s kernel 0.06s user 8884+171 cs pattern=d rsize=32k ratio=1 2.49s clock 0.40s kernel 0.05s user 7428+83 cs ratio=1 2.57s clock 0.40s kernel 0.06s user 7425+86 cs ratio=1 2.54s clock 0.41s kernel 0.06s user 7427+83 cs ratio=502.02s clock 0.40s kernel 0.08s user 7478+169 cs ratio=501.99s clock 0.43s kernel 0.05s user 7488+162 cs ratio=501.95s clock 0.39s kernel 0.05s user 7483+169 cs pattern=d rsize=128k ratio=1 2.17s clock 0.41s kernel 0.05s user 7248+120 cs ratio=1 2.13s clock 0.42s kernel 0.05s user 7242+133 cs ratio=1 2.23s clock 0.43s kernel 0.07s user 7247+121 cs ratio=502.09s clock 0.39s kernel 0.06s user 7315+97 cs ratio=501.93s clock 0.41s kernel 0.05s user 7314+131 cs ratio=501.97s clock 0.43s kernel 0.07s user 7317+132 cs pattern=dd rsize=8k ratio=1 8.23s clock 1.04s kernel 0.18s user 15564+1306 cs ratio=1 8.20s cl
Re: [PATCH] devices.txt - LANANA merge
Torben Mathiasen wrote: > Here's a merge with the latest from LANANA. Its been a while, so _please_ let > me know if anyone sees unwanted changes. A few whitespaces and formatting > changes included too. [] > +258 blockROM/Flash read-only translation layer > + 0 = /dev/blockrom0First ROM card's translation layer > interface > + 1 = /dev/blockrom0Second ROM card's translation layer > interface ^^^ Shouldn't here be '1', ie, /dev/blockrom1 ? /mjt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 4/5][AIO] - AIO completion signal notification
On Wed, Nov 29, 2006 at 11:33:01AM +0100, S?bastien Dugu? wrote: > AIO completion signal notification > > The current 2.6 kernel does not support notification of user space via > an RT signal upon an asynchronous IO completion. The POSIX specification > states that when an AIO request completes, a signal can be delivered to > the application as notification. > > This patch adds a struct sigevent *aio_sigeventp to the iocb. > The relevant fields (pid, signal number and value) are stored in the kiocb > for use when the request completes. > > That sigevent structure is filled by the application as part of the AIO > request preparation. Upon request completion, the kernel notifies the > application using those sigevent parameters. If SIGEV_NONE has been specified, > then the old behaviour is retained and the application must rely on polling > the completion queue using io_getevents(). Well, from what I see applications must rely on polling the completion queue using io_getevents() in any case, isn't that the only way how to free the kernel resources associated with the AIO request, even if it uses SIGEV_SIGNAL or thread notification? aio_error/aio_return/aio_suspend will still need to io_getevents, the only important difference with this patch is that a) the polling doesn't need to be asynchronous (i.e. have a special thread which just loops doing io_getevents) b) it doesn't need to care about notification itself. Jakub - 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] Implement file posix capabilities
I use this patch with 2.6.18.3. patching: ok configuring: ok compiling: ok installing: ok running: ok tested with httpd, smbd, nmbd, named, cupsd, ping, traceroute, modprobe, traceroute, ntpdate, xinit, killall, eject, dhcpd, route, qemu: ok I use this patch as documented: http://www.friedhoff.org/fscaps.html I also tested the patched kernel with "CONFIG_SECURITY_FS_CAPABILITIES is not set" and xinit kills X perfectly, when the GUI is stopped. Any other tests that might be helpful? The webpage is updated. Chris On Mon, 27 Nov 2006 11:07:40 -0600 "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > From: Serge E. Hallyn <[EMAIL PROTECTED]> > Subject: [PATCH 1/1] Implement file posix capabilities > > Implement file posix capabilities. This allows programs to be given a > subset of root's powers regardless of who runs them, without having to use > setuid and giving the binary all of root's powers. > > This version works with Kaigai Kohei's userspace tools, found at > http://www.kaigai.gr.jp/index.php. For more information on how to use this > patch, Chris Friedhoff has posted a nice page at > http://www.friedhoff.org/fscaps.html. > > Changelog: > Nov 27: > Incorporate fixes from Andrew Morton > (security-introduce-file-caps-tweaks and > security-introduce-file-caps-warning-fix) > Fix Kconfig dependency. > Fix change signaling behavior when file caps are not compiled in. - snip - Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] remove broken video drivers (v3)
On Wed, 29 Nov 2006, Adrian Bunk wrote:
> This patch removes some video drivers that:
> - had already been marked as BROKEN in 2.6.0 three years ago and
> - are still marked as BROKEN.
>
> These are the following drivers:
> - FB_CYBER
> - FB_VIRGE
> - FB_RETINAZ3
> - FB_SUN3
>
> Drivers that had been marked as BROKEN for such a long time seem to be
> unlikely to be revived in the forseeable future.
>
> But if anyone wants to ever revive any of these drivers, the code is
> still present in the older kernel releases.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-By: Geert Uytterhoeven <[EMAIL PROTECTED]>
> This patch obsoletes the following patches in -mm:
> ioremap-balanced-with-iounmap-for-drivers-video-cyberfb.patch
> ioremap-balanced-with-iounmap-for-drivers-video-retz3fb.patch
> ioremap-balanced-with-iounmap-for-drivers-video-virgefb.patch
If possible, can these still be integrated first, to ease a future
resurrection?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 patch] drivers/scsi/scsi_error.c should #include "scsi_transport_api.h"
Every file should #include the headers containing the prototypes for its global functions. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.19-rc6-mm2/drivers/scsi/scsi_error.c.old 2006-11-29 09:58:41.0 +0100 +++ linux-2.6.19-rc6-mm2/drivers/scsi/scsi_error.c 2006-11-29 09:58:58.0 +0100 @@ -36,6 +36,7 @@ #include "scsi_priv.h" #include "scsi_logging.h" +#include "scsi_transport_api.h" #define SENSE_TIMEOUT (10*HZ) #define START_UNIT_TIMEOUT (30*HZ) - 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] PCMCIA: identification strings for Elan
From: Tony Olech <[EMAIL PROTECTED]>
In older versions of the linux kernel it was sufficient for the
16-bit PCMCIA card manufacturer to distribute or make available
a text configuration file along with the physical cards. Such a
file with an extension of ".conf" and placed in the /etc/pcmcia
very easily enabled new hardware without rebuilding the kernel,
however with the new scheme of things, having found no userland
solution to the problem of new 16bit pcmcia card identification
this patch enumerates Elan Digital Systems strings.
In addition, for the ID strings to result in the correct module
being loaded, the too wide matching criterion of the PDaudioCF
card needs to have the MANF_ID/CARD_ID numbers replaced by the
more specific PROD_ID1 and PROD_ID2 strings. It is unfortunate
that otherwise the pdaudiocf module is loaded whenever an ELAN
pcmcia card is inserted, resulting in various random lockups
Signed-off-by: Tony Olech <[EMAIL PROTECTED]>
---
third attempt at submission - hopefully this conforms canonically.
patch against linux kernel 2.6.18 to add PCMCIA identification strings:
--- ./sound/pcmcia/pdaudiocf/pdaudiocf.c.orig 2006-11-20 10:24:23.0
+
+++ ./sound/pcmcia/pdaudiocf/pdaudiocf.c2006-11-20 10:33:46.0
+
@@ -299,7 +299,8 @@ static int pdacf_resume(struct pcmcia_de
* Module entry points
*/
static struct pcmcia_device_id snd_pdacf_ids[] = {
- PCMCIA_DEVICE_MANF_CARD(0x015d, 0x4c45),
+ /* this is too general PCMCIA_DEVICE_MANF_CARD(0x015d, 0x4c45), */
+ PCMCIA_DEVICE_PROD_ID12("Core
Sound","PDAudio-CF",0x396d19d2,0x71717b49),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, snd_pdacf_ids);
--- ./drivers/serial/serial_cs.c.orig 2006-11-17 10:59:10.0 +
+++ ./drivers/serial/serial_cs.c2006-11-17 10:59:54.0 +
@@ -787,6 +787,30 @@ static struct pcmcia_device_id serial_id
PCMCIA_DEVICE_CIS_PROD_ID123("ADVANTECH", "COMpad-32/85", "1.0",
0x96913a85, 0x8fbe92ae, 0x0877b627, "COMpad2.cis"),
PCMCIA_DEVICE_CIS_PROD_ID2("RS-COM 2P", 0xad20b156, "RS-COM-2P.cis"),
PCMCIA_DEVICE_CIS_MANF_CARD(0x0013, 0x, "GLOBETROTTER.cis"),
+ PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.","SERIAL
CARD: SL100 1.00.",0x19ca78af,0xf964f42b),
+ PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.","SERIAL
CARD: SL100",0x19ca78af,0x71d98e83),
+ PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.","SERIAL
CARD: SL232 1.00.",0x19ca78af,0x69fb7490),
+ PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.","SERIAL
CARD: SL232",0x19ca78af,0xb6bc0235),
+ PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c2000.","SERIAL
CARD: CF232",0x63f2e0bd,0xb9e175d3),
+ PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c2000.","SERIAL
CARD: CF232-5",0x63f2e0bd,0xfce33442),
+ PCMCIA_DEVICE_PROD_ID12("Elan","Serial Port:
CF232",0x3beb8cf2,0x171e7190),
+ PCMCIA_DEVICE_PROD_ID12("Elan","Serial Port:
CF232-5",0x3beb8cf2,0x20da4262),
+ PCMCIA_DEVICE_PROD_ID12("Elan","Serial Port:
CF428",0x3beb8cf2,0xea5dd57d),
+ PCMCIA_DEVICE_PROD_ID12("Elan","Serial Port:
CF500",0x3beb8cf2,0xd77255fa),
+ PCMCIA_DEVICE_PROD_ID12("Elan","Serial Port:
IC232",0x3beb8cf2,0x6a709903),
+ PCMCIA_DEVICE_PROD_ID12("Elan","Serial Port:
SL232",0x3beb8cf2,0x18430676),
+ PCMCIA_DEVICE_PROD_ID12("Elan","Serial Port:
XL232",0x3beb8cf2,0x6f933767),
+ PCMCIA_MFC_DEVICE_PROD_ID12(0,"Elan","Serial Port:
CF332",0x3beb8cf2,0x16dc1ba7),
+ PCMCIA_MFC_DEVICE_PROD_ID12(0,"Elan","Serial Port:
SL332",0x3beb8cf2,0x19816c41),
+ PCMCIA_MFC_DEVICE_PROD_ID12(0,"Elan","Serial Port:
SL385",0x3beb8cf2,0x64112029),
+ PCMCIA_MFC_DEVICE_PROD_ID12(0,"Elan","Serial Port:
SL432",0x3beb8cf2,0x1cce7ac4),
+ PCMCIA_MFC_DEVICE_PROD_ID12(0,"Elan","Serial+Parallel Port:
SP230",0x3beb8cf2,0xdb9e58bc),
+ PCMCIA_MFC_DEVICE_PROD_ID12(1,"Elan","Serial Port:
CF332",0x3beb8cf2,0x16dc1ba7),
+ PCMCIA_MFC_DEVICE_PROD_ID12(1,"Elan","Serial Port:
SL332",0x3beb8cf2,0x19816c41),
+ PCMCIA_MFC_DEVICE_PROD_ID12(1,"Elan","Serial Port:
SL385",0x3beb8cf2,0x64112029),
+ PCMCIA_MFC_DEVICE_PROD_ID12(1,"Elan","Serial Port:
SL432",0x3beb8cf2,0x1cce7ac4),
+ PCMCIA_MFC_DEVICE_PROD_ID12(2,"Elan","Serial Port:
SL432",0x3beb8cf2,0x1cce7ac4),
+ PCMCIA_MFC_DEVICE_PROD_ID12(3,"Elan","Serial Port:
SL432",0x3beb8cf2,0x1cce7ac4),
/* too generic */
/* PCMCIA_MFC_DEVICE_MANF_CARD(0, 0x0160, 0x0002), */
/* PCMCIA_MFC_DEVICE_MANF_CARD(1, 0x0160, 0x0002), */
--- ./drivers/parport/parport_cs.c.orig 2006-11-17 10:57:55.0 +
+++ ./drivers/parport/parport_cs.c 2006-11-17 10:58:52.0 +
@@ -263,6 +263,7 @@ void parport_cs_release(struct pcmcia_de
static struct pcmcia_device_id parport_ids[] = {
PCMCIA_DEVICE_FUNC_ID(3),
+ PCMCIA_MFC_DEVICE_PROD_ID12(1,"Elan","Serial+
2.6.16.32 stuck in generic_file_aio_write()
Hi,
I've got a machine which occasionally locks up. I can still sysrq it from
a serial console, so it's not entirely dead.
A sysrq-t learns me that it's got a large number of httpd processes stuck
in D state :
httpd D F7619440 2160 11635 2057 11636 (NOTLB)
dbb7ae14 cc9b0550 c33224a0 f7619440 de187604 00b3 0001
00b3 d374a550 c33224a0 0005b8d8 f04af800
000f75e7
d374a550 cc9b0550 cc9b0678 ef7d33ec ef7d33e8 cc9b0550 ef7d33fc
c041bf70
Call Trace:
[] __mutex_lock_slowpath+0x92/0x43e
[] generic_file_aio_write+0x5c/0xfa
[] generic_file_aio_write+0x5c/0xfa
[] generic_file_aio_write+0x5c/0xfa
[] permission+0xad/0xcb
[] ext3_file_write+0x3b/0xb0
[] do_sync_write+0xd5/0x130
[] _spin_unlock+0xb/0xf
[] autoremove_wake_function+0x0/0x4b
[] vfs_write+0x1a3/0x1a8
[] sys_write+0x4b/0x74
[] sysenter_past_esp+0x54/0x75
After this, the machine is rendered useless (probably due to the fact that
disk IO isn't working anymore).
The lock debugging gives me this :
D httpd:11635 [cc9b0550, 116] blocked on mutex: [ef7d33e8]
{inode_init_once}
.. held by: httpd: 506 [d67e1000, 121]
... acquired at: generic_file_aio_write+0x5c/0xfa
I see similiar things as mentioned in http://lkml.org/lkml/2006/1/10/64,
with the difference that I'm not running software RAID or SATA (it's an
Areca ARC-1110).
I can't reproduce it until now, it 'just' happens. Can someone give me a
pointer where to start looking ?
Erich, I've CC-ed you since the machine is running an Areca RAID config.
It's also the only used disk subsystem in this machine.
Regards,
Igmar
-
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] compile fix on x86 without X86_LOCAL_APIC (was 2.6.19-rc6-mm2)
On Tue, 28 Nov 2006, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/ When i386 kernel is compiled without CONFIG_X86_LOCAL_APIC, this happens: In file included from arch/i386/kernel/traps.c:51: include/asm/nmi.h:46:1: warning: "trigger_all_cpu_backtrace" redefined In file included from arch/i386/kernel/traps.c:32: include/linux/nmi.h:25:1: warning: this is the location of the previous definition In file included from arch/i386/kernel/traps.c:51: include/asm/nmi.h:46:1: warning: "trigger_all_cpu_backtrace" redefined In file included from arch/i386/kernel/traps.c:32: include/linux/nmi.h:25:1: warning: this is the location of the previous definition This is because x86_64-mm-all-cpu-backtrace.patch makes trigger_all_cpu_backtrace to be defined twice in such case. This fixes it. Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> --- include/asm-i386/nmi.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/i386/kernel/traps.c b/arch/i386/kernel/traps.c diff --git a/include/asm-i386/nmi.h b/include/asm-i386/nmi.h index 571a32c..02a3f7f 100644 --- a/include/asm-i386/nmi.h +++ b/include/asm-i386/nmi.h @@ -42,7 +42,9 @@ extern int proc_nmi_enabled(struct ctl_t void __user *, size_t *, loff_t *); extern int unknown_nmi_panic; +#ifdef ARCH_HAS_NMI_WATCHDOG void __trigger_all_cpu_backtrace(void); #define trigger_all_cpu_backtrace() __trigger_all_cpu_backtrace() +#endif #endif /* ASM_NMI_H */ - 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 -mm 1/2] s390: Use dev->groups for subchannel attributes.
From: Cornelia Huck <[EMAIL PROTECTED]>
Use dev->groups for adding/removing the subchannel attribute group.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
---
drivers/s390/cio/css.c|5 +
drivers/s390/cio/css.h|1 +
drivers/s390/cio/device.c | 16 +---
3 files changed, 11 insertions(+), 11 deletions(-)
--- linux-2.6-CH.orig/drivers/s390/cio/css.c
+++ linux-2.6-CH/drivers/s390/cio/css.c
@@ -137,6 +137,7 @@ css_register_subchannel(struct subchanne
sch->dev.parent = &css[0]->device;
sch->dev.bus = &css_bus_type;
sch->dev.release = &css_subchannel_release;
+ sch->dev.groups = subch_attr_groups;
/* make it known to the system */
ret = css_sch_device_register(sch);
@@ -146,10 +147,6 @@ css_register_subchannel(struct subchanne
return ret;
}
css_get_ssd_info(sch);
- ret = subchannel_add_files(&sch->dev);
- if (ret)
- printk(KERN_WARNING "%s: could not add attributes to %s\n",
- __func__, sch->dev.bus_id);
return ret;
}
--- linux-2.6-CH.orig/drivers/s390/cio/css.h
+++ linux-2.6-CH/drivers/s390/cio/css.h
@@ -190,4 +190,5 @@ extern struct workqueue_struct *slow_pat
extern struct work_struct slow_path_work;
int subchannel_add_files (struct device *);
+extern struct attribute_group *subch_attr_groups[];
#endif
--- linux-2.6-CH.orig/drivers/s390/cio/device.c
+++ linux-2.6-CH/drivers/s390/cio/device.c
@@ -235,9 +235,11 @@ chpids_show (struct device * dev, struct
ssize_t ret = 0;
int chp;
- for (chp = 0; chp < 8; chp++)
- ret += sprintf (buf+ret, "%02x ", ssd->chpid[chp]);
-
+ if (ssd)
+ for (chp = 0; chp < 8; chp++)
+ ret += sprintf (buf+ret, "%02x ", ssd->chpid[chp]);
+ else
+ ret += sprintf (buf, "n/a");
ret += sprintf (buf+ret, "\n");
return min((ssize_t)PAGE_SIZE, ret);
}
@@ -529,10 +531,10 @@ static struct attribute_group subch_attr
.attrs = subch_attrs,
};
-int subchannel_add_files (struct device *dev)
-{
- return sysfs_create_group(&dev->kobj, &subch_attr_group);
-}
+struct attribute_group *subch_attr_groups[] = {
+ &subch_attr_group,
+ NULL,
+};
static struct attribute * ccwdev_attrs[] = {
&dev_attr_devtype.attr,
-
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 -mm 2/2] s390: Update cio documentation.
From: Cornelia Huck <[EMAIL PROTECTED]> Update documentation for dynamic subchannel mapping. Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]> --- Documentation/s390/driver-model.txt |7 +++ 1 files changed, 7 insertions(+) --- linux-2.6-CH.orig/Documentation/s390/driver-model.txt +++ linux-2.6-CH/Documentation/s390/driver-model.txt @@ -18,11 +18,18 @@ devices/ - 0.0.0002/ - 0.1./0.1.1234/ ... + - defunct/ In this example, device 0815 is accessed via subchannel 0 in subchannel set 0, device 4711 via subchannel 1 in subchannel set 0, and subchannel 2 is a non-I/O subchannel. Device 1234 is accessed via subchannel 0 in subchannel set 1. +The subchannel named 'defunct' does not represent any real subchannel on the +system; it is a pseudo subchannel where disconnnected ccw devices are moved to +if they are displaced by another ccw device becoming operational on their +former subchannel. The ccw devices will be moved again to a proper subchannel +if they become operational again on that subchannel. + You should address a ccw device via its bus id (e.g. 0.0.4711); the device can be found under bus/ccw/devices/. - 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 -mm 0/2] s390: Updates for dynamic subchannel mapping.
Hi, the following two patches (against 2.6.19-rc6-mm2) contain updates for the s390 common I/O layer on top of s390-dynamic-subchannel-mapping-of-ccw-devices.patch. [1/2] s390: Use dev->groups for subchannel attributes. [2/2] s390: Update cio documentation. -- Cornelia Huck Linux for zSeries Developer Tel.: +49-7031-16-4837, Mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 4/5][AIO] - AIO completion signal notification
On Wed, 29 Nov 2006 10:51:50 +, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> I'm a little bit unhappy about the usage of the notify flag. The usage
> seems correct but very confusing:
Well, I followed the logic from posix-timers.c, but it may be a poor
choice ;-)
For a start, the SIGEV_* flags are quite confusing (for me at least).
SIGEV_SIGNAL is defined as 0, SIGEV_NONE as 1 and SIGEV_THREAD_ID as 4. I
would rather have seen SIGEV_NONE defined as 0 to avoid all this.
I also wish I knew why those SIGEV_* constants were defined that way.
>
> In io_submit_one we set ki_notify.notify to SIGEV_NONE and possibly
> call aio_setup_sigevent:
>
> > + /* handle setting up the sigevent for POSIX AIO signals */
> > + req->ki_notify.notify = SIGEV_NONE;
> > +
> > + if (iocb->aio_sigeventp) {
> > + ret = aio_setup_sigevent(&req->ki_notify,
> > +(struct sigevent __user *)(unsigned
> > long)
> > +iocb->aio_sigeventp);
> > + if (ret)
> > + goto out_put_req;
> > + }
> > +
>
> aio_setup_sigevent then checks the user passed even for which notify type
> we have, and returns if it's none or otherwise sets notify->notify to it.
>
> > + if (event.sigev_notify == SIGEV_NONE)
> > + return 0;
> > +
> > + notify->notify = event.sigev_notify;
>
> Later aio_setup_sigevent gets a reference to the target task_structure
> if notify->notify is (SIGEV_SIGNAL|SIGEV_THREAD_ID) but _always_ stores
> the target pointer.
Yep, as SIGEV_SIGNAL is 0, this in fact checks that notify is SIGEV_THREAD_ID.
It could have been written as:
if (notify->notify == SIGEV_THREAD_ID)
And the target pointer is always store because at this point notify is either
SIGEV_SIGNAL or SIGEV_THREAD_ID.
>
> > + if (notify->notify == (SIGEV_SIGNAL|SIGEV_THREAD_ID)) {
> > + /*
> > +* This reference will be dropped in really_put_req() when
> > +* we're done with the request.
> > +*/
> > + get_task_struct(target);
> > + }
> > +
> > + notify->target = target;
>
>
> Once we're done with the iocb aio_complete aclls aio_send_signal if
> notify.notify is not SIGEV_NONE.
Again, if it's not SIGEV_NONE, then it's either SIGEV_SIGNAL or
SIGEV_THREAD_ID.
>
> > + if (iocb->ki_notify.notify != SIGEV_NONE) {
> > + ret = aio_send_signal(&iocb->ki_notify);
> > +
> > + /* If signal generation failed, release the sigqueue */
> > + if (ret)
> > + sigqueue_free(iocb->ki_notify.sigq);
> > + }
> > +
>
> Which then uses notify->target to send the signal:
> > + if (notify->notify & SIGEV_THREAD_ID)
> > + ret = send_sigqueue(notify->signo, sigq, notify->target);
> > + else
> > + ret = send_group_sigqueue(notify->signo, sigq, notify->target);
>
> And finally really_put_req puts the target if notify.notify contains
> either SIGEV_SIGNAL or SIGEV_THREAD_ID.
>
> > + /* Release task ref */
> > + if (req->ki_notify.notify == (SIGEV_SIGNAL|SIGEV_THREAD_ID))
> > + put_task_struct(req->ki_notify.target);
Could have been if (req->ki_notify.notify == SIGEV_THREAD_ID)
>
> Do you see the confusing? I think all the notify.notify != SIGEV_NONE
> in the above code should be replaces by the much more descriptive
> notify.notify == (SIGEV_SIGNAL|SIGEV_THREAD_ID). In addition we should
> only store the target pointer inside the (SIGEV_SIGNAL|SIGEV_THREAD_ID)
> if block that gets a reference to it.
No, I don't think so, notify == (SIGEV_SIGNAL|SIGEV_THREAD_ID) really means
notify == SIGEV_THREAD_ID which leaves out notify == SIGEV_SIGNAL. Or
am I grossly mistaken?
Thanks,
Sébastien.
> -
> 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/
-
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] devices.txt - LANANA merge
> > +258 block ROM/Flash read-only translation layer > > + 0 = /dev/blockrom0First ROM card's > translation layer interface > > + 1 = /dev/blockrom0Second ROM card's > translation layer interface > ^^^ > > Shouldn't here be '1', ie, /dev/blockrom1 ? > Good catch. I also just added another patch fixing spelling on lanana.org. I'll let this email circulate until tomorrow and then send another patch if nothing else comes in. Thanks, Torben - 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] use probe_kernel_address in Dwarf2 unwinder
On Wednesday 29 November 2006 12:14, Jan Beulich wrote: > Use probe_kernel_address() instead of __get_user() in Dwarf2 unwinder. I had already done this here. Thanks. -Andi - 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] more sanity checks in Dwarf2 unwinder
On Wednesday 29 November 2006 12:13, Jan Beulich wrote:
> Tighten the requirements on both input to and output from the Dwarf2
> unwinder.
Thanks for doing this.
> while (unwind(info) == 0 && UNW_PC(info)) {
> n++;
> oad->ops->address(oad->data, UNW_PC(info));
> if (arch_unw_user_mode(info))
> break;
> + if ((sp & ~(PAGE_SIZE - 1)) == (UNW_SP(info) & ~(PAGE_SIZE - 1))
> + && sp > UNW_SP(info))
> + break;
Hmm, but that wouldn't catch the case when the SP is completely
corrupted for some reason.
Maybe it would be better to just run a brute force check here like
the old in_exception_stack(). Similar on x86-64.
> + if (UNW_PC(frame) % state.codeAlign
> + || UNW_SP(frame) % sleb128abs(state.dataAlign)
> + || (pc == UNW_PC(frame) && sp == UNW_SP(frame)))
> + return -EIO;
Would it be possible to add printks for the EIOs? We want to know
when dwarf2 is corrupted.
-Andi
-
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/
fs/9p/mux.c(786): remark #593: variable "cb" was set but never used
Hello there, I just tried to compile Linux kernel 2.6.18.3 with the Intel C C compiler. The compiler said fs/9p/mux.c(786): remark #593: variable "cb" was set but never used The source code is v9fs_mux_req_callback cb; I have checked the source code and I agree with the compiler. Suggest delete local variable. Regards David Binderman _ Download the new Windows Live Toolbar, including Desktop search! http://toolbar.live.com/?mkt=en-gb - 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/
fs/9p/vfs_inode.c(406): remark #593: variable "sb" was set but never used
Hello there, I just tried to compile Linux kernel 2.6.18.3 with the Intel C C compiler. The compiler said 1. fs/9p/vfs_inode.c(406): remark #593: variable "sb" was set but never used The source code is struct super_block *sb = NULL; I have checked the source code and I agree with the compiler. Suggest delete local variable. 2. fs/9p/vfs_inode.c(757): remark #593: variable "olddirfidnum" was set but never used fs/9p/vfs_inode.c(758): remark #593: variable "newdirfidnum" was set but never used More of the same. Regards David Binderman _ Find Singles In Your Area Now With Match.com! msnuk.match.com - 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.19-rc6-rt8
Am Mittwoch, 29. November 2006 08:06 schrieb Ingo Molnar: > * Karsten Wiese <[EMAIL PROTECTED]> wrote: > > After estimated 15 minutes more it bugged again. > > Related dmesg translates to linux error > > -EXDEV > > propably caused by the following lines: > > > > > > static int uhci_result_isochronous(struct uhci_hcd *uhci, struct > > urb *urb) > > hm. Below are all the USB changes done by -rt. Maybe one of them has > some side-effect? On rc6-rt5 rt-audio with usb-sound runs just fine so far, and I didn't find any USB changes between rc6-rt5 and rc6-rt8. Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 4/5][AIO] - AIO completion signal notification
On Wed, 29 Nov 2006 06:33:35 -0500, Jakub Jelinek <[EMAIL PROTECTED]> wrote: > On Wed, Nov 29, 2006 at 11:33:01AM +0100, S?bastien Dugu? wrote: > > AIO completion signal notification > > > > The current 2.6 kernel does not support notification of user space via > > an RT signal upon an asynchronous IO completion. The POSIX specification > > states that when an AIO request completes, a signal can be delivered to > > the application as notification. > > > > This patch adds a struct sigevent *aio_sigeventp to the iocb. > > The relevant fields (pid, signal number and value) are stored in the kiocb > > for use when the request completes. > > > > That sigevent structure is filled by the application as part of the AIO > > request preparation. Upon request completion, the kernel notifies the > > application using those sigevent parameters. If SIGEV_NONE has been > > specified, > > then the old behaviour is retained and the application must rely on polling > > the completion queue using io_getevents(). > > Well, from what I see applications must rely on polling the completion > queue using io_getevents() in any case, isn't that the only way how to free > the kernel resources associated with the AIO request, even if it uses > SIGEV_SIGNAL or thread notification? Well, applications do not need to do any polling on the queue anymore. io_getevents() needs to be called only once when the signal has been received, either from a signal handler or from a thread blocking on the signal. > aio_error/aio_return/aio_suspend > will still need to io_getevents, Right, but only once. > the only important difference with this > patch is that a) the polling doesn't need to be asynchronous (i.e. have > a special thread which just loops doing io_getevents) Yes, no more polling loop and I think this makes a big difference. > b) it doesn't need to care about notification itself. > Uh! what do you mean here? Sébastien. - 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/
TCP checksum change in RPC replies within XEN, NFS lockup (SLES10)
Hello,
my apologies for not being sure whom to tell this problem, but it is very
strange.
Let me tell the story:
I'm using XEN (3.0.2) with SLES10 (x86_64, SunFire X4100). On one machine I
have
three virtual machines ("DomU") that are very identically configured (SLES10
x86_64 also). There is also a SLES9 (i386) acting as a multi-homed NFS server.
I can mount and access a read-only NFS filesystem on the server from Dom0
(hypervisor), and from two of the three DomUs without any problem, but from the
third DomU mount hangs and is unkillable (except kill -9). This is how I
started
to debug the problem.
To make things short: I haven't found the solution, but a some problems:
Running
tcpdump/etheral on the client (inside DomU), and on the NFS server, I found out
that a significant number (almost all) of RPC reply packets have an invalid TCP
cjhecksum on the NFS server, but not on the NFS client. When actually comparing
the packets, I found that only the checksum is different. Example:
--- nfs-client9.txt 2006-11-29 12:56:59.176133729 +0100
+++ nfs-server8.txt 2006-11-29 12:56:25.812623453 +0100
@@ -1,10 +1,10 @@
No. TimeSourceDestination Protocol
Info
- 9 15:10:15.488963 132.199.176.153 132.199.177.13Portmap
V2
DUMP Reply (Call In 7)[Unreassembled Packet]
+ 8 15:10:15.497059 132.199.176.153 132.199.177.13Portmap
V2
DUMP Reply (Call In 6)[Unreassembled Packet [incorrect TCP checksum]]
00 16 3e f3 45 0d 00 c0 9f 27 44 a6 08 00 45 00 ..>.E'D...E.
0010 01 c4 d0 3f 40 00 40 06 fd be 84 c7 b0 99 84 c7 [EMAIL
PROTECTED]@.
0020 b1 0d 00 6f 94 48 89 33 9b af 3f e4 5a 65 80 18 ...o.H.3..?.Ze..
-0030 16 a0 27 8a 00 00 01 01 08 0a 5a a1 4b 92 01 2f ..'...Z.K../
+0030 16 a0 6c ec 00 00 01 01 08 0a 5a a1 4b 92 01 2f ..l...Z.K../
0040 a9 da 00 00 01 8c 65 e9 c4 df 00 00 00 01 00 00 ..e.
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060 00 01 00 01 86 a0 00 00 00 02 00 00 00 06 00 00
I' NOT saysing that _all_ TCP checksums are bad, but significantly those RPC
reply
packets seem to be affected. OK so far.
I don't know why the NFS mount is actually hanging, but the last packet
exchange
seems to be:
Server sends ACK to RPC reply with bad checksum:
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 1023 (1023),
Seq:
2306928188, Ack: 1069064470, Len: 0
Client receives:
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 1023 (1023),
Seq:
2306928188, Ack: 1069064470, Len: 0
Some time later I see the client sending an NFS GETATTR packet, but that's
probably when the kill came in (31 seconds later).
The other odd thing is that the multihomes NFS server has a route to
132.199.0.0
for both ethernet interfaces, but only one of those, eth0, has IP
132.199.176.153.
However when an ARP request is sent for 132.199.176.153, there are two ansers:
ARP 132.199.176.153 is at 00:c0:9f:27:44:a6
ARP 132.199.176.153 is at 00:02:b3:d9:91:a7
Only the first one is correct. However that problem may be unrelated.
Back to the issue, I doubt that XEN will just overwrite the TCP checksum of
some
specific RPC packets. Personally I could image is much more that there is some
problem in the RPC processing that might cause this. Sorry for the poor problem
description.
Just in case, the Novell/SUSE kernel versions are:
Client: 2.6.16.21-0.25-xen
Server: 2.6.5-7.282-default
Upon request I could provide the packet files as well as two PDFs that show the
packet flow.
Regards,
Ulrich
P.S: I'm subscribed to xen-users, but not to the kernel list, so maybe CC: me
for
kernel-list replies. Thanks!
-
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.19-rc6-rt8: alsa xruns
* Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > > > > (japa-4096 |#0): new 17 us maximum-latency wakeup. > > > > ( beagled-3412 |#1): new 19 us maximum-latency wakeup. > > > > ( IRQ 18-1081 |#1): new 26 us maximum-latency wakeup. > > > > ( snd-4040 |#1): new 1107 us maximum-latency wakeup. > > > > (japa-4096 |#0): new 1445 us maximum-latency wakeup. > > > > (japa-4096 |#0): new 2110 us maximum-latency wakeup. > > > > (qjackctl-4038 |#1): new 2328 us maximum-latency wakeup. > > > > (japa-4096 |#0): new 2548 us maximum-latency wakeup. > > > > ( IRQ 18-1081 |#0): new 10291 us maximum-latency wakeup. ok, i reproduced something similar on one of my boxes and it turned out to be a tracer bug. I've uploaded -rt10, could you try it? (The xruns will likely remain, but at least the tracer should be more usable now to find out the reason for the xruns.) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 4/5][AIO] - AIO completion signal notification
On Wed, Nov 29, 2006 at 02:08:01PM +0100, S?bastien Dugu? wrote:
> On Wed, 29 Nov 2006 10:51:50 +, Christoph Hellwig <[EMAIL PROTECTED]>
> wrote:
>
> > I'm a little bit unhappy about the usage of the notify flag. The usage
> > seems correct but very confusing:
>
> Well, I followed the logic from posix-timers.c, but it may be a poor
> choice ;-)
>
> For a start, the SIGEV_* flags are quite confusing (for me at least).
> SIGEV_SIGNAL is defined as 0, SIGEV_NONE as 1 and SIGEV_THREAD_ID as 4. I
> would rather have seen SIGEV_NONE defined as 0 to avoid all this.
>
> I also wish I knew why those SIGEV_* constants were defined that way.
Ah, I missed that. It explains some of the more wierd bits. I suspect
we should then use != SIGEV_NONE for the any kind of signal notification
bit and == SIGEV_THREAD_ID for the case where we want to deliver to
a particular thread.
But this means we only get a thread reference for SIGEV_THREAD_ID
here:
> > > + if (notify->notify == (SIGEV_SIGNAL|SIGEV_THREAD_ID)) {
> > > + /*
> > > + * This reference will be dropped in really_put_req() when
> > > + * we're done with the request.
> > > + */
> > > + get_task_struct(target);
> > > + }
But even use it for SIGEV_SIGNAL without SIGEV_THREAD_ID here:
> > > + if (notify->notify & SIGEV_THREAD_ID)
> > > + ret = send_sigqueue(notify->signo, sigq, notify->target);
> > > + else
> > > + ret = send_group_sigqueue(notify->signo, sigq, notify->target);
Or do I miss something?
-
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: Help for kernel module programming
>> I am writing a kernel module for assging an ip address to an interface. >> I have included linux/igmp.h but still whenever i use the function > >...What function? > >> declared in igmp.h file, it says unresolved symbol for that function. > >...What symbol? > >> I am new to this programming. >> i use the following command to compile it: >> gcc -c -D__KERNEL__ -DMODULE >> -I/home/newkernelsource/linux-2.4.22/include hello.c > >Please read the files in Documentation/kbuild/. Sorry, was not seeing you use 2.4.x. But the procedure is similar, e.g. http://ttyrpld.svn.sourceforge.net/viewvc/ttyrpld/trunk/k_linux-2.4/Makefile?revision=2&view=markup -`J' -- - 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] more sanity checks in Dwarf2 unwinder
>> while (unwind(info) == 0 && UNW_PC(info)) {
>> n++;
>> oad->ops->address(oad->data, UNW_PC(info));
>> if (arch_unw_user_mode(info))
>> break;
>> +if ((sp & ~(PAGE_SIZE - 1)) == (UNW_SP(info) & ~(PAGE_SIZE - 1))
>> +&& sp > UNW_SP(info))
>> +break;
>
>Hmm, but that wouldn't catch the case when the SP is completely
>corrupted for some reason.
>Maybe it would be better to just run a brute force check here like
>the old in_exception_stack(). Similar on x86-64.
Correct. Even though I know Linus disagrees here, I'm not sure
I want to do this, as my ultimate goal would be to eliminate the
hand-crafted linking (which we know got broken a few times on
x86-64, because it's so easy to forget about).
Not the least of the reasons for this is that this increases the
chances of stucks.
>> +if (UNW_PC(frame) % state.codeAlign
>> +|| UNW_SP(frame) % sleb128abs(state.dataAlign)
>> +|| (pc == UNW_PC(frame) && sp == UNW_SP(frame)))
>> +return -EIO;
>
>Would it be possible to add printks for the EIOs? We want to know
>when dwarf2 is corrupted.
Certainly, will be a follow-up patch.
Jan
-
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] use probe_kernel_address in Dwarf2 unwinder
>>> Andi Kleen <[EMAIL PROTECTED]> 29.11.06 14:15 >>> >On Wednesday 29 November 2006 12:14, Jan Beulich wrote: >> Use probe_kernel_address() instead of __get_user() in Dwarf2 unwinder. > >I had already done this here. Thanks. I had checked firstfloor and only found similar changes to arch/x86-64/. Jan - 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: Overriding X on panic
Hi! > >> for the Intel hw Keith doesn't seem to think it's all > >that much of a > >> problem though... > > > >Including the TV out, odder LCD panels, non BIOS modes > >etc ? If so then > >it might be an interesting test case for intelfb to > >grow some kind of > >console helper interface ... > I personally think we need to probably just bite the > bullet and start > sticking graphics drivers into the kernel, the new > randr-1.2 interface > for X is probably a good starting point for a generic > mode setting > interface that isn't so X dependent and could replace > fbdev with > something more sane wrt dualhead and multiple outputs... > fbdev could > be implemented on top of that layer then.. also > suspend/resume really > needs this sort of thing Yes, pretty please... > My main worry with integrating graphics drivers into the > kernel is > that when they don't work the user gets no screen, with > network/sound > etc this isn't so bad, but if they can't see a screen > debugging gets > to be a bit more difficult You can have my hgc card + monitor if it helps :-). Okay, it is old ISA, so it probably does not, but with serial or netconsole debugging should be doable, no? Pavel -- Thanks for all the (sleeping) penguins. - 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.19-rc6-mm2
Avi Kivity wrote:
Oh, and I get a ton of these messages with kvm:
rtc: lost some interrupts at 1024Hz.
I'll look into these too, though I'm not sure where.
Please try the attached patch and let us know.
--
error compiling committee.c: too many arguments to function
Index: linux/drivers/kvm/vmx.c
===
--- linux/drivers/kvm/vmx.c (revision 3989)
+++ linux/drivers/kvm/vmx.c (working copy)
@@ -1163,6 +1163,7 @@
vmcs_writel(VM_EXIT_MSR_LOAD_ADDR,
virt_to_phys(vcpu->host_msrs + NR_BAD_MSRS));
vmcs_write32_fixedbits(MSR_IA32_VMX_EXIT_CTLS_MSR, VM_EXIT_CONTROLS,
+ VM_EXIT_ACK_INTR_ON_EXIT |
(HOST_IS_64 << 9)); /* 22.2,1, 20.7.1 */
vmcs_write32(VM_EXIT_MSR_STORE_COUNT, nr_good_msrs); /* 22.2.2 */
vmcs_write32(VM_EXIT_MSR_LOAD_COUNT, nr_good_msrs); /* 22.2.2 */
@@ -1380,7 +1381,24 @@
static int handle_external_interrupt(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
{
+ unsigned long irq;
+
++kvm_stat.irq_exits;
+ irq = vmcs_read32(VM_EXIT_INTR_INFO) & 0xff;
+ asm volatile (
+ "lea irq_dispatch(%0,%0,2), %0 \n\t"
+ "call *%0 \n\t"
+ "jmp out \n\t"
+ "irq_dispatch: \n\t"
+ "irq = 0 \n\t"
+ ".rept 256 \n\t"
+ " .byte 0xcd, irq \n\t" /* avoid int $3 -- one byte opcode */
+ " ret \n\t"
+ " irq = irq + 1 \n\t"
+ ".endr \n\t"
+ "out:"
+ : "+r"(irq) );
+
return 1;
}
Re: [rfc patch] Re: [patch] PM: suspend/resume debugging should depend on SOFTWARE_SUSPEND
Hi!
> On Wed, 2006-11-29 at 11:21 +0100, Mike Galbraith wrote:
> > > The serial console appears to be innocent. The suspend/resume methods
> > > for my 16550A serial port aren't even being _called_, apparently because
> > > pnp swiped ttyS0.
>
> (ahem, bad aim with mouse, resuming)
>
> Well, after further rummaging, the suspend/resume methods aren't being
> called because we're using 8250_pnp.c when CONFIG_PNP is set, and it
> doesn't have any :) The below works for me, though I'm not sure it's
> sufficient. If it is deemed sufficient, I'll submit it to Andrew.
>
> Add suspend/resume methods to 8250_pnp driver.
Patch looks okay to me... care to sign-it-off and submit it to akpm?
Pavel
> --- linux-2.6.19-rc6-mm2/drivers/serial/8250_pnp.c.org2006-11-29
> 07:14:15.0 +0100
> +++ linux-2.6.19-rc6-mm2/drivers/serial/8250_pnp.c2006-11-29
> 10:55:17.0 +0100
> @@ -464,11 +464,38 @@ static void __devexit serial_pnp_remove(
> serial8250_unregister_port(line - 1);
> }
>
> +#ifdef CONFIG_PM
> +static int serial_pnp_suspend(struct pnp_dev *dev, pm_message_t state)
> +{
> + long line = (long)pnp_get_drvdata(dev);
> +
> + if (!line)
> + return -ENODEV;
> + serial8250_suspend_port(line - 1);
> + return 0;
> +}
> +
> +static int serial_pnp_resume(struct pnp_dev *dev)
> +{
> + long line = (long)pnp_get_drvdata(dev);
> +
> + if (!line)
> + return -ENODEV;
> + serial8250_resume_port(line - 1);
> + return 0;
> +}
> +
> +#endif /* CONFIG_PM */
> +
> static struct pnp_driver serial_pnp_driver = {
> .name = "serial",
> - .id_table = pnp_dev_table,
> .probe = serial_pnp_probe,
> .remove = __devexit_p(serial_pnp_remove),
> +#ifdef CONFIG_PM
> + .suspend= serial_pnp_suspend,
> + .resume = serial_pnp_resume,
> +#endif
> + .id_table = pnp_dev_table,
> };
>
> static int __init serial8250_pnp_init(void)
>
>
>
>
>
--
Thanks for all the (sleeping) penguins.
-
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/
make oldconfig problem Re: autoconf.h and auto.conf missing
On Mon, 2006-11-27 at 23:47 +0100, Lukasz Stelmach wrote: > Greetings. > > It seems that someone has broken *conf programs in 2.6.18 because > only "make silentoldconfig" recreates autoconf.h and auto.conf > properly after configuration (.config) has changed. > > I do everything as I always have done. > 1. create an empty dir and put my current .config there > 2. make O=dir oldconfig > 3. compile, everything seems to be OK here > 4. do some changes to .config and make oldconfig once again > BZT yap I have the same problem to workaround I just do make xconfig and click on save. I like to have some more input about this Thanks, > 5. auto.conf and autoconf.h don't change along with .config and when > I build the kernel once again new settings don't take effect. > > I discovered I have to make silentoldconfig to regenerate autoconf > files. However, this *seems* to force rebuilding of all the objects > instead of, what it has always done, only those that depend on > altered configurations. > > Has anyone else seen something like this? Is it a bug or a feature? > > Best regards, > > Please CC, I am not a subscriber. - 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] use probe_kernel_address in Dwarf2 unwinder
On Wednesday 29 November 2006 15:02, Jan Beulich wrote: > >>> Andi Kleen <[EMAIL PROTECTED]> 29.11.06 14:15 >>> > >On Wednesday 29 November 2006 12:14, Jan Beulich wrote: > >> Use probe_kernel_address() instead of __get_user() in Dwarf2 unwinder. > > > >I had already done this here. Thanks. > > I had checked firstfloor and only found similar changes to arch/x86-64/. Sorry I hadn't pushed the changes out yet (did it last night) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 4/5][AIO] - AIO completion signal notification
On Wed, 29 Nov 2006 13:50:12 +, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 29, 2006 at 02:08:01PM +0100, S?bastien Dugu? wrote:
> > On Wed, 29 Nov 2006 10:51:50 +, Christoph Hellwig <[EMAIL PROTECTED]>
> > wrote:
> >
> > > I'm a little bit unhappy about the usage of the notify flag. The usage
> > > seems correct but very confusing:
> >
> > Well, I followed the logic from posix-timers.c, but it may be a poor
> > choice ;-)
> >
> > For a start, the SIGEV_* flags are quite confusing (for me at least).
> > SIGEV_SIGNAL is defined as 0, SIGEV_NONE as 1 and SIGEV_THREAD_ID as 4. I
> > would rather have seen SIGEV_NONE defined as 0 to avoid all this.
> >
> > I also wish I knew why those SIGEV_* constants were defined that way.
>
> Ah, I missed that. It explains some of the more wierd bits. I suspect
> we should then use != SIGEV_NONE for the any kind of signal notification
> bit and == SIGEV_THREAD_ID for the case where we want to deliver to
> a particular thread.
Right, that would make things much cleaner. Will try for it.
>
> But this means we only get a thread reference for SIGEV_THREAD_ID
> here:
>
> > > > + if (notify->notify == (SIGEV_SIGNAL|SIGEV_THREAD_ID)) {
> > > > + /*
> > > > +* This reference will be dropped in really_put_req()
> > > > when
> > > > +* we're done with the request.
> > > > +*/
> > > > + get_task_struct(target);
> > > > + }
It's the way it is in posix-timers and I'm not sure I understand why. We take
a ref on the specific task if notify is SIGEV_THREAD_ID but not for
SIGEV_SIGNAL.
I'm wondering what I'm missing here, shouldn't we also take a ref on the task
group leader in the SIGEV_SIGNAL case in posix-timers?
>
> But even use it for SIGEV_SIGNAL without SIGEV_THREAD_ID here:
>
> > > > + if (notify->notify & SIGEV_THREAD_ID)
> > > > + ret = send_sigqueue(notify->signo, sigq,
> > > > notify->target);
> > > > + else
> > > > + ret = send_group_sigqueue(notify->signo, sigq,
> > > > notify->target);
>
> Or do I miss something?
I missing something too here ;-)
If someone cared to explain why there is no ref taken on the task for the
SIGEV_SIGNAL case, it would be much appreciated. Is this a bug in posix-timers?
Thanks,
Sébastien.
-
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: fs/9p/vfs_inode.c(406): remark #593: variable "sb" was set but never used
On 11/29/06, d binderman <[EMAIL PROTECTED]> wrote: Hello there, I just tried to compile Linux kernel 2.6.18.3 with the Intel C C compiler. The compiler said 1. fs/9p/vfs_inode.c(406): remark #593: variable "sb" was set but never used The source code is struct super_block *sb = NULL; I have checked the source code and I agree with the compiler. Suggest delete local variable. 2. fs/9p/vfs_inode.c(757): remark #593: variable "olddirfidnum" was set but never used fs/9p/vfs_inode.c(758): remark #593: variable "newdirfidnum" was set but never used Please, upload full list of these warnings somewhere and post URL. - 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/
O_DIRECT error, user space programming
Hi, I got an: *** glibc detected *** double free or corruption (!prev): 0x84c01000 *** using O_DIRECT with threads: this error appends if I run several threads wich are reading several files (opened with O_RDONLY|O_DIRECT) at the same time. The error doesn't appends if I open the files whithout O_DIRECT or if I place a pthread_join after each thread call. I'm sure that no double free is done. kernel version: 2.6.17 SMP PREEMPT glibc version: 2.3.6 filesystem: ext3 g++ used: g++ (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3) Does somebody knows the reasons of the error? There are limitation to use O_DIRECT on a multithread application? Thanks in advance for any help. A. ps. I can provide the source code code (135 lines of C++) if it is useful to uinderstand better the problem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 3/5][AIO] - export good_sigevent()
> +/***
> + * good_sigevent - check and get target task from a sigevent.
> + * @event: the sigevent to be checked
> + *
> + * This function must be called with tasklist_lock held for reading.
> + */
> +struct task_struct * good_sigevent(sigevent_t * event)
> +{
> + struct task_struct *rtn = current->group_leader;
> +
> + if ((event->sigev_notify & SIGEV_THREAD_ID ) &&
> + (!(rtn = find_task_by_pid(event->sigev_notify_thread_id)) ||
> + rtn->tgid != current->tgid ||
> + (event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_SIGNAL))
> + return NULL;
> +
> + if (((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) &&
> + ((event->sigev_signo <= 0) || (event->sigev_signo > SIGRTMAX)))
> + return NULL;
> +
> + return rtn;
> +}
And while we're at it we should badly beat up the person that wrote this
mess in the first time. To be somewhat readable it should look like:
static struct task_struct *good_sigevent(sigevent_t *event)
{
struct task_struct *task = current->group_leader;
if ((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) {
if (event->sigev_signo <= 0 || event->sigev_signo > SIGRTMAX)
return NULL;
}
if (event->sigev_notify & SIGEV_THREAD_ID) {
if ((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_SIGNAL)
return NULL;
task = find_task_by_pid(event->sigev_notify_thread_id);
if (!task || task->tgid != current->tgid)
return NULL;
}
return task;
}
And btw, looking at its currentl caller I see why we need the PF_EXITING
flag I recommended to remove easiler on, it even has a big comment that
we should copy & paste to aio.c aswell. Still no idea why it's doing
the selectiv reference grabbing, though.
-
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.16-rc6-mm2 patch] make 8250_pnp serial driver work after suspend to ram
Add suspend/resume methods to drivers/serial/8250_pnp.c. Tested on a
P4/HT 16550A box, ttyS0 login survives across suspend to ram.
Signed-off-by: Mike Galbraith <[EMAIL PROTECTED]>
--- linux-2.6.19-rc6-mm2/drivers/serial/8250_pnp.c.org 2006-11-29
07:14:15.0 +0100
+++ linux-2.6.19-rc6-mm2/drivers/serial/8250_pnp.c 2006-11-29
10:55:17.0 +0100
@@ -464,11 +464,38 @@ static void __devexit serial_pnp_remove(
serial8250_unregister_port(line - 1);
}
+#ifdef CONFIG_PM
+static int serial_pnp_suspend(struct pnp_dev *dev, pm_message_t state)
+{
+ long line = (long)pnp_get_drvdata(dev);
+
+ if (!line)
+ return -ENODEV;
+ serial8250_suspend_port(line - 1);
+ return 0;
+}
+
+static int serial_pnp_resume(struct pnp_dev *dev)
+{
+ long line = (long)pnp_get_drvdata(dev);
+
+ if (!line)
+ return -ENODEV;
+ serial8250_resume_port(line - 1);
+ return 0;
+}
+
+#endif /* CONFIG_PM */
+
static struct pnp_driver serial_pnp_driver = {
.name = "serial",
- .id_table = pnp_dev_table,
.probe = serial_pnp_probe,
.remove = __devexit_p(serial_pnp_remove),
+#ifdef CONFIG_PM
+ .suspend= serial_pnp_suspend,
+ .resume = serial_pnp_resume,
+#endif
+ .id_table = pnp_dev_table,
};
static int __init serial8250_pnp_init(void)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
CPUFREQ-CPUHOTPLUG: Possible circular locking dependency
Hi all,
Looks like the lockdep has resumed yelling about the cpufreq-cpu hotplug
interactions! Again, it's the Ondemand governor that's the culprit.
On linux-2.6.19-rc6-mm2, this is what I got yesterday evening.
[EMAIL PROTECTED] tests]# echo ondemand >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[EMAIL PROTECTED] tests]# echo 0 > /sys/devices/system/cpu/cpu1/online
===
[ INFO: possible circular locking dependency detected ]
2.6.19-rc6-mm2 #14
---
bash/4601 is trying to acquire lock:
(&policy->lock){--..}, at: [] mutex_lock+0x12/0x15
but task is already holding lock:
(cache_chain_mutex){--..}, at: [] mutex_lock+0x12/0x15
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (cache_chain_mutex){--..}:
[] __lock_acquire+0x8ef/0x9f3
[] lock_acquire+0x68/0x82
[] __mutex_lock_slowpath+0xd3/0x224
[] mutex_lock+0x12/0x15
[] cpuup_callback+0x1a3/0x2d6
[] notifier_call_chain+0x2b/0x5b
[] __raw_notifier_call_chain+0x18/0x1d
[] raw_notifier_call_chain+0x1a/0x1c
[] _cpu_down+0x56/0x1ef
[] cpu_down+0x26/0x3a
[] store_online+0x27/0x5a
[] sysdev_store+0x20/0x25
[] sysfs_write_file+0xb6/0xde
[] vfs_write+0x90/0x144
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5f/0x99
[] 0x
-> #2 (workqueue_mutex){--..}:
[] __lock_acquire+0x8ef/0x9f3
[] lock_acquire+0x68/0x82
[] __mutex_lock_slowpath+0xd3/0x224
[] mutex_lock+0x12/0x15
[] __create_workqueue+0x5b/0x11c
[] cpufreq_governor_dbs+0xa0/0x2e8
[] __cpufreq_governor+0x64/0xac
[] __cpufreq_set_policy+0x187/0x20b
[] store_scaling_governor+0x132/0x16a
[] store+0x35/0x46
[] sysfs_write_file+0xb6/0xde
[] vfs_write+0x90/0x144
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5f/0x99
[] 0x
-> #1 (dbs_mutex){--..}:
[] __lock_acquire+0x8ef/0x9f3
[] lock_acquire+0x68/0x82
[] __mutex_lock_slowpath+0xd3/0x224
[] mutex_lock+0x12/0x15
[] cpufreq_governor_dbs+0x84/0x2e8
[] __cpufreq_governor+0x64/0xac
[] __cpufreq_set_policy+0x187/0x20b
[] store_scaling_governor+0x132/0x16a
[] store+0x35/0x46
[] sysfs_write_file+0xb6/0xde
[] vfs_write+0x90/0x144
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5f/0x99
[] 0x
-> #0 (&policy->lock){--..}:
[] __lock_acquire+0x7f3/0x9f3
[] lock_acquire+0x68/0x82
[] __mutex_lock_slowpath+0xd3/0x224
[] mutex_lock+0x12/0x15
[] cpufreq_driver_target+0x2b/0x51
[] cpufreq_cpu_callback+0x42/0x52
[] notifier_call_chain+0x2b/0x5b
[] __raw_notifier_call_chain+0x18/0x1d
[] raw_notifier_call_chain+0x1a/0x1c
[] _cpu_down+0x56/0x1ef
[] cpu_down+0x26/0x3a
[] store_online+0x27/0x5a
[] sysdev_store+0x20/0x25
[] sysfs_write_file+0xb6/0xde
[] vfs_write+0x90/0x144
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5f/0x99
[] 0x
other info that might help us debug this:
4 locks held by bash/4601:
#0: (cpu_add_remove_lock){--..}, at: [] mutex_lock+0x12/0x15
#1: (sched_hotcpu_mutex){--..}, at: [] mutex_lock+0x12/0x15
#2: (workqueue_mutex){--..}, at: [] mutex_lock+0x12/0x15
#3: (cache_chain_mutex){--..}, at: [] mutex_lock+0x12/0x15
stack backtrace:
[] show_trace_log_lvl+0x19/0x2e
[] show_trace+0x12/0x14
[] dump_stack+0x14/0x16
[] print_circular_bug_tail+0x7c/0x85
[] __lock_acquire+0x7f3/0x9f3
[] lock_acquire+0x68/0x82
[] __mutex_lock_slowpath+0xd3/0x224
[] mutex_lock+0x12/0x15
[] cpufreq_driver_target+0x2b/0x51
[] cpufreq_cpu_callback+0x42/0x52
[] notifier_call_chain+0x2b/0x5b
[] __raw_notifier_call_chain+0x18/0x1d
[] raw_notifier_call_chain+0x1a/0x1c
[] _cpu_down+0x56/0x1ef
[] cpu_down+0x26/0x3a
[] store_online+0x27/0x5a
[] sysdev_store+0x20/0x25
[] sysfs_write_file+0xb6/0xde
[] vfs_write+0x90/0x144
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5f/0x99
===
Breaking affinity for irq 24
CPU 1 is now offline
Ok, so to cut the long story short,
- While changing governor from anything to
ondemand, locks are taken in the following order
policy->lock ===> dbs_mutex ===> workqueue_mutex.
- While offlining a cpu, locks are taken in the following order
cpu_add_remove_lock ==> sched_hotcpu_mutex ==> workqueue_mutex ==
==> cache_chain_mutex ==> policy->lock.
The dependency graph built out of this info has a circular dependency
as pointed out by lockdep. However, I am not quite sure how seriously this
circular dependency warning should be taken.
One way to avoid these warnings is to take the policy->lock before the
rest of the locks, while offlining the cpu.
For a moment I even thought of taking/releasing pol
Using poll for sysfs attribute files
Hi all, I'm looking for a way to implement polling for sysfs attribute files. There seem to be sysfs_poll API but I have no idea how to use it correctly. Any hint, example of usage or comment wold be deeply appreciated. -- Sincerely, Vladimir "Farcaller" Pouzanov - 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.16.32 stuck in generic_file_aio_write()
Hi, A followup. It crashed again, giving me : arcmsr0: scsi id=0 lun=0 ccb='0xf7c984e0' poll command abort successfully end_request: I/O error, dev sda, sector 3724719 and sd 0:0:0:0: rejecting I/O to offline device about 15k times. I'll see if I can upgrade the RAID driver. Igmar -- Igmar Palsenberg JDI ICT Zutphensestraatweg 85 6953 CJ Dieren Tel: +31 (0)313 - 496741 Fax: +31 (0)313 - 420996 The Netherlands mailto: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 3/5][AIO] - export good_sigevent()
On Wed, 29 Nov 2006 14:54:25 +, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > +/***
> > + * good_sigevent - check and get target task from a sigevent.
> > + * @event: the sigevent to be checked
> > + *
> > + * This function must be called with tasklist_lock held for reading.
> > + */
> > +struct task_struct * good_sigevent(sigevent_t * event)
> > +{
> > + struct task_struct *rtn = current->group_leader;
> > +
> > + if ((event->sigev_notify & SIGEV_THREAD_ID ) &&
> > + (!(rtn = find_task_by_pid(event->sigev_notify_thread_id)) ||
> > +rtn->tgid != current->tgid ||
> > +(event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_SIGNAL))
> > + return NULL;
> > +
> > + if (((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) &&
> > + ((event->sigev_signo <= 0) || (event->sigev_signo > SIGRTMAX)))
> > + return NULL;
> > +
> > + return rtn;
> > +}
>
> And while we're at it we should badly beat up the person that wrote this
> mess in the first time.
Agreed.
> To be somewhat readable it should look like:
>
> static struct task_struct *good_sigevent(sigevent_t *event)
> {
> struct task_struct *task = current->group_leader;
>
> if ((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) {
> if (event->sigev_signo <= 0 || event->sigev_signo > SIGRTMAX)
> return NULL;
> }
>
> if (event->sigev_notify & SIGEV_THREAD_ID) {
> if ((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_SIGNAL)
> return NULL;
> task = find_task_by_pid(event->sigev_notify_thread_id);
> if (!task || task->tgid != current->tgid)
> return NULL;
> }
>
> return task;
> }
Yes, will incorporate this.
>
> And btw, looking at its currentl caller I see why we need the PF_EXITING
> flag I recommended to remove easiler on, it even has a big comment that
> we should copy & paste to aio.c aswell.
Well, I do not take the siglock anymore, so I don't think the comment
really applies here.
> Still no idea why it's doing
> the selectiv reference grabbing, though.
-
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: Slab: Remove kmem_cache_t
On Wed, 29 Nov 2006, Nick Piggin wrote:
>
> You are saying that they should only be used to create new "primitive"
> types (ie. that you can use in arithmetic / logical ops) that can
> change depending on the config.
Well, it doesn't have to be something that is "arithmetic".
For an example of a primitive type that isn't arithmetic, the page table
entries are (pgt_t/pud_t/pmd_t/pte_t) are excellent - they don't do any
arithmetic or logical ops, but they do change depending on config, and no,
they aren't always opaque structures.
(Actually, these days they mostly are, but on many architectures it's much
slower to pass even a small struct around than it is to pass an integer
around - due simply to calling conventions - so for truly opaque things,
the typedef has the advantage that it _can_ be an opaque integer type, and
nobody will notice).
> That's fair enough. I'm sure you've also said in the past that they can
> be used (IIRC you even encouraged it) when the type is opaque in the
> context it is being used.
I'm sure I've been inconsistent, but in general, typedefs are bad. I think
you'll notice that I almost never use them myself. I much prefer passing
an opaque structure around, _unless_ I know the structure is so small that
it makes sense to do the above optimization (ie allow the case where the
opaque thing actually ends up being an integer).
Opaque integer types are generally useless in C, because they lose all the
type information _way_ too easily. There are no warnings for mis-use,
unless you use a sparse "bitwise" type and actually run sparse on the
thing. So even when there are performance reasons to use opaque integer
types (and on x86, the page table things were one such thing), usign a
struct is often preferable just for type-checking.
And as mentioned, there _are_ exceptions. Some types just get _sooo_
complex that it's inconvenient to type them out, even if they are
perfectly regular types, and don't depend on any config option. The
"filldir_t" typedef in fs.h is such an example - it's not really opaque,
_nor_ is it a config option, but it sure as hell would be inconvenient for
all low-level filesystems to do
int my_readdir(struct file *filp, void *dirent,
int (*filldir)(void *, const char *, int, loff_t,
u64, unsigned))
{
...
}
because let's face it, having to write out that "filldir" type just made
me use two lines (and potential for totally unnecessary tupos) because the
thing was so complex. So at that point, using a typedef is just common
sense, and we can do
int my_readdir(struct file *filp, void *dirent, filldir_t filldir)
{
...
}
instead.
But it's really quite hard to make that kind of complex type in C. It's
almost always a function pointer that takes complex arguments.
[ That said, I generally won't _complain_ if people use typedefs, but on
the other hand, some people definitely are too eager to do it, and I'll
happily remove them if people send me a patch. For example, we used to
have "task_t" for "struct task_struct", and that was just _unnecessary_,
and made it just harder to pick out what it was. Sometimes long names
and the explicit "struct" is a _good_ thing. ]
One final thing: for _small_ structures, typedefs are much better than for
large ones. Why? Because of stack usage. I want people to really _think_
about local variable sizes, and that's one thing that a typedef sometimes
causes - especially if it's opaque, so that users don't have any "handle"
on whether it is big or small, it's really nasty to use them for automatic
storage on the stack, because you may simply blow your stack usage on a
single (or a couple) of structures.
Making things be "struct something_or_other" makes at least _me_ think
more about it than if it's "file_t". Maybe it's just me, but I immediately
think "complex structure" when I see "struct", but "file_t" to me mentally
says "single word".
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] char: drivers use/need PCI
Jiri Slaby wrote: Randy Dunlap wrote: From: Randy Dunlap <[EMAIL PROTECTED]> With CONFIG_PCI=n: drivers/char/mxser_new.c: In function 'mxser_release_res': drivers/char/mxser_new.c:2383: warning: implicit declaration of function 'pci_release_region' drivers/char/mxser_new.c: In function 'mxser_probe': drivers/char/mxser_new.c:2578: warning: implicit declaration of function 'pci_request_region' drivers/built-in.o: In function `sx_remove_card': sx.c:(.text.sx_remove_card+0x65): undefined reference to `pci_release_region' drivers/char/isicom.c: In function 'isicom_probe': drivers/char/isicom.c:1793: warning: implicit declaration of function 'pci_request_region' drivers/char/isicom.c:1827: warning: implicit declaration of function 'pci_release_region' Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- drivers/char/Kconfig |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- linux-2.6.19-rc6-mm2.orig/drivers/char/Kconfig +++ linux-2.6.19-rc6-mm2/drivers/char/Kconfig @@ -203,7 +203,7 @@ config MOXA_SMARTIO config MOXA_SMARTIO_NEW tristate "Moxa SmartIO support v. 2.0 (EXPERIMENTAL)" - depends on SERIAL_NONSTANDARD + depends on SERIAL_NONSTANDARD && PCI help Say Y here if you have a Moxa SmartIO multiport serial card and/or want to help develop a new version of this driver. @@ -218,7 +218,7 @@ config MOXA_SMARTIO_NEW config ISI tristate "Multi-Tech multiport card support (EXPERIMENTAL)" - depends on SERIAL_NONSTANDARD + depends on SERIAL_NONSTANDARD && PCI select FW_LOADER help This is a driver for the Multi-Tech cards which provide several @@ -312,7 +312,7 @@ config SPECIALIX_RTSCTS config SX tristate "Specialix SX (and SI) card support" - depends on SERIAL_NONSTANDARD + depends on SERIAL_NONSTANDARD && PCI help This is a driver for the SX and SI multiport serial cards. Please read the file for details. Nack. I have to correct the mxser and sx code. Thanks, Sure, either way is OK. Thanks. -- ~Randy - 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/
