Re: [PATCH] mfd: SM501 core driver (#3)
On Tue, Feb 13, 2007 at 06:55:42PM +, Ben Dooks wrote: A new release of the SM501 core mfd driver. This driver provides the core functionality of the SM501, which is a multi-function chip including two framebuffers, video acceleration, USB, and many other peripheral blocks. The driver exports a number of entries for the peripheral drivers to use. Signed-off-by: Ben Dooks [EMAIL PROTECTED] Signed-off-by: Vincent Sanders [EMAIL PROTECTED] I would just like to add that I belive that I have made all the relevant adjustments from the feedback from the previous two patches. If there is nothing else from anyone, could this be merged in the current development window? We have several successful reports from users of the previous patches on a variety of architectures including SH4, PowerPC and ARM. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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/11] ANNOUNCE: Syslets, generic asynchronous system call support
On Tue, Feb 13, 2007 at 05:56:42PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: * Benjamin LaHaise [EMAIL PROTECTED] wrote: Open issues: Let me add some more Also: FPU state (especially important with the FPU and SSE memory copy variants), segment register bases on x86-64, interaction with set_fs()... agreed - i'll fix this. But i can see no big conceptual issue here - these resources are all attached to the user context, and that doesnt change upon an 'async context-switch'. So it's only a matter of properly separating the user execution context from the kernel execution context. The hardest bit was getting the ptregs details right - the FPU/SSE state is pretty much async already (in the hardware too) and isnt even touched by any of these codepaths. Good work, Ingo. I have not received first mail with announcement yet, so I will place my thoughts here if you do not mind. First one is per-thread data like TID. What about TLS related kernel data (is non-exec stack property stored in TLS block or in kernel)? Should it be copied with regs too (or better introduce new clone flag, which would force that info copy)? Btw, does SSE?/MMX?/call-it-yourself really saved on context switch? As far as I can see no syscalls (and kernel at all) use that registers. Another one is more global AIO question - while this approach IMHO outperforms micro-thread design (Zach and Linus created really good starting points, but they too have fundamental limiting factor), it still has a problem - syscall blocks and the same thread thus is not allowed to continue execution and fill the pipe - so what if system issues thousands of requests and there are only tens of working thread at most. What Tux did, as far as I recall, (and some other similar state machines do :) was to break blocking syscall issues and return to the next execution entity (next syslet or atom). Is it possible to extend exactly this state machine and interface to allow that (so that some other state machine implementations would not continue its life :)? Ingo -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: somebody dropped a (warning) bomb
Pekka Enberg [EMAIL PROTECTED] writes: On 2/13/07, Sergei Organov [EMAIL PROTECTED] wrote: May I suggest another definition for a warning being entirely sucks? The warning is entirely sucks if and only if it never has true positives. In all other cases it's only more or less sucks, IMHO. You're totally missing the point. No, I don't. False positives are not a minor annoyance, they're actively harmful as they hide other _useful_ warnings. Every warning I'm aware of do have false positives. They are indeed harmful, so one takes steps to get rid of them. If a warning had none false positives, it should be an error, not a warning in the first place. So, you really want warnings to be about things that can and should be fixed. That's the definition of a perfect warning, that is actually called error. So you really should aim for _zero false positives_ even if you risk not detecting some real positives. With almost any warning out there one makes more or less efforts to suppress the warning where it gives false positives, isn't it? At least that's my experience so far. -- Sergei. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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/11] ANNOUNCE: Syslets, generic asynchronous system call support
I have not received first mail with announcement yet, so I will place my thoughts here if you do not mind. An issue with sys_async_wait(): is is possible that events_left will be setup too late so that all events are already ready and thus sys_async_wait() can wait forever (or until next $sys_async_wait are ready)? -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel-doc: include struct short description in title output
From: Randy Dunlap [EMAIL PROTECTED]
Output of a struct in html mode needs to include the short description
from the struct name line in the output title line.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
scripts/kernel-doc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.20-git7.orig/scripts/kernel-doc
+++ linux-2.6.20-git7/scripts/kernel-doc
@@ -452,7 +452,7 @@ sub output_struct_html(%) {
my %args = %{$_[0]};
my ($parameter);
-print h2.$args{'type'}. .$args{'struct'}./h2\n;
+print h2.$args{'type'}. .$args{'struct'}. -
.$args{'purpose'}./h2\n;
print b.$args{'type'}. .$args{'struct'}./b {br\n;
foreach $parameter (@{$args{'parameterlist'}}) {
if ($parameter =~ /^#/) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel-doc: include struct short description in title output
On Tue, 2007-02-13 at 11:10 -0800, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Output of a struct in html mode needs to include the short description from the struct name line in the output title line. Yup, that fixes it for structs. I guess I forgot to mention this earlier because I didn't notice it until now... the same bug exists for functions as well. And apparently I never looked at the output for my description for pm_set_ops maybe (hopefully!) it'll teach me to be more careful next time. johannes signature.asc Description: This is a digitally signed message part
Re: somebody dropped a (warning) bomb
On Tue, 13 Feb 2007, Sergei Organov wrote: I want a char of indeterminate sign! I'm afraid I don't follow. Do we have a way to say I want an int of indeterminate sign in C? The same way there doesn't seem to be a way to say I want a char of indeterminate sign. You're wrong. Exactly because char *by*definition* is indeterminate sign as far as something like strlen() is concerned. char is _special_. Char is _different_. Char is *not* int. So no, strlen() doesn't actually say that, no matter if we like it or not. It actually says I want a char with implementation-defined sign. You're arguing some strange semantic difference in the English language. I'm not really interested. THE FACT IS, THAT strlen() IS DEFINED UNIVERSALLY AS TAKING char *. That BY DEFINITION means that strlen() cannot care about the sign, because the sign IS NOT DEFINED UNIVERSALLY! And if you cannot accept that fact, it's your problem. Not mine. The warning is CRAP. End of story. 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: NAK new drivers without proper power management?
On Tuesday, 13 February 2007 10:42, Tilman Schmidt wrote: Rafael J. Wysocki schrieb: I think we can introduce a pm_safe flag that will indicate if the driver handles suspend/resume correctly. If we do it, we can flag all of the drivers currently in the tree as pm_safe unless we know that they aren't. Next, we can convert the core to fail the suspend for any driver that is not flagged as pm_safe. But I think that will take time. Why a new flag? For example, there are drivers that define .suspend() and .resume() which do not work correctly and we can use the flag to mark them. IMHO it would be both more readable and more efficient to create a pm_generic_nosuspend() function which does return -ENOSYS, and set that as the .suspend method on drivers known to break suspend/resume. New drivers should either have .suspend and .resume methods of their own or set .suspend = pm_generic_nosuspend. This is quite similar to what we are trying to do now: ask driver authors to define .suspend that will return -ENOSYS if they can't ensure that the driver will handle the suspend and resume correctly. That way, NULL .suspend/.resume methods retain their current semantics (don't know whether suspend would work, never thought about it), I think this convention is unfortunate. The default should be to fail the suspend if there's no .suspend defined, IMO. Still, it's hard to change now. error-returning ones would clearly signal cannot suspend safely, and success-returning ones would equally clearly signal suspend works ok. (Bugs nonwithstanding.) There could then be a policy parameter (Kconfig selectable to start) to abort suspend when encountering a driver without .suspend/.resume methods, or to proceed with a warning message. I think there are many drivers without .suspend and .resume already in the tree, so that wouldn't be practical. Greetings, 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/
[PATCH] fb: SM501 framebuffer driver
Framebuffer support for the Silicon Motion SM501
multi-function chip.
This driver provides a pair of framebuffer interfaces
for the CRT and LCD panel interfaces, and some basic
acceleration for the cursor.
The patch has been updated slightly from the previous
version to including being able to pass an initial
video mode through via the platform data.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Signed-off-by: Vincent Sanders [EMAIL PROTECTED]
diff -urpN -X ../dontdiff linux-2.6.20/drivers/video/Kconfig
linux-2.6.20-sm501-2/drivers/video/Kconfig
--- linux-2.6.20/drivers/video/Kconfig 2007-02-04 18:44:54.0 +
+++ linux-2.6.20-sm501-2/drivers/video/Kconfig 2007-02-13 15:35:34.0
+
@@ -1600,6 +1600,24 @@ config FB_S3C2410_DEBUG
Turn on debugging messages. Note that you can set/unset at run time
through sysfs
+config FB_SM501
+ tristate Silicon Motion SM501 framebuffer support
+ depends on FB MFD_SM501
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ ---help---
+ Frame buffer driver for the CRT and LCD controllers in the Silicon
+ Motion SM501.
+
+ This driver is also available as a module ( = code which can be
+ inserted and removed from the running kernel whenever you want). The
+ module will be called sm501fb. If you want to compile it as a module,
+ say M here and read file:Documentation/modules.txt.
+
+ If unsure, say N.
+
+
config FB_PNX4008_DUM
tristate Display Update Module support on Philips PNX4008 board
depends on FB ARCH_PNX4008
diff -urpN -X ../dontdiff linux-2.6.20/drivers/video/Makefile
linux-2.6.20-sm501-2/drivers/video/Makefile
--- linux-2.6.20/drivers/video/Makefile 2007-02-04 18:44:54.0 +
+++ linux-2.6.20-sm501-2/drivers/video/Makefile 2007-02-13 15:35:34.0
+
@@ -100,6 +100,7 @@ obj-$(CONFIG_FB_S3C2410) += s3c2410fb.
obj-$(CONFIG_FB_PNX4008_DUM) += pnx4008/
obj-$(CONFIG_FB_PNX4008_DUM_RGB) += pnx4008/
obj-$(CONFIG_FB_IBM_GXT4500) += gxt4500.o
+obj-$(CONFIG_FB_SM501)+= sm501fb.o
# Platform or fallback drivers go here
obj-$(CONFIG_FB_VESA) += vesafb.o
diff -urpN -X ../dontdiff linux-2.6.20/drivers/video/sm501fb.c
linux-2.6.20-sm501-2/drivers/video/sm501fb.c
--- linux-2.6.20/drivers/video/sm501fb.c1970-01-01 01:00:00.0
+0100
+++ linux-2.6.20-sm501-2/drivers/video/sm501fb.c2007-02-13
19:14:47.0 +
@@ -0,0 +1,1809 @@
+/* linux/drivers/video/sm501fb.c
+ *
+ * Copyright (c) 2006 Simtec Electronics
+ * Vincent Sanders [EMAIL PROTECTED]
+ * Ben Dooks [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Framebuffer driver for the Silicon Motion SM501
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/string.h
+#include linux/mm.h
+#include linux/tty.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/fb.h
+#include linux/init.h
+#include linux/vmalloc.h
+#include linux/dma-mapping.h
+#include linux/interrupt.h
+#include linux/workqueue.h
+#include linux/wait.h
+#include linux/platform_device.h
+#include linux/clk.h
+
+#include asm/io.h
+#include asm/uaccess.h
+#include asm/div64.h
+
+#ifdef CONFIG_PM
+#include linux/pm.h
+#endif
+
+#include linux/sm501.h
+#include linux/sm501-regs.h
+
+#define NR_PALETTE 256
+
+enum sm501_controller {
+ HEAD_CRT= 0,
+ HEAD_PANEL = 1,
+};
+
+/* SM501 memory adress */
+struct sm501_mem {
+ unsigned longsize;
+ unsigned longsm_addr;
+ void __iomem*k_addr;
+};
+
+/* private data that is shared between all frambuffers* */
+struct sm501fb_info {
+ struct device *dev;
+ struct fb_info *fb[2]; /* fb info for both heads */
+ struct resource *fbmem_res; /* framebuffer resource */
+ struct resource *regs_res; /* registers resource */
+ struct sm501_platdata_fb *pdata;/* our platform data */
+
+ int irq;
+ int swap_endian; /* set to swap rgb=bgr */
+ void __iomem*regs; /* remapped registers */
+ void __iomem*fbmem; /* remapped framebuffer */
+ size_t fbmem_len; /* length of remapped region */
+};
+
+/* per-framebuffer private data */
+struct sm501fb_par {
+ u32 pseudo_palette[16];
+
+ enum sm501_controllerhead;
+ struct sm501_mem cursor;
+ struct sm501_mem screen;
+ struct fb_opsops;
+
+ void*store_fb;
+ void*store_cursor;
+ void
[PATCH v2] kernel-doc: include struct short description in title output
Yup, that fixes it for structs. I guess I forgot to mention this earlier
because I didn't notice it until now... the same bug exists for
functions as well.
updated patch. Thanks.
---
From: Randy Dunlap [EMAIL PROTECTED]
Output of a function or struct in html mode needs to include the short
description from the function/struct name line in the output title line.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
scripts/kernel-doc |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.20-git7.orig/scripts/kernel-doc
+++ linux-2.6.20-git7/scripts/kernel-doc
@@ -452,7 +452,7 @@ sub output_struct_html(%) {
my %args = %{$_[0]};
my ($parameter);
-print h2.$args{'type'}. .$args{'struct'}./h2\n;
+print h2.$args{'type'}. .$args{'struct'}. -
.$args{'purpose'}./h2\n;
print b.$args{'type'}. .$args{'struct'}./b {br\n;
foreach $parameter (@{$args{'parameterlist'}}) {
if ($parameter =~ /^#/) {
@@ -498,8 +498,8 @@ sub output_function_html(%) {
my %args = %{$_[0]};
my ($parameter, $section);
my $count;
-print h2Function/h2\n;
+print h2 .$args{'function'}. - .$args{'purpose'}./h2\n;
print i.$args{'functiontype'}./i\n;
print b.$args{'function'}./b\n;
print (;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 v2] kernel-doc: include struct short description in title output
On Tue, 2007-02-13 at 11:35 -0800, Randy Dunlap wrote:
Yup, that fixes it for structs. I guess I forgot to mention this earlier
because I didn't notice it until now... the same bug exists for
functions as well.
updated patch. Thanks.
Thanks, works great.
---
From: Randy Dunlap [EMAIL PROTECTED]
Output of a function or struct in html mode needs to include the short
description from the function/struct name line in the output title line.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
So if anyone cares:
Acked-by: Johannes Berg [EMAIL PROTECTED]
---
scripts/kernel-doc |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.20-git7.orig/scripts/kernel-doc
+++ linux-2.6.20-git7/scripts/kernel-doc
@@ -452,7 +452,7 @@ sub output_struct_html(%) {
my %args = %{$_[0]};
my ($parameter);
-print h2.$args{'type'}. .$args{'struct'}./h2\n;
+print h2.$args{'type'}. .$args{'struct'}. -
.$args{'purpose'}./h2\n;
print b.$args{'type'}. .$args{'struct'}./b {br\n;
foreach $parameter (@{$args{'parameterlist'}}) {
if ($parameter =~ /^#/) {
@@ -498,8 +498,8 @@ sub output_function_html(%) {
my %args = %{$_[0]};
my ($parameter, $section);
my $count;
-print h2Function/h2\n;
+print h2 .$args{'function'}. - .$args{'purpose'}./h2\n;
print i.$args{'functiontype'}./i\n;
print b.$args{'function'}./b\n;
print (;
signature.asc
Description: This is a digitally signed message part
Re: somebody dropped a (warning) bomb
On 2/13/07, Sergei Organov [EMAIL PROTECTED] wrote: With almost any warning out there one makes more or less efforts to suppress the warning where it gives false positives, isn't it? Yes, as long it's the _compiler_ that's doing the effort. You shouldn't need to annotate the source just to make the compiler shut up. Once the compiler starts issuing enough false positives, it's time to turn off that warning completely. Therefore, the only sane strategy for a warning is to aim for zero false positives. Pekka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bug in current -git tree causing dbus and gnome to chew up cpu time
Hi, I've used 'git bisect' to track down a change in the latest git tree that is causing dbus-daemon to sit and spin at the time GNOME launches, preventing nautlius from ever running. The bad commit is: commit eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1 Author: Andreas Gruenbacher [EMAIL PROTECTED] Date: Mon Feb 12 00:51:47 2007 -0800 [PATCH] Fix d_path for lazy unmounts With that patch out, GNOME startup works just fine. I have a strace of the dbus process running showing the problem, if anyone thinks that will help out any. I'm running pretty new GNOME and dbus here: dbus 1.0.2 gnome 2.16.2 hal 0.5.7.1 nautilus 2.16.3 Any ideas of things I can test? 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/
[PATCH] EHCI: turn off remote wakeup during shutdown
This patch (as850b) disables remote wakeup (and everything else!) on
all EHCI ports when the shutdown() method is called. If remote wakeup
is left active then some systems will reboot instead of powering off.
This fixes Bugzilla #7828.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
I'm submitting this for 2.6.20.stable. The problem it addresses can occur
with earlier kernels, but not unless the user explicitly enables remote
wakeup by doing a runtime suspend of the EHCI root hub. In 2.6.20 the
root hub will autosuspend itself, enabling remote wakeup and thus
triggering the problem.
A slightly different version of this patch will be submitted separately
for Greg KH's USB development tree.
Alan Stern
Index: 2.6.20/drivers/usb/host/ehci-hcd.c
===
--- 2.6.20.orig/drivers/usb/host/ehci-hcd.c
+++ 2.6.20/drivers/usb/host/ehci-hcd.c
@@ -296,6 +296,18 @@ static void ehci_watchdog (unsigned long
spin_unlock_irqrestore (ehci-lock, flags);
}
+/* On some systems, leaving remote wakeup enabled prevents system shutdown.
+ * The firmware seems to think that powering off is a wakeup event!
+ * This routine turns off remote wakeup and everything else, on all ports.
+ */
+static void ehci_turn_off_all_ports(struct ehci_hcd *ehci)
+{
+ int port = HCS_N_PORTS(ehci-hcs_params);
+
+ while (port--)
+ writel(PORT_RWC_BITS, ehci-regs-port_status[port]);
+}
+
/* ehci_shutdown kick in for silicon on any bus (not just pci, etc).
* This forcibly disables dma and IRQs, helping kexec and other cases
* where the next system software may expect clean state.
@@ -307,9 +319,13 @@ ehci_shutdown (struct usb_hcd *hcd)
ehci = hcd_to_ehci (hcd);
(void) ehci_halt (ehci);
+ ehci_turn_off_all_ports(ehci);
/* make BIOS/etc use companion controller during reboot */
writel (0, ehci-regs-configured_flag);
+
+ /* unblock posted writes */
+ readl(ehci-regs-configured_flag);
}
static void ehci_port_power (struct ehci_hcd *ehci, int is_on)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LIBATA] Libata under Qemu
On 2/13/07, Patrick Ale [EMAIL PROTECTED] wrote: Hi, Little errata, I only pulled Jeff's GIT at 15:00GMT , Linus' GIT was from two days ago. I just pulled linux-2.6-git8, same behaviour tho, it complains when nothing is attached to the second channel. Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.20-rc6 libata PATA ATAPI CDROM is not working
On Tue, Feb 13, 2007 at 05:35:32PM +, Joel Soete wrote: A small update: your patch also works against 2.6.20 but seems that open the door to numerous other pb: 1/ pb to burn cd: # md5sum cd060213.iso 6a1248783a21722816b972aa9bae9d5e cd060213.iso # ll cd060213.iso -rwxr-xr-x 1 root root 3213312 Feb 13 2006 cd060213.iso # dd if=/dev/sr0 bs=1 count=3213312 | md5sum dd: reading `/dev/sr0': Input/output error 0337e9846d17779945c5c252d4f897f0 - 3129344+0 records in 3129344+0 records out 3129344 bytes (3.1 MB) copied, 36.6963 seconds, 85.3 kB/s eventhought cdrecord seems to be successfull??? Has that ever worked by any method? I have always had to use readcd along with passing the correct number of sectors on the CD to get a proper matching image. dd always seems to end up reading some junk past the end of the disc. 2/ (but that should be much more related to scsi api) sdcXX sdc15 doesn't works ;-( # sfdisk -l /dev/sdc Disk /dev/sdc: 1826 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls#blocks Id System /dev/sdc1 * 0+195 196- 1574338+ b W95 FAT32 /dev/sdc219618251630 130929755 Extended /dev/sdc3 0 - 0 00 Empty /dev/sdc4 0 - 0 00 Empty /dev/sdc5 *196+197 2- 16033+ 83 Linux /dev/sdc6 *198+199 2- 16033+ 83 Linux /dev/sdc7200+201 2- 16033+ 83 Linux /dev/sdc8202+217 16-128488+ 82 Linux swap / Solaris /dev/sdc9218+478 261- 2096451 83 Linux /dev/sdc10 479+486 8- 64228+ 83 Linux /dev/sdc11 487+488 2- 16033+ 83 Linux /dev/sdc12 489+504 16-128488+ 83 Linux /dev/sdc13 505+618 114-915673+ 83 Linux /dev/sdc14 619+620 2- 16033+ 83 Linux /dev/sdc15 621+636 16-128488+ 83 Linux /dev/sdc16 637+644 8- 64228+ 83 Linux /dev/sdc17 645+646 2- 16033+ 83 Linux /dev/sdc18 647+654 8- 64228+ 83 Linux /dev/sdc19 655+656 2- 16033+ 83 Linux /dev/sdc20 657+773 117-939771 83 Linux /dev/sdc21 774+789 16-128488+ 83 Linux /dev/sdc22 790+880 91-730926 83 Linux /dev/sdc23 881+ 1533 653- 5245191 83 Linux /dev/sdc24 17951825 31 249007+ 83 Linux I have to ask: What are all those partitions? # mount /dev/sdc22 /4free mount: /dev/sdc22 is not a valid block device # ll /dev/sdc* brw-rw 1 root disk 8, 32 Dec 1 2001 /dev/sdc brw-rw 1 root disk 8, 33 Dec 1 2001 /dev/sdc1 brw-rw 1 root disk 8, 42 Dec 1 2001 /dev/sdc10 brw-rw 1 root disk 8, 43 Dec 1 2001 /dev/sdc11 brw-rw 1 root disk 8, 44 Dec 1 2001 /dev/sdc12 brw-rw 1 root disk 8, 45 Dec 1 2001 /dev/sdc13 brw-rw 1 root disk 8, 46 Dec 1 2001 /dev/sdc14 brw-rw 1 root disk 8, 47 Dec 1 2001 /dev/sdc15 brw-r--r-- 1 root root 8, 48 Feb 13 16:26 /dev/sdc16 brw-r--r-- 1 root root 8, 49 Feb 13 16:26 /dev/sdc17 brw-r--r-- 1 root root 8, 50 Feb 13 16:26 /dev/sdc18 brw-r--r-- 1 root root 8, 51 Feb 13 16:27 /dev/sdc19 brw-rw 1 root disk 8, 34 Dec 1 2001 /dev/sdc2 brw-r--r-- 1 root root 8, 52 Feb 13 16:27 /dev/sdc20 brw-r--r-- 1 root root 8, 53 Feb 13 16:27 /dev/sdc21 brw-r--r-- 1 root root 8, 54 Feb 13 16:27 /dev/sdc22 brw-r--r-- 1 root root 8, 55 Feb 13 16:27 /dev/sdc23 brw-r--r-- 1 root root 8, 56 Feb 13 16:27 /dev/sdc24 brw-rw 1 root disk 8, 35 Dec 1 2001 /dev/sdc3 brw-rw 1 root disk 8, 36 Dec 1 2001 /dev/sdc4 brw-rw 1 root disk 8, 37 Dec 1 2001 /dev/sdc5 brw-rw 1 root disk 8, 38 Dec 1 2001 /dev/sdc6 brw-rw 1 root disk 8, 39 Dec 1 2001 /dev/sdc7 brw-rw 1 root disk 8, 40 Dec 1 2001 /dev/sdc8 brw-rw 1 root disk 8, 41 Dec 1 2001 /dev/sdc9 Hmm, using udev? Any chance udev incorrectly doesn't check for going past the end of the block devices allowed (each scsi device has 16 minors assigned, which gives you 15 partitions per device). Last device for sdc is 8,47. 8,48 (your sdc16) is actually sdd. # dmesg [snip] scsi3 : ata_piix ata1.00: ATA-4, max UDMA/66, 29336832 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/33 scsi4 : ata_piix ata2.01: ATAPI, max MWDMA1 ata2.01: configured for MWDMA1 scsi 3:0:0:0: Direct-Access ATA QUANTUM FIREBALL A03. PQ: 0 ANSI: 5 SCSI device sdc: 29336832 512-byte hdwr sectors (15020 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 29336832 512-byte hdwr sectors (15020 MB) sdc: Write Protect is
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On Tuesday 13 February 2007 11:51, Greg KH wrote: Hi, I've used 'git bisect' to track down a change in the latest git tree that is causing dbus-daemon to sit and spin at the time GNOME launches, preventing nautlius from ever running. The bad commit is: commit eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1 Author: Andreas Gruenbacher [EMAIL PROTECTED] Date: Mon Feb 12 00:51:47 2007 -0800 [PATCH] Fix d_path for lazy unmounts With that patch out, GNOME startup works just fine. I have a strace of the dbus process running showing the problem, if anyone thinks that will help out any. I'd like to see that, please. I'm running pretty new GNOME and dbus here: dbus 1.0.2 gnome 2.16.2 hal 0.5.7.1 nautilus 2.16.3 Any ideas of things I can test? Sorry for the breakage. Printk of the __d_path result may tell: Index: b/fs/dcache.c === --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1803,6 +1803,8 @@ char *__d_path(struct dentry *dentry, st out: spin_unlock(dcache_lock); + printk(KERN_DEBUG %s(%d): %s\n, current-comm, current-pid, + IS_ERR(buffer) ? failed : buffer); return buffer; global_root: Thanks, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LIBATA] Libata under Qemu
On Tue, Feb 13, 2007 at 08:53:58PM +0100, Patrick Ale wrote: Little errata, I only pulled Jeff's GIT at 15:00GMT , Linus' GIT was from two days ago. I just pulled linux-2.6-git8, same behaviour tho, it complains when nothing is attached to the second channel. /That/ sounds like a qemu bug. 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: somebody dropped a (warning) bomb
Linus Torvalds [EMAIL PROTECTED] writes: On Tue, 13 Feb 2007, Sergei Organov wrote: I want a char of indeterminate sign! I'm afraid I don't follow. Do we have a way to say I want an int of indeterminate sign in C? The same way there doesn't seem to be a way to say I want a char of indeterminate sign. You're wrong. Sure, I knew it from the very beginning ;) Exactly because char *by*definition* is indeterminate sign as far as something like strlen() is concerned. Thanks, I now understand that you either don't see the difference between indeterminate and implementation-defined in this context or consider it non-essential, so I think I've got your point. char is _special_. Char is _different_. Char is *not* int. Sure. So no, strlen() doesn't actually say that, no matter if we like it or not. It actually says I want a char with implementation-defined sign. You're arguing some strange semantic difference in the English language. Didn't I further explain what I meant exactly (that you've skipped)? OK, never mind. I'm not really interested. OK, no problem. THE FACT IS, THAT strlen() IS DEFINED UNIVERSALLY AS TAKING char *. So just don't pass it unsigned char*. End of story. That BY DEFINITION means that strlen() cannot care about the sign, because the sign IS NOT DEFINED UNIVERSALLY! And if you cannot accept that fact, it's your problem. Not mine. I never had problems either with strlen() or with this warning, so was curious why does the warning is such a problem for the kernel. I'm sorry I took your time and haven't got an answer that I entirely agree with. Thank you very much for your explanations anyway. The warning is CRAP. End of story. Amen! -- Sergei. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LIBATA] Libata under Qemu
On 2/13/07, Jeff Garzik [EMAIL PROTECTED] wrote: /That/ sounds like a qemu bug. Allright, I will make sure tonight by testing it on a native PIIX mainboard without anything connected to the second PATA controller :) I thought for a second it was a similar abnorma statel error I got earlier this week with pata_via when no drive was attached (no qemu, real hardware) I'll keep you posted. Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] unify flush_work/flush_work_keventd and rename it to cancel_work_sync
flush_work(wq, work) doesn't need the first parameter, we can use cwq-wq
(this was possible from the very beginnig, I missed this). So we can unify
flush_work_keventd and flush_work.
Also, rename flush_work() to cancel_work_sync() and fix all callers. Perhaps
this is not the best name, but flush_work is really bad.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
include/linux/workqueue.h | 21 -
kernel/workqueue.c | 36 +---
fs/aio.c |4 ++--
block/ll_rw_blk.c |2 +-
drivers/ata/libata-core.c |8
drivers/net/e1000/e1000_main.c |2 +-
drivers/net/phy/phy.c |4 ++--
drivers/net/tg3.c |2 +-
kernel/relay.c |2 +-
net/ipv4/ipvs/ip_vs_ctl.c |2 +-
10 files changed, 42 insertions(+), 41 deletions(-)
--- 6.20-rc6-mm3/include/linux/workqueue.h~5_flush 2007-02-12
03:32:22.0 +0300
+++ 6.20-rc6-mm3/include/linux/workqueue.h 2007-02-12 03:26:54.0
+0300
@@ -168,29 +168,32 @@ extern struct workqueue_struct *__create
extern void destroy_workqueue(struct workqueue_struct *wq);
extern int FASTCALL(queue_work(struct workqueue_struct *wq, struct work_struct
*work));
-extern int FASTCALL(queue_delayed_work(struct workqueue_struct *wq, struct
delayed_work *work, unsigned long delay));
+extern int FASTCALL(queue_delayed_work(struct workqueue_struct *wq,
+ struct delayed_work *work, unsigned long delay));
extern int queue_delayed_work_on(int cpu, struct workqueue_struct *wq,
- struct delayed_work *work, unsigned long delay);
+ struct delayed_work *work, unsigned long delay);
+
extern void FASTCALL(flush_workqueue(struct workqueue_struct *wq));
-extern void flush_work(struct workqueue_struct *wq, struct work_struct *work);
-extern void flush_work_keventd(struct work_struct *work);
+extern void flush_scheduled_work(void);
extern int FASTCALL(schedule_work(struct work_struct *work));
-extern int FASTCALL(schedule_delayed_work(struct delayed_work *work, unsigned
long delay));
-
-extern int schedule_delayed_work_on(int cpu, struct delayed_work *work,
unsigned long delay);
+extern int FASTCALL(schedule_delayed_work(struct delayed_work *work,
+ unsigned long delay));
+extern int schedule_delayed_work_on(int cpu, struct delayed_work *work,
+ unsigned long delay);
extern int schedule_on_each_cpu(work_func_t func);
-extern void flush_scheduled_work(void);
extern int current_is_keventd(void);
extern int keventd_up(void);
extern void init_workqueues(void);
int execute_in_process_context(work_func_t fn, struct execute_work *);
+extern void cancel_work_sync(struct work_struct *work);
+
/*
* Kill off a pending schedule_delayed_work(). Note that the work callback
* function may still be running on return from cancel_delayed_work(). Run
- * flush_workqueue() or flush_work() to wait on it.
+ * flush_workqueue() or cancel_work_sync() to wait on it.
*/
static inline int cancel_delayed_work(struct delayed_work *work)
{
--- 6.20-rc6-mm3/kernel/workqueue.c~5_flush 2007-02-12 03:30:08.0
+0300
+++ 6.20-rc6-mm3/kernel/workqueue.c 2007-02-12 03:26:54.0 +0300
@@ -421,23 +421,23 @@ static void wait_on_work(struct cpu_work
}
/**
- * flush_work - block until a work_struct's callback has terminated
- * @wq: the workqueue on which the work is queued
+ * cancel_work_sync - block until a work_struct's callback has terminated
* @work: the work which is to be flushed
*
- * flush_work() will attempt to cancel the work if it is queued. If the work's
- * callback appears to be running, flush_work() will block until it has
- * completed.
+ * cancel_work_sync() will attempt to cancel the work if it is queued. If the
+ * work's callback appears to be running, cancel_work_sync() will block until
+ * it has completed.
*
- * flush_work() is designed to be used when the caller is tearing down data
- * structures which the callback function operates upon. It is expected that,
- * prior to calling flush_work(), the caller has arranged for the work to not
- * be requeued.
+ * cancel_work_sync() is designed to be used when the caller is tearing down
+ * data structures which the callback function operates upon. It is expected
+ * that, prior to calling cancel_work_sync(), the caller has arranged for the
+ * work to not be requeued.
*/
-void flush_work(struct workqueue_struct *wq, struct work_struct *work)
+void cancel_work_sync(struct work_struct *work)
{
- const cpumask_t *cpu_map = wq_cpu_map(wq);
struct cpu_workqueue_struct *cwq;
+ struct workqueue_struct *wq;
+ const cpumask_t *cpu_map;
int cpu;
might_sleep();
@@ -456,10 +456,13 @@ void flush_work(struct workqueue_struct
work_release(work);
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On Tuesday 13 February 2007 12:01, Greg KH wrote: Attached below. I'm getting a CRC error on that file. Would you mind to resend? Thanks, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libsata doesn't like bus without master
Patrick Ale wrote: ATA: abnormal status 0x8 on port 0xF88597DF Maybe this is purely a cosmetic error where the error code can be translated to something like no drive attached or maybe the drivers assume you always configure a master drive on a controller, which doesnt always have to be the case, especialy not with motherboards these days where you get 2 ATA ports + 2 exta raid channels. Yeah, it is a cosmetic error message that should have been killed quite a while ago. I just keep forgetting about it. Will kill it soon. -- 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] build error: allnoconfig fails on mincore/swapper_space
On Tue, 13 Feb 2007 13:48:53 +1100 Nick Piggin wrote:
Andrew Morton wrote:
On Mon, 12 Feb 2007 14:50:40 -0800 Randy Dunlap [EMAIL PROTECTED] wrote:
2.6.20-git8 on x86_64:
LD init/built-in.o
LD .tmp_vmlinux1
mm/built-in.o: In function `sys_mincore':
(.text+0xe584): undefined reference to `swapper_space'
make: *** [.tmp_vmlinux1] Error 1
oops. CONFIG_SWAP=n, I assume?
Hmm, OK. Hugh can strip me of my bonus point now...
Hugh, you can strip me of my bonus point now... How about your other
suggestion to just remove the stats from lookup_swap_cache? (and should
we also rename it to find_get_swap_page?)
I need a fix for this. It's killing my daily/automated builds.
So here is an ifdeffery-fix.
BUT: what is present used for in that loop? or is it used?
---
From: Randy Dunlap [EMAIL PROTECTED]
Don't check for pte swap entries when CONFIG_SWAP=n.
mm/built-in.o: In function `sys_mincore':
(.text+0xe584): undefined reference to `swapper_space'
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
mm/mincore.c |4
1 file changed, 4 insertions(+)
--- linux-2.6.20-git8.orig/mm/mincore.c
+++ linux-2.6.20-git8/mm/mincore.c
@@ -111,6 +111,7 @@ static long do_mincore(unsigned long add
present = mincore_page(vma-vm_file-f_mapping, pgoff);
} else { /* pte is a swap entry */
+#ifdef CONFIG_SWAP
swp_entry_t entry = pte_to_swp_entry(pte);
if (is_migration_entry(entry)) {
/* migration entries are always uptodate */
@@ -119,6 +120,9 @@ static long do_mincore(unsigned long add
pgoff = entry.val;
present = mincore_page(swapper_space, pgoff);
}
+#else
+ present = 0;
+#endif
}
}
pte_unmap_unlock(ptep-1, ptl);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 06/11] syslets: core, documentation
Wow! You really helped Zach out ;)
On Tue, 13 Feb 2007, Ingo Molnar wrote:
+The Syslet Atom:
+
+
+The syslet atom is a small, fixed-size (44 bytes on 32-bit) piece of
+user-space memory, which is the basic unit of execution within the syslet
+framework. A syslet represents a single system-call and its arguments.
+In addition it also has condition flags attached to it that allows the
+construction of larger programs (syslets) from these atoms.
+
+Arguments to the system call are implemented via pointers to arguments.
+This not only increases the flexibility of syslet atoms (multiple syslets
+can share the same variable for example), but is also an optimization:
+copy_uatom() will only fetch syscall parameters up until the point it
+meets the first NULL pointer. 50% of all syscalls have 2 or less
+parameters (and 90% of all syscalls have 4 or less parameters).
Why do you need to have an extra memory indirection per parameter in
copy_uatom()? It also forces you to have parameters pointed-to, to be
long (or pointers), instead of their natural POSIX type (like fd being
int for example). Also, you need to have array pointers (think about a
char buf[]; passed to an async read(2)) to be saved into a pointer
variable, and pass the pointer of the latter to the async system. Same for
all structures (ie. stat(2) struct stat). Let them be real argouments
and add a nparams argoument to the structure:
struct syslet_atom {
unsigned long flags;
unsigned intnr;
unsigned intnparams;
long __user *ret_ptr;
struct syslet_uatom __user *next;
unsigned long args[6];
};
I can understand that chaining syscalls requires variable sharing, but the
majority of the parameters passed to syscalls are just direct ones.
Maybe a smart method that allows you to know if a parameter is a direct
one or a pointer to one? An unsigned int pmap where bit N is 1 if param
N is an indirection? Hmm?
+Running Syslets:
+
+
+Syslets can be run via the sys_async_exec() system call, which takes
+the first atom of the syslet as an argument. The kernel does not need
+to be told about the other atoms - it will fetch them on the fly as
+execution goes forward.
+
+A syslet might either be executed 'cached', or it might generate a
+'cachemiss'.
+
+'Cached' syslet execution means that the whole syslet was executed
+without blocking. The system-call returns the submitted atom's address
+in this case.
+
+If a syslet blocks while the kernel executes a system-call embedded in
+one of its atoms, the kernel will keep working on that syscall in
+parallel, but it immediately returns to user-space with a NULL pointer,
+so the submitting task can submit other syslets.
+
+Completion of asynchronous syslets:
+---
+
+Completion of asynchronous syslets is done via the 'completion ring',
+which is a ringbuffer of syslet atom pointers user user-space memory,
+provided by user-space in the sys_async_register() syscall. The
+kernel fills in the ringbuffer starting at index 0, and user-space
+must clear out these pointers. Once the kernel reaches the end of
+the ring it wraps back to index 0. The kernel will not overwrite
+non-NULL pointers (but will return an error), user-space has to
+make sure it completes all events it asked for.
Sigh, I really dislike shared userspace/kernel stuff, when we're
transfering pointers to userspace. Did you actually bench it against a:
int async_wait(struct syslet_uatom **r, int n);
I can fully understand sharing userspace buffers with the kernel, if we're
talking about KB transferd during a block or net I/O DMA operation, but
for transfering a pointer? Behind each pointer transfer(4/8 bytes) there
is a whole syscall execution, that makes the 4/8 bytes tranfers have a
relative cost of 0.01% *maybe*. Different case is a O_DIRECT read of 16KB
of data, where in that case the memory transfer has a relative cost
compared to the syscall, that can be pretty high. The syscall saving
argument is moot too, because syscall are cheap, and if there's a lot of
async traffic, you'll be fetching lots of completions to keep you dispatch
loop pretty busy for a while.
And the API is *certainly* cleaner.
- 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: Serial console issues.
David Lang wrote: On Mon, 12 Feb 2007, Andy Kennedy wrote: For those of you who are on BusyBox's mailing list, you've already seen this -- I was sent here for help. Specs: Linux: 2.6.18 Bootloader: SysLinux Init: BusyBox (ver 1.4.0) init. Kernel command line: console=ttyS0,115200,n,8,1 System: VersaLogic 568 (STD80/STD32 Bus, i386 based computer) Issue: Booting on System I get perfect printk's to the serial console. When the init takes over (from within an initrd), the console begins to miss characters. I can still send write commands through the console, however, the output of these commands is garbled. The really odd part is when the init releases control (is killed by Linux), or when a printk is issued, the console prints perfectly again. The next really strange part about this is that changing System to my laptop -- no problems PERIOD. The BusyBox list directed me to LKML as this is a wider base of users that may have experienced the same problem and could provide me an answer. I've seen this happen when you accidently have multple programs attached to the same console (even with the text-mode vga consoles) double check that nothing else is trying to use that serial port David Lang Adding Off-line chatter Between David Lang and Andy Kennedy Not to be thick, but it is the same disk used on two different systems. . . one works, the other doesn't. Doesn't that imply that there is only one thing grabbing the serial port? If not, I'll look again. I have even had this problem with nothing in the inittab. . . The only thing I could think is that maybe something within the init code opens the /dev/console the wrong way. . . or is init opening /dev/console AND /dev/ttyS0 and that is what is causing the problem BUT, then why would it work on my laptop, however, not the embedded system? with the same disk working differently on different hardware I would start looking at the drivers and interrupts. does one of the two have different hardware that could be shareing an interrupt and the other doesn't? David Lang Other than looking into proc, is there another way to determine this? The BIOS CMOS setup isn't that forthcoming with any information -- this is an older board and has very limited settings on it. In proc/interrupts I'm seeing nothing but serial on 4. Do you know if the kernel preforms any type of init on the /dev/console before it writes each time? IE, from the BusyBox code, I cannot see that it mucks with the /dev/console before it writes, but the code is so thick I may have missed something. I don't know the answers to these questions, sorry. I'm not a kernel hacker, just an experianced user, and since this problem sounded familiar I spoke up. at this point we are getting out of my depth. David Lang Me neither David. . . but thanks for you help. Another piece of the puzzle (sorry I left this off before, didn't think): SERIAL PORT TYPE: TI16750 In printk(), when something is sent from the kernel to the console, is there an initialization that occurs prior to the actual write to the console? How does the console interact with ttyS0 when console=ttyS0 is supplied as command line parameter? When an init interfaces the console, should it also send the setup information if it detects that console=serial device? OR. . . could there be something specific to this hardware that requires additional coding to get the console to work the correct way (i.e. some form of force send, etc)? Before, I explained how the printk comes out perfectly, then BusyBox hoses the connection, then another printk will reset the input. The following is a snippet of that: Using IPI Shortcut mode drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Time: pit clocksource has been installed. Freeing unused kernel memory: 536k freed :l a l tr' z ye . gg et dil t' g input: AT Translated Set 2 keyboard as /class/input/input0 I'm in way over my head on this one since I don't know the underling driver for the serial port on Linux. Sorry again for polluting your list and thanks in advance (again) for any assistance you can provide me on this issue. Andy Kennedy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AHCI - remove probing of ata2
Hello, Paul. Paul Rolland wrote: Also, please note that libata is complaining : ATA: abnormal status 0x7F on port 0x177 and later : ATA: abnormal status 0x7F on port 0x9807 You can ignore the above. The errors on ata2 are due to SIMG storage processor and will probably fixed when PMP support is implemented. The latter errors on pata_jmicron is probably due to lack of proper mode programming on that driver. I'll look into that. Thanks. -- 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: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
On Tue, 13 Feb 2007, Ingo Molnar wrote: As it might be obvious to some of you, the syslet subsystem takes many ideas and experience from my Tux in-kernel webserver :) The syslet code originates from a heavy rewrite of the Tux-atom and the Tux-cachemiss infrastructure. Open issues: - the 'TID' of the 'head' thread currently varies depending on which thread is running the user-space context. - signal support is not fully thought through - probably the head should be getting all of them - the cachemiss threads are not really interested in executing signal handlers. - sys_fork() and sys_async_exec() should be filtered out from the syscalls that are allowed - first one only makes sense with ptregs, second one is a nice kernel recursion thing :) I didnt want to duplicate the sys_call_table though - maybe others have a better idea. If this is going to be a generic AIO subsystem: - Cancellation of peding request - 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: SATA-performance: Linux vs. FreeBSD
Arjan van de Ven wrote: The problem is: FreeBSD is fast, but lacks of some special drivers. Linux has all drivers but access to harddisk is unpredictable and thus unreliable! What can I do?? there's several tunables you can do; 1) increase /sys/block/device/queue/nr_requests the linux default is on the low side 2) investigate other elevators; cfq is great for interactive use but not so great for max throughput. you can do this by echo'ing deadline into /sys/block/device/scheduler I'd suggest trying the noop scheduler with your ram based devices. I don't see why these devices would need clever scheduling. ...but prove me wrong if you will. I haven't tested this. echo noop /sys/block/device/queue/scheduler If you don't need journaling EXT2 might be a good choice. But, I'd also like to re-iterate the XFS filesystem recommendation given several times now as well. There are many tunables that /may/ help during filesystem creation. Block size (-b) set to it's maximum would prob. help. If you're sure you can not encounter power issues: mount -t xfs -o nobarrier /dev/device /mount-point Here's some more general reading for ya: Troubleshooting Linux Performance Issues: http://www.phptr.com/articles/article.asp?p=481867seqNum=2rl=1 -- Jeffrey Hundstad - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: somebody dropped a (warning) bomb
On Tue, 13 Feb 2007, Sergei Organov wrote:
Exactly because char *by*definition* is indeterminate sign as far as
something like strlen() is concerned.
Thanks, I now understand that you either don't see the difference
between indeterminate and implementation-defined in this context or
consider it non-essential, so I think I've got your point.
The thing is, implementation-defined does actually matter when you can
_depend_ on it.
For example, there's a *huge* difference between undefined and
implementation-defined. A program can actually depend on something like
char c = 0x80;
if (c 0)
..
always having the *same* behaviour for a particular compiler (with a
particular set of compile flags - some compilers have flags to change the
sign behaviour).
So yes, there implementation defined actually has a real and worthwhile
meaning. It is guaranteed to have _some_ semantics within the confines of
that program, and they are defined to be consistent (again, within the
confines of that particular program).
So I agree that implementation defined doesn't always mean
meaningless.
BUT (and this is a big but) within the discussion of strlen(), that is
no longer true. strlen() exists _outside_ of a single particular
implementation. As such, implementation-defined is no longer something
that strlen() can depend on.
As an example of this argument, try this:
#include string.h
#include stdio.h
int main(int argc, char **argv)
{
char a1[] = { -1, 0 }, a2[] = { 1, 0 };
printf(%d %d\n, a1[0] a2[0], strcmp(a1, a2) 0);
return 0;
}
and *before* you compile it, try to guess what the output is.
And when that confuses you, try to compile it using gcc with the
-funsigned-char flag (or -fsigned-char if you started out on an
architecture where char was unsigned by default)
And when you really *really* think about it afterwards, I think you'll go
Ahh.. Linus is right. It's more than implementation-defined: it really
is totally indeterminate for code like this.
(Yeah, the above isn't strlen(), but it's an even subtler issue with
EXACTLY THE SAME PROBLEM! And one where you can actually see the _effects_
of it)
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/11] ANNOUNCE: Syslets, generic asynchronous system call support
On Tue, 13 Feb 2007, Linus Torvalds wrote: if (in_async_context()) return -EINVAL; or similar. We need that async_context() function anyway for the other cases where we can't do other things concurrently, like changing the UID. Yes, that's definitely better. Let's have the policy about weather a syscall is or is not async-enabled, inside the syscall itself. Simplify things a lot. - 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: somebody dropped a (warning) bomb
Pekka Enberg [EMAIL PROTECTED] writes: On 2/13/07, Sergei Organov [EMAIL PROTECTED] wrote: With almost any warning out there one makes more or less efforts to suppress the warning where it gives false positives, isn't it? Yes, as long it's the _compiler_ that's doing the effort. You shouldn't need to annotate the source just to make the compiler shut up. Sorry, what do you do with variable 'xxx' might be used uninitialized warning when it's false? Turn it off? Annotate the source? Assign fake initialization value? Change the compiler so that it does the effort for you? Never encountered false positive from this warning? Once the compiler starts issuing enough false positives, it's time to turn off that warning completely. Yes, I don't argue that. I said otherwise the warning is more or less sucks, and then it's up to programmers to decide if it's enough sucks to be turned off. The decision depends on the importance of its true positives then. Only if warning never has true positives it is unconditional, total, unhelpful crap, -- that was my point. Therefore, the only sane strategy for a warning is to aim for zero false positives. Sure. But unfortunately this in an unreachable aim in most cases. -- Sergei. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.2: maybe a bug inside the r8169 network driver (was Re: Linux 2.6.19.2: Freeze with CIFS mount)
Eric Lacombe [EMAIL PROTECTED] : [...] That problem also remind me that when I compiled this driver without the CONFIG_NET_ETHERNET (in the section Ethernet (10 or 100Mbit)), I have really poor performance with the net device. Maybe it is related, or not ;) If it gives you more ideas ? Maybe it could be interesting to know about the r8169 maintainer, but I dont know who he is. 1. $ ls arch crypto include kernel mm scripts blockDocumentation init lib net security COPYING driversipc MAINTAINERS README sound CREDITS fs Kbuild Makefile REPORTING-BUGS usr The maintainer of the r8169 driver is listed in the MAINTAINERS file. 2. Disabling CONFIG_NET_ETHERNET is a bad idea. Don't do that. 3. See tethereal -w or tcpdump on the adequate interface to save a traffic dump. 4. Are you using a binary module for your video adapter ? 5. How does the 2.6.20 version of the r8169 driver behave ? 6. You may setup a cron to monitor an ethtool dump of the register of the 8169 at regular interval. ifconfig and /proc/interrupts could exhibit some unusual drift as time passes on too. 7. A dmesg would be welcome. 8. Please open a PR at bugzilla.kernel.org. |...] There are various ways to analyze system hangs including (at least in some cases) getting a system dump which can be used to isolate the failing location - hopefully I would like to have more detailed help, if possible. CONFIG_MAGIC_SYSRQ is set. Check that the magic sysrq is not disabled at runtime through /etc/sysctl.conf. See Documentation/sysrq.txt for details. Please keep Steve French in the loop. -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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/11] ANNOUNCE: Syslets, generic asynchronous system call support
* Benjamin LaHaise [EMAIL PROTECTED] wrote: [...] interaction with set_fs()... hm, this one should already work in the current version, because addr_limit is in thread_info and hence stays with the async context. Or can you see any hole in it? Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
* Dmitry Torokhov [EMAIL PROTECTED] wrote: What are the semantics of async sys_async_wait and async sys_async ? Ohh. OpenVMS lives forever ;) Me likeee ;) hm, i dont know OpenVMS - but googled around a bit for 'VMS asynchronous' and it gave me this: http://en.wikipedia.org/wiki/Asynchronous_system_trap is AST what you mean? From a quick read AST seems to be a signal mechanism a bit like Unix signals, extended to kernel-space as well - while syslets are a different 'safe execution engine' kind of thing centered around the execution of system calls. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] RFC: Cell SPE logos
Andrew please apply.
Acked-By: James Simmons [EMAIL PROTECTED]
On Mon, 12 Feb 2007, Geert Uytterhoeven wrote:
On Wed, 31 Jan 2007, Geert Uytterhoeven wrote:
I would like to hear your opinions about the patchset below (updated version
compared to yesterday, lkml added to the CC list).
The Cell Broadband Engine contains a 64-bit PowerPC core with 2 hardware
threads (called PPEs) and 8 Synergistic Processing Engines (called SPEs).
When booting Linux, 2 penguins logos are shown on the graphical console by
the standard frame buffer console logo code.
To emphasize the existence of the SPEs (which can be used under Linux), we
added a second row of (smaller) helper penguin logos, one for each SPE.
I attached a PNG version of the helper penguin logo for reference.
Summaries:
[PATCH 1/7] fbdev: Avoid vertical overflow when making space for the logo
[PATCH 2/7] fbdev: fb_do_show_logo() updates
[PATCH 3/7] fbdev: extract fb_show_logo_line()
[PATCH 4/7] fbdev: move logo externs to header file
[PATCH 5/7] fbdev: Add fb_append_extra_logo()
[PATCH 6/7] fbdev: SPE helper penguin logo
[PATCH 7/7] Cell: Draw SPE helper penguin logos
The helper penguins overlap with the main penguins when using console rotation
(fbcon=rotate:x, with x != 0). Here's a fix:
---
Correct the image offsets when rotating the logo. Before image-dx and
image-dy were always zero, so nobody ever noticed.
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/video/fbmem.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
--- ps3-linux-2.6.20.orig/drivers/video/fbmem.c
+++ ps3-linux-2.6.20/drivers/video/fbmem.c
@@ -355,22 +355,26 @@ static void fb_rotate_logo(struct fb_inf
if (rotate == FB_ROTATE_UD) {
fb_rotate_logo_ud(image-data, dst, image-width,
image-height);
- image-dx = info-var.xres - image-width;
- image-dy = info-var.yres - image-height;
+ image-dx = info-var.xres - image-width - image-dx;
+ image-dy = info-var.yres - image-height - image-dy;
} else if (rotate == FB_ROTATE_CW) {
fb_rotate_logo_cw(image-data, dst, image-width,
image-height);
tmp = image-width;
image-width = image-height;
image-height = tmp;
- image-dx = info-var.xres - image-width;
+ tmp = image-dy;
+ image-dy = image-dx;
+ image-dx = info-var.xres - image-width - tmp;
} else if (rotate == FB_ROTATE_CCW) {
fb_rotate_logo_ccw(image-data, dst, image-width,
image-height);
tmp = image-width;
image-width = image-height;
image-height = tmp;
- image-dy = info-var.yres - image-height;
+ tmp = image-dx;
+ image-dx = image-dy;
+ image-dy = info-var.yres - image-height - tmp;
}
image-data = dst;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe
(NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 B-1935 Zaventem,
Belgium
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 02/11] syslets: add syslet.h include file, user API/ABI definitions
On Tue, February 13, 2007 15:20, Ingo Molnar wrote: +/* + * Execution control: conditions upon the return code + * of the previous syslet atom. 'Stop' means syslet + * execution is stopped and the atom is put into the + * completion ring: + */ +#define SYSLET_STOP_ON_NONZERO 0x0008 +#define SYSLET_STOP_ON_ZERO 0x0010 +#define SYSLET_STOP_ON_NEGATIVE 0x0020 +#define SYSLET_STOP_ON_NON_POSITIVE 0x0040 This is confusing. Why the return code of the previous syslet atom? Wouldn't it be more clear if the flag was for the current tasklet? Worse, what is the previous atom? Imagine some case with a loop: A | B--. | | C---' What will be the previous atom of B here? It can be either A or C, but their return values can be different and incompatible, so what flag should B set? +/* + * Special modifier to 'stop' handling: instead of stopping the + * execution of the syslet, the linearly next syslet is executed. + * (Normal execution flows along atom-next, and execution stops + * if atom-next is NULL or a stop condition becomes true.) + * + * This is what allows true branches of execution within syslets. + */ +#define SYSLET_SKIP_TO_NEXT_ON_STOP 0x0080 + Might rename this to SYSLET_SKIP_NEXT_ON_STOP too then. Greetings, Indan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] [PATCH] fb: SM501 framebuffer driver
Framebuffer support for the Silicon Motion SM501
multi-function chip.
This driver provides a pair of framebuffer interfaces
for the CRT and LCD panel interfaces, and some basic
acceleration for the cursor.
The patch has been updated slightly from the previous
version to including being able to pass an initial
video mode through via the platform data.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Signed-off-by: Vincent Sanders [EMAIL PROTECTED]
+ *
+ * Converts a period in picoseconds to Hz.
+ *
+ * Note, we try to keep this in Hz to minimise rounding with
+ * the limited PLL settings on the SM501.
+*/
+
+static unsigned long sm501fb_ps_to_hz(unsigned long psvalue)
+{
+ unsigned long long numerator=1ULL;
+
+ /* 10^12 / picosecond period gives frequency in Hz */
+ do_div(numerator, psvalue);
+ return (unsigned long)numerator;
+}
+
+/* sm501fb_hz_to_ps is identical to the oposite transform */
+
+#define sm501fb_hz_to_ps(x) sm501fb_ps_to_hz(x)
You really need it down to the Hz?
+/* sm501fb_validate_pan
+ *
+ * check panning on a var
+*/
+
+static inline int sm501fb_validate_pan(struct fb_var_screeninfo *var)
+{
+ if (var-xoffset 0 || var-yoffset 0)
+ return 0;
+
+ if (var-xoffset (var-xres_virtual - var-xres) ||
+ var-yoffset (var-yres_virtual - var-yres))
+ return 0;
+
+ return 1;
+}
Not needed. fb_pan_display in fbmem.c does this check for you :-)
+/* framebuffer ops */
+
+static struct fb_ops sm501fb_ops_crt = {
+ .owner = THIS_MODULE,
+ .fb_check_var = sm501fb_check_var_crt,
+ .fb_set_par = sm501fb_set_par_crt,
+ .fb_blank = sm501fb_blank_crt,
+ .fb_setcolreg = sm501fb_setcolreg,
+ .fb_pan_display = sm501fb_pan_crt,
+ .fb_cursor = sm501fb_cursor,
+ .fb_fillrect= cfb_fillrect,
+ .fb_copyarea= cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
+static struct fb_ops sm501fb_ops_pnl = {
+ .owner = THIS_MODULE,
+ .fb_check_var = sm501fb_check_var_pnl,
+ .fb_set_par = sm501fb_set_par_pnl,
+ .fb_pan_display = sm501fb_pan_pnl,
+ .fb_blank = sm501fb_blank_pnl,
+ .fb_setcolreg = sm501fb_setcolreg,
+ .fb_cursor = sm501fb_cursor,
+ .fb_fillrect= cfb_fillrect,
+ .fb_copyarea= cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
Many cards require a fb_sync function after/before they do a drawing
operation. I notice you don't have one. Is sm501fb_sync_regs equivalent to
that?
Other than that the driver looks great. Thank you.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: somebody dropped a (warning) bomb
On Tuesday 13 February 2007 2:25 pm, Linus Torvalds wrote: THE FACT IS, THAT strlen() IS DEFINED UNIVERSALLY AS TAKING char *. That BY DEFINITION means that strlen() cannot care about the sign, because the sign IS NOT DEFINED UNIVERSALLY! And if you cannot accept that fact, it's your problem. Not mine. The warning is CRAP. End of story. In busybox we fed the compiler -funsigned-char to make it shut up. (And so we had consistent bugs between arm and x86.) Building tcc I had to feed it -fsigned-char because -funsigned char broke stuff. :) Rob -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
User tools for March 11
Hi! In the United States, some idiots have decided that the year 2000 scare wasn't enough so they changed the start date for daylight savings time from the first Sunday in April to the second Sunday in March. Does anybody know if there are new tools like `hwclock` and `date`? Will new 'C' runtime libraries be necessary as well? Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.61 BogoMips). New book: http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] i2c updates for 2.6.21
Linus, Please pull the i2c subsystem updates for Linux 2.6.21 from: git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus There is one new i2c bus driver (i2c-pasemi), support for two new south bridges (ATI SB600 and VIA CX700), and lots of small fixes and cleanups all around the place. Documentation/i2c/busses/i2c-i801 | 60 +++ Documentation/i2c/busses/i2c-parport | 15 + Documentation/i2c/busses/i2c-piix4|2 Documentation/i2c/busses/i2c-viapro |7 Documentation/i2c/porting-clients |6 Documentation/i2c/smbus-protocol |2 Documentation/i2c/writing-clients | 58 ++- MAINTAINERS |6 drivers/acpi/i2c_ec.c |1 drivers/hwmon/vt8231.c|1 drivers/i2c/busses/Kconfig| 13 + drivers/i2c/busses/Makefile |1 drivers/i2c/busses/i2c-ali1535.c |1 drivers/i2c/busses/i2c-ali1563.c | 58 +-- drivers/i2c/busses/i2c-ali15x3.c |1 drivers/i2c/busses/i2c-amd756-s4882.c |2 drivers/i2c/busses/i2c-amd756.c |1 drivers/i2c/busses/i2c-amd8111.c | 71 ++-- drivers/i2c/busses/i2c-i801.c |3 drivers/i2c/busses/i2c-i810.c |2 drivers/i2c/busses/i2c-ibm_iic.c |1 drivers/i2c/busses/i2c-isa.c |1 drivers/i2c/busses/i2c-mv64xxx.c |1 drivers/i2c/busses/i2c-nforce2.c |3 drivers/i2c/busses/i2c-parport.h |8 drivers/i2c/busses/i2c-pasemi.c | 426 + drivers/i2c/busses/i2c-piix4.c|4 drivers/i2c/busses/i2c-powermac.c |1 drivers/i2c/busses/i2c-savage4.c |1 drivers/i2c/busses/i2c-sis5595.c |1 drivers/i2c/busses/i2c-sis630.c |1 drivers/i2c/busses/i2c-sis96x.c |1 drivers/i2c/busses/i2c-via.c |1 drivers/i2c/busses/i2c-viapro.c |7 drivers/i2c/busses/i2c-voodoo3.c |2 drivers/i2c/busses/scx200_acb.c |7 drivers/i2c/busses/scx200_i2c.c |1 drivers/i2c/i2c-core.c| 71 ++-- drivers/ieee1394/pcilynx.c|1 drivers/media/dvb/b2c2/flexcop-i2c.c |1 drivers/media/dvb/dvb-usb/dvb-usb-i2c.c |1 drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |1 drivers/media/video/cafe_ccic.c |1 drivers/media/video/pvrusb2/pvrusb2-i2c-core.c|1 drivers/media/video/usbvision/usbvision-i2c.c |1 drivers/media/video/w9968cf.c |1 drivers/media/video/zoran_card.c |1 drivers/rtc/rtc-ds1672.c |2 drivers/rtc/rtc-pcf8563.c |2 drivers/rtc/rtc-rs5c372.c |2 drivers/rtc/rtc-x1205.c |2 drivers/video/matrox/i2c-matroxfb.c |1 include/linux/i2c-id.h|5 include/linux/i2c.h |7 include/linux/pci_ids.h |1 55 files changed, 764 insertions(+), 116 deletions(-) create mode 100644 drivers/i2c/busses/i2c-pasemi.c --- David Brownell: i2c/vt8231: Remove superfluous initialization i2c: Add driver suspend/resume/shutdown support Jean Delvare: i2c-ali1563: Improve the status messages i2c-ali1563: Fix device initialization i2c-nforce2: Drop unused reference to pci_dev i2c-piix4: Add support for the ATI SB600 i2c-i801: Spelling fix i2c-i801: Document the SMBus unhiding quirk i2c: completion header cleanups i2c: Update the list of bus IDs i2c-viapro: Add support for the VIA CX700 south bridge i2c-amd8111: Proposed cleanups i2c: Declare more i2c_adapter parent devices i2c: Remove the warning on missing adapter device i2c: Stop using i2c_adapter.class_dev Jonathan McDowell: i2c-parport: Add support for One For All remote JP1 interface Mike Frysinger: i2c: Fix typo in SMBus Write Word Data description Olof Johansson: i2c: PA Semi SMBus driver Stephen Hemminger: i2c: Add IDs to adapters Thanks, -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
On Tue, 13 Feb 2007, Davide Libenzi wrote: If this is going to be a generic AIO subsystem: - Cancellation of peding request What about the busy_async_threads list becoming a hash/rb_tree indexed by syslet_atom ptr. A cancel would lookup the thread and send a signal (of course, signal handling of the async threads should be set properly)? - 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: somebody dropped a (warning) bomb
On Tue, Feb 13, 2007 at 11:29:44PM +0300, Sergei Organov wrote: Sorry, what do you do with variable 'xxx' might be used uninitialized warning when it's false? Turn it off? Annotate the source? Assign fake initialization value? Change the compiler so that it does the effort for you? Never encountered false positive from this warning? You pull git://git.kernel.org/...jgarzik/misc-2.6.git#gccbug 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: User tools for March 11
On Tue, 13 Feb 2007 16:19:59 -0500 linux-os \(Dick Johnson\) [EMAIL PROTECTED] wrote: Hi! In the United States, some idiots have decided that the year 2000 scare wasn't enough so they changed the start date for daylight savings time from the first Sunday in April to the second Sunday in March. Does anybody know if there are new tools like `hwclock` and `date`? Will new 'C' runtime libraries be necessary as well? Your vendor should be able to tell you whether the library versions you have are sufficiently up to date, which apps need restarting and which apps use their own timezone code and problems (check for example if you use Java) It's nothing special, timezone rules change all the time. Be glad the world is mostly standardising. When I was younger the UK summer time switches were set in a meeting each year and they were not too worried about adjusting it a week for Royal Ascot and that kind of thing. 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 06/11] syslets: core, documentation
* Davide Libenzi davidel@xmailserver.org wrote: +The Syslet Atom: + + +The syslet atom is a small, fixed-size (44 bytes on 32-bit) piece of +user-space memory, which is the basic unit of execution within the syslet +framework. A syslet represents a single system-call and its arguments. +In addition it also has condition flags attached to it that allows the +construction of larger programs (syslets) from these atoms. + +Arguments to the system call are implemented via pointers to arguments. +This not only increases the flexibility of syslet atoms (multiple syslets +can share the same variable for example), but is also an optimization: +copy_uatom() will only fetch syscall parameters up until the point it +meets the first NULL pointer. 50% of all syscalls have 2 or less +parameters (and 90% of all syscalls have 4 or less parameters). Why do you need to have an extra memory indirection per parameter in copy_uatom()? [...] yes. Try to use them in real programs, and you'll see that most of the time the variable an atom wants to access should also be accessed by other atoms. For example a socket file descriptor - one atom opens it, another one reads from it, a third one closes it. By having the parameters in the atoms we'd have to copy the fd to two other places. but i see your point: i actually had it like that in my earlier versions, only changed it to an indirect method later on, when writing more complex syslets. And, surprisingly, performance of atom handling /improved/ on both Intel and AMD CPUs when i added indirection, because the indirection enables the 'tail NULL' optimization. (which wasnt the goal of indirection, it was just a side-effect) [...] It also forces you to have parameters pointed-to, to be long (or pointers), instead of their natural POSIX type (like fd being int for example). [...] this wasnt a big problem while coding syslets. I'd also not expect application writers having to do these things on the syscall level - this is a system interface after all. But you do have a point. I can understand that chaining syscalls requires variable sharing, but the majority of the parameters passed to syscalls are just direct ones. Maybe a smart method that allows you to know if a parameter is a direct one or a pointer to one? An unsigned int pmap where bit N is 1 if param N is an indirection? Hmm? adding such things tends to slow down atom parsing. there's another reason as well: i wanted syslets to be like 'instructions' - i.e. not self-modifying. If the fd parameter is embedded in the syslet then every syslet has to be replicated note that chaining does not necessarily require variable sharing: a sys_umem_add() atom could be used to modify the next syslet's -fd parameter. So for example sys_open() - returns 'fd' sys_umem_add(atom1-fd) = atom1-fd is 0 initially sys_umem_add(atom2-fd) = the first umem_add returns the value atom1 [uses fd] atom2 [uses fd] but i didnt like this approach: this means 1 more atom per indirect parameter, and quite some trickery to put the right information into the right place. Furthermore, this makes syslets very much tied to the 'register contents' - instead of them being 'pure instructions/code'. +Completion of asynchronous syslets: +--- + +Completion of asynchronous syslets is done via the 'completion ring', +which is a ringbuffer of syslet atom pointers user user-space memory, +provided by user-space in the sys_async_register() syscall. The +kernel fills in the ringbuffer starting at index 0, and user-space +must clear out these pointers. Once the kernel reaches the end of +the ring it wraps back to index 0. The kernel will not overwrite +non-NULL pointers (but will return an error), user-space has to +make sure it completes all events it asked for. Sigh, I really dislike shared userspace/kernel stuff, when we're transfering pointers to userspace. Did you actually bench it against a: int async_wait(struct syslet_uatom **r, int n); I can fully understand sharing userspace buffers with the kernel, if we're talking about KB transferd during a block or net I/O DMA operation, but for transfering a pointer? Behind each pointer transfer(4/8 bytes) there is a whole syscall execution, [...] there are three main reasons for this choice: - firstly, by putting completion events into the user-space ringbuffer the asynchronous contexts are not held up at all, and the threads are available for further syslet use. - secondly, it was the most obvious and simplest solution to me - it just fits well into the syslet model - which is an execution concept centered around pure user-space memory and system calls, not some kernel resource. Kernel fills in the ringbuffer, user-space clears it. If we had to worry about a handshake between user-space and kernel-space
Re: [PATCH] Add PM_TRACE x86_64 support.
On Sat 2007-02-10 09:42:17, Jens Axboe wrote:
On Fri, Feb 09 2007, Pavel Machek wrote:
Hi!
Nigel Cunningham [EMAIL PROTECTED] writes:
- for (tracedata = __tracedata_start ; tracedata
__tracedata_end ; tracedata += 6) {
+ for (tracedata = __tracedata_start ; tracedata
__tracedata_end ; tracedata += 2 + sizeof(unsigned long)) {
Could you split this line?
Sure.
-- New version -- (What's the right way to do this?)
This patch add x86_64 support for PM_TRACE, and shifts per-arch code to
the appropriate subdirectories.
Symbol exports are added so tracing can be used from drivers built as
modules too.
Don't include exports in a patch that doesn't use them. Introduce the
exports in a later patch series, for when you actually need it.
It is debugging infrastructure, so export actually makes sense... It
will not ever be used in mainline kernel; you need to modify code
manually to use this code..
Then add the exports while you are modifying the other code, it's no
reason to put it in mainline.
Same could be said for the rest of the code, too... but Linus added it
to the mainline.
(Actually it has one example user somewhere, iirc)
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NAK new drivers without proper power management?
Hi! I would disagree that it's a peripheral issue, it's pretty core these days, at least for any hardware that you can stuff in a laptop (though a fair number of desktops get suspended and resumed these days too). Servers are still the most important Linux market, and don't care about suspend/resume. I would consider implementing suspend./resume for a driver that will only be used in server or HPC class hardware a waste of valuable development resources. Please allow me to be offensively blunt for a moment. So, the situation seems to be: 1. The work of the suspend developer who engages the users who put effort into making suspend work on their hardware (bless their addled little heads) often doesn't meet kernel standards, or isn't well enough documented to prove the real *need* for the features and/or hacks that have happened to get actual users' systems sleeping and running again. 2. The swsusp maintainer continues in the belief that as long as their are no bug reports in kernel bugzilla or crossing the (relatively obscure) swsusp mailing lists, it has zarro boogs and meanwhile works on the fourth implementation of suspend support in as many years. It's in CVS on sourceforge. There's no documentation whatsoever. 4. Everybody knows suspend doesn't work on Linux without a huge amount of tinkering, deep magic, and dead chickens. Only Gentoo users seem to bother; everyone else waits for Ubuntu 12.04 wherein suspend will just work. The Gentoo users all use swsusp2, as it contains the hacks to work around: Suspend just works in suse10.2 (and suse10.1, and suse10.0, ...)... thanks to work seife did on pm scripts. It is not my fault if it is broken on your distro. 6. Getting proper power-management support in Linux device drivers is not a priority; drivers without any power management support whatsoever should not only be accepted -- they should be merged without comment or complaint. How is working suspend support ever supposed to happen? If people stopped sending rants and started sending patches... yep, that would help. I don't have all the notebooks ever produced, sorry. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On Tue, Feb 13, 2007 at 11:58:02AM -0800, Andreas Gruenbacher wrote: I'm running pretty new GNOME and dbus here: dbus 1.0.2 gnome 2.16.2 hal 0.5.7.1 nautilus 2.16.3 Any ideas of things I can test? Sorry for the breakage. Printk of the __d_path result may tell: Index: b/fs/dcache.c === --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1803,6 +1803,8 @@ char *__d_path(struct dentry *dentry, st out: spin_unlock(dcache_lock); + printk(KERN_DEBUG %s(%d): %s\n, current-comm, current-pid, +IS_ERR(buffer) ? failed : buffer); return buffer; This causes the following to just loop over and over, incrementing the pid: gnome-vfs-daemo(8914): gnome-vfs-daemo(8914): / gnome-vfs-daemo(8914): /proc gnome-vfs-daemo(8914): /sys gnome-vfs-daemo(8914): /dev gnome-vfs-daemo(8914): /dev/pts gnome-vfs-daemo(8914): /dev/shm gnome-vfs-daemo(8914): /proc/bus/usb gnome-vfs-daemo(8914): /proc/sys/fs/binfmt_misc gnome-vfs-daemo(8918): gnome-vfs-daemo(8918): / gnome-vfs-daemo(8918): /proc gnome-vfs-daemo(8918): /sys gnome-vfs-daemo(8918): /dev gnome-vfs-daemo(8918): /dev/pts gnome-vfs-daemo(8918): /dev/shm gnome-vfs-daemo(8918): /proc/bus/usb gnome-vfs-daemo(8918): /proc/sys/fs/binfmt_misc and so on... I'm running gnome-vfs version 2.6.13 if that matters. Anything else I can try? 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: User tools for March 11
On Tuesday 13 February 2007 21:19, linux-os (Dick Johnson) wrote: Hi! In the United States, some idiots have decided that the year 2000 scare wasn't enough so they changed the start date for daylight savings time from the first Sunday in April to the second Sunday in March. Does anybody know if there are new tools like `hwclock` and `date`? Will new 'C' runtime libraries be necessary as well? Unless there are utilities homebrewing locales, glibc (locales) should be the only package that requires an update. Some distros may sub-package this as timezone. SLES got an updated timezone package for the Western Australian changes, but I'm not sure about the US changes. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: User tools for March 11
On Tue, Feb 13, 2007 at 04:19:59PM -0500, linux-os (Dick Johnson) wrote: Hi! In the United States, some idiots have decided that the year 2000 scare wasn't enough so they changed the start date for daylight savings time from the first Sunday in April to the second Sunday in March. Does anybody know if there are new tools like `hwclock` and `date`? Will new 'C' runtime libraries be necessary as well? Dick, UNIXes use UTC internally which has no DST, but for userspace there is tzdata package (with that name in Fedora, at least.) * Fri Jan 06 2006 Petr Machata [EMAIL PROTECTED] 2005r-2 - 2005r - Zones EST, MST, HST, EST5EDT, CST6CDT, MST7MDT, PST8PDT moved to northamerica to guard against old files with obsolete information being left in the time zone binary directory. - Changes for countries that are supposed to join 2007 US DST change. This includes most of Canada, however entries already in the database (Alberta, British Columbia, Newfoundland, Northwest Territories, and Yukon) were left alone for the time being. - Fixes in zdump.c (abbrok): conditions are chained, and the string is checked for emptiness. .. and many alterations since then. So.. you may already have it in your system. If not, just update that one package. Cheers, Dick Johnson /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 02/11] syslets: add syslet.h include file, user API/ABI definitions
* Indan Zupancic [EMAIL PROTECTED] wrote: + * Execution control: conditions upon the return code + * of the previous syslet atom. 'Stop' means syslet + * execution is stopped and the atom is put into the + * completion ring: + */ +#define SYSLET_STOP_ON_NONZERO 0x0008 +#define SYSLET_STOP_ON_ZERO0x0010 +#define SYSLET_STOP_ON_NEGATIVE0x0020 +#define SYSLET_STOP_ON_NON_POSITIVE0x0040 This is confusing. Why the return code of the previous syslet atom? Wouldn't it be more clear if the flag was for the current tasklet? Worse, what is the previous atom? [...] the previously executed atom. (I have fixed up the comment in my tree to say that.) [...] Imagine some case with a loop: A | B--. | | C---' What will be the previous atom of B here? It can be either A or C, but their return values can be different and incompatible, so what flag should B set? previous here is the previously executed atom, which is always a specific atom. Think of atoms as 'instructions', and these condition flags as the 'CPU flags' like 'zero' 'carry' 'sign', etc. Syslets can be thought of as streams of simplified instructions. +/* + * Special modifier to 'stop' handling: instead of stopping the + * execution of the syslet, the linearly next syslet is executed. + * (Normal execution flows along atom-next, and execution stops + * if atom-next is NULL or a stop condition becomes true.) + * + * This is what allows true branches of execution within syslets. + */ +#define SYSLET_SKIP_TO_NEXT_ON_STOP0x0080 + Might rename this to SYSLET_SKIP_NEXT_ON_STOP too then. but that's not what it does. It really 'skips to the next one on a stop event'. I.e. if you have three consecutive atoms (consecutive in linear memory): atom1 returns 0 atom2 has SYSLET_STOP_ON_ZERO|SYSLET_SKIP_NEXT_ON_STOP set atom3 then after atom1 returns 0, the SYSLET_STOP_ON_ZERO condition is recognized as a 'stop' event - but due to the SYSLET_SKIP_NEXT_ON_STOP flag execution does not stop (i.e. we do not return to user-space or complete the syslet), but we continue execution at atom3. this flag basically avoids having to add an atom-else pointer and keeps the data structure more compressed. Two-way branches are sufficiently rare, so i wanted to avoid the atom-else pointer. 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: User tools for March 11
On Tue, 2007-02-13 at 16:19 -0500, linux-os (Dick Johnson) wrote: Hi! In the United States, some idiots have decided that the year 2000 scare wasn't enough so they changed the start date for daylight savings time from the first Sunday in April to the second Sunday in March. Does anybody know if there are new tools like `hwclock` and `date`? Will new 'C' runtime libraries be necessary as well? Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.61 BogoMips). New book: http://www.AbominableFirebug.com/ Hi Dick, This timezone change will be handled by the distro makers, so you might want to check with them. This list is for discussion and development of the core linux kernel. Thanks. -- James Purser Producer/Presenter Open Source On The Air http://www.localfoss.org signature.asc Description: This is a digitally signed message part
[PROBLEM] Can't start MD devices by using /dev/disk/by-id
Hi chaps, I just came home, rebooted my box to git8 and *gasp* a problem :) I can't start my MD devices anymore by defining /dev/disk/by-id/* devices in /etc/mdadm.conf. When I do a: mdadm --assemble /dev/md/1 it tells me No devices found for /dev/md/1 When I edit the file /etc/mdadm.conf and change the /dev/disk/by-id/* to whatever the symbolic links points to in the /dev directory, it does work. An example: -- mdadm.conf ARRAY /dev/md/1 devices=/dev/disk/by-id/scsi-SATA_WDC_WD1200JB-00WD-WMAEL2258179-part1,/dev/disk/by-id/scsi-SATA_WDC_WD1200JB-00WD-WMACM1329740-part1 #ARRAY /dev/md/1 devices=/dev/sdb1,/dev/sdf1 ARRAY /dev/md/2 devices=/dev/disk/by-id/scsi-SATA_Maxtor_6L250R0_L609D78H-part1 ARRAY /dev/md/3 devices=/dev/disk/by-id/scsi-SATA_WDCD1600JB-00WD-WMAEK2977810-part1,/dev/disk/by-id/scsi-SATA_Maxtor_6Y160P0_Y48BCM3E-part1 -- end mdadm.conf -- localhost by-id # pwd /dev/disk/by-id localhost by-id # mdadm --assemble /dev/md/1 mdadm: no devices found for /dev/md/1 Let's change the config file now -- mdadm.conf -- #ARRAY /dev/md/1 devices=/dev/disk/by-id/scsi-SATA_WDC_WD1200JB-00WD-WMAEL2258179-part1,/dev/disk/by-id/scsi-SATA_WDC_WD1200JB-00WD-WMACM1329740-part1 ARRAY /dev/md/1 devices=/dev/sdb1,/dev/sdf1 ARRAY /dev/md/2 devices=/dev/disk/by-id/scsi-SATA_Maxtor_6L250R0_L609D78H-part1 ARRAY /dev/md/3 devices=/dev/disk/by-id/scsi-SATA_WDCD1600JB-00WD-WMAEK2977810-part1,/dev/disk/by-id/scsi-SATA_Maxtor_6Y160P0_Y48BCM3E-part1 And localhost by-id # mdadm --assemble /dev/md/1 mdadm: /dev/md/1 has been started with 2 drives. Now, granted, it's 22:49 and i had a sucky day at work but... this doesnt make any sense to me. So, I tried to use the vanilla 2.6.20 kernel, same problem. Here is a listing of symbolic links in /dev/disk/by-id , as you can see the initial mdadm.conf (which worked prior to 2.6.20) should work, since the links to the actual device nodes seem to be correct and taking in account the MD devices do start when using the /dev/ nodes. lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_Maxtor_6L250R0_L609D78H - ../../sdc lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_Maxtor_6L250R0_L609D78H-part1 - ../../sdc1 lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_Maxtor_6Y160P0_Y48BCM3E - ../../sde lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_Maxtor_6Y160P0_Y48BCM3E-part1 - ../../sde1 lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_WDC_WD1200JB-00WD-WMACM1329740 - ../../sdf lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD1200JB-00WD-WMACM1329740-part1 - ../../sdf1 lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_WDC_WD1200JB-00WD-WMAEL2258179 - ../../sdb lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD1200JB-00WD-WMAEL2258179-part1 - ../../sdb1 lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_WDC_WD1600JB-00WD-WMAEK2977810 - ../../sdd lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD1600JB-00WD-WMAEK2977810-part1 - ../../sdd1 lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867 - ../../sda lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part1 - ../../sda1 lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part2 - ../../sda2 lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part3 - ../../sda3 lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part4 - ../../sda4 lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part5 - ../../sda5 lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part6 - ../../sda6 lrwxrwxrwx 1 root root 9 Feb 12 05:40 usb-USB2.0_CardReader_CF_RW_586148026074 - ../../sdg Cheers, Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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/11] ANNOUNCE: Syslets, generic asynchronous system call support
* Davide Libenzi davidel@xmailserver.org wrote: Open issues: If this is going to be a generic AIO subsystem: - Cancellation of pending request How about implementing aio_cancel() as a NOP. Can anyone prove that the kernel didnt actually attempt to cancel that IO? [but unfortunately failed at doing so, because the platters were being written already.] really, what's the point behind aio_cancel()? Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CPU load
On Mon, 12 Feb 2007, Pavel Machek wrote: Hi! The kernel looks at what is using cpu _only_ during the timer interrupt. Which means if your HZ is 1000 it looks at what is running at precisely the moment those 1000 timer ticks occur. It is theoretically possible using this measurement system to use 99% cpu and record 0 usage if you time your cpu usage properly. It gets even more inaccurate at lower HZ values for the same reason. I have (had?) code that 'exploits' this. I believe I could eat 90% of cpu without being noticed. Slightly changed version of hog(around 3 lines in total changed) does that easily on 2.6.18.3 on PPC. http://www.boblycat.org/~malc/apc/load-hog-ppc.png -- vale - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please pull x86 updates
On Tue, 13 Feb 2007 13:40:56 +0100 Andi Kleen [EMAIL PROTECTED] wrote: Linux please pull from git://one.firstfloor.org/home/andi/git/linux-2.6 This is not all, but I pruned lots of stuff that still wasn't quite ready. Less is more I guess. I guess this means that hrtimersdynticks remains on hold. Do you have a feel for when batch #2 will be pushed? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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/11] ANNOUNCE: Syslets, generic asynchronous system call support
* Davide Libenzi davidel@xmailserver.org wrote: If this is going to be a generic AIO subsystem: - Cancellation of peding request What about the busy_async_threads list becoming a hash/rb_tree indexed by syslet_atom ptr. A cancel would lookup the thread and send a signal (of course, signal handling of the async threads should be set properly)? well, each async syslet has a separate TID at the moment, so if we want a submitted syslet to be cancellable then we could return the TID of the syslet handler (instead of the NULL) in sys_async_exec(). Then user-space could send a signal the old-fashioned way, via sys_tkill(), if it so wishes. the TID could also be used in a sys_async_wait_on() API. I.e. it would be a natural, readily accessible 'cookie' for the pending work. TIDs can be looked up lockless via RCU, so it's reasonably fast as well. ( Note that there's already a way to 'signal' pending syslets: do_exit() in the user context will signal all async contexts (which results in -EINTR of currently executing syscalls, wherever possible) and will tear them down. But that's too crude for aio_cancel() i guess. ) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/11] syslets: core code
Ingo Molnar [EMAIL PROTECTED] writes: + +static struct async_thread * +pick_ready_cachemiss_thread(struct async_head *ah) The cachemiss names are confusing. I assume that's just a left over from Tux? + + memset(atom-args, 0, sizeof(atom-args)); + + ret |= __get_user(arg_ptr, uatom-arg_ptr[0]); + if (!arg_ptr) + return ret; + if (!access_ok(VERIFY_WRITE, arg_ptr, sizeof(*arg_ptr))) + return -EFAULT; It's a little unclear why you do that many individual access_ok()s. And why is the target constant sized anyways? + /* +* Lock down the ring. Note: user-space should not munlock() this, +* because if the ring pages get swapped out then the async +* completion code might return a -EFAULT instead of the expected +* completion. (the kernel safely handles that case too, so this +* isnt a security problem.) +* +* mlock() is better here because it gets resource-accounted +* properly, and even unprivileged userspace has a few pages +* of mlock-able memory available. (which is more than enough +* for the completion-pointers ringbuffer) +*/ If it's only a few pages you don't need any resource accounting. If it's more then it's nasty to steal the users quota. I think plain gup() would be better. -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: Please pull x86 updates
On Tue, Feb 13, 2007 at 02:00:51PM -0800, Andrew Morton wrote: On Tue, 13 Feb 2007 13:40:56 +0100 Andi Kleen [EMAIL PROTECTED] wrote: Linux please pull from git://one.firstfloor.org/home/andi/git/linux-2.6 This is not all, but I pruned lots of stuff that still wasn't quite ready. Less is more I guess. I guess this means that hrtimersdynticks remains on hold. Why? The far majority of patches are included. Which patch do hrtimers/dynticks need which are missing? Do you have a feel for when batch #2 will be pushed? I only removed things that had unresolved technical issues. It depends on when they are resolved. -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 4/9] Remove the TSC synchronization on SMP machines
On Tue, Feb 13, 2007 at 06:20:14PM +0100, Andi Kleen wrote: On Tuesday 13 February 2007 18:09, Christoph Lameter wrote: On Tue, 13 Feb 2007, Arjan van de Ven wrote: no quite the opposite. gettimeofday() currently is NOT monotonic unfortunately. With this patchseries it actually has a better chance of becoming that... It is monotonic on IA64 at least and we have found that subtle application bugs occur if it is not. IA64 (and other arches using time interpolation) can insure the monotoneity of time sources. Are you sure about this? I wonder why the new time of day subsystem does not have that? Just to avoid spreading misinformation: modulo some new broken hardware (which we always try to work around when found) i386/x86-64 gettimeofday is monotonic. AFAIK on the currently known hardware it should be generally ok. However ntpd can always screw you up, but that's inherent in the design. It's not inherent to ntpd's design, but the current (which may have been fixed since I looked last) implementation of the NTP PLL in the kernel. The interaction with ntpd can be fixed and I've done it in the past once, although the fix wasn't all that nice. Safer in general is to use clock_gettime(CLOCK_MONOTONIC, ...) which guarantees no interference from ntpd -- Vojtech Pavlik Director SuSE Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
* Evgeniy Polyakov [EMAIL PROTECTED] wrote: [...] it still has a problem - syscall blocks and the same thread thus is not allowed to continue execution and fill the pipe - so what if system issues thousands of requests and there are only tens of working thread at most. [...] the same thread is allowed to continue execution even if the system call blocks: take a look at async_schedule(). The blocked system-call is 'put aside' (in a sleeping thread), the kernel switches the user-space context (registers) to a free kernel thread and switches to it - and returns to user-space as if nothing happened - allowing the user-space context to 'fill the pipe' as much as it can. Or did i misunderstand your point? basically there's SYSLET_ASYNC for 'always async' and SYSLET_SYNC for 'always sync' - but the default syslet behavior is: 'try sync and switch transparently to async on demand'. The testcode i sent very much uses this. (and this mechanism is in essence Zach's fibril-switching thing, but done via kernel threads.) 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: somebody dropped a (warning) bomb
On Tue, Feb 13, 2007 at 09:06:24PM +0300, Sergei Organov wrote: I agree that making strxxx() family special is not a good idea. So what do we do for a random foo(char*) called with an 'unsigned char*' argument? Silence? Hmmm... It's not immediately obvious that it's indeed harmless. Yet another -Wxxx option to GCC to silence this particular case? Silence would be good. char * has a special status in C, it can be: - pointer to a char/to an array of chars (standard interpretation) - pointer to a string - generic pointer to memory you can read(/write) Check the aliasing rules if you don't believe be on the third one. And it's *way* more often cases 2 and 3 than 1 for the simple reason that the signedness of char is unpredictable. As a result, a signedness warning between char * and (un)signed char * is 99.99% of the time stupid. May I suggest another definition for a warning being entirely sucks? The warning is entirely sucks if and only if it never has true positives. In all other cases it's only more or less sucks, IMHO. That means a warning that triggers on every line saying there may be a bug there does not entirely suck? I'm afraid I don't follow. Do we have a way to say I want an int of indeterminate sign in C? Almost completely. The rules on aliasing say you can convert pointer between signed and unsigned variants and the accesses will be unsurprising. The only problem is that the implicit conversion of incompatible pointer parameters to a function looks impossible in the draft I have. Probably has been corrected in the final version. In any case, having for instance unsigned int * in a prototype really means in the language I want a pointer to integers, and I'm probably going to use it them as unsigned, so beware. For the special case of char, since the beware version would require a signed or unsigned tag, it really means indeterminate. C is sometimes called a high-level assembler for a reason :-) The same way there doesn't seem to be a way to say I want a char of indeterminate sign. :( So no, strlen() doesn't actually say that, no matter if we like it or not. It actually says I want a char with implementation-defined sign. In this day and age it means I want a 0-terminated string. Everything else is explicitely signed char * or unsigned char *, often through typedefs in the signed case. In fact it's implementation-defined, and this may make a difference here. strlen(), being part of C library, could be specifically implemented for given architecture, and as architecture is free to define the sign of char, strlen() could in theory rely on particular sign of char as defined for given architecture. [Not that I think that any strlen() implementation actually depends on sign.] That would require pointers tagged in a way or another, you can't distinguish between pointers to differently-signed versions of the same integer type otherwise (they're required to have same size and alignment). You don't have that on modern architectures. Can we assure that no function taking 'char*' ever cares about the sign? I'm not sure, and I'm not a language lawyer, but if it's indeed the case, I'd probably agree that it might be a good idea for GCC to extend the C language so that function argument declared char* means either of char*, signed char*, or unsigned char* even though there is no precedent in the language. It's a warning you're talking about. That means it is _legal_ in the language (even if maybe implementation defined, but legal still). Otherwise it would be an error. BTW, the next logical step would be for int* argument to stop meaning signed int* and become any of int*, signed int* or unsigned int*. Isn't it cool to be able to declare a function that won't produce warning no matter what int is passed to it? ;) No, it wouldn't be logical, because char is *special*. Yes, indeed. So the real problem of the C language is inconsistency between strxxx() and isxxx() families of functions? If so, what is wrong with actually fixing the problem, say, by using wrappers over isxxx()? Checking... The kernel already uses isxxx() that are macros that do conversion to unsigned char themselves, and a few invocations of isspace() I've checked pass char as argument. So that's not a real problem for the kernel, right? Because a cast to silence a warning silences every possible warning even if the then-pointer turns for instance into an integer through an unrelated change. Think for instance about an error_t going from const char * (error string) to int (error code) through a patch, which happened to be passed to an utf8_to_whatever conversion function that takes an const unsigned char * as a parameter. Casting would hide the impact of changing the type. As the isxxx() family does not seem to be a real problem, at least in the context of the kernel source base, I'd like to learn other reasons to use unsigned char for doing strings either in general or
Re: CPU load
On Wednesday 14 February 2007 09:01, malc wrote: On Mon, 12 Feb 2007, Pavel Machek wrote: Hi! The kernel looks at what is using cpu _only_ during the timer interrupt. Which means if your HZ is 1000 it looks at what is running at precisely the moment those 1000 timer ticks occur. It is theoretically possible using this measurement system to use 99% cpu and record 0 usage if you time your cpu usage properly. It gets even more inaccurate at lower HZ values for the same reason. I have (had?) code that 'exploits' this. I believe I could eat 90% of cpu without being noticed. Slightly changed version of hog(around 3 lines in total changed) does that easily on 2.6.18.3 on PPC. http://www.boblycat.org/~malc/apc/load-hog-ppc.png I guess it's worth mentioning this is _only_ about displaying the cpu usage to userspace, as the cpu scheduler knows the accounting of each task in different ways. This behaviour can not be used to exploit the cpu scheduler into a starvation situation. Using the discrete per process accounting to accumulate the displayed values to userspace would fix this problem, but would be expensive. -- -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/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
* Evgeniy Polyakov [EMAIL PROTECTED] wrote: I have not received first mail with announcement yet, so I will place my thoughts here if you do not mind. An issue with sys_async_wait(): is is possible that events_left will be setup too late so that all events are already ready and thus sys_async_wait() can wait forever (or until next $sys_async_wait are ready)? yeah. I have fixed this up and have uploaded a newer queue to: http://redhat.com/~mingo/syslet-patches/ Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 02/11] syslets: add syslet.h include file, user API/ABI definitions
On Tue, February 13, 2007 22:43, Ingo Molnar wrote: * Indan Zupancic [EMAIL PROTECTED] wrote: A | B--. | | C---' What will be the previous atom of B here? It can be either A or C, but their return values can be different and incompatible, so what flag should B set? previous here is the previously executed atom, which is always a specific atom. Think of atoms as 'instructions', and these condition flags as the 'CPU flags' like 'zero' 'carry' 'sign', etc. Syslets can be thought of as streams of simplified instructions. In the diagram above the previously executed atom, when handling atom B, can be either atom A or atom C. So B doesn't know what kind of return value to expect, because it depends on the previous atom's kind of syscall, and not on B's return type. So I think you would want to move those return value flags one atom earlier, in this case to A and C. So each atom will have a flag telling what to to depending on its own return value. +/* + * Special modifier to 'stop' handling: instead of stopping the + * execution of the syslet, the linearly next syslet is executed. + * (Normal execution flows along atom-next, and execution stops + * if atom-next is NULL or a stop condition becomes true.) + * + * This is what allows true branches of execution within syslets. + */ +#define SYSLET_SKIP_TO_NEXT_ON_STOP 0x0080 + Might rename this to SYSLET_SKIP_NEXT_ON_STOP too then. but that's not what it does. It really 'skips to the next one on a stop event'. I.e. if you have three consecutive atoms (consecutive in linear memory): atom1 returns 0 atom2 has SYSLET_STOP_ON_ZERO|SYSLET_SKIP_NEXT_ON_STOP set atom3 then after atom1 returns 0, the SYSLET_STOP_ON_ZERO condition is recognized as a 'stop' event - but due to the SYSLET_SKIP_NEXT_ON_STOP flag execution does not stop (i.e. we do not return to user-space or complete the syslet), but we continue execution at atom3. this flag basically avoids having to add an atom-else pointer and keeps the data structure more compressed. Two-way branches are sufficiently rare, so i wanted to avoid the atom-else pointer. The flags are smart, they're just at the wrong place I think. In your example, if atom3 has a 'next' pointing to atom2, atom2 wouldn't know which return value it's checking: The one of atom1, or the one of atom3? You're spreading syscall specific knowledge over multiple atoms while that isn't necessary. What I propose: atom1 returns 0, has SYSLET_STOP_ON_ZERO|SYSLET_SKIP_NEXT_ON_STOP set atom2 atom3 (You've already used my SYSLET_SKIP_NEXT_ON_STOP instead of SYSLET_SKIP_TO_NEXT_ON_STOP. ;-) Perhaps it's even more clear when splitting that SYSLET_STOP_* into a SYSLET_STOP flag, and specific SYSLET_IF_* flags. Either that, or go all the way and introduce seperate SYSLET_SKIP_NEXT_ON_*. atom1 returns 0, has SYSLET_SKIP_NEXT|SYSLET_IF_ZERO set atom2 atom3 Greetings, Indan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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/11] ANNOUNCE: Syslets, generic asynchronous system call support
Ingo Molnar [EMAIL PROTECTED] writes: really, what's the point behind aio_cancel()? The main use case is when you open a file requester on a network file system where the server is down and you get tired of waiting and press Cancel it should abort the hanging IO immediately. At least I would appreciate such a feature sometimes. e.g. the readdir loop could be a syslet (are they powerful enough to allocate memory for a arbitary sized directory? Probably not) and then the cancel button could async_cancel() 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: [patch 05/11] syslets: core code
* Andi Kleen [EMAIL PROTECTED] wrote: Ingo Molnar [EMAIL PROTECTED] writes: + +static struct async_thread * +pick_ready_cachemiss_thread(struct async_head *ah) The cachemiss names are confusing. I assume that's just a left over from Tux? yeah. Although 'stuff goes async' is quite similar to a cachemiss. We didnt have some resource available right now so the syscall has to block == i.e. some cache was not available. + + memset(atom-args, 0, sizeof(atom-args)); + + ret |= __get_user(arg_ptr, uatom-arg_ptr[0]); + if (!arg_ptr) + return ret; + if (!access_ok(VERIFY_WRITE, arg_ptr, sizeof(*arg_ptr))) + return -EFAULT; It's a little unclear why you do that many individual access_ok()s. And why is the target constant sized anyways? each indirect pointer has to be checked separately, before dereferencing it. (Andrew pointed out that they should be VERIFY_READ, i fixed that in my tree) it looks a bit scary in C but the assembly code is very fast and quite straightforward. + /* + * Lock down the ring. Note: user-space should not munlock() this, + * because if the ring pages get swapped out then the async + * completion code might return a -EFAULT instead of the expected + * completion. (the kernel safely handles that case too, so this + * isnt a security problem.) + * + * mlock() is better here because it gets resource-accounted + * properly, and even unprivileged userspace has a few pages + * of mlock-able memory available. (which is more than enough + * for the completion-pointers ringbuffer) + */ If it's only a few pages you don't need any resource accounting. If it's more then it's nasty to steal the users quota. I think plain gup() would be better. get_user_pages() would have to be limited in some way - and i didnt want to add yet another wacky limit thing - so i just used the already existing mlock() infrastructure for this. If Oracle wants to set up a 10 MB ringbuffer, they can set the PAM resource limits to 11 MB and still have enough stuff left. And i dont really expect GPG to start using syslets - just yet ;-) a single page is enough for 1024 completion pointers - that's more than enough for most purposes - and the default mlock limit is 40K. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
* Andi Kleen [EMAIL PROTECTED] wrote: really, what's the point behind aio_cancel()? The main use case is when you open a file requester on a network file system where the server is down and you get tired of waiting and press Cancel it should abort the hanging IO immediately. ok, that should work fine already - exit in the user context gets propagated to all async syslet contexts immediately. So if the syscalls that the syslet uses are reasonably interruptible, it will work out fine. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/11] syslets: core code
On Tue, Feb 13, 2007 at 11:24:43PM +0100, Ingo Molnar wrote: + memset(atom-args, 0, sizeof(atom-args)); + + ret |= __get_user(arg_ptr, uatom-arg_ptr[0]); + if (!arg_ptr) + return ret; + if (!access_ok(VERIFY_WRITE, arg_ptr, sizeof(*arg_ptr))) + return -EFAULT; It's a little unclear why you do that many individual access_ok()s. And why is the target constant sized anyways? each indirect pointer has to be checked separately, before dereferencing it. (Andrew pointed out that they should be VERIFY_READ, i fixed that in my tree) But why only constant sized? It could be a variable length object, couldn't it? If it's an array it could be all checked together (i must be missing something here) If it's only a few pages you don't need any resource accounting. If it's more then it's nasty to steal the users quota. I think plain gup() would be better. get_user_pages() would have to be limited in some way - and i didnt want If you only use it for a small ring buffer it is naturally limited. Also beancounter will fix that eventually. a single page is enough for 1024 completion pointers - that's more than enough for most purposes - and the default mlock limit is 40K. Then limit it to a single page and use gup -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: Bug in current -git tree causing dbus and gnome to chew up cpu time
On Tuesday 13 February 2007 13:37, Greg KH wrote: On Tue, Feb 13, 2007 at 11:58:02AM -0800, Andreas Gruenbacher wrote: I'm running pretty new GNOME and dbus here: dbus 1.0.2 gnome 2.16.2 hal 0.5.7.1 nautilus 2.16.3 Any ideas of things I can test? Sorry for the breakage. Printk of the __d_path result may tell: Index: b/fs/dcache.c === --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1803,6 +1803,8 @@ char *__d_path(struct dentry *dentry, st out: spin_unlock(dcache_lock); + printk(KERN_DEBUG %s(%d): %s\n, current-comm, current-pid, + IS_ERR(buffer) ? failed : buffer); return buffer; This causes the following to just loop over and over, incrementing the pid: gnome-vfs-daemo(8914): That's the weird case, and it should only trigger if there's no path to be recovered from what gnome-vfs-deamon calls d_path on, like a lazily unmounted filesystem. (A bind mount wouldn't do.) I'm running gnome-vfs version 2.6.13 if that matters. Anything else I can try? I guess I'll just have to check what gnome-vfs-deamon does, thanks. Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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/11] ANNOUNCE: Syslets, generic asynchronous system call support
On Tue, Feb 13, 2007 at 11:26:26PM +0100, Ingo Molnar wrote: * Andi Kleen [EMAIL PROTECTED] wrote: really, what's the point behind aio_cancel()? The main use case is when you open a file requester on a network file system where the server is down and you get tired of waiting and press Cancel it should abort the hanging IO immediately. ok, that should work fine already - exit in the user context gets That would be a little heavy handed. I wouldn't expect my GUI program to quit itself on cancel. And requiring it to create a new thread just to exit on cancel would be also nasty. And of course you cannot interrupt blocked IOs this way right now (currently it only works with signals in some cases on NFS) -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 02/11] syslets: add syslet.h include file, user API/ABI definitions
* Indan Zupancic [EMAIL PROTECTED] wrote: What I propose: atom1 returns 0, has SYSLET_STOP_ON_ZERO|SYSLET_SKIP_NEXT_ON_STOP set atom2 atom3 (You've already used my SYSLET_SKIP_NEXT_ON_STOP instead of SYSLET_SKIP_TO_NEXT_ON_STOP. ;-) doh. Yes. I noticed and implemented this yesterday and it's in the submitted syslet code - but i guess i was too tired to remember my own code - so i added the wrong comments :-/ If you look at the sample user-space code: init_atom(req, req-open_file, __NR_sys_open, req-filename_p, O_RDONLY_var, NULL, NULL, NULL, NULL, req-fd, SYSLET_STOP_ON_NEGATIVE, req-read_file); the 'STOP_ON_NEGATIVE' acts on that particular atom. this indeed cleaned up things quite a bit and made the user-space syslet code alot more straightforward. A return value can still be recovered and examined (with a different condition and a different jump target) arbitrary number of times via ret_ptr and via sys_umem_add(). Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
Hi Ingo, On Tuesday 13 February 2007 15:39, Ingo Molnar wrote: * Dmitry Torokhov [EMAIL PROTECTED] wrote: What are the semantics of async sys_async_wait and async sys_async ? Ohh. OpenVMS lives forever ;) Me likeee ;) hm, i dont know OpenVMS - but googled around a bit for 'VMS asynchronous' and it gave me this: http://en.wikipedia.org/wiki/Asynchronous_system_trap is AST what you mean? From a quick read AST seems to be a signal mechanism a bit like Unix signals, extended to kernel-space as well - while syslets are a different 'safe execution engine' kind of thing centered around the execution of system calls. That is only one of ways of notifying userspace of system call completion on OpenVMS. Pretty much every syscall there exists in 2 flavors - async and sync, for example $QIO and $QIOW or $ENQ/$ENQW (actually -W flavor is async call + $SYNCH to wait for completion). Once system service call is completed the OS would raise a so-called event flag and may also deliver an AST to the process. Application may either wait for an event flag/set of event flags (EFN) or rely on AST to get notification. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/9] Remove the TSC synchronization on SMP machines
Hi, On Tue, Feb 13, 2007 at 11:18:48PM +0100, Vojtech Pavlik wrote: It's not inherent to ntpd's design, but the current (which may have been fixed since I looked last) implementation of the NTP PLL in the kernel. The interaction with ntpd can be fixed and I've done it in the past once, although the fix wasn't all that nice. Yep, it can slowly move towards the correct time, but ntpdate (or more generally settimeofday) remains a fundamental issue (and I prefer time skews to be fixed ASAP, not slowly). If the admin is good, he can know that if he ever runs the db when the clock isn't perfectly synchronized with the atomic clock, he risks to screwup his whole dataset as the apps won't even handle time going backwards after reboot. I think there should be a limit to how much an app can pretend from gtod before generating failures. Certainly it's always better to write apps that are robust against a not monotonic gtod because eventually it _can_ happen (either that or remove the stod syscall ;). About ntpdate at boot and ntpd at runtime, not running them isn't really an option on the server IMHO, think the liability if system time runs out of sync of a minute and you need to know exactly when something bad has happened. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On Tuesday February 13, [EMAIL PROTECTED] wrote:
This causes the following to just loop over and over, incrementing the
pid:
gnome-vfs-daemo(8914):
That's odd. getcwd returning an empty string.
I can only see that happening if you do the equivalent of
chdir(/);
chroot(/somewhere);
getcwd(buf,sizeof(buf));
That would return an empty string with the new code but not with the
old.
But I cannot imagine gnome-vfs-daemon doing a chroot, as it does not
run as root.
You could try removing the
if (*buffer == '/') {
buffer++;
buflen++;
}
from the new __d_path. But that still wouldn't really explain what
was happening.
Maybe also put a WARN_ON(! *buffer) just before the return to find out
exactly what is going on when the empty string is returned.
NeilBrown
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] build error: allnoconfig fails on mincore/swapper_space
On Tue, 13 Feb 2007, Randy Dunlap wrote:
On Tue, 13 Feb 2007 13:48:53 +1100 Nick Piggin wrote:
Andrew Morton wrote:
On Mon, 12 Feb 2007 14:50:40 -0800 Randy Dunlap [EMAIL PROTECTED] wrote:
2.6.20-git8 on x86_64:
LD init/built-in.o
LD .tmp_vmlinux1
mm/built-in.o: In function `sys_mincore':
(.text+0xe584): undefined reference to `swapper_space'
make: *** [.tmp_vmlinux1] Error 1
oops. CONFIG_SWAP=n, I assume?
Hmm, OK. Hugh can strip me of my bonus point now...
No, Nick, you get to keep your bonus point, it was for remembering
migration pages. I was the devil who tempted you into using
find_get_page(swapper_space,).
Hugh, you can strip me of my bonus point now... How about your other
suggestion to just remove the stats from lookup_swap_cache? (and should
we also rename it to find_get_swap_page?)
Not at this point. I won't mind you putting up a patch doing that for
discussion and inclusion in -mm (if you do, then read_swap_cache_async
should use it too), but it's not now an appropriate fix to the
CONFIG_SWAP=n build issue.
I need a fix for this. It's killing my daily/automated builds.
So here is an ifdeffery-fix.
Sorry for being so slow to respond on this. Yes, I'm inclined to
your ifdeffery fix - one can go cleverer, but I'd say it's the
appropriate fix now.
But, please change your present = 0; to present = 1; -
if CONFIG_SWAP isn't on, it has to be a migration entry,
which always counts as present.
BUT: what is present used for in that loop? or is it used?
Well spotted! Something has gone missing: there needs to be a
vec[i] = present;
at the bottom of that loop.
Hugh
---
From: Randy Dunlap [EMAIL PROTECTED]
Don't check for pte swap entries when CONFIG_SWAP=n.
mm/built-in.o: In function `sys_mincore':
(.text+0xe584): undefined reference to `swapper_space'
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
mm/mincore.c |4
1 file changed, 4 insertions(+)
--- linux-2.6.20-git8.orig/mm/mincore.c
+++ linux-2.6.20-git8/mm/mincore.c
@@ -111,6 +111,7 @@ static long do_mincore(unsigned long add
present = mincore_page(vma-vm_file-f_mapping, pgoff);
} else { /* pte is a swap entry */
+#ifdef CONFIG_SWAP
swp_entry_t entry = pte_to_swp_entry(pte);
if (is_migration_entry(entry)) {
/* migration entries are always uptodate */
@@ -119,6 +120,9 @@ static long do_mincore(unsigned long add
pgoff = entry.val;
present = mincore_page(swapper_space, pgoff);
}
+#else
+ present = 0;
+#endif
}
}
pte_unmap_unlock(ptep-1, ptl);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
whatever happened to down_timeout()?
There has been some discussion on lkml about a function that would
either down a semaphore or else abort if it couldn't get the semaphore
in a certain amount of time. Something along the lines of:
down_timeout(struct semaphore *sem, long timeout);
Does something like this exist? Does anyone have a working
implementation? Does anyone see anything obviously wrong with the
following version (that I loosely based on one by Rupert Eibauer)?
semaphore.h:
extern int __down_timeout(struct semaphore * sem, unsigned int timeout);
/* timeout is the number of jiffies to wait.
* Returns -ETIME if timeout period expires.
*/
static inline int down_timeout(struct semaphore * sem, unsigned int timeout)
{
int ret = down_trylock(sem);
if (!ret)
ret = __down_timeout(sem, timeout);
return ret;
}
kernel/timer.c
int __down_timeout(struct semaphore * sem, int timeout)
{
int ret;
unsigned long expire;
struct timer_list timer;
expire = jiffies + timeout;
init_timer(timer);
timer.expires = expire;
timer.data = (unsigned long) current;
timer.function = process_timeout;
add_timer(timer);
ret = down_interruptible(sema);
if (ret (jiffies expire))
ret = -ETIME;
else
del_timer_sync(timer);
return ret;
}
Thanks,
Chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/11] syslets: core code
* Andi Kleen [EMAIL PROTECTED] wrote: + if (!access_ok(VERIFY_WRITE, arg_ptr, sizeof(*arg_ptr))) + return -EFAULT; It's a little unclear why you do that many individual access_ok()s. And why is the target constant sized anyways? each indirect pointer has to be checked separately, before dereferencing it. (Andrew pointed out that they should be VERIFY_READ, i fixed that in my tree) But why only constant sized? It could be a variable length object, couldn't it? i think what you might be missing is that it's only the 6 syscall arguments that are fetched via indirect pointers - security checks are then done by the system calls themselves. It's a bit awkward to think about, but it is surprisingly clean in the assembly, and it simplified syslet programming too. get_user_pages() would have to be limited in some way - and i didnt want If you only use it for a small ring buffer it is naturally limited. yeah, but 'small' is a dangerous word when it comes to adding IO interfaces ;-) a single page is enough for 1024 completion pointers - that's more than enough for most purposes - and the default mlock limit is 40K. Then limit it to a single page and use gup 1024 (512 on 64-bit) is alot but not ALOT. It is also certainly not ALT :-) Really, people will want to have more than 512 disks/spindles in the same box. I have used such a beast myself. For Tux workloads and benchmarks we had parallelism levels of millions of pending requests (!) on a single system - networking, socket limits, disk IO combined with thousands of clients do create such scenarios. I really think that such 'pinned pages' are a pretty natural fit for sys_mlock() and RLIMIT_MEMLOCK, and since the kernel side is careful to use the _inatomic() uaccess methods, it's safe (and fast) as well. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
* Andi Kleen [EMAIL PROTECTED] wrote: ok, that should work fine already - exit in the user context gets That would be a little heavy handed. I wouldn't expect my GUI program to quit itself on cancel. And requiring it to create a new thread just to exit on cancel would be also nasty. And of course you cannot interrupt blocked IOs this way right now (currently it only works with signals in some cases on NFS) ok. The TID+signal approach i mentioned in the other reply should work. If it's frequent enough we could make this an explicit sys_async_cancel(TID) API. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
ok. The TID+signal approach i mentioned in the other reply should work. Not sure if a signal is good for this. It might conflict with existing strange historical semantics. If it's frequent enough we could make this an explicit sys_async_cancel(TID) API. Ideally there should be a new function like signal_pending() that checks for this. Then the network fs could check those in their blocking loops and error out. Then it would even work on non intr NFS mounts. -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 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
On Tue, Feb 13, 2007 at 10:57:24PM +0100, Ingo Molnar wrote: * Davide Libenzi davidel@xmailserver.org wrote: Open issues: If this is going to be a generic AIO subsystem: - Cancellation of pending request How about implementing aio_cancel() as a NOP. Can anyone prove that the kernel didnt actually attempt to cancel that IO? [but unfortunately failed at doing so, because the platters were being written already.] really, what's the point behind aio_cancel()? Lemme give you a real-world scenario: Question Answering in a Dialog System. Your locked-in-memory index ranks documents in a several million files corpus depending of the chances they have to have what you're looking for. You have a tenth of a second to read as many of them as you can, and each seek is 5ms. So you aio-read them, requesting them in order of ranking up to 200 or so, and see what you have at the 0.1s deadline. If you're lucky, a combination of cache (especially if you stat() the whole dir tree on a regular basis to keep the metadata fresh in cache) and of good io reorganisation by the scheduler will allow you to get a good number of them and do the information extraction, scoring and clustering of answers, which is pure CPU at that point. You *have* to cancel the remaining i/o because you do not want the disk saturated when the next request comes, especially if it's 10ms later because the dialog manager found out it needed a complementary request. Incidentally, that's something I'm currently implementing for work, making these aio discussions more interesting that usual :-) OG. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] build error: allnoconfig fails on mincore/swapper_space
oops. CONFIG_SWAP=n, I assume?
Sorry for being so slow to respond on this. Yes, I'm inclined to
your ifdeffery fix - one can go cleverer, but I'd say it's the
appropriate fix now.
But, please change your present = 0; to present = 1; -
if CONFIG_SWAP isn't on, it has to be a migration entry,
which always counts as present.
BUT: what is present used for in that loop? or is it used?
Well spotted! Something has gone missing: there needs to be a
vec[i] = present;
at the bottom of that loop.
From: Randy Dunlap [EMAIL PROTECTED]
Don't check for pte swap entries when CONFIG_SWAP=n.
And save 'present' in the vec array.
mm/built-in.o: In function `sys_mincore':
(.text+0xe584): undefined reference to `swapper_space'
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
mm/mincore.c |5 +
1 file changed, 5 insertions(+)
--- linux-2.6.20-git9.orig/mm/mincore.c
+++ linux-2.6.20-git9/mm/mincore.c
@@ -111,6 +111,7 @@ static long do_mincore(unsigned long add
present = mincore_page(vma-vm_file-f_mapping, pgoff);
} else { /* pte is a swap entry */
+#ifdef CONFIG_SWAP
swp_entry_t entry = pte_to_swp_entry(pte);
if (is_migration_entry(entry)) {
/* migration entries are always uptodate */
@@ -119,7 +120,11 @@ static long do_mincore(unsigned long add
pgoff = entry.val;
present = mincore_page(swapper_space, pgoff);
}
+#else
+ present = 1;
+#endif
}
+ vec[i] = present;
}
pte_unmap_unlock(ptep-1, ptl);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 05/11] syslets: core code
On Tue, 13 Feb 2007 23:24:43 +0100 Ingo Molnar [EMAIL PROTECTED] wrote: If it's only a few pages you don't need any resource accounting. If it's more then it's nasty to steal the users quota. I think plain gup() would be better. get_user_pages() would have to be limited in some way - and i didnt want to add yet another wacky limit thing - so i just used the already existing mlock() infrastructure for this. If Oracle wants to set up a 10 MB ringbuffer, they can set the PAM resource limits to 11 MB and still have enough stuff left. And i dont really expect GPG to start using syslets - just yet ;-) a single page is enough for 1024 completion pointers - that's more than enough for most purposes - and the default mlock limit is 40K. So if I have an application which instantiates a single mlocked page for this purpose, I can only run ten of them at once, and any other mlock-using process which I'm using starts to mysteriously fail. It seems like a problem to me.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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/11] ANNOUNCE: Syslets, generic asynchronous system call support
Ingo Molnar wrote: really, what's the point behind aio_cancel()? - sequence aio_write() aio_cancel() aio_write() with both writes going to the same place must be predictably - think beyond files. Writes to sockets, ttys, they can block and cancel must abort them. Even for files the same applies in some situations, e.g., for network filesystems. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On Tuesday 13 February 2007 14:39, Neil Brown wrote: On Tuesday February 13, [EMAIL PROTECTED] wrote: This causes the following to just loop over and over, incrementing the pid: gnome-vfs-daemo(8914): That's odd. getcwd returning an empty string. I can only see that happening if you do the equivalent of chdir(/); chroot(/somewhere); getcwd(buf,sizeof(buf)); The other case I'm aware of is this: $ mount -o loop image /mnt $ cd /mnt $ umount -l /mnt $ /bin/pwd Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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/11] VMI / Paravirt bugfixes for 2.6.21
Andi Kleen wrote: hmm stolen time could even be useful without virtualization; to a large degree, if cpufreq reduces the speed of your cpu you have stolen cycles that way... I wonder if this concept can be used for that as well... I don't see the point, frankly. In a virtualized environment, steal time shows the amount of contention between guests. If you have two guests trying to use 100% of the CPU, but they have to share the CPU and each gets 50%, then the steal time will be 50% on each guest. This allows the sysadmin to see that the guests would have been able to run faster, if only they were not fighting over the same CPU. Performance could have been improved by doing live migration. Contrast this to a client/server (or backend/middle tier) application on one system, where both virtual machines work together. They can still end up getting 50% of the CPU each, but a lot of the time they do not want the CPU simultaneously. In that case, there will be idle time and the amount of steal time will be way lower. Steal time allows you to distinguish between the CPU is not fast enough and I have too many virtual machines on the CPU and things are running OK. As for steal time in a non-virtualized environment, I am not quite sure either. I can't think of any action the sysadmin (or some load balancing program) could take, based on the information... -- All Rights Reversed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20 new perfmon code base + libpfm + pfmon
Hello, I have released another version of the perfmon new code base package. This version of the kernel patch is relative to 2.6.20. This new kernel patch includes the following new features and bug fixes: - first cut at supporting Oprofile on i386 and x86-64 architectures - several internal interfaces simplfications - various MIPS updates (Phil Mucci/Manoj Ekbote) - varous PPC32 updates (Phil Mucci) - fix bug in set switching with a single set - fix bug in pfm_restart() for per-thread mode with blocking notification Unfortunately, this release does not build for PowerPC due to a problem with the TIF_* flags. Perfmon adds 2 new flags which make the TIF now use more than 16 bits which causes problem with some assembly instructions in entry_64.S. Hopefully, this will be fixed in the next release. To make Oprofile work, you need a modified user level Oprofile package. I have made a first pass at modifying 0.9.2 to work on Perfmon 2.3 (and v2.0 for IA-64) for the following processors: AMD Opteron, P6, Core Duo, Core 2 Duo, P4. The modified package is available as Alpha at: ftp://ftp.hpl.hp.com/pub/linux-ia64/oprof-perfmon2-070122.diff I have also released a new libpfm, libpfm-3.2-070206, with lots of changes. Here are some of the most important ones: - Full Intel Core 2 Duo event table (Thanks to Dan Terpstra for his help) - Full event table for P6 and Pentium M (Dan Terpstra) - various MIPS updates (Phil Mucci) - improved Montecito event-counter assignment routine - rewritten P6 event-counter assignment routine - extended detect_unavail_pmcs() code to handle pmds - extended whichpmu.c example to show implement vs. available registers - possiblity to force a libpfm PMU different from host PMU - several bug fixes to library and examples Also a new version of pfmon, pfmon-3.2-070206, with a few changes: - rewritten the automatic sampling buffer sizing based on the resource limits (rlimits) and perfmon global settings - Intel Core 2 Duo event listing now shows if event supports PEBS - fixed important memory leak that showed up when monitoring across fork/pthread You can get the packages and more detailed changelogs our the web site: http://perfmon2.sf.net (go to Project Files) Enjoy, PS: home page not yet updated due to a problem connecting via ssh to SF.net today. -- -Stephane - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Open Firmware serial port driver
This can be used for serial ports that are connected to an
OF platform bus but are not autodetected by the lecacy
serial support.
It will automatically take over devices that come from the
legacy serial detection, which usually is only one device.
In some cases, rtas may be set up to use the serial port
in the firmware, which allows easier debugging before probing
the serial ports. In this case, the used-by-rtas property
must be set by the firmware. This patch also adds code to the
legacy serial driver to check for this.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
---
Who will handle this driver? It is powerpc specific and
hooks into powerpc code at one place, but it's also a
new driver for the (orphaned) serial layer.
Could either Paul or Andrew merge this, or whoever
else feels responsible?
arch/powerpc/kernel/legacy_serial.c | 15 +
drivers/serial/Kconfig | 10 +
drivers/serial/Makefile |1
drivers/serial/of_serial.c | 143
4 files changed, 169 insertions(+)
Index: linux-2.6/drivers/serial/Makefile
===
--- linux-2.6.orig/drivers/serial/Makefile
+++ linux-2.6/drivers/serial/Makefile
@@ -58,3 +58,4 @@ obj-$(CONFIG_SERIAL_SGI_IOC3) += ioc3_se
obj-$(CONFIG_SERIAL_ATMEL) += atmel_serial.o
obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
+obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
Index: linux-2.6/drivers/serial/of_serial.c
===
--- /dev/null
+++ linux-2.6/drivers/serial/of_serial.c
@@ -0,0 +1,143 @@
+/*
+ * Serial Port driver for Open Firmware platform devices
+ *
+ *Copyright (C) 2006 Arnd Bergmann [EMAIL PROTECTED], IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+#include linux/init.h
+#include linux/module.h
+#include linux/serial_core.h
+#include linux/serial_8250.h
+
+#include asm/of_platform.h
+#include asm/prom.h
+
+/*
+ * Fill a struct uart_port for a given device node
+ */
+static int __devinit of_platform_serial_setup(struct of_device *ofdev,
+ int type, struct uart_port *port)
+{
+ struct resource resource;
+ struct device_node *np = ofdev-node;
+ const unsigned int *clk, *spd;
+ int ret;
+
+ memset(port, 0, sizeof *port);
+ spd = get_property(np, current-speed, NULL);
+ clk = get_property(np, clock-frequency, NULL);
+ if (!clk) {
+ dev_warn(ofdev-dev, no clock-frequency property set\n);
+ return -ENODEV;
+ }
+
+ ret = of_address_to_resource(np, 0, resource);
+ if (ret) {
+ dev_warn(ofdev-dev, invalid address\n);
+ return ret;
+ }
+
+ spin_lock_init(port-lock);
+ port-mapbase = resource.start;
+ port-irq = irq_of_parse_and_map(np, 0);
+ port-iotype = UPIO_MEM;
+ port-type = type;
+ port-uartclk = *clk;
+ port-flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP;
+ port-dev = ofdev-dev;
+ port-custom_divisor = *clk / (16 * (*spd));
+
+ return 0;
+}
+
+/*
+ * Try to register a serial port
+ */
+static int __devinit of_platform_serial_probe(struct of_device *ofdev,
+ const struct of_device_id *id)
+{
+ struct uart_port port;
+ int port_type;
+ int ret;
+
+ if (of_find_property(ofdev-node, used-by-rtas, NULL))
+ return -EBUSY;
+
+ port_type = (unsigned long)id-data;
+ ret = of_platform_serial_setup(ofdev, port_type, port);
+ if (ret)
+ goto out;
+
+ switch (port_type) {
+ case PORT_UNKNOWN:
+ dev_info(ofdev-dev, Unknown serial port found,
+ attempting to use 8250 driver\n);
+ /* fallthrough */
+ case PORT_8250 ... PORT_MAX_8250:
+ ret = serial8250_register_port(port);
+ break;
+ default:
+ /* need to add code for these */
+ ret = -ENODEV;
+ break;
+ }
+ if (ret 0)
+ goto out;
+
+ ofdev-dev.driver_data = (void *)(unsigned long)ret;
+ return 0;
+out:
+ irq_dispose_mapping(port.irq);
+ return ret;
+}
+
+/*
+ * Release a line
+ */
+static int of_platform_serial_remove(struct of_device *ofdev)
+{
+ int line = (unsigned long)ofdev-dev.driver_data;
+ serial8250_unregister_port(line);
+ return 0;
+}
+
+/*
+ * A few common types, add more as needed.
+ */
+static struct of_device_id __devinitdata of_platform_serial_table[] = {
+ { .type = serial, .compatible = ns8250, .data =
Re: [perfmon] 2.6.20 new perfmon code base + libpfm + pfmon
Stephane Eranian wrote: Hello, I have released another version of the perfmon new code base package. This version of the kernel patch is relative to 2.6.20. This new kernel patch includes the following new features and bug fixes: - first cut at supporting Oprofile on i386 and x86-64 architectures - several internal interfaces simplfications - various MIPS updates (Phil Mucci/Manoj Ekbote) - varous PPC32 updates (Phil Mucci) - fix bug in set switching with a single set - fix bug in pfm_restart() for per-thread mode with blocking notification Unfortunately, this release does not build for PowerPC due to a problem with the TIF_* flags. Perfmon adds 2 new flags which make the TIF now use more than 16 bits which causes problem with some assembly instructions in entry_64.S. Hopefully, this will be fixed in the next release. To make Oprofile work, you need a modified user level Oprofile package. I have made a first pass at modifying 0.9.2 to work on Perfmon 2.3 (and v2.0 for IA-64) for the following processors: AMD Opteron, P6, Core Duo, Core 2 Duo, P4. The modified package is available as Alpha at: ftp://ftp.hpl.hp.com/pub/linux-ia64/oprof-perfmon2-070122.diff Hello Stephane, The oprofile patch should be made against the oprofile cvs rather than the 0.9.2 tarball. There are some files that the patch touches that are created by the autogen.sh. The oprofile patch doesn't build if things are configured without the --enable-perfmon2. gcc -W -Wall -fno-common -Wdeclaration-after-statement -fno-omit-frame-pointer -g -O2 -o oprofiled init.o oprofiled.o opd_stats.o opd_sfile.o opd_kernel.o opd_trans.o opd_cookie.o opd_events.o opd_mangling.o opd_perfmon.o opd_perfmon_22.o opd_perfmon_compat.o opd_anon.o liblegacy/liblegacy.a ../libabi/libabi.a ../libdb/libodb.a ../libop/libop.a ../libutil/libutil.a -lpopt -liberty -ldl opd_perfmon.o: In function `perfmon_init': /home/wcohen/research/profiling/oprofile/oprofile-0.9.2-perfmon2/daemon/opd_perfmon.c:384: undefined reference to `do_perfmon_init' collect2: ld returned 1 exit status -Will - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] serial driver PMC MSP71xx, kernel linux-mips.git mast er
Andrew Morton wrote:
On Mon, 12 Feb 2007 12:04:08 -0600 Marc St-Jean
[EMAIL PROTECTED] wrote:
There are three different fixes:
1. Fix for DesignWare THRE errata
- Dropped our fix since the 8250-uart-backup-timer.patch in the mm
tree also fixes it. This patch needs to be applied on top of mm patch.
2. Fix for Busy Detect on LCR write
- No changes since last patch.
3. Workaround for interrupt/data concurrency issue
- No changes since last patch.
A couple of things.
- When preparing a changelog, please just tell us what the patch does.
The information about how this patch differes from a previous version of
the patch is irrelevant when the patch hits the mainline repository hence
I must edit it all.
It's OK to add the what-i-changed-since-last-time details, but please
make
that separate and remember that it will be removed for when the patch
goes
upstream.
- When fixing a bug, please tell us in detail what that bug *is*. None
of the above three items tell us any of this, which is essential
information for those who are to review the change.
Understood, I'm adding the original description here and I'll add to the
next patch update.
1. Fix for DesignWare APB THRE errata:
In brief, this is a non-standard 16550 in that the THRE interrupt
will not re-assert itself simply by disabling and re-enabling the
THRI bit in the IER, it is only re-enabled if a character is actually
sent out.
It appears that the 8250-uart-backup-timer.patch in the mm tree also
fixes it so we have dropped our initial workaround.
This patch now needs to be applied on top of that mm patch.
2. Fix for Busy Detect on LCR write:
The DesignWare APB UART has a feature which causes a new Busy Detect
interrupt to be generated if it's busy when the LCR is written. This
fix saves the value of the LCR and rewrites it after clearing the
interrupt.
3. Workaround for interrupt/data concurrency issue:
The SoC needs to ensure that writes that can cause interrupts to be
cleared reach the UART before returning from the ISR. This fix reads
a non-destructive register on the UART so the read transaction
completion ensures the previously queued write transaction has
also completed.
+ case UPIO_DWAPB:
+ /* Save the LCR value so it can be re-written when a
+ * Busy Detect interrupt occurs. */
+ if (save_offset == UART_LCR)
+ up-lcr = value;
+ writeb(value, up-port.membase + offset);
+ /* Read the IER to ensure any interrupt is cleared before
+ * returning from ISR. */
+ if ((save_offset == UART_TX || save_offset == UART_IER)
in_irq())
The in_irq() is a worry. If the serial driver is used as the system
console, then it can be called from _any_ interrupt handler. eg a printk()
in the sata code.
What happens then?
The in_irq() is there to improve performance. The logic being that
writing to registers outside the interrupt context will not require
the fix for issue 3.
There should be no issues if called from other interrupt context
as the read is non-destructive. I can remove the call to in_irq() if
you prefer.
@@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt(
handled = 1;
end = NULL;
+ } else if (up-port.iotype == UPIO_DWAPB
+ (iir UART_IIR_BUSY) == UART_IIR_BUSY) {
+ /* The DesignWare APB UART has an Busy Detect
(0x07)
+ * interrupt meaning an LCR write attempt
occured while the
+ * UART was busy. The interrupt must be cleared
by reading
+ * the UART status register (USR) and the LCR
re-written. */
+ unsigned int status;
+ status = *(volatile u32 *)up-port.private_data;
Are you sure this is right? The use of volatile is generally discouraged
and is a sign that something is wrong. What is the driver attempting to
read here? Should it be using readl()?
The driver is reading the UART's USR (UART Status Register) which is
a non-standard register at a non-fixed offset, hence the need for
private_data. This was discussed in detail in the patch thread and the
goal was to avoid using platform specific #ifdefs as part of the fix
The register is accessed in kseg1 (unmapped on the mips architecture) so
readl is not needed. The register definitions in this space are all marked
volatile but since it's now accessed through private_data, the read had
to be made explicitly volatile.
Also, the newly-added private_data field is not being initialised to
anything anywhere in this patch.
private_data is initialized in the platform specific initialization code
which will be submitted to the l-m.o That patch contains only code which
lives in arch/mips and include/asm-mips so I was not
Re: 2.6.20 new perfmon code base + libpfm + pfmon
On Tue, 13 Feb 2007 10:48:39 -0800 Stephane Eranian [EMAIL PROTECTED] wrote: I have released another version of the perfmon new code base package. Can we have a bug push to get this merged up 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: 2.6.20 new perfmon code base + libpfm + pfmon
Andrew Morton [EMAIL PROTECTED] writes: On Tue, 13 Feb 2007 10:48:39 -0800 Stephane Eranian [EMAIL PROTECTED] wrote: I have released another version of the perfmon new code base package. Can we have a bug push to get this merged up please? Yes, there certainly seems to be user interest in this. I've been merging the x86 specific infrastructure Stephane sent. So hopefully the basics are there already. The big open question was still the review of the syscall interface. Probably needs some determined reviewers. I did a review of some of the basic low level code some time ago; there were some issues but I believe they are probably all resolved by now (but I haven't verified that recently) -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: libata FUA revisited
Hello, Robert. Robert Hancock wrote: [--snip--] On the NCQ side, I think it's pretty safe to assume that all controllers will handle it. Obviously I've verified it with sata_nv (at least that it doesn't blow up obviously), and the other two NCQ drivers we have, ahci and sata_sil24 just feed raw FIS data into the controller so there should be no issue with not supporting it. FWIW, ICH6/7/8 ahci's clear PMP field when transmitting FIS. The reason why I'm hesitant is because there is no way to tell whether the FUA bit got honored or ignored. With extra opcode, it's okay because barrier explicitly fails but if NCQ FUA is not supported, it will succeed silently as normal write. Everything will be okay generally but the barrier is done incorrectly and on a really bad day it will lead to journal corruption. So, actually, I was thinking about *always* using the non-NCQ FUA opcode. As currently implemented, FUA request is always issued by itself, so NCQ doesn't make any difference there. So, I think it would be better to turn on FUA on driver-by-driver basis whether the controller supports NCQ or not. Well, I might be being too paranoid but silent FUA failure would be really hard to diagnose if that ever happens (and I'm fairly certain that it will on some firmwares). -- 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: pcim_enable_device BUGs for libata devices in 2.6.20-git6
Hello, Pavel. Pavel Machek wrote: 1. Don't restore power state and re-enable PCI device on resume from freeze just as we don't do the opposite when freezing. 2. Unconditionally disable and power down PCI device on suspend whether it's freeze or not. #2 would be simpler but I'm a bit worried about it. There might be controllers which choke after such sequence (save state, disable, power down, no actual power removal, power on, restore state, re-enable). I'd just go for #2. I think I've been seeing too many weird ATA controller issues to be bold about this. I'll chicken out and go for #1. :-) #1 can be easily done by taking a look at the current device power state (gendev-power.power_state). The problem is that no one in suspend/resume path seems to be setting that variable except for runtime No, that variable is probably going to go away. If you want to remember that you are resuming from freeze, just store that info in private data structure. I see. Thanks. -- 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: Sata_via problems in a Vintage2-AE1
A Dimarts 13 Febrer 2007 12:20, Jean Delvare va escriure: Hi Leopold, Le Lundi 12 Février 2007 17:23, Leopold Palomo-Avellaneda a écrit : A Dilluns 12 Febrer 2007 10:11, Jean Delvare va escriure: Did you report the problem to Asus? They should fix it. Maybe this new BIOS actually fixes some other problems you have. no. It's on the todo list. However I'm a bit afraid because I'm not using the official system so probably they will say that we do not support ... That's indeed probable, but if enough people report the same problems, they might still end up looking into it. ok, I will try. Well in http://via8251.la-evento.com/index.html off topic please tell me that I'm not violating any rule about the linux-kernel list putting this link :-S /off topic claims that the VT8251 are supported in 2.6.20. As always you nned to see the official place :-( That's quite a bold claim considering that the VT8251 includes many different functions (PATA, SATA, USB, SMBus...) and can be configured differently on different motherboards. Maybe most functions are supposedly supported as of 2.6.20, but it doesn't mean everything works for everyone, as you are experiencing yourself. sure, you're right. *If* the VT8251 needs the VIA IRQ quirk, then the attached patch may help. Leopold, can you give it a try? Well, making your patch to the vanilla 2.6.20 the result is the same. The box doesn't boot. Always the same problem If it's not a VIA IRQ problem, then there's nothing more I can do, sorry. Someone else will have to look into the problem. Out of curiosity, with my patch applied, did you see any VIA VLink IRQ fixup messages on the console? No :-( Regards, Leo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sata_via problems in a Vintage2-AE1
Le Mardi 13 Février 2007 17:11, Leopold Palomo-Avellaneda a écrit : A Dimarts 13 Febrer 2007 12:20, Jean Delvare va escriure: (...) *If* the VT8251 needs the VIA IRQ quirk, then the attached patch may help. Leopold, can you give it a try? Well, making your patch to the vanilla 2.6.20 the result is the same. The box doesn't boot. Always the same problem If it's not a VIA IRQ problem, then there's nothing more I can do, sorry. Someone else will have to look into the problem. Out of curiosity, with my patch applied, did you see any VIA VLink IRQ fixup messages on the console? No :-( OK, so maybe the VT8251 actually no longer needs the quirk. Thanks for testing and reporting. -- Jean Delvare Suse L3 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Re: [autofs] Bad race condition in the new autofs protocol somewhere
On Tue, 2007-02-13 at 09:07 -0500, Chuck Ebbert wrote: Olivier Galibert wrote: On Tue, Feb 13, 2007 at 09:52:39AM +0900, Ian Kent wrote: Indeed. Which kernel can you use? I believe that 2200 had another problem so can you use an fc5 kernel later than that? I've ported your patch to 2257 (nothing special, only moved lines), and it seems to work beautifully. I'm enlarging the testing. If you get the patches into -stable they will end up in Fedora kernels automatically. 2288 (based on 2.6.19) is in testing now... This has just been done. I'll be submitting the new patches soon, if all goes well. Ian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Re: [autofs] Bad race condition in the new autofs protocol somewhere
On Tue, 2007-02-13 at 16:54 +0100, Olivier Galibert wrote: On Tue, Feb 13, 2007 at 09:07:27AM -0500, Chuck Ebbert wrote: Olivier Galibert wrote: On Tue, Feb 13, 2007 at 09:52:39AM +0900, Ian Kent wrote: Indeed. Which kernel can you use? I believe that 2200 had another problem so can you use an fc5 kernel later than that? I've ported your patch to 2257 (nothing special, only moved lines), and it seems to work beautifully. I'm enlarging the testing. If you get the patches into -stable they will end up in Fedora kernels automatically. 2288 (based on 2.6.19) is in testing now... Don't they require autofs5 to be of any use though? That's not going to be in fc until it's out of beta I guess. Not really? [EMAIL PROTECTED] ~]$ cat /etc/redhat-release Fedora Core release 6 (Zod) [EMAIL PROTECTED] ~]$ rpm -q autofs autofs-5.0.1-0.rc3.16 [EMAIL PROTECTED] ~]$ rpm -q --changelog autofs| head -10 * Sun Feb 11 2007 Ian Kent [EMAIL PROTECTED] - 5.0.1-0.rc3.16 - update the task done race patch to fix a deadlock. * Wed Feb 07 2007 Ian Kent [EMAIL PROTECTED] - 5.0.1-0.rc3.14 - fix race when setting task done (bz 227268). * Tue Jan 30 2007 Ian Kent [EMAIL PROTECTED] - 5.0.1-0.rc3.12 - make double quote handing consistent (at least as much as we can). - fix handling of trailing white space in wildcard lookup (forward port bz 199720). - check fqdn of each interface when matching export access list (bz 213700). [EMAIL PROTECTED] ~]$ The Rawhide or FC-6 srpm should build fine on FC5. Ian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Re: [autofs] Bad race condition in the new autofs protocol somewhere
On Wed, Feb 14, 2007 at 02:35:15AM +0900, Ian Kent wrote: On Tue, 2007-02-13 at 16:54 +0100, Olivier Galibert wrote: Don't they require autofs5 to be of any use though? That's not going to be in fc until it's out of beta I guess. Not really? [EMAIL PROTECTED] ~]$ cat /etc/redhat-release Fedora Core release 6 (Zod) [EMAIL PROTECTED] ~]$ rpm -q autofs autofs-5.0.1-0.rc3.16 Oh cool, my guess was wrong. The Rawhide or FC-6 srpm should build fine on FC5. The .spec that comes with the tgz works without a hitch too. I guess fc6 is going to have a *really* working automounter RSN then. OG. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Getting the nfs_fh of a specific file/dir from the kernel
On Sun, 2007-02-11 at 10:06 +0200, Menny Hamburger wrote: We implement our own nfsd in user space - so the kernel nfsd (as well as the lockd) are disabled. We need the handle in order to associate a kernel file handle with our own file id. Filehandles are not part of any API that is exported to userland. There are many reasons why that would be a bad idea. Cheers Trond M. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J. Bruce Fields Sent: Thursday, February 08, 2007 10:12 PM To: Menny Hamburger Cc: linux-kernel@vger.kernel.org Subject: Re: Getting the nfs_fh of a specific file/dir from the kernel On Thu, Feb 08, 2007 at 06:38:48PM +0200, Menny Hamburger wrote: I have a piece of code in my 2.6 kernel that associates an ioctl file_operation to nfs in file.c and dir.c. This ioctl sends the nfs_fh to a userland application. Doesn't /proc/fs/nfsd/filehandle do what you want already? See nfs-util/utils/mountd/cache.c:cache_get_filehandle(), or, for the kernel side, linux/fs/nfsd/nfsctl.c:write_filehandle(). (Just out of curiosity--why are you doing this?) --b. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
