Re: [PATCH] kernel: use kcalloc instead kmalloc/memset
On Thu, 4 Aug 2005, Andrew Morton wrote: > That'll generate just as much code as simply using kcalloc(1, ...). This > function should be out-of-line and EXPORT_SYMBOL()ed. And kcalloc() can > call it too.. Yes, much better now. Thanks Andrew. Pekka [PATCH] introduce kzalloc This patch introduces a kzalloc wrapper and converts kernel/ to use it. Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]> --- include/linux/slab.h |1 + kernel/intermodule.c |3 +-- kernel/params.c |4 ++-- kernel/power/pm.c|3 +-- kernel/resource.c|3 +-- kernel/workqueue.c |3 +-- mm/slab.c| 19 +++ 7 files changed, 22 insertions(+), 14 deletions(-) Index: 2.6/kernel/resource.c === --- 2.6.orig/kernel/resource.c +++ 2.6/kernel/resource.c @@ -430,10 +430,9 @@ EXPORT_SYMBOL(adjust_resource); */ struct resource * __request_region(struct resource *parent, unsigned long start, unsigned long n, const char *name) { - struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL); + struct resource *res = kzalloc(sizeof(*res), GFP_KERNEL); if (res) { - memset(res, 0, sizeof(*res)); res->name = name; res->start = start; res->end = start + n - 1; Index: 2.6/kernel/intermodule.c === --- 2.6.orig/kernel/intermodule.c +++ 2.6/kernel/intermodule.c @@ -39,7 +39,7 @@ void inter_module_register(const char *i struct list_head *tmp; struct inter_module_entry *ime, *ime_new; - if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) { + if (!(ime_new = kzalloc(sizeof(*ime), GFP_KERNEL))) { /* Overloaded kernel, not fatal */ printk(KERN_ERR "Aiee, inter_module_register: cannot kmalloc entry for '%s'\n", @@ -47,7 +47,6 @@ void inter_module_register(const char *i kmalloc_failed = 1; return; } - memset(ime_new, 0, sizeof(*ime_new)); ime_new->im_name = im_name; ime_new->owner = owner; ime_new->userdata = userdata; Index: 2.6/kernel/params.c === --- 2.6.orig/kernel/params.c +++ 2.6/kernel/params.c @@ -542,8 +542,8 @@ static void __init kernel_param_sysfs_se { struct module_kobject *mk; - mk = kmalloc(sizeof(struct module_kobject), GFP_KERNEL); - memset(mk, 0, sizeof(struct module_kobject)); + mk = kzalloc(sizeof(struct module_kobject), GFP_KERNEL); + BUG_ON(!mk); mk->mod = THIS_MODULE; kobj_set_kset_s(mk, module_subsys); Index: 2.6/kernel/power/pm.c === --- 2.6.orig/kernel/power/pm.c +++ 2.6/kernel/power/pm.c @@ -60,9 +60,8 @@ struct pm_dev *pm_register(pm_dev_t type unsigned long id, pm_callback callback) { - struct pm_dev *dev = kmalloc(sizeof(struct pm_dev), GFP_KERNEL); + struct pm_dev *dev = kzalloc(sizeof(struct pm_dev), GFP_KERNEL); if (dev) { - memset(dev, 0, sizeof(*dev)); dev->type = type; dev->id = id; dev->callback = callback; Index: 2.6/kernel/workqueue.c === --- 2.6.orig/kernel/workqueue.c +++ 2.6/kernel/workqueue.c @@ -310,10 +310,9 @@ struct workqueue_struct *__create_workqu BUG_ON(strlen(name) > 10); - wq = kmalloc(sizeof(*wq), GFP_KERNEL); + wq = kzalloc(sizeof(*wq), GFP_KERNEL); if (!wq) return NULL; - memset(wq, 0, sizeof(*wq)); wq->name = name; /* We don't need the distraction of CPUs appearing and vanishing. */ Index: 2.6/include/linux/slab.h === --- 2.6.orig/include/linux/slab.h +++ 2.6/include/linux/slab.h @@ -100,6 +100,7 @@ found: } extern void *kcalloc(size_t, size_t, unsigned int __nocast); +extern void *kzalloc(size_t, unsigned int __nocast); extern void kfree(const void *); extern unsigned int ksize(const void *); Index: 2.6/mm/slab.c === --- 2.6.orig/mm/slab.c +++ 2.6/mm/slab.c @@ -2555,6 +2555,20 @@ void kmem_cache_free(kmem_cache_t *cache EXPORT_SYMBOL(kmem_cache_free); /** + * kzalloc - allocate memory. The memory is set to zero. + * @size: how many bytes of memory are required. + * @flags: the type of memory to allocate. + */ +void *kzalloc(size_t size, unsigned int __nocast flags) +{ + void *ret = kmalloc(size, flags); + if (ret) + memset(ret, 0, size); + return ret; +} +EXPORT_SYMBOL(kzalloc); + +/** * kcalloc - allocate memory for an array. The
Re: [linux-usb-devel] Re: Fw: ati-remote strangeness from 2.6.12 onwards
Hi, Andrew Morton wrote: IOW: what does this (wordwrapped!) patch do? It changes the keycode the kernel is sending for three keys. For normal keyboards there is usually no argument to which keycode to send. An 'a' would send the keycoe for an 'a'. This however is a remote control. The keys are labled 'OK', 'TV' and 'DVD'. Therefore the kernel currently sends the keycodes KEY_OK, KEY_TV and KEY_DVD. The patch changes this to KEY_ENTER, KEY_PROG1 and KEY_PROG2. I do not know about the motivation of this patch, as the kernel currently _does_ send keycodes, maybe just not the ones the some users might want. IMHO this is an issue of remapping the keycodes in userspace and I would like to leave the kernel-codes alone. However, I might not see the whole problem here because it is working fine for me. Btw, Pavel: > No, I think that you can still diferentiate between them ... they come > from different keyboard after all. See /dev/input/event*. How can I tell the consoles of linux which keyboard to use? So far they all use all keyboards (which is my usual keyboard mixed with the remote control keys). (Yes, I searched google extensivly and no, I do not have X on that machine.) Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ck] [PATCH] Timer Top was: i386 No-Idle-Hz aka Dynamic-Ticks 3
On Thu, Aug 04 2005, Daniel Petrini wrote: > +static LIST_HEAD(timer_list); > + > +struct timer_top_info { > + unsigned intfunc_pointer; > + unsigned int long counter; > + struct list_headlist; > +}; > + > +struct timer_top_info top_info; > + > +int account_timer(unsigned int function, struct timer_top_info * top_info) > +{ > + struct timer_top_info *top; > + > + list_for_each_entry (top, &timer_list, list) { > + /* if it is in the list increment its count */ > + if (top->func_pointer == function) { > + top->counter += 1; > + return 0; > + } > + } What protects this list? > + > + /* if you are here then it didnt find so inserts in the list */ > + > + top = kmalloc(sizeof(struct timer_top_info), GFP_KERNEL); > + if (!top) > + return -ENOMEM; You can't use GFP_KERNEL here, you are inside the timer base lock. -- 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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
On Fri, Aug 05, 2005 at 12:07:55AM -0400, Michael Krufky wrote: > >Sounds like a fun thing for post-2.6.13. > > > >What does usb-handoff do, precisely? > > > I just did a series tests. This is necessary, because the problem was > intermittent for me. usb-handoff fixes all of my problems!!! > > without using usb-handoff, my ps/2 mouse works 1/10 times > using usb-handoff, my ps/2 mouse works 10/10 times > > I consider the problem solved... If Dmitry wants to make usb-handoff the > default, he has my support :-). Here is a patch from the SuSE kernel CVS. It's been in SuSE's kernels since 9.1 I believe, and that's a long time. [usb-handoff-default.diff] Date: Fri Mar 4 21:53:39 CET 2005 From: Vojtech Pavlik <[EMAIL PROTECTED]> Subject: Make "usb-handoff" the default, "usb-no-handoff" turns it off. = Documentation/kernel-parameters.txt |1 + drivers/pci/quirks.c|8 +++- 2 files changed, 8 insertions(+), 1 deletion(-) = diff -ur linux-2.6.12/Documentation/kernel-parameters.txt linux-2.6.12-input/Documentation/kernel-parameters.txt --- linux-2.6.12/Documentation/kernel-parameters.txt2005-06-24 15:56:17.0 +0200 +++ linux-2.6.12-input/Documentation/kernel-parameters.txt 2005-06-24 15:57:06.0 +0200 @@ -1456,6 +1456,7 @@ Format: , usb-handoff [HW] Enable early USB BIOS -> OS handoff + usb-no-handoff [HW] Disable early USB BIOS -> OS handoff usbhid.mousepoll= [USBHID] The interval which mice are to be polled at. diff -ur linux-2.6.12/drivers/pci/quirks.c linux-2.6.12-input/drivers/pci/quirks.c --- linux-2.6.12/drivers/pci/quirks.c 2005-06-24 15:56:17.0 +0200 +++ linux-2.6.12-input/drivers/pci/quirks.c 2005-06-24 15:56:42.0 +0200 @@ -902,13 +902,23 @@ #define EHCI_USBLEGCTLSTS 4 /* legacy control/status */ #define EHCI_USBLEGCTLSTS_SOOE (1 << 13) /* SMI on ownership change */ +#if defined(__i386__) || defined(__x86_64__) +int usb_early_handoff __devinitdata = 1; /* Do handoff by default */ +#else int usb_early_handoff __devinitdata = 0; +#endif static int __init usb_handoff_early(char *str) { usb_early_handoff = 1; return 0; } __setup("usb-handoff", usb_handoff_early); +static int __init usb_no_handoff_early(char *str) +{ + usb_early_handoff = 0; + return 0; +} +__setup("usb-no-handoff", usb_no_handoff_early); static void __devinit quirk_usb_handoff_uhci(struct pci_dev *pdev) { -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Symbios problems in recent -mm trees?
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote: > > If you look on http://test.kernel.org/, you'll see in the rightmost > column there's a yellow box under elm3b70 for 2.6.13-rc4-mm1, but > current mainline kernels are all green (ie no problems). That means > one test failed, in this case making an fs on the spare partition. > Odd. I went digging ... Don't you know that testing stuff just creates more work? > Looks like this got introduced between 2.6.12-mm1 and 2.6.12-mm2 > Sorry, should've caught it earlier. I'll blame OLS or something. > This is an 8x power4 box running "bare metal" (ie not on top of > the hypervisor). sym2 works OK on my little test box with latest -mm lineup, and I have zero patches which touch that driver. James, could some of the scsi core rework have caused this? > seems /dev/sdc1 doesn't exist. > 07/31/05-02:44:32 processing command: (5) 'fs --partition=1 --mkext2fs > --mount -l /mnt/tmp' > n format > PARTITION='/dev/sdc1' > mke2fs 1.35 (28-Feb-2004) > mkfs.ext2: No such device or address while trying to determine filesystem size > 07/31/05-02:44:32 fs: creating filesystem ext2 Failed rc = 1 > > Looking back at the bootlog (http://test.kernel.org/9609/debug/console.log), > I see it really not looking very happy (snapshot below). > > Good bootlog is here for comparsion: > (http://test.kernel.org/9445/debug/console.log) > > sym0: <1010-66> rev 0x1 at pci 0001:01:01.0 irq 115 > sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking > sym0: SCSI BUS has been reset. > scsi0 : sym-2.2.1 > target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) > Vendor: IBM Model: IC35L036UCDY10-0 Rev: S25M > Type: Direct-Access ANSI SCSI revision: 03 > target0:0:8: tagged command queuing enabled, command queue depth 16. > target0:0:8: Beginning Domain Validation > target0:0:8: asynchronous. > target0:0:8: wide asynchronous. > target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31) > sym0: unexpected disconnect > target0:0:8: Write Buffer failure 700ff > target0:0:8: Domain Validation Disabing Information Units > target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) > sym0: unexpected disconnect > target0:0:8: Write Buffer failure 700ff > target0:0:8: Domain Validation detected failure, dropping back > target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31) > target0:0:8: Ending Domain Validation > target0:0:9: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) > Vendor: IBM Model: IC35L036UCDY10-0 Rev: S25M > Type: Direct-Access ANSI SCSI revision: 03 > target0:0:9: tagged command queuing enabled, command queue depth 16. > target0:0:9: Beginning Domain Validation > target0:0:9: asynchronous. > target0:0:9: wide asynchronous. > target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31) > sym0: unexpected disconnect > target0:0:9: Write Buffer failure 700ff > target0:0:9: Domain Validation Disabing Information Units > target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) > sym0: unexpected disconnect > target0:0:9: Write Buffer failure 700ff > target0:0:9: Domain Validation detected failure, dropping back > target0:0:9: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31) > target0:0:9: Ending Domain Validation > target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) > Vendor: IBM Model: IC35L036UCDY10-0 Rev: S25M > Type: Direct-Access ANSI SCSI revision: 03 > target0:0:10: tagged command queuing enabled, command queue depth 16. > target0:0:10: Beginning Domain Validation > target0:0:10: asynchronous. > target0:0:10: wide asynchronous. > target0:0:10: Domain Validation skipping write tests > target0:0:10: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31) > sym0: unexpected disconnect > target0:0:10: Domain Validation Disabing Information Units > target0:0:10: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) > sym0: unexpected disconnect > target0:0:10: Domain Validation detected failure, dropping back > target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31) > target0:0:10: Ending Domain Validation > Vendor: IBM Model: HSBPM2 PU2SCSI Rev: 0016 > Type: Enclosure ANSI SCSI revision: 02 > target0:0:14: Beginning Domain Validation > 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7. > 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7. > 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7. > 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7. > target0:0:14: Ending Domain Validation > Vendor: IBM Model: HSBPD4M PU3SCSI Rev: 0016 > Type: Enclosure ANSI SCSI revision: 02 > target0:0:15: Beginning Domain Validation > 0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7. > 0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7. > 0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
Re: Power consumption HZ100, HZ250, HZ1000: new numbers
Ondrej Zary wrote: James Bruce wrote: Stephen Clark wrote: Maybe new desktop systems - but what about the tens of millions of old systems that don't. If it's an old system, it probably doesn't have working ACPI C-states though. Without that, low HZ does not save you anything. I should have said: 99% of desktops with the capability to do ACPI sleep have at least one USB device attached (usually a mouse). [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU0/power active state:C2 max_cstate: C8 bus master activity: states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00052470] *C2: type[C2] promotion[--] demotion[C1] latency[090] usage[02699149] This is PCPartner TXB820DS motherboard (Socket 7, i430TX) with 1998 Award BIOS and C-states seem to work fine. I've tested it in Windows 98 some time ago - the CPU is almost cold when idle with ACPI enabled and hot with ACPI disabled (that's partly caused by the fact that Windows 9x does not HLT the CPU when idle). With Pentium 100MHz in the socket and ACPI enabled, I could even touch the CPU (without heatsink) without burning my fingers. Ok I stand corrected, I had no idea there were machines that old where ACPI worked correctly in Linux. Do you see the same kind of heat reduction in Linux as Win98? What HZ value are you using, as the latency for entering C2 on your machine looks pretty substantial (Your C2 almost looks like a new machine's C3 state, which is supposedly the first level where substantial power savings occur on a new machines). - Jim Bruce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] kernel: use kcalloc instead kmalloc/memset
Pekka J Enberg <[EMAIL PROTECTED]> wrote: > > [PATCH] use kzalloc instead of kmalloc/memset > dammit, I was hoping for akpmalloc() > > +static inline void *kzalloc(size_t size, unsigned int __nocast flags) > +{ > + return kcalloc(1, size, flags); > +} > + That'll generate just as much code as simply using kcalloc(1, ...). This function should be out-of-line and EXPORT_SYMBOL()ed. And kcalloc() can call it too.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: /proc question
Jan Engelhardt wrote: I have a zombie process which has apparently died for some unknown reason.. I know it was terminated by a signal (found that from the 9th field (sheduler flags) in /proc/pid/stat) Start the process under the observation of strace. However, I'm trying to figure out what signal killed it. Jan Engelhardt Wish I could.. but it's already happened (to a lot of processes for the same reason) It's an intermittant problem and can't really reproduce it at will. I've redeployed the binary now so I can hopefully attach to it with gdb to figure out some things next time it does happen. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] kernel: use kcalloc instead kmalloc/memset
Hi Andrew, Pekka Enberg <[EMAIL PROTECTED]> wrote: > > This patch converts kernel/ to use kcalloc instead of kmalloc/memset. On Thu, 4 Aug 2005, Andrew Morton wrote: > grr. I am learning grep. Please don't eat me! > > - struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL); > > + struct resource *res = kcalloc(1, sizeof(*res), GFP_KERNEL); > > Notice how every conversion you did passes in `1' in the first argument? > > And that's going to happen again and again and again. Each callsite > needlessly passing that silly third argument, adding more kernel text. > > If we're going to do this, we should add a two-arg helper function first, > and use that, no? This was discussed some time ago [1] and here's a patch for you to do that. Pekka 1. http://marc.theaimsgroup.com/?l=linux-kernel&m=111279001428661&w=2 [PATCH] use kzalloc instead of kmalloc/memset This patch introduces a kzalloc wrapper and converts kernel/ to use it. Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]> --- include/linux/slab.h |5 + kernel/intermodule.c |3 +-- kernel/params.c |4 ++-- kernel/power/pm.c|3 +-- kernel/resource.c|3 +-- kernel/workqueue.c |3 +-- 6 files changed, 11 insertions(+), 10 deletions(-) Index: 2.6/kernel/resource.c === --- 2.6.orig/kernel/resource.c +++ 2.6/kernel/resource.c @@ -430,10 +430,9 @@ EXPORT_SYMBOL(adjust_resource); */ struct resource * __request_region(struct resource *parent, unsigned long start, unsigned long n, const char *name) { - struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL); + struct resource *res = kzalloc(sizeof(*res), GFP_KERNEL); if (res) { - memset(res, 0, sizeof(*res)); res->name = name; res->start = start; res->end = start + n - 1; Index: 2.6/kernel/intermodule.c === --- 2.6.orig/kernel/intermodule.c +++ 2.6/kernel/intermodule.c @@ -39,7 +39,7 @@ void inter_module_register(const char *i struct list_head *tmp; struct inter_module_entry *ime, *ime_new; - if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) { + if (!(ime_new = kzalloc(sizeof(*ime), GFP_KERNEL))) { /* Overloaded kernel, not fatal */ printk(KERN_ERR "Aiee, inter_module_register: cannot kmalloc entry for '%s'\n", @@ -47,7 +47,6 @@ void inter_module_register(const char *i kmalloc_failed = 1; return; } - memset(ime_new, 0, sizeof(*ime_new)); ime_new->im_name = im_name; ime_new->owner = owner; ime_new->userdata = userdata; Index: 2.6/kernel/params.c === --- 2.6.orig/kernel/params.c +++ 2.6/kernel/params.c @@ -542,8 +542,8 @@ static void __init kernel_param_sysfs_se { struct module_kobject *mk; - mk = kmalloc(sizeof(struct module_kobject), GFP_KERNEL); - memset(mk, 0, sizeof(struct module_kobject)); + mk = kzalloc(sizeof(struct module_kobject), GFP_KERNEL); + BUG_ON(!mk); mk->mod = THIS_MODULE; kobj_set_kset_s(mk, module_subsys); Index: 2.6/kernel/power/pm.c === --- 2.6.orig/kernel/power/pm.c +++ 2.6/kernel/power/pm.c @@ -60,9 +60,8 @@ struct pm_dev *pm_register(pm_dev_t type unsigned long id, pm_callback callback) { - struct pm_dev *dev = kmalloc(sizeof(struct pm_dev), GFP_KERNEL); + struct pm_dev *dev = kzalloc(sizeof(struct pm_dev), GFP_KERNEL); if (dev) { - memset(dev, 0, sizeof(*dev)); dev->type = type; dev->id = id; dev->callback = callback; Index: 2.6/kernel/workqueue.c === --- 2.6.orig/kernel/workqueue.c +++ 2.6/kernel/workqueue.c @@ -310,10 +310,9 @@ struct workqueue_struct *__create_workqu BUG_ON(strlen(name) > 10); - wq = kmalloc(sizeof(*wq), GFP_KERNEL); + wq = kzalloc(sizeof(*wq), GFP_KERNEL); if (!wq) return NULL; - memset(wq, 0, sizeof(*wq)); wq->name = name; /* We don't need the distraction of CPUs appearing and vanishing. */ Index: 2.6/include/linux/slab.h === --- 2.6.orig/include/linux/slab.h +++ 2.6/include/linux/slab.h @@ -103,6 +103,11 @@ extern void *kcalloc(size_t, size_t, uns extern void kfree(const void *); extern unsigned int ksize(const void *); +static inline void *kzalloc(size_t size, unsigned int __nocast flags) +{ + return kcalloc(1, size, flags); +} + #ifdef CONFIG_NUMA extern void *kmem_cache_alloc_node(kmem_cache_t *, int
Re: /proc question
> I have a zombie process which has apparently died for some unknown reason.. I > know it was terminated by a signal (found that from the 9th field (sheduler > flags) in /proc/pid/stat) Start the process under the observation of strace. > However, I'm trying to figure out what signal killed it. Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: make modules Segfault
>> Gnu C 2.96 > > Seriously, it seems like your machine is flaky. > And even if it were a kernel source problem, > gcc should never have an internal error. > But gcc-2.96 is so old that it's not supported anymore. Wasnot 2.96 the bugged one? Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Old api files, rewrite or delete?
> Nothing, I don't only want to rewrite driver, which others do not use. Why rewrite? (unless it's an important api change) If it's some optimization patch that requires an almost-rewrite, well, do it and see if it gets accepted. Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Speedup FAT filesystem directory reads
>We like a plain text, not attachment, see Documentation/SubmittingPatches. >Anyway, thanks for nice work. |Exception: If your mailer is mangling patches then someone may ask |you to re-send them using MIME. from the doc ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Symbios problems in recent -mm trees?
If you look on http://test.kernel.org/, you'll see in the rightmost column there's a yellow box under elm3b70 for 2.6.13-rc4-mm1, but current mainline kernels are all green (ie no problems). That means one test failed, in this case making an fs on the spare partition. Odd. I went digging ... Looks like this got introduced between 2.6.12-mm1 and 2.6.12-mm2 Sorry, should've caught it earlier. I'll blame OLS or something. This is an 8x power4 box running "bare metal" (ie not on top of the hypervisor). seems /dev/sdc1 doesn't exist. 07/31/05-02:44:32 processing command: (5) 'fs --partition=1 --mkext2fs --mount -l /mnt/tmp' n format PARTITION='/dev/sdc1' mke2fs 1.35 (28-Feb-2004) mkfs.ext2: No such device or address while trying to determine filesystem size 07/31/05-02:44:32 fs: creating filesystem ext2 Failed rc = 1 Looking back at the bootlog (http://test.kernel.org/9609/debug/console.log), I see it really not looking very happy (snapshot below). Good bootlog is here for comparsion: (http://test.kernel.org/9445/debug/console.log) sym0: <1010-66> rev 0x1 at pci 0001:01:01.0 irq 115 sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking sym0: SCSI BUS has been reset. scsi0 : sym-2.2.1 target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) Vendor: IBM Model: IC35L036UCDY10-0 Rev: S25M Type: Direct-Access ANSI SCSI revision: 03 target0:0:8: tagged command queuing enabled, command queue depth 16. target0:0:8: Beginning Domain Validation target0:0:8: asynchronous. target0:0:8: wide asynchronous. target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31) sym0: unexpected disconnect target0:0:8: Write Buffer failure 700ff target0:0:8: Domain Validation Disabing Information Units target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) sym0: unexpected disconnect target0:0:8: Write Buffer failure 700ff target0:0:8: Domain Validation detected failure, dropping back target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31) target0:0:8: Ending Domain Validation target0:0:9: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) Vendor: IBM Model: IC35L036UCDY10-0 Rev: S25M Type: Direct-Access ANSI SCSI revision: 03 target0:0:9: tagged command queuing enabled, command queue depth 16. target0:0:9: Beginning Domain Validation target0:0:9: asynchronous. target0:0:9: wide asynchronous. target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31) sym0: unexpected disconnect target0:0:9: Write Buffer failure 700ff target0:0:9: Domain Validation Disabing Information Units target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) sym0: unexpected disconnect target0:0:9: Write Buffer failure 700ff target0:0:9: Domain Validation detected failure, dropping back target0:0:9: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31) target0:0:9: Ending Domain Validation target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) Vendor: IBM Model: IC35L036UCDY10-0 Rev: S25M Type: Direct-Access ANSI SCSI revision: 03 target0:0:10: tagged command queuing enabled, command queue depth 16. target0:0:10: Beginning Domain Validation target0:0:10: asynchronous. target0:0:10: wide asynchronous. target0:0:10: Domain Validation skipping write tests target0:0:10: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31) sym0: unexpected disconnect target0:0:10: Domain Validation Disabing Information Units target0:0:10: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) sym0: unexpected disconnect target0:0:10: Domain Validation detected failure, dropping back target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31) target0:0:10: Ending Domain Validation Vendor: IBM Model: HSBPM2 PU2SCSI Rev: 0016 Type: Enclosure ANSI SCSI revision: 02 target0:0:14: Beginning Domain Validation 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7. 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7. 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7. 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7. target0:0:14: Ending Domain Validation Vendor: IBM Model: HSBPD4M PU3SCSI Rev: 0016 Type: Enclosure ANSI SCSI revision: 02 target0:0:15: Beginning Domain Validation 0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7. 0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7. 0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7. 0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7. target0:0:15: Ending Domain Validation sym1: <1010-66> rev 0x1 at pci 0001:01:01.1 irq 116 sym1: No NVRAM, ID 7, Fast-80, LVD, parity checking sym1: SCSI BUS has been reset. scsi1 : sym-2.2.1 sym2: <1010-66> rev 0x1 at pci 0001:41:01.0 irq 119 sym2: No NVRAM, ID 7, Fast-80, LVD, parity checking sym2: SCSI BUS has been reset. scsi2 : sym-2.2.1 sym3: <1010-66> rev 0x1 at pci 0001:41:01.1 irq 120 sym3: N
Re: Oops when shutting down laptop
Kristian Grønfeldt Sørensen <[EMAIL PROTECTED]> wrote: > > My laptop oops'es in the final phase of shutdown. It started this > Monday. I don't remember having done anything particular with respect to > the kernel around that time. It only happens when going to runlevel 0 - > a reboot does not result in an oops. > > Until yesterday i used kernel 2.6.13-rc3, but i have now compiled > 2.6.13-rc5 with some debugging support. However the problem persists. > > Since the oops happens so late in the shutdown-sequence, that all > filesystems has been unmounted, i am unable to capture the oops on the > disc, but a picture of the oops is available at > http://www.vkr.dk/~kriller/oops.jpg . (Sorry for not writing the oops in > this mail). > > I tried to remove all modules except speedstep_centrino, freqtable, > processor and ipv6 (reported as being in use), before calling poweroff, > but with no change. We've been busily reverting new power management patches and it's likely that we fixed this one in the past day or so. So please test 2.6.13-rc6 when it comes out, or 2.6.13-rc5-git3 which is about three hours away, thanks. If it still happens please add the below patch so we can work out the offending device. Or apply it anyway - we may have a buggy driver which will just bite us again later. Thanks. --- devel/drivers/base/power/suspend.c~a2005-08-04 23:06:27.0 -0700 +++ devel-akpm/drivers/base/power/suspend.c 2005-08-04 23:08:06.0 -0700 @@ -92,6 +92,8 @@ int device_suspend(pm_message_t state) get_device(dev); up(&dpm_list_sem); + printk("Suspending device %s\n", kobject_name(&dev->kobj)); + error = suspend_device(dev, state); down(&dpm_list_sem); _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/proc question
After much research.. I have a question regarding /proc I have a zombie process which has apparently died for some unknown reason.. I know it was terminated by a signal (found that from the 9th field (sheduler flags) in /proc/pid/stat) However, I'm trying to figure out what signal killed it. Also, it would be nice if /proc could show what the exit status of a dead process is.. seems strange that it doesn't contain that information (or am I just not seeing it in there). Any info would be helpful.. thanks, Davy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: squashfs seems nfs-incompatible
Hi, >> I found out that you cannot mount an exported squash fs. The exports(5) fsid= >> parameter does not help it [like it did with unionfs]. > >The exports(5) man page says fsid=num is necessary for filesystems on >non-block devices - I don't know whether this includes loopback >filesystems. Have you tried exporting a Squashfs filesystem mounted >on a real block device? Loopback is a real block device, and no, fsid= does not help it. I have talked with the unionfs people, because it works for them. After a short flash of idea and comparison, it turns out that squashfs is missing sb->s_export->get_parent (the only requirement as it seems). Includes that you have sb->s_export non-null, of course. sb->s_export can be set within fill_super(). >I've never tried to export a Squashfs filesystem, and so I don't know >if it works. If it doesn't, I would say it is because Squashfs (like >Cramfs) doesn't store correct nlink information for directories. > >The next release does store nlink information, has support for > 4GB >files/filesystems, and other nice improvements. I'm hoping to release >an alpha release soon. FTR, I currently cheated by using `mount -t unionfs -o dirs=/squash=ro none /squash` to get the export working. Jan Engelhardt -- | Alphagate Systems, http://alphagate.hopto.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HOW to handle partitions on SD Card in the driver?
Dear all, I have problem with my new driver that tired to support the partitions support on SD cards. My driver supports 4 SD cards at a time. The driver works well when there are partitions are disabled. i.e. when alloc_disk(1); - i.e. no partitions. It absolutely fine. Right now, I am working on getting the driver up with partitions supported. After making below changes in the gendisk initialization, I am able to mount the device in the socket 0 but I am NOT able mount the devices in the rest of the sockets when partitions are enabled? Changes made in gendisk code gDisk->gd = alloc_disk(4); /* 3 -> 3 partitions */ gDisk->gd->first_minor = (iSock * 4); i.e. iSock = device no [0-3] ( 4 devices) Physical nodes creation To support partitions on device 0 - mknod /dev/tfa0 b 252 0 ; mknod /dev/tfa1 b 252 1 mknod /dev/tfa2 b 252 2 ; mknod /dev/tfa3 b 252 3 To support partitions on device 1 - mknod /dev/tfa4 b 252 4 ; mknod /dev/tfa5 b 252 5 mknod /dev/tfa6 b 252 6 ; mknod /dev/tfa7 b 252 7 To support partitions on device 2 - mknod /dev/tfa8 b 252 8 ; mknod /dev/tfa9 b 252 9 mknod /dev/tfa10 b 252 10 ; mknod /dev/tfa11 b 252 11 To support partitions on device 3 - mknod /dev/tfa12 b 252 12 ; mknod /dev/tfa13 b 252 13 mknod /dev/tfa14 b 252 14 ; mknod /dev/tfa15 b 252 15 With these physical nodes, I thought I am through & it should work. When a card is inserted in the socket 0, I am able to mount. #mount /dev/tfa0 /mnt (works fine & mounts) BUT, when a card is inserted in the socket 3, I am NOT able to mount. #mount /dev/tfa12 /mnt Mount: /dev/tfa12 is not a valid block device However, I am in bit confusion whether the above mentioned changes to the gendisk code will suffice to my partition requirement or NOT? This gendisk is invoked at on every socket initialization i.e. when card is inserted. Can anyone convey me where exactly I am missing or why is it failing? Any suggestion will be greatly helpful? Thanks & Regards, Mukund Jampala - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 partition support driver methods
Dear Corbet, After loading my module that is partitioned supported & having defined a single FAT partition with #mkfs -tvfat /dev/tfa0 sfdisk show the disk info as follows. # sfdisk -l /dev/taf0 Disk /dev/tfa0: 448 cylinders, 2 heads, 32 sectors/track Units = cylinders of 32768 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls#blocks Id System /dev/tfa0p1 0 - 0 00 Empty /dev/tfa0p2 0 - 0 00 Empty /dev/tfa0p3 0 - 0 00 Empty /dev/tfa0p4 0 - 0 00 Empty Dear Corbet, Here are the details u might be interested in. I have explained my physical node creation logic below. #Cat/proc/partitions major minor #blocks name 3 0 78184008 hda 3 16144831 hda1 3 2 10241437 hda2 3 31285200 hda3 3 4 1 hda4 3 5 10241406 hda5 252 0 14336 tfa0 Can you just please explain me what can infer from the cat /proc/partitions? Do we expect all the 4 partitions to be show here? My node creation method is simple Kern code - gDisk->gd = alloc_disk(4); /* 3 -> 3 partitions */ gDisk->gd->first_minor = (iSock * 4); i.e. iSock = device no [0-3] ( 4 devices) Physical nodes design - To support partitions on device 0 - mknod /dev/tfa0 b 252 0 mknod /dev/tfa1 b 252 1 mknod /dev/tfa2 b 252 2 mknod /dev/tfa3 b 252 3 To support partitions on device 1 - mknod /dev/tfa4 b 252 4 mknod /dev/tfa5 b 252 5 mknod /dev/tfa6 b 252 6 mknod /dev/tfa7 b 252 7 To support partitions on device 2 - mknod /dev/tfa8 b 252 8 mknod /dev/tfa9 b 252 9 mknod /dev/tfa10 b 252 10 mknod /dev/tfa11 b 252 11 To support partitions on device 3 - mknod /dev/tfa12 b 252 12 mknod /dev/tfa13 b 252 13 mknod /dev/tfa14 b 252 14 mknod /dev/tfa15 b 252 15 Thanks & Regards, Mukund Jampala >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Thursday, August 04, 2005 8:09 PM >To: Mukund JB. >Cc: linux-kernel@vger.kernel.org >Subject: Re: 2.6 partition support driver methods > >Mukund JB. <[EMAIL PROTECTED]> wrote: > >> BUT, when a card is inserted in the socket 3, I am NOT able to mount and >> it says. >> Mount: /dev/tfa12 is not a valid block device >> >> Can you convey me where exactly I am missing or why is it failing? > >First step would be to look in /proc/partitions (and the system logfile) >to get an idea of what the kernel thinks is there. When you call >add_disk(), the kernel should emit some messages noting the partitions >that it sees. My guess is a mismatch of minor numbers between your >device nodes and what the kernel sees (it's hard for me to make complete >sense out of your minor number logic), but I could be wrong. > >jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 select doesn't notify readablity of /proc/loadavg.
Hi. select in Linux 2.6.12.3 doesn't notify readability of /proc/loadavg and several other files under /proc. It is reproducible as follows. The sample program follow blocks because select doesn't notify readability. % uname -a Linux debiansarge 2.6.12.3 #1 Thu Aug 4 20:23:16 JST 2005 i686 GNU/Linux % cat /proc/version Linux version 2.6.12.3 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 Thu Aug 4 20:23:16 JST 2005 % cat t.c #include #include #include #include #include int main(int argc, char **argv) { int fd, ret; fd_set readfds; fd = open(argv[1], O_RDONLY); if (fd == -1) { perror("open"); exit(1); } FD_ZERO(&readfds); FD_SET(fd, &readfds); ret = select(fd+1, &readfds, NULL, NULL, NULL); printf("select returns %d\n", ret); return 0; } % gcc t.c % ./a.out /proc/loadavg This program blocks here. /proc/loadavg can be read by cat. % ./a.out /proc/loadavg ^C % cat /proc/loadavg 0.00 0.00 0.00 2/36 2597 Also, /proc/cmdline, /proc/devices, /proc/execdomains, /proc/fb, /proc/filesystems, /proc/locks, /proc/meminfo, /proc/uptime and /proc/version are blocks too. Is this behaviour intentional? The output of ver_linux is follows. % sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux debiansarge 2.6.12.3 #1 Thu Aug 4 20:23:16 JST 2005 i686 GNU/Linux Gnu C 3.3.5 Gnu make 3.80 binutils 2.15 util-linux 2.12p mount 2.12p module-init-tools 3.2-pre1 e2fsprogs 1.37 reiserfsprogs line reiser4progs line nfs-utils 1.0.6 Linux C Library2.3.2 Dynamic linker (ldd) 2.3.2 Procps 3.2.1 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.2.1 Modules Loaded md5 ipv6 evdev ehci_hcd usbcore shpchp pci_hotplug intel_agp piix pcnet32 mii crc32 agpgart ide_disk ide_cd cdrom ide_core rtc unix Note that select notify readability of /proc/loadavg on Linux 2.4.20. % uname -a Linux serein 2.4.20-686 #1 Mon Jan 13 22:22:30 EST 2003 i686 GNU/Linux % ./a.out /proc/loadavg select returns 1 -- Tanaka Akira - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] kernel: use kcalloc instead kmalloc/memset
Pekka Enberg <[EMAIL PROTECTED]> wrote: > > This patch converts kernel/ to use kcalloc instead of kmalloc/memset. > grr. > -struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL); > +struct resource *res = kcalloc(1, sizeof(*res), GFP_KERNEL); Notice how every conversion you did passes in `1' in the first argument? And that's going to happen again and again and again. Each callsite needlessly passing that silly third argument, adding more kernel text. If we're going to do this, we should add a two-arg helper function first, and use that, no? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] kernel: use kcalloc instead kmalloc/memset
This patch converts kernel/ to use kcalloc instead of kmalloc/memset. Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]> --- intermodule.c |3 +-- params.c |4 ++-- power/pm.c|3 +-- resource.c|3 +-- workqueue.c |3 +-- 5 files changed, 6 insertions(+), 10 deletions(-) Index: 2.6/kernel/resource.c === --- 2.6.orig/kernel/resource.c +++ 2.6/kernel/resource.c @@ -430,10 +430,9 @@ EXPORT_SYMBOL(adjust_resource); */ struct resource * __request_region(struct resource *parent, unsigned long start, unsigned long n, const char *name) { - struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL); + struct resource *res = kcalloc(1, sizeof(*res), GFP_KERNEL); if (res) { - memset(res, 0, sizeof(*res)); res->name = name; res->start = start; res->end = start + n - 1; Index: 2.6/kernel/intermodule.c === --- 2.6.orig/kernel/intermodule.c +++ 2.6/kernel/intermodule.c @@ -39,7 +39,7 @@ void inter_module_register(const char *i struct list_head *tmp; struct inter_module_entry *ime, *ime_new; - if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) { + if (!(ime_new = kcalloc(1, sizeof(*ime), GFP_KERNEL))) { /* Overloaded kernel, not fatal */ printk(KERN_ERR "Aiee, inter_module_register: cannot kmalloc entry for '%s'\n", @@ -47,7 +47,6 @@ void inter_module_register(const char *i kmalloc_failed = 1; return; } - memset(ime_new, 0, sizeof(*ime_new)); ime_new->im_name = im_name; ime_new->owner = owner; ime_new->userdata = userdata; Index: 2.6/kernel/params.c === --- 2.6.orig/kernel/params.c +++ 2.6/kernel/params.c @@ -542,8 +542,8 @@ static void __init kernel_param_sysfs_se { struct module_kobject *mk; - mk = kmalloc(sizeof(struct module_kobject), GFP_KERNEL); - memset(mk, 0, sizeof(struct module_kobject)); + mk = kcalloc(1, sizeof(struct module_kobject), GFP_KERNEL); + BUG_ON(!mk); mk->mod = THIS_MODULE; kobj_set_kset_s(mk, module_subsys); Index: 2.6/kernel/power/pm.c === --- 2.6.orig/kernel/power/pm.c +++ 2.6/kernel/power/pm.c @@ -60,9 +60,8 @@ struct pm_dev *pm_register(pm_dev_t type unsigned long id, pm_callback callback) { - struct pm_dev *dev = kmalloc(sizeof(struct pm_dev), GFP_KERNEL); + struct pm_dev *dev = kcalloc(1, sizeof(struct pm_dev), GFP_KERNEL); if (dev) { - memset(dev, 0, sizeof(*dev)); dev->type = type; dev->id = id; dev->callback = callback; Index: 2.6/kernel/workqueue.c === --- 2.6.orig/kernel/workqueue.c +++ 2.6/kernel/workqueue.c @@ -310,10 +310,9 @@ struct workqueue_struct *__create_workqu BUG_ON(strlen(name) > 10); - wq = kmalloc(sizeof(*wq), GFP_KERNEL); + wq = kcalloc(1, sizeof(*wq), GFP_KERNEL); if (!wq) return NULL; - memset(wq, 0, sizeof(*wq)); wq->name = name; /* We don't need the distraction of CPUs appearing and vanishing. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Fri, 5 Aug 2005 01:03 am, Vojtech Pavlik wrote: > On Wed, Aug 03, 2005 at 04:23:59PM +0200, Jan De Luyck wrote: > > On Wednesday 03 August 2005 14:14, Con Kolivas wrote: > > > On Wed, 3 Aug 2005 21:54, Jan De Luyck wrote: > > > > On Wednesday 03 August 2005 07:59, Con Kolivas wrote: > > > > > This is the dynamic ticks patch for i386 as written by Tony Lindgen > > > > > <[EMAIL PROTECTED]> and Tuukka Tikkanen > > > > > <[EMAIL PROTECTED]>. Patch for 2.6.13-rc5 > > > > > > > > Compiles and runs ok here. > > > > > > > > Is there actually any timer frequency that's advisable to set as > > > > maximum? (in the kernel config) > > > > > > I'd recommend 1000. > > > > Thanks. Currently the system - under X, KDE, no artsd, bottoms at around > > 300HZ. In total single mode with every module unloaded that I can unload > > it stops around 22HZ. > > > > I guess I'll have to go hunting whatever thing is causing the pollings. > > no timertop yet, I guess? :P > > i8042 runs a steady periodic 20Hz timer. You can make it slower to get > even the total low lower, and it will not affect performance under > normal (sane hardware) circumstances. Indeed and this patch (safely tried at home but serves no useful purpose really) confirms a reasonable drop without problems. After this, only fbcon polls at a similar rate (HZ/5). Of interest to those using an ondemand scaling governor, now that we have timertop, I have found that the default ondemand settings lead to delayed_work_timer_fn at about 140Hz and this can be dropped substantially by slowing the rate of polling (and subsequently slowing the speed with which the ondemand governor responds) down to <25 by echo 10 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate (the default is 1 and the value is confusing as the rate goes down as you increase this value). Cheers, Con Index: linux-2.6.13-rc5-ck2/drivers/input/serio/i8042.h === --- linux-2.6.13-rc5-ck2.orig/drivers/input/serio/i8042.h 2005-07-06 16:56:52.0 +1000 +++ linux-2.6.13-rc5-ck2/drivers/input/serio/i8042.h 2005-08-05 15:03:49.0 +1000 @@ -44,7 +44,7 @@ * polling. */ -#define I8042_POLL_PERIOD HZ/20 +#define I8042_POLL_PERIOD HZ/5 /* * Status register bits.
re: make modules Segfault
George Van Tuyl <[EMAIL PROTECTED]> wrote: > gcc: Internal error: Segmentation fault (program cpp0) > ... > make[3]: Leaving directory `/usr/src/linux-2.4.31/drivers/net/wan' > ... > Gnu C 2.96 > ... cpu family: 6 model : 4 model name: AMD Athlon(tm) Processor stepping : 4 cpu MHz : 1400.110 ... > I expect you to tell me to upgrade everything. Nah. Stop overclocking, and *then* upgrade everything :-) Seriously, it seems like your machine is flaky. And even if it were a kernel source problem, gcc should never have an internal error. But gcc-2.96 is so old that it's not supported anymore. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: make modules Segfault
On Thu, 04 Aug 2005 21:20:22 -0600 George Van Tuyl wrote: > > To: linux-kernel@vger.kernel.org > > > > [1.] One line summary of the problem: > >make modules failed Segfault (program cpp0) > > [2.] Full description of the problem/report: > > gcc: Internal error: Segmentation fault (program cpp0) > Please submit a full bug report. That (above) is requesting a full bug report on gcc, not Linux kernel. See URL below: > See http://bugzilla.redhat.com/bugzilla/> for instructions. > make[3]: *** [cycx_drv.o] Error 1 > make[3]: Leaving directory `/usr/src/linux-2.4.31/drivers/net/wan' > make[2]: *** [_modsubdir_wan] Error 2 > make[2]: Leaving directory `/usr/src/linux-2.4.31/drivers/net' > make[1]: *** [_modsubdir_net] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4.31/drivers' > make: *** [_mod_drivers] Error 2 > [EMAIL PROTECTED] linux-2.4.31]# In file included from > /usr/src/linux-2.4.31/include/linux/vmalloc.h:5, > from /usr/src/linux-2.4.31/include/asm/io.h:47, > from cycx_drv.c:60: > /usr/src/linux-2.4.31/include/linux/mm.h:155: parse error at end of input > /usr/src/linux-2.4.31/include/linux/mm.h:155: warning: no semicolon at > end of struct or union > > > [3.] Keywords (i.e., modules, networking, kernel): > Modules > > [4.] Kernel version (from /proc/version): > > [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/version > Linux version 2.4.20-28.7 ([EMAIL PROTECTED]) (gcc > version 2.96 2731 (Red Hat Linux 7.3 2.96-126)) #1 Thu Dec 18 > 11:18:28 EST 2003 > > [5.] Output of Oops.. message (if applicable) with symbolic information > resolved (see Documentation/oops-tracing.txt) > > [6.] A small shell script or example program which triggers the > problem (if possible) > Presently running RedHat 7.3 with kernel-athlon-2.4.20-28.7 from rpm > > cd /usr/src/linux-2.4.31 downloaded today at 6:45 PM MST 8/4/05 > make mrproper > cp /boot/config-2.4.20-28.7 /usr/src/linux-2.4.31/.config > make oldconfig (Took all of the defaults no changes) > make xconfig > make dep > make bzImage > make modules > > > [7.] Environment > ASUS A7M-266, Athlon 1.4GHz, 512M, Nvidia Riva TNT/2, Link-Sys 10/100, > D-Link 1000 Marvell, Promise tx/100 IDE controller. RedHat 7.3 with as > updates as currently available from RedHat, Grrr! > > [7.1.] Software (add the output of the ver_linux script here) > > [EMAIL PROTECTED] linux-2.4.31]$ sh scripts/ver_linux > If some fields are empty or look unusual you may have an old version. > Compare to the current minimal requirements in Documentation/Changes. > > Linux wulff 2.4.20-28.7 #1 Thu Dec 18 11:18:28 EST 2003 i686 unknown > > Gnu C 2.96 > Gnu make 3.79.1 > util-linux 2.11n > mount 2.11n > modutils 2.4.18 > e2fsprogs 1.27 > reiserfsprogs 3.x.0j > quota-tools3.06. > PPP2.4.1 > isdn4k-utils 3.1pre1 > Linux C Library2.2.5 > Dynamic linker (ldd) 2.2.5 > Procps 2.0.7 > Net-tools 1.60 > Console-tools 0.3.3 > Sh-utils 2.0.11 > Modules Loaded sr_mod cmpci soundcore binfmt_misc autofs tulip > ipchains ide-scsi scsi_mod ide-cd cdrom usb-uhci usbcore ext3 jbd > > > [7.2.] Processor information (from /proc/cpuinfo): > > [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/cpuinfo > processor: 0 > vendor_id: AuthenticAMD > cpu family: 6 > model: 4 > model name: AMD Athlon(tm) Processor > stepping: 4 > cpu MHz: 1400.110 > cache size: 256 KB > fdiv_bug: no > hlt_bug: no > f00f_bug: no > coma_bug: no > fpu: yes > fpu_exception: yes > cpuid level: 1 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov > pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow > bogomips: 2791.83 > > [7.3.] Module information (from /proc/modules): > > [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/modules > sr_mod 16216 2 (autoclean) > cmpci 32468 0 (autoclean) > soundcore 6436 4 (autoclean) [cmpci] > binfmt_misc 7204 1 > autofs 11780 0 (autoclean) (unused) > tulip 42272 1 > ipchains 49484 10 > ide-scsi 10816 1 > scsi_mod 107212 2 [sr_mod ide-scsi] > ide-cd 32064 0 > cdrom 31936 0 [sr_mod ide-cd] > usb-uhci 24356 0 (unused) > usbcore73504 1 [usb-uhci] > ext3 65280 2 > jbd47468 2 [ext3] > > [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) > > [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/ioports > -001f : dma1 > 0020-003f : pic1 > 0040-005f : timer > 0060-006f : keyboard > 0070-007f : rtc > 0080-008f : dma page reg > 00a0-00bf : pic2 > 00
[PATCH] Timer Top tweaks
On Fri, 5 Aug 2005 07:15 am, Daniel Petrini wrote: > Hi, > > Here we have some support to have more tests on Dynamic Tick. > We have some functions that exports timers information to a proc entry > (/proc/top_info), in a kernel patch and a script that handles this > info and give some output to analyse. We tried to make it less > intrusive as possible. > > It is based in suggestions from Tony Lindgren. > > It is experimental and should evolve. > > Must be applied after 2.6.13-rc5-dtck-3.patch and 2.6.13-rc5. > > Usage: with kernel compiled with attached patch: "perl timer_top.pl > 5", to have refresh time of 5s. Yes that's very nice. It's probably premature but here's a small patch to your timer_top patch. Cheers, Con --- Index: linux-2.6.13-rc5-ck2/kernel/Makefile === --- linux-2.6.13-rc5-ck2.orig/kernel/Makefile 2005-08-05 13:41:26.0 +1000 +++ linux-2.6.13-rc5-ck2/kernel/Makefile 2005-08-05 13:49:23.0 +1000 @@ -7,7 +7,7 @@ obj-y = sched.o fork.o exec_domain.o sysctl.o capability.o ptrace.o timer.o user.o \ signal.o sys.o kmod.o workqueue.o pid.o \ rcupdate.o intermodule.o extable.o params.o posix-timers.o \ - kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o timer_top.o + kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o obj-$(CONFIG_FUTEX) += futex.o obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o @@ -30,7 +30,7 @@ obj-$(CONFIG_SYSFS) += ksysfs.o obj-$(CONFIG_GENERIC_HARDIRQS) += irq/ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o obj-$(CONFIG_SECCOMP) += seccomp.o -obj-$(CONFIG_NO_IDLE_HZ) += dyn-tick.o +obj-$(CONFIG_NO_IDLE_HZ) += dyn-tick.o timer_top.o ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y) # According to Alan Modra <[EMAIL PROTECTED]>, the -fno-omit-frame-pointer is Index: linux-2.6.13-rc5-ck2/kernel/timer.c === --- linux-2.6.13-rc5-ck2.orig/kernel/timer.c 2005-08-05 13:41:26.0 +1000 +++ linux-2.6.13-rc5-ck2/kernel/timer.c 2005-08-05 13:57:23.0 +1000 @@ -509,7 +509,9 @@ static inline void __run_timers(tvec_bas #ifdef CONFIG_NO_IDLE_HZ extern struct timer_top_info top_info; -extern int account_timer(unsigned int function, struct timer_top_info * top_info); +extern int account_timer(unsigned int function, + struct timer_top_info *top_info); + /* * Find out when the next timer event is due to happen. This * is used on S/390 to stop all activity when a cpus is idle. Index: linux-2.6.13-rc5-ck2/kernel/timer_top.c === --- linux-2.6.13-rc5-ck2.orig/kernel/timer_top.c 2005-08-05 13:41:26.0 +1000 +++ linux-2.6.13-rc5-ck2/kernel/timer_top.c 2005-08-05 13:54:50.0 +1000 @@ -11,7 +11,6 @@ * published by the Free Software Foundation. */ - #include #include #include @@ -20,8 +19,8 @@ static LIST_HEAD(timer_list); struct timer_top_info { unsigned int func_pointer; - unsigned int long counter; - struct list_head list; + unsigned long counter; + struct list_head list; }; struct timer_top_info top_info; @@ -30,37 +29,38 @@ int account_timer(unsigned int function, { struct timer_top_info *top; - list_for_each_entry (top, &timer_list, list) { + list_for_each_entry(top, &timer_list, list) { /* if it is in the list increment its count */ if (top->func_pointer == function) { - top->counter += 1; - return 0; + top->counter++; + goto out; } } - + /* if you are here then it didnt find so inserts in the list */ top = kmalloc(sizeof(struct timer_top_info), GFP_KERNEL); - if (!top) + if (!top) return -ENOMEM; top->func_pointer = function; top->counter = 1; list_add(&top->list, &timer_list); +out: return 0; } EXPORT_SYMBOL(account_timer); struct top_info_poll { - char value[18]; + char value[18]; }; struct top_info_poll top_info_poll_dt; struct proc_dir_entry *top_info_file; static int proc_read_top_info(char *page, char **start, off_t off, -int count, int *eof, void *data) +int count, int *eof, void *data) { char aux[18]; struct timer_top_info *top; @@ -69,21 +69,19 @@ static int proc_read_top_info(char *page sprintf(page, "Function counter - %s\n", info_poll_data->value); - list_for_each_entry (top, &timer_list, list) { + list_for_each_entry(top, &timer_list, list) { sprintf(aux, "%x %lu\n", top->func_pointer, top->counter); strcat(page, aux); } return strlen(page); - -} +} static int init_top_info(void) { top_info_file = create_proc_entry("top_info", 0666, NULL); - if(top_info_file == NULL) { - return -ENOMEM; - } + if (top_info_file == NULL) + return -ENOMEM; strcpy(top_info_poll_dt.value, "Timer Top v0.9.1"); @@ -96,6 +94,3 @@ static int init_top_info(void) module_init(init_top_info); //module_exit(); - - -
Re: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
Andrew Morton wrote: Dmitry Torokhov <[EMAIL PROTECTED]> wrote: On Thursday 04 August 2005 22:09, Frank Peters wrote: I'll use bugzilla to report any problems with 2.6.13-rc6. But since I've included the "usb-handoff" option at boot time, all my problems (except the long dhcp/eth0 connect time) are now gone. Right now I'm using 2.6.13-rc5. I understand the need to pinpoint the kernel version, but the "usb-handoff" option has even corrected some problems that started in linux-2.4.x. For example, my PS/2 mouse now functions normally. It has not worked with this motherboard since some time in the 2.4.x series. Also, my keyboard lights were malfunctioning under X-Window since early 2.6.x, but with the "usb-handoff" option they are working normally now. If I had known about the "usb-handoff" option earlier, this thread probalby would not even have come into existence. As long as "usb-handoff" keeps working, I would consider the issue closed. We really really need to make usb-handoff default. Even if there known boxes that don't like it the blacklist would be rather short, much shorter than a whitelist. Sounds like a fun thing for post-2.6.13. What does usb-handoff do, precisely? I just did a series tests. This is necessary, because the problem was intermittent for me. usb-handoff fixes all of my problems!!! without using usb-handoff, my ps/2 mouse works 1/10 times using usb-handoff, my ps/2 mouse works 10/10 times I consider the problem solved... If Dmitry wants to make usb-handoff the default, he has my support :-). -- Michael Krufky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
On Thursday 04 August 2005 22:54, Andrew Morton wrote: > Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > > On Thursday 04 August 2005 22:09, Frank Peters wrote: > > > I'll use bugzilla to report any problems with 2.6.13-rc6. > > > > > > But since I've included the "usb-handoff" option at boot time, > > > all my problems (except the long dhcp/eth0 connect time) are > > > now gone. Right now I'm using 2.6.13-rc5. > > > > > > I understand the need to pinpoint the kernel version, but the > > > "usb-handoff" option has even corrected some problems that > > > started in linux-2.4.x. For example, my PS/2 mouse now functions > > > normally. It has not worked with this motherboard since some time > > > in the 2.4.x series. Also, my keyboard lights were malfunctioning > > > under X-Window since early 2.6.x, but with the "usb-handoff" option > > > they are working normally now. > > > > > > If I had known about the "usb-handoff" option earlier, this thread > > > probalby would not even have come into existence. As long as > > > "usb-handoff" > > > keeps working, I would consider the issue closed. > > > > > > > We really really need to make usb-handoff default. Even if there known boxes > > that don't like it the blacklist would be rather short, much shorter than > > a whitelist. > > Sounds like a fun thing for post-2.6.13. > > What does usb-handoff do, precisely? > It requests BIOS to hand off control of USB which disables USB legacy emulation and all troubles associated with it. We could start with -mm... -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > On Thursday 04 August 2005 22:09, Frank Peters wrote: > > I'll use bugzilla to report any problems with 2.6.13-rc6. > > > > But since I've included the "usb-handoff" option at boot time, > > all my problems (except the long dhcp/eth0 connect time) are > > now gone. Right now I'm using 2.6.13-rc5. > > > > I understand the need to pinpoint the kernel version, but the > > "usb-handoff" option has even corrected some problems that > > started in linux-2.4.x. For example, my PS/2 mouse now functions > > normally. It has not worked with this motherboard since some time > > in the 2.4.x series. Also, my keyboard lights were malfunctioning > > under X-Window since early 2.6.x, but with the "usb-handoff" option > > they are working normally now. > > > > If I had known about the "usb-handoff" option earlier, this thread > > probalby would not even have come into existence. As long as "usb-handoff" > > keeps working, I would consider the issue closed. > > > > We really really need to make usb-handoff default. Even if there known boxes > that don't like it the blacklist would be rather short, much shorter than > a whitelist. Sounds like a fun thing for post-2.6.13. What does usb-handoff do, precisely? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: mthca and LinuxBIOS
Hmm, that output all looks fine. Can you run with the patch below to see exactly where the QP table initialization fails? (I haven't actually compiled this patch so you may have to fix a typo or two) I'm guessing that the CONF_SPECIAL_QP command is failing, but let's make sure. Thanks, Roland diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c b/drivers/infiniband/hw/mthca/mthca_qp.c --- a/drivers/infiniband/hw/mthca/mthca_qp.c +++ b/drivers/infiniband/hw/mthca/mthca_qp.c @@ -2214,13 +2214,16 @@ int __devinit mthca_init_qp_table(struct (1 << 24) - 1, dev->qp_table.sqp_start + MTHCA_MAX_PORTS * 2); - if (err) + if (err) { + mthca_err(dev, "mthca_init_qp_table: mthca_alloc_init failed (%d)\n", err); return err; + } err = mthca_array_init(&dev->qp_table.qp, dev->limits.num_qps); if (err) { mthca_alloc_cleanup(&dev->qp_table.alloc); + mthca_err(dev, "mthca_init_qp_table: mthca_array_init failed (%d)\n", err); return err; } @@ -2228,8 +2231,10 @@ int __devinit mthca_init_qp_table(struct err = mthca_CONF_SPECIAL_QP(dev, i ? IB_QPT_GSI : IB_QPT_SMI, dev->qp_table.sqp_start + i * 2, &status); - if (err) + if (err) { + mthca_err(dev, "mthca_init_qp_table: mthca_CONF_SPECIAL_QP failed for %d/%d (%d)\n", i, dev->qp_table.sqp_start + i * 2, err); goto err_out; + } if (status) { mthca_warn(dev, "CONF_SPECIAL_QP returned " "status %02x, aborting.\n", - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] dyn-tick3 tweaks respin
On Fri, 2005-08-05 at 13:20 +1000, Con Kolivas wrote: > Like this I assume you meant? > Yeah that looks good. Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Fri, 5 Aug 2005 11:30 am, Paul wrote: > Con Kolivas <[EMAIL PROTECTED]>, on Wed Aug 03, 2005 [03:59:24 PM] said: > > This is the dynamic ticks patch for i386 as written by Tony Lindgen > > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>. > > Patch for 2.6.13-rc5 > Ive been running this all afternoon on a pIIx2 @400mhz desktop > machine, SMP enabled Preempt kernel. > Initially, I tried it using APIC, got X up and tried to play > some music, but mplayer just hung and prompts in other terminals > were super slugish or blocked until I killed mplayer. (there were > no interrupts from the sound card during this time.) Without using > APIC, it seems to work just great. > With my regular desktop running and me not doing much, 'vmstat 5' > shows interrupts at 100-200 per entry. Loading the box completely with > 'make -j4' kernel build their are just over 1000 interrupts. Various other > loads show numbers in between. (eg. it seems to work as one would expect, > presuming the timer interupts dominate...) > Time seems fine. I havent noticed any interactivity problems. > Performance on 'kernbench' was within a percentage point of 2.6.12 > It does not seem to make any difference as far as the heat of the > cpus or mb, though. Thanks for the feedback. As Tony mentioned, it simply allows for better power management to be done rather than saving power on its own. At idle it allows the processor to enter a lower power state for example, which I doubt the pII does. Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] dyn-tick3 tweaks respin
On Fri, 5 Aug 2005 11:39 am, Con Kolivas wrote: > On Fri, 5 Aug 2005 10:53 am, Nick Piggin wrote: > > All else being equal, it is much better if you unlock in the > > same function that takes the lock. For readability. > > > > It looks like you should be able to leave all the flow control > > and locking the same, and use update_monotonic_base() to > > do the actual update? > > Good advice, thanks. Will respin. Like this I assume you meant? Cheers, Con --- Index: linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c === --- linux-2.6.13-rc5-ck2.orig/arch/i386/kernel/timers/timer_tsc.c 2005-08-03 11:29:29.0 +1000 +++ linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c 2005-08-05 13:15:23.0 +1000 @@ -167,10 +167,19 @@ static void delay_tsc(unsigned long loop } while ((now-bclock) < loops); } +/* update the monotonic base value */ +static inline void update_monotonic_base(unsigned long long last_offset) +{ + unsigned long long this_offset; + + this_offset = ((unsigned long long)last_tsc_high << 32) | last_tsc_low; + monotonic_base += cycles_2_ns(this_offset - last_offset); +} + #ifdef CONFIG_HPET_TIMER static void mark_offset_tsc_hpet(void) { - unsigned long long this_offset, last_offset; + unsigned long long last_offset; unsigned long offset, temp, hpet_current; write_seqlock(&monotonic_lock); @@ -198,9 +207,7 @@ static void mark_offset_tsc_hpet(void) } hpet_last = hpet_current; - /* update the monotonic base value */ - this_offset = ((unsigned long long)last_tsc_high<<32)|last_tsc_low; - monotonic_base += cycles_2_ns(this_offset - last_offset); + update_monotonic_base(last_offset); write_sequnlock(&monotonic_lock); /* calculate delay_at_last_interrupt */ @@ -347,7 +354,7 @@ static void mark_offset_tsc(void) int count; int countmp; static int count1 = 0; - unsigned long long this_offset, last_offset; + unsigned long long last_offset; static int lost_count = 0; write_seqlock(&monotonic_lock); @@ -368,8 +375,11 @@ static void mark_offset_tsc(void) rdtsc(last_tsc_low, last_tsc_high); - if (dyn_tick_enabled()) - goto monotonic_base; + if (dyn_tick_enabled()) { + update_monotonic_base(last_offset); + write_sequnlock(&monotonic_lock); + return; + } spin_lock(&i8253_lock); outb_p(0x00, PIT_MODE); /* latch the count ASAP */ @@ -439,16 +449,9 @@ static void mark_offset_tsc(void) } else lost_count = 0; - monotonic_base: - - /* update the monotonic base value */ - this_offset = ((unsigned long long)last_tsc_high<<32)|last_tsc_low; - monotonic_base += cycles_2_ns(this_offset - last_offset); + update_monotonic_base(last_offset); write_sequnlock(&monotonic_lock); - if (dyn_tick_enabled()) - return; - /* calculate delay_at_last_interrupt */ count = ((LATCH-1) - count) * TICK_SIZE; delay_at_last_interrupt = (count + LATCH/2) / LATCH;
Re: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
On Thursday 04 August 2005 22:09, Frank Peters wrote: > I'll use bugzilla to report any problems with 2.6.13-rc6. > > But since I've included the "usb-handoff" option at boot time, > all my problems (except the long dhcp/eth0 connect time) are > now gone. Right now I'm using 2.6.13-rc5. > > I understand the need to pinpoint the kernel version, but the > "usb-handoff" option has even corrected some problems that > started in linux-2.4.x. For example, my PS/2 mouse now functions > normally. It has not worked with this motherboard since some time > in the 2.4.x series. Also, my keyboard lights were malfunctioning > under X-Window since early 2.6.x, but with the "usb-handoff" option > they are working normally now. > > If I had known about the "usb-handoff" option earlier, this thread > probalby would not even have come into existence. As long as "usb-handoff" > keeps working, I would consider the issue closed. > We really really need to make usb-handoff default. Even if there known boxes that don't like it the blacklist would be rather short, much shorter than a whitelist. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
I'll use bugzilla to report any problems with 2.6.13-rc6. But since I've included the "usb-handoff" option at boot time, all my problems (except the long dhcp/eth0 connect time) are now gone. Right now I'm using 2.6.13-rc5. I understand the need to pinpoint the kernel version, but the "usb-handoff" option has even corrected some problems that started in linux-2.4.x. For example, my PS/2 mouse now functions normally. It has not worked with this motherboard since some time in the 2.4.x series. Also, my keyboard lights were malfunctioning under X-Window since early 2.6.x, but with the "usb-handoff" option they are working normally now. If I had known about the "usb-handoff" option earlier, this thread probalby would not even have come into existence. As long as "usb-handoff" keeps working, I would consider the issue closed. Frank Peters On Thu, 4 Aug 2005 16:28:12 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > Frank, if any problems remain in 2.6.13-rc6 could you please raise new > bugzilla.kernel.org records for them? That way poor old me will be able to > keep tabs on progress more easily. > > (It's especially important to identify the most recent kernel version which > didn't have a particular bug) > > Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
make modules Segfault
To: linux-kernel@vger.kernel.org [1.] One line summary of the problem: make modules failed Segfault (program cpp0) [2.] Full description of the problem/report: gcc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See http://bugzilla.redhat.com/bugzilla/> for instructions. make[3]: *** [cycx_drv.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.31/drivers/net/wan' make[2]: *** [_modsubdir_wan] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.31/drivers/net' make[1]: *** [_modsubdir_net] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.31/drivers' make: *** [_mod_drivers] Error 2 [EMAIL PROTECTED] linux-2.4.31]# In file included from /usr/src/linux-2.4.31/include/linux/vmalloc.h:5, from /usr/src/linux-2.4.31/include/asm/io.h:47, from cycx_drv.c:60: /usr/src/linux-2.4.31/include/linux/mm.h:155: parse error at end of input /usr/src/linux-2.4.31/include/linux/mm.h:155: warning: no semicolon at end of struct or union [3.] Keywords (i.e., modules, networking, kernel): Modules [4.] Kernel version (from /proc/version): [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/version Linux version 2.4.20-28.7 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-126)) #1 Thu Dec 18 11:18:28 EST 2003 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) [6.] A small shell script or example program which triggers the problem (if possible) Presently running RedHat 7.3 with kernel-athlon-2.4.20-28.7 from rpm cd /usr/src/linux-2.4.31 downloaded today at 6:45 PM MST 8/4/05 make mrproper cp /boot/config-2.4.20-28.7 /usr/src/linux-2.4.31/.config make oldconfig (Took all of the defaults no changes) make xconfig make dep make bzImage make modules [7.] Environment ASUS A7M-266, Athlon 1.4GHz, 512M, Nvidia Riva TNT/2, Link-Sys 10/100, D-Link 1000 Marvell, Promise tx/100 IDE controller. RedHat 7.3 with as updates as currently available from RedHat, Grrr! [7.1.] Software (add the output of the ver_linux script here) [EMAIL PROTECTED] linux-2.4.31]$ sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux wulff 2.4.20-28.7 #1 Thu Dec 18 11:18:28 EST 2003 i686 unknown Gnu C 2.96 Gnu make 3.79.1 util-linux 2.11n mount 2.11n modutils 2.4.18 e2fsprogs 1.27 reiserfsprogs 3.x.0j quota-tools3.06. PPP2.4.1 isdn4k-utils 3.1pre1 Linux C Library2.2.5 Dynamic linker (ldd) 2.2.5 Procps 2.0.7 Net-tools 1.60 Console-tools 0.3.3 Sh-utils 2.0.11 Modules Loaded sr_mod cmpci soundcore binfmt_misc autofs tulip ipchains ide-scsi scsi_mod ide-cd cdrom usb-uhci usbcore ext3 jbd [7.2.] Processor information (from /proc/cpuinfo): [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/cpuinfo processor: 0 vendor_id: AuthenticAMD cpu family: 6 model: 4 model name: AMD Athlon(tm) Processor stepping: 4 cpu MHz: 1400.110 cache size: 256 KB fdiv_bug: no hlt_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 1 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 2791.83 [7.3.] Module information (from /proc/modules): [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/modules sr_mod 16216 2 (autoclean) cmpci 32468 0 (autoclean) soundcore 6436 4 (autoclean) [cmpci] binfmt_misc 7204 1 autofs 11780 0 (autoclean) (unused) tulip 42272 1 ipchains 49484 10 ide-scsi 10816 1 scsi_mod 107212 2 [sr_mod ide-scsi] ide-cd 32064 0 cdrom 31936 0 [sr_mod ide-cd] usb-uhci 24356 0 (unused) usbcore73504 1 [usb-uhci] ext3 65280 2 jbd47468 2 [ext3] [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(auto) 0330-0331 : cmpci Midi 0376-0376 : ide1 0388-038b : cmpci FM 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 8000-80ff : Linksys Network Everywhere Fast Ethernet 10/100 model NC100 8000-80ff : tulip 8400-84ff : PCI device 1186:4c00 (D-Link System Inc) 8800-880f : Promise Technology, Inc. 20268 8800-8807 : ide
Re: File corruption on LVM2 on top of software RAID1
Andrew Morton <[EMAIL PROTECTED]> wrote: > > There's one fix against 2.6.12.3 which is needed, but 2.6.9 didn't have the > bug which this fix addresses. aargh, I see that it did fix it. Don't blame me. Blame people who screw up list threading by reading a mail->news gateway and hitting "reply". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: File corruption on LVM2 on top of software RAID1
"Simon Matter" <[EMAIL PROTECTED]> wrote: > > Hi, > > Please CC me as I'm not subscribed to the kernel list. > > I had a hard time identifying a serious problem in the 2.6 linux kernel. Yes, it is a serious problem. > It all started while evaluating RHEL4 for new servers. My data integrity > tests gave me bad results - which I couldn't believe - and my first idea > was - of course - bad hardware. I ordered new SCSI disks instead of the > IDE disks, took another server, spent some money again, tried again and > again. That's all long ago now... > > In my tests I get corrupt files on LVM2 which is on top of software raid1. > (This is a common setup even mentioned in the software RAID HOWTO and has > worked for me on RedHat 9 / kernel 2.4 for a long time now and it's my > favourite configuration). Now, I tested two different distributions, three > kernels, three different filesystems and three different hardware. I can > always reproduce it with the following easy scripts: > > LOGF=/root/diff.log > while true; do > rm -rf /home/XXX2 > rsync -a /home/XXX/ /home/XXX2 > date >> $LOGF > diff -r /home/XXX /home/XXX2 >> $LOGF > done > > the files in /home/XXX are ~15G of ISO images and rpms. > > diff.log looks like this: > Wed Aug 3 13:45:57 CEST 2005 > Binary files /home/XXX/ES3-U3/rhel-3-U3-i386-es-disc3.iso and > /home/XXX2/ES3-U3/rhel-3-U3-i386-es-disc3.iso differ > Wed Aug 3 14:09:14 CEST 2005 > Binary files /home/XXX/8.0/psyche-i386-disc1.iso and > /home/XXX2/8.0/psyche-i386-disc1.iso differ > Wed Aug 3 14:44:17 CEST 2005 > Binary files /home/XXX/7.3/valhalla-i386-disc3.iso and > /home/XXX2/7.3/valhalla-i386-disc3.iso differ > Wed Aug 3 15:15:05 CEST 2005 > Wed Aug 3 15:45:40 CEST 2005 > > > Tested software: > 1) RedHat EL4 > kernel-2.6.9-11.EL > vanilla 2.6.12.3 kernel > filesystems: EXT2, EXT3, XFS > > 2) NOVELL/SUSE 9.3 > kernel-default-2.6.11.4-21.7 > filesystem: EXT3 > > Tested Hardware: > 1) > - ASUS P2B-S board > - CPU PIII 450MHz > - Intel 440BX/ZX/DX Chipset > - 4x128M memory (ECC enabled) > - 2x IDE disks Seagate Barracuda 400G, connected to onboard "Intel PIIX4 > Ultra 33" > - Promise Ultra100TX2 adapter for additional tests > > 2) > - DELL PowerEdge 1400 > - CPU PIII 800MHz > - ServerWorks OSB4 Chipset > - 4x256M memory (ECC enabled) > - 2x U320 SCSI disks Maxtor Atlas 10K 146G > - onboard Adaptec aic7899 Ultra160 SCSI adapter > > 3) > - DELL PowerEdge 1850 > - CPU P4 XEON 2.8GHz > - 2G memory > - 2x U320 SCSI disks Maxtor Atlas 10K 73G SCA > - onboard LSI53C1030 SCSI adapter > > I've put some files toghether from the last test on the PE1850 server: > http://www.invoca.ch/bugs/linux-2.6-corruption-on-lvm2-on-raid1/ > > I've also filed a bug with RedHat: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164696 > > I have spent a lot of time on this bug because I consider it very serious. > I'm not a kernel hacker but if there is anything I can do to fix this, let > me know. > Thanks for doing that. There's one fix against 2.6.12.3 which is needed, but 2.6.9 didn't have the bug which this fix addresses. So unless 2.6.9 has a different problem, this won't help. But still, you should include this in testing please. diff -puN fs/bio.c~bio_clone-fix fs/bio.c --- devel/fs/bio.c~bio_clone-fix2005-07-28 00:39:40.0 -0700 +++ devel-akpm/fs/bio.c 2005-07-28 01:02:34.0 -0700 @@ -261,6 +261,7 @@ inline void __bio_clone(struct bio *bio, */ bio->bi_vcnt = bio_src->bi_vcnt; bio->bi_size = bio_src->bi_size; + bio->bi_idx = bio_src->bi_idx; bio_phys_segments(q, bio); bio_hw_segments(q, bio); } _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] relayfs: update Documentation
This patch updates the relayfs documentation to reflect the latest API changes, and generally cleans up and adds much-needed clarification to many areas - many thanks to Bert Hubert for that. Andrew, please apply. Thanks, Tom Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]> diff -urpN -X dontdiff linux-2.6.13-rc4-mm1/Documentation/filesystems/relayfs.txt linux-2.6.13-rc4-mm1-cur/Documentation/filesystems/relayfs.txt --- linux-2.6.13-rc4-mm1/Documentation/filesystems/relayfs.txt 2005-08-05 10:14:33.0 -0500 +++ linux-2.6.13-rc4-mm1-cur/Documentation/filesystems/relayfs.txt 2005-08-05 15:47:10.0 -0500 @@ -23,6 +23,51 @@ This document provides an overview of th the function parameters are documented along with the functions in the filesystem code - please see that for details. +Semantics += + +Each relayfs channel has one buffer per CPU, each buffer has one or +more sub-buffers. Messages are written to the first sub-buffer until +it is too full to contain a new message, in which case it it is +written to the next (if available). Messages are never split across +sub-buffers. At this point, userspace can be notified so it empties +the first sub-buffer, while the kernel continues writing to the next. + +When notified that a sub-buffer is full, the kernel knows how many +bytes of it are padding i.e. unused. Userspace can use this knowledge +to copy only valid data. + +After copying it, userspace can notify the kernel that a sub-buffer +has been consumed. + +relayfs can operate in a mode where it will overwrite data not yet +collected by userspace, and not wait for it to consume it. + +relayfs itself does not provide for communication of such data between +userspace and kernel, allowing the kernel side to remain simple and not +impose a single interface on userspace. It does provide a separate +helper though, described below. + +klog, relay-app & librelay +== + +relayfs itself is ready to use, but to make things easier, two +additional systems are provided. klog is a simple wrapper to make +writing formatted text or raw data to a channel simpler, regardless of +whether a channel to write into exists or not, or whether relayfs is +compiled into the kernel or is configured as a module. relay-app is +the kernel counterpart of userspace librelay.c, combined these two +files provide glue to easily stream data to disk, without having to +bother with housekeeping. klog and relay-app can be used together, +with klog providing high-level logging functions to the kernel and +relay-app taking care of kernel-user control and disk-logging chores. + +It is possible to use relayfs without relay-app & librelay, but you'll +have to implement communication between userspace and kernel, allowing +both to convey the state of buffers (full, empty, amount of padding). + +klog, relay-app and librelay can be found in the relay-apps tarball on +http://relayfs.sourceforge.net The relayfs user space API == @@ -34,7 +79,13 @@ available and some comments regarding th open() enables user to open an _existing_ buffer. mmap() results in channel buffer being mapped into the caller's -memory space. +memory space. Note that you can't do a partial mmap - you must +map the entire file, which is NRBUF * SUBBUFSIZE. + +read() read the contents of a channel buffer. If there are active +channel writers, results may be unpredictable - users should +make sure that all logging to the channel has ended before +using read(). poll() POLLIN/POLLRDNORM/POLLERR supported. User applications are notified when sub-buffer boundaries are crossed. @@ -63,13 +114,15 @@ Here's a summary of the API relayfs prov channel management functions: relay_open(base_filename, parent, subbuf_size, n_subbufs, - overwrite, callbacks) + callbacks) relay_close(chan) relay_flush(chan) relay_reset(chan) relayfs_create_dir(name, parent) relayfs_remove_dir(dentry) -relay_commit(buf, reserved, count) + + channel management typically called on instigation of userspace: + relay_subbufs_consumed(chan, cpu, subbufs_consumed) write functions: @@ -80,16 +133,18 @@ Here's a summary of the API relayfs prov callbacks: -subbuf_start(buf, subbuf, prev_subbuf_idx, prev_subbuf) -deliver(buf, subbuf_idx, subbuf) +subbuf_start(buf, subbuf, prev_subbuf, prev_padding) buf_mapped(buf, filp) buf_unmapped(buf, filp) -buf_full(buf, subbuf_idx) + helper functions: + +relay_buf_full(buf) +subbuf_start_reserve(buf, length) -A relayfs channel is made of up one or more per-cpu channel buffers, -each implemented as a circular buffer subdivided into one or more -sub-buffers. + +Creating a channel +-- relay_open() is used to create a channel, along with its per-cpu channel buffers. Each channel buffer will have
[-mm patch] relayfs: add read() support
At the kernel summit, there was some discussion of relayfs and the consensus was that it didn't make sense for relayfs to not implement read(). So here's a read implementation... Andrew, please apply. Tom Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]> diff -urpN -X dontdiff linux-2.6.13-rc4-mm1/fs/relayfs/inode.c linux-2.6.13-rc4-mm1-cur/fs/relayfs/inode.c --- linux-2.6.13-rc4-mm1/fs/relayfs/inode.c 2005-08-05 10:14:34.0 -0500 +++ linux-2.6.13-rc4-mm1-cur/fs/relayfs/inode.c 2005-08-05 10:17:47.0 -0500 @@ -232,7 +232,7 @@ int relayfs_remove_dir(struct dentry *de * * Increments the channel buffer refcount. */ -int relayfs_open(struct inode *inode, struct file *filp) +static int relayfs_open(struct inode *inode, struct file *filp) { struct rchan_buf *buf = RELAYFS_I(inode)->buf; kref_get(&buf->kref); @@ -247,7 +247,7 @@ int relayfs_open(struct inode *inode, st * * Calls upon relay_mmap_buf to map the file into user space. */ -int relayfs_mmap(struct file *filp, struct vm_area_struct *vma) +static int relayfs_mmap(struct file *filp, struct vm_area_struct *vma) { struct inode *inode = filp->f_dentry->d_inode; return relay_mmap_buf(RELAYFS_I(inode)->buf, vma); @@ -260,7 +260,7 @@ int relayfs_mmap(struct file *filp, stru * * Poll implemention. */ -unsigned int relayfs_poll(struct file *filp, poll_table *wait) +static unsigned int relayfs_poll(struct file *filp, poll_table *wait) { unsigned int mask = 0; struct inode *inode = filp->f_dentry->d_inode; @@ -286,7 +286,7 @@ unsigned int relayfs_poll(struct file *f * Decrements the channel refcount, as the filesystem is * no longer using it. */ -int relayfs_release(struct inode *inode, struct file *filp) +static int relayfs_release(struct inode *inode, struct file *filp) { struct rchan_buf *buf = RELAYFS_I(inode)->buf; kref_put(&buf->kref, relay_remove_buf); @@ -295,6 +295,157 @@ int relayfs_release(struct inode *inode, } /** + * relayfs_read_start - find the first available byte to read + * + * If the read_pos is in the middle of padding, return the + * position of the first actually available byte, otherwise + * return the original value. + */ +static inline unsigned int relayfs_read_start(unsigned int read_pos, + unsigned int avail, + unsigned int start_subbuf, + struct rchan_buf *buf) +{ + unsigned int read_subbuf, adj_read_subbuf; + unsigned int padding, padding_start, padding_end; + unsigned int subbuf_size = buf->chan->subbuf_size; + unsigned int n_subbufs = buf->chan->n_subbufs; + + read_subbuf = read_pos / subbuf_size; + adj_read_subbuf = (read_subbuf + start_subbuf) % n_subbufs; + + if ((read_subbuf + 1) * subbuf_size <= avail) { + padding = buf->padding[adj_read_subbuf]; + padding_start = (read_subbuf + 1) * subbuf_size - padding; + padding_end = (read_subbuf + 1) * subbuf_size; + if (read_pos >= padding_start && read_pos < padding_end) { + read_subbuf = (read_subbuf + 1) % n_subbufs; + read_pos = read_subbuf * subbuf_size; + } + } + + return read_pos; +} + +/** + * relayfs_read_end - return the end of available bytes to read + * + * If the read_pos is in the middle of a full sub-buffer, return + * the padding-adjusted end of that sub-buffer, otherwise return + * the position after the last byte written to the buffer. At + * most, 1 sub-buffer can be read at a time. + * + */ +static inline unsigned int relayfs_read_end(unsigned int read_pos, + unsigned int avail, + unsigned int start_subbuf, + struct rchan_buf *buf) +{ + unsigned int padding, read_endpos, buf_offset; + unsigned int read_subbuf, adj_read_subbuf; + unsigned int subbuf_size = buf->chan->subbuf_size; + unsigned int n_subbufs = buf->chan->n_subbufs; + + buf_offset = buf->offset > subbuf_size ? subbuf_size : buf->offset; + read_subbuf = read_pos / subbuf_size; + adj_read_subbuf = (read_subbuf + start_subbuf) % n_subbufs; + + if ((read_subbuf + 1) * subbuf_size <= avail) { + padding = buf->padding[adj_read_subbuf]; + read_endpos = (read_subbuf + 1) * subbuf_size - padding; + } else + read_endpos = read_subbuf * subbuf_size + buf_offset; + + return read_endpos; +} + +/** + * relayfs_read_avail - return total available along with buffer start + * + * Because buffers are circular, the 'beginning' of the buffer + * depends on where the buffer was last written. If the writer +
[-mm patch] relayfs: API cleanup
This patch does a bit of cleanup of the relayfs API, as discussed previously: http://marc.theaimsgroup.com/?l=linux-kernel&m=112134773617086&w=2 To recap, it: - removes the commit counts, relay_commit() and the deliver() callback (the padding counts had to stay, for the read() implementation) - removes the buffer_full() callback - changes the subbuf_start() callback - changes 'unsigned' to 'unsigned int' - other similar and related changes The examples have been updated to use the new API (there's also a new example that does commit/deliver in the client): http://prdownloads.sourceforge.net/relayfs/relay-apps-0.7.tar.gz?download Andrew, please apply. Thanks, Tom Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]> diff -urpN -X dontdiff linux-2.6.13-rc4-mm1/fs/relayfs/buffers.c linux-2.6.13-rc4-mm1-cur/fs/relayfs/buffers.c --- linux-2.6.13-rc4-mm1/fs/relayfs/buffers.c 2005-08-05 10:14:34.0 -0500 +++ linux-2.6.13-rc4-mm1-cur/fs/relayfs/buffers.c 2005-08-05 10:17:30.0 -0500 @@ -95,7 +95,7 @@ int relay_mmap_buf(struct rchan_buf *buf static void *relay_alloc_buf(struct rchan_buf *buf, unsigned long size) { void *mem; - int i, j, n_pages; + unsigned int i, j, n_pages; size = PAGE_ALIGN(size); n_pages = size >> PAGE_SHIFT; @@ -141,20 +141,15 @@ struct rchan_buf *relay_create_buf(struc if (!buf->padding) goto free_buf; - buf->commit = kmalloc(chan->n_subbufs * sizeof(unsigned *), GFP_KERNEL); - if (!buf->commit) - goto free_buf; - buf->start = relay_alloc_buf(buf, chan->alloc_size); if (!buf->start) goto free_buf; - + buf->chan = chan; kref_get(&buf->chan->kref); return buf; free_buf: - kfree(buf->commit); kfree(buf->padding); kfree(buf); return NULL; @@ -167,7 +162,7 @@ free_buf: void relay_destroy_buf(struct rchan_buf *buf) { struct rchan *chan = buf->chan; - int i; + unsigned int i; if (likely(buf->start)) { vunmap(buf->start); @@ -176,7 +171,6 @@ void relay_destroy_buf(struct rchan_buf kfree(buf->page_array); } kfree(buf->padding); - kfree(buf->commit); kfree(buf); kref_put(&chan->kref, relay_destroy_channel); } diff -urpN -X dontdiff linux-2.6.13-rc4-mm1/fs/relayfs/relay.c linux-2.6.13-rc4-mm1-cur/fs/relayfs/relay.c --- linux-2.6.13-rc4-mm1/fs/relayfs/relay.c 2005-08-05 10:14:34.0 -0500 +++ linux-2.6.13-rc4-mm1-cur/fs/relayfs/relay.c 2005-08-05 10:17:30.0 -0500 @@ -26,10 +26,7 @@ */ int relay_buf_empty(struct rchan_buf *buf) { - int produced = atomic_read(&buf->subbufs_produced); - int consumed = atomic_read(&buf->subbufs_consumed); - - return (produced - consumed) ? 0 : 1; + return (buf->subbufs_produced - buf->subbufs_consumed) ? 0 : 1; } /** @@ -38,17 +35,10 @@ int relay_buf_empty(struct rchan_buf *bu * * Returns 1 if the buffer is full, 0 otherwise. */ -static inline int relay_buf_full(struct rchan_buf *buf) +int relay_buf_full(struct rchan_buf *buf) { - int produced, consumed; - - if (buf->chan->overwrite) - return 0; - - produced = atomic_read(&buf->subbufs_produced); - consumed = atomic_read(&buf->subbufs_consumed); - - return (produced - consumed > buf->chan->n_subbufs - 1) ? 1 : 0; + unsigned int ready = buf->subbufs_produced - buf->subbufs_consumed; + return (ready >= buf->chan->n_subbufs) ? 1 : 0; } /* @@ -65,19 +55,10 @@ static inline int relay_buf_full(struct */ static int subbuf_start_default_callback (struct rchan_buf *buf, void *subbuf, - unsigned prev_subbuf_idx, - void *prev_subbuf) -{ - return 0; -} - -/* - * deliver() default callback. Does nothing. - */ -static void deliver_default_callback (struct rchan_buf *buf, - unsigned subbuf_idx, - void *subbuf) + void *prev_subbuf, + unsigned int prev_padding) { + return 1; } /* @@ -96,22 +77,11 @@ static void buf_unmapped_default_callbac { } -/* - * buf_full() default callback. Does nothing. - */ -static void buf_full_default_callback(struct rchan_buf *buf, - unsigned subbuf_idx, - void *subbuf) -{ -} - /* relay channel default callbacks */ static struct rchan_callbacks default_channel_callbacks = { .subbuf_start = subbuf_start_default_callback, - .deliver = deliver_default_callback, .buf_mapped = buf_mapped_default_callback, .buf_unmapped = buf_unmapped_default_callback, - .buf_full = buf_full_default
Re: [PATCH] dyn-tick3 tweaks
On Fri, 5 Aug 2005 10:53 am, Nick Piggin wrote: > Con Kolivas wrote: > > Something like this on top is cleaner and quieter. I'll add this to > > pending changes for another version. > > > > > > > > > > Index: linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c > > === > > --- > > linux-2.6.13-rc5-ck2.orig/arch/i386/kernel/timers/timer_tsc.c > > 2005-08-03 > > 11:29:29.0 +1000 +++ > > linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c2005-08-05 > > 10:22:25.0 +1000 @@ -167,10 +167,20 @@ static void > > delay_tsc(unsigned long loop > > } while ((now-bclock) < loops); > > } > > > > +/* update the monotonic base value */ > > +static inline void update_monotonic_base(unsigned long long last_offset) > > +{ > > + unsigned long long this_offset; > > + > > + this_offset = ((unsigned long long)last_tsc_high << 32) | last_tsc_low; > > + monotonic_base += cycles_2_ns(this_offset - last_offset); > > + write_sequnlock(&monotonic_lock); > > +} > > + > > All else being equal, it is much better if you unlock in the > same function that takes the lock. For readability. > > It looks like you should be able to leave all the flow control > and locking the same, and use update_monotonic_base() to > do the actual update? Good advice, thanks. Will respin. Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Speedup FAT filesystem directory reads
Karsten Wiese <[EMAIL PROTECTED]> writes: > Looks better, is smaller and works equally well here, thanks. > I had to hand apply it though as it was slightly scrambled > (by my mail client?) so patch couldn't handle it. > Please send patches as attachment. We like a plain text, not attachment, see Documentation/SubmittingPatches. Anyway, thanks for nice work. -- OGAWA Hirofumi <[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] i386 No-Idle-Hz aka Dynamic-Ticks 3
Con Kolivas <[EMAIL PROTECTED]>, on Wed Aug 03, 2005 [03:59:24 PM] said: > This is the dynamic ticks patch for i386 as written by Tony Lindgen > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>. > Patch for 2.6.13-rc5 > > There were a couple of things that I wanted to change so here is an updated > version. This code should have stabilised enough for general testing now. > > The sysfs interface was moved to its own directory > in /sys/devices/system/dyn_tick and split into separate files to > enable/disable dynamic ticks and usage of apic on the fly. It makes sense to > enable dynamic ticks and usage of apic by default if they're actually built > into the kernel so that is now done. > > Cheers, > Con Hi; Ive been running this all afternoon on a pIIx2 @400mhz desktop machine, SMP enabled Preempt kernel. Initially, I tried it using APIC, got X up and tried to play some music, but mplayer just hung and prompts in other terminals were super slugish or blocked until I killed mplayer. (there were no interrupts from the sound card during this time.) Without using APIC, it seems to work just great. With my regular desktop running and me not doing much, 'vmstat 5' shows interrupts at 100-200 per entry. Loading the box completely with 'make -j4' kernel build their are just over 1000 interrupts. Various other loads show numbers in between. (eg. it seems to work as one would expect, presuming the timer interupts dominate...) Time seems fine. I havent noticed any interactivity problems. Performance on 'kernbench' was within a percentage point of 2.6.12 It does not seem to make any difference as far as the heat of the cpus or mb, though. Hope this datapoint is useful; Paul [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/
[patch 3/5] USB: ub documentation update
From: Pete Zaitcev <[EMAIL PROTECTED]> The patch which went in was correct, but not quite what I had in mind. Here is a patch to update that a little bit. Original patch is at: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4749f32da939d4e4160541b2cadc22492bb507ec Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- Documentation/usb/usbmon.txt |2 +- drivers/usb/mon/Kconfig |9 - drivers/usb/mon/Makefile |1 + 3 files changed, 6 insertions(+), 6 deletions(-) --- gregkh-2.6.orig/Documentation/usb/usbmon.txt2005-08-04 17:37:11.0 -0700 +++ gregkh-2.6/Documentation/usb/usbmon.txt 2005-08-04 17:40:06.0 -0700 @@ -102,7 +102,7 @@ - URB Status. This field makes no sense for submissions, but is present to help scripts with parsing. In error case, it contains the error code. In case of a setup packet, it contains a Setup Tag. If scripts read a number - in this field, the proceed to read Data Length. Otherwise, they read + in this field, they proceed to read Data Length. Otherwise, they read the setup packet before reading the Data Length. - Setup packet, if present, consists of 5 words: one of each for bmRequestType, bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0. --- gregkh-2.6.orig/drivers/usb/mon/Kconfig 2005-08-04 17:37:11.0 -0700 +++ gregkh-2.6/drivers/usb/mon/Kconfig 2005-08-04 17:40:06.0 -0700 @@ -9,9 +9,8 @@ help If you say Y here, a component which captures the USB traffic between peripheral-specific drivers and HC drivers will be built. - The USB_MON is similar in spirit and may be compatible with Dave - Harding's USBMon. + For more information, see . - This is somewhat experimental at this time, but it should be safe, - as long as you aren't using modular USB and try to remove this - module. + This is somewhat experimental at this time, but it should be safe. + + If unsure, say Y. --- gregkh-2.6.orig/drivers/usb/mon/Makefile2005-08-04 17:37:11.0 -0700 +++ gregkh-2.6/drivers/usb/mon/Makefile 2005-08-04 17:40:06.0 -0700 @@ -4,4 +4,5 @@ usbmon-objs:= mon_main.o mon_stat.o mon_text.o +# This does not use CONFIG_USB_MON because we want this to use a tristate. obj-$(CONFIG_USB) += usbmon.o -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/5] USB: Fix setup packet initialization in isp116x-hcd
From: Olav Kongas <[EMAIL PROTECTED]> When recently addressing remarks by Alexey Dobriyan about the isp116x-hcd, I introduced a bug in the driver. Please apply the attached patch to fix it. Signed-off-by: Olav Kongas <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/usb/host/isp116x-hcd.c |4 +++- 1 files changed, 3 insertions(+), 1 deletion(-) --- gregkh-2.6.orig/drivers/usb/host/isp116x-hcd.c 2005-08-04 17:37:11.0 -0700 +++ gregkh-2.6/drivers/usb/host/isp116x-hcd.c 2005-08-04 17:40:10.0 -0700 @@ -229,9 +229,11 @@ struct isp116x_ep *ep; struct urb *urb; struct ptd *ptd; - u16 toggle = 0, dir = PTD_DIR_SETUP, len; + u16 len; for (ep = isp116x->atl_active; ep; ep = ep->active) { + u16 toggle = 0, dir = PTD_DIR_SETUP; + BUG_ON(list_empty(&ep->hep->urb_list)); urb = container_of(ep->hep->urb_list.next, struct urb, urb_list); -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/5] USB: ehci: microframe handling fix
From: David Brownell <[EMAIL PROTECTED]> This patch has a one line oops fix, plus related cleanups. - The bugfix uses microframe scheduling data given to the hardware to test "is this a periodic QH", rather than testing for nonzero period. (Prevents an oops by providing the correct answer.) - The cleanup going along with the patch should make it clearer what's going on whenever those bitfields are accessed. The bug came about when, around January, two new kinds of EHCI interrupt scheduling operation were added, involving both the high speed (24 KBytes per millisec) and low/full speed (1-64 bytes per millisec) microframe scheduling. A driver for the Edirol UA-1000 Audio Capture Unit ran into the oops; it used one of the newly supported high speed modes. Signed-off-by: David Brownell <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/usb/host/ehci-dbg.c |2 +- drivers/usb/host/ehci-q.c |5 +++-- drivers/usb/host/ehci-sched.c | 13 +++-- drivers/usb/host/ehci.h |5 + 4 files changed, 16 insertions(+), 9 deletions(-) --- gregkh-2.6.orig/drivers/usb/host/ehci-dbg.c 2005-08-04 17:37:11.0 -0700 +++ gregkh-2.6/drivers/usb/host/ehci-dbg.c 2005-08-04 17:40:08.0 -0700 @@ -527,7 +527,7 @@ p.qh->period, le32_to_cpup (&p.qh->hw_info2) /* uframe masks */ - & 0x, + & (QH_CMASK | QH_SMASK), p.qh); size -= temp; next += temp; --- gregkh-2.6.orig/drivers/usb/host/ehci.h 2005-08-04 17:37:11.0 -0700 +++ gregkh-2.6/drivers/usb/host/ehci.h 2005-08-04 17:40:08.0 -0700 @@ -385,6 +385,11 @@ __le32 hw_info1;/* see EHCI 3.6.2 */ #defineQH_HEAD 0x8000 __le32 hw_info2;/* see EHCI 3.6.2 */ +#defineQH_SMASK0x00ff +#defineQH_CMASK0xff00 +#defineQH_HUBADDR 0x007f +#defineQH_HUBPORT 0x3f80 +#defineQH_MULT 0xc000 __le32 hw_current; /* qtd list - see EHCI 3.6.4 */ /* qtd overlay (hardware parts of a struct ehci_qtd) */ --- gregkh-2.6.orig/drivers/usb/host/ehci-q.c 2005-08-04 17:37:11.0 -0700 +++ gregkh-2.6/drivers/usb/host/ehci-q.c2005-08-04 17:40:08.0 -0700 @@ -222,7 +222,7 @@ struct ehci_qh *qh = (struct ehci_qh *) urb->hcpriv; /* S-mask in a QH means it's an interrupt urb */ - if ((qh->hw_info2 & __constant_cpu_to_le32 (0x00ff)) != 0) { + if ((qh->hw_info2 & __constant_cpu_to_le32 (QH_SMASK)) != 0) { /* ... update hc-wide periodic stats (for usbfs) */ ehci_to_hcd(ehci)->self.bandwidth_int_reqs--; @@ -428,7 +428,8 @@ /* should be rare for periodic transfers, * except maybe high bandwidth ... */ - if (qh->period) { + if ((__constant_cpu_to_le32 (QH_SMASK) + & qh->hw_info2) != 0) { intr_deschedule (ehci, qh); (void) qh_schedule (ehci, qh); } else --- gregkh-2.6.orig/drivers/usb/host/ehci-sched.c 2005-08-04 17:37:11.0 -0700 +++ gregkh-2.6/drivers/usb/host/ehci-sched.c2005-08-04 17:40:08.0 -0700 @@ -301,7 +301,7 @@ dev_dbg (&qh->dev->dev, "link qh%d-%04x/%p start %d [%d/%d us]\n", - period, le32_to_cpup (&qh->hw_info2) & 0x, + period, le32_to_cpup (&qh->hw_info2) & (QH_CMASK | QH_SMASK), qh, qh->start, qh->usecs, qh->c_usecs); /* high bandwidth, or otherwise every microframe */ @@ -385,7 +385,8 @@ dev_dbg (&qh->dev->dev, "unlink qh%d-%04x/%p start %d [%d/%d us]\n", - qh->period, le32_to_cpup (&qh->hw_info2) & 0x, + qh->period, + le32_to_cpup (&qh->hw_info2) & (QH_CMASK | QH_SMASK), qh, qh->start, qh->usecs, qh->c_usecs); /* qh->qh_next still "live" to HC */ @@ -411,7 +412,7 @@ * active high speed queues may need bigger delays... */ if (list_empty (&qh->qtd_list) - || (__constant_cpu_to_le32 (0x0ff << 8) + || (__constant_cpu_to_le32 (QH_CMASK) & qh->hw_info2) != 0)
Re: [TCP]: Fix TSO cwnd caching bug
Herbert Xu <[EMAIL PROTECTED]> wrote: > > On Thu, Aug 04, 2005 at 04:58:42PM -0700, Andrew Morton wrote: > > > > Thanks, Guillaume. Herbert, David is travelling and not able to do a lot > > of patchmonkeying. Could you please prepare and submit a final patch? > > OK, here is the final version. Thanks. > It depends on the patch that David > posted earlier on in this thread. Please let me know if you need a > copy of that. Yes please. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] pci and yenta: pcibios_bus_to_resource
From: Dominik Brodowski <[EMAIL PROTECTED]> In yenta_socket, we default to using the resource setting of the CardBus bridge. However, this is a PCI-bus-centric view of resources and thus needs to be converted to generic resources first. Therefore, add a call to pcibios_bus_to_resource() call in between. This function is a mere wrapper on x86 and friends, however on some others it already exists, is added in this patch (alpha, arm, ppc, ppc64) or still needs to be provided (parisc -- where is its pcibios_resource_to_bus() ?). Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- arch/alpha/kernel/pci.c | 16 arch/arm/kernel/bios32.c | 17 + arch/ppc/kernel/pci.c | 15 +++ arch/ppc64/kernel/pci.c | 20 drivers/pcmcia/yenta_socket.c | 15 ++- include/asm-alpha/pci.h |3 +++ include/asm-arm/pci.h |4 include/asm-generic/pci.h |8 include/asm-parisc/pci.h |4 include/asm-ppc/pci.h |4 include/asm-ppc64/pci.h |4 11 files changed, 101 insertions(+), 9 deletions(-) --- gregkh-2.6.orig/arch/alpha/kernel/pci.c 2005-08-04 17:46:04.0 -0700 +++ gregkh-2.6/arch/alpha/kernel/pci.c 2005-08-04 17:46:16.0 -0700 @@ -350,8 +350,24 @@ region->end = res->end - offset; } +void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res, +struct pci_bus_region *region) +{ + struct pci_controller *hose = (struct pci_controller *)dev->sysdata; + unsigned long offset = 0; + + if (res->flags & IORESOURCE_IO) + offset = hose->io_space->start; + else if (res->flags & IORESOURCE_MEM) + offset = hose->mem_space->start; + + res->start = region->start + offset; + res->end = region->end + offset; +} + #ifdef CONFIG_HOTPLUG EXPORT_SYMBOL(pcibios_resource_to_bus); +EXPORT_SYMBOL(pcibios_bus_to_resource); #endif int --- gregkh-2.6.orig/arch/arm/kernel/bios32.c2005-08-04 17:46:04.0 -0700 +++ gregkh-2.6/arch/arm/kernel/bios32.c 2005-08-04 17:46:16.0 -0700 @@ -447,9 +447,26 @@ region->end = res->end - offset; } +void __devinit +pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res, + struct pci_bus_region *region) +{ + struct pci_sys_data *root = dev->sysdata; + unsigned long offset = 0; + + if (res->flags & IORESOURCE_IO) + offset = root->io_offset; + if (res->flags & IORESOURCE_MEM) + offset = root->mem_offset; + + res->start = region->start + offset; + res->end = region->end + offset; +} + #ifdef CONFIG_HOTPLUG EXPORT_SYMBOL(pcibios_fixup_bus); EXPORT_SYMBOL(pcibios_resource_to_bus); +EXPORT_SYMBOL(pcibios_bus_to_resource); #endif /* --- gregkh-2.6.orig/arch/ppc64/kernel/pci.c 2005-08-04 17:46:04.0 -0700 +++ gregkh-2.6/arch/ppc64/kernel/pci.c 2005-08-04 17:46:16.0 -0700 @@ -108,8 +108,28 @@ region->end = res->end - offset; } +void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res, + struct pci_bus_region *region) +{ + unsigned long offset = 0; + struct pci_controller *hose = pci_bus_to_host(dev->bus); + + if (!hose) + return; + + if (res->flags & IORESOURCE_IO) + offset = (unsigned long)hose->io_base_virt - pci_io_base; + + if (res->flags & IORESOURCE_MEM) + offset = hose->pci_mem_offset; + + res->start = region->start + offset; + res->end = region->end + offset; +} + #ifdef CONFIG_HOTPLUG EXPORT_SYMBOL(pcibios_resource_to_bus); +EXPORT_SYMBOL(pcibios_bus_to_resource); #endif /* --- gregkh-2.6.orig/arch/ppc/kernel/pci.c 2005-08-04 17:46:04.0 -0700 +++ gregkh-2.6/arch/ppc/kernel/pci.c2005-08-04 17:46:16.0 -0700 @@ -160,6 +160,21 @@ } EXPORT_SYMBOL(pcibios_resource_to_bus); +void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res, +struct pci_bus_region *region) +{ + unsigned long offset = 0; + struct pci_controller *hose = dev->sysdata; + + if (hose && res->flags & IORESOURCE_IO) + offset = (unsigned long)hose->io_base_virt - isa_io_base; + else if (hose && res->flags & IORESOURCE_MEM) + offset = hose->pci_mem_offset; + res->start = region->start + offset; + res->end = region->end + offset; +} +EXPORT_SYMBOL(pcibios_bus_to_resource); + /* * We need to avoid collisions with `mirrored' VGA ports * and other strange ISA hardware, so we always want the --- gregkh-2.6.orig/drivers/pcmcia/yenta_socket.c 2005-08-04 17:46:04.0 -0700 +++ gregkh-2.6/d
[patch 1/5] PCI: restore BAR values after D3hot->D0 for devices that need it
From: "John W. Linville" <[EMAIL PROTECTED]> Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration (including BARs) when transitioning from D3hot->D0. This leaves such a device in an inaccessible state. The patch below causes the BARs to be restored when enabling such a device, so that its driver will be able to access it. The patch also adds pci_restore_bars as a new global symbol, and adds a correpsonding EXPORT_SYMBOL_GPL for that. Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a (re)boot. Most drivers call pci_enable_device very early, so devices left in D3hot that lose configuration during the D3hot->D0 transition will be inaccessible to their drivers. Drivers could be modified to account for this, but it would be difficult to know which drivers need modification. This is especially true since often many devices are covered by the same driver. It likely would be necessary to replicate code across dozens of drivers. The patch below should trigger only when transitioning from D3hot->D0 (or at boot), and only for devices that have the "no soft reset" bit cleared in the PM control register. I believe it is safe to include this patch as part of the PCI infrastructure. The cleanest implementation of pci_restore_bars was to call pci_update_resource. Unfortunately, that does not currently exist for the sparc64 architecture. The patch below includes a null implemenation of pci_update_resource for sparc64. Some have expressed interest in making general use of the the pci_restore_bars function, so that has been exported to GPL licensed modules. Signed-off-by: John W. Linville <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- arch/sparc64/kernel/pci.c |6 drivers/pci/pci.c | 59 ++ drivers/pci/setup-res.c |2 - include/linux/pci.h |3 ++ 4 files changed, 65 insertions(+), 5 deletions(-) --- gregkh-2.6.orig/arch/sparc64/kernel/pci.c 2005-08-04 17:37:26.0 -0700 +++ gregkh-2.6/arch/sparc64/kernel/pci.c2005-08-04 17:46:13.0 -0700 @@ -413,6 +413,12 @@ return -EBUSY; } +void pci_update_resource(struct pci_dev *dev, struct resource *res, int resno) +{ + /* Not implemented for sparc64... */ + BUG(); +} + int pci_assign_resource(struct pci_dev *pdev, int resource) { struct pcidev_cookie *pcp = pdev->sysdata; --- gregkh-2.6.orig/drivers/pci/pci.c 2005-08-04 17:37:26.0 -0700 +++ gregkh-2.6/drivers/pci/pci.c2005-08-04 17:46:13.0 -0700 @@ -222,6 +222,37 @@ } /** + * pci_restore_bars - restore a devices BAR values (e.g. after wake-up) + * @dev: PCI device to have its BARs restored + * + * Restore the BAR values for a given device, so as to make it + * accessible by its driver. + */ +void +pci_restore_bars(struct pci_dev *dev) +{ + int i, numres; + + switch (dev->hdr_type) { + case PCI_HEADER_TYPE_NORMAL: + numres = 6; + break; + case PCI_HEADER_TYPE_BRIDGE: + numres = 2; + break; + case PCI_HEADER_TYPE_CARDBUS: + numres = 1; + break; + default: + /* Should never get here, but just in case... */ + return; + } + + for (i = 0; i < numres; i ++) + pci_update_resource(dev, &dev->resource[i], i); +} + +/** * pci_set_power_state - Set the power state of a PCI device * @dev: PCI device to be suspended * @state: PCI power state (D0, D1, D2, D3hot, D3cold) we're entering @@ -239,7 +270,7 @@ int pci_set_power_state(struct pci_dev *dev, pci_power_t state) { - int pm; + int pm, need_restore = 0; u16 pmcsr, pmc; /* bound the state we're entering */ @@ -278,14 +309,17 @@ return -EIO; } + pci_read_config_word(dev, pm + PCI_PM_CTRL, &pmcsr); + /* If we're in D3, force entire word to 0. * This doesn't affect PME_Status, disables PME_En, and * sets PowerState to 0. */ - if (dev->current_state >= PCI_D3hot) + if (dev->current_state >= PCI_D3hot) { + if (!(pmcsr & PCI_PM_CTRL_NO_SOFT_RESET)) + need_restore = 1; pmcsr = 0; - else { - pci_read_config_word(dev, pm + PCI_PM_CTRL, &pmcsr); + } else { pmcsr &= ~PCI_PM_CTRL_STATE_MASK; pmcsr |= state; } @@ -308,6 +342,22 @@ platform_pci_set_power_state(dev, state); dev->current_state = state; + + /* According to section 5.4.1 of the "PCI BUS POWER MANAGEMENT +* INTERFACE SPECIFICATION, REV. 1.2", a device transitioning +* from D3hot to D0 _may_ perform an internal reset, thereby +* going to "D0 Uninitialized" rather than "D0 Initialized". +* For example, at least some versions of the 3c905B and
[patch 0/5] fixes for 2.6.13-rc5
Here are a series of patches against 2.6.13-rc5 that fix a few different bugs in the USB and PCI subsystems. thanks, greg k-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/
[TCP]: Fix TSO cwnd caching bug
On Thu, Aug 04, 2005 at 04:58:42PM -0700, Andrew Morton wrote: > > Thanks, Guillaume. Herbert, David is travelling and not able to do a lot > of patchmonkeying. Could you please prepare and submit a final patch? OK, here is the final version. It depends on the patch that David posted earlier on in this thread. Please let me know if you need a copy of that. [TCP]: Fix TSO cwnd caching bug tcp_write_xmit caches the cwnd value indirectly in cwnd_quota. When tcp_transmit_skb reduces the cwnd because of tcp_enter_cwr, the cached value becomes invalid. This patch ensures that the cwnd value is always reread after each tcp_transmit_skb call. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -972,19 +972,18 @@ static int tcp_write_xmit(struct sock *s if (unlikely(sk->sk_state == TCP_CLOSE)) return 0; - skb = sk->sk_send_head; - if (unlikely(!skb)) - return 0; - - tso_segs = tcp_init_tso_segs(sk, skb, mss_now); - cwnd_quota = tcp_cwnd_test(tp, skb); - if (unlikely(!cwnd_quota)) - goto out; - sent_pkts = 0; - while (likely(tcp_snd_wnd_test(tp, skb, mss_now))) { + while ((skb = sk->sk_send_head)) { + tso_segs = tcp_init_tso_segs(sk, skb, mss_now); BUG_ON(!tso_segs); + cwnd_quota = tcp_cwnd_test(tp, skb); + if (!cwnd_quota) + break; + + if (unlikely(!tcp_snd_wnd_test(tp, skb, mss_now))) + break; + if (tso_segs == 1) { if (unlikely(!tcp_nagle_test(tp, skb, mss_now, (tcp_skb_is_last(sk, skb) ? @@ -1026,27 +1025,12 @@ static int tcp_write_xmit(struct sock *s tcp_minshall_update(tp, mss_now, skb); sent_pkts++; - - /* Do not optimize this to use tso_segs. If we chopped up -* the packet above, tso_segs will no longer be valid. -*/ - cwnd_quota -= tcp_skb_pcount(skb); - - BUG_ON(cwnd_quota < 0); - if (!cwnd_quota) - break; - - skb = sk->sk_send_head; - if (!skb) - break; - tso_segs = tcp_init_tso_segs(sk, skb, mss_now); } if (likely(sent_pkts)) { tcp_cwnd_validate(sk, tp); return 0; } -out: return !tp->packets_out && sk->sk_send_head; }
Re: [PATCH] Speedup FAT filesystem directory reads
Am Donnerstag, 4. August 2005 16:21 schrieb OGAWA Hirofumi: > Karsten Wiese <[EMAIL PROTECTED]> writes: > > > Please give this a try and commit to -mm or mainline, if approved. > > Looks good. Thanks. However, I tweaked the patch. > > - replace __getblk() to sb_getblk() > - exclude root-dir of FAT12/FAT16 from readahead > - exclude (sec_per_clus == 1) from readahead > - move the all readahead stuff to one inline function > > What do you think of the following patch? Looks better, is smaller and works equally well here, thanks. I had to hand apply it though as it was slightly scrambled (by my mail client?) so patch couldn't handle it. Please send patches as attachment. Andrew, please replace the initial version in -mm with this one. Thanks, Karsten From: Karsten Wiese <[EMAIL PROTECTED]> From: OGAWA Hirofumi <[EMAIL PROTECTED]> This speeds up directory reads for large FAT partitions, if the buffercache has to be filled from the drive. Following values were taken from: $ time find path_to_freshly_mounted_fat > /dev/null on an otherwise idle system. FAT with 16KB Clusters on IDE attached drive: Factor 2 FAT with 32KB Clusters on USB2 attached drive: Factor 10 (!) Its less than 1/10 slower, if the buffercache is uptodate. The patch introduces the new function fat_dir_readahead(). fat_dir_readahead() calls sb_breadahead() to readahead a whole cluster, if the requested sector is the first one in a cluster. It is usefull to do this, because on FAT directories occupy whole clusters, with the exception of FAT12/FAT16 root dirs. Readahead is only done, if the cluster's first sector is not uptodate to avoid overhead, when the buffer cache is already uptodate. Note that under memory pressure, the maximal byte count wasted (read: has to be red from disk twice) is 1 cluster's size. Thats 64KB. fat_dir_readahead() is called from fat__get_entry(). There is also an unrelated cleanup at one spot: if (bh) brelse(bh); is replaced with: brelse(bh); brelse() can handle NULL pointer arguments by itself. Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]> Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]> diff -ur linux-2.6.13_orig/fs/fat/dir.c linux-2.6.13/fs/fat/dir.c --- linux-2.6.13_orig/fs/fat/dir.c 2005-07-31 21:14:20.0 +0200 +++ linux-2.6.13/fs/fat/dir.c 2005-08-04 19:11:21.0 +0200 @@ -30,6 +30,29 @@ | (de - (struct msdos_dir_entry *)bh->b_data); } +static inline void fat_dir_readahead(struct inode *dir, sector_t iblock, + sector_t phys) +{ + struct super_block *sb = dir->i_sb; + struct msdos_sb_info *sbi = MSDOS_SB(sb); + struct buffer_head *bh; + int sec; + + /* This is not a first sector of cluster, or sec_per_clus == 1 */ + if ((iblock & (sbi->sec_per_clus - 1)) || sbi->sec_per_clus == 1) + return; + /* root dir of FAT12/FAT16 */ + if ((sbi->fat_bits != 32) && (dir->i_ino == MSDOS_ROOT_INO)) + return; + + bh = sb_getblk(sb, phys); + if (bh && !buffer_uptodate(bh)) { + for (sec = 0; sec < sbi->sec_per_clus; sec++) + sb_breadahead(sb, phys + sec); + } + brelse(bh); +} + /* Returns the inode number of the directory entry at offset pos. If bh is non-NULL, it is brelse'd before. Pos is incremented. The buffer header is returned in bh. @@ -58,6 +81,8 @@ if (err || !phys) return -1; /* beyond EOF or error */ + fat_dir_readahead(dir, iblock, phys); + *bh = sb_bread(sb, phys); if (*bh == NULL) { printk(KERN_ERR "FAT: Directory bread(block %llu) failed\n", @@ -635,8 +660,7 @@ EODir: filp->f_pos = cpos; FillFailed: - if (bh) - brelse(bh); + brelse(bh); if (unicode) free_page((unsigned long)unicode); out:
Re: [PATCH] dyn-tick3 tweaks
Con Kolivas wrote: Something like this on top is cleaner and quieter. I'll add this to pending changes for another version. Index: linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c === --- linux-2.6.13-rc5-ck2.orig/arch/i386/kernel/timers/timer_tsc.c 2005-08-03 11:29:29.0 +1000 +++ linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c2005-08-05 10:22:25.0 +1000 @@ -167,10 +167,20 @@ static void delay_tsc(unsigned long loop } while ((now-bclock) < loops); } +/* update the monotonic base value */ +static inline void update_monotonic_base(unsigned long long last_offset) +{ + unsigned long long this_offset; + + this_offset = ((unsigned long long)last_tsc_high << 32) | last_tsc_low; + monotonic_base += cycles_2_ns(this_offset - last_offset); + write_sequnlock(&monotonic_lock); +} + All else being equal, it is much better if you unlock in the same function that takes the lock. For readability. It looks like you should be able to leave all the flow control and locking the same, and use update_monotonic_base() to do the actual update? -- 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] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Fri, 5 Aug 2005 08:12 am, Marc Ballarin wrote: > On Wed, 3 Aug 2005 15:59:24 +1000 > > Con Kolivas <[EMAIL PROTECTED]> wrote: > > This is the dynamic ticks patch for i386 as written by Tony Lindgen > > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>. > > Patch for 2.6.13-rc5 > > One issue (tested the -rc4 Version on -mm): > - on interrupt flood (ping -f) HZ goes down to 0-4 HZ. > This matches "ticks to skip" below. Coincidence? > > - ping -f complains: > .Warning: time of day goes back (-304us), taking countermeasures. > ... > .Warning: time of day goes back (-33us), taking countermeasures. > > Yet, system time _seems_ to be kept correctly. Interesting... It almost seems like if you throw enough interrupts at it the next_timer_interrupt function gets confused. I wonder if S390 and ARM are seeing this at all since (it seems to me) they use that function? Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc4-git4: bluetooth oops on pcmcia shutdown
Andreas Steinmetz <[EMAIL PROTECTED]> wrote: > > The attached bluetooth oops can be reliably reproduced on my x86_64 > laptop. It happens when hciattach is still running while a sequence of > "cardctl eject" and then "killproc /sbin/cardmgr" is executed. > Though this seems to point to preempt I could manage to cause similar > oopses on non-preemptible kernels a while ago. Again, it doesn't look like we'll have a quick fix for this, so a bugzilla entry would be appreciated, please. It would help if you can identify an earlier 2.6 kernel which didn't have the bug, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dyn-tick3 tweaks
On Fri, 5 Aug 2005 10:05 am, Con Kolivas wrote: > Looking yet further into this, if it gotos monotonic_base it will return > without using any of these variables so it's a harmless warning but we may > as well initialise them to quieten it. Something like this on top is cleaner and quieter. I'll add this to pending changes for another version. Cheers, Con --- Index: linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c === --- linux-2.6.13-rc5-ck2.orig/arch/i386/kernel/timers/timer_tsc.c 2005-08-03 11:29:29.0 +1000 +++ linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c 2005-08-05 10:22:25.0 +1000 @@ -167,10 +167,20 @@ static void delay_tsc(unsigned long loop } while ((now-bclock) < loops); } +/* update the monotonic base value */ +static inline void update_monotonic_base(unsigned long long last_offset) +{ + unsigned long long this_offset; + + this_offset = ((unsigned long long)last_tsc_high << 32) | last_tsc_low; + monotonic_base += cycles_2_ns(this_offset - last_offset); + write_sequnlock(&monotonic_lock); +} + #ifdef CONFIG_HPET_TIMER static void mark_offset_tsc_hpet(void) { - unsigned long long this_offset, last_offset; + unsigned long long last_offset; unsigned long offset, temp, hpet_current; write_seqlock(&monotonic_lock); @@ -198,10 +208,7 @@ static void mark_offset_tsc_hpet(void) } hpet_last = hpet_current; - /* update the monotonic base value */ - this_offset = ((unsigned long long)last_tsc_high<<32)|last_tsc_low; - monotonic_base += cycles_2_ns(this_offset - last_offset); - write_sequnlock(&monotonic_lock); + update_monotonic_base(last_offset); /* calculate delay_at_last_interrupt */ /* @@ -347,7 +354,7 @@ static void mark_offset_tsc(void) int count; int countmp; static int count1 = 0; - unsigned long long this_offset, last_offset; + unsigned long long last_offset; static int lost_count = 0; write_seqlock(&monotonic_lock); @@ -368,8 +375,10 @@ static void mark_offset_tsc(void) rdtsc(last_tsc_low, last_tsc_high); - if (dyn_tick_enabled()) - goto monotonic_base; + if (dyn_tick_enabled()) { + update_monotonic_base(last_offset); + return; + } spin_lock(&i8253_lock); outb_p(0x00, PIT_MODE); /* latch the count ASAP */ @@ -439,15 +448,7 @@ static void mark_offset_tsc(void) } else lost_count = 0; - monotonic_base: - - /* update the monotonic base value */ - this_offset = ((unsigned long long)last_tsc_high<<32)|last_tsc_low; - monotonic_base += cycles_2_ns(this_offset - last_offset); - write_sequnlock(&monotonic_lock); - - if (dyn_tick_enabled()) - return; + update_monotonic_base(last_offset); /* calculate delay_at_last_interrupt */ count = ((LATCH-1) - count) * TICK_SIZE;
Re: 2.6.13-rc4: yenta_socket and swsusp
On Thu, 2005-08-04 at 17:15 -0700, Andrew Morton wrote: > Seems that the linux-kernel list has the same result ;( Are you serious, LKML is subscribers only now? Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc4: yenta_socket and swsusp
Andreas Steinmetz <[EMAIL PROTECTED]> wrote: > > [now sending to lkml as sending to the pcmcia list without being > subscribed seems to go to /dev/null] Seems that the linux-kernel list has the same result ;( > I do have problems with yenta_socket on my x86_64 laptop which appear > when using swsusp (suspend to disk mode). > > 1. When I do not access any pcmcia device from initrd during boot >I have to terminate cardmgr, otherwise suspend to disk hangs. >For 2.6.11 it was sufficient to call 'cardctl eject'. > > 2. When I have to access a pcmcia device from initrd during boot >(there's required crypto keys stored on a pcmcia flash disk) >and I do not unload yenta_socket prior to suspend the laptop >spontaneously reboots or just hangs on resume when swsusp has >finished loading. > > 3. If I do not unload the pcmcia modules prior to suspend with >rmmod -w unloading yenta_socket fails. > > 4. If I do unload the pcmcia modules in a loop with rmmod -w >but no delay between unloading the modules it happens from >time to time that yenta_socket unloading hangs with a use >count of 2 when there is definitely no more user of the module. >A delay of 50 msec after unload of each pcmcia module seems >to cure this. > > 5. If I insert yenta_socket within the first few seconds after resume >the laptop spontaneously reboots. A 5 second delay seems to cure >this most of the time. OK so we have one solid regression there. Are the other problems also new since 2.6.11? Could you please retest 2.6.13-rc6 when it's out and if problems remain, raise a bugzilla.kernel.org entry so we can keep track of the problem? Thanks. (I'm trying to get all unattended and older-than-a-few-days bug reports pushed over to bugzilla so they don't get lost). > BTW: > Did I read this right? PCMCIA control ioctl (needed for pcmcia-cs > [cardmgr, cardctl]) scheduled for removal in november *this* year? So a > 3 month warning for everybody is sufficient? Probably only one kernel > release? So much for sufficient backwards compatability. Especially as > the tools stated to be required aren't even released as of today (hint: > module-init-tools 3.2). Grrr. Three months does sound optimistic. Dominik, wouldn't a year be better? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to get the physical page addresses from a kernel virtual address for DMA SG List?
You may want to take a look at the user-mode driver infrastructure patches, which do almost exactly what you're trying to do. Get them from http://www.gelato.unsw.edu.au/cgi-bin/viewcvs.cgi/cvs/kernel/usrdrivers/kernel-2.6.12-rc3/ -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au The technical we do immediately, the political takes *forever* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] no-idle-hz aka dynamic ticks-2
On Fri, 5 Aug 2005 10:02 am, Con Kolivas wrote: > On Thu, 4 Aug 2005 07:09 am, Pavel Machek wrote: > > Hi! > > > > > > > As promised, here is an updated patch for the newly released > > > > > 2.6.13-rc5. Boots and runs fine on P4HT (SMP+SMT kernel) built with > > > > > gcc 4.0.1. > > > > > > > > Doesn't compile for me w/ gcc 3.4.4: > > > > > > Thanks for the report. Tiny change required. Here is a respun patch. > > > > I'm not sure if you added them, but... > > > > CC arch/i386/kernel/timers/timer_tsc.o > > arch/i386/kernel/timers/timer_tsc.c: In function `mark_offset_tsc': > > arch/i386/kernel/timers/timer_tsc.c:345: warning: `lost' might be used > > uninitialized in this function arch/i386/kernel/timers/timer_tsc.c:345: > > warning: `delay' might be used uninitialized in this function > > arch/i386/kernel/timers/timer_tsc.c:347: warning: `count' might be used > > uninitialized in this function > > Indeed the goto will bypass the setting of these variables and they will be > uninitialised. Will fix with next version, thanks. Looking yet further into this, if it gotos monotonic_base it will return without using any of these variables so it's a harmless warning but we may as well initialise them to quieten it. Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] no-idle-hz aka dynamic ticks-2
On Thu, 4 Aug 2005 07:09 am, Pavel Machek wrote: > Hi! > > > > > As promised, here is an updated patch for the newly released > > > > 2.6.13-rc5. Boots and runs fine on P4HT (SMP+SMT kernel) built with > > > > gcc 4.0.1. > > > > > > Doesn't compile for me w/ gcc 3.4.4: > > > > Thanks for the report. Tiny change required. Here is a respun patch. > > I'm not sure if you added them, but... > > CC arch/i386/kernel/timers/timer_tsc.o > arch/i386/kernel/timers/timer_tsc.c: In function `mark_offset_tsc': > arch/i386/kernel/timers/timer_tsc.c:345: warning: `lost' might be used > uninitialized in this function arch/i386/kernel/timers/timer_tsc.c:345: > warning: `delay' might be used uninitialized in this function > arch/i386/kernel/timers/timer_tsc.c:347: warning: `count' might be used > uninitialized in this function Indeed the goto will bypass the setting of these variables and they will be uninitialised. Will fix with next version, thanks. Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc4 - kernel panic - BUG at net/ipv4/tcp_output.c:918
Guillaume Pelat <[EMAIL PROTECTED]> wrote: > > Hi, > > Herbert Xu wrote: > > On Thu, Aug 04, 2005 at 01:33:29PM +1000, herbert wrote: > > > >>So I suppose we should reset cwnd_quota after tcp_transmit_skb? > > > > Please try this patch to see if this is really the problem or not. > > > > Thanks, > > I just applied your patch, and it seems to work :) > 2 hours uptime, and no crash yet (without the patch, it was crashing a > few mins only after booting). > So i think the bug is crushed :) > Thanks, Guillaume. Herbert, David is travelling and not able to do a lot of patchmonkeying. Could you please prepare and submit a final patch? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] Add write protection switch handling to the PXA MMC driver
Add a write protection switch handling code to the PXA MMC driver so that platform specific code can provide it if available (extending the MMC/SD patches in -mm). Signed-off-by: Richard Purdie <[EMAIL PROTECTED]> Index: linux-2.6.12/include/asm-arm/arch-pxa/mmc.h === --- linux-2.6.12.orig/include/asm-arm/arch-pxa/mmc.h2005-08-05 00:29:17.0 +0100 +++ linux-2.6.12/include/asm-arm/arch-pxa/mmc.h 2005-08-05 00:29:43.0 +0100 @@ -10,6 +10,7 @@ struct pxamci_platform_data { unsigned int ocr_mask; /* available voltages */ int (*init)(struct device *, irqreturn_t (*)(int, void *, struct pt_regs *), void *); + int (*get_ro)(struct device *); void (*setpower)(struct device *, unsigned int); void (*exit)(struct device *, void *); }; Index: linux-2.6.12/drivers/mmc/pxamci.c === --- linux-2.6.12.orig/drivers/mmc/pxamci.c 2005-08-05 00:29:17.0 +0100 +++ linux-2.6.12/drivers/mmc/pxamci.c 2005-08-05 00:29:43.0 +0100 @@ -362,6 +362,16 @@ pxamci_start_cmd(host, mrq->cmd, cmdat); } +static int pxamci_get_ro(struct mmc_host *mmc) +{ + struct pxamci_host *host = mmc_priv(mmc); + + if (host->pdata && host->pdata->get_ro) + return host->pdata->get_ro(mmc->dev); + /* Host doesn't support read only detection so assume writeable */ + return 0; +} + static void pxamci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) { struct pxamci_host *host = mmc_priv(mmc); @@ -401,6 +411,7 @@ static struct mmc_host_ops pxamci_ops = { .request= pxamci_request, + .get_ro = pxamci_get_ro, .set_ios= pxamci_set_ios, }; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Corgi: Add MMC/SD write protection switch handling
Add MMC/SD write protection switch handling for the Corgi platform (extending the MMC/SD patches in -mm). Signed-off-by: Richard Purdie <[EMAIL PROTECTED]> Index: linux-2.6.12/arch/arm/mach-pxa/corgi.c === --- linux-2.6.12.orig/arch/arm/mach-pxa/corgi.c 2005-08-05 00:29:17.0 +0100 +++ linux-2.6.12/arch/arm/mach-pxa/corgi.c 2005-08-05 00:29:45.0 +0100 @@ -160,6 +160,11 @@ } } +static int corgi_mci_get_ro(struct device *dev) +{ + return GPLR(CORGI_GPIO_nSD_WP) & GPIO_bit(CORGI_GPIO_nSD_WP); +} + static void corgi_mci_exit(struct device *dev, void *data) { free_irq(CORGI_IRQ_GPIO_nSD_DETECT, data); @@ -169,6 +174,7 @@ static struct pxamci_platform_data corgi_mci_platform_data = { .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34, .init = corgi_mci_init, + .get_ro = corgi_mci_get_ro, .setpower = corgi_mci_setpower, .exit = corgi_mci_exit, }; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ahci, SActive flag, and the HD activity LED
On 8/3/05, Jens Axboe <[EMAIL PROTECTED]> wrote: > On Wed, Aug 03 2005, Martin Wilck wrote: > > Have you (or has anybody else) also seen the wrong behavior of the > > activity LED? > > No, but I have observed that SActive never gets cleared by the device > for non-NCQ commands (which is probably which gets you the stuck LED on > some systems?), which to me is another indication that we should not be > setting the tag bits for those commands. The drives won't send a SetBits FIS when not using NCQ, as it can really confuse some host adapters that don't understand NCQ. I'd imagine you're correct that the driver shouldn't be setting the bit in the first place. --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: NUMA policy interface
On Fri, 5 Aug 2005, Andi Kleen wrote: > None of them seem very attractive to me. I would prefer to just > not support external accesses keeping things lean and fast. That is a surprising statement given what we just discussed. Things are not lean and fast but weirdly screwed up. The policy layer is significantly impacted by historical contingencies rather than designed in a clean way. It cannot even deliver the functionality it was designed to deliver (see BIND). > Individual physical page migration is quite different from > address space migration. Address space migration? That is something new in this discussion. So could you explain what you mean by that? I have looked at page migration in a variety of contexts and could not see much difference. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Corgi: Add keyboard and touchscreen device definitions
Add keyboard and touchscreen device definitions for corgi. Signed-off-by: Richard Purdie <[EMAIL PROTECTED]> Index: linux-2.6.12/arch/arm/mach-pxa/corgi.c === --- linux-2.6.12.orig/arch/arm/mach-pxa/corgi.c 2005-08-05 00:29:45.0 +0100 +++ linux-2.6.12/arch/arm/mach-pxa/corgi.c 2005-08-05 00:29:47.0 +0100 @@ -99,6 +99,27 @@ /* + * Corgi Keyboard Device + */ +static struct platform_device corgikbd_device = { + .name = "corgi-keyboard", + .id = -1, +}; + + +/* + * Corgi Touch Screen Device + */ +static struct platform_device corgits_device = { + .name = "corgi-ts", + .dev= { + .parent = &corgissp_device.dev, + }, + .id = -1, +}; + + +/* * MMC/SD Device * * The card detect interrupt isn't debounced so we delay it by HZ/4 @@ -180,6 +201,7 @@ }; + /* * USB Device Controller */ @@ -205,7 +227,9 @@ &corgiscoop_device, &corgissp_device, &corgifb_device, + &corgikbd_device, &corgibl_device, + &corgits_device, }; static void __init corgi_init(void) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IDE disks show invalid geometries in /proc/ide/hd*/geometry
On 8/4/05, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > All of these numbers are virtual, since CHS is not really used anymore, as > we know. But, which of these fake CHS values (16383/16/63 | 65535/16/63 | > 1023/255/63) is the right one? 255/63/4982 is another matter, since it > [almost] matches the actual size of the disk while the other three are just > "for the bios". What do you mean by right? Not one of those above values has any physical meaning --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: NUMA policy interface
On Thu, Aug 04, 2005 at 03:19:52PM -0700, Christoph Lameter wrote: > There are three possibilites: > > 1. do what cpusets is doing by versioning. > > 2. Have the task notifier access the task_struct information. > See http://lwn.net/Articles/145232/ "A new path to the refrigerator" > > 3. Maybe the easiest: Require mmap_sem to be taken for all policy > accesses. Currently its only require for vma policies. Then we need > to make a copy of the policy at some point so that alloc_pages can > access policy information lock free. This may also allow us to fix > the bind issue if we would f.e. keep a bitmap in the taskstruct or (ab)use > the cpusets map. None of them seem very attractive to me. I would prefer to just not support external accesses keeping things lean and fast. > > If they cannot afford enough disk space it might be possible > > to do the page migration in swap cache like Hugh proposed. > > This code already exist in the memory hotplug code base and Ray already > had a working implementation for page migration. The migration code will > also be necessary in order to relocate pages with ECC single bit failures > that Russ is working on (of course that will only work for some pages) and > for Mel Gorman's defragmentation approach (if we ever get the split into > differnet types of memory chunks in). Individual physical page migration is quite different from address space migration. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PNPACPI: fix IRQ and 64-bit address decoding
Maybe the third time's the charm :-) Added a bugfix (pcibios_penalize_isa_irq()) and a workaround for HP HPET firmware description since last time. The workaround accepts stuff that is illegal according to the spec, so speak up if you think this is a problem. It seems fairly safe to me. Use types that match the ACPI resource structures. Previously the u64 value from an RSTYPE_ADDRESS64 was passed as an int, which corrupts the value. Move pcibios_penalize_isa_irq() to pnpacpi_parse_allocated_irqresource(). Previously we passed the GSI, not the IRQ, and we did it even if parsing the IRQ resource failed. Parse IRQ descriptors that contain multiple interrupts. This violates the spec (in _CRS, only one interrupt per descriptor is allowed), but some firmware, e.g., HP rx7620 and rx8620 descriptions of HPET, has this bug. Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]> Index: work-mm/drivers/pnp/pnpacpi/rsparser.c === --- work-mm.orig/drivers/pnp/pnpacpi/rsparser.c 2005-08-04 16:41:04.0 -0600 +++ work-mm/drivers/pnp/pnpacpi/rsparser.c 2005-08-04 16:42:52.0 -0600 @@ -73,25 +73,35 @@ } static void -pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, int irq) +pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, u32 gsi, + int edge_level, int active_high_low) { int i = 0; + int irq; + + if (!valid_IRQ(gsi)) + return; + while (!(res->irq_resource[i].flags & IORESOURCE_UNSET) && i < PNP_MAX_IRQ) i++; - if (i < PNP_MAX_IRQ) { - res->irq_resource[i].flags = IORESOURCE_IRQ; //Also clears _UNSET flag - if (irq < 0) { - res->irq_resource[i].flags |= IORESOURCE_DISABLED; - return; - } - res->irq_resource[i].start =(unsigned long) irq; - res->irq_resource[i].end = (unsigned long) irq; + if (i >= PNP_MAX_IRQ) + return; + + res->irq_resource[i].flags = IORESOURCE_IRQ; // Also clears _UNSET flag + irq = acpi_register_gsi(gsi, edge_level, active_high_low); + if (irq < 0) { + res->irq_resource[i].flags |= IORESOURCE_DISABLED; + return; } + + res->irq_resource[i].start = irq; + res->irq_resource[i].end = irq; + pcibios_penalize_isa_irq(irq, 1); } static void -pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, int dma) +pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, u32 dma) { int i = 0; while (i < PNP_MAX_DMA && @@ -103,14 +113,14 @@ res->dma_resource[i].flags |= IORESOURCE_DISABLED; return; } - res->dma_resource[i].start =(unsigned long) dma; - res->dma_resource[i].end = (unsigned long) dma; + res->dma_resource[i].start = dma; + res->dma_resource[i].end = dma; } } static void pnpacpi_parse_allocated_ioresource(struct pnp_resource_table * res, - int io, int len) + u32 io, u32 len) { int i = 0; while (!(res->port_resource[i].flags & IORESOURCE_UNSET) && @@ -122,14 +132,14 @@ res->port_resource[i].flags |= IORESOURCE_DISABLED; return; } - res->port_resource[i].start = (unsigned long) io; - res->port_resource[i].end = (unsigned long)(io + len - 1); + res->port_resource[i].start = io; + res->port_resource[i].end = io + len - 1; } } static void pnpacpi_parse_allocated_memresource(struct pnp_resource_table * res, - int mem, int len) + u64 mem, u64 len) { int i = 0; while (!(res->mem_resource[i].flags & IORESOURCE_UNSET) && @@ -141,8 +151,8 @@ res->mem_resource[i].flags |= IORESOURCE_DISABLED; return; } - res->mem_resource[i].start = (unsigned long) mem; - res->mem_resource[i].end = (unsigned long)(mem + len - 1); + res->mem_resource[i].start = mem; + res->mem_resource[i].end = mem + len - 1; } } @@ -151,27 +161,28 @@ void *data) { struct pnp_resource_table * res_table = (struct pnp_resource_table *)data; + int i; switch (res->id) { case ACPI_RSTYPE_IRQ: - if ((res->data.irq.number_of_interrupts > 0) && - valid_IRQ(res->data.irq.interrupts[0])) { - pnpacpi_parse_allocated_irqresource(res_table, - acpi_register_gsi(res->data.irq.interrupts[0], - res->data.irq.edge_level, - res->data.irq.active_hig
Re: [PATCH] push rounding up of relative request to schedule_timeout()
Hi, On Thu, 4 Aug 2005, Nishanth Aravamudan wrote: > > What makes you think the comment is correct? This comment was added at > > 2.4.3, while schedule_timeout() has this behaviour since it was added at > > 2.1.127. > > Fair enough. Should we change the comment? It can't hurt to fix the comment. > If a user requests schedule_timeout(HZ/100); which, if HZ is 1000, is 10 > jiffies, yes? But, since we are between ticks, we want to actually add > that request to the next interval, not to the current one. Otherwise, we > do have the possibility of returning early. Currently, we require > callers to add the +1 to their request, and thus they only add it to the > first one. The problem with my patch which pushed it to > schedule_timeout(), is that we will do +1 to every request. I'm not > sure, without some sort of "persistent" timeout control structure, how > we get around that, though, in the schedule_timeout() case. Does that > make any more sense? I don't disagree, but please create some sane interfaces, e.g. something like below. This allows to first convert as much as possible schedule_timeout() users and then we can still change the schedule_timeout() interface. bye, Roman include/linux/sched.h | 17 +++ kernel/timer.c| 71 +++--- 2 files changed, 78 insertions(+), 10 deletions(-) Index: linux-2.6/include/linux/sched.h === --- linux-2.6.orig/include/linux/sched.h2005-06-18 15:00:59.0 +0200 +++ linux-2.6/include/linux/sched.h 2005-08-04 23:42:43.0 +0200 @@ -182,9 +182,24 @@ extern void scheduler_tick(void); extern int in_sched_functions(unsigned long addr); #defineMAX_SCHEDULE_TIMEOUTLONG_MAX -extern signed long FASTCALL(schedule_timeout(signed long timeout)); +extern void schedule_until(unsigned long expire) fastcall; +extern int schedule_until_intr(unsigned long expire) fastcall; +extern int schedule_until_unintr(unsigned long expire) fastcall; +extern signed long schedule_timeout(signed long timeout) fastcall; +extern int schedule_timeout_intr(signed long timeout) fastcall; +extern int schedule_timeout_unintr(signed long timeout) fastcall; asmlinkage void schedule(void); +static inline int schedule_timeout_msecs_intr(unsigned int timeout) +{ + return schedule_timeout_intr(msecs_to_jiffies(timeout)); +} + +static inline int schedule_timeout_msecs_unintr(unsigned int timeout) +{ + return schedule_timeout_unintr(msecs_to_jiffies(timeout)); +} + struct namespace; /* Maximum number of active map areas.. This is a random (large) number */ Index: linux-2.6/kernel/timer.c === --- linux-2.6.orig/kernel/timer.c 2005-06-18 15:01:12.0 +0200 +++ linux-2.6/kernel/timer.c2005-08-04 23:42:36.0 +0200 @@ -1049,6 +1049,67 @@ static void process_timeout(unsigned lon wake_up_process((task_t *)__data); } +fastcall __sched void schedule_until(unsigned long expire) +{ + struct timer_list timer; + + init_timer(&timer); + timer.expires = expire; + timer.data = (unsigned long) current; + timer.function = process_timeout; + + add_timer(&timer); + schedule(); + del_singleshot_timer_sync(&timer); +} +EXPORT_SYMBOL(schedule_until); + +fastcall __sched int schedule_until_intr(unsigned long expire) +{ + set_current_state(TASK_INTERRUPTIBLE); + schedule_until(expire); + return time_before(expire, jiffies); +} +EXPORT_SYMBOL(schedule_until_intr); + +fastcall __sched int schedule_until_unintr(unsigned long expire) +{ + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_until(expire); + return time_before(expire, jiffies); +} +EXPORT_SYMBOL(schedule_until_intr); + +fastcall __sched int schedule_timeout_intr(signed long timeout) +{ + unsigned long expire; + + set_current_state(TASK_INTERRUPTIBLE); + if (timeout >= MAX_SCHEDULE_TIMEOUT - 1) { + schedule(); + return 1; + } + expire = jiffies + timeout + 1; + schedule_until(expire); + return time_before(expire, jiffies); +} +EXPORT_SYMBOL(schedule_timeout_intr); + +fastcall __sched int schedule_timeout_unintr(signed long timeout) +{ + unsigned long expire; + + set_current_state(TASK_UNINTERRUPTIBLE); + if (timeout >= MAX_SCHEDULE_TIMEOUT - 1) { + schedule(); + return 1; + } + expire = jiffies + timeout + 1; + schedule_until(expire); + return time_before(expire, jiffies); +} +EXPORT_SYMBOL(schedule_timeout_unintr); + /** * schedule_timeout - sleep until timeout * @timeout: timeout value in jiffies @@ -1077,7 +1138,6 @@ static void process_timeout(unsigned lon */ fastcall signed long __sched schedule_timeout(signed long timeout) { - struct timer_list t
[PATCH] fix voyager compile after machine_emergency_restart breakage
[PATCH] i386: Implement machine_emergency_reboot introduced this new function into arch/i386/reboot.c. However, subarchitectures are entitled to implement their own copies of reboot.c from which this new function is now missing. It looks like visws will also need a similar fixup Signed-off-by: James Bottomley <[EMAIL PROTECTED]> diff --git a/arch/i386/mach-voyager/voyager_basic.c b/arch/i386/mach-voyager/voyager_basic.c --- a/arch/i386/mach-voyager/voyager_basic.c +++ b/arch/i386/mach-voyager/voyager_basic.c @@ -279,6 +279,13 @@ machine_restart(char *cmd) } void +machine_emergency_restart(void) +{ + /*for now, just hook this to a warm restart */ + machine_restart(NULL); +} + +void mca_nmi_hook(void) { __u8 dumpval __attribute__((unused)) = inb(0xf823); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc5-git2 does not boot on (my) amd64
On Fri, Aug 05, 2005 at 12:06:25AM +0100, Hugh Dickins wrote: > On Thu, 5 Aug 2005, Andi Kleen wrote: > > [EMAIL PROTECTED] (Danny ter Haar) writes: > > > > > > Freeing unused kernel memory: 248k freed > > > VM: killing process hotplug > > > VM: killing process hotplug > > > VM: killing process hotplug > > > VM: killing process hotplug > > > Unable to handle kernel paging request at fff28017b5be RIP: > > > [] > > > > Looks weird. Just to make sure can you do a make distclean and try > > again? It might be a bad compile. > > No, like Pavel's and Martin's reports, this is just an effect > of the not-quite-fully-baked do_wp_page/get_user_pages race fix in > 2.6.13-rc5-git2, which AlexN reported earlier. Should now be fully > fixed in Linus' current git, and in the 2.6.13-rc6 akpm prophesies > to be coming soon - please all test that. Yes. I didn't read the mail fully before replying to that one. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] no-idle-hz aka dynamic ticks-2
Hi! > > > As promised, here is an updated patch for the newly released 2.6.13-rc5. > > > Boots and runs fine on P4HT (SMP+SMT kernel) built with gcc 4.0.1. > > > > Doesn't compile for me w/ gcc 3.4.4: > > Thanks for the report. Tiny change required. Here is a respun patch. I tried setting DYN_TICK_USE_APIC, and it got even worse. Basically machine was frozen; if I pressed enough keys, it moved forward, then froze again. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc5-git2 does not boot on (my) amd64
--Hugh Dickins <[EMAIL PROTECTED]> wrote (on Friday, August 05, 2005 00:06:25 +0100): > On Thu, 5 Aug 2005, Andi Kleen wrote: >> [EMAIL PROTECTED] (Danny ter Haar) writes: >> > >> > Freeing unused kernel memory: 248k freed >> > VM: killing process hotplug >> > VM: killing process hotplug >> > VM: killing process hotplug >> > VM: killing process hotplug >> > Unable to handle kernel paging request at fff28017b5be RIP: >> > [] >> >> Looks weird. Just to make sure can you do a make distclean and try >> again? It might be a bad compile. > > No, like Pavel's and Martin's reports, this is just an effect > of the not-quite-fully-baked do_wp_page/get_user_pages race fix in > 2.6.13-rc5-git2, which AlexN reported earlier. Should now be fully > fixed in Linus' current git, and in the 2.6.13-rc6 akpm prophesies > to be coming soon - please all test that. OK, nightly builds tests should auto-appear on http://test.kernel.org tommorow morning. I'll try to remember to look for it; if you remember before I wake up Hugh, should be published there ... ;-) Thanks for the feedback, M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
networking problems when using gcc 4.0.1
On Wed, Aug 03, 2005 at 08:53:52PM -0400, Mathieu Chouquet-Stringer wrote: > > Moreover I get some weird networking problems which prevent setting up the > routes (RNETLINK invalid argument messages) when I compile my kernel with > 4.0.1 while the same kernel, same config works fine compiled with 3.2.3... > > So eventhough 4.0 is supposed to be supported, it doesn't work too well in > my case. I haven't heard of such a problem. Please give a complete bug report: - exact error messages - kernel version - self-compiled gcc or distrbution compiler? > Mathieu Chouquet-Stringer cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] remove support for gcc < 3.2
On Thu, Aug 04, 2005 at 08:54:47AM +0200, Jan-Benedict Glaw wrote: >... > Current GCC from CVS (plus minor configury patches) seems to work. We > had -fno-unit-at-a-time missing in our arch Makefile which hides a bug > in kernel's sources. > > I guess that if you remove -fno-unit-at-a-time from i386 and use a > current GCC, you'll run into that fun, too. What bug exactly? I'm sometimes using kernels compiled with gcc 4.0 and without -fno-unit-at-a-time and except for the kernel image being smaller I haven't noticed any difference. Besides this, all architectures except i386 and um are not disabling unit-at-a-time. There are a few parts of the kernel that might still have stack problems with unit-at-a-time, but I assume that's not what you are talking about? > MfG, JBG >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc5-git2 does not boot on (my) amd64
On Thu, 5 Aug 2005, Andi Kleen wrote: > [EMAIL PROTECTED] (Danny ter Haar) writes: > > > > Freeing unused kernel memory: 248k freed > > VM: killing process hotplug > > VM: killing process hotplug > > VM: killing process hotplug > > VM: killing process hotplug > > Unable to handle kernel paging request at fff28017b5be RIP: > > [] > > Looks weird. Just to make sure can you do a make distclean and try > again? It might be a bad compile. No, like Pavel's and Martin's reports, this is just an effect of the not-quite-fully-baked do_wp_page/get_user_pages race fix in 2.6.13-rc5-git2, which AlexN reported earlier. Should now be fully fixed in Linus' current git, and in the 2.6.13-rc6 akpm prophesies to be coming soon - please all test that. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Getting rid of SHMMAX/SHMALL ?
Andi Kleen wrote on Thursday, August 04, 2005 3:54 PM > > This might be too low on large system. We usually stress shm pretty hard > > for db application and usually use more than 87% of total memory in just > > one shm segment. So I prefer either no limit or a tunable. > > With large system you mean >32GB right? Yes, between 32 GB - 128 GB. On larger numa box in the 256 GB and upward, we have to break shm segment into one per-numa-node and then the limit should be OK. I was concerned with SMP box with large memory. > I think on a large systems some tuning is reasonable because they likely > have trained admins. I'm more worried on reasonable defaults for the > class of systems with 0-4GB Sounds reasonable to me. - Ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Getting rid of SHMMAX/SHMALL ?
Andi Kleen wrote on Thursday, August 04, 2005 6:24 AM > I think we should just get rid of the per process limit and keep > the global limit, but make it auto tuning based on available memory. > That is still not very nice because that would likely keep it < available > memory/2, but I suspect databases usually want more than that. So > I would even make it bigger than tmpfs for reasonably big machines. > Let's say > > if (main memory >= 1GB) > maxmem = main memory - main memory/8 This might be too low on large system. We usually stress shm pretty hard for db application and usually use more than 87% of total memory in just one shm segment. So I prefer either no limit or a tunable. - Ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Getting rid of SHMMAX/SHMALL ?
On Thu, Aug 04, 2005 at 03:49:37PM -0700, Chen, Kenneth W wrote: > Andi Kleen wrote on Thursday, August 04, 2005 6:24 AM > > I think we should just get rid of the per process limit and keep > > the global limit, but make it auto tuning based on available memory. > > That is still not very nice because that would likely keep it < available > > memory/2, but I suspect databases usually want more than that. So > > I would even make it bigger than tmpfs for reasonably big machines. > > Let's say > > > > if (main memory >= 1GB) > > maxmem = main memory - main memory/8 > > This might be too low on large system. We usually stress shm pretty hard > for db application and usually use more than 87% of total memory in just > one shm segment. So I prefer either no limit or a tunable. With large system you mean >32GB right? I think on a large systems some tuning is reasonable because they likely have trained admins. I'm more worried on reasonable defaults for the class of systems with 0-4GB The /8 was to account for the overhead of page tables and mem_map and leave some other memory for the system, but you're right it might be less with hugetlbfs. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: 2.6.13-rc3-mm3
Michael Thonke <[EMAIL PROTECTED]> wrote: > > Moore, Robert schrieb: > > >+ACPI-0287: *** Error: Region SystemMemory(0) has no handler > >+ACPI-0127: *** Error: acpi_load_tables: Could not load namespace: > >AE_NOT_EXIST > >+ACPI-0136: *** Error: acpi_load_tables: Could not load tables: > > > >This looks like a nasty case where some executable code in the table is > >attempting to access a SystemMemory operation region before any OpRegion > >handlers are initialized. > > > >We certainly want to see the output of acpidump to attempt to diagnose > >and/or reproduce the problem. > > > >Bob > > > > > > > > > Sorry for double post. > > With this mail I hand over the acpidump output with the pmtools > Andrew pointed me to. > > And a dmesg output with CONFIG_KALLSYMS=y. > > > I attached them in bz2 format, because of the length. > > I hope we find the problem. > Michael, I'm assuming that a) this problem remains in those -mm kernels which include git-acpi.patch and that b) the problems are not present in 2.6.13-rc5 or 2.6.13-rc6, yes? So I think we have a bug in git-acpi.patch? If that's all correct then can you please test the next -mm (which will include git-acpi.patch - the most recent -mm did not) and if the bug's still there can you raise a bugzilla.kernel.org entry for it? We seem to have a handful of bug reports against the -mm acpi patch. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote: > My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. > 2.6.12 does not show this behaviour. I'm out of town at the moment, could you maybe diff radeonfb between working & non-working and CC me the diff ? I don't have my work stuff at hand not my kernel images so... Thanks, 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: NUMA policy interface
On Thu, Aug 04, 2005 at 03:19:52PM -0700, Christoph Lameter wrote: > This code already exist in the memory hotplug code base and Ray already > had a working implementation for page migration. The migration code will > also be necessary in order to relocate pages with ECC single bit failures > that Russ is working on (of course that will only work for some pages) and > for Mel Gorman's defragmentation approach (if we ever get the split into > differnet types of memory chunks in). Yup, we need page migration for memory hotplug. However, for hotplug we are not too concerned about where the pages are migrated to. Our primary concern is to move them out of the block/section that we want to offline. Suspect this is the same for pages with ECC single bit failures. In fact, this is one possible use of the hotplug code. Notice a failure. Migrate all pages off the containing DIMM. Offline section corresponding to DIMM. Replace the DIMM. Online section corresponding to DIMM. Of course, your hardware needs to be able to do this. -- Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Fw: ati-remote strangeness from 2.6.12 onwards
Ryan Brown <[EMAIL PROTECTED]> wrote: > > Sorry Andrew, but the diff was incorrectly made, the updated patch, > reverts the changes too TV, DVD and OK Button, from 2.6.12-rc1. hm, this was about 20 patches and 300 emails ago and I've forgotten what we're discussing. For poor old scatterbrains it really helps if people can maintain a description of their patch alongside the patch itself. > diff -ruN linux-2.6.12/drivers/usb/input/ati_remote.c > linux-2.6.12-modified/drivers/usb/input/ati_remote.c > --- linux-2.6.12/drivers/usb/input/ati_remote.c 2005-06-18 > 07:48:29.0 +1200 > +++ linux-2.6.12-modified/drivers/usb/input/ati_remote.c 2005-08-03 > 09:54:48.0 +1200 > @@ -252,8 +252,8 @@ > {KIND_FILTERED, 0xdd, 0x18, EV_KEY, KEY_KPENTER, 1},/* "check" */ > {KIND_FILTERED, 0xdb, 0x16, EV_KEY, KEY_MENU, 1}, /* "menu" */ > {KIND_FILTERED, 0xc7, 0x02, EV_KEY, KEY_POWER, 1}, /* Power */ > - {KIND_FILTERED, 0xc8, 0x03, EV_KEY, KEY_TV, 1}, /* TV */ > - {KIND_FILTERED, 0xc9, 0x04, EV_KEY, KEY_DVD, 1},/* DVD */ > + {KIND_FILTERED, 0xc8, 0x03, EV_KEY, KEY_PROG1, 1}, /* TV */ > + {KIND_FILTERED, 0xc9, 0x04, EV_KEY, KEY_PROG2, 1}, /* DVD */ > {KIND_FILTERED, 0xca, 0x05, EV_KEY, KEY_WWW, 1},/* WEB */ > {KIND_FILTERED, 0xcb, 0x06, EV_KEY, KEY_BOOKMARKS, 1}, /* "book" */ > {KIND_FILTERED, 0xcc, 0x07, EV_KEY, KEY_EDIT, 1}, /* "hand" */ > @@ -263,7 +263,7 @@ > {KIND_FILTERED, 0xe4, 0x1f, EV_KEY, KEY_RIGHT, 1}, /* right */ > {KIND_FILTERED, 0xe7, 0x22, EV_KEY, KEY_DOWN, 1}, /* down */ > {KIND_FILTERED, 0xdf, 0x1a, EV_KEY, KEY_UP, 1}, /* up */ > - {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_OK, 1}, /* "OK" */ > + {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_ENTER, 1}, /* "OK" */ > {KIND_FILTERED, 0xce, 0x09, EV_KEY, KEY_VOLUMEDOWN, 1}, /* VOL + */ > {KIND_FILTERED, 0xcd, 0x08, EV_KEY, KEY_VOLUMEUP, 1}, /* VOL - */ > {KIND_FILTERED, 0xcf, 0x0a, EV_KEY, KEY_MUTE, 1}, /* MUTE */ IOW: what does this (wordwrapped!) patch do? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc5-git2 on x86_64 slaughters all processes?
-git1 works fine, but -git2 fails in a strange way. Only on my AMD64 box, the other seem fine. Boots all the way up, then seems to slaughter any userspace process: -- EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 236k freed INIT: version 2.86 booting VM: killing process rcS INIT: Entering runlevel: 2 VM: killing process rc VM: killing process getty VM: killing process getty VM: killing process getty VM: killing process getty VM: killing process getty VM: killing process getty VM: killing process getty Debian GNU/Linux 3.1 (none) ttyS0 (none) login: -- 0:conmux-control -- time-stamp -- Aug/04/05 2:57:24 -- - full bootlog for -git2 is here: http://test.kernel.org/9966/debug/console.log -git1's bootlog looks like this: http://test.kernel.org/9804/debug/console.log tail is: - Freeing unused kernel memory: 236k freed input: PS/2 Logitech Mouse on isa0060/serio1 INIT: version 2.86 booting Activating swap. Adding 12104968k swap on /dev/sdb3. Priority:-1 extents:1 Checking root file system... fsck 1.35 (28-Feb-2004) e2fsck 1.35 (28-Feb-2004) /dev/shm/root: clean, 268023/977280 files, 1467207/19EXT3 FS on sda1, 53897 blocks internal journal System time was Wed Aug 3 09:56:18 UTC 2005. Setting the System Clock using the Hardware Clock as reference... System Clock set. System local time is now Wed Aug 3 09:56:20 UTC 2005. Calculating module dependencies... done. Loading modules... sd_mod FATAL: Module sd_mod not found. ide-cd FATAL: Module ide_cd not found. ide-detect FATAL: Module ide_detect not found. All modules loaded. Checking all file systems... fsck 1.35 (28-Feb-2004) Setting kernel variables ... ... done. Mounting local filesystems... Cleaning /tmp /var/run /var/lock. Running 0dns-down to make sure resolv.conf is ok...done. Cleaning: /etc/network/ifstate. Kernel hotplug support not enabled. Setting up IP spoofing protection: rp_filter. Configuring network interfaces...done. Starting portmap daemon: portmap. Loading the saved-state of the serial devices... /dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A Setting the System Clock using the Hardware Clock as reference... System Clock set. Local time: Wed Aug 3 02:56:22 PDT 2005 Running ntpdate to synchronize clocktg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is off for TX and off for RX. . Initializing random number generator...done. Recovering nvi editor sessions... done. Setting up X server socket directory /tmp/.X11-unix...done. Setting up ICE socket directory /tmp/.ICE-unix...done. INIT: Entering runlevel: 2 Starting system log daemon: syslogd. Starting kernel log daemon: klogd. Starting portmap daemon: portmap. Starting MTA: exim4. Starting file alteration monitor: FAM. Starting internet superserver: inetd. Starting printer spooler: lpd . Starting OpenBSD Secure Shell server: sshd. Setting up X font server socket directory /tmp/.font-unix...done. Starting X font server: xfs. Starting Xprint servers: Xprt. Starting NFS common utilities: statd. Starting NTP server: ntpd. Starting deferred execution scheduler: atd. Starting periodic command scheduler: cron. Starting GNOME Display Manager: gdm. Starting staf: staf. Not starting X display manager (xdm); it is not the default display manager. XFree86: vm86 mode not supported on 64 bit kernel mtrr: type mismatch for e500,40 old: write-back new: write-combining Debian GNU/Linux 3.1 elm3b6 ttyS0 elm3b6 login: -- 0:conmux-control -- time-stamp -- Aug/03/05 2:58:57 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc6-mm1
On Friday 05 August 2005 00:28, Andrew Morton wrote: > Andrew Morton <[EMAIL PROTECTED]> wrote: > > Dominik Karall <[EMAIL PROTECTED]> wrote: > > > On Friday 29 July 2005 23:27, Andrew Morton wrote: > > > > Dominik Karall <[EMAIL PROTECTED]> wrote: > > > > > On Friday 29 July 2005 20:22, Andrew Morton wrote: > > > > > > Dominik Karall <[EMAIL PROTECTED]> wrote: > > > > > > > On Friday 29 July 2005 06:54, Andrew Morton wrote: > > > > > > > > Dominik Karall <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Tuesday 07 June 2005 13:29, Andrew Morton wrote: > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches > > > > > > > > > >/2.6/2 .6.1 2-rc 6/2. 6.12-rc6-mm1/ > > > > > > > > > > > > > > > > > > After looking in my dmesg output today, I saw following > > > > > > > > > error with 2.6.12-rc6-mm1, maybe it's usefull to you. I > > > > > > > > > don't know when it exactly happens, cause I never used mono > > > > > > > > > last time, I just did an emerge mono on my gentoo system, > > > > > > > > > maybe this forced the failure. > > > > > > > > > > > > > > > > > > note: mono[26736] exited with preempt_count 1 > > > > > > > > > scheduling while atomic: mono/0x1001/26736 > > > > > > > > > > > > > > > > > > Call Trace:{schedule+122} > > > > > > > > > {vprintk+635} > > > > > > > > > {cond_resched+56} > > > > > > > > > {unmap_vmas+1587} > > > > > > > > > {exit_mmap+128} > > > > > > > > > {mmput+31} > > > > > > > > > {do_exit+438} > > > > > > > > > {__dequeue_signal+501} > > > > > > > > >{do_group_exit+280} > > > > > > > > > {get_signal_to_deliver+1575} > > > > > > > > >{do_signal+162} > > > > > > > > > {default_wake_function+0} > > > > > > > > >{sys_rt_sigreturn+577} > > > > > > > > > {sysret_signal+28} > > > > > > > > >{ptregscall_common+103} > > > > > > > > > > > > > > > > A couple of people reported this, but all seems to have gone > > > > > > > > quiet. Is it fixed in later -mm's? Is 2.6.13-rc4 running > > > > > > > > OK? > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > hi andrew! > > > > > > > > > > > > > > I'm sorry, but it's not fixed in current 2.6.13-rc3-mm3. I did > > > > > > > an emerge mono right now to test it, and I got this one: > > > > > > > Jul 29 15:26:37 [kernel] note: mono[11138] exited with > > > > > > > preempt_count 1 Jul 29 15:26:50 [kernel] file[14627]: segfault > > > > > > > at 2b453000 rip 2af652cf rsp 7fe43b50 > > > > > > > error 4 > > > > > > > Jul 29 15:26:50 [kernel] file[14633]: segfault at > > > > > > > 2b453000 rip 2af652cf rsp 7fcc87a0 > > > > > > > error 4 > > > > > > > Jul 29 15:26:51 [kernel] file[14669]: segfault at > > > > > > > 2b453000 rip 2af652cf rsp 7f905f80 > > > > > > > error 4 > > > > > > > > > > > > > > DEBUG_KERNEL/ PREEMPT/ SPINLOCK are enabled, but I didn't get > > > > > > > more info about the bug. Did I forget any debug option? > > > > > > > > > > > > Gee, I don't know how to find this one. Do you know if the > > > > > > problem is specific to -mm? > > > > > > > > > > Tested with 2.6.13-rc4 and it seems to work. Didn't get any error. > > > > > > > > Great, thanks for that. > > > > > > > > > So it seems to be -mm related. Do you suspect any patch which could > > > > > cause the error? > > > > > > > > I wouldn't know, sorry. Possible the scheduler patches, possibly an > > > > x86_64-specific patch. Is the problem repeatable? If so, a binary > > > > search would only take ten build-n-boots ;) > > > > > > Yes, it is repeatable. I tested on lastest -mm about 4 times. Ok, I > > > will try to find the right patch tomorrow, 10 build-n-boots would end > > > up in morning ;) > > > > > > btw, as the error occured in 2.6.12-rc6-mm1 too, it must be an old > > > patch which wasn't merged to linus tree till now...hope there aren't a > > > lot of them :) > > > > Any progress on this? It kinda measn that the whole of the -mm lineup is > > stuck until we can identify the offending patch. We have a couple of > > weeks in which to do this but if you can identify the bad patch it'd help > > enormously, thanks. > > OK, Bartosz Taudul tells me that he's occasionally seeing this on stock > 2.6.12 (thanks!). So there's not a lot of point in doing the -mm bisection > search. > > I think Ingo was planning on coming up with some infrastructure which would > allow us to debug this further. I'm sorry that I couldn't do the tests earlier, but I had no time this week. I did some tests now and noticed that the bug only occures when kde is running...weird. I'm going to continue testing tomorrow after work, exactly in 12 hours ;) I will let you know if I have any news! dominik pgpvYfWXRWZH1.pgp Description: PGP signature
Re: [PATCH] Re: 2.6.12: itimer_real timers don't survive execve() any more
That's wrong. It has to be done only by the last thread in the group to go. Just revert Ingo's change. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][PPP] ppp_generic: Add checks for NULL pointers
Hmamouche, Youssef writes: > This patch adds two checks for NULL pointers. OK, but get the whitespace right please - use tabs not spaces for indentation, and put a space between "if" and "(". See Documentation/CodingStyle. 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: [patch] fix ACPI table discovery from EFI for x86
Bjorn Helgaas <> wrote: > On Wednesday 13 July 2005 7:09 pm, Matt Tolentino wrote: >> This patch addresses a problem on x86 EFI systems with larger memory >> configurations. Up until now, we've relied on the fact that the >> ACPI RSDT would reside somewhere in low memory that could be >> permanently >> mapped in kernel address space - so __va() has been sufficient. >> However, >> on EFI systems, the RSDT is often anywhere in the lower 4GB of >> physical >> address space. So, we may need to remap it on x86 systems. > > The hunk below breaks HP rx7620, rx8620, and Superdome (all ia64) > systems. This is from 2.6.13-rc4-mm1, in Ugh. Well, that's pretty ugly... Andrew, Len, please drop this one until I look at this closer. > acpi-fix-table-discovery-from-efi-for-x86.patch Thanks for testing Bjorn. matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: NUMA policy interface
On Thu, 4 Aug 2005, Andi Kleen wrote: > > There is this scan over the page table that verifies if all nodes are > > allocated according to the policy. That scan could easily be used to > > provide a map to the application (and to /proc//smap) of where the > > The application can already get it. But it's an ugly feature > that I only used for debugging and I was actually considering > to remove it. > > Doing it for external users is a completely different thing though. > I still think those have business in messing with other people's > virtual addresses. In addition I expect it will cause problems > longer term > (did you ever look why mmap on /proc/*/mem is not allowed - it used > to be long ago, but it was impossible to make it work race free and > before that was always a gapping security hole) The proc stuff is fake anyways. I would not worry about that. The biggest worry is the locking mechanism to make this clean. There are three possibilites: 1. do what cpusets is doing by versioning. 2. Have the task notifier access the task_struct information. See http://lwn.net/Articles/145232/ "A new path to the refrigerator" 3. Maybe the easiest: Require mmap_sem to be taken for all policy accesses. Currently its only require for vma policies. Then we need to make a copy of the policy at some point so that alloc_pages can access policy information lock free. This may also allow us to fix the bind issue if we would f.e. keep a bitmap in the taskstruct or (ab)use the cpusets map. > If they cannot afford enough disk space it might be possible > to do the page migration in swap cache like Hugh proposed. This code already exist in the memory hotplug code base and Ray already had a working implementation for page migration. The migration code will also be necessary in order to relocate pages with ECC single bit failures that Russ is working on (of course that will only work for some pages) and for Mel Gorman's defragmentation approach (if we ever get the split into differnet types of memory chunks in). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc6-mm1
Andrew Morton <[EMAIL PROTECTED]> wrote: > > Dominik Karall <[EMAIL PROTECTED]> wrote: > > > > On Friday 29 July 2005 23:27, Andrew Morton wrote: > > > Dominik Karall <[EMAIL PROTECTED]> wrote: > > > > On Friday 29 July 2005 20:22, Andrew Morton wrote: > > > > > Dominik Karall <[EMAIL PROTECTED]> wrote: > > > > > > On Friday 29 July 2005 06:54, Andrew Morton wrote: > > > > > > > Dominik Karall <[EMAIL PROTECTED]> wrote: > > > > > > > > On Tuesday 07 June 2005 13:29, Andrew Morton wrote: > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2 > > > > > > > > >.6.1 2-rc 6/2. 6.12-rc6-mm1/ > > > > > > > > > > > > > > > > After looking in my dmesg output today, I saw following error > > > > > > > > with 2.6.12-rc6-mm1, maybe it's usefull to you. I don't know > > > > > > > > when > > > > > > > > it exactly happens, cause I never used mono last time, I just > > > > > > > > did > > > > > > > > an emerge mono on my gentoo system, maybe this forced the > > > > > > > > failure. > > > > > > > > > > > > > > > > note: mono[26736] exited with preempt_count 1 > > > > > > > > scheduling while atomic: mono/0x1001/26736 > > > > > > > > > > > > > > > > Call Trace:{schedule+122} > > > > > > > > {vprintk+635} > > > > > > > > {cond_resched+56} > > > > > > > > {unmap_vmas+1587} > > > > > > > > {exit_mmap+128} {mmput+31} > > > > > > > > {do_exit+438} > > > > > > > > {__dequeue_signal+501} > > > > > > > >{do_group_exit+280} > > > > > > > > {get_signal_to_deliver+1575} > > > > > > > >{do_signal+162} > > > > > > > > {default_wake_function+0} > > > > > > > >{sys_rt_sigreturn+577} > > > > > > > > {sysret_signal+28} > > > > > > > >{ptregscall_common+103} > > > > > > > > > > > > > > A couple of people reported this, but all seems to have gone > > > > > > > quiet. > > > > > > > Is it fixed in later -mm's? Is 2.6.13-rc4 running OK? > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > hi andrew! > > > > > > > > > > > > I'm sorry, but it's not fixed in current 2.6.13-rc3-mm3. I did an > > > > > > emerge mono right now to test it, and I got this one: > > > > > > Jul 29 15:26:37 [kernel] note: mono[11138] exited with preempt_count > > > > > > 1 Jul 29 15:26:50 [kernel] file[14627]: segfault at 2b453000 > > > > > > rip 2af652cf rsp 7fe43b50 error 4 > > > > > > Jul 29 15:26:50 [kernel] file[14633]: segfault at 2b453000 > > > > > > rip 2af652cf rsp 7fcc87a0 error 4 > > > > > > Jul 29 15:26:51 [kernel] file[14669]: segfault at 2b453000 > > > > > > rip 2af652cf rsp 7f905f80 error 4 > > > > > > > > > > > > DEBUG_KERNEL/ PREEMPT/ SPINLOCK are enabled, but I didn't get more > > > > > > info about the bug. Did I forget any debug option? > > > > > > > > > > Gee, I don't know how to find this one. Do you know if the problem is > > > > > specific to -mm? > > > > > > > > Tested with 2.6.13-rc4 and it seems to work. Didn't get any error. > > > > > > Great, thanks for that. > > > > > > > So it seems to be -mm related. Do you suspect any patch which could > > > > cause > > > > the error? > > > > > > I wouldn't know, sorry. Possible the scheduler patches, possibly an > > > x86_64-specific patch. Is the problem repeatable? If so, a binary search > > > would only take ten build-n-boots ;) > > > > Yes, it is repeatable. I tested on lastest -mm about 4 times. Ok, I will > > try > > to find the right patch tomorrow, 10 build-n-boots would end up in morning > > ;) > > > > btw, as the error occured in 2.6.12-rc6-mm1 too, it must be an old patch > > which > > wasn't merged to linus tree till now...hope there aren't a lot of them :) > > > > Any progress on this? It kinda measn that the whole of the -mm lineup is > stuck until we can identify the offending patch. We have a couple of weeks > in which to do this but if you can identify the bad patch it'd help > enormously, thanks. > OK, Bartosz Taudul tells me that he's occasionally seeing this on stock 2.6.12 (thanks!). So there's not a lot of point in doing the -mm bisection search. I think Ingo was planning on coming up with some infrastructure which would allow us to debug this further. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Fw: ati-remote strangeness from 2.6.12 onwards
Sorry Andrew, but the diff was incorrectly made, the updated patch, reverts the changes too TV, DVD and OK Button, from 2.6.12-rc1. diff -ruN linux-2.6.12/drivers/usb/input/ati_remote.c linux-2.6.12-modified/drivers/usb/input/ati_remote.c --- linux-2.6.12/drivers/usb/input/ati_remote.c 2005-06-18 07:48:29.0 +1200 +++ linux-2.6.12-modified/drivers/usb/input/ati_remote.c2005-08-03 09:54:48.0 +1200 @@ -252,8 +252,8 @@ {KIND_FILTERED, 0xdd, 0x18, EV_KEY, KEY_KPENTER, 1},/* "check" */ {KIND_FILTERED, 0xdb, 0x16, EV_KEY, KEY_MENU, 1}, /* "menu" */ {KIND_FILTERED, 0xc7, 0x02, EV_KEY, KEY_POWER, 1}, /* Power */ - {KIND_FILTERED, 0xc8, 0x03, EV_KEY, KEY_TV, 1}, /* TV */ - {KIND_FILTERED, 0xc9, 0x04, EV_KEY, KEY_DVD, 1},/* DVD */ + {KIND_FILTERED, 0xc8, 0x03, EV_KEY, KEY_PROG1, 1}, /* TV */ + {KIND_FILTERED, 0xc9, 0x04, EV_KEY, KEY_PROG2, 1}, /* DVD */ {KIND_FILTERED, 0xca, 0x05, EV_KEY, KEY_WWW, 1},/* WEB */ {KIND_FILTERED, 0xcb, 0x06, EV_KEY, KEY_BOOKMARKS, 1}, /* "book" */ {KIND_FILTERED, 0xcc, 0x07, EV_KEY, KEY_EDIT, 1}, /* "hand" */ @@ -263,7 +263,7 @@ {KIND_FILTERED, 0xe4, 0x1f, EV_KEY, KEY_RIGHT, 1}, /* right */ {KIND_FILTERED, 0xe7, 0x22, EV_KEY, KEY_DOWN, 1}, /* down */ {KIND_FILTERED, 0xdf, 0x1a, EV_KEY, KEY_UP, 1}, /* up */ - {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_OK, 1}, /* "OK" */ + {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_ENTER, 1}, /* "OK" */ {KIND_FILTERED, 0xce, 0x09, EV_KEY, KEY_VOLUMEDOWN, 1}, /* VOL + */ {KIND_FILTERED, 0xcd, 0x08, EV_KEY, KEY_VOLUMEUP, 1}, /* VOL - */ {KIND_FILTERED, 0xcf, 0x0a, EV_KEY, KEY_MUTE, 1}, /* MUTE */ On 8/5/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > mdew <[EMAIL PROTECTED]> wrote: > > > > I discovered a minor change in 2.6.10-mm1, changing this value back > > corrects the "ok" button issue. > > > > > > diff -urN linux/drivers/usb/input/ati_remote.c > > linux-2.6.11/drivers/usb/input/ati_remote.c > > --- linux/drivers/usb/input/ati_remote.c2005-08-02 > > 17:56:26.0 +1200 > > +++ linux-2.6.11/drivers/usb/input/ati_remote.c 2005-08-02 > > 17:54:34.0 +1200 > > @@ -263,7 +263,7 @@ > > {KIND_FILTERED, 0xe4, 0x1f, EV_KEY, KEY_RIGHT, 1}, /* right */ > > {KIND_FILTERED, 0xe7, 0x22, EV_KEY, KEY_DOWN, 1}, /* down */ > > {KIND_FILTERED, 0xdf, 0x1a, EV_KEY, KEY_UP, 1}, /* up */ > > - {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_ENTER, 1}, /* "OK" */ > > + {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_OK, 1}, /* "OK" */ > > {KIND_FILTERED, 0xce, 0x09, EV_KEY, KEY_VOLUMEDOWN, 1}, /* VOL + */ > > {KIND_FILTERED, 0xcd, 0x08, EV_KEY, KEY_VOLUMEUP, 1}, /* VOL - */ > > {KIND_FILTERED, 0xcf, 0x0a, EV_KEY, KEY_MUTE, 1}, /* MUTE */ > > This appears to be already applied in 2.6.12-rc5. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Old api files, rewrite or delete?
Adrian Bunk napsal(a): On Thu, Aug 04, 2005 at 02:00:05PM +0200, Jiri Slaby wrote: There might be users for many of the listed drivers - even if there are only very few. And what do you really gain by removing drivers? Nothing, I don't only want to rewrite driver, which others do not use. -- Jiri Slaby www.fi.muni.cz/~xslaby ~\-/~ [EMAIL PROTECTED] ~\-/~ 241B347EC88228DE51EE A49C4A73A25004CB2A10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Wed, 3 Aug 2005 15:59:24 +1000 Con Kolivas <[EMAIL PROTECTED]> wrote: > This is the dynamic ticks patch for i386 as written by Tony Lindgen > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>. > Patch for 2.6.13-rc5 One issue (tested the -rc4 Version on -mm): - on interrupt flood (ping -f) HZ goes down to 0-4 HZ. This matches "ticks to skip" below. Coincidence? - ping -f complains: .Warning: time of day goes back (-304us), taking countermeasures. ... .Warning: time of day goes back (-33us), taking countermeasures. Yet, system time _seems_ to be kept correctly. CPU is Pentium M. dmesg: Using pmtmr for high-res timesource dyn-tick: Found suitable timer: pmtmr dyn-tick: Maximum ticks to skip limited to 54 dyn-tick: Timer not enabled during boot sysfs: suitable: 1 enabled:1 using APIC: 0 Regards - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/23] reboot-fixes
Hi. On Fri, 2005-08-05 at 07:45, Pavel Machek wrote: > Hi! > > > > > > > Good question. I'm not certain if Pavel intended to add > > > > > > device_suspend(PMSG_FREEZE) to the reboot path. It was > > > > > > there in only one instance. Pavel comments talk only about > > > > > > the suspend path. > > > > > > > > > > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path. > > > > > > > > Why? > > > > > > Many bioses are broken; if you leave hardware active during reboot, > > > they'll hang during reboot. It is so common problem that I think that > > > only sane solution is make hardware quiet before reboot. > > > > Sorry for my slow reply. > > > > If I remember correctly PMSG_FREEZE was intended solely for stopping > > activity when suspend to disk implementations are about to do their > > Well, I think that PMSG_FREEZE can be handy when we want to stop > activity for other reasons, too... > > > atomic copies. I thought that ide reacts to this message by putting a > > hold on queues, but doesn't otherwise do anything to prepare a drive for > > a restart. If that's true, using FREEZE here isn't going to stop drives > > from doing their emergency shutdown actions. Don't we need PMSG_SUSPEND > > instead? > > Spinning disk down is not neccessary for reboot. Users will be angry > if we do it before reboot... Yes, but I understood (perhaps wrongly) that we were discussing the shutdown path. Nevertheless, for rebooting, you don't want to simply freeze the queue - you want to flush the queue and tell the drive to flush too. For freeze, you may well flush the queue, but you might not necessarily force the drive to flush its queue too. Regards, Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc5-git2 does not boot on (my) amd64
[EMAIL PROTECTED] (Danny ter Haar) writes: > This is as far as it comes: > > > Freeing unused kernel memory: 248k freed > VM: killing process hotplug > VM: killing process hotplug > VM: killing process hotplug > VM: killing process hotplug > Unable to handle kernel paging request at fff28017b5be RIP: > [] Looks weird. Just to make sure can you do a make distclean and try again? It might be a bad compile. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 2.6.12: itimer_real timers don't survive execve() any more
Andrew Morton wrote: Roland McGrath <[EMAIL PROTECTED]> wrote: That's wrong. It has to be done only by the last thread in the group to go. Just revert Ingo's change. Hm... I was looking at 2.6.10 to figure it out. This looks more correct. OK.. --- 25/kernel/exit.c~revert-timer-exit-cleanup Thu Aug 4 15:00:55 2005 +++ 25-akpm/kernel/exit.c Thu Aug 4 15:01:06 2005 @@ -829,8 +829,10 @@ fastcall NORET_TYPE void do_exit(long co acct_update_integrals(tsk); update_mem_hiwater(tsk); group_dead = atomic_dec_and_test(&tsk->signal->live); - if (group_dead) + if (group_dead) { + del_timer_sync(&tsk->signal->real_timer); acct_process(code); + } exit_mm(tsk); exit_sem(tsk); diff -puN kernel/posix-timers.c~revert-timer-exit-cleanup kernel/posix-timers.c --- 25/kernel/posix-timers.c~revert-timer-exit-cleanup Thu Aug 4 15:00:55 2005 +++ 25-akpm/kernel/posix-timers.c Thu Aug 4 15:01:06 2005 @@ -1166,7 +1166,6 @@ void exit_itimers(struct signal_struct * tmr = list_entry(sig->posix_timers.next, struct k_itimer, list); itimer_delete(tmr); } - del_timer_sync(&sig->real_timer); } /* _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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/
Documentation/ioctl-mess.txt and ida_ioctl() review (was Re: [PATCH 2/3] cpqarray: ioctl support to configure LUNs dynamically)
On Thu, Aug 04, 2005 at 10:15:29AM +0530, Saripalli, Venkata Ramanamurthy (STSD) wrote: > Patch 2 of 3 > This patch adds support for IDAREGNEWDISK, IDADEREGDISK, IDAGETLOGINFO > ioctls required > to configure LUNs dynamically on SA4200 controller using ACU. drivers/block/cpqarray.c: 1131 static int ida_ioctl(struct inode *inode, struct file *filep, unsigned int cmd, unsigned long arg) 1132 { 1133 drv_info_t *drv = get_drv(inode->i_bdev->bd_disk); 1134 ctlr_info_t *host = get_host(inode->i_bdev->bd_disk); 1135 int error; 1136 int diskinfo[4]; Hmm... diskinfo[3] seems to be enough. 1137 struct hd_geometry __user *geo = (struct hd_geometry __user *)arg; 1138 ida_ioctl_t __user *io = (ida_ioctl_t __user *)arg; 1139 ida_ioctl_t *my_io; 1140 1141 switch(cmd) { 1142 case HDIO_GETGEO: 1143 if (drv->cylinders) { 1144 diskinfo[0] = drv->heads; 1145 diskinfo[1] = drv->sectors; 1146 diskinfo[2] = drv->cylinders; 1147 } else { 1148 diskinfo[0] = 0xff; 1149 diskinfo[1] = 0x3f; 1150 diskinfo[2] = drv->nr_blks / (0xff*0x3f); 1151 } 1152 put_user(diskinfo[0], &geo->heads); 1153 put_user(diskinfo[1], &geo->sectors); 1154 put_user(diskinfo[2], &geo->cylinders); 1155 put_user(get_start_sect(inode->i_bdev), &geo->start); Mental note: export drv->heads, drv->sectors, drv->cylinders and inode->i_bdev->bd_part->start_sect to userspace (with possible tweaking). 1156 return 0; 1157 case IDAGETDRVINFO: 1158 if (copy_to_user(&io->c.drv, drv, sizeof(drv_info_t))) What does drv_info_t contain? From drivers/block/cpqarray.h: 47 typedef struct { 48 unsigned blk_size; 49 unsigned nr_blks; 50 unsigned cylinders; 51 unsigned heads; 52 unsigned sectors; 53 int usage_count; 54 } drv_info_t; Great... Same heads, sectors, cylinders we can already export. Without magic "if (!drv->cylinders)". With extra crap for free: "usage_count". Why should userspace know about reference count of drive? This is not even funny... $ grep usage_count -w -r . | grep cpq ./drivers/block/cpqarray.c: host->usage_count++; ./drivers/block/cpqarray.c: host->usage_count--; ./drivers/block/cpqarray.c: if (host->usage_count > 1) { ./drivers/block/cpqarray.c: " revalidation (usage=%d)\n", host->usage_count); ./drivers/block/cpqarray.c: host->usage_count++; ./drivers/block/cpqarray.c: host->usage_count--; ./drivers/block/cpqarray.h: int usage_count; ./drivers/block/cpqarray.h: int usage_count; where the type of "host" is "struct ctlr_info", NOT drv_info_t. 1159 return -EFAULT; 1160 return 0; 1161 case IDAPASSTHRU: 1162 if (!capable(CAP_SYS_RAWIO)) 1163 return -EPERM; 1164 my_io = kmalloc(sizeof(ida_ioctl_t), GFP_KERNEL); 1165 if (!my_io) 1166 return -ENOMEM; 1167 error = -EFAULT; 1168 if (copy_from_user(my_io, io, sizeof(*my_io))) 1169 goto out_passthru; 1170 error = ida_ctlr_ioctl(host, drv - host->drv, my_io); 1171 if (error) 1172 goto out_passthru; 1173 error = -EFAULT; 1174 if (copy_to_user(io, my_io, sizeof(*my_io))) 1175 goto out_passthru; 1176 error = 0; 1177 out_passthru: 1178 kfree(my_io); 1179 return error; 1180 case IDAGETCTLRSIG: 1181 if (!arg) return -EINVAL; 1182 put_user(host->ctlr_sig, (int __user *)arg); 1183 return 0; 1184 case IDAREVALIDATEVOLS: 1185 if (iminor(inode) != 0) 1186 return -ENXIO; 1187 return revalidate_allvol(host); 1188 case IDADRIVERVERSION: 1189 if (!arg) return -EINVAL; 1190 put_user(DRIVER_VERSION, (unsigned long __user *)arg); 1191 return 0; Why should userspace know anything about module version? 1192 case IDAGETPCIINFO: 1193 { 1194 1195 ida_pci_info_struct pciinfo; 1196 1197 if (!arg) return -EINVAL; 1198 pciinfo.bus = host->pci_dev->bus->number; 1199 pciinfo.dev_fn = host->pci_dev->devfn; 1200