RE: libata-dev queue updated
Hi Jeff, 2.6.13- rc7-libata1.patch.bz2 was used. A combined mode of ata_piix seems not to work. Is the following patches correct? diff -urN linux-2.6.13-rc7.orig/drivers/scsi/Kconfig linux-2.6.13-rc7/drivers/scsi/Kconfig --- linux-2.6.13-rc7.orig/drivers/scsi/Kconfig 2005-08-25 13:44:33.0 +0900 +++ linux-2.6.13-rc7/drivers/scsi/Kconfig 2005-08-25 14:33:38.0 +0900 @@ -424,7 +424,7 @@ source "drivers/scsi/megaraid/Kconfig.megaraid" config SCSI_SATA - tristate "Serial ATA (SATA) support" + bool "Serial ATA (SATA) support" depends on SCSI help This driver family supports Serial ATA host controllers -- Haruo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12 Performance problems
Danial Thom wrote: --- Ben Greear <[EMAIL PROTECTED]> wrote: Danial Thom wrote: I think the concensus is that 2.6 has made trade offs that lower raw throughput, which is what a networking device needs. So as a router or network appliance, 2.6 seems less suitable. A raw bridging test on a 2.0Ghz operton system: FreeBSD 4.9: Drops no packets at 900K pps Linux 2.4.24: Starts dropping packets at 350K pps Linux 2.6.12: Starts dropping packets at 100K pps I ran some quick tests using kernel 2.6.11, 1ms tick (HZ=1000), SMP kernel. Hardware is P-IV 3.0Ghz + HT on a new SuperMicro motherboard with 64/133Mhz PCI-X bus. NIC is dual Intel pro/1000. Kernel is close to stock 2.6.11. I used brctl to create a bridge with the two GigE adapters in it and used pktgen to stream traffic through it (250kpps in one direction, 1kpps in the other.) I see a reasonable amount of drops at 250kpps (60 byte packets): about 60,000,000 packets received, 20,700 dropped. I get slightly worse performance on this system when running RH9 with kernel 2.4.29 (my hacks, HZ=1000, SMP). Tried increasing e1000 descriptors to 2048 tx and rx, but that didn't help, or at least not much. Will try some other tunings, but I doubt it will affect performance enough to come close to the discrepency that you show between 2.4 and 2.6 kernels... I tried copying a 500MB CDROM to HD on my RH9 system, and only 6kpps of the 250kpps get through the bridge...btw. Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.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: [RFC] RT-patch update to remove the global pi_lock
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > Well, after turning off hrtimers, I keep getting one bug. A possible > soft lockup with the ext3 code. But this didn't seem to be caused by > the changes I made. So just to be sure, I ran my test on the vanilla > 2.6.13-rc6-rt11 and it gave the same bug too. So, it looks like my > changes are now at par with what is out there with the rt11 release. > They both give the same bug! ;-) does the system truly lock up, or is this some transitional condition? In any case, i agree that this should be debugged independently of the pi_lock patch. 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: [RFC] RT-patch update to remove the global pi_lock
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > So, Ingo, what do you think of the changes so far? Do you feel that > it is stable enough to send you an actual real patch. That way we can > work together in cleaning it up and get all the other kinks out. yeah, please send me a patch against 2.6.13-rc7-rt1 if possible. 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/
2.6.13-rc7-rt1
i have released the 2.6.13-rc7-rt1 tree, which can be downloaded from the usual place: http://redhat.com/~mingo/realtime-preempt/ this is a fixes-only release. Changes since 2.6.13-rc6-rt10: - init_hrtimers() compilation fix (K.R. Foley) - first phase p->pi_lock SMP speedup (Steven Rostedt) - HRT/signals exit fixes (Thomas Gleixner) - change single-signal delivery (used by e.g. HRT) to RCU (Thomas Gleixner) - fix larger-than-5-sec sleeps (Thomas Gleixner) - ALL_TASKS_PI compilation fixes (Daniel Walker) - HRT compilation warning fix (Daniel Walker) - PPC fixes (Thomas Gleixner) - merge to 2.6.13-rc7 - disable old HIGH_RES_TIMERS code in ipmi - sx8.c semaphore -> compat_semaphore - route.c kmalloc-size build fix to build a 2.6.13-rc7-rt1 tree, the following patches should be applied: http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2 http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.13-rc7.bz2 http://redhat.com/~mingo/realtime-preempt/patch-2.6.13-rc7-rt1 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: 2.6.13-rc6-rt9
* Darren Hart <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: > >i have released the 2.6.13-rc6-rt9 tree, which can be downloaded from > >the usual place: > > > > http://redhat.com/~mingo/realtime-preempt/ > > > > I'm looking into getting HRT and RT booting on a SUMMIT NUMA machine > (cyclone timer), but after s/error/warning/ in > arch/i386/timers/timer.c for the HRT cyclone ifdef, I still get the > following link error: should be fixed in 2.6.13-rc6-rt12 and later patches. 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/
[PATCH] VFS: update documentation
This patch brings the now out-of-date Documentation/filesystems/vfs.txt back to life. Thanks to Carsten Otte, Trond Myklebust, and Anton Altaparmakov for their help on updating this documentation. Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]> --- vfs.txt | 435 +++- 1 files changed, 323 insertions(+), 112 deletions(-) Index: 2.6/Documentation/filesystems/vfs.txt === --- 2.6.orig/Documentation/filesystems/vfs.txt +++ 2.6/Documentation/filesystems/vfs.txt @@ -1,35 +1,27 @@ -/* -*- auto-fill -*- */ - Overview of the Virtual File System + Overview of the Linux Virtual File System - Richard Gooch <[EMAIL PROTECTED]> + Original author: Richard Gooch <[EMAIL PROTECTED]> - 5-JUL-1999 + Last updated on August 25, 2005 + Copyright (C) 1999 Richard Gooch + Copyright (C) 2005 Pekka Enberg -Conventions used in this document -= + This file is released under the GPLv2. -Each section in this document will have the string "" at the -right-hand side of the section title. Each subsection will have -"" at the right-hand side. These strings are meant to make -it easier to search through the document. -NOTE that the master copy of this document is available online at: -http://www.atnf.csiro.au/~rgooch/linux/docs/vfs.txt - - -What is it? +What is it? === The Virtual File System (otherwise known as the Virtual Filesystem Switch) is the software layer in the kernel that provides the filesystem interface to userspace programs. It also provides an abstraction within the kernel which allows different filesystem -implementations to co-exist. +implementations to coexist. -A Quick Look At How It Works +A Quick Look At How It Works In this section I'll briefly describe how things work, before @@ -38,7 +30,8 @@ when user programs open and manipulate f other view which is how a filesystem is supported and subsequently mounted. -Opening a File + +Opening a File -- The VFS implements the open(2), stat(2), chmod(2) and similar system @@ -77,7 +70,7 @@ back to userspace. Opening a file requires another operation: allocation of a file structure (this is the kernel-side implementation of file -descriptors). The freshly allocated file structure is initialised with +descriptors). The freshly allocated file structure is initialized with a pointer to the dentry and a set of file operation member functions. These are taken from the inode data. The open() file method is then called so the specific filesystem implementation can do it's work. You @@ -102,7 +95,8 @@ filesystem or driver code at the same ti processors. You should ensure that access to shared resources is protected by appropriate locks. -Registering and Mounting a Filesystem + +Registering and Mounting a Filesystem - If you want to support a new kind of filesystem in the kernel, all you @@ -123,17 +117,21 @@ updated to point to the root inode for t It's now time to look at things in more detail. -struct file_system_type +struct file_system_type === -This describes the filesystem. As of kernel 2.1.99, the following +This describes the filesystem. As of kernel 2.6.13, the following members are defined: struct file_system_type { const char *name; int fs_flags; - struct super_block *(*read_super) (struct super_block *, void *, int); - struct file_system_type * next; +struct super_block *(*get_sb) (struct file_system_type *, int, + const char *, void *); +void (*kill_sb) (struct super_block *); +struct module *owner; +struct file_system_type * next; +struct list_head fs_supers; }; name: the name of the filesystem type, such as "ext2", "iso9660", @@ -141,51 +139,97 @@ struct file_system_type { fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.) - read_super: the method to call when a new instance of this + get_sb: the method to call when a new instance of this filesystem should be mounted - next: for internal VFS use: you should initialise this to NULL + kill_sb: the method to call when an instance of this filesystem + should be unmounted + + owner: for internal VFS use: you should initialize this to THIS_MODULE in + most cases. -The read_super() method has the following arguments: + next: for inter
Re: CFQ + 2.6.13-rc4-RT-V0.7.52-02 = BUG: scheduling with irqs disabled
On Thu, Aug 25 2005, Ingo Molnar wrote: > > * Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > BUG: scheduling with irqs disabled: libc6.postinst/0x2000/13229 > > > caller is ___down_mutex+0xe9/0x1a0 > > > [] schedule+0x59/0xf0 (8) > > > [] ___down_mutex+0xe9/0x1a0 (28) > > > [] cfq_exit_single_io_context+0x22/0xa0 (84) > > > [] cfq_exit_io_context+0x3a/0x50 (16) > > > [] exit_io_context+0x64/0x70 (16) > > > [] do_exit+0x5a/0x3e0 (20) > > > [] do_group_exit+0x2a/0xb0 (24) > > > [] syscall_call+0x7/0xb (20) > > > > Hmm, Ingo I seem to remember you saying that the following construct: > > > > local_irq_save(flags); > > spin_lock(lock); > > > > which is equivelant to spin_lock_irqsave() in mainline being illegal > > in -RT, is that correct? This is what cfq uses right now for an > > exiting task, as the above trace indicates. > > yes, that's correct. Mainline's exit_io_contexts() uses the above > construct because there's no task_lock_irqsave(current, flags) API. > > note that recent -RT kernels are a lot less drastic about these cases > and print a once-per-bootup warning, not a scary message like above. > This message should not happen in recent -RT kernels. > > The problem was this piece of code in exit_io_contexts(): > > local_irq_save(flags); > task_lock(current); > ioc = current->io_context; > current->io_context = NULL; > ioc->task = NULL; > task_unlock(current); > local_irq_restore(flags); > > i understand the detached use of flags, but i'm also wondering why irqs > have to be disabled here in the first place? At this point in do_exit() > we should normally not have any pending IO attached to our io_context. > What am i missing? There can quite easily be lots of pending IO for the io_context (and, in CFQ's case, below cfq_io_contexts), task exiting is completely decoupled from any pending io. Then there's the cfq_exit_io_context() locking. I have to ponder this a bit, I cannot even convince myself that it is currently safe right now. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3] exterminate strtok - drivers/video/au1100fb.c
I see the patch, or an equivalent, has been applied already. Pete On Wed, 2005-08-24 at 21:08 +0200, Jesper Juhl wrote: > Since strtok() died in 2002 let's not use it - use strsep() instead which > is the replacement function. > > Note: I've not been able to test this patch since I lack both hardware and > a cross compiler, so if someone else could please check it and sign off on > it before I send it to Andrew for inclusion in -mm I'd appreciate it. > > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> > --- > > au1100fb.c |7 --- > 1 files changed, 4 insertions(+), 3 deletions(-) > > --- linux-2.6.13-rc6-mm2-orig/drivers/video/au1100fb.c2005-08-17 > 21:51:59.0 +0200 > +++ linux-2.6.13-rc6-mm2/drivers/video/au1100fb.c 2005-08-24 > 18:58:18.0 +0200 > @@ -614,7 +614,7 @@ void au1100fb_cleanup(struct fb_info *in > > void au1100fb_setup(char *options, int *ints) > { > - char* this_opt; > + char *this_opt; > int i; > int num_panels = sizeof(panels)/sizeof(struct known_lcd_panels); > > @@ -622,8 +622,9 @@ void au1100fb_setup(char *options, int * > if (!options || !*options) > return; > > - for(this_opt=strtok(options, ","); this_opt; > - this_opt=strtok(NULL, ",")) { > + while ((this_opt = strsep(&options, ","))) { > + if (!*this_opt) > + continue; > if (!strncmp(this_opt, "panel:", 6)) { > #if defined(CONFIG_MIPS_PB1100) || defined(CONFIG_MIPS_DB1100) > /* Read Pb1100 Switch S10 ? */ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12 Performance problems
Danial Thom wrote: --- Ben Greear <[EMAIL PROTECTED]> wrote: Danial Thom wrote: I think the concensus is that 2.6 has made trade offs that lower raw throughput, which is what a networking device needs. So as a router or network appliance, 2.6 seems less suitable. A raw bridging test on a 2.0Ghz operton system: FreeBSD 4.9: Drops no packets at 900K pps Linux 2.4.24: Starts dropping packets at 350K pps Linux 2.6.12: Starts dropping packets at 100K pps I ran some quick tests using kernel 2.6.11, 1ms tick (HZ=1000), SMP kernel. Hardware is P-IV 3.0Ghz + HT on a new SuperMicro motherboard with 64/133Mhz PCI-X bus. NIC is dual Intel pro/1000. Kernel is close to stock 2.6.11. What GigE adapters did you use? Clearly every driver is going to be different. My experience is that a 3.4Ghz P4 is about the performance of a 2.0Ghz Opteron. I have to try your tuning script tomorrow. Intel pro/1000, as I mentioned. I haven't tried any other NIC that comes close in performance to the e1000. If your test is still set up, try compiling something large while doing the test. The drops go through the roof in my tests. Installing RH9 on the box now to try some tests... Disk access always robs networking, in my experience, so I am not supprised you see bad ntwk performance while compiling. Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.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: CFQ + 2.6.13-rc4-RT-V0.7.52-02 = BUG: scheduling with irqs disabled
On Wed, Aug 24 2005, Esben Nielsen wrote: > On Wed, 24 Aug 2005, Jens Axboe wrote: > > > On Wed, Aug 24 2005, Lee Revell wrote: > > > Just found this in dmesg. > > > > > > BUG: scheduling with irqs disabled: libc6.postinst/0x2000/13229 > > > caller is ___down_mutex+0xe9/0x1a0 > > > [] schedule+0x59/0xf0 (8) > > > [] ___down_mutex+0xe9/0x1a0 (28) > > > [] cfq_exit_single_io_context+0x22/0xa0 (84) > > > [] cfq_exit_io_context+0x3a/0x50 (16) > > > [] exit_io_context+0x64/0x70 (16) > > > [] do_exit+0x5a/0x3e0 (20) > > > [] do_group_exit+0x2a/0xb0 (24) > > > [] syscall_call+0x7/0xb (20) > > > > Hmm, Ingo I seem to remember you saying that the following construct: > > > > local_irq_save(flags); > > spin_lock(lock); > > > > which is equivelant to spin_lock_irqsave() in mainline being illegal in > > -RT, is that correct? > > I can easily answer this for Ingo. > > Yes, spin_lock(lock) is blocking since lock is mutex, not a spinlock under > preempt-rt. But isn't it easy to fix? Replace the two lines by > spin_lock_irqsave(flags). That would work for both preempt-rt > and !preempt-rt. Well, it might and it might not be. There's a correctness and optimization side to it. For this case it is probably doable, but I have to say that the new semantics defy normal logic. > You supposed to ask if the macro name spin_lock() isn't confusing. It very > much is, but one of Ingo's aims is not to change existing code too much. > The purist would probably change all instances of spin_lock() to lock() or > down() to stop refering to a specific lock type when it can be changed > with config-options. That would, however, require a large patch, > which does the preempt-rt branch harder to merge with the main-line. I can certainly understand Ingo's point of view, as long as he is maintaining the patch outside of the kernel. Where it ever to go in, this would have to change. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: CFQ + 2.6.13-rc4-RT-V0.7.52-02 = BUG: scheduling with irqs disabled
* Jens Axboe <[EMAIL PROTECTED]> wrote: > > BUG: scheduling with irqs disabled: libc6.postinst/0x2000/13229 > > caller is ___down_mutex+0xe9/0x1a0 > > [] schedule+0x59/0xf0 (8) > > [] ___down_mutex+0xe9/0x1a0 (28) > > [] cfq_exit_single_io_context+0x22/0xa0 (84) > > [] cfq_exit_io_context+0x3a/0x50 (16) > > [] exit_io_context+0x64/0x70 (16) > > [] do_exit+0x5a/0x3e0 (20) > > [] do_group_exit+0x2a/0xb0 (24) > > [] syscall_call+0x7/0xb (20) > > Hmm, Ingo I seem to remember you saying that the following construct: > > local_irq_save(flags); > spin_lock(lock); > > which is equivelant to spin_lock_irqsave() in mainline being illegal > in -RT, is that correct? This is what cfq uses right now for an > exiting task, as the above trace indicates. yes, that's correct. Mainline's exit_io_contexts() uses the above construct because there's no task_lock_irqsave(current, flags) API. note that recent -RT kernels are a lot less drastic about these cases and print a once-per-bootup warning, not a scary message like above. This message should not happen in recent -RT kernels. The problem was this piece of code in exit_io_contexts(): local_irq_save(flags); task_lock(current); ioc = current->io_context; current->io_context = NULL; ioc->task = NULL; task_unlock(current); local_irq_restore(flags); i understand the detached use of flags, but i'm also wondering why irqs have to be disabled here in the first place? At this point in do_exit() we should normally not have any pending IO attached to our io_context. What am i missing? 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: 2.6.12 Performance problems
--- Ben Greear <[EMAIL PROTECTED]> wrote: > Danial Thom wrote: > > > I think the concensus is that 2.6 has made > trade > > offs that lower raw throughput, which is what > a > > networking device needs. So as a router or > > network appliance, 2.6 seems less suitable. A > raw > > bridging test on a 2.0Ghz operton system: > > > > FreeBSD 4.9: Drops no packets at 900K pps > > Linux 2.4.24: Starts dropping packets at 350K > pps > > Linux 2.6.12: Starts dropping packets at 100K > pps > > I ran some quick tests using kernel 2.6.11, 1ms > tick (HZ=1000), SMP kernel. > Hardware is P-IV 3.0Ghz + HT on a new > SuperMicro motherboard with 64/133Mhz > PCI-X bus. NIC is dual Intel pro/1000. Kernel > is close to stock 2.6.11. > > I used brctl to create a bridge with the two > GigE adapters in it and > used pktgen to stream traffic through it > (250kpps in one direction, 1kpps in > the other.) > > I see a reasonable amount of drops at 250kpps > (60 byte packets): > about 60,000,000 packets received, 20,700 > dropped. > > Interestingly, the system is about 60% idle > according to top, > and still dropping pkts, so it would seem that > the system could > be better utilized! > > Ben > What GigE adapters did you use? Clearly every driver is going to be different. My experience is that a 3.4Ghz P4 is about the performance of a 2.0Ghz Opteron. I have to try your tuning script tomorrow. If your test is still set up, try compiling something large while doing the test. The drops go through the roof in my tests. Danial Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/1] ES7000 platform update (i386)
This is subarch update for ES7000. I've modified platform check code and removed unnecessary OEM table parsing for newer systems that don't use OEM information during boot. Parsing the table in fact is causing problems, and the platform doesn't get recognized. The patch only affects the ES7000 subach. Signed-off-by: <[EMAIL PROTECTED]> --- arch/i386/mach-es7000/es7000.h |5 +-- arch/i386/mach-es7000/es7000plat.c | 45 +--- include/asm-i386/mach-es7000/mach_mpparse.h | 30 ++ 3 files changed, 49 insertions(+), 31 deletions(-) diff -puN arch/i386/mach-es7000/es7000.h~es7000_plat_update arch/i386/mach-es7000/es7000.h --- linux-2.6.13-rc6/arch/i386/mach-es7000/es7000.h~es7000_plat_update 2005-08-23 21:01:22.621684672 -0700 +++ linux-2.6.13-rc6-root/arch/i386/mach-es7000/es7000.h2005-08-23 23:49:47.225551392 -0700 @@ -104,7 +104,8 @@ struct mip_reg { #defineMIP_SW_APIC 0x1020b #defineMIP_FUNC(VALUE) (VALUE & 0xff) -extern int parse_unisys_oem (char *oemptr, int oem_entries); -extern int find_unisys_acpi_oem_table(unsigned long *oem_addr, int *length); +extern int parse_unisys_oem (char *oemptr); +extern int find_unisys_acpi_oem_table(unsigned long *oem_addr); +extern void setup_unisys (); extern int es7000_start_cpu(int cpu, unsigned long eip); extern void es7000_sw_apic(void); diff -puN arch/i386/mach-es7000/es7000plat.c~es7000_plat_update arch/i386/mach-es7000/es7000plat.c --- linux-2.6.13-rc6/arch/i386/mach-es7000/es7000plat.c~es7000_plat_update 2005-08-23 21:01:22.656679352 -0700 +++ linux-2.6.13-rc6-root/arch/i386/mach-es7000/es7000plat.c2005-08-23 21:04:15.662378488 -0700 @@ -75,12 +75,29 @@ es7000_rename_gsi(int ioapic, int gsi) #endif // (CONFIG_X86_IO_APIC) && (CONFIG_ACPI_INTERPRETER || CONFIG_ACPI_BOOT) +void __init +setup_unisys () +{ + /* +* Determine the generation of the ES7000 currently running. +* +* es7000_plat = 1 if the machine is a 5xx ES7000 box +* es7000_plat = 2 if the machine is a x86_64 ES7000 box +* +*/ + if (!(boot_cpu_data.x86 <= 15 && boot_cpu_data.x86_model <= 2)) + es7000_plat = 2; + else + es7000_plat = 1; + ioapic_renumber_irq = es7000_rename_gsi; +} + /* * Parse the OEM Table */ int __init -parse_unisys_oem (char *oemptr, int oem_entries) +parse_unisys_oem (char *oemptr) { int i; int success = 0; @@ -95,7 +112,7 @@ parse_unisys_oem (char *oemptr, int oem_ tp += 8; - for (i=0; i <= oem_entries; i++) { + for (i=0; i <= 6; i++) { type = *tp++; size = *tp++; tp -= 2; @@ -130,34 +147,18 @@ parse_unisys_oem (char *oemptr, int oem_ default: break; } - if (i == 6) break; tp += size; } if (success < 2) { es7000_plat = 0; - } else { - printk("\nEnabling ES7000 specific features...\n"); - /* -* Determine the generation of the ES7000 currently running. -* -* es7000_plat = 0 if the machine is NOT a Unisys ES7000 box -* es7000_plat = 1 if the machine is a 5xx ES7000 box -* es7000_plat = 2 if the machine is a x86_64 ES7000 box -* -*/ - if (!(boot_cpu_data.x86 <= 15 && boot_cpu_data.x86_model <= 2)) - es7000_plat = 2; - else - es7000_plat = 1; - - ioapic_renumber_irq = es7000_rename_gsi; - } + } else + setup_unisys(); return es7000_plat; } int __init -find_unisys_acpi_oem_table(unsigned long *oem_addr, int *length) +find_unisys_acpi_oem_table(unsigned long *oem_addr) { struct acpi_table_rsdp *rsdp = NULL; unsigned long rsdp_phys = 0; @@ -201,13 +202,11 @@ find_unisys_acpi_oem_table(unsigned long acpi_table_print(header, sdt.entry[i].pa); t = (struct oem_table *) __acpi_map_table(sdt.entry[i].pa, header->length); addr = (void *) __acpi_map_table(t->OEMTableAddr, t->OEMTableSize); - *length = header->length; *oem_addr = (unsigned long) addr; return 0; } } } - Dprintk("ES7000: did not find Unisys ACPI OEM table!\n"); return -1; } diff -puN include/asm-i386/mach-es7000/mach_mpparse.h~es7000_plat_update include/asm-i386/mach-es7000/mach_mpparse.h --- linux-2.6.13-rc6/include/asm-i386/mach-es7000/mach_mpparse.h~es7000_plat_update 2005-0
Re: 2.6.13-rc6-rt15 won't compile without HR-Timers
* K.R. Foley <[EMAIL PROTECTED]> wrote: > Ingo, > > Without the attached patch 2.6.13-rc6-rt15 won't compile for me with > CONFIG_HIGH_RES_TIMERS not configured. thanks, applied. 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: cpu_exclusive sched domains fix broke ppc64
Paul Jackson writes: > ... however ... question for Paul M. ... what version of gcc did this fail > on? The gcc-4.0.2 in Debian/ppc sid, which is biarch. > I finally got my crosstools setup working for me again, and building > a powerpc64 using gcc-3.4.0 on my Intel PC box does _not_ fail. That Did you have CONFIG_NUMA=y ? Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (22/22) ADBREQ_RAW missing declaration
pulled from m68k CVS; ADBREQ_RAW is used in arch/m68k/mac/misc.c, but its declaration had not been propagated to Linus' tree yet. Related chunk in drivers/macintosh/adb.c also pulled in; even though the file is shared with ppc, behaviour is changed only for m68k. Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-m68k-flags/drivers/macintosh/adb.c RC13-rc7-m68k-adb.patch/drivers/macintosh/adb.c --- RC13-rc7-m68k-flags/drivers/macintosh/adb.c 2005-08-10 10:37:49.0 -0400 +++ RC13-rc7-m68k-adb.patch/drivers/macintosh/adb.c 2005-08-25 00:54:21.0 -0400 @@ -476,13 +476,15 @@ use_sreq = 1; } else use_sreq = 0; - req->nbytes = nbytes+1; + i = (flags & ADBREQ_RAW) ? 0 : 1; + req->nbytes = nbytes+i; req->done = done; req->reply_expected = flags & ADBREQ_REPLY; req->data[0] = ADB_PACKET; va_start(list, nbytes); - for (i = 0; i < nbytes; ++i) - req->data[i+1] = va_arg(list, int); + while (i < req->nbytes) { + req->data[i++] = va_arg(list, int); + } va_end(list); if (flags & ADBREQ_NOSEND) diff -urN RC13-rc7-m68k-flags/include/linux/adb.h RC13-rc7-m68k-adb.patch/include/linux/adb.h --- RC13-rc7-m68k-flags/include/linux/adb.h 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k-adb.patch/include/linux/adb.h 2005-08-25 00:54:21.0 -0400 @@ -76,6 +76,7 @@ #define ADBREQ_REPLY 1 /* expect reply */ #define ADBREQ_SYNC2 /* poll until done */ #define ADBREQ_NOSEND 4 /* build the request, but don't send it */ +#define ADBREQ_RAW 8 /* send raw packet (don't prepend ADB_PACKET) */ /* Messages sent thru the client_list notifier. You should NOT stop the operation, at least not with this version */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (14/22) oktagon makefile fix
oktagon_esp is described as modular. However, drivers/scsi/Makefile doesn't handle it right - it's multi-object module, with one of the parts being built from .S. Current makefile tries to declare each part a module of its own; that not only wouldn't work (oktagon_io.o doesn't have the right parts for that), it actually doesn't even build since kbuild doesn't believe in single-object modules built from .S. Turned into proper multi-object module... Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-isa_type/drivers/scsi/Makefile RC13-rc7-oktagon/drivers/scsi/Makefile --- RC13-rc7-isa_type/drivers/scsi/Makefile 2005-08-10 10:37:50.0 -0400 +++ RC13-rc7-oktagon/drivers/scsi/Makefile 2005-08-25 00:54:14.0 -0400 @@ -41,7 +41,7 @@ obj-$(CONFIG_BLZ2060_SCSI) += NCR53C9x.o blz2060.o obj-$(CONFIG_BLZ1230_SCSI) += NCR53C9x.o blz1230.o obj-$(CONFIG_FASTLANE_SCSI)+= NCR53C9x.o fastlane.o -obj-$(CONFIG_OKTAGON_SCSI) += NCR53C9x.o oktagon_esp.o oktagon_io.o +obj-$(CONFIG_OKTAGON_SCSI) += NCR53C9x.o oktagon_esp_mod.o obj-$(CONFIG_ATARI_SCSI) += atari_scsi.o obj-$(CONFIG_MAC_SCSI) += mac_scsi.o obj-$(CONFIG_SCSI_MAC_ESP) += mac_esp.oNCR53C9x.o @@ -160,6 +160,7 @@ cpqfc-objs := cpqfcTSinit.o cpqfcTScontrol.o cpqfcTSi2c.o \ cpqfcTSworker.o cpqfcTStrigger.o libata-objs:= libata-core.o libata-scsi.o +oktagon_esp_mod-objs := oktagon_esp.o oktagon_io.o # Files generated that shall be removed upon make clean clean-files := 53c7xx_d.h 53c700_d.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] (8/22) lvalues abuse in lance
result of comma operator is not an lvalue Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-mac8390/drivers/net/atarilance.c RC13-rc7-lance/drivers/net/atarilance.c --- RC13-rc7-mac8390/drivers/net/atarilance.c 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-lance/drivers/net/atarilance.c 2005-08-25 00:54:10.0 -0400 @@ -235,7 +235,7 @@ #defineMEM lp->mem #defineDREGIO->data #defineAREGIO->addr -#defineREGA(a) ( AREG = (a), DREG ) +#defineREGA(a) (*( AREG = (a), &DREG )) /* Definitions for packet buffer access: */ #define PKT_BUF_SZ 1544 diff -urN RC13-rc7-mac8390/drivers/net/sun3lance.c RC13-rc7-lance/drivers/net/sun3lance.c --- RC13-rc7-mac8390/drivers/net/sun3lance.c2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-lance/drivers/net/sun3lance.c 2005-08-25 00:54:10.0 -0400 @@ -162,7 +162,7 @@ #defineMEM lp->mem #defineDREGlp->iobase[0] #defineAREGlp->iobase[1] -#defineREGA(a) ( AREG = (a), DREG ) +#defineREGA(a) (*( AREG = (a), &DREG )) /* Definitions for the Lance */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (16/22) Kconfig fix (mac vs. FONTS)
mac won't build without non-modular FONTS, which requires non-modular FB and FRAMEBUFFER_CONSOLE Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-82596/arch/m68k/Kconfig RC13-rc7-mac-fonts/arch/m68k/Kconfig --- RC13-rc7-82596/arch/m68k/Kconfig2005-08-10 10:37:46.0 -0400 +++ RC13-rc7-mac-fonts/arch/m68k/Kconfig2005-08-25 00:54:16.0 -0400 @@ -126,6 +126,8 @@ config MAC bool "Macintosh support" depends on !MMU_SUN3 + select FRAMEBUFFER_CONSOLE + select FB help This option enables support for the Apple Macintosh series of computers (yes, there is experimental support now, at least for part - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (12/22) broken constraints on mulu.l
too permissive constraint on mulu.l - the first argument should not be an a-register. Fixed by replacing "g" with "dm"; with older gcc we got lucky and it had never attempted mulu.l %a0, %d1:%d0. These days it does, with predictable objections from as(1). Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-m68k-reset/arch/m68k/math-emu/multi_arith.h RC13-rc7-m68k-mul/arch/m68k/math-emu/multi_arith.h --- RC13-rc7-m68k-reset/arch/m68k/math-emu/multi_arith.h2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k-mul/arch/m68k/math-emu/multi_arith.h 2005-08-25 00:54:13.0 -0400 @@ -366,7 +366,7 @@ #define fp_mul64(desth, destl, src1, src2) ({ \ asm ("mulu.l %2,%1:%0" : "=d" (destl), "=d" (desth) \ - : "g" (src1), "0" (src2)); \ + : "dm" (src1), "0" (src2)); \ }) #define fp_div64(quot, rem, srch, srcl, div) \ asm ("divu.l %2,%1:%0" : "=d" (quot), "=d" (rem)\ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (15/22) Kconfig fix (82596)
driver is non-modular Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-oktagon/drivers/net/Kconfig RC13-rc7-82596/drivers/net/Kconfig --- RC13-rc7-oktagon/drivers/net/Kconfig2005-08-24 01:58:29.0 -0400 +++ RC13-rc7-82596/drivers/net/Kconfig 2005-08-25 00:54:15.0 -0400 @@ -395,7 +395,7 @@ If you're not building a kernel for a Sun 3, say N. config SUN3_82586 - tristate "Sun3 on-board Intel 82586 support" + bool "Sun3 on-board Intel 82586 support" depends on NET_ETHERNET && SUN3 help This driver enables support for the on-board Intel 82586 based - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (21/22) task_thread_info - part 4/4
partially pulled from m68k CVS; switches m68k handling of thread flags to usual bitmap, which allows to unify most of the thread flag helpers. After that only task_thread_info(), stack_end() and setup_thread_info() are conditional on __HAVE_THREAD_FUNCTIONS. Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-m68k/arch/m68k/fpsp040/skeleton.S RC13-rc7-m68k-flags/arch/m68k/fpsp040/skeleton.S --- RC13-rc7-m68k/arch/m68k/fpsp040/skeleton.S 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k-flags/arch/m68k/fpsp040/skeleton.S2005-08-25 00:54:20.0 -0400 @@ -381,10 +381,8 @@ .Lnotkern: SAVE_ALL_INT GET_CURRENT(%d0) - tstb%curptr@(TASK_NEEDRESCHED) - jne ret_from_exception | deliver signals, - | reschedule etc.. - RESTORE_ALL + | deliver signals, reschedule etc.. + jra ret_from_exception | | mem_write --- write to user or supervisor address space diff -urN RC13-rc7-m68k/arch/m68k/ifpsp060/iskeleton.S RC13-rc7-m68k-flags/arch/m68k/ifpsp060/iskeleton.S --- RC13-rc7-m68k/arch/m68k/ifpsp060/iskeleton.S2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k-flags/arch/m68k/ifpsp060/iskeleton.S 2005-08-25 00:54:20.0 -0400 @@ -75,10 +75,8 @@ .Lnotkern: SAVE_ALL_INT GET_CURRENT(%d0) - tstb%curptr@(TASK_NEEDRESCHED) - jne ret_from_exception | deliver signals, - | reschedule etc.. - RESTORE_ALL + | deliver signals, reschedule etc.. + jra ret_from_exception | | _060_real_chk(): diff -urN RC13-rc7-m68k/arch/m68k/kernel/asm-offsets.c RC13-rc7-m68k-flags/arch/m68k/kernel/asm-offsets.c --- RC13-rc7-m68k/arch/m68k/kernel/asm-offsets.c2005-08-25 00:54:19.0 -0400 +++ RC13-rc7-m68k-flags/arch/m68k/kernel/asm-offsets.c 2005-08-25 00:54:20.0 -0400 @@ -25,11 +25,6 @@ DEFINE(TASK_STATE, offsetof(struct task_struct, state)); DEFINE(TASK_FLAGS, offsetof(struct task_struct, flags)); DEFINE(TASK_PTRACE, offsetof(struct task_struct, ptrace)); - DEFINE(TASK_WORK, offsetof(struct task_struct, thread.work)); - DEFINE(TASK_NEEDRESCHED, offsetof(struct task_struct, thread.work.need_resched)); - DEFINE(TASK_SYSCALL_TRACE, offsetof(struct task_struct, thread.work.syscall_trace)); - DEFINE(TASK_SIGPENDING, offsetof(struct task_struct, thread.work.sigpending)); - DEFINE(TASK_NOTIFY_RESUME, offsetof(struct task_struct, thread.work.notify_resume)); DEFINE(TASK_THREAD, offsetof(struct task_struct, thread)); DEFINE(TASK_INFO, offsetof(struct task_struct, thread.info)); DEFINE(TASK_MM, offsetof(struct task_struct, mm)); @@ -48,7 +43,7 @@ /* offsets into the thread_info struct */ DEFINE(TINFO_PREEMPT, offsetof(struct thread_info, preempt_count)); - DEFINE(HARDIRQ_SHIFT, HARDIRQ_SHIFT); + DEFINE(TINFO_FLAGS, offsetof(struct thread_info, flags)); /* offsets into the pt_regs */ DEFINE(PT_D0, offsetof(struct pt_regs, d0)); diff -urN RC13-rc7-m68k/arch/m68k/kernel/entry.S RC13-rc7-m68k-flags/arch/m68k/kernel/entry.S --- RC13-rc7-m68k/arch/m68k/kernel/entry.S 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k-flags/arch/m68k/kernel/entry.S2005-08-25 00:54:20.0 -0400 @@ -44,9 +44,7 @@ #include -.globl system_call, buserr, trap -.globl resume, ret_from_exception -.globl ret_from_signal +.globl system_call, buserr, trap, resume .globl inthandler, sys_call_table .globl sys_fork, sys_clone, sys_vfork .globl ret_from_interrupt, bad_interrupt @@ -58,7 +56,7 @@ movel %sp,[EMAIL PROTECTED] | stack frame pointer argument bsrlbuserr_c addql #4,%sp - jra ret_from_exception + jra .Lret_from_exception ENTRY(trap) SAVE_ALL_INT @@ -66,7 +64,7 @@ movel %sp,[EMAIL PROTECTED] | stack frame pointer argument bsrltrap_c addql #4,%sp - jra ret_from_exception + jra .Lret_from_exception | After a fork we jump here directly from resume, | so that %d1 contains the previous task @@ -75,30 +73,31 @@ movel %d1,[EMAIL PROTECTED] jsr schedule_tail addql #4,%sp - jra ret_from_exception + jra .Lret_from_exception -badsys: - movel #-ENOSYS,%sp@(PT_D0) - jra ret_from_exception - -do_trace: +do_trace_entry: movel #-ENOSYS,%sp@(PT_D0)| needed for strace subql #4,%sp SAVE_SWITCH_STACK jbsrsyscall_trace RESTORE_SWITCH_STACK addql #4,%sp - movel %sp@(PT_ORIG_D0),%d1 - movel #-ENOSYS,%d0 - cmpl#NR_syscalls,%d1 - jcc 1f - jbsr@(sys_call_table,%d1:l:4)@(0) -1: movel %d0,%sp@(PT_D0) | save the return value -
[PATCH] (20/22) task_thread_info - part 3/4
a) added embedded thread_info [m68k processor.h] b) added missing symbols in asm-offsets.c c) task_thread_info() and freinds in asm-m68k/thread_info.h d) made m68k thread_info.h included by m68k processor.h, not the other way round. Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-includes/arch/m68k/kernel/asm-offsets.c RC13-rc7-m68k/arch/m68k/kernel/asm-offsets.c --- RC13-rc7-includes/arch/m68k/kernel/asm-offsets.c2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k/arch/m68k/kernel/asm-offsets.c2005-08-25 00:54:19.0 -0400 @@ -31,6 +31,7 @@ DEFINE(TASK_SIGPENDING, offsetof(struct task_struct, thread.work.sigpending)); DEFINE(TASK_NOTIFY_RESUME, offsetof(struct task_struct, thread.work.notify_resume)); DEFINE(TASK_THREAD, offsetof(struct task_struct, thread)); + DEFINE(TASK_INFO, offsetof(struct task_struct, thread.info)); DEFINE(TASK_MM, offsetof(struct task_struct, mm)); DEFINE(TASK_ACTIVE_MM, offsetof(struct task_struct, active_mm)); @@ -45,6 +46,10 @@ DEFINE(THREAD_FPCNTL, offsetof(struct thread_struct, fpcntl)); DEFINE(THREAD_FPSTATE, offsetof(struct thread_struct, fpstate)); + /* offsets into the thread_info struct */ + DEFINE(TINFO_PREEMPT, offsetof(struct thread_info, preempt_count)); + DEFINE(HARDIRQ_SHIFT, HARDIRQ_SHIFT); + /* offsets into the pt_regs */ DEFINE(PT_D0, offsetof(struct pt_regs, d0)); DEFINE(PT_ORIG_D0, offsetof(struct pt_regs, orig_d0)); diff -urN RC13-rc7-includes/include/asm-m68k/processor.h RC13-rc7-m68k/include/asm-m68k/processor.h --- RC13-rc7-includes/include/asm-m68k/processor.h 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k/include/asm-m68k/processor.h 2005-08-25 00:54:19.0 -0400 @@ -14,6 +14,7 @@ #define current_text_addr() ({ __label__ _l; _l: &&_l;}) #include +#include #include #include #include @@ -79,6 +80,7 @@ unsigned long fpcntl[3]; /* fp control regs */ unsigned char fpstate[FPSTATESIZE]; /* floating point state */ struct task_work work; + struct thread_info info; }; #define INIT_THREAD { \ diff -urN RC13-rc7-includes/include/asm-m68k/thread_info.h RC13-rc7-m68k/include/asm-m68k/thread_info.h --- RC13-rc7-includes/include/asm-m68k/thread_info.h2005-08-10 10:37:53.0 -0400 +++ RC13-rc7-m68k/include/asm-m68k/thread_info.h2005-08-25 00:54:19.0 -0400 @@ -2,7 +2,6 @@ #define _ASM_M68K_THREAD_INFO_H #include -#include #include struct thread_info { @@ -35,11 +34,11 @@ #define free_thread_info(ti) free_pages((unsigned long)(ti),1) #endif /* PAGE_SHIFT == 13 */ -//#define init_thread_info (init_task.thread.info) -#define init_stack (init_thread_union.stack) - -#define current_thread_info() (current->thread_info) +#define init_thread_info (init_thread_union.thread_info) +#define init_stack (init_thread_union.stack) +#define task_thread_info(tsk) (&(tsk)->thread.info) +#define current_thread_info() task_thread_info(current) #define __HAVE_THREAD_FUNCTIONS @@ -52,6 +51,10 @@ extern int thread_flag_fixme(void); +#define setup_thread_info(p, ti) do (ti)->task = p; while(0) + +#define end_of_stack(p) ((unsigned long *)(p)->thread_info + 1) + /* * flag set/clear/test wrappers * - pass TIF_ constants to these functions - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] LSM hook updates
* James Morris ([EMAIL PROTECTED]) wrote: > On Wed, 24 Aug 2005, Chris Wright wrote: > > > This is based on Kurt's original work. The net effect is that > > LSM hooks are called conditionally, and in all cases capabilities > > provide the defaults. I've done some basic performance testing, and > > found nothing surprising. > > Do you mean nothing noticable? I did only microbenchmarking, which was as much as double digit percentage faster (on P4), nothing was slower. > > I'm interested to see numbers from others > > before I push this up. These are against Linus' current git tree (they > > will clash with the -mm tree). > > Are there any numbers for popular architectures like i386 and x86_64? I'll have some numbers tomorrow. If you'd like to run SELinux that'd be quite useful. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (11/22) memory input should be an lvalue (mac/misc.c)
gcc4 is less forgiving and wants memory inputs to be real lvalues; variable added and value stored in it explicitly before doing __asm__. Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-scc/arch/m68k/mac/misc.c RC13-rc7-m68k-reset/arch/m68k/mac/misc.c --- RC13-rc7-scc/arch/m68k/mac/misc.c 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k-reset/arch/m68k/mac/misc.c2005-08-25 00:54:12.0 -0400 @@ -466,12 +466,13 @@ /* make a 1-to-1 mapping, using the transparent tran. reg. */ unsigned long virt = (unsigned long) mac_reset; unsigned long phys = virt_to_phys(mac_reset); + unsigned long addr = (phys&0xFF00)|0x8777; unsigned long offset = phys-virt; local_irq_disable(); /* lets not screw this up, ok? */ __asm__ __volatile__(".chip 68030\n\t" "pmove %0,%/tt0\n\t" ".chip 68k" -: : "m" ((phys&0xFF00)|0x8777)); +: : "m" (addr)); /* Now jump to physical address so we can disable MMU */ __asm__ __volatile__( ".chip 68030\n\t" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (17/22) task_thread_info - part 1/4
new helper - task_thread_info(task). On platforms that have thread_info allocated separately (i.e. in default case) it simply returns task->thread_info m68k wants (and for good reasons) to embed its thread_info into task_struct. So it will (in later patch) have task_thread_info() of its own. For now we just add a macro for generic case and convert existing instances of its body in core kernel to uses of new macro. Obviously safe - all normal architectures get the same preprocessor output they used to get. Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-mac-fonts/include/linux/sched.h RC13-rc7-task_thread_info/include/linux/sched.h --- RC13-rc7-mac-fonts/include/linux/sched.h2005-08-10 10:37:54.0 -0400 +++ RC13-rc7-task_thread_info/include/linux/sched.h 2005-08-25 00:54:17.0 -0400 @@ -1136,32 +1136,34 @@ spin_unlock(&p->alloc_lock); } +#define task_thread_info(task) (task)->thread_info + /* set thread flags in other task's structures * - see asm/thread_info.h for TIF_ flags available */ static inline void set_tsk_thread_flag(struct task_struct *tsk, int flag) { - set_ti_thread_flag(tsk->thread_info,flag); + set_ti_thread_flag(task_thread_info(tsk), flag); } static inline void clear_tsk_thread_flag(struct task_struct *tsk, int flag) { - clear_ti_thread_flag(tsk->thread_info,flag); + clear_ti_thread_flag(task_thread_info(tsk), flag); } static inline int test_and_set_tsk_thread_flag(struct task_struct *tsk, int flag) { - return test_and_set_ti_thread_flag(tsk->thread_info,flag); + return test_and_set_ti_thread_flag(task_thread_info(tsk), flag); } static inline int test_and_clear_tsk_thread_flag(struct task_struct *tsk, int flag) { - return test_and_clear_ti_thread_flag(tsk->thread_info,flag); + return test_and_clear_ti_thread_flag(task_thread_info(tsk), flag); } static inline int test_tsk_thread_flag(struct task_struct *tsk, int flag) { - return test_ti_thread_flag(tsk->thread_info,flag); + return test_ti_thread_flag(task_thread_info(tsk), flag); } static inline void set_tsk_need_resched(struct task_struct *tsk) @@ -1232,12 +1234,12 @@ static inline unsigned int task_cpu(const struct task_struct *p) { - return p->thread_info->cpu; + return task_thread_info(p)->cpu; } static inline void set_task_cpu(struct task_struct *p, unsigned int cpu) { - p->thread_info->cpu = cpu; + task_thread_info(p)->cpu = cpu; } #else diff -urN RC13-rc7-mac-fonts/kernel/exit.c RC13-rc7-task_thread_info/kernel/exit.c --- RC13-rc7-mac-fonts/kernel/exit.c2005-08-10 10:37:54.0 -0400 +++ RC13-rc7-task_thread_info/kernel/exit.c 2005-08-25 00:54:17.0 -0400 @@ -846,7 +846,7 @@ if (group_dead && tsk->signal->leader) disassociate_ctty(1); - module_put(tsk->thread_info->exec_domain->module); + module_put(task_thread_info(tsk)->exec_domain->module); if (tsk->binfmt) module_put(tsk->binfmt->module); diff -urN RC13-rc7-mac-fonts/kernel/fork.c RC13-rc7-task_thread_info/kernel/fork.c --- RC13-rc7-mac-fonts/kernel/fork.c2005-08-10 10:37:54.0 -0400 +++ RC13-rc7-task_thread_info/kernel/fork.c 2005-08-25 00:54:17.0 -0400 @@ -898,7 +898,7 @@ if (nr_threads >= max_threads) goto bad_fork_cleanup_count; - if (!try_module_get(p->thread_info->exec_domain->module)) + if (!try_module_get(task_thread_info(p)->exec_domain->module)) goto bad_fork_cleanup_count; if (p->binfmt && !try_module_get(p->binfmt->module)) @@ -1151,7 +1151,7 @@ if (p->binfmt) module_put(p->binfmt->module); bad_fork_cleanup_put_domain: - module_put(p->thread_info->exec_domain->module); + module_put(task_thread_info(p)->exec_domain->module); bad_fork_cleanup_count: put_group_info(p->group_info); atomic_dec(&p->user->processes); diff -urN RC13-rc7-mac-fonts/kernel/sched.c RC13-rc7-task_thread_info/kernel/sched.c --- RC13-rc7-mac-fonts/kernel/sched.c 2005-08-21 13:12:57.0 -0400 +++ RC13-rc7-task_thread_info/kernel/sched.c2005-08-25 00:54:17.0 -0400 @@ -1317,7 +1317,7 @@ #endif #ifdef CONFIG_PREEMPT /* Want to start with kernel preemption disabled. */ - p->thread_info->preempt_count = 1; + task_thread_info(p)->preempt_count = 1; #endif /* * Share the timeslice between parent and child, thus the @@ -4204,9 +4204,9 @@ /* Set the preempt count _outside_ the spinlocks! */ #if defined(CONFIG_PREEMPT) && !defined(CONFIG_PREEMPT_BKL) - idle->thread_info->preempt_count = (idle->lock_depth >= 0); + task_thread_info(idle)->preempt_count = (idle->lock_depth >= 0); #else - idle->thread_info->preempt_count = 0; + task_thread_info(idle)->preempt_count = 0; #endif } - To unsubscribe fro
[PATCH] (7/22) lvalues abuse in mac8390
cast is not an lvalue Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-atyfb-typo/drivers/net/mac8390.c RC13-rc7-mac8390/drivers/net/mac8390.c --- RC13-rc7-atyfb-typo/drivers/net/mac8390.c 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-mac8390/drivers/net/mac8390.c 2005-08-25 00:54:09.0 -0400 @@ -560,55 +560,52 @@ /* directly from daynaport.c by Alan Cox */ static void dayna_memcpy_fromcard(struct net_device *dev, void *to, int from, int count) { - volatile unsigned short *ptr; - unsigned short *target=to; + volatile unsigned char *ptr; + unsigned char *target=to; from<<=1; /* word, skip overhead */ - ptr=(unsigned short *)(dev->mem_start+from); + ptr=(unsigned char *)(dev->mem_start+from); /* Leading byte? */ if (from&2) { - *((char *)target)++ = *(((char *)ptr++)-1); + *target++ = ptr[-1]; + ptr += 2; count--; } while(count>=2) { - *target++=*ptr++; /* Copy and */ - ptr++; /* skip cruft */ + *(unsigned short *)target = *(unsigned short volatile *)ptr; + ptr += 4; /* skip cruft */ + target += 2; count-=2; } /* Trailing byte? */ if(count) - { - /* Big endian */ - unsigned short v=*ptr; - *((char *)target)=v>>8; - } + *target = *ptr; } static void dayna_memcpy_tocard(struct net_device *dev, int to, const void *from, int count) { volatile unsigned short *ptr; - const unsigned short *src=from; + const unsigned char *src=from; to<<=1; /* word, skip overhead */ ptr=(unsigned short *)(dev->mem_start+to); /* Leading byte? */ if (to&2) { /* avoid a byte write (stomps on other data) */ - ptr[-1] = (ptr[-1]&0xFF00)|*((unsigned char *)src)++; + ptr[-1] = (ptr[-1]&0xFF00)|*src++; ptr++; count--; } while(count>=2) { - *ptr++=*src++; /* Copy and */ + *ptr++=*(unsigned short *)src; /* Copy and */ ptr++; /* skip cruft */ + src += 2; count-=2; } /* Trailing byte? */ if(count) { - /* Big endian */ - unsigned short v=*src; /* card doesn't like byte writes */ - *ptr=(*ptr&0x00FF)|(v&0xFF00); + *ptr=(*ptr&0x00FF)|(*src << 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] (6/22) dumb typo in atyfb
atyfb_par misspelled as aty_par, fortunately in m68k-only part of driver Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-amigaints/drivers/video/aty/atyfb_base.c RC13-rc7-atyfb-typo/drivers/video/aty/atyfb_base.c --- RC13-rc7-amigaints/drivers/video/aty/atyfb_base.c 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-atyfb-typo/drivers/video/aty/atyfb_base.c 2005-08-25 00:54:08.0 -0400 @@ -3458,7 +3458,7 @@ static int __devinit atyfb_atari_probe(void) { - struct aty_par *par; + struct atyfb_par *par; struct fb_info *info; int m64_num; u32 clock_r; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (10/22) static vs. extern in scc
extern declaration before the static one Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-82596-apricot/drivers/char/scc.h RC13-rc7-scc/drivers/char/scc.h --- RC13-rc7-82596-apricot/drivers/char/scc.h 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-scc/drivers/char/scc.h 2005-08-25 00:54:11.0 -0400 @@ -399,7 +399,7 @@ __asm__ __volatile__ ( "tstb %0" : : "g" (*_scc_del) : "cc" );\ } while (0) -extern unsigned char scc_shadow[2][16]; +static unsigned char scc_shadow[2][16]; /* The following functions should relax the somehow complicated * register access of the SCC. _SCCwrite() stores all written values - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (3/22) static vs. extern in sun3ints.h
extern declaration of static object removed from header Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-dmasound-extern/include/asm-m68k/sun3ints.h RC13-rc7-sun3ints/include/asm-m68k/sun3ints.h --- RC13-rc7-dmasound-extern/include/asm-m68k/sun3ints.h2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-sun3ints/include/asm-m68k/sun3ints.h 2005-08-25 00:54:06.0 -0400 @@ -31,7 +31,6 @@ ); extern void sun3_init_IRQ (void); extern irqreturn_t (*sun3_default_handler[]) (int, void *, struct pt_regs *); -extern irqreturn_t (*sun3_inthandler[]) (int, void *, struct pt_regs *); extern void sun3_free_irq (unsigned int irq, void *dev_id); extern void sun3_enable_interrupts (void); extern void sun3_disable_interrupts (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] (19/22) task_thread_info - part 3/4
a) in smp_lock.h #include of sched.h and spinlock.h moved under #ifdef CONFIG_LOCK_KERNEL. b) interrupt.h now explicitly pulls sched.h (not via smp_lock.h from hardirq.h as it used to) c) in two more places we need changes to compensate for (a) - one place in arch/sparc needs string.h now and hardirq.h needs forward declaration of task_struct and direct include of thread_info.h. d) thread_info-related helpers in sched.h and thread_info.h put under ifndef __HAVE_THREAD_FUNCTIONS. Obviously safe. Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-other-helpers/arch/sparc/lib/bitext.c RC13-rc7-includes/arch/sparc/lib/bitext.c --- RC13-rc7-other-helpers/arch/sparc/lib/bitext.c 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-includes/arch/sparc/lib/bitext.c 2005-08-25 00:54:18.0 -0400 @@ -10,6 +10,7 @@ */ #include +#include #include #include diff -urN RC13-rc7-other-helpers/include/linux/hardirq.h RC13-rc7-includes/include/linux/hardirq.h --- RC13-rc7-other-helpers/include/linux/hardirq.h 2005-08-10 10:37:54.0 -0400 +++ RC13-rc7-includes/include/linux/hardirq.h 2005-08-25 00:54:18.0 -0400 @@ -4,6 +4,7 @@ #include #include #include +#include #include #include @@ -90,6 +91,8 @@ #define nmi_enter()irq_enter() #define nmi_exit() sub_preempt_count(HARDIRQ_OFFSET) +struct task_struct; + #ifndef CONFIG_VIRT_CPU_ACCOUNTING static inline void account_user_vtime(struct task_struct *tsk) { diff -urN RC13-rc7-other-helpers/include/linux/interrupt.h RC13-rc7-includes/include/linux/interrupt.h --- RC13-rc7-other-helpers/include/linux/interrupt.h2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-includes/include/linux/interrupt.h 2005-08-25 00:54:18.0 -0400 @@ -12,6 +12,7 @@ #include #include #include +#include /* * For 2.4.x compatibility, 2.4.x can use diff -urN RC13-rc7-other-helpers/include/linux/sched.h RC13-rc7-includes/include/linux/sched.h --- RC13-rc7-other-helpers/include/linux/sched.h2005-08-25 00:54:17.0 -0400 +++ RC13-rc7-includes/include/linux/sched.h 2005-08-25 00:54:18.0 -0400 @@ -1136,6 +1136,8 @@ spin_unlock(&p->alloc_lock); } +#ifndef __HAVE_THREAD_FUNCTIONS + #define task_thread_info(task) (task)->thread_info static inline void setup_thread_info(struct task_struct *p, struct thread_info *ti) @@ -1176,6 +1178,8 @@ return test_ti_thread_flag(task_thread_info(tsk), flag); } +#endif + static inline void set_tsk_need_resched(struct task_struct *tsk) { set_tsk_thread_flag(tsk,TIF_NEED_RESCHED); diff -urN RC13-rc7-other-helpers/include/linux/smp_lock.h RC13-rc7-includes/include/linux/smp_lock.h --- RC13-rc7-other-helpers/include/linux/smp_lock.h 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-includes/include/linux/smp_lock.h 2005-08-25 00:54:18.0 -0400 @@ -2,11 +2,10 @@ #define __LINUX_SMPLOCK_H #include +#ifdef CONFIG_LOCK_KERNEL #include #include -#ifdef CONFIG_LOCK_KERNEL - #define kernel_locked()(current->lock_depth >= 0) extern int __lockfunc __reacquire_kernel_lock(void); diff -urN RC13-rc7-other-helpers/include/linux/thread_info.h RC13-rc7-includes/include/linux/thread_info.h --- RC13-rc7-other-helpers/include/linux/thread_info.h 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-includes/include/linux/thread_info.h 2005-08-25 00:54:18.0 -0400 @@ -22,6 +22,7 @@ #ifdef __KERNEL__ +#ifndef __HAVE_THREAD_FUNCTIONS /* * flag set/clear/test wrappers * - pass TIF_ constants to these functions @@ -88,5 +89,6 @@ } #endif +#endif #endif /* _LINUX_THREAD_INFO_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] (9/22) wrong ifdefs in 82596
ifdefs around variable declaration would better match those around its uses... Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-lance/drivers/net/82596.c RC13-rc7-82596-apricot/drivers/net/82596.c --- RC13-rc7-lance/drivers/net/82596.c 2005-08-10 10:37:49.0 -0400 +++ RC13-rc7-82596-apricot/drivers/net/82596.c 2005-08-25 00:54:10.0 -0400 @@ -614,7 +614,7 @@ static int init_i596_mem(struct net_device *dev) { struct i596_private *lp = dev->priv; -#if !defined(ENABLE_MVME16x_NET) && !defined(ENABLE_BVME6000_NET) +#if !defined(ENABLE_MVME16x_NET) && !defined(ENABLE_BVME6000_NET) || defined(ENABLE_APRICOT) short ioaddr = dev->base_addr; #endif unsigned long flags; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: cpu_exclusive sched domains fix broke ppc64
A day or two ago, Paul M. wrote: > Compiling -rc7 for ppc64 using pSeries_defconfig I get this compile > error: Not that the following really matters ... I've already sent in a fix, based on your analysis, followed by Nick's suggestion that we don't do it this way anyway. ... however ... question for Paul M. ... what version of gcc did this fail on? I finally got my crosstools setup working for me again, and building a powerpc64 using gcc-3.4.0 on my Intel PC box does _not_ fail. That build goes through fine. This is with CONFIG_CPUSETS=y, but without my fix of early this Wednesday to put the cpumask in question into a local variable. Either I've managed to confuse myself (most likely) or else this gcc 3.4 is newer than you were using, and this newer gcc has gotten smart enough to unravel this particular case and recognize that there actually is already a memory object (the array of cpumasks, one per node, specifying which cpus are on that node) laying around that can be used here. Strange. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (18/22) task_thread_info - part 2/4
encapsulates the rest of arch-dependent operations with thread_info access. Two new helpers - setup_thread_info() and end_of_stack(). For normal case the former consists of copying thread_info of parent to new thread_info and the latter returns pointer immediately past the end of thread_info. Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-task_thread_info/include/linux/sched.h RC13-rc7-other-helpers/include/linux/sched.h --- RC13-rc7-task_thread_info/include/linux/sched.h 2005-08-25 00:54:17.0 -0400 +++ RC13-rc7-other-helpers/include/linux/sched.h2005-08-25 00:54:17.0 -0400 @@ -1138,6 +1138,16 @@ #define task_thread_info(task) (task)->thread_info +static inline void setup_thread_info(struct task_struct *p, struct thread_info *ti) +{ + *ti = *p->thread_info; +} + +static inline unsigned long *end_of_stack(struct task_struct *p) +{ + return (unsigned long *)(p->thread_info + 1); +} + /* set thread flags in other task's structures * - see asm/thread_info.h for TIF_ flags available */ diff -urN RC13-rc7-task_thread_info/kernel/fork.c RC13-rc7-other-helpers/kernel/fork.c --- RC13-rc7-task_thread_info/kernel/fork.c 2005-08-25 00:54:17.0 -0400 +++ RC13-rc7-other-helpers/kernel/fork.c2005-08-25 00:54:17.0 -0400 @@ -169,8 +169,8 @@ return NULL; } - *ti = *orig->thread_info; *tsk = *orig; + setup_thread_info(tsk, ti); tsk->thread_info = ti; ti->task = tsk; diff -urN RC13-rc7-task_thread_info/kernel/sched.c RC13-rc7-other-helpers/kernel/sched.c --- RC13-rc7-task_thread_info/kernel/sched.c2005-08-25 00:54:17.0 -0400 +++ RC13-rc7-other-helpers/kernel/sched.c 2005-08-25 00:54:17.0 -0400 @@ -4121,10 +4121,10 @@ #endif #ifdef CONFIG_DEBUG_STACK_USAGE { - unsigned long * n = (unsigned long *) (p->thread_info+1); + unsigned long * n = end_of_stack(p); while (!*n) n++; - free = (unsigned long) n - (unsigned long)(p->thread_info+1); + free = (unsigned long) n - (unsigned long) end_of_stack(p); } #endif printk("%5lu %5d %6d ", free, p->pid, p->parent->pid); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (20/22) task_thread_info - part 3/4
Bah... I can't count, apparently. That one is 4/5, the next is 5/5. My apologies - cut'n'waste damage while editing patchset description.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/22) compile fixes for dmsound (static vs. extern)
sound/oss/dmasound/dmasound_atari.c has static expand_bal sound/oss/dmasound/dmasound_q40.c has static expand_bal sound/oss/dmasound/dmasound_awacs.c has non-static expand_bal sound/oss/dmasound/trans_16.c uses expand_bal from dmasound_awacs.c all 4 include dmasound.h; extern for expand_bal used to be there, which is a bloody bad idea, considering _atari and _q40. Moved the extern to trans_16.c. Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound.h RC13-rc7-dmasound-extern/sound/oss/dmasound/dmasound.h --- RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound.h 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-dmasound-extern/sound/oss/dmasound/dmasound.h 2005-08-25 00:54:05.0 -0400 @@ -270,7 +270,6 @@ #define SW_INPUT_VOLUME_SCALE 4 #define SW_INPUT_VOLUME_DEFAULT(128 / SW_INPUT_VOLUME_SCALE) -extern int expand_bal; /* Balance factor for expanding (not volume!) */ extern int expand_read_bal;/* Balance factor for reading */ extern uint software_input_volume; /* software implemented recording volume! */ diff -urN RC13-rc7-dmasound-lvalues/sound/oss/dmasound/trans_16.c RC13-rc7-dmasound-extern/sound/oss/dmasound/trans_16.c --- RC13-rc7-dmasound-lvalues/sound/oss/dmasound/trans_16.c 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-dmasound-extern/sound/oss/dmasound/trans_16.c 2005-08-25 00:54:05.0 -0400 @@ -17,6 +17,7 @@ #include #include "dmasound.h" +extern int expand_bal; /* Balance factor for expanding (not volume!) */ static short dmasound_alaw2dma16[] ; static short dmasound_ulaw2dma16[] ; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (5/22) static vs. extern in amigaints.h
extern declaration of static object removed from header Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h RC13-rc7-amigaints/include/asm-m68k/amigaints.h --- RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-amigaints/include/asm-m68k/amigaints.h 2005-08-25 00:54:07.0 -0400 @@ -109,8 +109,6 @@ extern void amiga_do_irq(int irq, struct pt_regs *fp); extern void amiga_do_irq_list(int irq, struct pt_regs *fp); -extern unsigned short amiga_intena_vals[]; - /* CIA interrupt control register bits */ #define CIA_ICR_TA 0x01 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/22) lvalues abuse in dmasound
result of typecast is not an lvalue. Part of those are fixed in m68k CVS. Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7/sound/oss/dmasound/dmasound_atari.c RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound_atari.c --- RC13-rc7/sound/oss/dmasound/dmasound_atari.c2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound_atari.c 2005-08-25 00:54:04.0 -0400 @@ -217,8 +217,9 @@ used = count*2; while (count > 0) { u_short data; - if (get_user(data, ((u_short *)userPtr)++)) + if (get_user(data, (u_short *)userPtr)) return -EFAULT; + userPtr += 2; *p++ = data ^ 0x8080; count--; } @@ -240,8 +241,9 @@ used = count*2; while (count > 0) { u_short data; - if (get_user(data, ((u_short *)userPtr)++)) + if (get_user(data, (u_short *)userPtr)) return -EFAULT; + userPtr += 2; *p++ = data; *p++ = data; count--; @@ -271,8 +273,9 @@ used = count*2; while (count > 0) { u_short data; - if (get_user(data, ((u_short *)userPtr)++)) + if (get_user(data, (u_short *)userPtr)) return -EFAULT; + userPtr += 2; data ^= 0x8000; *p++ = data; *p++ = data; @@ -285,8 +288,9 @@ used = count*4; while (count > 0) { u_long data; - if (get_user(data, ((u_int *)userPtr)++)) + if (get_user(data, (u_int *)userPtr)) return -EFAULT; + userPtr += 4; *p++ = data ^ 0x80008000; count--; } @@ -309,8 +313,9 @@ used = count*2; while (count > 0) { u_short data; - if (get_user(data, ((u_short *)userPtr)++)) + if (get_user(data, (u_short *)userPtr)) return -EFAULT; + userPtr += 2; data = le2be16(data); *p++ = data; *p++ = data; @@ -323,8 +328,9 @@ used = count*4; while (count > 0) { u_long data; - if (get_user(data, ((u_int *)userPtr)++)) + if (get_user(data, (u_int *)userPtr)) return -EFAULT; + userPtr += 4; data = le2be16dbl(data); *p++ = data; count--; @@ -348,8 +354,9 @@ used = count*2; while (count > 0) { u_short data; - if (get_user(data, ((u_short *)userPtr)++)) + if (get_user(data, (u_short *)userPtr)) return -EFAULT; + userPtr += 2; data = le2be16(data) ^ 0x8000; *p++ = data; *p++ = data; @@ -361,8 +368,9 @@ used = count; while (count > 0) { u_long data; - if (get_user(data, ((u_int *)userPtr)++)) + if (get_user(data, (u_int *)userPtr)) return -EFAULT; + userPtr += 4; data = le2be16dbl(data) ^ 0x80008000; *p++ = data; count--; @@ -470,8 +478,9 @@ if (bal < 0) { if (userCount < 2) break; - if (get_user(data, ((u_short *)userPtr)++)) + if (get_user(data, (u_short *)userPtr)) return -EFAULT; + userPtr += 2; userCount -= 2; bal += hSpeed; } @@ -524,8 +533,9 @@ if (bal < 0) { if (userCount < 2) break; - if (get_user(data, ((u_short *)userPtr)++)) + if (get_user(data, (u_short *)userPtr)) return -EFAULT; +
[PATCH] (13/22) isa_{type,sex} should be exported (m68k)
missing export on m68k Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-m68k-mul/arch/m68k/kernel/setup.c RC13-rc7-isa_type/arch/m68k/kernel/setup.c --- RC13-rc7-m68k-mul/arch/m68k/kernel/setup.c 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-isa_type/arch/m68k/kernel/setup.c 2005-08-25 00:54:13.0 -0400 @@ -100,6 +100,8 @@ #if defined(CONFIG_ISA) && defined(MULTI_ISA) int isa_type; int isa_sex; +EXPORT_SYMBOL(isa_type); +EXPORT_SYMBOL(isa_sex); #endif extern int amiga_parse_bootinfo(const struct bi_record *); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (4/22) bogus function argument types (sun3_pgtable.h)
function arguments can not be inline, TYVM... Signed-off-by: Al Viro <[EMAIL PROTECTED]> diff -urN RC13-rc7-sun3ints/include/asm-m68k/sun3_pgtable.h RC13-rc7-sun3_pgtable/include/asm-m68k/sun3_pgtable.h --- RC13-rc7-sun3ints/include/asm-m68k/sun3_pgtable.h 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-sun3_pgtable/include/asm-m68k/sun3_pgtable.h 2005-08-25 00:54:07.0 -0400 @@ -211,7 +211,7 @@ return pte.pte & SUN3_PAGE_PGNUM_MASK; } -static inline pte_t pgoff_to_pte(inline unsigned off) +static inline pte_t pgoff_to_pte(unsigned off) { pte_t pte = { off + SUN3_PAGE_ACCESSED }; return pte; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()
From: Andi Kleen <[EMAIL PROTECTED]> > > Hi, > > > > The following patch does not use MMX regsiters so that we don't have > > to worry about save/restore the FPU/MMX states. > > > > What do you think? > > Performance will probably be bad on K7 Athlons - those have a microcoded > movnti which is quite slow. > > Also BTW I don't see any code anywhere that tests the CPUID bits, > so your code will fail spectacularly on a PII that didn't do SSE > (intel user copy used to be enabled on those) > > One way to solve this might be to use different code using > alternative() > > -Andi Thanks for your comments. I'll consider it. Regards, Hiro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 3/3] exterminate strtok - usr/gen_init_cpio.c
On Wed, Aug 24, 2005 at 09:08:53PM +0200, Jesper Juhl wrote: > Convert strtok() use to strsep() in usr/gen_init_cpio.c > > I've compile tested this patch and it compiles fine. > I build a 2.6.13-rc6-mm2 kernel with the patch applied without problems, and > the resulting kernel boots and runs just fine (using it right now). > But despite this basic testing it would still be nice if someone would > double-check that I haven't made some silly mistake that would break some > other setup than mine. This is userland - I see no point in uglyfying the code. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()
From: Hirokazu Takahashi <[EMAIL PROTECTED]> > > The following patch does not use MMX regsiters so that we don't have > > to worry about save/restore the FPU/MMX states. > > > > What do you think? > > I think __copy_user_zeroing_intel_nocache() should be followed by sfence > or mfence instruction to flush the data. Thanks. I'll implement it. Regards, Hiro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12 Performance problems
Danial Thom wrote: I think the concensus is that 2.6 has made trade offs that lower raw throughput, which is what a networking device needs. So as a router or network appliance, 2.6 seems less suitable. A raw bridging test on a 2.0Ghz operton system: FreeBSD 4.9: Drops no packets at 900K pps Linux 2.4.24: Starts dropping packets at 350K pps Linux 2.6.12: Starts dropping packets at 100K pps I ran some quick tests using kernel 2.6.11, 1ms tick (HZ=1000), SMP kernel. Hardware is P-IV 3.0Ghz + HT on a new SuperMicro motherboard with 64/133Mhz PCI-X bus. NIC is dual Intel pro/1000. Kernel is close to stock 2.6.11. I used brctl to create a bridge with the two GigE adapters in it and used pktgen to stream traffic through it (250kpps in one direction, 1kpps in the other.) I see a reasonable amount of drops at 250kpps (60 byte packets): about 60,000,000 packets received, 20,700 dropped. Interestingly, the system is about 60% idle according to top, and still dropping pkts, so it would seem that the system could be better utilized! Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.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 3/3] exterminate strtok - usr/gen_init_cpio.c
Horst wrote: > > - if ('\n' == *type) { > > + if (!*type || '\n' == *type) { > > Redundant. If *type == '\n', it is certainly != 0. No - I don't think redundant, at least not this change in isolation. Perhaps redundant in light of subsequent code lines, as Jesper notes in his followup. But it is confusing to read - poor and inconsistent choice of code phrasing. If the patch had read as: - if (*type == '\n') { + if (*type == '\n' || *type == '\0') { then it would be clearer to the reader in my view. A check for newline is changed to a check for newline or nul-byte. (Yes - I recognize that one is not given the freedom to change the -old- lines in a patch for the sake of clarity ;). -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel
Could anyone inform which will be a good guide to start learning the linux kernel programming. -- Shwetha V Software Engineer - Networks Business Unit Sasken Communication Technologies Ltd. Gold Hill Square, Hosur Road, Bangalore. Ph: +91-80-25355501 Ext: 5799 Web: www.sasken.com "Srinivas K" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > hi friends, > > post concepts regarding linux kernel which will be useful > > > -- > Srinivasa Rao K > Systems Engineer > Nortel Business Unit > Sasken Communication Technologies Ltd > 139/25, Ring Road, Domlur > Bangalore - 560 071 > Ph: 2535 5501 Extn.:4804 > mail : [EMAIL PROTECTED] > > "SASKEN RATED THE BEST EMPLOYER IN THE COUNTRY by the BUSINESS TODAY > Mercer > Survey 2004" > > > SASKEN BUSINESS DISCLAIMER > This message may contain confidential, proprietary or legally Privileged > information. In case you are not the original intended Recipient of the > message, you must not, directly or indirectly, use, Disclose, distribute, > print, or copy any part of this message and you are requested to delete it > and inform the sender. Any views expressed in this message are those of > the > individual sender unless otherwise stated. Nothing contained in this > message > shall be construed as an offer or acceptance of any offer by Sasken > Communication Technologies Limited ("Sasken") unless sent with that > express > intent and with due authority of Sasken. Sasken has taken enough > precautions > to prevent the spread of viruses. However the company accepts no liability > for any damage caused by any virus transmitted by this email > > "SASKEN RATED THE BEST EMPLOYER IN THE COUNTRY by the BUSINESS TODAY Mercer Survey 2004" SASKEN BUSINESS DISCLAIMER This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] LSM hook updates
On Wed, 24 Aug 2005, Chris Wright wrote: > This is based on Kurt's original work. The net effect is that > LSM hooks are called conditionally, and in all cases capabilities > provide the defaults. I've done some basic performance testing, and > found nothing surprising. Do you mean nothing noticable? > I'm interested to see numbers from others > before I push this up. These are against Linus' current git tree (they > will clash with the -mm tree). Are there any numbers for popular architectures like i386 and x86_64? - James -- James Morris <[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/
Initramfs and TMPFS!
>Also, tar should be an option instead of cpio for the archiver, >because tar is more widely used. >>pretty much everyone will have cpio and it's format is much >>simpler/cleaner to deal with >>if we want vastly more complex early-userspace semantics i think we >>need to carefully decide what is needed and how to put as much of that >>logic into userspace rather than hacking this much more in the kernel >>for fear of breaking things in subtle ways I don't know, because tar is probably more widely used and consequently people are more familiar with how to use it. But, that is not as important as having the option of using tmpfs as the initramfs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>It uses 50% of total memory for tmpfs, but it would be nice to have >an option (tmpfs_size=90% etc.) that you could pass to the kernel. >>that's just because of the tmpfs default; you can remount to change >>that if it's not suitable once your up and running in your >>init-scripts or whatever Right, but it would be nice to have that option if initramfs using tmpfs becomes part of the kernel. >You need to add this to init/main.c for it to compile. >#include >>hmm... really? i'll rediff it at some point and test it maybe. i >>really don't like the explicity shm init though, i'd like to think of >>a cleaner way to do that You get this error without it. init/main.c: In function `overmount_rootfs': init/main.c:663: warning: implicit declaration of function `get_fs' init/main.c:663: error: incompatible types in assignment init/main.c:664: warning: implicit declaration of function `set_fs' init/main.c:664: error: `KERNEL_DS' undeclared (first use in this function) init/main.c:664: error: (Each undeclared identifier is reported only once init/main.c:664: error: for each function it appears in.) make[1]: *** [init/main.o] Error 1 make: *** [init] Error 2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[KCONFIG] Can't compile 2.6.12 without Gettext
Hi, I didn't see much informations about this. It's not possible to "make {,menu}config" and even to compile a 2.6.12 kernel if there is no or partially installed Gettext on the system. Full Gettext is *required* to launch the kbuild scripts since the modifications to add i18n to the config scripts. Not all system have gettext, I'm thinking about small or embedded system with specific toolchain. For example, uClibc is widely used but as still a partial nls support. Anyway, this should not be required for compiling a kernel. At least an option to pass to make which override the default behavior could solve the issue. Moreover, the script doesn't do any sanity check about the system (there is no configure script of course) and just try to catch the gettext binaries he founds first. There is a hard-coded filename too. Seems dangerous to me and should not be allowed by default. Am I misleading ? -- Jerome Pinot ftp://ngc891.blogdns.net/pub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] for acpi S1 power cycle resume problems
> Date: Fri, 19 Aug 2005 08:39:25 -0600 > From: "William Morrow" <[EMAIL PROTECTED]> > Subject: [PATCH] for acpi S1 power cycle resume problems > > > Hi > I was told that if I had a patch to submit for a baseline change that > this was the place to do it. In this case that works fine. Normally they should go to linux-usb-devel for me (and others) to read there. Thanks, these need a bit of cleaning up, finishing, and splitting out; they should be in 2.6.14 though. Comments below. Were these patches written by you, or by Jordan? - Dave > If not, please let me know... > > thanks, > morrow > > Patched against 2.6.11 baseline > problems fixed: > 1) OHCI_INTR_RD not being cleared in ohci interrupt handler > results in interrupt storm and system hang on RD status. > ohci spec indicates this should be done. Yeah, I noticed that one but didn't fix it yet. It's not that it was _never_ cleared ... only certain code paths missed it. The systems I test with were clearly using those working paths! Having this fixed should help get rid of the 1/4 second timer this driver normally ties up. That'll help make the dynamic tick stuff work better, reducing power even when something like "ACPI S1" doesn't exist (like say, on that one Zaurus). > 2) PORT_CSC not being cleared in ehci_hub_status_data > code attempts to clear bit, but bit is write to clear. > there are other errant clears, since the PORTSCn regs > have 3 RWC bits, and the rest are RW. All stmts of the form: >writel (v, &ehci->regs->port_status[i]) > should clear RWC bits if they do not intend to clear status, > and should set the bits which should be cleared (this case). Yeah, whoever did that RWC patch for UHCI ports certainly should have checked other HCDs for the same bug. (Kicks self.) In fact you didn't fix this issue comprehensively. There are other places that register is written; they need to change too. This is clearly wrong, but did you notice any effects more serious than "lsusb -v" output for EHCI root hubs looking a bit strange? > 3) loop control and subsequent port resume/reset not correct. > unsigned index made detecting port1 active impossible, Odd, I've done that with some regularity. Is that maybe some kind of compiler bug? (I heard even 4.1 isn't quite there yet for kernels.) The looping doesn't look incorrect to me; ports are numbered from 1..N, and C code in the body must index them from 0..(N-1). > and OWNER/POWER status was being ignored on ports assigned > to companion controller. Well, in that one resume case anyway! But OWNER and POWER are very different status bits ... if POWER ever goes off, that port is by definition not resumable. But if a port's owned by the companion (OHCI or UHCI) controller, then it surely ought not to be reset (even if the companion's own SUSPEND bit doesn't show through EHCI). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6: halt instead of reboot
Meelis Roos <[EMAIL PROTECTED]> writes: >>> It does not hang, it just powers off like on halt. >> >> Ok. Then at least in part the kernel behavior is either >> intersecting with a BIOS bug, a bad reboot script that calls halt instead, >> or a driver that is scribbling on the wrong register. There is >> nothing in that code path that should remove the power. > > With reboot=c, reboot=w and reboot=h it still powers off. With reboot=b it > actually reboots. With 2.6.13-rc2 (the previous good kernel here) it just > works > and does a reboot with no special parameters. > > I also have lapic nmi_watchdog=1 in boot command line but removing these does > not help either. > > So far I only know that rc6+somegit and rc7 power off and rc2 works, will try > som kernels inbetween. Hmm. Odd. When skimming through the code I thought that reboot_thru_bios was the default. So the code is currently trying a reset through the keyboard controller and a triple fault and neither work. If you can't track this down we can at least dig up your board DMI ID and put it in the list of systems that need to go through the BIOS to reboot. 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: Initramfs and TMPFS!
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote: > Also, tar should be an option instead of cpio for the archiver, > because tar is more widely used. pretty much everyone will have cpio and it's format is much simpler/cleaner to deal with if we want vastly more complex early-userspace semantics i think we need to carefully decide what is needed and how to put as much of that logic into userspace rather than hacking this much more in the kernel for fear of breaking things in subtle ways - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Initramfs and TMPFS!
On Wed, Aug 24, 2005 at 06:41:26PM -0400, [EMAIL PROTECTED] wrote: > I tried it with kernel 2.6.13-rc5 and it seems to work. it should yes > It uses 50% of total memory for tmpfs, but it would be nice to have > an option (tmpfs_size=90% etc.) that you could pass to the kernel. that's just because of the tmpfs default; you can remount to change that if it's not suitable once your up and running in your init-scripts or whatever > You need to add this to init/main.c for it to compile. > #include hmm... really? i'll rediff it at some point and test it maybe. i really don't like the explicity shm init though, i'd like to think of a cleaner way to do that - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-rc6] dcdbas: add Dell Systems Management Base Driver with sysfs support
On Wed, Aug 24, 2005 at 09:00:21PM -0500, Doug Warzecha wrote: [...] > +Dell OpenManage requires this driver on the following Dell PowerEdge systems: > +300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC, > +700, and 750. Other Dell software such as the open source Libsmbios library > +is expected to make use of this driver, and it may include the use of this > +driver on other Dell systems. I'd like to see a URL/pointer somewhere about here in the docs for the location of libsmbios if nobody objects. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PowerOP Take 2 2/3: sysfs UI core
A sysfs interface for PowerOP that allows operating points to be created and activated from userspace. The platform-specific backend provides the code to read and write sysfs attributes for each power parameter; the core sysfs interface has no knowledge of the struct powerop_point contents. This interface could be used independently of an integrated cpufreq or DPM interface. It is not an integral part of PowerOP and is provided in part to facilitate discussion and experimentation with PowerOP, but could serve as a basis for a basic userspace power policy management stack. Operating points are created by writing the name of the operating point to /sys/powerop/new. This may be a job for configfs. /sys/powerop// will contain an attribute for each power parameter that may be written to set the associated parameter for the new operating point. An operating point may be activated by writing its name to /sys/powerop/active. The hardware power parameters currently set may be read and written via /sys/powerop/hw/, a special operating point that reads and writes parameter attribute values immediately, primarily for diagnostic purposes. Buried in this interface is also the notion of a registry of "named operating points", allowing operating points created by some other interface (such as cpufreq or loading a module with the definitions as suggested previously by David Brownell) to be activated from userspace via /sys/powerop/active. Changing operating points (or other power-policy-based information that triggers changes in operating points) from userspace is a common scenario in some embedded systems, where power/performance needs change based on system state changes that are coordinated by a userspace process (for example, a mobile phone starting a multimedia application). Index: linux-2.6.13-rc4/drivers/powerop/Kconfig === --- /dev/null +++ linux-2.6.13-rc4/drivers/powerop/Kconfig @@ -0,0 +1,4 @@ +config POWEROP_SYSFS + bool " Enable PowerOP sysfs interface" + depends on POWEROP && SYSFS + help Index: linux-2.6.13-rc4/drivers/powerop/Makefile === --- /dev/null +++ linux-2.6.13-rc4/drivers/powerop/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_POWEROP_SYSFS)+= powerop_sysfs.o Index: linux-2.6.13-rc4/drivers/powerop/powerop_sysfs.c === --- /dev/null +++ linux-2.6.13-rc4/drivers/powerop/powerop_sysfs.c @@ -0,0 +1,398 @@ +/* + * PowerOP sysfs UI + * + * Author: Todd Poynor <[EMAIL PROTECTED]> + * + * 2005 (c) MontaVista Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +int powerop_register_point(const char *id, struct powerop_point *point); +int powerop_select_point(const char *id); + +struct namedop { + struct kobject kobj; + struct powerop_point *point; + struct list_head node; + struct completion released; +}; + +#define to_namedop(_kobj) container_of(_kobj,\ + struct namedop,kobj) + +static DECLARE_MUTEX(namedop_list_mutex); +static struct list_head namedop_list; +static struct namedop *activeop; + +struct sysfsop { + struct powerop_point point; + struct list_head node; +}; + +static DECLARE_MUTEX(sysfsop_list_mutex); +static struct list_head sysfsop_list; + +static struct powerop_point *hwop; + +#define powerop_attr(_name) \ +static struct subsys_attribute _name##_attr = { \ + .attr = { \ + .name = __stringify(_name), \ + .mode = 0644, \ + .owner = THIS_MODULE, \ + }, \ + .show = _name##_show, \ + .store = _name##_store,\ +} + +static struct attribute_group param_attr_group; + +#define to_powerop_param_attr(_attr) container_of(_attr,\ + struct powerop_param_attribute,attr) + + +decl_subsys(powerop, NULL, NULL); +static int subsys_reg; +static int sysfs_init; + +static void namedop_release(struct kobject *kobj) +{ + struct namedop *op = to_namedop(kobj); + + complete(&op->released); + return; +} + +static struct sysfsop *sysfsop_create(const char *id) +{ + struct sysfsop *op; + int error; + + if ((op = kmalloc(sizeof(struct sysfsop), GFP_KERNEL)) == NULL) + return ERR_PTR(-ENOMEM); + + down(&sysfsop_list_mutex); + list_add_tail(&op->node, &sysfsop_list); + up(&sysfsop_list_mutex); + memset(&op->point, 0, sizeof(struct powerop_point)); + return (error = powerop_register_point(id, &op->point)) == 0 +
PowerOP Take 2 3/3: OMAP1 sysfs UI
A PowerOP sysfs UI backend for OMAP1 platforms, adding sysfs attributes and show/store functions that correspond to the platform power parameters. An example usage on an OMAP1510 Innovator which does not have voltage scaling and ignoring the DSP: # echo -n 168-168-84 > /sys/powerop/new # DPLL 168MHz, ARM 168MHz, TC 84MHz # echo -n 14 > /sys/powerop/168-168-84/dpllmult # echo -n 0 > /sys/powerop/168-168-84/dplldiv # echo -n 0 > /sys/powerop/168-168-84/armdiv # echo -n 1 > /sys/powerop/168-168-84/tcdiv # echo -n -1 > /sys/powerop/168-168-84/dspdiv # echo -n -1 > /sys/powerop/168-168-84/lowpwr # echo -n 60-60-60 > /sys/powerop/new # DPLL 60MHz, ARM 60MHz, TC 60MHz # echo -n 5 > /sys/powerop/60-60-60/dpllmult # echo -n 0 > /sys/powerop/60-60-60/dplldiv # echo -n 0 > /sys/powerop/60-60-60/armdiv # echo -n 0 > /sys/powerop/60-60-60/tcdiv # echo -n -1 > /sys/powerop/60-60-60/dspdiv # echo -n -1 > /sys/powerop/60-60-60/lowpwr # echo -n 60-60-60 > /sys/powerop/active # cat /sys/powerop/hw/dpllmult 5 The lower-powered operating point consumes about .07A less power using my .config (it should be noted this is not a proper low-power evaluation platform). Index: linux-2.6.13-rc4/arch/arm/mach-omap1/Kconfig === --- linux-2.6.13-rc4.orig/arch/arm/mach-omap1/Kconfig +++ linux-2.6.13-rc4/arch/arm/mach-omap1/Kconfig @@ -155,3 +155,5 @@ source "arch/arm/plat-omap/dsp/Kconfig" config POWEROP bool "PowerOP Platform Core Power Management for OMAP1" help + +source "drivers/powerop/Kconfig" Index: linux-2.6.13-rc4/arch/arm/mach-omap1/powerop.c === --- linux-2.6.13-rc4.orig/arch/arm/mach-omap1/powerop.c +++ linux-2.6.13-rc4/arch/arm/mach-omap1/powerop.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include @@ -144,13 +145,141 @@ powerop_set_point(struct powerop_point * EXPORT_SYMBOL_GPL(powerop_get_point); EXPORT_SYMBOL_GPL(powerop_set_point); +#ifdef CONFIG_POWEROP_SYSFS + +ssize_t lowpwr_show(struct powerop_point *op, char * buf) +{ + return sprintf(buf,"%d\n",op->lowpwr); +} + +ssize_t lowpwr_store(struct powerop_point *op, const char * buf, size_t count) +{ + int error; + + if ((error = sscanf(buf, "%d", &op->lowpwr)) == 1) + return count; + return error; +} + +powerop_param_attr(lowpwr); + +ssize_t dpllmult_show(struct powerop_point *op, char * buf) +{ + return sprintf(buf,"%d\n",op->dpllmult); +} + +ssize_t dpllmult_store(struct powerop_point *op, const char * buf, size_t count) +{ + int error; + + if ((error = sscanf(buf, "%d", &op->dpllmult)) == 1) + return count; + return error; +} + +powerop_param_attr(dpllmult); + +ssize_t dplldiv_show(struct powerop_point *op, char * buf) +{ + return sprintf(buf,"%d\n",op->dplldiv); +} + +ssize_t dplldiv_store(struct powerop_point *op, const char * buf, size_t count) +{ + int error; + + if ((error = sscanf(buf, "%d", &op->dplldiv)) == 1) + return count; + return error; +} + +powerop_param_attr(dplldiv); + +ssize_t armdiv_show(struct powerop_point *op, char * buf) +{ + return sprintf(buf,"%d\n",op->armdiv); +} + +ssize_t armdiv_store(struct powerop_point *op, const char * buf, size_t count) +{ + int error; + + if ((error = sscanf(buf, "%d", &op->armdiv)) == 1) + return count; + return error; +} + +powerop_param_attr(armdiv); + +ssize_t dspdiv_show(struct powerop_point *op, char * buf) +{ + return sprintf(buf,"%d\n",op->dspdiv); +} + +ssize_t dspdiv_store(struct powerop_point *op, const char * buf, size_t count) +{ + int error; + + if ((error = sscanf(buf, "%d", &op->dspdiv)) == 1) + return count; + return error; +} + +powerop_param_attr(dspdiv); + +ssize_t tcdiv_show(struct powerop_point *op, char * buf) +{ + return sprintf(buf,"%d\n",op->tcdiv); +} + +ssize_t tcdiv_store(struct powerop_point *op, const char * buf, size_t count) +{ + int error; + + if ((error = sscanf(buf, "%d", &op->tcdiv)) == 1) + return count; + return error; +} + +powerop_param_attr(tcdiv); + +static struct attribute *powerop_sysfs_param_attrs[] = { + &lowpwr_attr.attr, + &dpllmult_attr.attr, + &dplldiv_attr.attr, + &armdiv_attr.attr, + &dspdiv_attr.attr, + &tcdiv_attr.attr, + NULL, +}; + +static void powerop_omap1_sysfs_init() +{ + powerop_sysfs_register(powerop_sysfs_param_attrs); +} + +static void powerop_omap1_sysfs_exit() +{ + powerop_sysfs_unregister(powerop_sysfs_param_attrs); +} +#else /* CONFIG_POWEROP_SYSFS */ +static void powerop_omap1_sysfs_init() +{ +} +static void powerop_omap1_sysfs_exit() +{ +} +#endif /* CONFIG_POWEROP_SYSFS */ + static int __init powerop_init(void) { + powerop_omap1_sysfs_init(); return 0; } static
PowerOP Take 2 0/3 Intro
PowerOP is a system power parameter management API submitted for discussion. PowerOP writes and reads power "operating points", comprised of arbitrary values, called power parameters, that correspond to registers, clocks, dividers, voltage regulators, etc. that may be modified to set a basic power/performance point for the system. Higher-layer power management software passes a platform-specific struct of power parameters to a backend that makes the requested adjustments. PowerOP can be thought of as a layer below cpufreq that actually accesses the hardware to make cpu frequency, voltage, core bus, and perhaps other modifications to set a power point. The main goal is to open up interfaces to operating points comprised of arbitrary power parameters, as an alternative to the "cpu frequency" parameter that cpufreq is designed around. It pushes the hardware-level power parameter management down to a level that can be shared with other power management policy frameworks that deal with entire operating points as the basic unit of system power management for reasons described below, and that The new layer is intended to leave all power policy decisions, and various other power management chores such as driver notification, to higher layers in a power management software stack. This work is aimed in part at supporting embedded systems, which often have several parameters that can be set and the cpu frequency abstraction specifies only part of the operating point that may be managed from software. For example, an XScale PXA27x could be considered to have six basic power parameters (mainly cpu run mode and memory and bus dividers) that for the most part should be set in tandem to known good sets of values as validated by the silicon vendor. Embedded systems typically handle more hardware clock manipulation directly in Linux than do, for example, desktop/server systems based on ACPI interfaces. Desktop/server systems may also benefit from the ability to select custom voltages, bus speeds, etc., although deviating from values validated by the hardware vendor is risky and controversial. An optional sysfs interface to create and activate operating points is also submitted for discussion. This interface could be used in an actual power management stack, or at least can serve as a starting point for discussing how to manage operating points at the next higher layer in the power management soctware stack. cpufreq is another possible interface. PowerOP can fit below cpufreq to make cpu frequency, voltage, core bus, and perhaps other modifications to set a power point, leaving cpufreq to manage the interfaces based around the "cpu frequency" abstraction, the policies and governors that select the frequency, its notifiers, and so forth. An example hooking up support for one cpufreq platform to PowerOP has been previously submitted. Some discussion regarding incorporating an expanded set of power parameters into the cpufreq interfaces has also taken place. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hardware Perfromance Counters
Hello everyone, The system I am working on is a single processor Athlon. In the kernel I need to detect a cache miss (L1/L2) and trigger an event/function (inside the kernel). Now we have performance counters for detecting/counting cache misses. Among the various tools/patches available for accessing performance counters, which one do you guys recommend. Or do you think it would be easy to write code for this myself, as i just need this one event detection. Can you give some links where one can read about programming performance counters or some book on it. Thanks a lot. please cc reply to me too. -- Sushant Sharma http://cs.unm.edu/~sushant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PowerOP Take 2 1/3: ARM OMAP1 platform support
PowerOP support for OMAP1 platforms. Currently handles these power parameters: dpllmult DPLL_CTL reg PLL MULT bits dplldiv DPLL_CTL reg PLL DIV bits armdiv ARM_CKCTL reg ARMDIV bits dspdiv ARM_CKCTL reg DSPDIV bits tcdivARM_CKCTL reg TCDIV bits lowpwr 1 = assert ULPD LOW_PWR, voltage scale low Other parameters such as DSPMMUDIV, LCDDIV, and ARM_PERDIV might also be useful. Example usage will be shown with a follow-on sysfs UI patch. Index: linux-2.6.13-rc4/arch/arm/mach-omap1/powerop.c === --- /dev/null +++ linux-2.6.13-rc4/arch/arm/mach-omap1/powerop.c @@ -0,0 +1,157 @@ +/* + * PowerOP support for OMAP1 + * + * Based on DPM OMAP code by Matthew Locke, Dmitry Chigirev, Vladimir + * Barinov, and Todd Poynor. + * + * 2005 (c) MontaVista Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. + */ + +#include +#include +#include + +#include +#include +#include + +/* ARM_CKCTL bit shifts */ +#define CKCTL_PERDIV_OFFSET0 +#define CKCTL_LCDDIV_OFFSET2 +#define CKCTL_ARMDIV_OFFSET4 +#define CKCTL_DSPDIV_OFFSET6 +#define CKCTL_TCDIV_OFFSET 8 +#define CKCTL_DSPMMUDIV_OFFSET 10 + +#define DPLL_CTL_MASK 0xfe0 + +#define ULPD_MIN_MAX_REG (1 << 11) +#define ULPD_DVS_ENABLE (1 << 10) +#define ULPD_LOW_PWR_REQ (1 << 1) +#define LOW_POWER (ULPD_MIN_MAX_REG | ULPD_DVS_ENABLE | ULPD_LOW_PWR_REQ | \ + ULPD_LOW_PWR_EN) + +int +powerop_get_point(struct powerop_point *point) +{ + unsigned long flags; + int dpll_ctl, arm_cktl; + + local_irq_save(flags); + dpll_ctl = omap_readw(DPLL_CTL); + arm_cktl = omap_readw(ARM_CKCTL); + + point->dpllmult = dpll_ctl >> 7 & 0x1f; + point->dplldiv = dpll_ctl >> 5 & 0x3; + point->armdiv = arm_cktl >> CKCTL_ARMDIV_OFFSET & 0x3; + point->dspdiv = arm_cktl >> CKCTL_DSPDIV_OFFSET & 0x3; + point->tcdiv = arm_cktl >> CKCTL_TCDIV_OFFSET & 0x3; + point->lowpwr = (omap_readw(ULPD_POWER_CTRL) & (ULPD_LOW_PWR_REQ)) ? + 1 : 0; + local_irq_restore(flags); + return 0; +} + +static void scale_dpll(int dpll_ctl) +{ + int i; + + omap_writew((omap_readw(DPLL_CTL) & ~DPLL_CTL_MASK) | dpll_ctl, + DPLL_CTL); + + for (i = 0; i < 0x1FF; i++) + nop(); + + /* +* Wait for PLL relock. +*/ + + while ((omap_readw(DPLL_CTL) & 0x1) == 0); +} + +static void set_low_pwr(int lowpwr) +{ + int cur_lowpwr; + + if (lowpwr == -1) + return; + + cur_lowpwr = (omap_readw(ULPD_POWER_CTRL) & (ULPD_LOW_PWR_REQ)) ? + 1 : 0; + + if (cur_lowpwr != lowpwr) { + if (lowpwr) + omap_writew(omap_readw(ULPD_POWER_CTRL) | LOW_POWER, + ULPD_POWER_CTRL); + else + omap_writew(omap_readw(ULPD_POWER_CTRL) & ~LOW_POWER, + ULPD_POWER_CTRL); + } +} + +int +powerop_set_point(struct powerop_point *point) +{ + int dpll_ctl = 0; + int dpll_mod = 0; + int arm_ctl = 0; + int arm_msk = 0; + int cur_dpll_ctl; + unsigned long flags; + + if ((point->dpllmult != -1) && (point->dplldiv != -1)) { + dpll_ctl = (point->dpllmult << 7) | + (point->dplldiv << 5); + dpll_mod = 1; + } + + if (point->armdiv != -1) { + arm_ctl |= (point->armdiv << CKCTL_ARMDIV_OFFSET); + arm_msk |= (3 << CKCTL_ARMDIV_OFFSET); + } + + if (point->dspdiv != -1) { + arm_ctl |= (point->dspdiv << CKCTL_DSPDIV_OFFSET); + arm_msk |= (3 << CKCTL_DSPDIV_OFFSET); + } + + if (point->tcdiv != -1) { + arm_ctl |= (point->tcdiv << CKCTL_TCDIV_OFFSET); + arm_msk |= (3 << CKCTL_TCDIV_OFFSET); + } + + local_irq_save(flags); + cur_dpll_ctl = omap_readw(DPLL_CTL) & DPLL_CTL_MASK; + + if (dpll_mod && (dpll_ctl < cur_dpll_ctl)) + scale_dpll(dpll_ctl); + + if (arm_msk != 0) + omap_writew((omap_readw(ARM_CKCTL) & ~arm_msk) | arm_ctl, + ARM_CKCTL); + + if (dpll_mod && (dpll_ctl > cur_dpll_ctl)) + scale_dpll(dpll_ctl); + + set_low_pwr(point->lowpwr); + local_irq_restore(flags); + return 0; +} + +EXPORT_SYMBOL_GPL(powerop_get_point); +EXPORT_SYMBOL_GPL(powerop_set_point); + +static int __init powerop_init(void) +{ + return 0; +} + +static void __exit powerop_exit(void) +{ +} + +module_init(powerop_init); +module_exit(powerop_exit); Index: linux-2.6.13-rc4/include/asm-arm/arch-omap/powerop.h
Re: [PATCH] Add MCE resume under ia32
On Wed, 2005-08-24 at 10:50 +0200, Pavel Machek wrote: > Hi! > > > > > diff -puN arch/i386/power/cpu.c~mcheck_resume arch/i386/power/cpu.c > > > > --- linux-2.6.13-rc6/arch/i386/power/cpu.c~mcheck_resume > > > > 2005-08-23 09:32:13.054008584 +0800 > > > > +++ linux-2.6.13-rc6-root/arch/i386/power/cpu.c 2005-08-23 > > > > 09:41:54.992540480 +0800 > > > > @@ -104,6 +104,8 @@ static void fix_processor_context(void) > > > > > > > > } > > > > > > > > +extern void mcheck_init(struct cpuinfo_x86 *c); > > > > + > > > > void __restore_processor_state(struct saved_context *ctxt) > > > > { > > > > /* > > > > > > > > > this should go to some header file and most importantly > > If you agree my other points, I'll do this. Ok, updated one. Reinitialize MCE to avoid MCE non-fatal warning after resume. Signed-off-by: Shaohua Li<[EMAIL PROTECTED]> --- linux-2.6.13-rc6-root/arch/i386/kernel/cpu/common.c |5 + linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/k7.c |2 +- linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/mce.c |4 ++-- linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p4.c |4 ++-- linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p5.c |2 +- linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p6.c |2 +- linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/winchip.c |2 +- linux-2.6.13-rc6-root/arch/i386/power/cpu.c |1 + linux-2.6.13-rc6-root/include/asm-i386/processor.h |6 ++ 9 files changed, 16 insertions(+), 12 deletions(-) diff -puN arch/i386/kernel/cpu/mcheck/k7.c~mcheck_resume arch/i386/kernel/cpu/mcheck/k7.c --- linux-2.6.13-rc6/arch/i386/kernel/cpu/mcheck/k7.c~mcheck_resume 2005-08-24 17:00:32.0 +0800 +++ linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/k7.c 2005-08-24 17:00:32.0 +0800 @@ -69,7 +69,7 @@ static fastcall void k7_machine_check(st /* AMD K7 machine check is Intel like */ -void __devinit amd_mcheck_init(struct cpuinfo_x86 *c) +void amd_mcheck_init(struct cpuinfo_x86 *c) { u32 l, h; int i; diff -puN arch/i386/kernel/cpu/mcheck/mce.c~mcheck_resume arch/i386/kernel/cpu/mcheck/mce.c --- linux-2.6.13-rc6/arch/i386/kernel/cpu/mcheck/mce.c~mcheck_resume 2005-08-24 17:00:32.0 +0800 +++ linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/mce.c 2005-08-24 17:00:32.0 +0800 @@ -16,7 +16,7 @@ #include "mce.h" -int mce_disabled __devinitdata = 0; +int mce_disabled = 0; int nr_mce_banks; EXPORT_SYMBOL_GPL(nr_mce_banks); /* non-fatal.o */ @@ -31,7 +31,7 @@ static fastcall void unexpected_machine_ void fastcall (*machine_check_vector)(struct pt_regs *, long error_code) = unexpected_machine_check; /* This has to be run for each processor */ -void __devinit mcheck_init(struct cpuinfo_x86 *c) +void mcheck_init(struct cpuinfo_x86 *c) { if (mce_disabled==1) return; diff -puN arch/i386/kernel/cpu/mcheck/p4.c~mcheck_resume arch/i386/kernel/cpu/mcheck/p4.c --- linux-2.6.13-rc6/arch/i386/kernel/cpu/mcheck/p4.c~mcheck_resume 2005-08-24 17:00:32.0 +0800 +++ linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p4.c 2005-08-24 17:00:32.0 +0800 @@ -78,7 +78,7 @@ fastcall void smp_thermal_interrupt(stru } /* P4/Xeon Thermal regulation detect and init */ -static void __devinit intel_init_thermal(struct cpuinfo_x86 *c) +static void intel_init_thermal(struct cpuinfo_x86 *c) { u32 l, h; unsigned int cpu = smp_processor_id(); @@ -232,7 +232,7 @@ static fastcall void intel_machine_check } -void __devinit intel_p4_mcheck_init(struct cpuinfo_x86 *c) +void intel_p4_mcheck_init(struct cpuinfo_x86 *c) { u32 l, h; int i; diff -puN arch/i386/kernel/cpu/mcheck/p5.c~mcheck_resume arch/i386/kernel/cpu/mcheck/p5.c --- linux-2.6.13-rc6/arch/i386/kernel/cpu/mcheck/p5.c~mcheck_resume 2005-08-24 17:00:32.0 +0800 +++ linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p5.c 2005-08-24 17:00:32.0 +0800 @@ -29,7 +29,7 @@ static fastcall void pentium_machine_che } /* Set up machine check reporting for processors with Intel style MCE */ -void __devinit intel_p5_mcheck_init(struct cpuinfo_x86 *c) +void intel_p5_mcheck_init(struct cpuinfo_x86 *c) { u32 l, h; diff -puN arch/i386/kernel/cpu/mcheck/p6.c~mcheck_resume arch/i386/kernel/cpu/mcheck/p6.c --- linux-2.6.13-rc6/arch/i386/kernel/cpu/mcheck/p6.c~mcheck_resume 2005-08-24 17:00:32.0 +0800 +++ linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p6.c 2005-08-24 17:00:32.0 +0800 @@ -80,7 +80,7 @@ static fastcall void intel_machine_check } /* Set up machine check reporting for processors with Intel style MCE */ -void __devinit intel_p6_mcheck_init(struct cpuinfo_x86 *c) +void intel_p6_mcheck_init(struct cpuinfo_x86 *c) { u32 l, h; int i; diff -puN arch/i386/kernel/cpu/mcheck/winchip.c~mcheck_resu
RE: question on memory barrier
> Wrong. Reference: > > http://www.phy.duke.edu/~rgb/General/c_book/c_book/chapter8/sequen > ce_points.html > > Cheers, > Dick Johnson That discussion is wrong. The form of the argument is simply invalid. Just because an optimization could break things in some cases doesnt mean the compiler cant ever make the optimization. It just cant make the optimization in the case that breaks things. And by things I mean things that are defined in the standard that would be broken, not things outside of it. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] NTP ntp-helper functions
Andrew, All, This patch cleans up a commonly repeated set of changes to the NTP state variables by adding two helper inline functions: ntp_clear(): Clears the ntp state variables ntp_synced(): Returns 1 if the system is synced with a time server. This was compile tested for alpha, arm, i386, x86-64, ppc64, s390, sparc, sparc64. Please consider for inclusion into your tree. thanks -john Signed-off-by: John Stultz <[EMAIL PROTECTED]> linux-2.6.13-rc7_ntp-helpers_A0.patch = diff --git a/arch/alpha/kernel/time.c b/arch/alpha/kernel/time.c --- a/arch/alpha/kernel/time.c +++ b/arch/alpha/kernel/time.c @@ -149,7 +149,7 @@ irqreturn_t timer_interrupt(int irq, voi * CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be * called as close as possible to 500 ms before the new second starts. */ - if ((time_status & STA_UNSYNC) == 0 + if (ntp_synced() && xtime.tv_sec > state.last_rtc_update + 660 && xtime.tv_nsec >= 50 - ((unsigned) TICK_SIZE) / 2 && xtime.tv_nsec <= 50 + ((unsigned) TICK_SIZE) / 2) { @@ -502,10 +502,7 @@ do_settimeofday(struct timespec *tv) set_normalized_timespec(&xtime, sec, nsec); set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec); - time_adjust = 0;/* stop active adjtime() */ - time_status |= STA_UNSYNC; - time_maxerror = NTP_PHASE_LIMIT; - time_esterror = NTP_PHASE_LIMIT; + ntp_clear(); write_sequnlock_irq(&xtime_lock); clock_was_set(); diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c --- a/arch/arm/kernel/time.c +++ b/arch/arm/kernel/time.c @@ -102,7 +102,7 @@ static unsigned long next_rtc_update; */ static inline void do_set_rtc(void) { - if (time_status & STA_UNSYNC || set_rtc == NULL) + if (!ntp_synced() || set_rtc == NULL) return; if (next_rtc_update && @@ -292,10 +292,7 @@ int do_settimeofday(struct timespec *tv) set_normalized_timespec(&xtime, sec, nsec); set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec); - time_adjust = 0;/* stop active adjtime() */ - time_status |= STA_UNSYNC; - time_maxerror = NTP_PHASE_LIMIT; - time_esterror = NTP_PHASE_LIMIT; + ntp_clear(); write_sequnlock_irq(&xtime_lock); clock_was_set(); return 0; diff --git a/arch/arm26/kernel/time.c b/arch/arm26/kernel/time.c --- a/arch/arm26/kernel/time.c +++ b/arch/arm26/kernel/time.c @@ -114,7 +114,7 @@ static unsigned long next_rtc_update; */ static inline void do_set_rtc(void) { - if (time_status & STA_UNSYNC || set_rtc == NULL) + if (!ntp_synced() || set_rtc == NULL) return; //FIXME - timespec.tv_sec is a time_t not unsigned long @@ -189,10 +189,7 @@ int do_settimeofday(struct timespec *tv) xtime.tv_sec = tv->tv_sec; xtime.tv_nsec = tv->tv_nsec; - time_adjust = 0;/* stop active adjtime() */ - time_status |= STA_UNSYNC; - time_maxerror = NTP_PHASE_LIMIT; - time_esterror = NTP_PHASE_LIMIT; + ntp_clear(); write_sequnlock_irq(&xtime_lock); clock_was_set(); return 0; diff --git a/arch/cris/arch-v10/kernel/time.c b/arch/cris/arch-v10/kernel/time.c --- a/arch/cris/arch-v10/kernel/time.c +++ b/arch/cris/arch-v10/kernel/time.c @@ -240,7 +240,7 @@ timer_interrupt(int irq, void *dev_id, s * The division here is not time critical since it will run once in * 11 minutes */ - if ((time_status & STA_UNSYNC) == 0 && + if (ntp_synced() && xtime.tv_sec > last_rtc_update + 660 && (xtime.tv_nsec / 1000) >= 50 - (tick_nsec / 1000) / 2 && (xtime.tv_nsec / 1000) <= 50 + (tick_nsec / 1000) / 2) { diff --git a/arch/cris/kernel/time.c b/arch/cris/kernel/time.c --- a/arch/cris/kernel/time.c +++ b/arch/cris/kernel/time.c @@ -114,10 +114,7 @@ int do_settimeofday(struct timespec *tv) set_normalized_timespec(&xtime, sec, nsec); set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec); - time_adjust = 0;/* stop active adjtime() */ - time_status |= STA_UNSYNC; - time_maxerror = NTP_PHASE_LIMIT; - time_esterror = NTP_PHASE_LIMIT; + ntp_clear(); write_sequnlock_irq(&xtime_lock); clock_was_set(); return 0; diff --git a/arch/frv/kernel/time.c b/arch/frv/kernel/time.c --- a/arch/frv/kernel/time.c +++ b/arch/frv/kernel/time.c @@ -85,7 +85,7 @@ static irqreturn_t timer_interrupt(int i * CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be * called as close as possible to 500 ms before the new second starts. */ - if ((time_status & STA_UNSYNC) == 0 && + if (ntp_synced() && xtime.tv_sec > last_rtc_update + 660 &
Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
On Wed, 2005-08-24 at 18:44 -0700, George Anzinger wrote: > > Ok, so your forcing gettimeofday to be interval aware, so its applying > > different fixed NTP adjustments to different chunks of the current > > interval. The issue of course is if you're using fixed adjustments, is > > that you have to have n ntp adjustments for n intervals, or you have to > > apply the same ntp adjustment to multiple intervals. > > Uh, are you saying that one ntpd call can set up several different > adjustments? Well, it allows for frequency adjustments, tick adjustments, and offset adjustments in a single call or just the singleshot (adjtime) adjustment. However it does not give multiple scaling factors for different intervals, so you are correct there. > I was assuming that any given call would set up either a > fixed adjustment for ever or a fixed adjustment to be applied for a > fixed number of ticks (or until so much correcting was done, which, in > the end is the same thing at this point in the code). > > If ntpd has to come back to change the adjustment, I am assuming that > some kernel action can be taken at that time to sync the xtime clock and > the gettimeofday reading of it. I.e. we would only have to keep track > of one adjustment with a possible pre specified end time. Well, I guess a component of the adjustment would end at a specified time, that's true. > >>I would argue that only two terms are needed here regardless of > >>how late a tick is. This is because, I would expect the ntp system call > >>to sync the two clocks. This means in your example, the ntp call would > >>have been made at, or prior to the timer interrupt at 2 and this is the > >>same edge that gettimeofday is to used to start applying the correction. > > > > > > If you argue that we only need two adjustments, why not argue for only > > one? You're saying have one adjustment that you apply for the first > > tick's worth of time, and a second adjustment that you apply for the > > following N ticks' worth of time in the interval. Why the odd base > > case? > > Correct me if I am wrong here, but I am assuming that ntpd can ask for > an adjustment of X amount which the kernel changes into N adjustments of > X/N amount spread over the next N ticks. No, sorry, you are correct there, I was confusing things. It may work, and I had considered a similar idea when developing my solution, but it seemed far too ugly and complicated. But that could have just been my fault. :) thanks -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] RT-patch update to remove the global pi_lock
On Wed, 24 Aug 2005, Daniel Walker wrote: > > I got a report of a possible softlockup with setiathome, the trace > wasn't a little garbled though . I'm not sure the checking is working > correctly . But if it is maybe these spot need some performance > analysis . Didn't you changes catch anything that stays in the kernel > for 10 seconds or more ? > I haven't looked that hard yet. If Ingo is ready for my changes, to replace the pi_lock, then I can spend time tracking this down. Something is definity wrong, regardless whether or not the output is right. The tests constantly spit crap out, but when this happens, everything is silent. So something is definity amiss. Try it out and see what I mean. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.6.13-rc6] dcdbas: add Dell Systems Management Base Driver with sysfs support
This patch adds the Dell Systems Management Base Driver with sysfs support. This driver has been tested with Dell OpenManage. Signed-off-by: Doug Warzecha <[EMAIL PROTECTED]> --- diff -uprN linux-2.6.13-rc6.orig/Documentation/dcdbas.txt linux-2.6.13-rc6/Documentation/dcdbas.txt --- linux-2.6.13-rc6.orig/Documentation/dcdbas.txt 1969-12-31 18:00:00.0 -0600 +++ linux-2.6.13-rc6/Documentation/dcdbas.txt 2005-08-19 18:45:37.0 -0500 @@ -0,0 +1,87 @@ +Overview + +The Dell Systems Management Base Driver provides a sysfs interface for +systems management software such as Dell OpenManage to perform system +management interrupts and host control actions (system power cycle or +power off after OS shutdown) on certain Dell systems. + +Dell OpenManage requires this driver on the following Dell PowerEdge systems: +300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC, +700, and 750. Other Dell software such as the open source Libsmbios library +is expected to make use of this driver, and it may include the use of this +driver on other Dell systems. + + +System Management Interrupt + +On some Dell systems, systems management software must access certain +management information via a system management interrupt (SMI). The SMI data +buffer must reside in 32-bit address space, and the physical address of the +buffer is required for the SMI. The driver maintains the memory required for +the SMI and provides a way for the application to generate the SMI. +The driver creates the following sysfs entries for systems management +software to perform these system management interrupts: + +/sys/devices/platform/dcdbas/smi_data +/sys/devices/platform/dcdbas/smi_data_buf_phys_addr +/sys/devices/platform/dcdbas/smi_data_buf_size +/sys/devices/platform/dcdbas/smi_request + +Systems management software must perform the following steps to execute +a SMI using this driver: + +1) Lock smi_data. +2) Write system management command to smi_data. +3) Write "1" to smi_request to generate a calling interface SMI or + "2" to generate a raw SMI. +4) Read system management command response from smi_data. +5) Unlock smi_data. + + +Host Control Action + +Dell OpenManage supports a host control feature that allows the administrator +to perform a power cycle or power off of the system after the OS has finished +shutting down. On some Dell systems, this host control feature requires that +a driver perform a SMI after the OS has finished shutting down. + +The driver creates the following sysfs entries for systems management software +to schedule the driver to perform a power cycle or power off host control +action after the system has finished shutting down: + +/sys/devices/platform/dcdbas/host_control_action +/sys/devices/platform/dcdbas/host_control_smi_type +/sys/devices/platform/dcdbas/host_control_on_shutdown + +Dell OpenManage performs the following steps to execute a power cycle or +power off host control action using this driver: + +1) Write host control action to be performed to host_control_action. +2) Write type of SMI that driver needs to perform to host_control_smi_type. +3) Write "1" to host_control_on_shutdown to enable host control action. +4) Initiate OS shutdown. + (Driver will perform host control SMI when it is notified that the OS + has finished shutting down.) + + +Host Control SMI Type + +The following table shows the value to write to host_control_smi_type to +perform a power cycle or power off host control action: + +PowerEdge SystemHost Control SMI Type +- + 300 HC_SMITYPE_TYPE1 + 1300 HC_SMITYPE_TYPE1 + 1400 HC_SMITYPE_TYPE2 + 500SC HC_SMITYPE_TYPE2 + 1500SC HC_SMITYPE_TYPE2 + 1550 HC_SMITYPE_TYPE2 + 600SC HC_SMITYPE_TYPE2 + 1600SC HC_SMITYPE_TYPE2 + 650 HC_SMITYPE_TYPE2 + 1655MC HC_SMITYPE_TYPE2 + 700 HC_SMITYPE_TYPE3 + 750 HC_SMITYPE_TYPE3 + + diff -uprN linux-2.6.13-rc6.orig/drivers/firmware/dcdbas.c linux-2.6.13-rc6/drivers/firmware/dcdbas.c --- linux-2.6.13-rc6.orig/drivers/firmware/dcdbas.c 1969-12-31 18:00:00.0 -0600 +++ linux-2.6.13-rc6/drivers/firmware/dcdbas.c 2005-08-19 19:07:50.823719952 -0500 @@ -0,0 +1,593 @@ +/* + * dcdbas.c: Dell Systems Management Base Driver + * + * The Dell Systems Management Base Driver provides a sysfs interface for + * systems management software to perform System Management Interrupts (SMIs) + * and Host Control Actions (power cycle or power off after OS shutdown) on + * Dell systems. + * + * See Documentation/dcdbas.txt for more information. + * + * Copyright (C) 1995-2005 Dell Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License v2.0 as published by + * the Free Software Foundation. + * + * Th
Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
john stultz wrote: On Wed, 2005-08-24 at 16:46 -0700, George Anzinger wrote: john stultz wrote: On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote: Roman Zippel wrote: Hi, On Tue, 23 Aug 2005, john stultz wrote: I'm assuming gettimeofday()/clock_gettime() looks something like: xtime + (get_cycles()-last_update)*(mult+ntp_adj)>>shift Where did you get the ntp_adj from? It's not in my example. gettimeofday() was in the previous mail: "xtime + (cycle_offset * mult + error) >> shift". The difference between system time and reference time is really important. gettimeofday() returns the system time, NTP controls the reference time and these two are synchronized regularly. I didn't see that anywhere in your example. If I read your example right, the problem is when the NTP adjustment changes while the two clocks are out of sync (because of a late tick). Not quite. The issue that I'm trying to describe is that if, we inconsistently calculate time intervals in gettimeofday and the timer interrupt, we have the possibility for time inconsistencies. The trivial example using the current code would be something like: Again with my 2 cyc per tick clock, HZ=1000. gettimeofday(): xtime + offset_ns timer_interrupt: xtime += tick_length + ntp_adj offset_ns = 0 0: gettimeofday: 0 + 0 = 0 ns 1: gettimeofday: 0 + 500k ns = 500k ns 2: gettimeofday: 0 + 1M ns = 1M ns 2: timer_interrupt: 2: gettimeofday: 1M ns + 0 ns = 1M ns 3: gettimeofday: 1M ns + 500k ns = 1.5M ns 4: gettimeofday: 1M ns + 1M ns = 2 ns 4: timer_interrupt (using -500ppm adjustment) 4: gettimeofday: 1,999,500 ns + 0 ns = 1,999,500 ns At point 4 you are introducing a NEW ntp adjustment. This, I submit, needs to actually have been introduced to the system prior to the interrupt at point 2 with the first xtime change at point 4. However, gettimeofday() should be aware of it from the interrupt at point 2 and be doing corrections from that time forward. Thus when the point 4 interrutp happens xtime will be the same at the gettimeofday a ns earlier. Yes, clearly a forward knowledge of the NTP adjustment is necessary for gettimeofday(), because after the NTP adjustment has been accumulated into xtime, there's nothing left for gettimeofday to adjust (its already been applied). :) Likewise, gettimeofday() needs to know when to stop apply the correction so that if a tick is late, it will apply the correction only for those times that it was needed. This, could be done by figuring the offset thusly: offset = (offset from last tick to end of ntp period * ntp_adj1) + (offset from end of ntp period to now) Well, in my example, the ntp_adjustment is a fixed nanosecond offset, so it would be added to the nanosecond offset from the last tick (which is how the current code works). If you are doing scaling (as you have in the equation above), then the problem goes away, since you can apply the adjustment consistently through any interval. Until the end of the correction time... I suppose it is possible that the latter part of the offset is also under a different ntp correction which would mean a "* ntp_adj2" is needed. Ok, so your forcing gettimeofday to be interval aware, so its applying different fixed NTP adjustments to different chunks of the current interval. The issue of course is if you're using fixed adjustments, is that you have to have n ntp adjustments for n intervals, or you have to apply the same ntp adjustment to multiple intervals. Uh, are you saying that one ntpd call can set up several different adjustments? I was assuming that any given call would set up either a fixed adjustment for ever or a fixed adjustment to be applied for a fixed number of ticks (or until so much correcting was done, which, in the end is the same thing at this point in the code). If ntpd has to come back to change the adjustment, I am assuming that some kernel action can be taken at that time to sync the xtime clock and the gettimeofday reading of it. I.e. we would only have to keep track of one adjustment with a possible pre specified end time. I would argue that only two terms are needed here regardless of how late a tick is. This is because, I would expect the ntp system call to sync the two clocks. This means in your example, the ntp call would have been made at, or prior to the timer interrupt at 2 and this is the same edge that gettimeofday is to used to start applying the correction. If you argue that we only need two adjustments, why not argue for only one? You're saying have one adjustment that you apply for the first tick's worth of time, and a second adjustment that you apply for the following N ticks' worth of time in the interval. Why the odd base case? Correct me if I am wrong here, but I am assuming that ntpd can ask for an adjustment of X amount which the kernel changes into N adjustments of X/N amount spread over the ne
Re: [RFC] RT-patch update to remove the global pi_lock
On Wed, 2005-08-24 at 21:13 -0400, Steven Rostedt wrote: > Well, after turning off hrtimers, I keep getting one bug. A possible > soft lockup with the ext3 code. But this didn't seem to be caused by the > changes I made. So just to be sure, I ran my test on the vanilla > 2.6.13-rc6-rt11 and it gave the same bug too. So, it looks like my > changes are now at par with what is out there with the rt11 release. > They both give the same bug! ;-) > > Attached is the test I ran. I did a > > while : ; do ./test3a_rt ; done > > Where test3a_rt is a C program that does adding, deleting and reading of > files, by different tasks that are each at a different priority. Here's > the soft lockup I'm getting: I got a report of a possible softlockup with setiathome, the trace wasn't a little garbled though . I'm not sure the checking is working correctly . But if it is maybe these spot need some performance analysis . Didn't you changes catch anything that stays in the kernel for 10 seconds or more ? Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Incorrect CLOCK_TICK_RATE in 2.6 kernel
john stultz wrote: On Wed, 2005-08-24 at 17:24 -0700, George Anzinger wrote: CLOCK_TICK_RATE is used by the kernel to compute LATCH, TICK_NSEC and tick_nsec. This latter is used to update xtime each tick. TICK_NSEC is then used to compute (at compile time) the conversion constants needed to convert to/from jiffies from/to timespec and timeval (and others). The problem is that, if the timer being used is either Cyclone or HPET, the wrong CLOCK_TICK_RATE is used. Err, the Cyclone does not generate interrupts. So this issue does not affect those systems. As for the HPET, it sets its own interrupt frequency based off of KERNEL_TICK_USEC (which you're right, isn't quite what is used in the jiffies conversions). Would it be easier to just adjust that value to use ACTHZ or CLOCK_TICK_RATE? If you want to take that approach you would want the HPET to interrupt every TICK_NSEC nanoseconds, that being what xtime is pushed by each tick. -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 3/5] Call security hooks conditionally if the security_op is filled out.
Call security hooks conditionally if the security_op is filled out. Branches can be more efficient than the unconditional indirect function call. Inspired by patch from Kurt Garloff <[EMAIL PROTECTED]>. Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- include/linux/security.h | 825 +++ 1 files changed, 411 insertions(+), 414 deletions(-) Index: linus-2.6/include/linux/security.h === --- linus-2.6.orig/include/linux/security.h +++ linus-2.6/include/linux/security.h @@ -1264,10 +1264,10 @@ static inline int security_init(void) static inline int security_ptrace (struct task_struct * parent, struct task_struct * child) { #ifdef CONFIG_SECURITY - return security_ops->ptrace (parent, child); -#else - return cap_ptrace (parent, child); + if (security_ops->ptrace) + return security_ops->ptrace(parent, child); #endif + return cap_ptrace (parent, child); } @@ -1277,10 +1277,10 @@ static inline int security_capget (struc kernel_cap_t *permitted) { #ifdef CONFIG_SECURITY - return security_ops->capget (target, effective, inheritable, permitted); -#else - return cap_capget (target, effective, inheritable, permitted); + if (security_ops->capget) + return security_ops->capget(target, effective, inheritable, permitted); #endif + return cap_capget (target, effective, inheritable, permitted); } static inline int security_capset_check (struct task_struct *target, @@ -1289,10 +1289,10 @@ static inline int security_capset_check kernel_cap_t *permitted) { #ifdef CONFIG_SECURITY - return security_ops->capset_check (target, effective, inheritable, permitted); -#else + if (security_ops->capset_check) + return security_ops->capset_check(target, effective, inheritable, permitted); +#endif return cap_capset_check (target, effective, inheritable, permitted); -#endif } static inline void security_capset_set (struct task_struct *target, @@ -1301,183 +1301,183 @@ static inline void security_capset_set ( kernel_cap_t *permitted) { #ifdef CONFIG_SECURITY - security_ops->capset_set (target, effective, inheritable, permitted); -#else - cap_capset_set (target, effective, inheritable, permitted); + if (security_ops->capset_set) + return security_ops->capset_set(target, effective, inheritable, permitted); #endif + cap_capset_set (target, effective, inheritable, permitted); } static inline int security_acct (struct file *file) { #ifdef CONFIG_SECURITY - return security_ops->acct (file); -#else - return 0; + if (security_ops->acct) + return security_ops->acct(file); #endif + return 0; } static inline int security_sysctl(struct ctl_table *table, int op) { #ifdef CONFIG_SECURITY - return security_ops->sysctl(table, op); -#else - return 0; + if (security_ops->sysctl) + return security_ops->sysctl(table, op); #endif + return 0; } static inline int security_quotactl (int cmds, int type, int id, struct super_block *sb) { #ifdef CONFIG_SECURITY - return security_ops->quotactl (cmds, type, id, sb); -#else - return 0; + if (security_ops->quotactl) + return security_ops->quotactl(cmds, type, id, sb); #endif + return 0; } static inline int security_quota_on (struct dentry * dentry) { #ifdef CONFIG_SECURITY - return security_ops->quota_on (dentry); -#else - return 0; + if (security_ops->quota_on) + return security_ops->quota_on(dentry); #endif + return 0; } static inline int security_syslog(int type) { #ifdef CONFIG_SECURITY - return security_ops->syslog(type); -#else - return cap_syslog(type); + if (security_ops->syslog) + return security_ops->syslog(type); #endif + return cap_syslog(type); } static inline int security_settime(struct timespec *ts, struct timezone *tz) { #ifdef CONFIG_SECURITY - return security_ops->settime(ts, tz); -#else - return cap_settime(ts, tz); + if (security_ops->settime) + return security_ops->settime(ts, tz); #endif + return cap_settime(ts, tz); } static inline int security_vm_enough_memory(long pages) { #ifdef CONFIG_SECURITY - return security_ops->vm_enough_memory(pages); -#else - return cap_vm_enough_memory(pages); + if (security_ops->vm_enough_memory) + return security_ops->vm_enough_memory(pages); #endif + return cap_vm_enough_memory(pages); } static inline int security_bprm_alloc (struct linux_binprm *bprm) { #ifdef CONFIG_SECURITY - return security_ops->bprm_allo
[PATCH 5/5] Remove unnecesary capability hooks in rootplug.
Now that capability functions are default, rootplug no longer needs to manually add them to its security_ops. Cc: Greg Kroah <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- security/root_plug.c | 14 +- 1 files changed, 1 insertion(+), 13 deletions(-) Index: lsm-hooks-2.6/security/root_plug.c === --- lsm-hooks-2.6.orig/security/root_plug.c +++ lsm-hooks-2.6/security/root_plug.c @@ -83,19 +83,7 @@ static int rootplug_bprm_check_security } static struct security_operations rootplug_security_ops = { - /* Use the capability functions for some of the hooks */ - .ptrace = cap_ptrace, - .capget = cap_capget, - .capset_check = cap_capset_check, - .capset_set = cap_capset_set, - .capable = cap_capable, - - .bprm_apply_creds = cap_bprm_apply_creds, - .bprm_set_security =cap_bprm_set_security, - - .task_post_setuid = cap_task_post_setuid, - .task_reparent_to_init =cap_task_reparent_to_init, - + /* The capability functions are the defaults */ .bprm_check_security = rootplug_bprm_check_security, }; -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/5] LSM hook updates
This is based on Kurt's original work. The net effect is that LSM hooks are called conditionally, and in all cases capabilities provide the defaults. I've done some basic performance testing, and found nothing surprising. I'm interested to see numbers from others before I push this up. These are against Linus' current git tree (they will clash with the -mm tree). security/dummy.c | 996 include/linux/security.h | 1665 --- security/Makefile|9 security/commoncap.c | 160 ++-- security/root_plug.c | 14 security/security.c | 62 - 6 files changed, 839 insertions(+), 2067 deletions(-) thanks, -chris -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/5] Rework stubs in security.h
Collapse security stubs so that the def'n is done in one spot with ifdef in function body rather than two separately defined functions. Patch from Kurt Garloff <[EMAIL PROTECTED]>, and slightly altered by me to make all ifdef sites consistent and move the prototype decl's to a sane spot. Signed-off-by: Kurt Garloff <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- include/linux/security.h | 1410 --- 1 files changed, 609 insertions(+), 801 deletions(-) Index: lsm-hooks-2.6/include/linux/security.h === --- lsm-hooks-2.6.orig/include/linux/security.h +++ lsm-hooks-2.6/include/linux/security.h @@ -1248,10 +1248,27 @@ struct security_operations { /* global variables */ extern struct security_operations *security_ops; -/* inline stuff */ +/* prototypes */ +extern int security_init (void); +extern int register_security (struct security_operations *ops); +extern int unregister_security (struct security_operations *ops); +extern int mod_reg_security(const char *name, struct security_operations *ops); +extern int mod_unreg_security (const char *name, struct security_operations *ops); +#else +static inline int security_init(void) +{ + return 0; +} +#endif /* CONFIG_SECURITY */ + static inline int security_ptrace (struct task_struct * parent, struct task_struct * child) { +#ifdef CONFIG_SECURITY return security_ops->ptrace (parent, child); +#else + return cap_ptrace (parent, child); +#endif + } static inline int security_capget (struct task_struct *target, @@ -1259,7 +1281,11 @@ static inline int security_capget (struc kernel_cap_t *inheritable, kernel_cap_t *permitted) { +#ifdef CONFIG_SECURITY return security_ops->capget (target, effective, inheritable, permitted); +#else + return cap_capget (target, effective, inheritable, permitted); +#endif } static inline int security_capset_check (struct task_struct *target, @@ -1267,7 +1293,11 @@ static inline int security_capset_check kernel_cap_t *inheritable, kernel_cap_t *permitted) { +#ifdef CONFIG_SECURITY return security_ops->capset_check (target, effective, inheritable, permitted); +#else + return cap_capset_check (target, effective, inheritable, permitted); +#endif } static inline void security_capset_set (struct task_struct *target, @@ -1275,278 +1305,457 @@ static inline void security_capset_set ( kernel_cap_t *inheritable, kernel_cap_t *permitted) { +#ifdef CONFIG_SECURITY security_ops->capset_set (target, effective, inheritable, permitted); +#else + cap_capset_set (target, effective, inheritable, permitted); +#endif } static inline int security_acct (struct file *file) { +#ifdef CONFIG_SECURITY return security_ops->acct (file); +#else + return 0; +#endif } static inline int security_sysctl(struct ctl_table *table, int op) { +#ifdef CONFIG_SECURITY return security_ops->sysctl(table, op); +#else + return 0; +#endif } static inline int security_quotactl (int cmds, int type, int id, struct super_block *sb) { +#ifdef CONFIG_SECURITY return security_ops->quotactl (cmds, type, id, sb); +#else + return 0; +#endif } static inline int security_quota_on (struct dentry * dentry) { +#ifdef CONFIG_SECURITY return security_ops->quota_on (dentry); +#else + return 0; +#endif } static inline int security_syslog(int type) { +#ifdef CONFIG_SECURITY return security_ops->syslog(type); +#else + return cap_syslog(type); +#endif } static inline int security_settime(struct timespec *ts, struct timezone *tz) { +#ifdef CONFIG_SECURITY return security_ops->settime(ts, tz); +#else + return cap_settime(ts, tz); +#endif } - static inline int security_vm_enough_memory(long pages) { +#ifdef CONFIG_SECURITY return security_ops->vm_enough_memory(pages); +#else + return cap_vm_enough_memory(pages); +#endif } static inline int security_bprm_alloc (struct linux_binprm *bprm) { +#ifdef CONFIG_SECURITY return security_ops->bprm_alloc_security (bprm); +#else + return 0; +#endif } + static inline void security_bprm_free (struct linux_binprm *bprm) { +#ifdef CONFIG_SECURITY security_ops->bprm_free_security (bprm); +#else + return; +#endif } + static inline void security_bprm_apply_creds (struct linux_binprm *bprm, int unsafe) { +#ifdef CONFIG_SECURITY security_ops->bprm_apply_creds (bprm, unsafe); +#else + cap_bprm_apply_creds (bprm, unsafe); +#endif } + static inline void security_bprm_post_apply_creds (struct linux_binprm
[PATCH 1/5] Use capabilities as default w/ and w/out CONFIG_SECURITY.
If a kernel is compiled with CONFIG_SECURITY to enable LSM, the default behaviour changes unless the admin loads capability. This is undesirable. This patch makes capability the default. capability can still be compiled as module and be loaded as LSM. If loaded as primary LSM, it won't change anything. But it may also be loaded as secondary LSM and stacked on top of another LSM (if the other LSM allows this or if stacker is used). Based on original patch from Kurt Garloff <[EMAIL PROTECTED]>. Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- security/dummy.c | 996 --- security/Makefile|9 security/commoncap.c | 977 +- security/security.c | 22 - 4 files changed, 912 insertions(+), 1092 deletions(-) Index: lsm-hooks-2.6/security/Makefile === --- lsm-hooks-2.6.orig/security/Makefile +++ lsm-hooks-2.6/security/Makefile @@ -5,15 +5,12 @@ obj-$(CONFIG_KEYS) += keys/ subdir-$(CONFIG_SECURITY_SELINUX) += selinux -# if we don't select a security model, use the default capabilities -ifneq ($(CONFIG_SECURITY),y) obj-y += commoncap.o -endif # Object file lists -obj-$(CONFIG_SECURITY) += security.o dummy.o +obj-$(CONFIG_SECURITY) += security.o # Must precede capability.o in order to stack properly. obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o -obj-$(CONFIG_SECURITY_CAPABILITIES)+= commoncap.o capability.o -obj-$(CONFIG_SECURITY_ROOTPLUG)+= commoncap.o root_plug.o +obj-$(CONFIG_SECURITY_CAPABILITIES)+= capability.o +obj-$(CONFIG_SECURITY_ROOTPLUG)+= root_plug.o obj-$(CONFIG_SECURITY_SECLVL) += seclvl.o Index: lsm-hooks-2.6/security/commoncap.c === --- lsm-hooks-2.6.orig/security/commoncap.c +++ lsm-hooks-2.6/security/commoncap.c @@ -8,7 +8,6 @@ */ #include -#include #include #include #include @@ -23,38 +22,7 @@ #include #include #include - -int cap_netlink_send(struct sock *sk, struct sk_buff *skb) -{ - NETLINK_CB(skb).eff_cap = current->cap_effective; - return 0; -} - -EXPORT_SYMBOL(cap_netlink_send); - -int cap_netlink_recv(struct sk_buff *skb) -{ - if (!cap_raised(NETLINK_CB(skb).eff_cap, CAP_NET_ADMIN)) - return -EPERM; - return 0; -} - -EXPORT_SYMBOL(cap_netlink_recv); - -int cap_capable (struct task_struct *tsk, int cap) -{ - /* Derived from include/linux/sched.h:capable. */ - if (cap_raised(tsk->cap_effective, cap)) - return 0; - return -EPERM; -} - -int cap_settime(struct timespec *ts, struct timezone *tz) -{ - if (!capable(CAP_SYS_TIME)) - return -EPERM; - return 0; -} +#include int cap_ptrace (struct task_struct *parent, struct task_struct *child) { @@ -64,6 +32,7 @@ int cap_ptrace (struct task_struct *pare return -EPERM; return 0; } +EXPORT_SYMBOL(cap_ptrace); int cap_capget (struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted) @@ -74,6 +43,7 @@ int cap_capget (struct task_struct *targ *permitted = cap_t (target->cap_permitted); return 0; } +EXPORT_SYMBOL(cap_capget); int cap_capset_check (struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted) @@ -100,6 +70,7 @@ int cap_capset_check (struct task_struct return 0; } +EXPORT_SYMBOL(cap_capset_check); void cap_capset_set (struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted) @@ -108,34 +79,42 @@ void cap_capset_set (struct task_struct target->cap_inheritable = *inheritable; target->cap_permitted = *permitted; } +EXPORT_SYMBOL(cap_capset_set); -int cap_bprm_set_security (struct linux_binprm *bprm) +int cap_capable (struct task_struct *tsk, int cap) { - /* Copied from fs/exec.c:prepare_binprm. */ - - /* We don't have VFS support for capabilities yet */ - cap_clear (bprm->cap_inheritable); - cap_clear (bprm->cap_permitted); - cap_clear (bprm->cap_effective); + /* Derived from include/linux/sched.h:capable. */ + if (cap_raised(tsk->cap_effective, cap)) + return 0; + return -EPERM; +} +EXPORT_SYMBOL(cap_capable); - /* To support inheritance of root-permissions and suid-root -* executables under compatibility mode, we raise all three -* capability sets for the file. -* -* If only the real uid is 0, we only raise the inheritable -* and permitted sets of the executable file. -*/ +int cap_syslog (int type) +{ + if ((type != 3 && type != 10) && !capable(
[PATCH 4/5] Remove unnecessary default capability callbacks.
Now that all security hook inline stubs conditionally call to module and do proper default action as fallback, all the old no-op default hooks can be removed. Similarly, the verify() bits which populated empty slots with default hooks is no longer needed. A few hooks are called from security core directly rather than from inline stubs, so fix those up as well. Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- security/commoncap.c | 825 --- security/security.c | 50 +-- 2 files changed, 17 insertions(+), 858 deletions(-) Index: lsm-hooks-2.6/security/commoncap.c === --- lsm-hooks-2.6.orig/security/commoncap.c +++ lsm-hooks-2.6/security/commoncap.c @@ -337,828 +337,3 @@ int cap_netlink_recv(struct sk_buff *skb return 0; } EXPORT_SYMBOL(cap_netlink_recv); - -#ifdef CONFIG_SECURITY - -static int cap_acct (struct file *file) -{ - return 0; -} - -static int cap_sysctl (ctl_table * table, int op) -{ - return 0; -} - -static int cap_quotactl (int cmds, int type, int id, struct super_block *sb) -{ - return 0; -} - -static int cap_quota_on (struct dentry *dentry) -{ - return 0; -} - -static int cap_bprm_alloc_security (struct linux_binprm *bprm) -{ - return 0; -} - -static void cap_bprm_free_security (struct linux_binprm *bprm) -{ - return; -} - -static void cap_bprm_post_apply_creds (struct linux_binprm *bprm) -{ - return; -} - -static int cap_bprm_check_security (struct linux_binprm *bprm) -{ - return 0; -} - -static int cap_sb_alloc_security (struct super_block *sb) -{ - return 0; -} - -static void cap_sb_free_security (struct super_block *sb) -{ - return; -} - -static int cap_sb_copy_data (struct file_system_type *type, - void *orig, void *copy) -{ - return 0; -} - -static int cap_sb_kern_mount (struct super_block *sb, void *data) -{ - return 0; -} - -static int cap_sb_statfs (struct super_block *sb) -{ - return 0; -} - -static int cap_sb_mount (char *dev_name, struct nameidata *nd, char *type, - unsigned long flags, void *data) -{ - return 0; -} - -static int cap_sb_check_sb (struct vfsmount *mnt, struct nameidata *nd) -{ - return 0; -} - -static int cap_sb_umount (struct vfsmount *mnt, int flags) -{ - return 0; -} - -static void cap_sb_umount_close (struct vfsmount *mnt) -{ - return; -} - -static void cap_sb_umount_busy (struct vfsmount *mnt) -{ - return; -} - -static void cap_sb_post_remount (struct vfsmount *mnt, unsigned long flags, - void *data) -{ - return; -} - - -static void cap_sb_post_mountroot (void) -{ - return; -} - -static void cap_sb_post_addmount (struct vfsmount *mnt, struct nameidata *nd) -{ - return; -} - -static int cap_sb_pivotroot (struct nameidata *old_nd, struct nameidata *new_nd) -{ - return 0; -} - -static void cap_sb_post_pivotroot (struct nameidata *old_nd, struct nameidata *new_nd) -{ - return; -} - -static int cap_inode_alloc_security (struct inode *inode) -{ - return 0; -} - -static void cap_inode_free_security (struct inode *inode) -{ - return; -} - -static int cap_inode_create (struct inode *inode, struct dentry *dentry, - int mask) -{ - return 0; -} - -static void cap_inode_post_create (struct inode *inode, struct dentry *dentry, -int mask) -{ - return; -} - -static int cap_inode_link (struct dentry *old_dentry, struct inode *inode, -struct dentry *new_dentry) -{ - return 0; -} - -static void cap_inode_post_link (struct dentry *old_dentry, - struct inode *inode, - struct dentry *new_dentry) -{ - return; -} - -static int cap_inode_unlink (struct inode *inode, struct dentry *dentry) -{ - return 0; -} - -static int cap_inode_symlink (struct inode *inode, struct dentry *dentry, - const char *name) -{ - return 0; -} - -static void cap_inode_post_symlink (struct inode *inode, - struct dentry *dentry, const char *name) -{ - return; -} - -static int cap_inode_mkdir (struct inode *inode, struct dentry *dentry, - int mask) -{ - return 0; -} - -static void cap_inode_post_mkdir (struct inode *inode, struct dentry *dentry, - int mask) -{ - return; -} - -static int cap_inode_rmdir (struct inode *inode, struct dentry *dentry) -{ - return 0; -} - -static int cap_inode_mknod (struct inode *inode, struct dentry *dentry, - int mode, dev_t dev) -{ - return 0; -} - -static void cap_inode_post_mknod (struct inode *inode, struct dentry *dentry, -
Re: [RFC] RT-patch update to remove the global pi_lock
Well, after turning off hrtimers, I keep getting one bug. A possible soft lockup with the ext3 code. But this didn't seem to be caused by the changes I made. So just to be sure, I ran my test on the vanilla 2.6.13-rc6-rt11 and it gave the same bug too. So, it looks like my changes are now at par with what is out there with the rt11 release. They both give the same bug! ;-) Attached is the test I ran. I did a while : ; do ./test3a_rt ; done Where test3a_rt is a C program that does adding, deleting and reading of files, by different tasks that are each at a different priority. Here's the soft lockup I'm getting: NFSD: starting 90-second grace period BUG: test3a_rt:6138, possible softlockup detected on CPU#0! [] dump_stack+0x23/0x30 (20) [] softlockup_detected+0x41/0x60 (24) [] softlockup_tick+0xf0/0x100 (24) [] update_process_times+0x5b/0x80 (28) [] smp_apic_timer_interrupt+0xee/0x100 (36) [] apic_timer_interrupt+0x21/0x28 (124) [] ext3_add_entry+0xd1/0x210 (60) [] ext3_add_nondir+0x2d/0x80 (32) [] ext3_create+0xbb/0x110 (40) [] vfs_create+0xf1/0x170 (44) [] open_namei+0x61b/0x6e0 (72) [] filp_open+0x3f/0x70 (92) [] sys_open+0x53/0x100 (44) [] syscall_call+0x7/0xb (-8116) --- | preempt count: 0001 ] | 0-level deep critical section nesting: -- | showing all locks held by: | (test3a_rt/6138 [f7ef61a0, 89]): -- #001: [f2eaddac] {(struct semaphore *)(&inode->i_sem)} ... acquired at: open_namei+0xf9/0x6e0 NMI show regs on CPU#0: Pid: 6138, comm:test3a_rt EIP: 0060:[] CPU: 0 EIP is at nmi_show_all_regs+0x89/0xd0 EFLAGS: 0046Not tainted (2.6.13-rc6-rt11-real) EAX: EBX: 17fa ECX: 0060 EDX: 0080 ESI: EDI: 0006c692 EBP: f07dbd48 DS: 007b ES: 007b CR0: 8005003b CR2: b7e37ae0 CR3: 3085 CR4: 06d0 [] show_regs+0x164/0x16c (36) [] nmi_watchdog_tick+0x128/0x2b0 (56) [] default_do_nmi+0x7f/0x190 (52) [] do_nmi+0x50/0x60 (24) [] nmi_stack_correct+0x1d/0x22 (72) [] softlockup_detected+0x46/0x60 (24) [] softlockup_tick+0xf0/0x100 (24) [] update_process_times+0x5b/0x80 (28) [] smp_apic_timer_interrupt+0xee/0x100 (36) [] apic_timer_interrupt+0x21/0x28 (124) [] ext3_add_entry+0xd1/0x210 (60) [] ext3_add_nondir+0x2d/0x80 (32) [] ext3_create+0xbb/0x110 (40) [] vfs_create+0xf1/0x170 (44) [] open_namei+0x61b/0x6e0 (72) [] filp_open+0x3f/0x70 (92) [] sys_open+0x53/0x100 (44) [] syscall_call+0x7/0xb (-8116) --- | preempt count: 00010001 ] | 1-level deep critical section nesting: .. [] add_preempt_count+0x1c/0x20 .[] .. ( <= nmi_watchdog_tick+0x10d/0x2b0) -- | showing all locks held by: | (test3a_rt/6138 [f7ef61a0, 89]): -- #001: [f2eaddac] {(struct semaphore *)(&inode->i_sem)} ... acquired at: open_namei+0xf9/0x6e0 NMI show regs on CPU#1: Pid: 6137, comm:test3a_rt EIP: 0060:[] CPU: 1 EIP is at do_get_write_access+0x83/0x560 EFLAGS: 0206Not tainted (2.6.13-rc6-rt11-real) EAX: 000e201d EBX: f7ffe000 ECX: f71e49bc EDX: f71e49bc ESI: f7f6b3bc EDI: f71e49bc EBP: f1409e94 DS: 007b ES: 007b CR0: 8005003b CR2: b7fdb000 CR3: 326fb000 CR4: 06d0 [] show_regs+0x164/0x16c (36) [] nmi_watchdog_tick+0x128/0x2b0 (56) [] default_do_nmi+0x7f/0x190 (52) [] do_nmi+0x50/0x60 (24) [] nmi_stack_correct+0x1d/0x22 (132) [] journal_get_write_access+0x35/0x50 (28) [] ext3_orphan_del+0x1a2/0x230 (80) [] ext3_delete_inode+0x73/0x110 (24) [] generic_delete_inode+0x99/0x160 (28) [] generic_drop_inode+0x1d/0x30 (12) [] iput+0x70/0x80 (20) [] sys_unlink+0x110/0x140 (96) [] syscall_call+0x7/0xb (-8116) --- | preempt count: 0001 ] | 1-level deep critical section nesting: .. [] add_preempt_count+0x1c/0x20 .[] .. ( <= nmi_watchdog_tick+0x10d/0x2b0) -- | showing all locks held by: | (test3a_rt/6137 [f5d437f0, 90]): -- #001: [f709cc88] {(struct semaphore *)(&s->s_lock)} ... acquired at: ext3_orphan_del+0x3a/0x230 Well, looking at this further, it seems to release somehow, and continue, since I've got multiple "possible soft lockups", by different threads. But It doesn't seem to go any further. Somethings spinning quite a bit, and something else must be starved. I'll look further into this. So, Ingo, what do you think of the changes so far? Do you feel that it is stable enough to send you an actual real patch. That way we can work together in cleaning it up and get all the other kinks out. Also, let me know if you are getting this. The last couple of messages I sent, never reached me on the LKML, and I sent the last one 4 hours ago. :-( Thomas, I did ge
Where do packets sent to 255.255.255.255 go?
Hi list, If I understand correctly, packets sent to the all-ones broadcast address only go out through a single interface. My question is threefold: 1. Why doesn't Linux send 255.255.255.255 packages through all network interfaces? (I realize that this is probably not a Linux-specific question.) 2. How does it choose which interface to send through? My first guess was that it just took the first Ethernet interface and used that for broadcasting. But playing around with nameif, this seems not to be the case. 3. Can I set the default broadcast interface explicitly? For example, say I wanted broadcasts to go out over eth1 by default, instead of over eth0. What if I wanted them to get sent through tap0? Yes, I know that what I *should* be doing is just send the packages to the broadcast address specific to the network where I want them to go. (That is, I should be sending them to 10.255.255.255 instead of 255.255.255.255 if I want them to be broadcast to the 10.0.0.0 network.) Unfortunately, this is not a viable option in my case, as I'm dealing with a closed-source application that unconditionally sends broadcasts to 255.255.255.255. Ideally, the application would let me choose which interface to broadcast to, but alas it does not. I've tried searching for a solution to this problem on the web and on IRC with no luck, so now I'm turning to you guys. Thanks in advance, -- Daniel Brockman <[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 2.6.13-rc6] cpu_exclusive sched domains build fix
Nick wrote: > and that it looks like what I was thinking about. Ok - I almost have my crosstool installation healthy again. I will actually see to it that my patch builds this time for whatever arch's I can test on, and send this simple disabling of sched domain mangling from cpuset-land as a real patch. I have a couple other commitments - it will be 6 to 12 hours before I send it in, unless someone asks for a half-baked version sooner. > We need to revert to a stable behaviour, however we can't risk > major surgery to get there. Yup. Agreed. Thanks for looking into this, Nick. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 8/8] PCI Error Recovery: PPC64 core recovery routines
> I think what I'd like to see is that when a slot gets isolated and the > driver doesn't have recovery code, the kernel calls the driver's > unplug function and generates a hotplug event to udev. Ideally this > would be a variant of the remove event which would say "and by the > way, please try replugging this slot when you've finished handling the > remove event" or something along those lines. I'm still trying to understand why we care. What prevents us from just uplugging the previous device and re-plugging right away ? After all, the driver->remove() function is supposed to guarantee that no HW access will happen after it returns and that everything was unmapped. Of course, we'll possibly end up with a different ethX or whatever, but I don't see the problem with that ... It's hopeless to think we might manage to keep that identical anyway, unless the driver implements proper error recovery. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
Hi, On Wed, 24 Aug 2005, john stultz wrote: > Ok, well, I'm still at a loss for understanding how this avoids my > concern about time inconsistencies. Let's take a simple example to demonstrate the difference between system time and reference time. NTP tells us to update the reference time by 1000 units every tick and a single tick consists of 123 cycles, so the initial multiplier is 8. This means after 1 tick the system time is 984 and off by -16: time (ticks)reference time system time multerror 0 0 0 8 0 1 1000984 8 -16 2 200019688 -32 3 300029528 -48 4 400039369 -64 the error is now big enough, so we speed up system time: 5 500050439 43 6 600061508 150 and slow it down again: 7 700071348 134 8 800081188 118 9 900091028 102 10 1 10086 8 86 11 11000 11070 8 70 12 12000 12054 8 54 13 13000 13038 8 38 14 14000 14022 8 22 15 15000 15006 8 6 16 16000 15990 8 -10 17 17000 16974 8 -26 18 18000 17958 8 -42 19 19000 18942 8 -58 20 2 19926 8 -74 let's assume we're late with the update by 10 cycles (gettimeofday=19926+10*8=20006), so a change to the mult also requires a adjustment of the system time: 20+10 2 19916 9 -84 so gettimeofday=19916+10*9=20006 21 21000 21023 9 23 22 22000 22130 8 130 now add a single adjustment of 500 to the reference time: 23 23500 23114 11 -386 24 24500 24467 8 -33 A detail which is missing now in my example code is that we actually should look ahead to the next update, so that multiplier is immediately adjusted and the error above would never exceed 123/2 unless an update is delayed. It's really not that difficult :), it's just important to understand the difference between reference time and system time. All the NTP adjustments are done to the reference time and we manipulate the speed of the system clock to keep it close. The latter has _nothing_ to do with NTP so I don't want to see anything called like ntp_adj there. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
On Wed, 2005-08-24 at 16:46 -0700, George Anzinger wrote: > john stultz wrote: > > On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote: > > > >>Roman Zippel wrote: > >> > >>>Hi, > >>> > >>>On Tue, 23 Aug 2005, john stultz wrote: > >>> > >>> > >>> > I'm assuming gettimeofday()/clock_gettime() looks something like: > xtime + (get_cycles()-last_update)*(mult+ntp_adj)>>shift > >>> > >>> > >>>Where did you get the ntp_adj from? It's not in my example. > >>>gettimeofday() was in the previous mail: "xtime + (cycle_offset * mult + > >>>error) >> shift". The difference between system time and reference > >>>time is really important. gettimeofday() returns the system time, NTP > >>>controls the reference time and these two are synchronized regularly. > >>>I didn't see that anywhere in your example. > >>> > > > > > >>If I read your example right, the problem is when the NTP adjustment > >>changes while the two clocks are out of sync (because of a late tick). > > > > > > Not quite. The issue that I'm trying to describe is that if, we > > inconsistently calculate time intervals in gettimeofday and the timer > > interrupt, we have the possibility for time inconsistencies. > > > > The trivial example using the current code would be something like: > > > > Again with my 2 cyc per tick clock, HZ=1000. > > > > gettimeofday(): > > xtime + offset_ns > > > > timer_interrupt: > > xtime += tick_length + ntp_adj > > offset_ns = 0 > > > > 0: gettimeofday: 0 + 0 = 0 ns > > 1: gettimeofday: 0 + 500k ns = 500k ns > > 2: gettimeofday: 0 + 1M ns = 1M ns > > 2: timer_interrupt: > > 2: gettimeofday: 1M ns + 0 ns = 1M ns > > 3: gettimeofday: 1M ns + 500k ns = 1.5M ns > > 4: gettimeofday: 1M ns + 1M ns = 2 ns > > 4: timer_interrupt (using -500ppm adjustment) > > 4: gettimeofday: 1,999,500 ns + 0 ns = 1,999,500 ns > > > At point 4 you are introducing a NEW ntp adjustment. This, I submit, > needs to actually have been introduced to the system prior to the > interrupt at point 2 with the first xtime change at point 4. However, > gettimeofday() should be aware of it from the interrupt at point 2 and > be doing corrections from that time forward. Thus when the point 4 > interrutp happens xtime will be the same at the gettimeofday a ns earlier. Yes, clearly a forward knowledge of the NTP adjustment is necessary for gettimeofday(), because after the NTP adjustment has been accumulated into xtime, there's nothing left for gettimeofday to adjust (its already been applied). :) > Likewise, gettimeofday() needs to know when to stop apply the correction > so that if a tick is late, it will apply the correction only for those > times that it was needed. This, could be done by figuring the offset > thusly: > > offset = (offset from last tick to end of ntp period * ntp_adj1) + > (offset from end of ntp period to now) Well, in my example, the ntp_adjustment is a fixed nanosecond offset, so it would be added to the nanosecond offset from the last tick (which is how the current code works). If you are doing scaling (as you have in the equation above), then the problem goes away, since you can apply the adjustment consistently through any interval. > I suppose it is possible that the latter part of the offset is also > under a different ntp correction which would mean a "* ntp_adj2" is > needed. Ok, so your forcing gettimeofday to be interval aware, so its applying different fixed NTP adjustments to different chunks of the current interval. The issue of course is if you're using fixed adjustments, is that you have to have n ntp adjustments for n intervals, or you have to apply the same ntp adjustment to multiple intervals. > I would argue that only two terms are needed here regardless of > how late a tick is. This is because, I would expect the ntp system call > to sync the two clocks. This means in your example, the ntp call would > have been made at, or prior to the timer interrupt at 2 and this is the > same edge that gettimeofday is to used to start applying the correction. If you argue that we only need two adjustments, why not argue for only one? You're saying have one adjustment that you apply for the first tick's worth of time, and a second adjustment that you apply for the following N ticks' worth of time in the interval. Why the odd base case? > >>It would appear that gettimeofday would need to know that the NTP > >>adjustment is changing (and to what). It would also appear that this > >>is known by the ntp code and could be made available to gettimeofday. > >>If it is changing due to an NTP call, that system call, itself, > >>should/must force synchronization. So the only case gettimeofday needs > >>to worry/know about is that an adjustment is to change at time X to > >>value Y. Also, me thinks there is only one such change that can be > >>present at any given time. > > > > > > Well, in many arches gettimeofday() works around the above issu
Re: Add pselect, ppoll system calls.
David Woodhouse wrote: > If it's mandatory that we actually call the signal handler, then we need > to play tricks like sigsuspend() does to leave the old signal mask on > the stack frame. That's a bit painful atm because do_signal is different > between architectures. It is necessary that the handler is called. This is the purpose of these interfaces. If this means more complexity is needed then this is how the cookie crumbles. One use case for pselect would be something like this: int got_signal; void sigint_handler(int sig) { got_signal = 1; } { ... while (1) { if (!got_signal) pselect() if (got_signal) { handle signal got_signal = 0; } } ... } -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: Incorrect CLOCK_TICK_RATE in 2.6 kernel
On Wed, 2005-08-24 at 17:24 -0700, George Anzinger wrote: > CLOCK_TICK_RATE is used by the kernel to compute LATCH, TICK_NSEC and > tick_nsec. This latter is used to update xtime each tick. TICK_NSEC is > then used to compute (at compile time) the conversion constants needed > to convert to/from jiffies from/to timespec and timeval (and others). > > The problem is that, if the timer being used is either Cyclone or HPET, > the wrong CLOCK_TICK_RATE is used. Err, the Cyclone does not generate interrupts. So this issue does not affect those systems. As for the HPET, it sets its own interrupt frequency based off of KERNEL_TICK_USEC (which you're right, isn't quite what is used in the jiffies conversions). Would it be easier to just adjust that value to use ACTHZ or CLOCK_TICK_RATE? thanks -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Incorrect CLOCK_TICK_RATE in 2.6 kernel
CLOCK_TICK_RATE is used by the kernel to compute LATCH, TICK_NSEC and tick_nsec. This latter is used to update xtime each tick. TICK_NSEC is then used to compute (at compile time) the conversion constants needed to convert to/from jiffies from/to timespec and timeval (and others). The problem is that, if the timer being used is either Cyclone or HPET, the wrong CLOCK_TICK_RATE is used. This means that systems using these interrupt sources will be doing a) incorrect update of xtime and b) incorrect conversion of jiffies. Since these two values will track each other this will not be seen by simple gettimeofday(); sleep();gettimeofday() tests, but will be seen as a system clock drift (without NTP) or with NTP, a somewhat high drift rate (to the point of loosing sync at HZ=1000). The fact that the user/ system chooses the clock to use at boot time and can change the clock after boot means that it is not possible to pin down CLOCK_TICK_RATE at compile time. However, since the computation of TICK_NSEC and the conversion constants is rather involved it is clear that we REALLY do want to compute these at compile time. The suggested solution is to a) set up a structure with the default (clock of choice at config time) conversion constants in it at compile time. Then b) at clock init time, populate the structure with the proper constants for the given clock. These can be computed at compile time, but from the correct CLOCK_TICK_RATE for the given clock. Switching to a fall back clock would also require an update of this structure. Commits? -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] fix minor bug in sungem.h
This changes the Sun Gem Ether driver's tx ring buffer length to the proper constant. Currently TX_RING_SIZE and RX_RING_SIZE are equal, so no malfunction occurs. Signed-off-by: Geoff Levand <[EMAIL PROTECTED]> --- a/drivers/net/sungem.h 2005-08-19 14:35:50.0 -0700 +++ b/drivers/net/sungem.h 2005-08-24 17:14:18.0 -0700 @@ -1020,7 +1020,7 @@ struct gem_init_block *init_block; struct sk_buff *rx_skbs[RX_RING_SIZE]; - struct sk_buff *tx_skbs[RX_RING_SIZE]; + struct sk_buff *tx_skbs[TX_RING_SIZE]; dma_addr_t gblock_dvma; struct pci_dev *pdev; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
root:sleipner:~# modprobe hotkey FATAL: Error inserting hotkey (/lib/modules/2.6.13-rc7/kernel/drivers/acpi/hotkey.ko): No such device Not that I care, but it at least loaded in -rc6 and created the /proc/acpi/hotkey directory with its content. When the revolution comes, the author of acpi-hotkey.txt will face the wall first. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: process creation time increases linearly with shmem
Ray Fucillo wrote: I am seeing process creation time increase linearly with the size of the shared memory segment that the parent touches. The attached forktest.c is a very simple user program that illustrates this behavior, which I have tested on various kernel versions from 2.4 through 2.6. Is this a known issue, and is it solvable? fork() can be changed so as not to set up page tables for MAP_SHARED mappings. I think that has other tradeoffs like initially causing several unavoidable faults reading libraries and program text. What kind of application are you using? -- 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 2.6.13-rc6] cpu_exclusive sched domains build fix
Paul Jackson wrote: So long as the cpuset code stops making any calls to partition_sched_domains() whatsoever, then we should be back where we were in 2.6.12, so far as the scheduler is concerned - right? That's right - sorry I just meant disabling the dynamic sched domains behaviour of the cpu_exclusive cpusets. I hope that the following (untested, unbuilt) patch, that I suggested in my "Mon, 22 Aug 2005 13:38:23 -0700" message best meets you suggestion above ... and I quote: I apologise, I missed that patch you sent. I think it looks OK, and that it looks like what I was thinking about. We need to revert to a stable behaviour, however we can't risk major surgery to get there. -- 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 8/8] PCI Error Recovery: PPC64 core recovery routines
Linas Vepstas writes: > The meta-issue that I'd like to reach consensus on first is whether > there should be any hot-plug recovery attempted at all. Removing > hot-plug-recovery support will make many of the issues you raise > to be moot. Yes, this probably the thorniest issue we have. My feeling is that the unplug half of it is probably fairly uncontroversial, but the replug half is a can of worms. Would you agree with that? Is it udev that handles the hotplug notifications on the userspace side in all cases (do both RHEL and SLES use udev, for instance)? How hard is it to add a new sort of notification, on the kernel side and in udev? I think what I'd like to see is that when a slot gets isolated and the driver doesn't have recovery code, the kernel calls the driver's unplug function and generates a hotplug event to udev. Ideally this would be a variant of the remove event which would say "and by the way, please try replugging this slot when you've finished handling the remove event" or something along those lines. Thoughts? Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: kgdbwait in 2.6.13-rc4-mm1?
Wilkerson, Bryan P wrote: Is there an equivalent kernel boot option for kgdbwait in 2.6.13-rc4-mm1? I grep'd the kernel source but didn't find kgdbwait. Is there any documentation other than the source for the flavor of KGDB that is included in the akpm kernel patch? The patch has some documentation at Documentation/i386/kgdb/* as well as a couple of gdb macros... The wait option is "gdb". This has been in flux so, to be absolutely sure, look at include/asm-i386/bugs.h -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.6.13-rc7] Fix IXP4xx flash resource range
[Resend...forgot to send to lkml] We are currently reserving one byte more than actually needed by the flash device and overlapping into the next I/O expansion bus window. This a) causes us to allocate an extra page of VM due to ARM ioremap() alignment code and b) could cause problems if another driver tries to request the next expansion bus window. Signed-off-by: Deepak Saxena <[EMAIL PROTECTED]> diff --git a/arch/arm/mach-ixp4xx/coyote-setup.c b/arch/arm/mach-ixp4xx/coyote-setup.c --- a/arch/arm/mach-ixp4xx/coyote-setup.c +++ b/arch/arm/mach-ixp4xx/coyote-setup.c @@ -36,7 +36,7 @@ static struct flash_platform_data coyote static struct resource coyote_flash_resource = { .start = COYOTE_FLASH_BASE, - .end= COYOTE_FLASH_BASE + COYOTE_FLASH_SIZE, + .end= COYOTE_FLASH_BASE + COYOTE_FLASH_SIZE - 1, .flags = IORESOURCE_MEM, }; diff --git a/arch/arm/mach-ixp4xx/gtwx5715-setup.c b/arch/arm/mach-ixp4xx/gtwx5715-setup.c --- a/arch/arm/mach-ixp4xx/gtwx5715-setup.c +++ b/arch/arm/mach-ixp4xx/gtwx5715-setup.c @@ -114,7 +114,7 @@ static struct flash_platform_data gtwx57 static struct resource gtwx5715_flash_resource = { .start = GTWX5715_FLASH_BASE, - .end= GTWX5715_FLASH_BASE + GTWX5715_FLASH_SIZE, + .end= GTWX5715_FLASH_BASE + GTWX5715_FLASH_SIZE - 1, .flags = IORESOURCE_MEM, }; diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c b/arch/arm/mach-ixp4xx/ixdp425-setup.c --- a/arch/arm/mach-ixp4xx/ixdp425-setup.c +++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c @@ -36,7 +36,7 @@ static struct flash_platform_data ixdp42 static struct resource ixdp425_flash_resource = { .start = IXDP425_FLASH_BASE, - .end= IXDP425_FLASH_BASE + IXDP425_FLASH_SIZE, + .end= IXDP425_FLASH_BASE + IXDP425_FLASH_SIZE - 1, .flags = IORESOURCE_MEM, }; -- Deepak Saxena - [EMAIL PROTECTED] - http://www.plexity.net Even a stopped clock gives the right time twice a day. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
john stultz wrote: On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote: Roman Zippel wrote: Hi, On Tue, 23 Aug 2005, john stultz wrote: I'm assuming gettimeofday()/clock_gettime() looks something like: xtime + (get_cycles()-last_update)*(mult+ntp_adj)>>shift Where did you get the ntp_adj from? It's not in my example. gettimeofday() was in the previous mail: "xtime + (cycle_offset * mult + error) >> shift". The difference between system time and reference time is really important. gettimeofday() returns the system time, NTP controls the reference time and these two are synchronized regularly. I didn't see that anywhere in your example. If I read your example right, the problem is when the NTP adjustment changes while the two clocks are out of sync (because of a late tick). Not quite. The issue that I'm trying to describe is that if, we inconsistently calculate time intervals in gettimeofday and the timer interrupt, we have the possibility for time inconsistencies. The trivial example using the current code would be something like: Again with my 2 cyc per tick clock, HZ=1000. gettimeofday(): xtime + offset_ns timer_interrupt: xtime += tick_length + ntp_adj offset_ns = 0 0: gettimeofday: 0 + 0 = 0 ns 1: gettimeofday: 0 + 500k ns = 500k ns 2: gettimeofday: 0 + 1M ns = 1M ns 2: timer_interrupt: 2: gettimeofday: 1M ns + 0 ns = 1M ns 3: gettimeofday: 1M ns + 500k ns = 1.5M ns 4: gettimeofday: 1M ns + 1M ns = 2 ns 4: timer_interrupt (using -500ppm adjustment) 4: gettimeofday: 1,999,500 ns + 0 ns = 1,999,500 ns At point 4 you are introducing a NEW ntp adjustment. This, I submit, needs to actually have been introduced to the system prior to the interrupt at point 2 with the first xtime change at point 4. However, gettimeofday() should be aware of it from the interrupt at point 2 and be doing corrections from that time forward. Thus when the point 4 interrutp happens xtime will be the same at the gettimeofday a ns earlier. Likewise, gettimeofday() needs to know when to stop apply the correction so that if a tick is late, it will apply the correction only for those times that it was needed. This, could be done by figuring the offset thusly: offset = (offset from last tick to end of ntp period * ntp_adj1) + (offset from end of ntp period to now) I suppose it is possible that the latter part of the offset is also under a different ntp correction which would mean a "* ntp_adj2" is needed. I would argue that only two terms are needed here regardless of how late a tick is. This is because, I would expect the ntp system call to sync the two clocks. This means in your example, the ntp call would have been made at, or prior to the timer interrupt at 2 and this is the same edge that gettimeofday is to used to start applying the correction. It would appear that gettimeofday would need to know that the NTP adjustment is changing (and to what). It would also appear that this is known by the ntp code and could be made available to gettimeofday. If it is changing due to an NTP call, that system call, itself, should/must force synchronization. So the only case gettimeofday needs to worry/know about is that an adjustment is to change at time X to value Y. Also, me thinks there is only one such change that can be present at any given time. Well, in many arches gettimeofday() works around the above issue by capping the offset_ns value as such: I think this may have been done with only usec gettimeofday. Now that we have clock_gettime() returning nsec, we need to be a bit more careful. gettimeofday: xtime + min(offset_ns, tick_len + ntp_adj) The problem with this is that when we have lost or late ticks, or if we are using dynamic ticks you have granularity problems. -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
overlapping MTRR regions
Hi, I tested 2.6.13-rc7 on nice server motherboard with 16GB of RAM ;) http://www.msicomputer.com/product/p_spec.asp?model=E7520_Master-S2M&class=spd and I see the following when acpi is enabled (haven't even tried without): # cat /proc/mtrr reg00: base=0xd000 (3328MB), size= 256MB: uncachable, count=1 reg01: base=0xe000 (3584MB), size= 512MB: uncachable, count=1 reg02: base=0x ( 0MB), size=16384MB: write-back, count=1 reg03: base=0x4 (16384MB), size= 512MB: write-back, count=1 reg04: base=0x42000 (16896MB), size= 256MB: write-back, count=1 reg05: base=0xcff8 (3327MB), size= 512KB: uncachable, count=1 # Is that correct? Please cc: me in replies. phylo ~ # lspci :00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 0c) :00:00.1 Class ff00: Intel Corporation E7525/E7520 Error Reporting Registers (rev 0c) :00:01.0 System peripheral: Intel Corporation E7520 DMA Controller (rev 0c) :00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 0c) :00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 0c) :00:05.0 PCI bridge: Intel Corporation E7520 PCI Express Port B1 (rev 0c) :00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 0c) :00:07.0 PCI bridge: Intel Corporation E7520 PCI Express Port C1 (rev 0c) :00:1c.0 PCI bridge: Intel Corporation 6300ESB 64-bit PCI-X Bridge (rev 02) :00:1d.0 USB Controller: Intel Corporation 6300ESB USB Universal Host Controller (rev 02) :00:1d.1 USB Controller: Intel Corporation 6300ESB USB Universal Host Controller (rev 02) :00:1d.4 System peripheral: Intel Corporation 6300ESB Watchdog Timer (rev 02) :00:1d.5 PIC: Intel Corporation 6300ESB I/O Advanced Programmable Interrupt Controller (rev 02) :00:1d.7 USB Controller: Intel Corporation 6300ESB USB2 Enhanced Host Controller (rev 02) :00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 0a) :00:1f.0 ISA bridge: Intel Corporation 6300ESB LPC Interface Controller (rev 02) :00:1f.1 IDE interface: Intel Corporation 6300ESB PATA Storage Controller (rev 02) :00:1f.2 IDE interface: Intel Corporation 6300ESB SATA Storage Controller (rev 02) :00:1f.3 SMBus: Intel Corporation 6300ESB SMBus Controller (rev 02) :01:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09) :01:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) :08:01.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] :08:02.0 Ethernet controller: Intel Corporation 82541GI/PI Gigabit Ethernet Controller :08:03.0 Ethernet controller: Intel Corporation 82541GI/PI Gigabit Ethernet Controller :09:01.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) phylo ~ # lspci -v :00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 0c) Subsystem: Intel Corporation E7520 Memory Controller Hub Flags: bus master, fast devsel, latency 0 Capabilities: [40] #09 [4105] :00:00.1 Class ff00: Intel Corporation E7525/E7520 Error Reporting Registers (rev 0c) Subsystem: Micro-Star International Co., Ltd.: Unknown device 3590 Flags: fast devsel :00:01.0 System peripheral: Intel Corporation E7520 DMA Controller (rev 0c) Subsystem: Micro-Star International Co., Ltd.: Unknown device 3594 Flags: fast devsel, IRQ 10 Memory at d000 (32-bit, non-prefetchable) [size=4K] Capabilities: [b0] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- :00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 0c) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=03, sec-latency=0 Capabilities: [50] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Capabilities: [64] #10 [0041] :00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 0c) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Capabilities: [50] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Capabilities: [64] #10 [0041] :00:05.0 PCI bridge: Intel Corporation E7520 PCI Express Port B1 (rev 0c) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 Capabilities: [50] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Capabilities: [64] #10 [0041] :00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 0c) (prog-if 00 [Normal decode])
[PATCH] ignore all debugging info sections in scripts/reference_discarded.pl
GCC 4 emits more DWARF debugging information than before and there is now a .debug_loc section as well. This causes "make buildcheck" to fail. Rather than just add that one to the special case list, I used a regexp to ignore any .debug_ANYTHING sections in case more show up in the future. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- scripts/reference_discarded.pl |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) a91d80398d6f8c1f335a0af34342b5747f153c13 diff --git a/scripts/reference_discarded.pl b/scripts/reference_discarded.pl --- a/scripts/reference_discarded.pl +++ b/scripts/reference_discarded.pl @@ -91,11 +91,7 @@ foreach $object (keys(%object)) { $from !~ /\.exit\.data$/ && $from !~ /\.altinstructions$/ && $from !~ /\.pdr$/ && -$from !~ /\.debug_info$/ && -$from !~ /\.debug_aranges$/ && -$from !~ /\.debug_ranges$/ && -$from !~ /\.debug_line$/ && -$from !~ /\.debug_frame$/ && +$from !~ /\.debug_.*$/ && $from !~ /\.exitcall\.exit$/ && $from !~ /\.eh_frame$/ && $from !~ /\.stab$/)) { - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>>On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote: >>Care to send me the patch? >Heh. Not really as I don't really know if people should be using it >in it's current state --- the shmem init is very very hacky and I have >other changes I've not had a chance to do. >Anyhow, here is an older version of it. It's from some old internal >embedded tree but should be trivial to shoehorn into anything recent. >If people really do like or want this I would like to know and maybe >something more elegant can be worked out. I tried it with kernel 2.6.13-rc5 and it seems to work. It uses 50% of total memory for tmpfs, but it would be nice to have an option (tmpfs_size=90% etc.) that you could pass to the kernel. You need to add this to init/main.c for it to compile. #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: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
On Wed, 2005-08-24 at 21:49 +0200, Roman Zippel wrote: > On Wed, 24 Aug 2005, john stultz wrote: > > > from your example: > > > // at init: system_update = update_cycles * mult; > > > system_time += system_update; > > > > and: > > > error = system_time - (xtime.tv_nsec << shift); > > > > This doesn't seem to make sense with the above. Could you clarify? > > The example here doesn't keep the complete system time, just enough to > compute the difference. Hey Roman, Ok, well, I'm still at a loss for understanding how this avoids my concern about time inconsistencies. However, I don't want to burn any more of your patience explaining it, so in the hopes making some productive outcome, I'm going to take a step back, pull the most trivial and uncontroversial cleanups and fixes in my patches and try to send them to Andrew one by one. Hopefully that will give me a chance to spend some time and understand your suggestions (or maybe allow someone else to express your suggestions differently) and think of alternate solutions without feeling like I'm constantly running into walls. Again, I really do appreciate the time you've spent giving me feedback. thanks -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7 : OK
Hello, On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: > > Hullo. > > I really wanted to release a 2.6.13, but there's been enough changes > while we've been waiting for other issues to resolve that I think it's > best to do a -rc7 first. > > Most of the -rc7 changes are pretty trivial, either one-liners or > affecting some particular specific driver or unusual configuration. The > shortlog (appended) should give a pretty good idea of what's up. Well, it's been running here for a few hours this evening, and I must say that I have not noticed anything strange yet (except the printk timestamps which switch to zero twice during boot and start with funny values, but that's not important). The box is a dual-k7 with aic7xxx, and NFSv3 over an e1000 NIC. Tested with SMP and preempt enabled. > > Linus Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Additions to .data.read_mostly section
Ravikiran G Thirumalai a écrit : Following patch moves a few static 'read mostly' variables to the .data.read_mostly section. Typically these are vector - irq tables, boot_cpu_data, node_maps etc., which are initialized once and read from often and rarely written to. Please include. Good candidates for read_mostly are all the 'kmem_cache_t *xxx_cache' slab was carefuly designed to eliminate cache line ping pongs on SMP, but if the initial pointer to slab sits in a heavily modified cache line, we loose. 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: [PATCH 2.6] I2C: Drop I2C_DEVNAME and i2c_clientname
Hi Mauro, > > I2C_DEVNAME and i2c_clientname were introduced in 2.5.68 [1] to help > > media/video driver authors who wanted their code to be compatible > > with both Linux 2.4 and 2.6. The cause of the incompatibility has > > gone since [2], so I think we can get rid of them, as they tend to > > make the code harder to read and longer to preprocess/compile for no > > more benefit. > > > > I'd hope nobody seriously attempts to keep media/video driver > > compatible across Linux trees anymore, BTW. > > That's not true. We keep V4L tree compatible with older kernel > releases. Each change like this does generate a lot of work at V4L > side to provide #ifdefs to check for linux version and provide a > compatible way to compile with older versions. I'm sorry but we will not stop updating the various Linux 2.6 subsystems to keep them compatible with 2.4 - else one would wonder why there is a 2.6 kernel tree at all. As time goes, the differences bwteen 2.4 and 2.6 will only increase. You seem to be trying to keep common driver code across incompatible trees. I'm not surprised that it is a lot of work. That's your choice, live with it. > I don't see any sense on applying this patch, since it will not reduce > code size or increase execution time. Code size and execution time are not the only factors to take into account. Code readability and compilation time are two other ones that I mentioned already. Anyway, it doesn't look like you actually read what I wrote in the first place. My comment about common driver code was really only by the way. The reason why I have been proposing this patch is that I2C_DEVNAME and i2c_clientname were only needed between Linux 2.5.68 and 2.6.0-test3, which are unsupported by now, as they were development releases. As far as i2c_client.name is concerned, 2.4 and 2.6.0+ trees are compatible. Thanks, -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/