Re: [PATCH 4/9] Vmi fix highpte
Jeremy Fitzhardinge wrote: I can deal with the change going into -git, but it does seem awkward knowing that it is the wrong change and it will be replaced by something else almost immediately. Well, it is not quite wrong - it is appropriate for -git. That it will be replaced soon is a minor thing, as long as we can work together to make sure your patches are unaffected. My main concern is that the Xen patch queue is complex enough as-is, and I've been trying hard to remove dependencies on other uncommitted patches. It's doubly complex because I'm not really sure if I'm targeting Andrew or Andi's tree as a base, though at the moment -git seems to work either way. J Believe me, I understand the complexities of dealing with -mm, -git, and -i386 trees. It's not just doubly complex, its triply so. I believe the best approach is to make it easiest on the maintainers. So the patch stream I am uploading through -mm, -i386, to -git does not conflict with the Xen patch queue as long as we make sure the next bundle to those same trees applies clean. Again, I broke the Xen patch queue in -mm, and for that I am sorry. I will help you re-integrate against the VMI patches I sent out, as I broke your code, I will help fix it. And we both have a tree to work off from, which makes it rather easy to work together ;) Cheers, Zach Sutra I.2 - interruptah chittavritti nirodhah - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/9] 2.6.19-stable review
On Fri, Mar 02, 2007 at 08:48:54PM -0500, Michael Krufky wrote: > > The dvbdev patch is pretty important, fixes a horrible problem, although the > case for > it to occur is rare. The other two patches are of the "obviously correct - > minimal change" > type. > > If it isnt too much trouble, then yes, it is worth it to push a new release > because of the > dvbdev patch. > > However, please chop the "backported from" and "cherry picked from" lines > from those patches. > I cherry-picked them from Mauro's tree, but he wiped it out and re-pushed > those changes in > before Linus merged them so, the actual changesets in Linus' tree have > different hashes. > > (i removed those old hashes from the patches that I posted on linuxtv.org) I picked up the new patches and did a new release. > As for the 2.6.20.y patches, should I email those to you inline or can you > just grab them from > the linuxtv.org www server? ( http://linuxtv.org/~mkrufky/stable/2.6.20.y/ ) Email is usually better, as that's what my scripts are set up to handle. 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/
Re: dynamic linking files slow fork down significantly
David Lang a écrit : I have a fork-heavy workload (a proxy that forks per connection, I know it's not the most efficiant design) and I discovered a 2x performance difference between a static and dynamicly linked version of the same program (2200 connections/sec vs 4700 connections/sec) I know that there is overhead on program startup, but didn't expect to find it on a fork with no exec. If I has been asked I would have guessed that the static version would have been slower due to the need to mark more memory as COW. what is it that costs so much with dynamic libraries on a fork/clone? man ld.so LD_BIND_NOW If set to non-empty string, causes the dynamic linker to resolve all symbols at program startup instead of deferring function call resolval to the point when they are first referenced. If you do : export LD_BIND_NOW=1 before starting your dynamicaly linked version, do you get different numbers ? If some symbols are resolved dynamically after your forks(), the dynamic linker has to dirty some parts of memory and each child gets its own copy of modified pages. The cpu cost is not factorized, and memory needs are larger, so cpu caches are less efficient. With LD_BIND_NOW=1, the initial exec of your programm will be a litle bit longer, but in the end you win. You may see effect of immediate binding with ldd command : Its -r option asks to do the full binding : # time ldd ./groff libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xf7ea) libm.so.6 => /lib/tls/libm.so.6 (0xf7e7e000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7e73000) libc.so.6 => /lib/tls/libc.so.6 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xf7f5d000) 0.00user 0.00system 0:00.00elapsed 80%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+696minor)pagefaults 0swaps # time ldd -r ./groff libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xf7e8f000) libm.so.6 => /lib/tls/libm.so.6 (0xf7e6d000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7e62000) libc.so.6 => /lib/tls/libc.so.6 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xf7f4c000) 0.00user 0.00system 0:00.00elapsed 50%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+777minor)pagefaults 0swaps You can see 777 pagefaults instead of 696 on this example. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 4/9] Vmi fix highpte
Zachary Amsden wrote: > Yes, but the hook point now happens before the page table mapping. Did you change that since you posted the patch? Sounds like a larger change than the one I'm proposing. > Not that it should cause a problem. But we've been testing things > the original way for over a year now, and if we want to get the fix > upstream for 2.6.21, it seems better to upstream a more tested fix > rather than a new way of doing things, even if it is identical in theory. Sure. > That said, I have no problems with the approach you propose going > forward. I just don't think it is appropriate for an -rc release, > because it provides no tangible benefit for any of the in-kernel code, > and causes a lot of retesting. I still believe there is almost zero > risk to doing things the way you propose. But I am also a firm > believer in shipping what is tested and working unless there is a > compelling reason to do otherwise. And if Xen is not going to be in > 2.6.21, the compelling reason becomes getting the code working for > both of us for 2.6.22 - so let's do that, and keep the patches from > Andrew's -mm tree around to make sure that we have a suitable patch > base that can be applied to 2.6.21 for any distros that are willing to > pick up the Xen paravirt-ops. > > Sound reasonable? I can deal with the change going into -git, but it does seem awkward knowing that it is the wrong change and it will be replaced by something else almost immediately. My main concern is that the Xen patch queue is complex enough as-is, and I've been trying hard to remove dependencies on other uncommitted patches. It's doubly complex because I'm not really sure if I'm targeting Andrew or Andi's tree as a base, though at the moment -git seems to work either way. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc2-mm1 - build error with CONFIG_NO_HZ=y and CONFIG_SMP=n
On Fri, 2007-03-02 at 03:00 -0800, Andrew Morton wrote: I get this with CONFIG_NO_HZ=y, CONFIG_SMP=n kernel/sched.c: In function ‘trigger_load_balance’: kernel/sched.c:3384: error: ‘struct rq’ has no member named ‘in_nohz_recently’ kernel/sched.c:3384: error: ‘struct rq’ has no member named ‘idle_at_tick’ kernel/sched.c:3385: error: ‘struct rq’ has no member named ‘in_nohz_recently’ kernel/sched.c:3387: error: ‘nohz’ undeclared (first use in this function) kernel/sched.c:3387: error: (Each undeclared identifier is reported only once kernel/sched.c:3387: error: for each function it appears in.) kernel/sched.c:3404: warning: implicit declaration of function ‘resched_cpu’ kernel/sched.c:3412: error: ‘struct rq’ has no member named ‘idle_at_tick’ kernel/sched.c:3422: error: ‘struct rq’ has no member named ‘idle_at_tick’ make[1]: *** [kernel/sched.o] Error 1 make: *** [kernel] Error 2 Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usbserial not working/oops on removal
Am Samstag, den 03.03.2007, 07:45 +0100 schrieb Oliver Neukum: > Am Samstag, 3. März 2007 03:37 schrieb Kevin Fenzi: > > I'm seeing some oddity with the latest fedora development kernel and a > > usbserial device. > > Very interesting. Is this repeatable? Does unplugging have the same effect? I see it also on fedora rawhide using reinersct (cyberjack) scard readers and it repeatable. The first usbserial devices likes to register the line number 255 which indeed is invalid. 2.6.20-1.2953.fc7: usbcore: registered new interface driver usbserial drivers/usb/serial/usb-serial.c: USB Serial support registered for generic parport0: Printer, Hewlett-Packard HP LaserJet 6L usbcore: registered new interface driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registered for Reiner SCT Cyberjack USB card reader cyberjack 5-2.2:1.0: Reiner SCT Cyberjack USB card reader converter detected Attempt to register invalid tty line number (255). usb 5-2.2: Reiner SCT Cyberjack USB card reader converter now attached to ttyUSB255 cyberjack 5-2.3:1.0: Reiner SCT Cyberjack USB card reader converter detected usb-serial ttyUSB255: Error registering port device, continuing usbcore: registered new interface driver cyberjack drivers/usb/serial/cyberjack.c: v1.01 Matthias Bruestle drivers/usb/serial/cyberjack.c: REINER SCT cyberJack pinpad/e-com USB Chipcard Reader Driver Last rawhide kernel which was working for me is kernel-2.6.20-1.2925.fc7.x86_64 2.6.20-1.2925.fc7: usbcore: registered new interface driver usbserial drivers/usb/serial/usb-serial.c: USB Serial support registered for generic usbcore: registered new interface driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver core input: PC Speaker as /class/input/input2 ata_piix :00:1f.1: version 2.00ac7 ACPI: PCI Interrupt :00:1f.1[A] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device :00:1f.1 to 64 ata7: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14 ata8: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 scsi6 : ata_piix drivers/usb/serial/usb-serial.c: USB Serial support registered for Reiner SCT Cyberjack USB card reader cyberjack 4-1:1.0: Reiner SCT Cyberjack USB card reader converter detected usb 4-1: Reiner SCT Cyberjack USB card reader converter now attached to ttyUSB0 cyberjack 4-2:1.0: Reiner SCT Cyberjack USB card reader converter detected usb 4-2: Reiner SCT Cyberjack USB card reader converter now attached to ttyUSB1 cyberjack 5-4.1.2:1.0: Reiner SCT Cyberjack USB card reader converter detected usb 5-4.1.2: Reiner SCT Cyberjack USB card reader converter now attached to ttyUSB2 cyberjack 5-4.1.3:1.0: Reiner SCT Cyberjack USB card reader converter detected usb 5-4.1.3: Reiner SCT Cyberjack USB card reader converter now attached to ttyUSB3 cyberjack 5-2.3:1.0: Reiner SCT Cyberjack USB card reader converter detected usb 5-2.3: Reiner SCT Cyberjack USB card reader converter now attached to ttyUSB4 cyberjack 5-2.1:1.0: Reiner SCT Cyberjack USB card reader converter detected usb 5-2.1: Reiner SCT Cyberjack USB card reader converter now attached to ttyUSB5 cyberjack 5-2.2:1.0: Reiner SCT Cyberjack USB card reader converter detected usb 5-2.2: Reiner SCT Cyberjack USB card reader converter now attached to ttyUSB6 usbcore: registered new interface driver cyberjack drivers/usb/serial/cyberjack.c: v1.01 Matthias Bruestle drivers/usb/serial/cyberjack.c: REINER SCT cyberJack pinpad/e-com USB Chipcard Reader Driver System is x86_64 XEON 5160 4GB RAM Regards Andreas > > Regards > Oliver > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > Note that the control bits do not just magically change during normal > FPU use. It's a bit like sys_setsid()/iopl/etc., it makes little sense > to change those per-thread anyway. This is a non-issue anyway - what is > important is that the big bulk of 512 (or more) bytes of FPU state /are/ > callee-saved (both on 32-bit and on 64-bit), hence there's no need to ^ caller-saved > unlazy anything or to do expensive FPU state saves or other FPU juggling > around threadlet (or even syslet) use. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 00/13] Syslets, "Threadlets", generic AIO support, v3
* Davide Libenzi wrote: > [...] Status word and control bits should not be changed from > underneath userspace AFAIK. [...] Note that the control bits do not just magically change during normal FPU use. It's a bit like sys_setsid()/iopl/etc., it makes little sense to change those per-thread anyway. This is a non-issue anyway - what is important is that the big bulk of 512 (or more) bytes of FPU state /are/ callee-saved (both on 32-bit and on 64-bit), hence there's no need to unlazy anything or to do expensive FPU state saves or other FPU juggling around threadlet (or even syslet) use. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usbserial not working/oops on removal
On Sat, 3 Mar 2007 07:45:19 +0100 [EMAIL PROTECTED] (Oliver Neukum) wrote: > Am Samstag, 3. März 2007 03:37 schrieb Kevin Fenzi: > > I'm seeing some oddity with the latest fedora development kernel > > and a usbserial device. > > Very interesting. Is this repeatable? Yep. Tried a half dozen times or so... same thing each time. > Does unplugging have the same > effect? Well, the card is a minipci, so I would prefer to avoid taking the machine apart to unplug the card. ;) > Regards > Oliver kevin signature.asc Description: PGP signature
Re: [PATCH 4/9] Vmi fix highpte
Jeremy Fitzhardinge wrote:
Those are bugs that can occur, but they don't apply in this case. The
vmi implementation of kmap_atomic_pte() would be:
static void *vmi_kmap_atomic_pte(struct page *page, enum km_type type)
{
void *ptep = kmap_atomic(page, type);
vmi_map_pt_hook(type, ptep, page_to_pfn(page));
return ptep;
}
Right? Which is functionally identical to the code in your patch,
except wrapped up in a new function.
Yes, but the hook point now happens before the page table mapping. Not
that it should cause a problem. But we've been testing things the
original way for over a year now, and if we want to get the fix upstream
for 2.6.21, it seems better to upstream a more tested fix rather than a
new way of doing things, even if it is identical in theory.
That said, I have no problems with the approach you propose going
forward. I just don't think it is appropriate for an -rc release,
because it provides no tangible benefit for any of the in-kernel code,
and causes a lot of retesting. I still believe there is almost zero
risk to doing things the way you propose. But I am also a firm believer
in shipping what is tested and working unless there is a compelling
reason to do otherwise. And if Xen is not going to be in 2.6.21, the
compelling reason becomes getting the code working for both of us for
2.6.22 - so let's do that, and keep the patches from Andrew's -mm tree
around to make sure that we have a suitable patch base that can be
applied to 2.6.21 for any distros that are willing to pick up the Xen
paravirt-ops.
Sound reasonable?
Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: system call time increase when turning on CONFIG_PARAVIRT
Jeremy Fitzhardinge wrote: Tim Chen wrote: I also hope that the performance can be recovered as this option could enabled in distributions' kernels in future. Yes, the intent is that running a CONFIG_PARAVIRT kernel on native hardware will have negligible performance hit compared to running a non-paravirt kernel. We can validate that claim entirely. The way we are proceeding, the native code will be inlined or direct called as much as possible. With the VMI-Linux code we had earlier, this mostly created <3% overhead for microbenchmarks (and in some cases, we actually won over the unmodified native code). For macro-benchmarks, with real-world workloads, this reduced to immeasurable noise, never off by more than +/- 0.5% IIRC. I believe all of this is totally achievable. We have the technology. We can rebuild it. Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?
On Fri, 2 Mar 2007 14:57:06 +0100, Pavel Machek wrote: > On Fri 2007-03-02 14:37:20, Jean Delvare wrote: > > drivers/pci/quirks.c is full of things we do against the BIOS authors > > intent. You don't plan to remove them all, do you? > > Notice how quirks.c is careful to name machines where given quirk is > used. Notice how we unhide the SMBus only on a few named machines as well. > If you do whitelist "it is okay to do sensors accesses on this board", > that is okay with me. But having quirk "on all future Intel chipsets, > do foo" would be stupid. We don't do that, never did, and never planed to do. >(...) Enabling sensors blindly is pretty similar. This is the view of someone obviously not interested in sensors. Go tell that to all the lm-sensors users and they'll reply: "Disabling sensors blindly would be stupid." Please realize that we're not writing hardware monitoring drivers just for the fun of conflicting with ACPI on some machines. We're writing them because users are asking for these features. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usbserial not working/oops on removal
Am Samstag, 3. März 2007 03:37 schrieb Kevin Fenzi: > I'm seeing some oddity with the latest fedora development kernel and a > usbserial device. Very interesting. Is this repeatable? Does unplugging have the same effect? Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] ioatdma: Push pending transactions to hardware more frequently
> This sounds like something that will always be wrong -- or in other > words, always be right for only the latest CPUs. Can this be made > dynamic, based on some timing factor? In fact I think this has been tweaked twice in the vanilla tree already. This is actually just the same tweak you remember me posting before and I never pushed to get it in mainline, but Jeff's right. The problem isn't so much in the driver itself, as in how it's used by I/OAT in the TCP receive code, there are inherent assumptions about how long a context switch takes compared to how long an offloaded memcpy takes. I'm working on using completion interrupts for the device so as not to end up polling when the CPUs are faster than the code was tuned for, and doing it in a way that doesn't introduce extra context switches. I'm hoping to have something ready for 2.6.22, or at least ready for MM in that time frame. As for this change in the short term, we did go back and make sure that it didn't performance worse with the older CPUs supported on these platforms. We should have tested more intermediate values instead of just jumping from 1 t o 20 for that threshold. - Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kref refcounting breakage in mainline
On Fri, Mar 02, 2007 at 12:58:33AM -0800, Andrew Morton wrote: > > -mm has a debugging patch which warns when atomic_dec_and_test() takes an > atomic_t negative > (ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/detect-atomic-counter-underflows.patch). > > > When it is applied to current mainline, a simple `rmmod ipw2200' gives: > > [ 75.825072] BUG: atomic counter underflow at: > [ 75.825180] [] kref_put+0x66/0x82 > [ 75.825278] [] bus_remove_driver+0x66/0x75 > [ 75.825383] [] driver_unregister+0x8/0x13 > [ 75.825484] [] pci_unregister_driver+0xc/0x45 > [ 75.825593] [] sys_delete_module+0x157/0x17c > [ 75.825703] [] audit_syscall_entry+0x10d/0x137 > [ 75.825818] [] syscall_call+0x7/0xb > [ 75.825913] [] xfrm4_dst_destroy+0xe/0xd5 > > This didn't happen in 2.6.20-mm2, so this bug was introduced by a patch > which was not in the -mm lineup twelve days ago. > > Presumably the effect of this is a memory leak or a use-after-free. Ugh. I'll add it to my local tree here and try to bisect to find the problem. thanks for the pointer, 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/
Re: [PATCH] Loop device - Tracking page writes made to a loop device through mmap
There were a couple more white spaces, instead of tabs, hopefully this is
the last of them:-)
Signed-off-by: Kandan Venkataraman [EMAIL PROTECTED]
diff -uprN linux-2.6.19.2/drivers/block/loop.c
linux-2.6.19.2-new/drivers/block/loop.c
--- linux-2.6.19.2/drivers/block/loop.c 2007-03-03 16:26:03.0 +1100
+++ linux-2.6.19.2-new/drivers/block/loop.c 2007-03-03 16:44:38.0
+1100
@@ -74,12 +74,16 @@
#include
#include
#include
+#include
#include
static int max_loop = 8;
static struct loop_device *loop_dev;
static struct gendisk **disks;
+static kmem_cache_t *pgoff_elem_cache;
+static char *cache_name = "loop_pgoff_elem_cache";
+static struct file_operations loop_fops;
/*
* Transfer functions
@@ -646,6 +650,70 @@ static void do_loop_switch(struct loop_d
complete(>wait);
}
+static void pgoff_tree_clear(struct rb_root *rb_root)
+{
+ struct rb_node *rb_node = rb_root->rb_node;
+
+ while (rb_node != NULL) {
+
+ rb_erase(rb_node, rb_root);
+ kmem_cache_free(pgoff_elem_cache, rb_entry(rb_node,
+ struct pgoff_elem, node));
+ rb_node = rb_root->rb_node;
+ }
+
+ *rb_root = RB_ROOT;
+}
+
+
+static int loop_clr_pgwrites(struct loop_device *lo)
+{
+ struct file *filp = lo->lo_backing_file;
+
+ if (lo->lo_state != Lo_bound)
+ return -ENXIO;
+
+ if (filp == NULL || !lo->lo_track_pgwrite)
+ return -EINVAL;
+
+ pgoff_tree_clear(>pgoff_tree);
+
+ return 0;
+}
+
+static int loop_get_pgwrites(struct loop_device *lo,
+struct loop_pgoff_array __user *arg)
+{
+ struct file *filp = lo->lo_backing_file;
+ struct loop_pgoff_array array;
+ loff_t i = 0;
+ struct rb_node *rb_node = rb_first(>pgoff_tree);
+
+ if (lo->lo_state != Lo_bound)
+ return -ENXIO;
+
+ if (filp == NULL || !lo->lo_track_pgwrite)
+ return -EINVAL;
+
+ if (copy_from_user(, arg, sizeof (struct loop_pgoff_array)))
+ return -EFAULT;
+
+ while (i < array.max && rb_node != NULL) {
+
+ if (put_user(rb_entry(rb_node, struct pgoff_elem, node)->offset,
+ array.pgoff + i))
+ return -EFAULT;
+
+ ++i;
+ rb_node = rb_next(rb_node);
+ }
+ array.num = i;
+
+ if (copy_to_user(arg, , sizeof(array)))
+ return -EFAULT;
+
+ return 0;
+}
/*
* loop_change_fd switched the backing store of a loopback device to
@@ -692,6 +760,8 @@ static int loop_change_fd(struct loop_de
if (get_loop_size(lo, file) != get_loop_size(lo, old_file))
goto out_putf;
+ pgoff_tree_clear(>pgoff_tree);
+
/* and ... switch */
error = loop_switch(lo, file);
if (error)
@@ -799,6 +869,8 @@ static int loop_set_fd(struct loop_devic
lo->transfer = transfer_none;
lo->ioctl = NULL;
lo->lo_sizelimit = 0;
+ lo->lo_track_pgwrite = 0;
+ lo->pgoff_tree = RB_ROOT;
lo->old_gfp_mask = mapping_gfp_mask(mapping);
mapping_set_gfp_mask(mapping, lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS));
@@ -913,6 +985,8 @@ static int loop_clr_fd(struct loop_devic
lo->lo_sizelimit = 0;
lo->lo_encrypt_key_size = 0;
lo->lo_flags = 0;
+ lo->lo_track_pgwrite = 0;
+ pgoff_tree_clear(>pgoff_tree);
lo->lo_thread = NULL;
memset(lo->lo_encrypt_key, 0, LO_KEY_SIZE);
memset(lo->lo_crypt_name, 0, LO_NAME_SIZE);
@@ -969,6 +1043,14 @@ loop_set_status(struct loop_device *lo,
return -EFBIG;
}
+ if (info->lo_track_pgwrite)
+ lo->lo_track_pgwrite = 1;
+ else {
+ if (lo->lo_track_pgwrite)
+ pgoff_tree_clear(>pgoff_tree);
+ lo->lo_track_pgwrite = 0;
+ }
+
memcpy(lo->lo_file_name, info->lo_file_name, LO_NAME_SIZE);
memcpy(lo->lo_crypt_name, info->lo_crypt_name, LO_NAME_SIZE);
lo->lo_file_name[LO_NAME_SIZE-1] = 0;
@@ -1011,6 +1093,7 @@ loop_get_status(struct loop_device *lo,
info->lo_offset = lo->lo_offset;
info->lo_sizelimit = lo->lo_sizelimit;
info->lo_flags = lo->lo_flags;
+ info->lo_track_pgwrite = lo->lo_track_pgwrite;
memcpy(info->lo_file_name, lo->lo_file_name, LO_NAME_SIZE);
memcpy(info->lo_crypt_name, lo->lo_crypt_name, LO_NAME_SIZE);
info->lo_encrypt_type =
@@ -1036,6 +1119,7 @@ loop_info64_from_old(const struct loop_i
info64->lo_encrypt_type = info->lo_encrypt_type;
info64->lo_encrypt_key_size = info->lo_encrypt_key_size;
info64->lo_flags = info->lo_flags;
+ info64->lo_track_pgwrite = 0;
info64->lo_init[0] = info->lo_init[0];
info64->lo_init[1] = info->lo_init[1];
if (info->lo_encrypt_type ==
Re: 2.6.21-rc2 radeon backlight
Richard Purdie <[EMAIL PROTECTED]> writes: > I propose the following patch (I was previously waiting on James for > this). It avoids backing out the problematic Kconfig changes but > means a user has to explicitly enable the backlight via a kernel or > module parameter. > > Can people with backlight problems try enabling them in Kconfig but > applying the following patch? Hopefully I have you all cc'd. > > If it works I will add it to the other fix I have queued and pass to > Linus via the backlight tree. If it doesn't, I will revert the > problematic Kconfig changes for the next -rc. with the patch applied i can boot into 2.6.21-rc2 and have a working backlight when i enable radeon backlight support. so i guess the patch successfully disables the new radeon backlight stuff on my thinkpad and therefore it does what it says it does. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.19.7
diff --git a/Makefile b/Makefile
index 5335f17..10a3416 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 19
-EXTRAVERSION = .6
+EXTRAVERSION = .7
NAME=Avast! A bilge rat!
# *DOCUMENTATION*
diff --git a/drivers/media/dvb/dvb-core/dvbdev.c
b/drivers/media/dvb/dvb-core/dvbdev.c
index 40774fe..af35f30 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.c
+++ b/drivers/media/dvb/dvb-core/dvbdev.c
@@ -200,6 +200,8 @@ int dvb_register_device(struct dvb_adapter *adap, struct
dvb_device **pdvbdev,
const struct dvb_device *template, void *priv, int type)
{
struct dvb_device *dvbdev;
+ struct file_operations *dvbdevfops;
+
int id;
if (mutex_lock_interruptible(_register_lock))
@@ -219,12 +221,22 @@ int dvb_register_device(struct dvb_adapter *adap, struct
dvb_device **pdvbdev,
return -ENOMEM;
}
+ dvbdevfops = kzalloc(sizeof(struct file_operations), GFP_KERNEL);
+
+ if (!dvbdevfops) {
+ kfree (dvbdev);
+ mutex_unlock(_register_lock);
+ return -ENOMEM;
+ }
+
memcpy(dvbdev, template, sizeof(struct dvb_device));
dvbdev->type = type;
dvbdev->id = id;
dvbdev->adapter = adap;
dvbdev->priv = priv;
+ dvbdev->fops = dvbdevfops;
+ memcpy(dvbdev->fops, template->fops, sizeof(struct file_operations));
dvbdev->fops->owner = adap->module;
list_add_tail (>list_head, >device_list);
@@ -252,6 +264,7 @@ void dvb_unregister_device(struct dvb_device *dvbdev)
dvbdev->type, dvbdev->id)));
list_del (>list_head);
+ kfree (dvbdev->fops);
kfree (dvbdev);
}
EXPORT_SYMBOL(dvb_unregister_device);
diff --git a/drivers/media/dvb/dvb-usb/cxusb.c
b/drivers/media/dvb/dvb-usb/cxusb.c
index 43f3906..848dc4f 100644
--- a/drivers/media/dvb/dvb-usb/cxusb.c
+++ b/drivers/media/dvb/dvb-usb/cxusb.c
@@ -471,8 +471,8 @@ static int bluebird_patch_dvico_firmware_download(struct
usb_device *udev, const
if (fw->data[BLUEBIRD_01_ID_OFFSET] == (USB_VID_DVICO & 0xff) &&
fw->data[BLUEBIRD_01_ID_OFFSET + 1] == USB_VID_DVICO >> 8) {
- fw->data[BLUEBIRD_01_ID_OFFSET + 2] =
udev->descriptor.idProduct + 1;
- fw->data[BLUEBIRD_01_ID_OFFSET + 3] =
udev->descriptor.idProduct >> 8;
+ fw->data[BLUEBIRD_01_ID_OFFSET + 2] =
le16_to_cpu(udev->descriptor.idProduct) + 1;
+ fw->data[BLUEBIRD_01_ID_OFFSET + 3] =
le16_to_cpu(udev->descriptor.idProduct) >> 8;
return usb_cypress_load_firmware(udev,fw,CYPRESS_FX2);
}
diff --git a/drivers/media/dvb/dvb-usb/digitv.c
b/drivers/media/dvb/dvb-usb/digitv.c
index 8fb3437..ea7df29 100644
--- a/drivers/media/dvb/dvb-usb/digitv.c
+++ b/drivers/media/dvb/dvb-usb/digitv.c
@@ -119,6 +119,8 @@ static int digitv_nxt6000_tuner_set_params(struct
dvb_frontend *fe, struct dvb_f
struct dvb_usb_adapter *adap = fe->dvb->priv;
u8 b[5];
dvb_usb_tuner_calc_regs(fe,fep,b, 5);
+ if (fe->ops.i2c_gate_ctrl)
+ fe->ops.i2c_gate_ctrl(fe, 1);
return digitv_ctrl_msg(adap->dev, USB_WRITE_TUNER, 0, [1], 4, NULL,
0);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.19.7
We (the -stable team) are announcing the release of the 2.6.19.7 kernel. It turns out that I forgot some patches that had already been submitted to me, hence the new release. It contains some DVB bugfixes, so anyone who uses that subsystem is recommended to upgrade, otherwise 2.6.19.6 is fine. Barring anything major, there will not be any more 2.6.19 releases. If you disagree with this, please let the stable team know about the patches that you feel must be in a new release. We need to move on to flushing out the very large backlog of 2.6.20-stable patches. The diffstat and short summary of the fixes are below. I'll also be replying to this message with a copy of the patch between 2.6.19.6 and 2.6.19.7, as it is small enough to do so. The updated 2.6.19.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.19.y.git and can be browsed at the normal kernel.org git web browser: www.kernel.org/git/ thanks, greg k-h Makefile|2 +- drivers/media/dvb/dvb-core/dvbdev.c | 13 + drivers/media/dvb/dvb-usb/cxusb.c |4 ++-- drivers/media/dvb/dvb-usb/digitv.c |2 ++ 4 files changed, 18 insertions(+), 3 deletions(-) Summary of changes from v2.6.19.6 to v2.6.19.7 == Greg Kroah-Hartman (1): Linux 2.6.19.7 Jin-Bong lee (1): DVB: cxusb: fix firmware patch for big endian systems Marcel Siegert (1): dvbdev: fix illegal re-usage of fileoperations struct Michael Krufky (1): DVB: digitv: open nxt6000 i2c_gate for TDED4 tuner handling - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH 2/2 -stable] libata: add missing CONFIG_PM in LLDs
Hi. On Sat, 2007-03-03 at 12:20 +0900, Tejun Heo wrote: > Hello, Nigel. > > Nigel Cunningham wrote: > >> Index: work1/drivers/ata/ahci.c > >> === > >> --- work1.orig/drivers/ata/ahci.c > >> +++ work1/drivers/ata/ahci.c > >> @@ -225,10 +225,12 @@ static void ahci_thaw(struct ata_port *a > >> static void ahci_error_handler(struct ata_port *ap); > >> static void ahci_vt8251_error_handler(struct ata_port *ap); > >> static void ahci_post_internal_cmd(struct ata_queued_cmd *qc); > >> +#ifdef CONFIG_PM > >> static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg); > >> static int ahci_port_resume(struct ata_port *ap); > >> static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t > >> mesg); > >> static int ahci_pci_device_resume(struct pci_dev *pdev); > > > > Wouldn't it be simpler to add > > > > #else > > #define ahci_port_suspend(port, message) (NULL) > > > > etc (or something similar)? > > ahci_port_suspend() is used to fill ata_port_ops vector, so it needs to > be a function. If you're talking about defining NULL function, yeah, > that will remove half of CONFIG_PMs but would require dummy definitions > for all functions. I think both are ugly. :-) Yeah, I didn't look really carefully; an empty static function would have been what I'd have written if I'd paid more attention. > I'm working on a linker trick. Please take a look at the following thread. > > http://thread.gmane.org/gmane.linux.ide/16475 Not familiar with fancy things like that, so I'll just pipe down and leave you to it :). Regards, Nigel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] sched: optimize siblings status check logic in wake_idle()
When a logical cpu 'x' already has more than one process running, then most
likely
the siblings of that cpu 'x' must be busy. Otherwise the idle siblings
would have likely(in most of the scenarios) picked up the extra load making
the load on 'x' atmost one.
Use this logic to eliminate the siblings status check and minimize the cache
misses encountered on a heavily loaded system.
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
---
diff --git a/kernel/sched.c b/kernel/sched.c
index 0dc7572..d1ecc56 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -1368,7 +1368,16 @@ static int wake_idle(int cpu, struct task_struct *p)
struct sched_domain *sd;
int i;
- if (idle_cpu(cpu))
+ /*
+* If it is idle, then it is the best cpu to run this task.
+*
+* This cpu is also the best, if it has more than one task already.
+* Siblings must be also busy(in most cases) as they didn't already
+* pickup the extra load from this cpu and hence we need not check
+* sibling runqueue info. This will avoid the checks and cache miss
+* penalities associated with that.
+*/
+ if (idle_cpu(cpu) || cpu_rq(cpu)->nr_running > 1)
return cpu;
for_each_domain(cpu, sd) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The performance and behaviour of the anti-fragmentation related patches
On Fri, 2 Mar 2007 16:32:07 + [EMAIL PROTECTED] (Mel Gorman) wrote: > The zone-based patches for memory partitioning should be providing what is > required for memory hot-remove of an entire DIMM or bank of memory (PPC64 > also cares about removing smaller blocks of memory but zones are overkill > there and anti-fragmentation on its own is good enough). Pages hot-added > to ZONE_MOVABLE will always be reclaimable or migratable in the case of > mlock(). Kamezawa Hiroyuki has indicated that his hot-remove patches also > do something like ZONE_MOVABLE. I would hope that his patches could be > easily based on top of my memory partitioning set of patches. The markup > of pages has been tested and the zone definitely works. I've added the > [EMAIL PROTECTED] to the cc list so he can comment :) Thanks. As you wrote, I'm planning to write patch based on ZONE_MOVABLE. I'm now using my own one just because I can't handle too many patches. My version has a few just-for-cleanup patches. And it may be a bit different from yours. I'll add cc to you when I post. It's not ready to send yet...(found some panic at offlining memory ;) > What I do not do in my patchset is hot-add to ZONE_MOVABLE because I couldn't > be certain it's what the hotplug people wanted. They will of course need to > hot-add to that zone if they want to be able to remove it later. > I'm planing to make hot-added memory as ZONE_MOVABLE. I believe we can find and move movable pages in ZONE_NOT_MOVABLE to ZONE_MOVABLE.(or kswapd/pageout will do this in slow way.) The reason is that my first purpose is removing hot-added-memory. I think I can add knob to choose a zone for hot-added-memory but I won't do it until someone wants it. > For node-based memory hot-add and hot-remove, the node would consist of just > one populated zone - ZONE_MOVABLE. > yes. Note: We are considering to allocate well-known-structures like mem_map and pgdat from hot-added memory. We can remove it when a node is unplugged. But no plan/patches yet. > For the removal of DIMMs, anti-fragmentation has something additional > to offer. The later patches in the anti-fragmentation patchset bias the > placement of unmovable pages towards the lower PFNs. It's not very strict > about this because being strict would cost. A mechanism could be put in place > that enforced the placement of unmovables pages at low PFNS. Due to the cost, > it would need to be disabled by default and enabled on request. On the plus > side, the cost would only be incurred when splitting a MAX_ORDER block of > pages which is a rare event. And kernel on VM, IBM's uses 16MB sparsemem for memory-hotplug, can get enough benefit. While Xen's baloon driver can do memory-unplug, I heard it causes memory fragmentation. anti-frag patch will help this. -Kame - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] ioatdma: Push pending transactions to hardware more frequently
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri, 02 Mar 2007 22:14:39 -0500
> Chris Leech wrote:
> > Every 20 descriptors turns out to be to few append commands with
> > newer/faster CPUs. Pushing every 4 still cuts down on MMIO writes to an
> > acceptable level without letting the DMA engine run out of work.
> >
> > Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
> > ---
> >
> > drivers/dma/ioatdma.c |4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
> > index 8e87261..0f77a9d 100644
> > --- a/drivers/dma/ioatdma.c
> > +++ b/drivers/dma/ioatdma.c
> > @@ -310,7 +310,7 @@ static dma_cookie_t do_ioat_dma_memcpy(struct
> > ioat_dma_chan *ioat_chan,
> > list_splice_init(_chain, ioat_chan->used_desc.prev);
> >
> > ioat_chan->pending += desc_count;
> > - if (ioat_chan->pending >= 20) {
> > + if (ioat_chan->pending >= 4) {
>
> This sounds like something that will always be wrong -- or in other
> words, always be right for only the latest CPUs. Can this be made
> dynamic, based on some timing factor?
In fact I think this has been tweaked twice in the vanilla tree
already.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The performance and behaviour of the anti-fragmentation related patches
On Fri, 2 Mar 2007, William Lee Irwin III wrote: >> AIUI that phenomenon is universal to NUMA. Maybe it's time we >> reexamined our locking algorithms in the light of fairness >> considerations. On Fri, Mar 02, 2007 at 07:15:38PM -0800, Christoph Lameter wrote: > This is a phenomenon that is usually addressed at the cache logic level. > Its a hardware maturation issue. A certain package should not be allowed > to hold onto a cacheline forever and other packages must have a mininum > time when they can operate on that cacheline. I think when I last asked about that I was told "cache directories are too expensive" or something on that order, if I'm not botching this, too. In any event, the above shows a gross inaccuracy in my statement. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The performance and behaviour of the anti-fragmentation related patches
On Fri, 2 Mar 2007 17:40:04 -0800 William Lee Irwin III <[EMAIL PROTECTED]> wrote: >> My gut feeling is to agree, but I get nagging doubts when I try to >> think of how to boil things like [major benchmarks whose names are >> trademarked/copyrighted/etc. censored] down to simple testcases. Some >> other things are obvious but require vast resources, like zillions of >> disks fooling throttling/etc. heuristics of ancient downrev kernels. On Fri, Mar 02, 2007 at 05:58:56PM -0800, Andrew Morton wrote: > noo. You're approaching it from the wrong direction. > Step 1 is to understand what is happening on the affected production > system. Completely. Once that is fully understood then it is a relatively > simple matter to concoct a test case which triggers the same failure mode. > It is very hard to go the other way: to poke around with various stress > tests which you think are doing something similar to what you think the > application does in the hope that similar symptoms will trigger so you can > then work out what the kernel is doing. yuk. Yeah, it's really great when it's possible to get debug info out of people e.g. they're willing to boot into a kernel instrumented with the appropriate printk's/etc. Most of the time it's all guesswork. People who post to lkml are much better about all this on average. I never truly understood the point of kprobes/jprobes/dprobes (or whatever the probing letter is), crash dumps, and so on until I ran into this, not that I use personally them (though I may yet start). Most of the time I just read the code instead and smoke out what could be going on by something like the process of devising counterexamples. For instance, I told that colouroff patch guy about the possibility of getting the wrong page for the start of the buffer from virt_to_page() on a cache colored buffer pointer (clearly cache->gfporder >= 4 in such a case). Deriving the head page without __GFP_COMP might be considered to be ugly-looking, though. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH 2/2 -stable] libata: add missing CONFIG_PM in LLDs
Hello, Nigel. Nigel Cunningham wrote: >> Index: work1/drivers/ata/ahci.c >> === >> --- work1.orig/drivers/ata/ahci.c >> +++ work1/drivers/ata/ahci.c >> @@ -225,10 +225,12 @@ static void ahci_thaw(struct ata_port *a >> static void ahci_error_handler(struct ata_port *ap); >> static void ahci_vt8251_error_handler(struct ata_port *ap); >> static void ahci_post_internal_cmd(struct ata_queued_cmd *qc); >> +#ifdef CONFIG_PM >> static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg); >> static int ahci_port_resume(struct ata_port *ap); >> static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg); >> static int ahci_pci_device_resume(struct pci_dev *pdev); > > Wouldn't it be simpler to add > > #else > #define ahci_port_suspend(port, message) (NULL) > > etc (or something similar)? ahci_port_suspend() is used to fill ata_port_ops vector, so it needs to be a function. If you're talking about defining NULL function, yeah, that will remove half of CONFIG_PMs but would require dummy definitions for all functions. I think both are ugly. :-) I'm working on a linker trick. Please take a look at the following thread. http://thread.gmane.org/gmane.linux.ide/16475 -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The performance and behaviour of the anti-fragmentation related patches
On Fri, 2 Mar 2007, William Lee Irwin III wrote: > On Fri, Mar 02, 2007 at 02:22:56PM -0800, Andrew Morton wrote: > > Opterons seem to be particularly prone to lock starvation where a cacheline > > gets captured in a single package for ever. > > AIUI that phenomenon is universal to NUMA. Maybe it's time we > reexamined our locking algorithms in the light of fairness > considerations. This is a phenomenon that is usually addressed at the cache logic level. Its a hardware maturation issue. A certain package should not be allowed to hold onto a cacheline forever and other packages must have a mininum time when they can operate on that cacheline. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] ioatdma: Push pending transactions to hardware more frequently
Chris Leech wrote:
Every 20 descriptors turns out to be to few append commands with
newer/faster CPUs. Pushing every 4 still cuts down on MMIO writes to an
acceptable level without letting the DMA engine run out of work.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
index 8e87261..0f77a9d 100644
--- a/drivers/dma/ioatdma.c
+++ b/drivers/dma/ioatdma.c
@@ -310,7 +310,7 @@ static dma_cookie_t do_ioat_dma_memcpy(struct ioat_dma_chan
*ioat_chan,
list_splice_init(_chain, ioat_chan->used_desc.prev);
ioat_chan->pending += desc_count;
- if (ioat_chan->pending >= 20) {
+ if (ioat_chan->pending >= 4) {
This sounds like something that will always be wrong -- or in other
words, always be right for only the latest CPUs. Can this be made
dynamic, based on some timing factor?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] libata: add missing PM callbacks
[cc'ing Pavel and linux-kernel, hello] Original thread can be read from http://thread.gmane.org/gmane.linux.ide/16475 Jeff Garzik wrote: > Tejun Heo wrote: >> Some LLDs were missing scsi device PM callbacks while having host/port >> suspend support. Add missing ones. >> >> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > > applied 1-3, though I agree with Alan that a non-ifdef solution should > be sought (by the PM & PCI people?), where possible Agreed, CONFIG_PM ifdefs are all over low level drivers, libata or not, and ugly as hell. Maybe use separate section, mark functions with __power and drop them at link time is a better idea. With linker tricks, we can make references to __power symbols NULL. How does it sound? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: i386: make x86_64 tsc header require i386 rather than vice-versa
Prior to commit 95492e4646e5de8b43d9a7908d6177fb737b61f0 ([PATCH] x86:
rewrite SMP TSC sync code), the headers in asm-i386 did not really
require anything in include/asm-x86_64. This means that distributions
such as fedora did not include asm-x86_64 in kernel-devel headers for
i386. Ingo's commit changed that, and broke things. This is easy
enough to hack around in package builds by just including asm-x86_64 on
i386, but that's kind of annoying. If anything, x86_64 should depend
upon i386, not the other way around.
This patch changes it so that asm-x86_64/tsc.h includes asm-i386/tsc.h,
rather than vice-versa.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
diff --git a/include/asm-i386/tsc.h b/include/asm-i386/tsc.h
index e997891..6207fc0 100644
--- a/include/asm-i386/tsc.h
+++ b/include/asm-i386/tsc.h
@@ -1 +1,66 @@
-#include
+/*
+ * linux/include/asm-i386/tsc.h
+ *
+ * x86 TSC related functions
+ */
+#ifndef _ASM_i386_TSC_H
+#define _ASM_i386_TSC_H
+
+#include
+
+/*
+ * Standard way to access the cycle counter.
+ */
+typedef unsigned long long cycles_t;
+
+extern unsigned int cpu_khz;
+extern unsigned int tsc_khz;
+
+static inline cycles_t get_cycles(void)
+{
+ unsigned long long ret = 0;
+
+#ifndef CONFIG_X86_TSC
+ if (!cpu_has_tsc)
+ return 0;
+#endif
+
+#if defined(CONFIG_X86_GENERIC) || defined(CONFIG_X86_TSC)
+ rdtscll(ret);
+#endif
+ return ret;
+}
+
+/* Like get_cycles, but make sure the CPU is synchronized. */
+static __always_inline cycles_t get_cycles_sync(void)
+{
+ unsigned long long ret;
+#ifdef X86_FEATURE_SYNC_RDTSC
+ unsigned eax;
+
+ /*
+* Don't do an additional sync on CPUs where we know
+* RDTSC is already synchronous:
+*/
+ alternative_io("cpuid", ASM_NOP2, X86_FEATURE_SYNC_RDTSC,
+ "=a" (eax), "0" (1) : "ebx","ecx","edx","memory");
+#else
+ sync_core();
+#endif
+ rdtscll(ret);
+
+ return ret;
+}
+
+extern void tsc_init(void);
+extern void mark_tsc_unstable(void);
+extern int unsynchronized_tsc(void);
+
+/*
+ * Boot-time check whether the TSCs are synchronized across
+ * all CPUs/cores:
+ */
+extern void check_tsc_sync_source(int cpu);
+extern void check_tsc_sync_target(void);
+
+#endif
diff --git a/include/asm-x86_64/tsc.h b/include/asm-x86_64/tsc.h
index 9a0a368..d66ba6e 100644
--- a/include/asm-x86_64/tsc.h
+++ b/include/asm-x86_64/tsc.h
@@ -1,66 +1 @@
-/*
- * linux/include/asm-x86_64/tsc.h
- *
- * x86_64 TSC related functions
- */
-#ifndef _ASM_x86_64_TSC_H
-#define _ASM_x86_64_TSC_H
-
-#include
-
-/*
- * Standard way to access the cycle counter.
- */
-typedef unsigned long long cycles_t;
-
-extern unsigned int cpu_khz;
-extern unsigned int tsc_khz;
-
-static inline cycles_t get_cycles(void)
-{
- unsigned long long ret = 0;
-
-#ifndef CONFIG_X86_TSC
- if (!cpu_has_tsc)
- return 0;
-#endif
-
-#if defined(CONFIG_X86_GENERIC) || defined(CONFIG_X86_TSC)
- rdtscll(ret);
-#endif
- return ret;
-}
-
-/* Like get_cycles, but make sure the CPU is synchronized. */
-static __always_inline cycles_t get_cycles_sync(void)
-{
- unsigned long long ret;
-#ifdef X86_FEATURE_SYNC_RDTSC
- unsigned eax;
-
- /*
-* Don't do an additional sync on CPUs where we know
-* RDTSC is already synchronous:
-*/
- alternative_io("cpuid", ASM_NOP2, X86_FEATURE_SYNC_RDTSC,
- "=a" (eax), "0" (1) : "ebx","ecx","edx","memory");
-#else
- sync_core();
-#endif
- rdtscll(ret);
-
- return ret;
-}
-
-extern void tsc_init(void);
-extern void mark_tsc_unstable(void);
-extern int unsynchronized_tsc(void);
-
-/*
- * Boot-time check whether the TSCs are synchronized across
- * all CPUs/cores:
- */
-extern void check_tsc_sync_source(int cpu);
-extern void check_tsc_sync_target(void);
-
-#endif
+#include
lock_rename for cluster filesystems? (was: Re: [PATCH] prune_icache_sb)
On 12/4/06, Wendy Cheng <[EMAIL PROTECTED]> wrote: Russell Cattelan wrote: > Wendy Cheng wrote: > >> Linux kernel, particularly the VFS layer, is starting to show signs >> of inadequacy as the software components built upon it keep growing. >> I have doubts that it can keep up and handle this complexity with a >> development policy like you just described (filesystem is a dumb >> layer ?). Aren't these DIO_xxx_LOCKING flags inside >> __blockdev_direct_IO() a perfect example why trying to do too many >> things inside vfs layer for so many filesystems is a bad idea ? By >> the way, since we're on this subject, could we discuss a little bit >> about vfs rename call (or I can start another new discussion thread) ? >> >> Note that linux do_rename() starts with the usual lookup logic, >> followed by "lock_rename", then a final round of dentry lookup, and >> finally comes to filesystem's i_op->rename call. Since lock_rename() >> only calls for vfs layer locks that are local to this particular >> machine, for a cluster filesystem, there exists a huge window between >> the final lookup and filesystem's i_op->rename calls such that the >> file could get deleted from another node before fs can do anything >> about it. Is it possible that we could get a new function pointer >> (lock_rename) in inode_operations structure so a cluster filesystem >> can do proper locking ? > > It looks like the ocfs2 guys have the similar problem? > > http://ftp.kernel.org/pub/linux/kernel/people/mfasheh/ocfs2/ocfs2_git_patches/ocfs2-upstream-linus-20060924/0009-PATCH-Allow-file-systems-to-manually-d_move-inside-of-rename.txt > > > Thanks for the pointer. Same as ocfs2, under current VFS code, both GFS1/2 also need FS_ODD_RENAME flag for the rename problem - got an ugly ~200 line draft patch ready for GFS1 (and am looking into GFS2 at this moment). The issue here is, for GFS, if vfs lock_rename() can call us, this complication can be greatly reduced. Will start another thread to see whether the wish can be granted. Hi Wendy, Have you (or others) made any progress on a possible solution to simplify handling cluster fs do_rename() races (e.g. your proposed lock_rename in inode_operations)? I couldn't find a newer thread that continued this discussion... please advise, thanks. 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: [PATCH] free swap space of (re)activated pages
On Saturday 03 March 2007 12:31, Rik van Riel wrote: > Andrew Morton wrote: > > On Fri, 02 Mar 2007 15:31:19 -0500 > > > > Rik van Riel <[EMAIL PROTECTED]> wrote: > >> the attached patch frees the swap space of already resident pages > >> when swap space starts getting tight, instead of only freeing up > >> the swap space taken up by newly swapped in pages. > >> > >> This should result in the swap space of pages that remain resident > >> in memory being freed, allowing kswapd more chances to actually swap > >> a page out (instead of rotating it back onto the active list). > > > > Fair enough. How do we work out if this helps things? > > I suspect it should mostly help on desktop systems that slowly > fill up (and run out of) swap. I'm not sure how to create that > synthetically. Ooh you have a vm patch that helps swap on the desktop! I can help you here with my experience from swap prefetch. 1. Get it reviewed and have noone show any evidence it harms 2. Find hundreds of users who can testify it helps 3. Find a way of quantifying it. 4. ... 5. Merge into mainline. There, that should get you as far as 4. I haven't figured out what 4 is yet. I believe it may be goto 1; -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
usbserial not working/oops on removal
I'm seeing some oddity with the latest fedora development kernel and a usbserial device. 2.6.20-1.2949.fc7 #1 SMP Mon Feb 26 18:33:03 EST 2007 x86_64 x86_64 x86_64 GNU/Linux Its a evdo device. Doing: modprobe usbserial vendor=0x413c product=0x8128 debug=1 gets: drivers/usb/serial/usb-serial.c: Had to override the open usb serial operation with the generic one. drivers/usb/serial/usb-serial.c: Had to override the write usb serial operation with the generic one. drivers/usb/serial/usb-serial.c: Had to override the close usb serial operation with the generic one. drivers/usb/serial/usb-serial.c: Had to override the write_room usb serial operation with the generic one. drivers/usb/serial/usb-serial.c: Had to override the chars_in_buffer usb serial operation with the generic one. drivers/usb/serial/usb-serial.c: Had to override the read_bulk_callback usb serial operation with the generic one. drivers/usb/serial/usb-serial.c: Had to override the write_bulk_callback usb serial operation with the generic one. drivers/usb/serial/usb-serial.c: USB Serial support registered for generic drivers/usb/serial/usb-serial.c: static descriptor matches drivers/usb/serial/usb-serial.c: found interrupt in on endpoint 0 drivers/usb/serial/usb-serial.c: found bulk in on endpoint 1 drivers/usb/serial/usb-serial.c: found bulk out on endpoint 2 usbserial_generic 1-2.2:1.0: generic converter detected drivers/usb/serial/usb-serial.c: usb_serial_probe - setting up 1 port structures for this device drivers/usb/serial/usb-serial.c: the device claims to support interrupt in transfers, but read_int_callback is not defined drivers/usb/serial/usb-serial.c: get_free_serial 1 drivers/usb/serial/usb-serial.c: get_free_serial - minor base = 0 drivers/usb/serial/usb-serial.c: usb_serial_probe - registering ttyUSB255 Attempt to register invalid tty line number (255). usb 1-2.2: generic converter now attached to ttyUSB255 drivers/usb/serial/usb-serial.c: static descriptor matches drivers/usb/serial/usb-serial.c: found bulk in on endpoint 0 drivers/usb/serial/usb-serial.c: found bulk out on endpoint 1 usbserial_generic 1-2.2:1.1: generic converter detected drivers/usb/serial/usb-serial.c: usb_serial_probe - setting up 1 port structures for this device drivers/usb/serial/usb-serial.c: get_free_serial 1 drivers/usb/serial/usb-serial.c: get_free_serial - minor base = 1 drivers/usb/serial/usb-serial.c: usb_serial_probe - registering ttyUSB255 usb-serial ttyUSB255: Error registering port device, continuing usbcore: registered new interface driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver core usbcore: deregistering interface driver usbserial_generic drivers/usb/serial/usb-serial.c: usb_serial_disconnect drivers/usb/serial/usb-serial.c: destroy_serial - generic drivers/usb/serial/generic.c: usb_serial_generic_shutdown drivers/usb/serial/generic.c: generic_cleanup - port 255 drivers/usb/serial/usb-serial.c: return_serial On a updated fc6 kernel it works fine and gives me a ttyUSB0, ttyUSB1. Trying to rmmod the module gets: Unable to handle kernel NULL pointer dereference at 0048 RIP: [] klist_del+0x16/0x50 PGD 626f0067 PUD 601bc067 PMD 0 Oops: [1] SMP last sysfs file: /class/net/eth0/carrier CPU 1 Modules linked in: usbserial kvm_intel kvm i915 drm autofs4 hidp rfcomm l2cap sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables acpi_cpufreq dm_multipath video sbs i2c_ec button bay dock battery asus_acpi ac ipv6 parport_pc lp parport aes cbc blkcipher sha256 dm_crypt snd_hda_intel snd_hda_codec snd_seq_dummy hci_usb bluetooth snd_seq_oss snd_seq_midi_event rtc_cmos fw_ohci snd_seq tg3 rtc_core fw_core serio_raw snd_seq_device rtc_lib snd_pcm_oss iTCO_wdt iTCO_vendor_support snd_mixer_oss snd_pcm snd_timer snd soundcore shpchp i2c_i801 snd_page_alloc i2c_core sr_mod cdrom sg joydev dm_snapshot dm_zero dm_mirror dm_mod ata_piix ata_generic libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd Pid: 3256, comm: rmmod Not tainted 2.6.20-1.2949.fc7 #1 RIP: 0010:[] [] klist_del+0x16/0x50 RSP: 0018:8100606d1c88 EFLAGS: 00010296 RAX: 8100760cf2b8 RBX: RCX: 0001 RDX: 81004f4c6778 RSI: 0001 RDI: RBP: 8100606d1ca8 R08: 022a R09: 0001 R10: 884479d2 R11: 00300018 R12: 8100760cf4a8 R13: 81004f4c6768 R14: 81007e386710 R15: 81007e386710 FS: 2b0136f0() GS:810003f5fcc0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0048 CR3: 5e918000 CR4: 26e0 Process rmmod (pid: 3256, threadinfo 8100606d, task 810065365080) Stack: 0001 8100760cf458 8100760cf458 81004f4c6768 8100606d1cd8 803b7d60 8100760cf458 81004f4c6768 81004f4c6768
[PATCH] dynticks: don't unlock spinlock twice
During boot with dynticks enabled, we would sometimes get:
[ 35.271900] Switched to high resolution mode on CPU 0
[ 35.304468] BUG: spinlock already unlocked on CPU#0, swapper/1
[ 35.338099] lock: c06428a0, .magic: dead4ead, .owner: /-1,
.owner_cpu:
-1
[ 35.373597] [] _raw_spin_unlock+0x28/0x67
[ 35.406647] [] _spin_unlock+0x5/0x23
[ 35.439369] [] tick_sched_timer+0x4e/0xa7
[ 35.472388] [] tick_sched_timer+0x0/0xa7
[ 35.504833] [] hrtimer_run_queues+0x199/0x1ec
[ 35.537617] [] run_timer_softirq+0x12/0x166
[ 35.570019] [] __do_softirq+0x40/0x85
[ 35.601542] [] do_softirq+0x53/0xa9
...
This appears to be caused by run_hrtimer_queue() (called by
hrtimer_run_queues) calling spin_unlock_irq(_base->lock) before
calling timer->function(timer). The callback function
(tick_sched_timer) expects cpu_base->lock to be held when it is called,
and attempts to unlock it. Since it doesn't seem like anything within
tick_sched_timer really needs to hold the lock (afaict), the attached
patch simply removes the lock handling from tick_sched_timer. Things
called by tick_sched_timer may grab the base->lock, but that's fine (and
their responsibility). Let me know if there's some reason why the lock
should be held, and I can rework this.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 51556b9..b43bccb 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -422,13 +422,12 @@ static inline void tick_nohz_switch_to_nohz(void) { }
#ifdef CONFIG_HIGH_RES_TIMERS
/*
* We rearm the timer until we get disabled by the idle code
- * Called with interrupts disabled and timer->base->cpu_base->lock held.
+ * Called with interrupts disabled and timer->base->cpu_base->lock *not* held.
*/
static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)
{
struct tick_sched *ts =
container_of(timer, struct tick_sched, sched_timer);
- struct hrtimer_cpu_base *base = timer->base->cpu_base;
struct pt_regs *regs = get_irq_regs();
ktime_t now = ktime_get();
@@ -454,13 +453,12 @@ static enum hrtimer_restart tick_sched_timer(struct
hrtimer *timer)
}
/*
* update_process_times() might take tasklist_lock, hence
-* drop the base lock. sched-tick hrtimers are per-CPU and
-* never accessible by userspace APIs, so this is safe to do.
+* we don't attempt to grab the base lock here.
+* sched-tick hrtimers are per-CPU and never accessible by
+* userspace APIs, so this is safe to do.
*/
- spin_unlock(>lock);
update_process_times(user_mode(regs));
profile_tick(CPU_PROFILING);
- spin_lock(>lock);
}
/* Do not restart, when we are in the idle loop */
[PATCH 8/9] I/OAT: warning fix
net/ipv4/tcp.c: In function 'tcp_recvmsg':
net/ipv4/tcp.c:: warning: unused variable 'available'
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
net/ipv4/tcp.c | 26 --
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 5ccd5e1..69c525d 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1110,7 +1110,6 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk,
struct msghdr *msg,
long timeo;
struct task_struct *user_recv = NULL;
int copied_early = 0;
- int available = 0;
struct sk_buff *skb;
lock_sock(sk);
@@ -1139,15 +1138,22 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk,
struct msghdr *msg,
tp->ucopy.dma_chan = NULL;
preempt_disable();
skb = skb_peek_tail(>sk_receive_queue);
- if (skb)
- available = TCP_SKB_CB(skb)->seq + skb->len - (*seq);
- if ((available < target) &&
- (len > sysctl_tcp_dma_copybreak) && !(flags & MSG_PEEK) &&
- !sysctl_tcp_low_latency && __get_cpu_var(softnet_data).net_dma) {
- preempt_enable_no_resched();
- tp->ucopy.pinned_list = dma_pin_iovec_pages(msg->msg_iov, len);
- } else
- preempt_enable_no_resched();
+ {
+ int available = 0;
+
+ if (skb)
+ available = TCP_SKB_CB(skb)->seq + skb->len - (*seq);
+ if ((available < target) &&
+ (len > sysctl_tcp_dma_copybreak) && !(flags & MSG_PEEK) &&
+ !sysctl_tcp_low_latency &&
+ __get_cpu_var(softnet_data).net_dma) {
+ preempt_enable_no_resched();
+ tp->ucopy.pinned_list =
+ dma_pin_iovec_pages(msg->msg_iov, len);
+ } else {
+ preempt_enable_no_resched();
+ }
+ }
#endif
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/
[PATCH 1/9] ioatdma: Push pending transactions to hardware more frequently
Every 20 descriptors turns out to be to few append commands with
newer/faster CPUs. Pushing every 4 still cuts down on MMIO writes to an
acceptable level without letting the DMA engine run out of work.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
index 8e87261..0f77a9d 100644
--- a/drivers/dma/ioatdma.c
+++ b/drivers/dma/ioatdma.c
@@ -310,7 +310,7 @@ static dma_cookie_t do_ioat_dma_memcpy(struct ioat_dma_chan
*ioat_chan,
list_splice_init(_chain, ioat_chan->used_desc.prev);
ioat_chan->pending += desc_count;
- if (ioat_chan->pending >= 20) {
+ if (ioat_chan->pending >= 4) {
append = 1;
ioat_chan->pending = 0;
}
@@ -818,7 +818,7 @@ static void __devexit ioat_remove(struct pci_dev *pdev)
}
/* MODULE API */
-MODULE_VERSION("1.7");
+MODULE_VERSION("1.9");
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Intel Corporation");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/9] drivers/dma: handle sysfs errors
From: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/dmaengine.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 1527804..dc65773 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -312,7 +312,7 @@ void dma_async_client_chan_request(struct dma_client
*client,
int dma_async_device_register(struct dma_device *device)
{
static int id;
- int chancnt = 0;
+ int chancnt = 0, rc;
struct dma_chan* chan;
if (!device)
@@ -334,8 +334,15 @@ int dma_async_device_register(struct dma_device *device)
snprintf(chan->class_dev.class_id, BUS_ID_SIZE, "dma%dchan%d",
device->dev_id, chan->chan_id);
+ rc = class_device_register(>class_dev);
+ if (rc) {
+ chancnt--;
+ free_percpu(chan->local);
+ chan->local = NULL;
+ goto err_out;
+ }
+
kref_get(>refcount);
- class_device_register(>class_dev);
}
mutex_lock(_list_mutex);
@@ -345,6 +352,17 @@ int dma_async_device_register(struct dma_device *device)
dma_chans_rebalance();
return 0;
+
+err_out:
+ list_for_each_entry(chan, >channels, device_node) {
+ if (chan->local == NULL)
+ continue;
+ kref_put(>refcount, dma_async_device_cleanup);
+ class_device_unregister(>class_dev);
+ chancnt--;
+ free_percpu(chan->local);
+ }
+ return rc;
}
/**
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] I/OAT: Add entries to MAINTAINERS for the DMA memcpy subsystem and ioatdma
Signed-off-by: Chris Leech <[EMAIL PROTECTED]> --- MAINTAINERS | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1dfba85..2dd5d23 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1156,6 +1156,12 @@ M: [EMAIL PROTECTED] L: netdev@vger.kernel.org S: Maintained +DMA GENERIC MEMCPY SUBSYSTEM +P: Chris Leech +M: [EMAIL PROTECTED] +L: linux-kernel@vger.kernel.org +S: Maintained + DOCBOOK FOR DOCUMENTATION P: Randy Dunlap M: [EMAIL PROTECTED] @@ -1777,6 +1783,12 @@ P: Tigran Aivazian M: [EMAIL PROTECTED] S: Maintained +INTEL I/OAT DMA DRIVER +P: Chris Leech +M: [EMAIL PROTECTED] +L: linux-kernel@vger.kernel.org +S: Supported + INTEL IXP4XX RANDOM NUMBER GENERATOR SUPPORT P: Deepak Saxena M: [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 7/9] I/OAT: Only offload copies for TCP when there will be a context switch
The performance wins come with having the DMA copy engine doing the copies
in parallel with the context switch. If there is enough data ready on the
socket at recv time just use a regular copy.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
net/ipv4/tcp.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 74c4d10..5ccd5e1 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1110,6 +1110,8 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk,
struct msghdr *msg,
long timeo;
struct task_struct *user_recv = NULL;
int copied_early = 0;
+ int available = 0;
+ struct sk_buff *skb;
lock_sock(sk);
@@ -1136,7 +1138,11 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk,
struct msghdr *msg,
#ifdef CONFIG_NET_DMA
tp->ucopy.dma_chan = NULL;
preempt_disable();
- if ((len > sysctl_tcp_dma_copybreak) && !(flags & MSG_PEEK) &&
+ skb = skb_peek_tail(>sk_receive_queue);
+ if (skb)
+ available = TCP_SKB_CB(skb)->seq + skb->len - (*seq);
+ if ((available < target) &&
+ (len > sysctl_tcp_dma_copybreak) && !(flags & MSG_PEEK) &&
!sysctl_tcp_low_latency && __get_cpu_var(softnet_data).net_dma) {
preempt_enable_no_resched();
tp->ucopy.pinned_list = dma_pin_iovec_pages(msg->msg_iov, len);
@@ -1145,7 +1151,6 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk,
struct msghdr *msg,
#endif
do {
- struct sk_buff *skb;
u32 offset;
/* Are we at urgent data? Stop if we have read anything or have
SIGURG pending. */
@@ -1433,7 +1438,6 @@ skip_copy:
#ifdef CONFIG_NET_DMA
if (tp->ucopy.dma_chan) {
- struct sk_buff *skb;
dma_cookie_t done, used;
dma_async_memcpy_issue_pending(tp->ucopy.dma_chan);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/9] I/OAT: Add documentation for the tcp_dma_copybreak sysctl
Signed-off-by: Chris Leech <[EMAIL PROTECTED]> --- Documentation/networking/ip-sysctl.txt |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index d3aae1f..9541691 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -413,6 +413,12 @@ tcp_workaround_signed_windows - BOOLEAN not receive a window scaling option from them. Default: 0 +tcp_dma_copybreak - INTEGER + Lower limit, in bytes, of the size of socket reads that will be + offloaded to a DMA copy engine, if one is present in the system + and CONFIG_NET_DMA is enabled. + Default: 4096 + CIPSOv4 Variables: cipso_cache_enable - BOOLEAN - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/9] I/OAT fixes
Andrew Morton (1): I/OAT: warning fix Chris Leech (6): ioatdma: Push pending transactions to hardware more frequently ioatdma: Remove the wrappers around read(bwl)/write(bwl) in ioatdma ioatdma: Remove the use of writeq from the ioatdma driver I/OAT: Add documentation for the tcp_dma_copybreak sysctl I/OAT: Add entries to MAINTAINERS for the DMA memcpy subsystem and ioatdma I/OAT: Only offload copies for TCP when there will be a context switch Dan Aloni (1): I/OAT: fix I/OAT for kexec Jeff Garzik (1): drivers/dma: handle sysfs errors Documentation/networking/ip-sysctl.txt |6 + MAINTAINERS| 12 +++ drivers/dma/dmaengine.c| 22 +- drivers/dma/ioatdma.c | 81 -- drivers/dma/ioatdma_io.h | 118 - net/ipv4/tcp.c | 26 +-- 6 files changed, 100 insertions(+), 165 deletions(-) -- Chris Leech <[EMAIL PROTECTED]> I/O Acceleration Technology Software Development LAN Access Division / Digital Enterprise Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] I/OAT: fix I/OAT for kexec
Under kexec, I/OAT initialization breaks over busy resources because the
previous kernel did not release them.
I'm not sure this fix can be considered a complete one but it works for me.
I guess something similar to the *_remove method should occur there..
Signed-off-by: Dan Aloni <[EMAIL PROTECTED]>
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
index cbf93ca..1d259e5 100644
--- a/drivers/dma/ioatdma.c
+++ b/drivers/dma/ioatdma.c
@@ -41,6 +41,7 @@
/* internal functions */
static int __devinit ioat_probe(struct pci_dev *pdev, const struct
pci_device_id *ent);
+static void ioat_shutdown(struct pci_dev *pdev);
static void __devexit ioat_remove(struct pci_dev *pdev);
static int enumerate_dma_channels(struct ioat_device *device)
@@ -557,6 +558,7 @@ static struct pci_driver ioat_pci_drv = {
.name = "ioatdma",
.id_table = ioat_pci_tbl,
.probe = ioat_probe,
+ .shutdown = ioat_shutdown,
.remove = __devexit_p(ioat_remove),
};
@@ -781,9 +783,20 @@ err_request_regions:
err_set_dma_mask:
pci_disable_device(pdev);
err_enable_device:
+
+ printk(KERN_ERR "Intel(R) I/OAT DMA Engine initialization failed\n");
+
return err;
}
+static void ioat_shutdown(struct pci_dev *pdev)
+{
+ struct ioat_device *device;
+ device = pci_get_drvdata(pdev);
+
+ dma_async_device_unregister(>common);
+}
+
static void __devexit ioat_remove(struct pci_dev *pdev)
{
struct ioat_device *device;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/9] ioatdma: Remove the wrappers around read(bwl)/write(bwl) in ioatdma
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c| 60 +++
drivers/dma/ioatdma_io.h | 118 --
2 files changed, 28 insertions(+), 150 deletions(-)
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
index 0f77a9d..ec11131 100644
--- a/drivers/dma/ioatdma.c
+++ b/drivers/dma/ioatdma.c
@@ -32,7 +32,6 @@
#include
#include
#include "ioatdma.h"
-#include "ioatdma_io.h"
#include "ioatdma_registers.h"
#include "ioatdma_hw.h"
@@ -51,8 +50,8 @@ static int enumerate_dma_channels(struct ioat_device *device)
int i;
struct ioat_dma_chan *ioat_chan;
- device->common.chancnt = ioatdma_read8(device, IOAT_CHANCNT_OFFSET);
- xfercap_scale = ioatdma_read8(device, IOAT_XFERCAP_OFFSET);
+ device->common.chancnt = readb(device->reg_base + IOAT_CHANCNT_OFFSET);
+ xfercap_scale = readb(device->reg_base + IOAT_XFERCAP_OFFSET);
xfercap = (xfercap_scale == 0 ? -1 : (1UL << xfercap_scale));
for (i = 0; i < device->common.chancnt; i++) {
@@ -123,7 +122,7 @@ static int ioat_dma_alloc_chan_resources(struct dma_chan
*chan)
* In-use bit automatically set by reading chanctrl
* If 0, we got it, if 1, someone else did
*/
- chanctrl = ioatdma_chan_read16(ioat_chan, IOAT_CHANCTRL_OFFSET);
+ chanctrl = readw(ioat_chan->reg_base + IOAT_CHANCTRL_OFFSET);
if (chanctrl & IOAT_CHANCTRL_CHANNEL_IN_USE)
return -EBUSY;
@@ -132,12 +131,12 @@ static int ioat_dma_alloc_chan_resources(struct dma_chan
*chan)
IOAT_CHANCTRL_ERR_INT_EN |
IOAT_CHANCTRL_ANY_ERR_ABORT_EN |
IOAT_CHANCTRL_ERR_COMPLETION_EN;
-ioatdma_chan_write16(ioat_chan, IOAT_CHANCTRL_OFFSET, chanctrl);
+writew(chanctrl, ioat_chan->reg_base + IOAT_CHANCTRL_OFFSET);
- chanerr = ioatdma_chan_read32(ioat_chan, IOAT_CHANERR_OFFSET);
+ chanerr = readl(ioat_chan->reg_base + IOAT_CHANERR_OFFSET);
if (chanerr) {
printk("IOAT: CHANERR = %x, clearing\n", chanerr);
- ioatdma_chan_write32(ioat_chan, IOAT_CHANERR_OFFSET, chanerr);
+ writel(chanerr, ioat_chan->reg_base + IOAT_CHANERR_OFFSET);
}
/* Allocate descriptors */
@@ -161,10 +160,10 @@ static int ioat_dma_alloc_chan_resources(struct dma_chan
*chan)
_chan->completion_addr);
memset(ioat_chan->completion_virt, 0,
sizeof(*ioat_chan->completion_virt));
- ioatdma_chan_write32(ioat_chan, IOAT_CHANCMP_OFFSET_LOW,
- ((u64) ioat_chan->completion_addr) & 0x);
- ioatdma_chan_write32(ioat_chan, IOAT_CHANCMP_OFFSET_HIGH,
- ((u64) ioat_chan->completion_addr) >> 32);
+ writel(((u64) ioat_chan->completion_addr) & 0x,
+ ioat_chan->reg_base + IOAT_CHANCMP_OFFSET_LOW);
+ writel(((u64) ioat_chan->completion_addr) >> 32,
+ ioat_chan->reg_base + IOAT_CHANCMP_OFFSET_HIGH);
ioat_start_null_desc(ioat_chan);
return i;
@@ -182,7 +181,7 @@ static void ioat_dma_free_chan_resources(struct dma_chan
*chan)
ioat_dma_memcpy_cleanup(ioat_chan);
- ioatdma_chan_write8(ioat_chan, IOAT_CHANCMD_OFFSET, IOAT_CHANCMD_RESET);
+ writeb(IOAT_CHANCMD_RESET, ioat_chan->reg_base + IOAT_CHANCMD_OFFSET);
spin_lock_bh(_chan->desc_lock);
list_for_each_entry_safe(desc, _desc, _chan->used_desc, node) {
@@ -210,9 +209,9 @@ static void ioat_dma_free_chan_resources(struct dma_chan
*chan)
ioat_chan->last_completion = ioat_chan->completion_addr = 0;
/* Tell hw the chan is free */
- chanctrl = ioatdma_chan_read16(ioat_chan, IOAT_CHANCTRL_OFFSET);
+ chanctrl = readw(ioat_chan->reg_base + IOAT_CHANCTRL_OFFSET);
chanctrl &= ~IOAT_CHANCTRL_CHANNEL_IN_USE;
- ioatdma_chan_write16(ioat_chan, IOAT_CHANCTRL_OFFSET, chanctrl);
+ writew(chanctrl, ioat_chan->reg_base + IOAT_CHANCTRL_OFFSET);
}
/**
@@ -318,9 +317,8 @@ static dma_cookie_t do_ioat_dma_memcpy(struct ioat_dma_chan
*ioat_chan,
spin_unlock_bh(_chan->desc_lock);
if (append)
- ioatdma_chan_write8(ioat_chan,
- IOAT_CHANCMD_OFFSET,
- IOAT_CHANCMD_APPEND);
+ writeb(IOAT_CHANCMD_APPEND,
+ ioat_chan->reg_base + IOAT_CHANCMD_OFFSET);
return cookie;
}
@@ -417,9 +415,8 @@ static void ioat_dma_memcpy_issue_pending(struct dma_chan
*chan)
if (ioat_chan->pending != 0) {
ioat_chan->pending = 0;
- ioatdma_chan_write8(ioat_chan,
- IOAT_CHANCMD_OFFSET,
- IOAT_CHANCMD_APPEND);
+ writeb(IOAT_CHANCMD_APPEND,
+ ioat_chan->reg_base
[PATCH 4/9] ioatdma: Remove the use of writeq from the ioatdma driver
There's only one now anyway, and it's not in a performance path, so make it behave the same on 32-bit and 64-bit CPUs. Signed-off-by: Chris Leech <[EMAIL PROTECTED]> --- drivers/dma/ioatdma.c | 10 -- 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c index ec11131..cbf93ca 100644 --- a/drivers/dma/ioatdma.c +++ b/drivers/dma/ioatdma.c @@ -608,13 +608,11 @@ static void ioat_start_null_desc(struct ioat_dma_chan *ioat_chan) list_add_tail(>node, _chan->used_desc); spin_unlock_bh(_chan->desc_lock); -#if (BITS_PER_LONG == 64) - writeq(desc->phys, ioat_chan->reg_base + IOAT_CHAINADDR_OFFSET); -#else - writel((u32) desc->phys, + writel(((u64) desc->phys) & 0x, ioat_chan->reg_base + IOAT_CHAINADDR_OFFSET_LOW); - writel(0, ioat_chan->reg_base + IOAT_CHAINADDR_OFFSET_HIGH); -#endif + writel(((u64) desc->phys) >> 32, + ioat_chan->reg_base + IOAT_CHAINADDR_OFFSET_HIGH); + writeb(IOAT_CHANCMD_START, ioat_chan->reg_base + IOAT_CHANCMD_OFFSET); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 00/13] Syslets, "Threadlets", generic AIO support, v3
On Fri, 2 Mar 2007, Nicholas Miell wrote: > On Fri, 2007-03-02 at 16:52 -0800, Davide Libenzi wrote: > > On Fri, 2 Mar 2007, Nicholas Miell wrote: > > > > > The point Ingo was making is that the x86 ABI already requires the FPU > > > context to be saved before *all* function calls. > > > > I've not seen that among Ingo's points, but yeah some status is caller > > saved. But, aren't things like status word and control bits callee saved? > > If that's the case, it might require proper handling. > > > > Ingo mentioned it in one of the parts you cut out of your reply: > > > and here is where thinking about threadlets as a function call and not > > as an asynchronous context helps alot: the classic gcc convention for > > FPU use & function calls should apply: gcc does not call an external > > function with an in-use FPU stack/register, it always neatly unuses it, > > as no FPU register is callee-saved, all are caller-saved. > > The i386 psABI is ancient (i.e. it predates SSE, so no mention of the > XMM or MXCSR registers) and a bit vague (no mention at all of the FP > status word), but I'm fairly certain that Ingo is right. I'm not sure if that's the case. I'd be happy if it was, but I'm afraid it's not. Status word and control bits should not be changed from underneath userspace AFAIK. The ABI I remember tells me that those are callee saved. A quick gcc asm test tells me that too. And assuming that's the case, why don't we have a smarter unlazy_fpu() then, that avoid FPU context sync if we're scheduled while inside a syscall (this is no different than an enter inside sys_async_exec - userspace should have taken care of it)? IMO a syscall enter should not assume that userspace took care of saving the whole FPU context. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] I/OAT fixes
On 3/2/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Where is the patch for review? I'm sending them now. These have been posted before, and other than one objectionable change that I dropped the first time around they quietly went nowhere. - Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ehea: Optional TX/RX path optimized for SMP
Jan-Bernd Themann <[EMAIL PROTECTED]> writes: > > Are there any concerns about this approach? Yes. You should fix the NAPI code instead of trying to work around it. -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: The performance and behaviour of the anti-fragmentation related patches
On Fri, 2 Mar 2007 17:40:04 -0800 William Lee Irwin III <[EMAIL PROTECTED]> wrote: > On Fri, Mar 02, 2007 at 02:59:06PM -0800, Andrew Morton wrote: > > Somehow I don't believe that a person or organisation which is incapable of > > preparing even a simple testcase will be capable of fixing problems such as > > this without breaking things. > > My gut feeling is to agree, but I get nagging doubts when I try to > think of how to boil things like [major benchmarks whose names are > trademarked/copyrighted/etc. censored] down to simple testcases. Some > other things are obvious but require vast resources, like zillions of > disks fooling throttling/etc. heuristics of ancient downrev kernels. noo. You're approaching it from the wrong direction. Step 1 is to understand what is happening on the affected production system. Completely. Once that is fully understood then it is a relatively simple matter to concoct a test case which triggers the same failure mode. It is very hard to go the other way: to poke around with various stress tests which you think are doing something similar to what you think the application does in the hope that similar symptoms will trigger so you can then work out what the kernel is doing. yuk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/9] 2.6.19-stable review
Greg KH wrote: > On Tue, Feb 27, 2007 at 03:23:05PM -0500, Michael Krufky wrote: >> Greg KH wrote: >>> This is the start of the stable review cycle for the 2.6.19.6 release. >>> >>> This will probably be the last release of the 2.6.19-stable series, so >>> if there are patches that you feel should be applied to that tree, >>> please let me know. >>> >>> There are 9 patches in this series, all will be posted as a response to >>> this one. If anyone has any issues with these being applied, please let >>> us know. If anyone is a maintainer of the proper subsystem, and wants >>> to add a Signed-off-by: line to the patch, please respond with it. >>> >>> These patches are sent out with a number of different people on the Cc: >>> line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to >>> add your name to the list. If you want to be off the reviewer list, >>> also email us. >>> >>> Responses should be made by Thursday March 1 00:00 UTC. Anything >>> received after that time might be too late. >>> >>> The whole patch set can be downloaded at: >>> kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.19.6-rc1.gz >>> >>> thanks, >>> >>> the -stable release team >> Greg, >> >> I still have three DVB patches that need to go to 2.6.19.y, the dvbdev patch >> being most important. I sent this dvbdev patch to you during the 2.6.19.5 >> review period and expected it to surface this time around, but maybe our >> email >> paths have crossed. >> >> Since I am unable to send patches inline from my current location, I've >> posted >> the three pending patches for 2.6.19.y here: >> >> http://linuxtv.org/~mkrufky/stable/2.6.19.y/ >> >> Please add these if possible. Again, the >> "dvbdev-fix-illegal-re-usage-of-fileoperations-struct" patch is the most >> important one of these. > > Argh, I forgot these :( > > Do you want me to do a new 2.6.19-stable release with these patches in > it? It's my fault I didn't get this in, so I don't really mind if you > feel it is important enough (it doesn't take that long to spin another > kernel release.) > > thanks, > > greg k-h The dvbdev patch is pretty important, fixes a horrible problem, although the case for it to occur is rare. The other two patches are of the "obviously correct - minimal change" type. If it isnt too much trouble, then yes, it is worth it to push a new release because of the dvbdev patch. However, please chop the "backported from" and "cherry picked from" lines from those patches. I cherry-picked them from Mauro's tree, but he wiped it out and re-pushed those changes in before Linus merged them so, the actual changesets in Linus' tree have different hashes. (i removed those old hashes from the patches that I posted on linuxtv.org) As for the 2.6.20.y patches, should I email those to you inline or can you just grab them from the linuxtv.org www server? ( http://linuxtv.org/~mkrufky/stable/2.6.20.y/ ) Thanks, Mike 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: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On Fri, Mar 02, 2007 at 05:36:01PM -0800, Nicholas Miell wrote: > > as an asynchronous context helps alot: the classic gcc convention for > > FPU use & function calls should apply: gcc does not call an external > > function with an in-use FPU stack/register, it always neatly unuses it, > > as no FPU register is callee-saved, all are caller-saved. > > The i386 psABI is ancient (i.e. it predates SSE, so no mention of the > XMM or MXCSR registers) and a bit vague (no mention at all of the FP > status word), but I'm fairly certain that Ingo is right. The FPU status word *must* be saved, as the rounding behaviour and error mode bits are assumed to be preserved. Iow, yes, there is state which is required. -ben -- "Time is of no importance, Mr. President, only life is important." Don't Email: <[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/
[git patches] libata fixes
Notes:
1) The patches credited to me are really extractions of Alan's patches.
2) In particular, the 'change master/slave IDENTIFY order' has a wide
(but hopefully not negative) impact, as mentioned in the thread. Since
pata_* drivers are Officially(tm) considered more experimental than
drivers/ide, and since most SATA devices are one-per-port (no slave),
the biggest consideration is really master/slave on ata_piix.
3) Tejun's CONFIG_PM stuff might look like a cleanup, but IMO it is
indeed a bug fix. As Nigel C noted in the related thread, this can
probably be cleaned up further with some hopeful macros, but let's go
ahead and get things compiling correctly.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ahci.c | 14 ++
drivers/ata/ata_generic.c |4
drivers/ata/ata_piix.c |4
drivers/ata/libata-core.c | 32 +++-
drivers/ata/libata-eh.c | 29 +
drivers/ata/libata-scsi.c |2 ++
drivers/ata/pata_ali.c |6 ++
drivers/ata/pata_amd.c |6 ++
drivers/ata/pata_atiixp.c |4
drivers/ata/pata_cmd64x.c |8 +++-
drivers/ata/pata_cs5520.c |6 ++
drivers/ata/pata_cs5530.c |6 ++
drivers/ata/pata_cs5535.c |4
drivers/ata/pata_cypress.c |4
drivers/ata/pata_efar.c |4
drivers/ata/pata_hpt366.c |7 ++-
drivers/ata/pata_hpt3x3.c |6 ++
drivers/ata/pata_it8213.c |4
drivers/ata/pata_it821x.c |6 ++
drivers/ata/pata_jmicron.c |7 +++
drivers/ata/pata_legacy.c | 18 ++
drivers/ata/pata_marvell.c |4
drivers/ata/pata_mpc52xx.c |4
drivers/ata/pata_mpiix.c|4
drivers/ata/pata_netcell.c |4
drivers/ata/pata_ns87410.c |4
drivers/ata/pata_oldpiix.c |4
drivers/ata/pata_opti.c |4
drivers/ata/pata_optidma.c |4
drivers/ata/pata_pdc202xx_old.c |4
drivers/ata/pata_qdi.c | 12
drivers/ata/pata_radisys.c |4
drivers/ata/pata_rz1000.c |6 ++
drivers/ata/pata_sc1200.c |7 +++
drivers/ata/pata_scc.c |2 ++
drivers/ata/pata_serverworks.c |6 ++
drivers/ata/pata_sil680.c |8
drivers/ata/pata_sis.c |4
drivers/ata/pata_sl82c105.c |3 +++
drivers/ata/pata_triflex.c |4
drivers/ata/pata_via.c |6 ++
drivers/ata/sata_inic162x.c |7 ++-
drivers/ata/sata_nv.c | 16
drivers/ata/sata_sil.c |2 ++
drivers/ata/sata_sil24.c|2 ++
include/linux/libata.h |7 +--
46 files changed, 299 insertions(+), 14 deletions(-)
Alan Cox (2):
libata-core: Fix simplex handling
pata_qdi: Fix initialisation
Jeff Garzik (3):
[libata] change master/slave IDENTIFY order
[libata] pata_{legacy,sc1200,sl82c105}: add missing hooks
[libata] pata_cmd64x: fix driver description in comments
Tejun Heo (3):
libata: add missing PM callbacks
libata: add missing CONFIG_PM in LLDs
libata: add CONFIG_PM to libata core layer
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 1539734..43cc43d 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -219,10 +219,12 @@ static void ahci_thaw(struct ata_port *ap);
static void ahci_error_handler(struct ata_port *ap);
static void ahci_vt8251_error_handler(struct ata_port *ap);
static void ahci_post_internal_cmd(struct ata_queued_cmd *qc);
+#ifdef CONFIG_PM
static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg);
static int ahci_port_resume(struct ata_port *ap);
static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
static int ahci_pci_device_resume(struct pci_dev *pdev);
+#endif
static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
@@ -241,8 +243,10 @@ static struct scsi_host_template ahci_sht = {
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+#ifdef CONFIG_PM
.suspend= ata_scsi_device_suspend,
.resume = ata_scsi_device_resume,
+#endif
};
static const struct ata_port_operations ahci_ops = {
@@ -271,8 +275,10 @@ static const struct ata_port_operations ahci_ops = {
.error_handler = ahci_error_handler,
.post_internal_cmd = ahci_post_internal_cmd,
+#ifdef CONFIG_PM
.port_suspend = ahci_port_suspend,
Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On Fri, 2007-03-02 at 16:52 -0800, Davide Libenzi wrote: > On Fri, 2 Mar 2007, Nicholas Miell wrote: > > > The point Ingo was making is that the x86 ABI already requires the FPU > > context to be saved before *all* function calls. > > I've not seen that among Ingo's points, but yeah some status is caller > saved. But, aren't things like status word and control bits callee saved? > If that's the case, it might require proper handling. > Ingo mentioned it in one of the parts you cut out of your reply: > and here is where thinking about threadlets as a function call and not > as an asynchronous context helps alot: the classic gcc convention for > FPU use & function calls should apply: gcc does not call an external > function with an in-use FPU stack/register, it always neatly unuses it, > as no FPU register is callee-saved, all are caller-saved. The i386 psABI is ancient (i.e. it predates SSE, so no mention of the XMM or MXCSR registers) and a bit vague (no mention at all of the FP status word), but I'm fairly certain that Ingo is right. -- Nicholas Miell <[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: The performance and behaviour of the anti-fragmentation related patches
On Fri, Mar 02, 2007 at 02:59:06PM -0800, Andrew Morton wrote: > What is it with vendors finding MM problems and either not fixing them or > kludging around them and not telling the upstream maintainers about *any* > of it? I'm not in the business of defending vendors, but a lot of times the base is so far downrev it's difficult to relate it to much of anything current. It may be best not to say precisely how far downrev things can get, since some of these things are so old even distro vendors won't touch them. On Fri, Mar 02, 2007 at 02:59:06PM -0800, Andrew Morton wrote: > Somehow I don't believe that a person or organisation which is incapable of > preparing even a simple testcase will be capable of fixing problems such as > this without breaking things. My gut feeling is to agree, but I get nagging doubts when I try to think of how to boil things like [major benchmarks whose names are trademarked/copyrighted/etc. censored] down to simple testcases. Some other things are obvious but require vast resources, like zillions of disks fooling throttling/etc. heuristics of ancient downrev kernels. I guess for those sorts of things the voodoo incantations, chicken blood, and carcasses of freshly slaughtered goats come out. Might as well throw in a Tarot reading and some tea leaves while I'm at it. My tack on basic stability was usually testbooting on several arches, which various people have an active disinterest in (suggesting, for example, that I throw out all of my sparc32 systems and replace them with Opterons, or that anything that goes wrong on ia64 is not only irrelevant but also that neither I nor anyone else should ever fix them; you know who you are). It's become clear to me that this is insufficient, and that I'll need to start using some sort of suite of regression tests, at the very least to save myself the embarrassment of acking a patch that oopses when exercised, but also to elevate the standard. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-rc2-mm1
On Sat, 03 Mar 2007 02:22:59 +0100 Michal Piotrowski <[EMAIL PROTECTED]> wrote: > Andrew Morton napisa__(a): > > On Sat, 3 Mar 2007 00:42:33 +0100 > > "Michal Piotrowski" <[EMAIL PROTECTED]> wrote: > > > >> On 02/03/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > >>> Temporarily at > >>> > >>> http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/ > >>> > >> I have noticed some strange system behavior. When i try to build a > >> kernel (medium load) - X, keyboard, mouse and sound hangs. > >> > >> I can ping machine and I can use magic SysRq key, but that's all. > >> > >> 2.6.20-mm2 was fine, 2.6.21-rc2 works well (over 800 patches since > >> 2.6.20-mm2 - great...) > >> > >> NIL (Nothing Interesting in Logs) > >> > > > > Can we see the sysrq-T output please? > > > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc2-mm1/sys.log > Well that's all very dull - everything's just sitting there asleep. If it was just X then I'd suspect the psmouse changes (are you PS2 or USB?) Or I'd suspect that the entire interrupt system has gone bust, but you're still able to do sysrq. How are you doing sysrq, btw? Serial console? alt-F7 into a vgaconsole? Are you able to log in from another machine via ssh? Are you able to log into it via ssh before it hangs and run things like `top' and `watch -n1 cat /proc/interrupts', see what they do when it hangs? Is the CPU idle when it hangs, or is it busy? If busy, what does sysrq-P say? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.21-rc2] ahci: RAID mode SATA patch for Intel ICH9M
This patch adds the Intel ICH9M RAID controller DID for SATA support.
Signed-off-by: Jason Gaston <[EMAIL PROTECTED]>
--- linux-2.6.21-rc2/drivers/ata/ahci.c.orig2007-03-02 17:28:00.0
-0800
+++ linux-2.6.21-rc2/drivers/ata/ahci.c 2007-03-02 17:28:30.0 -0800
@@ -380,6 +380,7 @@
{ PCI_VDEVICE(INTEL, 0x2929), board_ahci_pi }, /* ICH9M */
{ PCI_VDEVICE(INTEL, 0x292a), board_ahci_pi }, /* ICH9M */
{ PCI_VDEVICE(INTEL, 0x292b), board_ahci_pi }, /* ICH9M */
+ { PCI_VDEVICE(INTEL, 0x292c), board_ahci_pi }, /* ICH9M */
{ PCI_VDEVICE(INTEL, 0x292f), board_ahci_pi }, /* ICH9M */
{ PCI_VDEVICE(INTEL, 0x294d), board_ahci_pi }, /* ICH9 */
{ PCI_VDEVICE(INTEL, 0x294e), board_ahci_pi }, /* ICH9M */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git patches] net driver fixes
Fixes du jour.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
arch/mips/jmr3927/rbhma3100/setup.c |4 -
arch/mips/momentum/jaguar_atx/platform.c| 20 +---
arch/mips/momentum/ocelot_3/platform.c | 20 +---
arch/mips/momentum/ocelot_c/platform.c | 12 +--
drivers/net/cxgb3/version.h |2 +-
drivers/net/mv643xx_eth.c |2 +-
drivers/net/mv643xx_eth.h |4 +-
drivers/net/myri10ge/myri10ge.c | 22 ++--
drivers/net/netxen/netxen_nic.h |4 +-
drivers/net/netxen/netxen_nic_ethtool.c | 144 +--
drivers/net/netxen/netxen_nic_hw.c |5 +-
drivers/net/netxen/netxen_nic_init.c| 23 +++--
drivers/net/netxen/netxen_nic_main.c| 13 +--
drivers/net/netxen/netxen_nic_phan_reg.h|3 +
drivers/net/qla3xxx.c |2 +-
drivers/net/tc35815.c | 13 ---
drivers/net/tulip/de2104x.c |2 +-
drivers/net/tulip/tulip_core.c |2 +-
drivers/net/wireless/bcm43xx/bcm43xx_main.c |5 +-
include/linux/mv643xx.h |2 +-
20 files changed, 87 insertions(+), 217 deletions(-)
Brice Goglin (1):
myri10ge: fix copyright and license
Dale Farnsworth (1):
mv643xx_eth: move mac_addr inside mv643xx_eth_platform_data
Dave Jones (1):
Fix mv643xx_eth compilation.
Divy Le Ray (1):
cxgb3 - Tag driver version
Jeff Garzik (1):
[netdrvr] tulip, de2104x: fix typo: s/__sparc_/__sparc__/
Linsys Contractor Mithlesh Thukral (2):
NetXen: Updates, removal of unsupported features and minor bug fixes.
NetXen: Fix second rmmod failure observed on PowerPC machines.
Ralf Baechle (1):
jmr3927: do not call tc35815_killall().
Ron Mercer (1):
qla3xxx: bugfix for line omitted in previous patch.
Stefano Brivio (1):
bcm43xx: fix for 4309
diff --git a/arch/mips/jmr3927/rbhma3100/setup.c
b/arch/mips/jmr3927/rbhma3100/setup.c
index 7ca3d6d..ecabe5b 100644
--- a/arch/mips/jmr3927/rbhma3100/setup.c
+++ b/arch/mips/jmr3927/rbhma3100/setup.c
@@ -137,10 +137,6 @@ int jmr3927_ccfg_toeon = 0;
static inline void do_reset(void)
{
-#ifdef CONFIG_TC35815
- extern void tc35815_killall(void);
- tc35815_killall();
-#endif
#if 1 /* Resetting PCI bus */
jmr3927_ioc_reg_out(0, JMR3927_IOC_RESET_ADDR);
jmr3927_ioc_reg_out(JMR3927_IOC_RESET_PCI, JMR3927_IOC_RESET_ADDR);
diff --git a/arch/mips/momentum/jaguar_atx/platform.c
b/arch/mips/momentum/jaguar_atx/platform.c
index 3df36ed..771e55f 100644
--- a/arch/mips/momentum/jaguar_atx/platform.c
+++ b/arch/mips/momentum/jaguar_atx/platform.c
@@ -47,11 +47,7 @@ static struct resource mv64x60_eth0_resources[] = {
},
};
-static char eth0_mac_addr[ETH_ALEN];
-
static struct mv643xx_eth_platform_data eth0_pd = {
- .mac_addr = eth0_mac_addr,
-
.tx_sram_addr = MV_SRAM_BASE_ETH0,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
@@ -80,11 +76,7 @@ static struct resource mv64x60_eth1_resources[] = {
},
};
-static char eth1_mac_addr[ETH_ALEN];
-
static struct mv643xx_eth_platform_data eth1_pd = {
- .mac_addr = eth1_mac_addr,
-
.tx_sram_addr = MV_SRAM_BASE_ETH1,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
@@ -113,11 +105,7 @@ static struct resource mv64x60_eth2_resources[] = {
},
};
-static char eth2_mac_addr[ETH_ALEN];
-
-static struct mv643xx_eth_platform_data eth2_pd = {
- .mac_addr = eth2_mac_addr,
-};
+static struct mv643xx_eth_platform_data eth2_pd;
static struct platform_device eth2_device = {
.name = MV643XX_ETH_NAME,
@@ -200,9 +188,9 @@ static int __init mv643xx_eth_add_pds(void)
int ret;
get_mac(mac);
- eth_mac_add(eth0_mac_addr, mac, 0);
- eth_mac_add(eth1_mac_addr, mac, 1);
- eth_mac_add(eth2_mac_addr, mac, 2);
+ eth_mac_add(eth0_pd.mac_addr, mac, 0);
+ eth_mac_add(eth1_pd.mac_addr, mac, 1);
+ eth_mac_add(eth2_pd.mac_addr, mac, 2);
ret = platform_add_devices(mv643xx_eth_pd_devs,
ARRAY_SIZE(mv643xx_eth_pd_devs));
diff --git a/arch/mips/momentum/ocelot_3/platform.c
b/arch/mips/momentum/ocelot_3/platform.c
index 024aef2..b80733f 100644
--- a/arch/mips/momentum/ocelot_3/platform.c
+++ b/arch/mips/momentum/ocelot_3/platform.c
@@ -47,11 +47,7 @@ static struct resource mv64x60_eth0_resources[] = {
},
};
-static char eth0_mac_addr[ETH_ALEN];
-
static struct mv643xx_eth_platform_data eth0_pd = {
- .mac_addr = eth0_mac_addr,
-
.tx_sram_addr = MV_SRAM_BASE_ETH0,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
Re: [RFC] div64_64 support
Stephen Hemminger <[EMAIL PROTECTED]> writes: > Here is another way to handle the 64 bit divide case. > It allows full 64 bit divide by adding the support routine > GCC needs. Not supplying that was intentional by Linus so that people think twice (or more often) before they using such expensive operations. A plain / looks too innocent. Is it really needed by CUBIC anyways? It uses it for getting the cubic root, but the algorithm recommended by Hacker's Delight (great book) doesn't use any divisions at all. Probably better to use a better algorithm without divisions. -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] free swap space of (re)activated pages
Andrew Morton wrote: On Fri, 02 Mar 2007 15:31:19 -0500 Rik van Riel <[EMAIL PROTECTED]> wrote: the attached patch frees the swap space of already resident pages when swap space starts getting tight, instead of only freeing up the swap space taken up by newly swapped in pages. This should result in the swap space of pages that remain resident in memory being freed, allowing kswapd more chances to actually swap a page out (instead of rotating it back onto the active list). Fair enough. How do we work out if this helps things? I suspect it should mostly help on desktop systems that slowly fill up (and run out of) swap. I'm not sure how to create that synthetically. I have seen that swap is kept free much easier in a qsbench test, but that's probably not a very good test since it swaps things in and out all the time... -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] I/OAT fixes
Chris Leech wrote: Please pull from git://lost.foo-projects.org/~cleech/linux-2.6#master A few drivers/dma and related I/OAT fixes, and missing documentation. These have been posted for review and sitting in MM for a while now. - Chris Andrew Morton (1): I/OAT: warning fix Chris Leech (6): ioatdma: Push pending transactions to hardware more frequently ioatdma: Remove the wrappers around read(bwl)/write(bwl) in ioatdma ioatdma: Remove the use of writeq from the ioatdma driver I/OAT: Add documentation for the tcp_dma_copybreak sysctl I/OAT: Add entries to MAINTAINERS for the DMA memcpy subsystem and ioatdma I/OAT: Only offload copies for TCP when there will be a context switch Dan Aloni (1): I/OAT: fix I/OAT for kexec Jeff Garzik (1): drivers/dma: handle sysfs errors Documentation/networking/ip-sysctl.txt |6 + MAINTAINERS| 12 +++ drivers/dma/dmaengine.c| 22 +- drivers/dma/ioatdma.c | 81 -- drivers/dma/ioatdma_io.h | 118 - net/ipv4/tcp.c | 26 +-- 6 files changed, 100 insertions(+), 165 deletions(-) Where is the patch for review? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System hanging randomly (SMP Kernel 2.6.20) - ATI chipset+Pentium 4HT
El Viernes, 2 de Marzo de 2007, Xavier Callejas escribió: > El Viernes, 2 de Marzo de 2007, Erik Mouw escribió: > > Try to recreate the problem without the proprietary wlan driver. With > > that driver loaded it's impossible to debug. > > > > > > Erik > > Thank you Erik, > > I've deleted madwifi from my current kernel, now I'm connected with > ethernet, but after reboot my laptop just stay 10 minutes and then hang > again :s > > The same beahave, the mouse keeps moving but everything gets stucked, then > the mouse also get hang, I have tu make a force shutdown. > > Thank you, I'll be waiting your answer. Hi, I've keeping running without hang for about 5 hours. I have booted with: Kernel command line: root=/dev/hda3 vga=0x317 resume=/dev/hda2 splash=silent splash=verbose noapic enable_8254_timer enable_timer_pin_1 debug apic=debug acpi=debug And also without the Atheros (midwifi) driveres, I'm steel connected by ethernet. I attach dmesg, and other info. about the current boot. I hope this help. Thank you. -- Xavier Callejas Open Your Mind, Use Open Source. Module Size Used by appletalk 33836 0 ax25 53456 0 ipx26276 0 p8023 2304 1 ipx radeon111008 2 drm73748 3 radeon af_packet 20744 2 ipv6 246976 14 cpufreq_conservative 7304 0 cpufreq_ondemand8204 0 cpufreq_userspace 4520 0 cpufreq_powersave 2048 0 acpi_cpufreq8728 0 speedstep_lib 4868 0 freq_table 4744 2 cpufreq_ondemand,acpi_cpufreq snd_pcm_oss46592 0 snd_mixer_oss 16256 1 snd_pcm_oss snd_seq50672 0 snd_seq_device 8332 1 snd_seq button 7952 0 battery 9988 0 ac 5252 0 apparmor 48788 0 aamatch_pcre 14208 1 apparmor nls_iso8859_1 4352 1 nls_cp437 6016 1 vfat 12288 1 fat48796 1 vfat reiserfs 220544 2 nls_utf82304 1 ntfs 203668 1 loop 16520 0 dm_mod 53324 0 omnibook 57396 0 backlight 6016 1 omnibook usbhid 34144 0 hid22912 1 usbhid ff_memless 5384 1 usbhid pcmcia 35092 0 firmware_class 9600 1 pcmcia 8139too25344 0 mii 5504 1 8139too yenta_socket 25100 1 rsrc_nonstatic 10752 1 yenta_socket ide_cd 36768 0 cdrom 33184 1 ide_cd pcmcia_core37268 3 pcmcia,yenta_socket,rsrc_nonstatic ehci_hcd 29452 0 shpchp 31124 0 ohci_hcd 18820 0 snd_atiixp 19468 1 pci_hotplug29376 1 shpchp i2c_piix4 8460 0 ati_agp 8844 1 usbcore 107092 3 usbhid,ehci_hcd,ohci_hcd i2c_core 20736 1 i2c_piix4 agpgart30408 2 drm,ati_agp snd_atiixp_modem 16264 1 snd_ac97_codec 90404 2 snd_atiixp,snd_atiixp_modem ac97_bus2560 1 snd_ac97_codec snd_pcm77828 4 snd_pcm_oss,snd_atiixp,snd_atiixp_modem,snd_ac97_codec snd_timer 22148 2 snd_seq,snd_pcm snd54276 13 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,snd_atiixp,snd_atiixp_modem,snd_ac97_codec,snd_pcm,snd_timer soundcore 7648 1 snd snd_page_alloc 10120 3 snd_atiixp,snd_atiixp_modem,snd_pcm parport_pc 36708 0 lp 11172 0 parport33736 2 parport_pc,lp ext3 128008 2 mbcache 8452 1 ext3 jbd64052 1 ext3 edd 9284 0 fan 4868 0 thermal14088 0 processor 30140 2 acpi_cpufreq,thermal atiixp 6288 0 [permanent] ide_disk 15744 9 ide_core 115656 3 ide_cd,atiixp,ide_disk Linux version 2.6.20-245-xavier ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP Mon Feb 26 15:00:17 CST 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009f800 end: 0009f800 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009f800 size: 0800 end: 000a type: 2 copy_e820_map() start: 000d size: 8000 end: 000d8000 type: 2 copy_e820_map() start: 000e4000 size: 0001c000 end: 0010 type: 2 copy_e820_map() start: 0010 size: 1be7 end: 1bf7 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start:
Re: [PATCH] schedule wext/rtnl for removal
John W. Linville wrote: From: Johannes Berg <[EMAIL PROTECTED]> Since wext is being replaced as fast as we can (it'll probably stick around for legacy drivers though) and the wext/netlink stuff was never really used, this schedules it for removal. The removal schedule is tight but there are no users of the code, the main user of the wext user interface are the wireless-tools, they only have an alpha version using the netlink interface and even that is incomplete. Signed-off-by: Johannes Berg <[EMAIL PROTECTED]> Signed-off-by: John W. Linville <[EMAIL PROTECTED]> --- Which you consider applying this feature-removal-schedule.txt patch in the current (i.e. pre-2.6.21) timeframe? Documentation/feature-removal-schedule.txt | 12 1 file changed, 12 insertions(+) When you send this sort of stuff, spam as many lists as reasonable. The removal of a recently-added userspace ABI is an unusual event, and IMO needs discussing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-rc2-mm1
Andrew Morton napisał(a): > On Sat, 3 Mar 2007 00:42:33 +0100 > "Michal Piotrowski" <[EMAIL PROTECTED]> wrote: > >> On 02/03/07, Andrew Morton <[EMAIL PROTECTED]> wrote: >>> Temporarily at >>> >>> http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/ >>> >> I have noticed some strange system behavior. When i try to build a >> kernel (medium load) - X, keyboard, mouse and sound hangs. >> >> I can ping machine and I can use magic SysRq key, but that's all. >> >> 2.6.20-mm2 was fine, 2.6.21-rc2 works well (over 800 patches since >> 2.6.20-mm2 - great...) >> >> NIL (Nothing Interesting in Logs) >> > > Can we see the sysrq-T output please? > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc2-mm1/sys.log Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/9] 2.6.19-stable review
On Tue, Feb 27, 2007 at 03:23:05PM -0500, Michael Krufky wrote: > Greg KH wrote: > > This is the start of the stable review cycle for the 2.6.19.6 release. > > > > This will probably be the last release of the 2.6.19-stable series, so > > if there are patches that you feel should be applied to that tree, > > please let me know. > > > > There are 9 patches in this series, all will be posted as a response to > > this one. If anyone has any issues with these being applied, please let > > us know. If anyone is a maintainer of the proper subsystem, and wants > > to add a Signed-off-by: line to the patch, please respond with it. > > > > These patches are sent out with a number of different people on the Cc: > > line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to > > add your name to the list. If you want to be off the reviewer list, > > also email us. > > > > Responses should be made by Thursday March 1 00:00 UTC. Anything > > received after that time might be too late. > > > > The whole patch set can be downloaded at: > > kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.19.6-rc1.gz > > > > thanks, > > > > the -stable release team > > Greg, > > I still have three DVB patches that need to go to 2.6.19.y, the dvbdev patch > being most important. I sent this dvbdev patch to you during the 2.6.19.5 > review period and expected it to surface this time around, but maybe our email > paths have crossed. > > Since I am unable to send patches inline from my current location, I've posted > the three pending patches for 2.6.19.y here: > > http://linuxtv.org/~mkrufky/stable/2.6.19.y/ > > Please add these if possible. Again, the > "dvbdev-fix-illegal-re-usage-of-fileoperations-struct" patch is the most > important one of these. Argh, I forgot these :( Do you want me to do a new 2.6.19-stable release with these patches in it? It's my fault I didn't get this in, so I don't really mind if you feel it is important enough (it doesn't take that long to spin another kernel release.) 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/
[GIT PULL] I/OAT fixes
Please pull from git://lost.foo-projects.org/~cleech/linux-2.6#master A few drivers/dma and related I/OAT fixes, and missing documentation. These have been posted for review and sitting in MM for a while now. - Chris Andrew Morton (1): I/OAT: warning fix Chris Leech (6): ioatdma: Push pending transactions to hardware more frequently ioatdma: Remove the wrappers around read(bwl)/write(bwl) in ioatdma ioatdma: Remove the use of writeq from the ioatdma driver I/OAT: Add documentation for the tcp_dma_copybreak sysctl I/OAT: Add entries to MAINTAINERS for the DMA memcpy subsystem and ioatdma I/OAT: Only offload copies for TCP when there will be a context switch Dan Aloni (1): I/OAT: fix I/OAT for kexec Jeff Garzik (1): drivers/dma: handle sysfs errors Documentation/networking/ip-sysctl.txt |6 + MAINTAINERS| 12 +++ drivers/dma/dmaengine.c| 22 +- drivers/dma/ioatdma.c | 81 -- drivers/dma/ioatdma_io.h | 118 - net/ipv4/tcp.c | 26 +-- 6 files changed, 100 insertions(+), 165 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] network: add the missing phy_device speed information to phy_mii_ioctl
Shan Lu wrote: Changelog: Function `phy_mii_ioctl' returns physical device's information based on user requests. When requested to return the basic mode control register information (BMCR), the original implementation only returns the physical device's duplex information and forgets to return speed information, which should not be because BMCR register is used to hold both duplex and speed information. The patch checks the BMCR value against speed-related flags and fills the return structure's speed field accordingly. Signed-off-by: Shan<[EMAIL PROTECTED]> --- --- drivers/net/phy/phy.c 2007-03-02 10:40:26.0 -0600 2.6.20 +++ drivers/net/phy/phy.c 2007-03-02 10:41:39.0 -0600 @@ -337,6 +337,10 @@ int phy_mii_ioctl(struct phy_device *phy phydev->duplex = DUPLEX_FULL; else phydev->duplex = DUPLEX_HALF; + if ((!phydev->autoneg) && (val _SPEED1000)) + phydev->speed = SPEED_1000; + else if ((!phydev->autoneg) && (val & BMCR_SPEED100)) + phydev->speed = SPEED_100; patch is word-wrapped - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] free swap space of (re)activated pages
On Fri, 02 Mar 2007 15:31:19 -0500 Rik van Riel <[EMAIL PROTECTED]> wrote: > the attached patch frees the swap space of already resident pages > when swap space starts getting tight, instead of only freeing up > the swap space taken up by newly swapped in pages. > > This should result in the swap space of pages that remain resident > in memory being freed, allowing kswapd more chances to actually swap > a page out (instead of rotating it back onto the active list). Fair enough. How do we work out if this helps things? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dynamic linking files slow fork down significantly
I have a fork-heavy workload (a proxy that forks per connection, I know it's not the most efficiant design) and I discovered a 2x performance difference between a static and dynamicly linked version of the same program (2200 connections/sec vs 4700 connections/sec) I know that there is overhead on program startup, but didn't expect to find it on a fork with no exec. If I has been asked I would have guessed that the static version would have been slower due to the need to mark more memory as COW. what is it that costs so much with dynamic libraries on a fork/clone? according to strace, the clone call that's being made is clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7c92c08) David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mv643xx_eth: Place explicit port number in mv643xx_eth_platform_data
Dale Farnsworth wrote: We were using the platform_device.id field to identify which ethernet port is used for mv643xx_eth device. This is not generally correct. It will be incorrect, for example, if a hardware platform uses a single port but not the first port. Here, we add an explicit port_number field to struct mv643xx_eth_platform_data. This makes the mv643xx_eth_platform_data structure required, but that isn't an issue since all users currently provide it already. Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]> --- arch/mips/momentum/jaguar_atx/platform.c |8 ++ arch/mips/momentum/ocelot_3/platform.c|8 ++ arch/mips/momentum/ocelot_c/platform.c|4 + arch/powerpc/platforms/chrp/pegasos_eth.c |2 arch/ppc/syslib/mv64x60.c | 12 +++- drivers/net/mv643xx_eth.c | 59 ++-- include/linux/mv643xx.h |1 7 files changed, 62 insertions(+), 32 deletions(-) ACK but not applied, patch corrupted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mv643xx_eth: move mac_addr inside mv643xx_eth_platform_data
Dale Farnsworth wrote: The information contained within platform_data should be self-contained. Replace the pointer to a MAC address with the actual MAC address in struct mv643xx_eth_platform_data. Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]> --- Replaced explicit mac address comparison with a call to is_valid_ether_addr(), as suggested by Stephen Hemminger <[EMAIL PROTECTED]>. arch/mips/momentum/jaguar_atx/platform.c | 20 arch/mips/momentum/ocelot_3/platform.c | 20 arch/mips/momentum/ocelot_c/platform.c | 12 ++-- drivers/net/mv643xx_eth.c|2 +- include/linux/mv643xx.h |2 +- 5 files changed, 12 insertions(+), 44 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix mv643xx_eth compilation.
Dave Jones wrote: Commit 908b637fe793165b6aecdc875cdca67c4959a1ad removed ETH_DMA_ALIGN but missed a usage of it in a macro, which broke the build. Signed-off-by: Dave Jones <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.19.6
diff --git a/Makefile b/Makefile
index cd5b5cf..5335f17 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 19
-EXTRAVERSION = .5
+EXTRAVERSION = .6
NAME=Avast! A bilge rat!
# *DOCUMENTATION*
diff --git a/drivers/input/mouse/psmouse-base.c
b/drivers/input/mouse/psmouse-base.c
index 6f9b2c7..d5c9c4b 100644
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/input/mouse/psmouse-base.c
@@ -986,8 +986,36 @@ static void psmouse_resync(void *p)
static void psmouse_cleanup(struct serio *serio)
{
struct psmouse *psmouse = serio_get_drvdata(serio);
+ struct psmouse *parent = NULL;
+
+ mutex_lock(_mutex);
+
+ if (serio->parent && serio->id.type == SERIO_PS_PSTHRU) {
+ parent = serio_get_drvdata(serio->parent);
+ psmouse_deactivate(parent);
+ }
+
+ psmouse_deactivate(psmouse);
+
+ if (psmouse->cleanup)
+ psmouse->cleanup(psmouse);
psmouse_reset(psmouse);
+
+/*
+ * Some boxes, such as HP nx7400, get terribly confused if mouse
+ * is not fully enabled before suspending/shutting down.
+ */
+ ps2_command(>ps2dev, NULL, PSMOUSE_CMD_ENABLE);
+
+ if (parent) {
+ if (parent->pt_deactivate)
+ parent->pt_deactivate(parent);
+
+ psmouse_activate(parent);
+ }
+
+ mutex_unlock(_mutex);
}
/*
diff --git a/drivers/input/mouse/psmouse.h b/drivers/input/mouse/psmouse.h
index 1b74cae..cf1de95 100644
--- a/drivers/input/mouse/psmouse.h
+++ b/drivers/input/mouse/psmouse.h
@@ -68,6 +68,7 @@ struct psmouse {
int (*reconnect)(struct psmouse *psmouse);
void (*disconnect)(struct psmouse *psmouse);
+ void (*cleanup)(struct psmouse *psmouse);
int (*poll)(struct psmouse *psmouse);
void (*pt_activate)(struct psmouse *psmouse);
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 49ac696..f0f9413 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -652,6 +652,7 @@ int synaptics_init(struct psmouse *psmouse)
psmouse->set_rate = synaptics_set_rate;
psmouse->disconnect = synaptics_disconnect;
psmouse->reconnect = synaptics_reconnect;
+ psmouse->cleanup = synaptics_reset;
psmouse->pktsize = 6;
/* Synaptics can usually stay in sync without extra help */
psmouse->resync_time = 0;
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index 458dd9f..e2cb19b 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -617,13 +617,15 @@ rx_next:
* this round of polling
*/
if (rx_work) {
+ unsigned long flags;
+
if (cpr16(IntrStatus) & cp_rx_intr_mask)
goto rx_status_loop;
- local_irq_disable();
+ local_irq_save(flags);
cpw16_f(IntrMask, cp_intr_mask);
__netif_rx_complete(dev);
- local_irq_enable();
+ local_irq_restore(flags);
return 0; /* done */
}
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 474a4e3..5eb2ec6 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -879,12 +879,14 @@ static int b44_poll(struct net_device *netdev, int
*budget)
}
if (bp->istat & ISTAT_ERRORS) {
- spin_lock_irq(>lock);
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
b44_halt(bp);
b44_init_rings(bp);
b44_init_hw(bp, 1);
netif_wake_queue(bp->dev);
- spin_unlock_irq(>lock);
+ spin_unlock_irqrestore(>lock, flags);
done = 1;
}
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 72325fa..75b9404 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -2544,14 +2544,15 @@ static int nv_napi_poll(struct net_device *dev, int
*budget)
int pkts, limit = min(*budget, dev->quota);
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
+ unsigned long flags;
pkts = nv_rx_process(dev, limit);
if (nv_alloc_rx(dev)) {
- spin_lock_irq(>lock);
+ spin_lock_irqsave(>lock, flags);
if (!np->in_shutdown)
mod_timer(>oom_kick, jiffies + OOM_REFILL);
- spin_unlock_irq(>lock);
+ spin_unlock_irqrestore(>lock, flags);
}
if (pkts < limit) {
@@ -2559,13 +2560,15 @@ static int nv_napi_poll(struct net_device *dev, int
*budget)
netif_rx_complete(dev);
/* re-enable receive interrupts */
- spin_lock_irq(>lock);
+ spin_lock_irqsave(>lock, flags);
+
np->irqmask |= NVREG_IRQ_RX_ALL;
if (np->msi_flags & NV_MSI_X_ENABLED)
Linux 2.6.19.6
We (the -stable team) are announcing the release of the 2.6.19.6 kernel. It contains a number of bugfixes, and all 2.6.19 users are recommended to upgrade. Barring anything major, there will not be any more 2.6.19 releases. If you disagree with this, please let the stable team know about the patches that you feel must be in a new release. We need to move on to flushing out the very large backlog of 2.6.20-stable patches. The diffstat and short summary of the fixes are below. I'll also be replying to this message with a copy of the patch between 2.6.19.5 and 2.6.19.6, as it is small enough to do so. The updated 2.6.19.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.19.y.git and can be browsed at the normal kernel.org git web browser: www.kernel.org/git/ thanks, greg k-h Makefile |2 drivers/input/mouse/psmouse-base.c | 28 +++ drivers/input/mouse/psmouse.h |1 drivers/input/mouse/synaptics.c|1 drivers/net/8139cp.c |6 drivers/net/b44.c |6 drivers/net/forcedeth.c| 11 - drivers/net/skge.c |5 drivers/net/sky2.c | 51 +++-- drivers/net/sky2.h |2 drivers/usb/net/usbnet.c |7 fs/bad_inode.c | 330 - fs/cifs/sess.c | 13 - fs/ext2/super.c|4 fs/ext3/super.c|4 fs/ext4/super.c|4 lib/swiotlb.c |2 sound/pci/hda/hda_intel.c |2 sound/pci/hda/patch_si3054.c |3 19 files changed, 400 insertions(+), 82 deletions(-) Summary of changes from v2.6.19.5 to v2.6.19.6 == David Brownell (1): USB: usbnet driver bugfix David Moore (1): Missing critical phys_to_virt in lib/swiotlb.c Eric Sandeen (1): fix memory corruption from misinterpreted bad_inode_ops return values (CVE-2006-5753) Francois Romieu (1): netpoll: drivers must not enable IRQ unconditionally in their NAPI handler Greg Kroah-Hartman (1): Linux 2.6.19.6 Hugh Dickins (1): fix umask when noACL kernel meets extN tuned for ACLs Stephen Hemminger (6): sky2: pci config blocks phy power control sky2: fix for NAPI with dual port boards sky2: kfree_skb with IRQ with netconsole sky2: transmit timeout deadlock sky2: dont flush good pause frames sky2: fix ram buffer allocation settings Steve French (1): Fix oops when Windows server sent bad domain name null terminator Takashi Iwai (2): hda-intel - Don't try to probe invalid codecs hda-codec - Don't return error at initialization of modem codec Thomas Renninger (1): Backport of psmouse suspend/shutdown cleanups - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/2] semaphores: add down_interruptible_timeout() and asm-generic/semaphore.h
On Tuesday 27 February 2007 12:45, Ingo Oeser wrote:
> Hi Inaky,
>
> On Tuesday, 27. February 2007, Inaky Perez-Gonzalez wrote:
> > On Monday 26 February 2007 18:18, Alan wrote:
> > > > Yeah, I need semaphore. This is a hw register that says when the hw
> > > > is ready to accept a new command. Code that wants to send commands
> > > > has to down the semaphore and then send it. When hw is ready to get a
> > > > new command, it sends and IRQ and the IRQ up()s the semaphore.
> > >
> > > So you need a mutex not a semaphore
> >
> > Theoretically I could use a mutex. Practically it would trigger ugly
> > complications. Only the owner can unlock a mutex (for example), so
> > I could not unlock from an IRQ handler -- not to mention that the
> > semantic rules outlined in Documentation/mutex-design.txt explicitly
> > forbid IRQ usage.
> >
> > And then, this is what semaphores where designed for, as gates :)
> > for once that I get to use a semaphore properly...
>
> But they are not required for that :-)
>
> I would suggest to use an irq-safe spinlock for the hardware access
> and a status indicator (ready for command), if this is really just a
> command register. If the status indicator is updated (in IRQ) and read
> under spinlock, that is safe.
I have that already. The registers are shared for the two flows of
information, sending commands to the device and receiving notifications
from them, so any access to the registers is protected by a IRQ spinlock.
Now, it would be kind of pointless to do a busy poll for the command-ready
indicator if I have an IRQ that notifies me of it, ergo there the need
for a semaphore. I could use a waitqueue, as akpm suggested, but I still
need something else that says 'its only me who has the command sending
privilege now', and I'd still need to push a timeout something to detect
broken hw.
So:
1 - to send a command I need to wait for !register.execute_command
2 - to access 'register', I need to have an spinlock
3 - when register.executing_command drops to zero, I get an IRQ
4 - other code flows access register
If I didn't have to wait for register.execute_command(), we have the usual
construct:
execute_command(hw) {
...
spin_lock_irqsave(hw->lock, flags);
prep_command_buffer;
writel(execute_command, register)
spin_unlock_irqrestore(hw->lock, flags);
...
}
checking for 'register.execute_command == 0' inside the spinlock protected
area, bailing out if busy and waiting for a while before retrying is another
(fugly) option that I am not willing to implement.
Another option is using a wait_event() mechanism that is woken up from the
IRQ that says register.execute_command is zero, but that's basically
a semaphore.
A FIFO or queue is the most complex of the mechanisms, because now I have
to create all this support infrastructure to store the queued commands.
A semaphore simplifies everything -- I guess I have brain corruption, because
I can't understand your objections.
execute_command(hw) {
...
down(hw->cmd_semaphore);
/* now it's only this thread who can send a command */
spin_lock_irqsave(hw->lock, flags);
prep_command_buffer;
writel(execute_command, register)
spin_unlock_irqrestore(hw->lock, flags);
...
}
irq_handler(hw) {
...
spin_lock_irqsave(hw->lock, flags);
if (readl(irq_register & execute_command_cleared))
up(hw->cmd_sem);
...
// touch command register here for other stuff
...
spin_unlock_irqrestore(hw->lock, flags);
...
}
It's not a mutex or spinlock, is a gating or sequencing mechanism that
allows just one guy at a time.
> Timeout based locking mechanisms are flawed, because they introduce the
> hard to find timing sensitive bugs.
The only reason why the timeout is added is to detect when the hw is dead
so we can recover. This shouldn't create timing bugs because if it times
out [in this case], the hw is broken and we are going to reset it.
> Semaphores aren't good "busy/ready flags", as you might have already
> noticed.
That's why I am not using them as a flag.
-- Inaky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ehea: dynamic add / remove port
Jan-Bernd Themann wrote: This patch introduces functionality to dynamically add / remove ehea ports via an userspace DLPAR tool. It creates a subnode for each logical port in the sysfs. Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]> applied 1-2 to #upstream (2.6.22) your patches added much trailing whitespace. please fix. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 3/7] Freezer: Remove PF_NOFREEZE from rcutorture thread
On Saturday, 3 March 2007 00:33, Oleg Nesterov wrote:
> On 03/02, Paul E. McKenney wrote:
> >
> > One way to embed try_to_freeze() into kthread_should_stop() might be
> > as follows:
> >
> > int kthread_should_stop(void)
> > {
> > if (kthread_stop_info.k == current)
> > return 1;
> > try_to_freeze();
> > return 0;
> > }
>
> I think this is dangerous. For example, worker_thread() will probably
> need some special actions after return from refrigerator. Also, a kernel
> thread may check kthread_should_stop() in the place where try_to_freeze()
> is not safe.
>
> Perhaps we should introduce a new helper which does this.
Agreed.
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 3/7] Freezer: Remove PF_NOFREEZE from rcutorture thread
On Sat, Mar 03, 2007 at 02:33:37AM +0300, Oleg Nesterov wrote:
> On 03/02, Paul E. McKenney wrote:
> >
> > One way to embed try_to_freeze() into kthread_should_stop() might be
> > as follows:
> >
> > int kthread_should_stop(void)
> > {
> > if (kthread_stop_info.k == current)
> > return 1;
> > try_to_freeze();
> > return 0;
> > }
>
> I think this is dangerous. For example, worker_thread() will probably
> need some special actions after return from refrigerator. Also, a kernel
> thread may check kthread_should_stop() in the place where try_to_freeze()
> is not safe.
>
> Perhaps we should introduce a new helper which does this.
Good point -- the return value from try_to_freeze() is lost if one uses
the above approach. About one third of the calls to try_to_freeze()
in 2.6.20 pay attention to the return value.
One approach would be to have a kthread_should_stop_nofreeze() for those
cases, and let the default be to try to freeze.
Is this what you had in mind?
Thanx, 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] dma-mapping.h
On Fri, 02 Mar 2007 19:43:34 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Gary Zambrano wrote: > > Added dma_sync_single_range_for_cpu/device to dma-mapping.h in asm-arm & > > asm-avr32 to call dma_sync_single_for_cpu/device. This patch enables b44 > > to compile on systems with these cpus. > > This patch was created with the assumption that another method of > > dma_sync_single_range_for_cpu/device does not exist on these > > architectures. > > > > > > Signed-off by: Gary Zambrano <[EMAIL PROTECTED]> > > this patch looks OK to me, but I'm not the one to apply it. This should > go through Andrew or linux-arch > yeah, I split this into separate arm and avr32 patches and queued them up a while back. I need to send them off to Russell and Haavard. But I'm a bit sluggish about forwarding things to the subsystem maintainers. Perhaps because the resutls are so disappointing ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The performance and behaviour of the anti-fragmentation related patches
On Fri, 2 Mar 2007 16:33:19 -0800 William Lee Irwin III <[EMAIL PROTECTED]> wrote: > On Fri, Mar 02, 2007 at 02:22:56PM -0800, Andrew Morton wrote: > > Opterons seem to be particularly prone to lock starvation where a cacheline > > gets captured in a single package for ever. > > AIUI that phenomenon is universal to NUMA. Maybe it's time we > reexamined our locking algorithms in the light of fairness > considerations. > It's also a multicore thing. iirc Kiran was seeing it on Intel CPUs. I expect the phenomenon would be observeable on a number of locks in the kernel, give the appropriate workload. We just hit it first on lru_lock. I'd have thought that increasing SWAP_CLUSTER_MAX by two or four orders of magnitude would plug it, simply by decreasing the acquisition frequency but I think Kiran fiddled with that to no effect. See below for Linus's thoughts, forwarded without permission.. Begin forwarded message: Date: Mon, 22 Jan 2007 13:49:02 -0800 (PST) From: Linus Torvalds <[EMAIL PROTECTED]> To: Andrew Morton <[EMAIL PROTECTED]> Cc: Nick Piggin <[EMAIL PROTECTED]>, Ravikiran G Thirumalai <[EMAIL PROTECTED]> Subject: Re: High lock spin time for zone->lru_lock under extreme conditions On Mon, 22 Jan 2007, Andrew Morton wrote: > > Please review the whole thread sometime. I think we're pretty screwed, and > the problem will only become worse as more cores get rolled out and I don't > know what to do about it apart from whining to Intel, but that won't fix > anything. I think people need to realize that spinlocks are always going to be unfair, and *extremely* so under some conditions. And yes, multi-core brought those conditions home to roost for some people (two or more cores much closer to each other than others, and able to basically ping-pong the spinlock to each other, with nobody else ever able to get it). There's only a few possible solutions: - use the much slower semaphores, which actually try to do fairness. - if you cannot sleep, introduce a separate "fair spinlock" type. It's going to be appreciably slower (and will possibly have a bigger memory footprint) than a regular spinlock, though. But it's certainly a possible thing to do. - make sure no lock that you care about ever has high enough contention to matter. NOTE! back-off etc simply will not help. This is not a back-off issue. Back-off helps keep down coherency traffic, but it doesn't help fairness. If somebody wants to play with fair spinlocks, go wild. I looked at it at one point, and it was not wonderful. It's pretty complicated to do, and the best way I could come up with was literally a list of waiting CPU's (but you only need one static list entry per CPU). I didn't bother to think a whole lot about it. The "never enough contention" is the real solution. For example, anything that drops and just re-takes the lock again (which some paths do for latency reduction) won't do squat. The same CPU that dropped the lock will basically always be able to retake it (and multi-core just means that is even more true, with the lock staying within one die even if some other core can get it). Of course, "never enough contention" may not be possible for all locks. Which is why a "fair spinlock" may be the solution - use it for the few locks that care (and the VM locks could easily be it). What CANNOT work: timeouts. A watchdog won't work. If you have workloads with enough contention, once you have enough CPU's, there's no upper bound on one of the cores not being able to get the lock. On the other hand, what CAN work is: not caring. If it's ok to not be fair, and it only happens under extreme load, then "we don't care" is a perfectly fine option. In the "it could work" corner, I used to hope that cache coherency protocols in hw would do some kind of fairness thing, but I've come to the conclusion that it's just too hard. It's hard enough for software, it's likely really painful for hw too. So not only does hw generally not do it today (although certain platforms are better at it than others), I don't really expect this to change. If anything, we'll see more of it, since multicore is one thing that makes things worse (as does multiple levels of caching - NUMA machines tend to have this problem even without multi-core, simply because they don't have a shared bus, which happens to hide many cases). I'm personally in the "don't care" camp, until somebody shows a real-life workload. I'd often prefer to disable a watchdog if that's the biggest problem, for example. But if there's a real load that shows this as a real problem... Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On Fri, 2 Mar 2007, Nicholas Miell wrote: > The point Ingo was making is that the x86 ABI already requires the FPU > context to be saved before *all* function calls. I've not seen that among Ingo's points, but yeah some status is caller saved. But, aren't things like status word and control bits callee saved? If that's the case, it might require proper handling. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] dma-mapping.h
Gary Zambrano wrote: Added dma_sync_single_range_for_cpu/device to dma-mapping.h in asm-arm & asm-avr32 to call dma_sync_single_for_cpu/device. This patch enables b44 to compile on systems with these cpus. This patch was created with the assumption that another method of dma_sync_single_range_for_cpu/device does not exist on these architectures. Signed-off by: Gary Zambrano <[EMAIL PROTECTED]> this patch looks OK to me, but I'm not the one to apply it. This should go through Andrew or linux-arch Jeff, passing the buck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-rc2-mm1
On Sat, 3 Mar 2007 00:42:33 +0100 "Michal Piotrowski" <[EMAIL PROTECTED]> wrote: > On 02/03/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/ > > > > I have noticed some strange system behavior. When i try to build a > kernel (medium load) - X, keyboard, mouse and sound hangs. > > I can ping machine and I can use magic SysRq key, but that's all. > > 2.6.20-mm2 was fine, 2.6.21-rc2 works well (over 800 patches since > 2.6.20-mm2 - great...) > > NIL (Nothing Interesting in Logs) > Can we see the sysrq-T output 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/
Re: The performance and behaviour of the anti-fragmentation related patches
On Fri, Mar 02, 2007 at 02:22:56PM -0800, Andrew Morton wrote: > Opterons seem to be particularly prone to lock starvation where a cacheline > gets captured in a single package for ever. AIUI that phenomenon is universal to NUMA. Maybe it's time we reexamined our locking algorithms in the light of fairness considerations. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The performance and behaviour of the anti-fragmentation related patches
On Fri, 02 Mar 2007 15:28:43 -0800 "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: > >>> 32GB is pretty much the minimum size to reproduce some of these > >>> problems. Some workloads may need larger systems to easily trigger > >>> them. > >> > >> We can find a 32GB system here pretty easily to test things on if > >> need be. Setting up large commercial databases is much harder. > > > > That's my problem, too. > > > > There does not seem to exist any single set of test cases that > > accurately predicts how the VM will behave with customer > > workloads. > > Tracing might help? Showing Andrew traces of what happened in > production for the prev_priority change made it much easier to > demonstrate and explain the real problem ... > Tracing is one way. The other way is the old scientific method: - develop a theory - add sufficient instrumentation to prove or disprove that theory - run workload, crunch on numbers - repeat Of course, multiple theories can be proven/disproven in a single pass. Practically, this means adding one new /prov/vmstat entry for each `goto keep*' in shrink_page_list(). And more instrumentation in shrink_active_list() to determine the behaviour of swap_tendency. Once that process is finished, we should have a thorough understanding of what the problem is. We can then construct a testcase (it'll be a couple hundred lines only) and use that testcase to determine what implementation changes are needed, and whether it actually worked. Then go back to the real workload, verify that it's still fixed. Then do whitebox testing of other workloads to check that they haven't regressed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH 2/2 -stable] libata: add missing CONFIG_PM in LLDs
Hi. On Fri, 2007-03-02 at 17:46 +0900, Tejun Heo wrote: > Add missing #ifdef CONFIG_PM conditionals around all PM related parts > in libata LLDs. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > --- > drivers/ata/ahci.c | 14 ++ > drivers/ata/ata_generic.c |4 > drivers/ata/ata_piix.c |4 > drivers/ata/pata_ali.c |6 ++ > drivers/ata/pata_amd.c |6 ++ > drivers/ata/pata_atiixp.c |4 > drivers/ata/pata_cmd64x.c |6 ++ > drivers/ata/pata_cs5520.c |7 +++ > drivers/ata/pata_cs5530.c |6 ++ > drivers/ata/pata_cs5535.c |4 > drivers/ata/pata_cypress.c |4 > drivers/ata/pata_efar.c |4 > drivers/ata/pata_hpt366.c |7 ++- > drivers/ata/pata_hpt3x3.c |6 ++ > drivers/ata/pata_it821x.c |6 ++ > drivers/ata/pata_jmicron.c |4 > drivers/ata/pata_marvell.c |4 > drivers/ata/pata_mpiix.c|4 > drivers/ata/pata_netcell.c |4 > drivers/ata/pata_ns87410.c |4 > drivers/ata/pata_oldpiix.c |4 > drivers/ata/pata_opti.c |4 > drivers/ata/pata_optidma.c |4 > drivers/ata/pata_pdc202xx_old.c |4 > drivers/ata/pata_radisys.c |4 > drivers/ata/pata_rz1000.c |6 ++ > drivers/ata/pata_sc1200.c |4 > drivers/ata/pata_serverworks.c |6 ++ > drivers/ata/pata_sil680.c |4 > drivers/ata/pata_sis.c |4 > drivers/ata/pata_triflex.c |4 > drivers/ata/pata_via.c |6 ++ > drivers/ata/sata_sil.c |2 ++ > drivers/ata/sata_sil24.c|2 ++ > 34 files changed, 165 insertions(+), 1 deletion(-) > > Index: work1/drivers/ata/ahci.c > === > --- work1.orig/drivers/ata/ahci.c > +++ work1/drivers/ata/ahci.c > @@ -225,10 +225,12 @@ static void ahci_thaw(struct ata_port *a > static void ahci_error_handler(struct ata_port *ap); > static void ahci_vt8251_error_handler(struct ata_port *ap); > static void ahci_post_internal_cmd(struct ata_queued_cmd *qc); > +#ifdef CONFIG_PM > static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg); > static int ahci_port_resume(struct ata_port *ap); > static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg); > static int ahci_pci_device_resume(struct pci_dev *pdev); Wouldn't it be simpler to add #else #define ahci_port_suspend(port, message) (NULL) etc (or something similar)? Regards, Nigel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: system call time increase when turning on CONFIG_PARAVIRT
Tim Chen wrote: > I also hope that the performance can be recovered as this option could > enabled in distributions' kernels in future. Yes, the intent is that running a CONFIG_PARAVIRT kernel on native hardware will have negligible performance hit compared to running a non-paravirt kernel. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: warn if speed limited due to 40-wire cable (v2)
Alan Cox wrote: it seems broken to manipulate xfer_mask after returning from the driver's ->mode_filter hook. this patch is more than just a speed-limited warning printk, afaics I actually suggested that order because the only way the printk can be done correctly is for it to be the very last test made. Since the mode filter is not told what mode will be used but just subtracts modes that are not allowed this should be safe. OK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] libata Kconfig: Update the various experimentality levels
Alan Cox wrote: Signed-off-by: Alan Cox <[EMAIL PROTECTED]> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.21-rc2/drivers/ata/Kconfig linux-2.6.21-rc2/drivers/ata/Kconfig --- linux.vanilla-2.6.21-rc2/drivers/ata/Kconfig2007-03-01 13:36:03.0 + +++ linux-2.6.21-rc2/drivers/ata/Kconfig2007-03-02 13:30:50.535164824 + @@ -184,7 +184,7 @@ If unsure, say N. config PATA_AMD - tristate "AMD/NVidia PATA support (Experimental)" + tristate "AMD/NVidia PATA support" depends on PCI help This option enables support for the AMD and NVidia PATA @@ -273,7 +283,7 @@ If unsure, say N. config PATA_HPT366 - tristate "HPT 366/368 PATA support (Very Experimental)" + tristate "HPT 366/368 PATA support (Experimental)" depends on PCI && EXPERIMENTAL ACK the changes you've presented, but please do resend combined with a patch that updates the CONFIG_EXPERIMENTAL dependencies at the same time - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: system call time increase when turning on CONFIG_PARAVIRT
On Fri, 2007-03-02 at 13:54 -0800, Jeremy Fitzhardinge wrote: > [ I assume you're talking about running on native hardware. ] > That's correct. > I haven't done any detailed measurements on what effect this will have, > but it does bring the actual executed instruction stream much closer to > the !CONFIG_PARAVIRT case, and so I would hope it would recover most or > all of the performance loss you've noticed. > I also hope that the performance can be recovered as this option could enabled in distributions' kernels in future. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The performance and behaviour of the anti-fragmentation related patches
.. and think about a realistic future. EVERYBODY will do on-die memory controllers. Yes, Intel doesn't do it today, but in the one- to two-year timeframe even Intel will. What does that mean? It means that in bigger systems, you will no longer even *have* 8 or 16 banks where turning off a few banks makes sense. You'll quite often have just a few DIMM's per die, because that's what you want for latency. Then you'll have CSI or HT or another interconnect. And with a few DIMM's per die, you're back where even just 2-way interleaving basically means that in order to turn off your DIMM, you probably need to remove HALF the memory for that CPU. In other words: TURNING OFF DIMM's IS A BEDTIME STORY FOR DIMWITTED CHILDREN. Even with only 4 banks per CPU, and 2-way interleaving, we could still power off half the DIMMs in the system. That's a huge impact on the power budget for a large cluster. No, it's not ideal, but what was that quote again ... "perfect is the enemy of good"? Something like that ;-) There are maybe a couple machines IN EXISTENCE TODAY that can do it. But nobody actually does it in practice, and nobody even knows if it's going to be viable (yes, DRAM takes energy, but trying to keep memory free will likely waste power *too*, and I doubt anybody has any real idea of how much any of this would actually help in practice). Batch jobs across clusters have spikes at different times of the day, etc that are fairly predictable in many cases. 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/
Re: [PATCH (update 3)] timer: Run calc_load halfway through each round_jiffies second
(I've removed the other CC:s for now to avoid annoying them - assuming removing them from the CC: list doesn't do that). On 02/03/07 22:32, Eric Dumazet wrote: Simon Arlott a écrit : On 02/03/07 16:35, Eric Dumazet wrote: I believe this patch is too complex/hazardous and may break exp decay computation. I still don't know why you think it may change the computation of load (aside from at boot or jiffies wrapping), and it's not really complex at all. It is possible that someone will change the value of LOAD_FREQ to something other than a multiple of HZ and this won't work because it'll get rounded up to a whole second. That and the negligible extra processing time of doing round_jiffies every 5 seconds is the only problem I can see. You apparently have no idea of the mathematic formulae used. You're right, I've not looked at exactly how it's done. I do know that calling it early/late (by +/- 750ms/250ms) *once* on boot and every 7 weeks is going to have a tiny effect that will go away quickly. This formulae has a meaning *only* if EXP_1, EXP_5, EXP_15 are directly computed from the exact LOAD_FREQ value. If you change it 'randomly' without changing the EXP_... you basically compute a wrong value... My comment asking about why you say it's complex is about the patch, not the computation. After an initial sync the patch does not change how often the calc_load computation is run or how it works, it will still be run exactly the same way and every 5*HZ ticks as before (try adding a printk to report when the count value's been changed by the call to round_jiffies). So what ? Do you want to impress your boss with a given value ? ? Please dont mess it. Just ignore the avenrun values and let it die. You can change it to suit your needs, but it wont suit every needs. I'm not sure you realise the problem the patch fixes, which is that since 2.6.20 tasks can use round_jiffies to run "in around X seconds time" at a time when jiffies % HZ == 0 to avoid waking the CPU several times because of multiple timers firing at random. This affects the calc_load process really badly because it also tends to run at this time too. Moving calc_load to always run halfway between a second will solve the problem. Imagine for example your task is awaken for 1us periods every HZ. Basically your cpu load should be HZ/100 (machine mostly idle) But computed 'load' will be 1.0 This whole avenrun[] thing is plain stupid anyway. The load should be something between 0 and 1 (per cpu), to get a precise idea of cpu_power used/unused. Nobody mentioned avenrun[] values on lkml in the last decade. If you're sure no one here cares about the values then I'll submit a patch to remove them from /proc/loadavg (and wait it to get rejected). Until the whole concept of load average and how it should be better calculated and reported is solved the best that can be done is to not make things worse like round_jiffies has done. *I* know the values are nowhere near perfect, but I made a change to a driver so that it uses round_jiffies to schedule status checking because it's appropriate and it makes the load average values sit at 1.00 even when idle - someone is going to complain about it and possibly take the time to find out why. If they bisect it, my patch will show up as the cause of the problem. (Assuming someone else uses this device; I sent an email to the accessrunner list once -rc2-mm1 was released asking for people to test it). -- Simon Arlott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] libata: warn if speed limited due to 40-wire cable (v2)
> it seems broken to manipulate xfer_mask after returning from the > driver's ->mode_filter hook. > > this patch is more than just a speed-limited warning printk, afaics I actually suggested that order because the only way the printk can be done correctly is for it to be the very last test made. Since the mode filter is not told what mode will be used but just subtracts modes that are not allowed this should be safe. I don't otherwise see how we deal with the case where a 40wire cable is used and the mode filter function decides itself to drop to UDMA33 or lower due to incompatibilities or errata. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird hard disk noise on shutdown (bug #7674)
Francesco Pretto wrote: 2007/2/22, Robert Hancock <[EMAIL PROTECTED]>: I believe it runs on suspend, but we don't run that code on normal shutdown, do we? Tejun Heo had a patch for sd that could (optionally) trigger a START STOP UNIT command to spin the disk down after synchronizing the cache before shutdown, but I haven't heard anything of it lately.. Was this? http://www.nabble.com/(fwd)--PATCH--sd:-implement-stop_on_shutdown-t3049703.html Not ready for inclusion yet? Tomorrow i'll give it a try, hoping it will apply to my conf. My actually shutdown procedure is to reboot on windows Xp and shutdown from there... Hi, I just wanted to say that I'm another user having this issue. I have a Toshiba M55-S3314 which is also making the same noise on shutdown. I have heard it from Ubuntu 5.04 on to Feisty Fawn Herd 4 (which is using the 2.6.20-9 kernel). I had installed the newest version of Sidux the other night, with the 2.6.20 kernel, and it didn't seem to do it. But then I tried it with Feisty, and at first, it didn't do it. Then I suspended the unit, and it came back fine; then I hibernated the unit; it came up ok, but after that, it's making the noise again every time. So I have no idea what's causing this. I hope that somebody can figure this one out...for the first time since 1998, I can't use linux on my machine! :-( I can't afford to sacrifice my hard drive... I'm not a programmer, but I'll be more than happy to try out stuff if anybody wants me to, or give logs or whatever. Just tell me what you want and how to get it! Thanks, Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] pata_cmd640: CMD640 PCI support
> > + if (ap->port_no != 0 && adev->devno != timing->last) {
> > + pci_write_config_byte(pdev, DRWTIM23,
> > timing->reg58[adev->devno]);
> > + timing->last = adev->devno;
> > + }
>
> It might be worth looking into whether ->dev_select is a better place
> for this sort of code
It isn't, for any driver because ->dev_select() is used extremely early
before all the setup of modes is even begun. This is why all the PATA
drivers hook qc_issue_prot instead.
> > + static struct ata_port_info *port_info[2] = { , };
> > +
> > + /* CMD640 detected, commiserations */
> > + pci_write_config_byte(pdev, 0x5C, 0x00);
>
> magic number
Indeed. Its undocumented magic.
> > +static int cmd640_reinit_one(struct pci_dev *pdev)
> > +{
> > + return ata_pci_device_resume(pdev);
> > +}
>
> appears to be useless wrapper
To remind me to add the resume path, which I've now done. Basically the
FIFO fixes go away on a resume ...
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] char/epca.c remove unused function (was: Re: 2.6.21-rc2-mm1)
On Sat, 03 Mar 2007 00:05:23 +0100 Michal Piotrowski <[EMAIL PROTECTED]> wrote: > Andrew Morton napisał(a): > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/ > > > > Please consider this patch for inclusion in >= 2.6.22. > > "drivers/char/epca.c:2741: warning: 'get_termio' defined but not used" Acked-by: Alan Cox <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc2-mm1
On 02/03/07, Andrew Morton <[EMAIL PROTECTED]> wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/ I have noticed some strange system behavior. When i try to build a kernel (medium load) - X, keyboard, mouse and sound hangs. I can ping machine and I can use magic SysRq key, but that's all. 2.6.20-mm2 was fine, 2.6.21-rc2 works well (over 800 patches since 2.6.20-mm2 - great...) NIL (Nothing Interesting in Logs) Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] 2.6.21-rc2 radeon backlight
On Fri, 2007-03-02 at 13:58 -0800, Andrew Morton wrote: > > @@ -1106,7 +1105,8 @@ config FB_ATY_GX > > > > config FB_ATY_BACKLIGHT > > bool "Support for backlight control" > > - depends on FB_ATY > > + depends on FB_ATY && EXPERIMENTAL > > + select FB_BACKLIGHT > > default y > > help > > Say Y here if you want to control the backlight of your display. > > Sorry, but my confidence level on this one is very low. We've had heaps > and heaps of Kconfig-related build errors in exactly this area. I'd prefer > that a patch like this one have a lot of testing and review (and a > changelog?) before we let it near a tree. Agreed, I can tell from what I've seen so far this will at least break the PMAC users... See my proposed patch, if that doesn't work, we should revert the problematic change. Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH,RFC] pci: do not mark exported functions as __devinit
On Sat, Mar 03, 2007 at 12:02:14AM +0100, Sam Ravnborg wrote: > > > > Yes, we allow them to be exported globally, as other init code might > > need to call them, like these functions. > > > > So yes, I think we need to find a way to fix the warning tools, as the > > code is correct here. > > This was the patch that I made to ignore these. > It is on top of other pending changes to modpost so it will not > apply. > I had to check for _ksymtab* because we have various > section names for ksymtab. (_gpl, _future etc.) Looks good to me. Thanks for fixing all of these warnings. 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/
Re: + fully-honor-vdso_enabled.patch added to -mm tree
Chuck Ebbert wrote: > John Reiser wrote: > >>The value of ->sysenter_return is interpreted in user space by the >>sysexit instruction; nobody else cares what the value is. The kernel >>is not required to provide a good value when vdso_enabled is zero, >>because the kernel has not told the process that sysenter is valid >>(by setting AT_SYSINFO.) > > > Doesn't matter because a malicious user can still execute sysenter. > We do have to deal with that somehow, so we have to put something > safe in there. All values are safe as far as the kernel is concerned. The sysexit instruction is the only consumer of the value. The sysexit instruction interprets the value as a _user_ virtual address, and jumps to it, in _user_ mode. If user code does not like jumping to a random address when vdso_enabled is zero, then user code should not use sysenter when vdso_enabled is zero. But execution of kernel code is not affected in any way regardless of the value. I'd be happy to set ->sysenter_return to 0 (or any other suggested value) when vdso_enabled is 0, but this would be a politeness only. There is no added security risk to the kernel by leaving it unset. >>Correct. Changing vdso_enabled from 0 to non-zero must be prepared >>to lose this race if it is not prevented. Ordinarily it won't matter >>because the administrator will perform such changes at a "quiet" time. >> > > > We have to deal with all the possibilities here, too. Documentation is one method of dealing with it. -- John Reiser, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 3/7] Freezer: Remove PF_NOFREEZE from rcutorture thread
On 03/02, Paul E. McKenney wrote:
>
> One way to embed try_to_freeze() into kthread_should_stop() might be
> as follows:
>
> int kthread_should_stop(void)
> {
> if (kthread_stop_info.k == current)
> return 1;
> try_to_freeze();
> return 0;
> }
I think this is dangerous. For example, worker_thread() will probably
need some special actions after return from refrigerator. Also, a kernel
thread may check kthread_should_stop() in the place where try_to_freeze()
is not safe.
Perhaps we should introduce a new helper which does this.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21-rc2 radeon backlight
On Fri, 2007-03-02 at 12:29 -0800, Andrew Morton wrote:
> On Fri, 02 Mar 2007 09:24:03 -0800
> Alex Romosan <[EMAIL PROTECTED]> wrote:
> > > Unclear. Are you saying that the backlight comes on OK if you use
> > > the IBM acpi module?
> >
> > yes, if i disable the radeon backlight and use the ibm acpi module,
> > than the backlight works. if i enable the radeon backlight, the screen
> > stays dark and i can't turn it on (i tried using radeontool to control
> > it but nothing happened).
>
> Richard, is this actually a bug, or is it a config error or something like
> that?
>
> And should we track it as a post-2.6.20 regression?
Its a regression IMO. Arguably its a Kconfig error but a nasty one as
the defaults cause the problems. Different people seem to have different
interpretations but to me it appears that the patch from James causes
backlights to fail to turn on for a variety of devices which worked
before.
I propose the following patch (I was previously waiting on James for
this). It avoids backing out the problematic Kconfig changes but means a
user has to explicitly enable the backlight via a kernel or module
parameter.
Can people with backlight problems try enabling them in Kconfig but
applying the following patch? Hopefully I have you all cc'd.
If it works I will add it to the other fix I have queued and pass to
Linus via the backlight tree. If it doesn't, I will revert the
problematic Kconfig changes for the next -rc.
Enabling the backlight by default appears to cause problems for mamny
users. Disable backlight controls unless explicitly enabled by users via
a module parameter. Since PMAC users are known to work, default to
enabled in that case.
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
--- a/drivers/video/aty/aty128fb.c
+++ b/drivers/video/aty/aty128fb.c
@@ -357,6 +357,12 @@ static int default_lcd_on __devinitdata = 1;
static int mtrr = 1;
#endif
+#ifdef CONFIG_PMAC_BACKLIGHT
+static int backlight __devinitdata = 1;
+#else
+static int backlight __devinitdata = 0;
+#endif
+
/* PLL constants */
struct aty128_constants {
u32 ref_clk;
@@ -1652,6 +1658,9 @@ static int __devinit aty128fb_setup(char *options)
} else if (!strncmp(this_opt, "crt:", 4)) {
default_crt_on = simple_strtoul(this_opt+4, NULL, 0);
continue;
+ } else if (!strncmp(this_opt, "backlight:", 10)) {
+ backlight = simple_strtoul(this_opt+10, NULL, 0);
+ continue;
}
#ifdef CONFIG_MTRR
if(!strncmp(this_opt, "nomtrr", 6)) {
@@ -1985,7 +1994,8 @@ static int __devinit aty128_init(struct pci_dev *pdev,
const struct pci_device_i
par->lock_blank = 0;
#ifdef CONFIG_FB_ATY128_BACKLIGHT
- aty128_bl_init(par);
+ if (backlight)
+ aty128_bl_init(par);
#endif
if (register_framebuffer(info) < 0)
diff --git a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
index a7e0062..00a5183 100644
--- a/drivers/video/aty/atyfb_base.c
+++ b/drivers/video/aty/atyfb_base.c
@@ -308,6 +308,12 @@ static int xclk;
static int comp_sync __devinitdata = -1;
static char *mode;
+#ifdef CONFIG_PMAC_BACKLIGHT
+static int backlight __devinitdata = 1;
+#else
+static int backlight __devinitdata = 0;
+#endif
+
#ifdef CONFIG_PPC
static int default_vmode __devinitdata = VMODE_CHOOSE;
static int default_cmode __devinitdata = CMODE_CHOOSE;
@@ -2575,7 +2581,7 @@ static int __devinit aty_init(struct fb_info *info)
| (USE_F32KHZ | TRISTATE_MEM_EN), par);
} else
#endif
- if (M64_HAS(MOBIL_BUS)) {
+ if (M64_HAS(MOBIL_BUS) && backlight) {
#ifdef CONFIG_FB_ATY_BACKLIGHT
aty_bl_init (par);
#endif
@@ -3757,6 +3763,8 @@ static int __init atyfb_setup(char *options)
xclk = simple_strtoul(this_opt+5, NULL, 0);
else if (!strncmp(this_opt, "comp_sync:", 10))
comp_sync = simple_strtoul(this_opt+10, NULL, 0);
+ else if (!strncmp(this_opt, "backlight:", 10))
+ backlight = simple_strtoul(this_opt+10, NULL, 0);
#ifdef CONFIG_PPC
else if (!strncmp(this_opt, "vmode:", 6)) {
unsigned int vmode =
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 7e228ad..7de3ff9 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -268,6 +268,11 @@ static int nomtrr = 0;
#endif
static int force_sleep;
static int ignore_devlist;
+#ifdef CONFIG_PMAC_BACKLIGHT
+static int backlight = 1;
+#else
+static int backlight = 0;
+#endif
/*
* prototypes
@@ -2349,7 +2354,8 @@ static int __devinit radeonfb_pci_register (struct
pci_dev *pdev,
MTRR_TYPE_WRCOMB, 1);
#endif
- radeonfb_bl_init(rinfo);
+ if (backlight)
+
