Re: [PATCH 0/3] x86_64 EFI runtime service support
On Sun, 2007-08-19 at 16:25 -0600, Eric W. Biederman wrote: > "Huang, Ying" <[EMAIL PROTECTED]> writes: > >> > +#define EFI_LOADER_SIG ((unsigned char *)(PARAM+0x1c0)) > >> > +#define EFI_MEMDESC_SIZE (*((unsigned int *) (PARAM+0x1c4))) > >> > +#define EFI_MEMDESC_VERSION (*((unsigned int *) (PARAM+0x1c8))) > >> > +#define EFI_MEMMAP_SIZE (*((unsigned int *) (PARAM+0x1cc))) > >> > +#define EFI_MEMMAP (*((unsigned long *)(PARAM+0x1d0))) > >> > +#define EFI_SYSTAB (*((unsigned long *)(PARAM+0x1d8))) > >> > #define MOUNT_ROOT_RDONLY (*(unsigned short *) (PARAM+0x1F2)) > Be very very very careful how you talk about this. > > I have seen machines in the wild a 64bit processor and a 32bit EFI. > So this is not a linux architecture issue, or a cpu architecture > issue. This is an EFI architecture issue. > > This is an issue of do you have a 32bit or a 64bit EFI implementation > on your machine. Which is very different. > > We should be able to boot a 32bit kernel with a 64bit EFI. > We should be able to boot a 64bit kernel with a 32bit EFI. > > Maybe our response is to ignore the information from elilo so > we don't attempt EFI runtime calls but the boot information should > be unambiguous. > > So we need to be able to look at the data and answer these questions. > - Is EFI present? > - Is EFI 32bit? > - Is EFI 64bit? Yes, it is necessary to distinguish these situations. I think the EFI_LOADER_SIG defined above can be used for that. For example the following signature can be defined: 32-bit EFI EL32 64-bit EFI EL64 All other values will be treated as no EFI present. If struct setup_data proposed by H. Peter Anvin is used for EFI information passed from bootloader, two "type" can be defined for 32-bit EFI and 64-bit EFI, such as SETUP_DATA_TYPE_EFI_32 and SETUP_DATA_TYPE_EFI64. If either type is not presented in "linked list of struct setup_data", it is considered that EFI is not present. Best Regards, Huang Ying - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Non atomic unaligned writes
> > > Are misaligned/cross-cache-line updates atomic? > > > > In theory yes, in practice there can be errata of course. Afaik the theory is "Platform specific; most x86 will be in practice"; it's up to the system vendor and chipset vendor. The practice is "mixed ball, slow as h*ck anyway, just never ever do it" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptrdiff_t is not uintptr_t, damnit
On Sunday 19 August 2007, Al Viro wrote: > On Sun, Aug 19, 2007 at 08:26:24PM -0700, David Brownell wrote: > > > ISTR the warning was the other way around: about "cast from integer > > to pointer of a different size". The __u64 came from userspace and > > the kernel pointer was only 32 bits. Not really truncation, but GCC > > could not know that directly ... ergo the extra non-pointer cast. > > And? Cast to integer type with the size equal to that of pointer. > unsigned long is just that on all supported targets. Some tool kept warning about that. Presumably then-current sparse. I've certainly heard the conventional "unsigned long fits pointers" wisdom, but tools disagreed. (Does ANSI C guarantee that? I'd think not, or uintptr_t would not be needed.) And ptrdiff_t was the closest relevant data type that passed both gcc and sparse, since uintptr_t didn't previously exist everywhere. > More interesting question is whether you want an error returned when > pointers are 32bit and value doesn't fit into that... Either access_ok() or copy_from_user() reports an error if the pointer part of that u64 (N LSBs) is bad. As a general policy, I think the other part is undefined and irrelevant to the kernel ... it's a kind of explicit padding, and padding isn't valdated. (At most it's zeroed to prevent a covert channel, but that's not relevent here.) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ensure we don't use bootconsoles after init has been released
From: Robin Getz <[EMAIL PROTECTED]>
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
This ensures that a bootconsole is unregistered if it is not replaced.
The current implementation spews garbage out the bootconsole in this case,
since the bootconsole structure is normally in the init section, and is
freed, but still used.
Signed-off-by: Robin Getz <[EMAIL PROTECTED]>
---
linux-2.6.x-old/kernel/printk.c | 15 +++
1 file changed, 15 insertions(+)
Index: linux-2.6.x-old/kernel/printk.c
===
--- linux-2.6.x-old/kernel/printk.c (revision 3583)
+++ linux-2.6.x-old/kernel/printk.c (working copy)
@@ -1104,6 +1104,21 @@
}
EXPORT_SYMBOL(unregister_console);
+static int __init disable_boot_consoles(void)
+{
+ struct console *con;
+
+ for (con = console_drivers; con; con = con->next) {
+ if (con->flags & CON_BOOT) {
+ printk(KERN_INFO "Turn off boot console %s%d\n",
+ con->name, con->index);
+ unregister_console(con);
+ }
+ }
+ return 0;
+}
+late_initcall(disable_boot_consoles);
+
/**
* tty_write_message - write a message to a certain tty, not just the console.
* @tty: the destination tty_struct
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)
On Thu, 2007-08-16 at 05:29 +0200, Nick Piggin wrote: > On Wed, Aug 15, 2007 at 03:12:06PM +0200, Peter Zijlstra wrote: > > On Wed, 2007-08-15 at 14:22 +0200, Nick Piggin wrote: > > > On Tue, Aug 14, 2007 at 07:21:03AM -0700, Christoph Lameter wrote: > > > > The following patchset implements recursive reclaim. Recursive reclaim > > > > is necessary if we run out of memory in the writeout patch from reclaim. > > > > > > > > This is f.e. important for stacked filesystems or anything that does > > > > complicated processing in the writeout path. > > > > > > Filesystems (most of them) that require compilcated allocations at > > > writeout time suck. That said, especially with network ones, it > > > seems like making them preallocate or reserve required memory isn't > > > progressing very smoothly. > > > > Mainly because we seem to go in circles :-( > > > > > I think these patchsets are definitely > > > worth considering as an alternative. > > > > Honestly, I don't. They very much do not solve the problem, they just > > displace it. > > Well perhaps it doesn't work for networked swap, because dirty accounting > doesn't work the same way with anonymous memory... but for _filesystems_, > right? > > I mean, it intuitively seems like a good idea to terminate the recursive > allocation problem with an attempt to reclaim clean pages rather than > immediately let them have-at our memory reserve that is used for other > things as well. I'm concerned about the worst case scenarios, and those don't change. The proposed changes can be seen as an optimisation of various things, but they do not change the fundamental issues. > Any and all writepage() via reclaim is allowed to eat > into all of memory (I hate that writepage() ever has to use any memory, > and have prototyped how to fix that for simple block based filesystems > in fsblock, but others will require it). > > > > Christoph's suggestion to set min_free_kbytes to 20% is ridiculous - nor > > does it solve all deadlocks :-( > > Well of course it doesn't, but it is a pragmatic way to reduce some > memory depletion cases. I don't see too much harm in it (although I didn't > see the 20% suggestion?) Sure, and on that note I don't object to them, they might be quite useful at times. It just doesn't help the worst case scenarios. > > > No substantial comments though. > > > > Please do ponder the problem and its proposed solutions, because I'm > > going crazy here. > > Well yeah I think you simply have to reserve a minimum amount of memory in > order to reclaim a page, and I don't see any other way to do it other than > what you describe to be _technically_ deadlock free. Right, and I guess I have to go at it again, this time ensuring not to touch the fast-path nor sacrificing anything NUMA for simplicity in the reclaim path. (I think its a good thing to be technically deadlock free - and if your work on the fault path rewrite and buffered write rework shows anything it is that you seem to agree with this) > But firstly, you don't _want_ to start dropping packets when you hit a tough > patch in reclaim -- even if you are strictly deadlock free. And secondly, > I think recursive reclaim could reduce the deadlocks in practice which is > not a bad thing as your patches aren't merged. Non of the people who have actually used these patches seem to object to the dropping packets thing. Nor do I see that as a real problem, networks are assumed lossy - also if you really need that traffic for a RT app that also runs on the machine you need networked swap on (odd combination but hey, it should be possible) then I can make that work as well with a little bit more effort. Also, I'm a very reluctant to accept a known deadlock, esp. since the changes needed are not _that_ complex. > How are your deadlock patches going anyway? AFAIK they are mostly a network > issue and I haven't been keeping up with them for a while. They really do rely on some VM interaction too, network does not have enough information to break out of the deadlock on its own. As for how its going, it seems to work quite reliably in my test setup - that is, I can shut down the NFS server, swamp the client in network traffic for hours (yes it will quickly stop userspace) and then restart the NFS server and the client will reconnect and resume operation. There are also a few people running various versions of my patches in production environments. One university is running it on a 500-node cluster and another on ~500 thin-clients and there is someone using it in a blade product. > Do you really need > networked swap and actually encounter the deadlock, or is it just a question > of > wanting to fix the bugs? If the former, what for, may I ask? Yes (we - not I personally) want networked swap. There is quite the demand for it in the marked. It allows clusters and blades to be build without any storage - which not only saves on the initial cost of a hard drive [1] but also on maintenance
Re: [2.6.23-rc3 possible regression] 8250 claims nonexisting device blocking IO port
On Saturday 18 August 2007 01:07:55 am Andrey Borzenkov wrote: > This is related to thread "2.6.22-rc: regression: no irda0 interface (2.6.21 > was OK), smsc does not find chip" but it is already way too overloaded. > > In 2.6.23 smsc-ircc2 fails to initialize IrDA controller. Apparently because > it by default is using the same IO port as ttyS3 and this is now claimed by > 8250. 8250 should have claimed ttyS3 in 2.6.21 and earlier. So from the 8250 point of view, 2.6.21 and 2.6.23 should behave the same. >From the smsc-ircc2 point of view, 2.6.21 and 2.6.23 should work the same except for the additional quirk_smc_enable(). If 2.6.23 is worse than 2.6.21, please try removing the body of quirk_smc_enable() and see whether that makes 2.6.23 as good as 2.6.21. For smsc-ircc2, 2.6.23 is definitely a regression from 2.6.22, because 8250 stayed out of the way in 2.6.22. But we had to revert 8250 back to the 2.6.21 behavior because the change swapped ttyS0 and ttyS1 on some machines, so we just have to live with that 8250/smsc-ircc2 conflict for the time being. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/12] Blackfin arch: Add label to call new GPIO API
On Sunday 19 August 2007, Robin Getz wrote: > On Sun 19 Aug 2007 17:54, David Brownell pondered: > > On Saturday 18 August 2007, Robin Getz wrote: > > > > > I don't see how early/late makes the problem easier/worse to debug. No > > > matter when you do it - the driver refuses to install (or at least > > > should). > > > > If you arrange to *reliably* detect the pinmux/setup problems by > > the time the system starts ""init" (early), that means one large > > class of hard-to-sort problems never needs runtime troubleshooting. > > Sure it does - it just needs to do it in the bootloader, not the kernel. Kernel arch/.../board-X.c code is the place to "reliably" handle that. Bootloader is out-of-scope here; it's a separate codebase. > You > haven't eliminated the problem - or made it any easier to debug - it is just > moved somewhere else. Moved it out of runtime, to a small window before "init" sections get discarded and "init" is invoked. So if it ever *could* show up, it'll show up then ... every time the system boots, a message will appear. Easy to notice while the bug is fresh, just from a developer's routine scan of bootup messages. The alternative lets the problem appear later, almost randomly, based on whether the conflicting drivers happen to be loaded at the same time. Which *IS* harder to debug. I still remember the time a board had to be respun because the hardware guys goofed on use of one signal. Two different drivers both needed it ... but until later in system integration, they were never tested together, so that conflict never showed up. (It was a non-obvious thing, for on-chip signal routing not the on-board type verified by module tests in hardware QA and design review.) Doing that setup "early" would have prevented that problem, and avoided one annoying schedule slip and hardware respin. > Again - this is not bad. We decided/are attempting to > do it in the kernel. Normally what we find is there are more kernel people on > a project than bootloader (whether this makes this easier - or not - is still > TDB :) I don't know why you're reading what I write as any kind of preference for doing that in the bootloader. It's nothing more than an *acknowledgement* that some vendors work that way, so Linux is better off with an approach which won't be broken when they do. (That is, always having finished pin mux setup before drivers get probed.) When Linux does that setup in arch//board-X.c files, mostly before drivers come into play, it's normal for driver code to ignore it ... which means the bootloader might also have done it, for those kinds of product. Usually I'd expect one person on the bootloader, plus ideally understudies. Not a full time job; that person might mostly do kernel development, hardware test/bringup, or something else depending on how the product team was structured. > > Remember that I didn't argue in favor of putting that code into > > boot loaders ... I just pointed out that some product lines work > > that way, so Linux needs to cope with that strategy. (One of the > > many examples involves OpenFirmware device tables.) > > > > But regardless: I can't buy any argument that it's better to put > > lots of board-specific code into drivers. > > I don't think we are putting board specific code in drivers (or if there is - > it should get removed). > > I did a quick look, and the only place this has happened is in some of our > drivers that have not made it to main line yet Good!! If it's not in drivers, I suspect you'll agree that it will probably all land in that arch//board-X.c setup code. > I agree - which is why don't do this either. Board specific info does not go > into drivers. I think this is something that Michael, Bryan and others > working on the Blackfin arch & drivers will agree to 100%. > > What we do is try to make the driver agnostic to the hardware as much as > possible, Good ... > where hardware specifics (chip selects, IRQ, GPIO, etc) are managed > in Kconfig. ... IMO less good, but that's all your worry. I suspect that by the time you handle a few dozen boards, you'll find Kconfig is not well suited to this. (Because of the way it prevents one kernel from handling multiple boards, unless they really aren't very different.) > > Doing that in Kconfig is atypical ... it may well be a bit easier to > > pick up at the beginning of a developer's learning curve, but I think > > it doesn't scale very well as multi-board product lines evolve. > > We have lots of end users (obviously not as many as ARM or PPC yet), and they > have not been complaining, in fact some say that this is easier to deploy. These are people already familiar with ARM or PPC embedded Linux? I guess one question is "easier than what". Kconfig doesn't try to help with the "give me a minimal .config for hardware" problem; say, by reading "lspci -n" output or some other system description. It expects people to know their way
Re: [PATCH] ptrdiff_t is not uintptr_t, damnit
On Sun, Aug 19, 2007 at 08:26:24PM -0700, David Brownell wrote: > ISTR the warning was the other way around: about "cast from integer > to pointer of a different size". The __u64 came from userspace and > the kernel pointer was only 32 bits. Not really truncation, but GCC > could not know that directly ... ergo the extra non-pointer cast. And? Cast to integer type with the size equal to that of pointer. unsigned long is just that on all supported targets. More interesting question is whether you want an error returned when pointers are 32bit and value doesn't fit into that... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ensure we don't use bootconsoles after init has been released
On Sun, Aug 19, 2007 at 11:11:47PM -0400, Mike Frysinger wrote:
> On 8/19/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> > +static int __init disable_boot_consoles(void)
> > +{
> > + struct console *con;
> > +
> > + for (con = console_drivers; con; con = con->next) {
> > + if (con->flags & CON_BOOT) {
> > + printk(KERN_INFO "Turn off boot console %s%d\n",
> > + con->name, con->index);
> > + unregister_console(con);
> > + }
> > + }
> > +}
>
> erp, no 'return 0;' ... that'll earn you a warning at build time and
> maybe random failures depending on the arch ...
Or better yet, complain if unregister_console() fails, and pass the
failure down.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ptrdiff_t is not uintptr_t, damnit
On Sunday 19 August 2007, Satyam Sharma wrote: > > > On a 32-bit arch "unsigned long" is 32-bit and pointers are 32-bit. > > > > > > On a 64-bit archi "unsigned long" is 64-bit and pointers are 64-bit. > > > > So with 32 bit userspace "unsigned long long" is the type to use > > when talking to a 64-bit kernel; and with pure 64-bit code, it's > > enough to write "unsigned long". > > > > I'm fairly sure that's the root cause of the pain I recall here; > > but I'd have to run experiments again to verify that. > > I suspect the root cause of the pain was that you used "int" or "long" > to talk between kernel and userspace in the first place. You shouldn't, > we have __u32 / __u64 / etc for that. Nope; the relevant code was always with "__u64". The issue was warning when turning that into a __user pointer. > The reason I ask is that gcc will also complain (understandably so) with > "warning: cast from pointer to integer of different size" i.e. even if > it's a conversion from smaller size to greater size, and not really a > case of truncation. ISTR the warning was the other way around: about "cast from integer to pointer of a different size". The __u64 came from userspace and the kernel pointer was only 32 bits. Not really truncation, but GCC could not know that directly ... ergo the extra non-pointer cast. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/3] x86_64 EFI runtime service support
On Fri, 2007-08-17 at 09:11 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >>
> >> Has the zero page documentation and version numbering project
> >> made any progress? I think we cannot merge this without at least
> >> the version number
> >
>
> More than that. You need to be able to boot a 32-bit kernel on a 64-bit
> system, so anything that breaks that is a nonstarter. Of course, if EFI
> itself inherently breaks that, then, well, that's just another reason to
> avoid EFI like the plague, but I can't think that even EFI is that broken.
The 32-bit EFI runtime service and 64-bit EFI runtime service is not
binary compatible. So, it is difficult for 32-bit Linux kernel to
support 64-bit EFI runtime service on x86_64 machine with 64-bit EFI
firmware. The 32-bit Linux kernel must switch between 32-bit mode and
64-bit mode before and after calling EFI runtime service. It is a little
complex too for 64-bit Linux kernel to support 32-bit EFI runtime
service on x86_64 machine with 32-bit EFI firmware.
But EFI runtime service is not essential for Linux booting, the Linux
kernel can boot (even operate) normally without EFI runtime service
support.
Summary, on x86_64 machine:
firmwareLinux kernelbootruntime service
EFI-64 32-bit Yes No
EFI-64 64-bit Yes Yes
EFI-32 32-bit Yes Yes
EFI-32 64-bit Yes No
So, Why we add support for EFI runtime service? I think there are at
least following reasons:
1. Some legacy hardware (such as CMOS clock) may be replaced silently in
the future when most legacy BIOS is replaced by EFI firmware. With EFI
runtime service, the new hardware can be supported immediately.
2. EFI variable service can be used to store some information cross
rebooting, such as the OOPS information can be saved into flash through
EFI variable service as proposed by Andi Kleen.
3. EFI reboot service can be used to support warm reboot.
The problem remains is that should we support 32-bit EFI runtime service
in 64-bit Linux kernel, or should we support 64-bit EFI runtime service
in 32-bit Linux kernel? I think we can add these supports later if
needed.
> > OK, I will work on the zero page documentation and version numbering
> > project.
>
> There already is documentation (Documentation/i386/zero-page.txt); as
> far as version numbering, that means sticking in a field with a number,
> and adding a magic number (since there isn't anything that guarantees
> that fields are otherwise zero.)
>
> Anything that conforms to the updated standard should guarantee
> undefined fields are zero.
Yes. This is necessary for extensibility.
> However, we also have an immediate need to define how to grow past 4K,
> and if we're going to have a major revision in mechanism I would like to
> see that happen now.
>
> I propose that, in addition to the aforementioned version number and
> magic fields, we add a pointer, which should be the last pointer added
> that doesn't point into I/O space or reserved memory (i.e. memory that
> is off limit anyway for the operating system.)
>
> This pointer should point to a linked list of suggested form:
>
> struct setup_data {
> u64 next;
> u32 type;
> u32 len;
> u8 data[];
> };
>
> This can thus encapsulate large objects as necessary, and the early
> kernel entry can linearize them if it needs to move them out of the way.
> Better yet, this information can be made available to sysfs for
> debuggability, and/or use by kexec.
This is a good interface. It is extensible. In the future, when we need
more boot information, we can just define a new type.
And with this interface, it is not necessary to export the "zero page
protocol" as a external boot protocol (ABI) of the kernel. So, I
proposed that:
1. Keep "zero page" as a internal interface, even make that explicitly
in the document.
2. Increase the version number of standard boot protocol.
3. Append this pointer (pointed to linked list of struct setup_data) to
standard boot protocol.
4. Define a set of types of struct setup_data, each for one zero_page
field.
5. The kernel 16-bit setup code generates "linked list of struct
setup_data" instead of generating "zero page". On machine with BIOS
other than legacy BIOS (such as EFI, LinuxBIOS, etc), the bootloader
(incuding kexec) generates the "linked list of struct setup_data"
instead of generating "zero page" too.
6. In kernel early booting code, the "zero page" is generated from the
"linked list of struct setup_data".
7. In the future, most booting code uses "linked list of struct
setup_data" directly instead of "zero page".
So, we need not define a new boot protocol, just extend the standard
boot protocol. The version number and magic need not to be added to
"zero page". But, at the same time,
Re: [PATCH 0/4] process memory footprint info in proc//[s|p]maps v2
On 8/19/07, Fengguang Wu <[EMAIL PROTECTED]> wrote: > Inspired by Matt Mackall's pagemap patches and ideas, I worked up these > textual interfaces that achieve the same goals. The patches run OK > under different sized reads. [...] > 2b7d6e8f3000-2b7d6ea4 r-xp 08:01 1564031 > /lib/libc-2.6.so > 0 2 YRAU___ 81 > 2 1 YRAU___ 80 > 3 1 YRAU___ 81 > 4 1 YRAU___ 72 > 5 1 YRAU___ 77 > 6 1 YRAU___ 79 > 7 1 YRAU___ 73 > 8 1 YRAU___ 79 > 9 1 YRAU___ 78 > a 1 YRAU___ 77 > b 1 YRAU___ 72 > c 1 YRAU___ 75 > d 1 YRAU___ 81 > e 1 YRAU___ 72 > f 1 YRAU___ 78 > 10 1 YRAU___ 81 > 11 1 YRAU___ 78 > 12 1 YRAU___ 80 > 13 1 YRAU___ 78 > 14 2 YRAU___ 81 > 16 1 YRAU___ 49 > 17 6 YRAU___ 41 > 1d 1 YRAU___ 80 > 2a 1 YRAU___ 44 > 2b 1 YRAU___ 69 > 2c 1 YRAU___ 28 > 31 1 YRAU___ 79 > 32 1 YRAU___ 49 > 33 1 YRAU___ 73 > 34 1 YRAU___ 57 > 35 1 YRAU___ 67 > 42 1 YRAU___ 77 > 43 3 YRAU___ 78 > 46 1 YRAU___ 77 > 47 1 YRAU___ 70 > 48 1 YRAU___ 15 > 4d 1 YRAU___ 78 > 5f 1 YRAU___ 78 > 60 1 YRAU___ 75 > 61 1 YRAU___ 72 > 62 1 YRAU___ 67 > 63 1 YRAU___ 59 > 68 1 YRAU___ 63 > 69 1 YRAU___ 61 > 6a 1 YRAU___ 63 > 6b 1 YRAU___ 75 > 6c 1 YRAU___ 76 > 6d 1 YRAU___ 81 > 6e 1 YRAU___ 77 > 6f 1 YRAU___ 79 > 70 1 YRAU___ 44 > 71 1 YRAU___ 79 > 72 1 YRAU___ 78 > 73 1 YRAU___ 79 > 74 1 YRAU___ 46 > 75 1 YRAU___ 78 > 76 1 YRAU___ 60 > 78 1 YRAU___ 79 > 79 1 YRAU___ 81 > 7a 1 YRAU___ 80 > 7e 1 YRAU___ 41 > 8a 1 YRAU___ 36 > 8b 1 YRAU___ 72 > 8c 1 YRAU___ 28 > 8d 1 YRAU___ 21 > 91 2 YRAU___ 19 > 99 1 YRAU___ 62 > 9a 1 YRAU___ 76 > 9b 1 YRAU___ 72 > c4 1 YRAU___ 80 > c5 1 YRAU___ 82 > c6 1 YRAU___ 81 > cb 1 YRAU___ 42 > cc 1 YRAU___ 79 > cd 1 YRAU___ 26 > cf 1 YRAU___ 12 > d0 1 YRAU___ 77 > d1 1 YRAU___ 38 > d2 1 YRAU___ 45 > d3 1 YRAU___ 66 > d4 1 YRAU___ 71 > e0 1 YRAU___ 52 > 106 1 YRAU___ 33 > 107 1 YRAU___ 14 > 108 1 YRAU___ 63 > 109 1 YRAU___ 57 > 10b 1 YRAU___ 70 > 10c 1 YRAU___ 63 > 118 1 YRAU___ 65 > 119 1 YRAU___ 78 > 11a 1 YRAU___ 69 > 11b 1 YRAU___ 68 > 11e 2 YRAU___ 62 > 120 1 YRAU___ 74 > 121 1 YRAU___ 42 > 125 1 YRAU___ 17 Eh, I'd think that pivoting the data set would be a much more natural (& therefore shorter) representation. YRAU___ 0,2:81 2:80 3:81 4:72 5:77 6:79 7:73 8:79 9:78 ...versus... > 0 2 YRAU___ 81 > 2 1 YRAU___ 80 > 3 1 YRAU___ 81 > 4 1 YRAU___ 72 > 5 1 YRAU___ 77 > 6 1 YRAU___ 79 > 7 1 YRAU___ 73 > 8 1 YRAU___ 79 > 9 1 YRAU___ 78 So, flags followed by a list of offset[,length]:usage. If the flags change, start a new line. If you get a line that's too long, start a new line. No? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ensure we don't use bootconsoles after init has been released
On 8/19/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> +static int __init disable_boot_consoles(void)
> +{
> + struct console *con;
> +
> + for (con = console_drivers; con; con = con->next) {
> + if (con->flags & CON_BOOT) {
> + printk(KERN_INFO "Turn off boot console %s%d\n",
> + con->name, con->index);
> + unregister_console(con);
> + }
> + }
> +}
erp, no 'return 0;' ... that'll earn you a warning at build time and
maybe random failures depending on the arch ...
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptrdiff_t is not uintptr_t, damnit
On Sun, 19 Aug 2007, David Brownell wrote: > On Sunday 19 August 2007, Anton Altaparmakov wrote: > > > > > > ISTR we don't *have* a uintptr_t on all architectures, or that would > > > be the appropriate thing to use in these 32/64 bit ABI scenarios. > > > > > > > > >> Use unsigned long or uintptr_t instead. > > > > > > I suspect you mean "unsigned long long"... > > > > No he doesn't.  "unsigned long" is guaranteed to be large enough to  > > hold a pointer (at least on Linux anyway). Yup, sizeof(long) >= sizeof(void *) should always be true in Linux C. I bet a lot of code out there depends on this. BTW, just curious to know, but which (if any) are the platforms that have sizeof(long) > sizeof(void *)? [i.e. greater-than but not equal?] The reason I ask is that gcc will also complain (understandably so) with "warning: cast from pointer to integer of different size" i.e. even if it's a conversion from smaller size to greater size, and not really a case of truncation. Therefore, I wonder if the stricter assertion: sizeof(long) == sizeof(void *) holds true for Linux C, actually. > And yet when I used that, I got compiler warnings on some systems. > > ISTR that was the first solution I tried, but GCC really wanted to > issue warnings. Either about casting 64-bit to pointer, or about > casting it to "unsigned long", either way lost precision. Hmm, if you could fish out those testcases ... > > On a 32-bit arch "unsigned long" is 32-bit and pointers are 32-bit. > > > > On a 64-bit archi "unsigned long" is 64-bit and pointers are 64-bit. > > So with 32 bit userspace "unsigned long long" is the type to use > when talking to a 64-bit kernel; and with pure 64-bit code, it's > enough to write "unsigned long". > > I'm fairly sure that's the root cause of the pain I recall here; > but I'd have to run experiments again to verify that. I suspect the root cause of the pain was that you used "int" or "long" to talk between kernel and userspace in the first place. You shouldn't, we have __u32 / __u64 / etc for that. Satyam
[PATCH 1/1] ensure we don't use bootconsoles after init has been released
From: Robin Getz <[EMAIL PROTECTED]>
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
This ensures that a bootconsole is unregistered if it is not replaced.
The current implementation spews garbage out the bootconsole in this case,
since the bootconsole structure is normally in the init section, and is
freed, but still used.
Signed-off-by: Robin Getz <[EMAIL PROTECTED]>
---
linux-2.6.x/kernel/printk.c | 14 ++
1 file changed, 14 insertions(+)
Index: linux-2.6.x/kernel/printk.c
===
--- linux-2.6.x/kernel/printk.c
+++ linux-2.6.x/kernel/printk.c
@@ -1104,6 +1104,20 @@
}
EXPORT_SYMBOL(unregister_console);
+static int __init disable_boot_consoles(void)
+{
+ struct console *con;
+
+ for (con = console_drivers; con; con = con->next) {
+ if (con->flags & CON_BOOT) {
+ printk(KERN_INFO "Turn off boot console %s%d\n",
+ con->name, con->index);
+ unregister_console(con);
+ }
+ }
+}
+late_initcall(disable_boot_consoles);
+
/**
* tty_write_message - write a message to a certain tty, not just the console.
* @tty: the destination tty_struct
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Should GFP_ATOMIC fail when we're below low watermark?
On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote: > Hi all. > > In current git (and for a while now), an attempt to allocate memory with > GFP_ATOMIC will fail if we're below the low watermark level. The only way to > access that memory that I can see (not that I've looked that hard) is to have > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is correct. > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about GFP_KERNEL? > > The following patch is a potential fix for GFP_ATOMIC. Sorry, no. GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT and hence can sleep and wait for reclaim so that should not be a problem (usually). GFP_ATOMIC may not access the reserves because the reserves are needed to get out of OOM deadlocks within the VM. Consider the fact that freeing memory needs memory - if there is no memory free, you cannot free memory and you're pretty much stuck. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Regression 2.6.23-rc3 fails to boot (acpi)
On 8/19/07, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote: > What machine is it? > Could you open a bug at bugzilla.kernel.org and append acpidump output > to it? > Done, see http://bugzilla.kernel.org/show_bug.cgi?id=8909 > Thanks, > Alex. > > Alex Hunsaker wrote: > > Hangs on boot with: > > ACPI: EC: GPE = 0x4, I/O: command/status = 0x66, data = 0x62 > > ACPI: Interpreter enabled > > ACPI: (supports S0 S3) > > ACPI: Using PIC for interrupt routing > > ACIP: EC: GPE = 0x4, I/O: command/status = 0x66, data = 0x62 > > > > 2.6.23-rc2 is ok > > 2.6.23-rc3 bad > > 2.6.23-rc3-latest (7c010de7506954e973abfab5c5999c5a97f7a73e) bad > > > > git-bisect narrowed it down to: > > > > 7c010de7506954e973abfab5c5999c5a97f7a73e > > ACPI: EC: Switch from boot_ec as soon as we find its desc in DSDT. > > Alexey Starikovskiy [Fri, 3 Aug 2007 21:57:53 + (17:57 -0400)] > > Some ASUS laptops fail to use boot time EC > > and need to eventually switch to one described in DSDT. > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8709 > > > > Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]> > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > > > Reverting the above commit fixes the problem. > > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: Make rtc-ds1742 driver hotplug-aware
On Sun, 19 Aug 2007 19:02:04 -0700, David Brownell <[EMAIL PROTECTED]> wrote: > This is indeed a platform driver. And v2 of this patch > doesn't resolve its "won't hotplug" problem. The simplest > way to resolve that would be switching to the more widely > used platform_device_register(). Yes, if the current in-tree users (JMR3927 and RBTX4927 board) really wanted to hotplug this driver. And I believe they won't :-) I just want to fix a potential problem in rtc-ds1742 driver for someone who want to hotplug it. That's all. --- Atsushi Nemoto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
Michael Tharp wrote: Marc Perkel wrote: The important point that you are missing here is that the Linux world is willing to live with an rm command that is broken and the Windows and DOS world isn't. This isn't about the rm command it's about programming standards. It's about that the Linux community isn't committed to getting it right. I wonder, do these sorts of people email random celebrities and tell them they suck? If not, why do they think emailing a developer mailing list about how much they hate their product, work ethics, and general way of life is more socially acceptable? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [5/12] x86_64: Make patching more robust, fix paravirt issue
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> Then back out 19d36ccdc34f5ed444f8a6af0cbfdb6790eb1177 too, which broke
> lguest booting, and this tried to fix.
That did get backed out (at least the part that broke paravirt patching)
in 602033ed5907a59ce86f709082a35be047743a86. Linus' tree should be
working fine right now with d34fda4a84c18402640a1a2342d6e6d9829e6db7
committed, and can be further refined with the patch below that's just
waiting on some further testing.
thanks,
-chris
--
Subject: [PATCH] x86: skip paravirt patching when appropriate
From: Chris Wright <[EMAIL PROTECTED]>
commit d34fda4a84c18402640a1a2342d6e6d9829e6db7 was a little overkill
in the case where a paravirt patcher chooses to leave patch site
unpatched. Instead of copying original instructions to temp buffer
then back to patch site, simply skip patching those sites altogether.
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Zach Amsden <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
arch/i386/kernel/alternative.c |4 ++--
arch/i386/kernel/paravirt.c| 10 +-
arch/i386/kernel/vmi.c |4 ++--
include/asm-i386/paravirt.h|3 +++
4 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c
index 9f4ac8b..b81d87e 100644
--- a/arch/i386/kernel/alternative.c
+++ b/arch/i386/kernel/alternative.c
@@ -366,10 +366,10 @@ void apply_paravirt(struct paravirt_patch_site *start,
unsigned int used;
BUG_ON(p->len > MAX_PATCH_LEN);
- /* prep the buffer with the original instructions */
- memcpy(insnbuf, p->instr, p->len);
used = paravirt_ops.patch(p->instrtype, p->clobbers, insnbuf,
(unsigned long)p->instr, p->len);
+ if (used == PV_NO_PATCH)
+ continue;
BUG_ON(used > p->len);
diff --git a/arch/i386/kernel/paravirt.c b/arch/i386/kernel/paravirt.c
index 739cfb2..a36ce34 100644
--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -122,7 +122,7 @@ unsigned paravirt_patch_nop(void)
unsigned paravirt_patch_ignore(unsigned len)
{
- return len;
+ return PV_NO_PATCH;
}
struct branch {
@@ -139,9 +139,9 @@ unsigned paravirt_patch_call(void *insnbuf,
unsigned long delta = (unsigned long)target - (addr+5);
if (tgt_clobbers & ~site_clobbers)
- return len; /* target would clobber too much for this site
*/
+ return PV_NO_PATCH; /* target would clobber too much for
this site */
if (len < 5)
- return len; /* call too long for patch site */
+ return PV_NO_PATCH; /* call too long for patch site */
b->opcode = 0xe8; /* call */
b->delta = delta;
@@ -157,7 +157,7 @@ unsigned paravirt_patch_jmp(const void *target, void
*insnbuf,
unsigned long delta = (unsigned long)target - (addr+5);
if (len < 5)
- return len; /* call too long for patch site */
+ return PV_NO_PATCH; /* call too long for patch site */
b->opcode = 0xe9; /* jmp */
b->delta = delta;
@@ -196,7 +196,7 @@ unsigned paravirt_patch_insns(void *insnbuf, unsigned len,
unsigned insn_len = end - start;
if (insn_len > len || start == NULL)
- insn_len = len;
+ insn_len = PV_NO_PATCH;
else
memcpy(insnbuf, start, insn_len);
diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c
index 18673e0..27ae004 100644
--- a/arch/i386/kernel/vmi.c
+++ b/arch/i386/kernel/vmi.c
@@ -118,7 +118,7 @@ static unsigned patch_internal(int call, unsigned len, void
*insnbuf,
case VMI_RELOCATION_NONE:
/* leave native code in place */
- break;
+ return PV_NO_PATCH;
default:
BUG();
@@ -153,7 +153,7 @@ static unsigned vmi_patch(u8 type, u16 clobbers, void
*insns,
default:
break;
}
- return len;
+ return PV_NO_PATCH;
}
/* CPUID has non-C semantics, and paravirt-ops API doesn't match hardware ISA
*/
diff --git a/include/asm-i386/paravirt.h b/include/asm-i386/paravirt.h
index 9fa3fa9..b26794f 100644
--- a/include/asm-i386/paravirt.h
+++ b/include/asm-i386/paravirt.h
@@ -252,6 +252,9 @@ extern struct paravirt_ops paravirt_ops;
#define paravirt_alt(insn_string) \
_paravirt_alt(insn_string, "%c[paravirt_typenum]",
"%c[paravirt_clobber]")
+enum {
+ PV_NO_PATCH = -1
+};
unsigned paravirt_patch_nop(void);
unsigned paravirt_patch_ignore(unsigned len);
unsigned paravirt_patch_call(void *insnbuf,
-
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH] rtc: Make rtc-ds1742 driver hotplug-aware
On Sunday 19 August 2007, David Brownell wrote: > On Sunday 19 August 2007, Kay Sievers wrote: > > No, I object to the concept of "platform" to disable all uevents by > > default, > > Which it certainly doesn't do. > > Since the $SUBJECT patch doesn't affect a platform driver in any case, > all those comments are well off-topic for $SUBJECT. Sorry, my bad -- I was looking at the wrong files. (Kay -- apply cluebat to *my* head, on this point.) This is indeed a platform driver. And v2 of this patch doesn't resolve its "won't hotplug" problem. The simplest way to resolve that would be switching to the more widely used platform_device_register(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: legacy platform drivers and hotplugging
On Sun, 19 Aug 2007 18:44:43 -0700, David Brownell <[EMAIL PROTECTED]> wrote: > Notice I fixed $SUBJECT to not mention rtc-ds1742, which has > never been a platform device and thus is offtopic to your > specific complaints about platform bus hotplugging. Well, rtc-ds1742 *IS* a platform driver. But it seems the discussion is not DS1742 specific at all, and I guess ds1742 is not a good example for hotplugging, so I welcome your $SUBJECT fix :-) --- Atsushi Nemoto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] rtc: Make rtc-rs5c348 driver hotplug-aware (take 2)
On Sunday 19 August 2007, Atsushi Nemoto wrote:
> The rtc-rs5c348 SPI driver name doesn't match its module name, which
> prevents it from properly hotplugging. There is only one in-tree user
> of its driver, which is fixed by this patch too.
>
> Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
ACK.
> ---
> arch/mips/tx4938/toshiba_rbtx4938/setup.c |2 +-
> drivers/rtc/rtc-rs5c348.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/tx4938/toshiba_rbtx4938/setup.c
> b/arch/mips/tx4938/toshiba_rbtx4938/setup.c
> index 57f3c70..84ebff7 100644
> --- a/arch/mips/tx4938/toshiba_rbtx4938/setup.c
> +++ b/arch/mips/tx4938/toshiba_rbtx4938/setup.c
> @@ -1115,7 +1115,7 @@ static void __init txx9_spi_init(unsigned long base,
> int irq)
> static int __init rbtx4938_spi_init(void)
> {
> struct spi_board_info srtc_info = {
> - .modalias = "rs5c348",
> + .modalias = "rtc-rs5c348",
> .max_speed_hz = 100, /* 1.0Mbps @ Vdd 2.0V */
> .bus_num = 0,
> .chip_select = 16 + SRTC_CS,
> diff --git a/drivers/rtc/rtc-rs5c348.c b/drivers/rtc/rtc-rs5c348.c
> index f50f3fc..8394626 100644
> --- a/drivers/rtc/rtc-rs5c348.c
> +++ b/drivers/rtc/rtc-rs5c348.c
> @@ -226,7 +226,7 @@ static int __devexit rs5c348_remove(struct spi_device
> *spi)
>
> static struct spi_driver rs5c348_driver = {
> .driver = {
> - .name = "rs5c348",
> + .name = "rtc-rs5c348",
> .bus= _bus_type,
> .owner = THIS_MODULE,
> },
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/12] Blackfin arch: Add label to call new GPIO API
On Sun 19 Aug 2007 17:54, David Brownell pondered:
> On Saturday 18 August 2007, Robin Getz wrote:
>
> > I don't see how early/late makes the problem easier/worse to debug. No
> > matter when you do it - the driver refuses to install (or at least
> > should).
>
> If you arrange to *reliably* detect the pinmux/setup problems by
> the time the system starts ""init" (early), that means one large
> class of hard-to-sort problems never needs runtime troubleshooting.
Sure it does - it just needs to do it in the bootloader, not the kernel. You
haven't eliminated the problem - or made it any easier to debug - it is just
moved somewhere else. Again - this is not bad. We decided/are attempting to
do it in the kernel. Normally what we find is there are more kernel people on
a project than bootloader (whether this makes this easier - or not - is still
TDB :)
> Think of it this way: folk have observed that pin setup issues can
> be painful to sort out.
Absolutely - the problem that everyone is trying to solve - is how to do plug
and play, with no enumeration?
Doing it early in the bootloader is akin to historical PC solution where early
ISA PNP (shudder) filled out a table in memory, and passed it to the OS.
> So they adopt a strategy ("failfast"/"early")
> which helps surface them early and basically removes them as issues
> in later debugging.
When the kernel engineer runs into a problem because a driver won't load, is
it better that he can fix it himself (hopefully), or that they have to call
the person maintaining the bootloader? There are pro/cons of either. I can
see the value in both.
We choose to do it in the driver, not the bootloader.
> > Right - for us - the code handing the hardware differences is easier
> > in the drivers, rather than the bootloaders.
>
> Remember that I didn't argue in favor of putting that code into
> boot loaders ... I just pointed out that some product lines work
> that way, so Linux needs to cope with that strategy. (One of the
> many examples involves OpenFirmware device tables.)
>
> But regardless: I can't buy any argument that it's better to put
> lots of board-specific code into drivers.
I don't think we are putting board specific code in drivers (or if there is -
it should get removed).
I did a quick look, and the only place this has happened is in some of our
drivers that have not made it to main line yet - where we accidently put some
mtd_partitions in the drivers, rather than the boards file. I know we are
working on fixing this.
> That adds up quickly,
> making maintaining the drivers painful. "Real" updates (bugfixes,
> new features, API updates, cleanup, and so on) regularly end up
> in conflict with patches to support a few more boards, and board
> support patches must then always involve those driver maintainers.
> So merging new boards involves many more people than necessary...
I agree - which is why don't do this either. Board specific info does not go
into drivers. I think this is something that Michael, Bryan and others
working on the Blackfin arch & drivers will agree to 100%.
What we do is try to make the driver agnostic to the hardware as much as
possible, where hardware specifics (chip selects, IRQ, GPIO, etc) are managed
in Kconfig.
I can see the value of doing the initialisation in the bootloader - since this
would allow you have a common driver - and hardware customisation is done in
the bootloader.
>
> >
> > linux-2.6.x/drivers/serial/Kconfig:
>
> That can work, at least for *single-board* kernel builds. Of course,
> that gets into territory some people will say is Kconfig abuse ...
> and the need for many ugly #ifdefs is very obvious. :)
We have been trying to minimise that - and I think we have been doing a pretty
good job. There doesn't seem to be any platform specific ifdefs in our
drivers that are not abstracted out.
> Doing that in Kconfig is atypical ... it may well be a bit easier to
> pick up at the beginning of a developer's learning curve, but I think
> it doesn't scale very well as multi-board product lines evolve.
We have lots of end users (obviously not as many as ARM or PPC yet), and they
have not been complaining, in fact some say that this is easier to deploy.
But - I think we both agree - that what we are doing is just an alternative
implemention of hardware abstraction - that is different than the way that
some others are doing it. Not better/worse (from what I can tell) - it just
has different tradeoffs.
-Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [5/12] x86_64: Make patching more robust, fix paravirt issue
On Fri, 2007-08-17 at 17:05 -0700, Jeremy Fitzhardinge wrote: > Andi Kleen wrote: > > Commit 19d36ccdc34f5ed444f8a6af0cbfdb6790eb1177 "x86: Fix alternatives > > and kprobes to remap write-protected kernel text" uses code which is > > being patched for patching. > > > > In particular, paravirt_ops does patching in two stages: first it > > calls paravirt_ops.patch, then it fills any remaining instructions > > with nop_out(). nop_out calls text_poke() which calls > > lookup_address() which calls pgd_val() (aka paravirt_ops.pgd_val): > > that call site is one of the places we patch. > > > > If we always do patching as one single call to text_poke(), we only > > need make sure we're not patching the memcpy in text_poke itself. > > This means the prototype to paravirt_ops.patch needs to change, to > > marshal the new code into a buffer rather than patching in place as it > > does now. It also means all patching goes through text_poke(), which > > is known to be safe (apply_alternatives is also changed to make a > > single patch). > > > > Hi Andi, > > This patch breaks Xen booting. I get infinite recursive faults during > patching when this patch is present. If I boot with > "noreplace-paravirt" it works OK, and it works as expected if I back > this patch out. I haven't tracked down the exact failure mode; its a > little hard to debug because it overwrites all kernel memory with > recursive fault stackframes and then finally traps out to Xen when it > hits the bottom of memory. > > I think we should back this one out before .23. Then back out 19d36ccdc34f5ed444f8a6af0cbfdb6790eb1177 too, which broke lguest booting, and this tried to fix. Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] rtc: Make rtc-ds1742 driver hotplug-aware
On Sunday 19 August 2007, Kay Sievers wrote: > No, I object to the concept of "platform" to disable all uevents by > default, Which it certainly doesn't do. Since the $SUBJECT patch doesn't affect a platform driver in any case, all those comments are well off-topic for $SUBJECT. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andi Kleen > Sent: Sunday, August 19, 2007 4:28 PM > To: Felix Marti > Cc: David Miller; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED] > Subject: Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate > PS_TCPportsfrom the host TCP port space. > > "Felix Marti" <[EMAIL PROTECTED]> writes: > > > what benefits does the TSO infrastructure give the > > non-TSO capable devices? > > It improves performance on software queueing devices between guests > and hypervisors. This is a more and more important application these > days. Even when the system running the Hypervisor has a non TSO > capable device in the end it'll still save CPU cycles this way. Right > now > virtualized IO tends to much more CPU intensive than direct IO so any > help it can get is beneficial. > > It also makes loopback faster, although given that's probably not that > useful. > > And a lot of the "TSO infrastructure" was needed for zero copy TX > anyways, > which benefits most reasonable modern NICs (anything with hardware > checksumming) Hi Andi, yes, you're right. I should have chosen my example more carefully. > > -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: legacy platform drivers and hotplugging
Notice I fixed $SUBJECT to not mention rtc-ds1742, which has never been a platform device and thus is offtopic to your specific complaints about platform bus hotplugging. On Saturday 18 August 2007, Kay Sievers wrote: > On Fri, 2007-08-17 at 21:06 -0700, David Brownell wrote: > > On Friday 17 August 2007, Kay Sievers wrote: > > > > > > > I'm not the one who's advocating a change here. If you want to > > > > first change/break and then fix things, all of that is up to you. > > > > > > I'm happy to do that. Patch is attached. > > > > NAK. That wasn't even a serious attempt at the "fix" part, > > though it does the "break" part well enough to cause severe > > regressions. > > You disabled uevents which breaks udev and HAL setups, because we can't > track the existence of the devices. Only certain code paths -- ones primarily used by legacy drivers -- disable those events. The basic problem with such legacy drivers is that they violate core driver model assumptions ... notably, by creating device nodes for non-existent hardware. Which means that for these legacy drivers, userspace can't track device existence in *that* way. If said driver creates some other device node after it's verified the hardware exists -- maybe one that's coupled to a character device -- it'd be fine to track *those* events. ISTR that most such drivers *do* create such nodes, since back in the prehistoric ooze from which they crawled, that was the only way to be seen by userspace. > You can't just disable device events > to disable module loading. Uevents have are by far not only about module > loading. Only for legacy drivers, because of the modprobe loop thing. So your proposal for how to handle such broken/legacy drivers is ... exactly what, then? Near as I can tell, you propose that the platform bus never support automatic module loading. Which seems to me like a nonstarting proposal: a significant and needless regression, inflicting harm on what for most platforms (by type, and also maybe by number-in-the-field) is the primary system bus. > > (As well as leaving all my technical points about your pushback > > un-addressed. As I noted before, the evident fact that you don't > > have technical responses to them says to me that your pushback > > has no real technical basis ...) > > It has. Disabling uevents to control module loading is just the totally > wrong thing to do. Uevents are there to let userspace know that a device > exists. See above. By your definition, legacy drivers would be issuing bogus events. So one key issue here is how to handle them; the patch you object to won't issue those buggy events. >From you, I've not seen even a proposal for a viable workaround to that looping bug. Not even that udev configs should handle it, for example, although that would appear to be the most natural conclusion given your premises and the fact that ISTR you're still maintaining it ... Whatever happens, I believe that legacy drivers will necessarily involve special casing to cope with the fact that they don't follow the current set of rules for drivers (though some folk seem to want to make them act as if they do). > Only the existence of MODALIAS and the "modalias" file controls > module loading, not the enabling and disabling of uevents, which is a > completely broken hack. Well, ISTR my original patch for the "looping" bug only affected those values, but you objected to that too... Which is why the code now just uses a pre-existing "no uevents" hook (on code paths used primarily by legacy drivers) instead of only addressing the "this driver can't be hotplugged" issue. It looks like you're maybe coming around to my original position, at least that key part of it. > My patch fixes tons of issues, and that is "technical basis" enough. It > makes platform play nice with userspace, by behaving like the rest of > the kernel. Yet as I noted: it causes a regression of just shy of 100% for platform device hotplug. Ergo a well-founded "NAK" ... two steps forward versus hundreds of steps backward, rarely a good idea. (You still haven't actually described any case where the current code is a problem. Handwaving "tons of issues" doesn't count.) > Userspace udev/HAL relies entirely on uevents, for hot- and for > coldplug. Coldplug is done by writing "add" to all "uevent" files during > early boot, that does not work anymore with platform, and needs to be > fixed. Like I said: "technical basis" enough not to merge your patch; it breaks coldplug too, as well as hotplug. > > Out of around 300 platform drivers in the tree (and many more > > not yet merged upstream), this makes it so that only *THREE* of > > them can hotplug ... versus in the current tree, essentially > > everything that's not a legacy driver is hotplugging just fine. > > > > That's one heck of a regression. Just shy of 100% ... > > So where are the 100's of drivers that send an uevent? I'll go and fix them. Device creation sends
RE: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 19, 2007 6:06 PM
> To: Felix Marti
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]
> Subject: Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate
> PS_TCPportsfrom the host TCP port space.
>
> From: "Felix Marti" <[EMAIL PROTECTED]>
> Date: Sun, 19 Aug 2007 17:47:59 -0700
>
> > [Felix Marti]
>
> Please stop using this to start your replies, thank you.
Better?
>
> > David and Herbert, so you agree that the user<>kernel
> > space memory copy overhead is a significant overhead and we want to
> > enable zero-copy in both the receive and transmit path? - Yes, copy
> > avoidance is mainly an API issue and unfortunately the so widely
used
> > (synchronous) sockets API doesn't make copy avoidance easy, which is
> one
> > area where protocol offload can help. Yes, some apps can resort to
> > sendfile() but there are many apps which seem to have trouble
> switching
> > to that API... and what about the receive path?
>
> On the send side none of this is an issue. You either are sending
> static content, in which using sendfile() is trivial, or you're
> generating data dynamically in which case the data copy is in the
> noise or too small to do zerocopy on and if not you can use a shared
> mmap to generate your data into, and then sendfile out from that file,
> to avoid the copy that way.
>
> splice() helps a lot too.
>
> Splice has the capability to do away with the receive side too, and
> there are a few receivefile() implementations that could get cleaned
> up and merged in.
I don't believe it is as simple as that. Many apps synthesize their
payload in user space buffers (i.e. malloced memory) and expect to
receive their data in user space buffers _and_ expect the received data
to have a certain alignment and to be contiguous - something not
addressed by these 'new' APIs. Look, people writing HPC apps tend to
take advantage of whatever they can to squeeze some extra performance
out of their apps and they are resorting to protocol offload technology
for a reason, wouldn't you agree?
>
> Also, the I/O bus is still the more limiting factor and main memory
> bandwidth in all of this, it is the smallest data pipe for
> communications out to and from the network. So the protocol header
> avoidance gains of TSO and LRO are still a very worthwhile savings.
So, i.e. with TSO, your saving about 16 headers (let us say 14 + 20 +
20), 864B, when moving ~64KB of payload - looks like very much in the
noise to me. And again, PCI-E provides more bandwidth than the wire...
>
> But even if RDMA increases performance 100 fold, it still doesn't
> avoid the issue that it doesn't fit in with the rest of the networking
> stack and feature set.
>
> Any monkey can change the rules around ("ok I can make it go fast as
> long as you don't need firewalling, packet scheduling, classification,
> and you only need to talk to specific systems that speak this same
> special protocol") to make things go faster. On the other hand well
> designed solutions can give performance gains within the constraints
> of the full system design and without sactificing functionality.
While I believe that you should give people an option to get 'high
performance' _instead_ of other features and let them chose whatever
they care about, I really do agree with what you're saying and believe
that offload devices _should_ be integrated with the facilities that you
mention (in fact, offload can do a much better job at lots of things
that you mention ;) ... but you're not letting offload devices integrate
and you're slowing down innovation in this field.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Should GFP_ATOMIC fail when we're below low watermark?
Hi all.
In current git (and for a while now), an attempt to allocate memory with
GFP_ATOMIC will fail if we're below the low watermark level. The only way to
access that memory that I can see (not that I've looked that hard) is to have
PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is correct.
Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about GFP_KERNEL?
The following patch is a potential fix for GFP_ATOMIC.
Regards,
Nigel
Signed-off-by: Nigel Cunningham <[EMAIL PROTECTED]>
page_alloc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -ruNp 995-gfp-atomic-alloc.patch-old/mm/page_alloc.c
995-gfp-atomic-alloc.patch-new/mm/page_alloc.c
--- 995-gfp-atomic-alloc.patch-old/mm/page_alloc.c 2007-08-20
11:14:34.0 +1000
+++ 995-gfp-atomic-alloc.patch-new/mm/page_alloc.c 2007-08-20
11:11:09.0 +1000
@@ -1286,8 +1286,8 @@ restart:
/* This allocation should allow future memory freeing. */
rebalance:
- if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
- && !in_interrupt()) {
+ if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE))
||
+ (gfp_mask & GFP_ATOMIC)) && !in_interrupt()) {
if (!(gfp_mask & __GFP_NOMEMALLOC)) {
nofail_alloc:
/* go through the zonelist yet again, ignoring mins */
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Marvell 88E8056 gigabit ethernet controller
Someone wrote me with a solution to try and so far it's working. They suggested I try the driver up on Marvell's website but to make sure I powered off the machine completely and when it rebooted to not have any of the regular kernel drivers for the Marvell chipset to load. They had found that letting the sky2 load and then unloading the module would mean the vendor's driver wouldn't work. So I got down the latest driver package they have (10.0.5.3). At first I couldn't get it compiled against kernel 2.6.22.3 that I'm running, but I have it compiled with the 2.6.21.5 kernel, which is what the machine is running now. And I'm happy to say that it's working fine so far. I've transfered about 4G over the link and it's still working fine. Since Marvell's driver seems to be working for the 88E8056 chipset and from what I've looked at the code it's marked as GPL, could it be rolled into the kernel for those of us that have 88E8056 chipsets that are working to use? Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptrdiff_t is not uintptr_t, damnit
On Sunday 19 August 2007, Al Viro wrote: > On Mon, Aug 20, 2007 at 01:27:13AM +0100, Anton Altaparmakov wrote: > > > And what the cast was doing I can't remember. I may well have just > > copied it from the VFS or I was perhaps trying to silence a warning > > and this happened to work... > > ... due to sparse bug (it miscalculated address space of pointed to, > picking top-level qualifiers for some reason; __user pointer to char > and pointer to __user char gave the same result and so did __user long). > That cast still made no sense... I could believe that all came from sparse bugs. Fixed now? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: "Felix Marti" <[EMAIL PROTECTED]>
Date: Sun, 19 Aug 2007 17:47:59 -0700
> [Felix Marti]
Please stop using this to start your replies, thank you.
> David and Herbert, so you agree that the user<>kernel
> space memory copy overhead is a significant overhead and we want to
> enable zero-copy in both the receive and transmit path? - Yes, copy
> avoidance is mainly an API issue and unfortunately the so widely used
> (synchronous) sockets API doesn't make copy avoidance easy, which is one
> area where protocol offload can help. Yes, some apps can resort to
> sendfile() but there are many apps which seem to have trouble switching
> to that API... and what about the receive path?
On the send side none of this is an issue. You either are sending
static content, in which using sendfile() is trivial, or you're
generating data dynamically in which case the data copy is in the
noise or too small to do zerocopy on and if not you can use a shared
mmap to generate your data into, and then sendfile out from that file,
to avoid the copy that way.
splice() helps a lot too.
Splice has the capability to do away with the receive side too, and
there are a few receivefile() implementations that could get cleaned
up and merged in.
Also, the I/O bus is still the more limiting factor and main memory
bandwidth in all of this, it is the smallest data pipe for
communications out to and from the network. So the protocol header
avoidance gains of TSO and LRO are still a very worthwhile savings.
But even if RDMA increases performance 100 fold, it still doesn't
avoid the issue that it doesn't fit in with the rest of the networking
stack and feature set.
Any monkey can change the rules around ("ok I can make it go fast as
long as you don't need firewalling, packet scheduling, classification,
and you only need to talk to specific systems that speak this same
special protocol") to make things go faster. On the other hand well
designed solutions can give performance gains within the constraints
of the full system design and without sactificing functionality.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Non atomic unaligned writes
* Andi Kleen ([EMAIL PROTECTED]) wrote: > Normally there are not that many NMIs or MCEs at boot, but it would > be still good to avoid the very rare crash by auditing the code first > [better than try to debug it on some production system later] > > > > - smp lock patching only ever changes a single byte (lock prefix) of > > > a single instruction > > > - kprobes only ever change a single byte > > > > > > For the immediate value patching it also cannot happen because > > > you'll never modify multiple instructions and all immediate values > > > can be changed atomically. > > > > > > > Are misaligned/cross-cache-line updates atomic? > > In theory yes, in practice there can be errata of course. There tend > to be a couple with self modifying code, especially cross modifying > (from another CPU) -- but you don't do that. > > -Andi I must disagree with Andi on this point. Considering the quoted paragraph below, misaligned/cross-cache-line updates are not atomic. This is why I align the immediate values in such a way that the immediate value within the mov instruction is itself aligned. Intel System Programming Guide 7.1.1 Guaranteed Atomic Operations The Intel386™, Intel486™, Pentium®, and P6 family processors guarantee that the following basic memory operations will always be carried out atomically: • Reading or writing a byte. • Reading or writing a word aligned on a 16-bit boundary. • Reading or writing a doubleword aligned on a 32-bit boundary. The P6 family processors guarantee that the following additional memory operations will always be carried out atomically: • Reading or writing a quadword aligned on a 64-bit boundary. (This operation is also guaranteed on the Pentium® processor.) • 16-bit accesses to uncached memory locations that fit within a 32-bit data bus. • 16-, 32-, and 64-bit accesses to cached memory that fit within a 32-Byte cache line. Accesses to cacheable memory that are split across bus widths, cache lines, and page boundaries are not guaranteed to be atomic by the Intel486™, Pentium®, or P6 family processors. The P6 family processors provide bus control signals that permit external memory subsystems to make split accesses atomic; however, nonaligned data accesses will seriously impact the performance of the processor and should be avoided where possible. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ptrdiff_t is not uintptr_t, damnit
On Mon, Aug 20, 2007 at 01:29:21AM +0100, Anton Altaparmakov wrote: > Hi, > > On 20 Aug 2007, at 01:19, David Brownell wrote: > >On Sunday 19 August 2007, Al Viro wrote: > >>is wrong; for one thing, it's a bad C (it's what uintptr_t is for; > >>in general > >>we are not even promised that ptrdiff_t is large enough to hold a > >>pointer, > > > >ISTR we don't *have* a uintptr_t on all architectures, or that would > >be the appropriate thing to use in these 32/64 bit ABI scenarios. > > > > > >>Use unsigned long or uintptr_t instead. > > > >I suspect you mean "unsigned long long"... > > No he doesn't. "unsigned long" is guaranteed to be large enough to > hold a pointer (at least on Linux anyway). > > On a 32-bit arch "unsigned long" is 32-bit and pointers are 32-bit. ... while unsigned long long is 64bit, which is definitely not what one wants. For sparse it's "unsigned long is special". FWIW, this patch puts it in linux/types.h as unsigned long. Eventually we might want to switch explicit casts to/from unsigned long in such contexts to uintptr_t, but for now we can't start complaining about unsigned long - too many places are using it. I'll see what can be done to get sane assistance from sparse in that kind of work... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
gitstat 0.1: kernel development statistics / monitoring system
We are pleased to announce the release of gitstat 0.1. Gitstat is a GPL'd, web-based git statistics/monitoring system. It retrieves a specified git tree, analyzes changesets, and shows graphical information like the number of changesets per day, the number of people who submitted changesets for a specific version(tag)…etc. Users may subscribe to gitstat so that they automatically receive an email notification if any change is applied to a specified directory. Currently, gitstat is mainly for linux kernel developers to monitor kernel development more conveniently with email notifications. It also shows each changset that users can search through with a specified title, content or developer. Gitstat was originally developed for internal use with minimal functionalities and therefore has much room for improvement. We hope more people join us to make this system a better one. gitstat was derived from kfm(kernel feature monitor) which was originally developed by Keun-Sik Lim and Sang-Bae Lee of Samsung Electronics and currently maintained and developed by Jeong-Seung Lee and Soon-Son Kwon(Shawn) of Samsung Electronics. kfm was inspired from Jon Corbet of lwn.net when he analyzed the git tree and Greg KH when he presented similar status report at OLS2007. We thought it would be interesting those information every day. You are welcome to try gitstat at http://tree.celinuxforum.org/gitstat For any suggestion, bug report, or patches, please visit http://sourceforge.net/projects/gitstat The developers would like to thank Samsung for sponsoring the work and CE Linux Forum for providing the hosting space - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ptrdiff_t is not uintptr_t, damnit
On Sunday 19 August 2007, Anton Altaparmakov wrote: > > > > ISTR we don't *have* a uintptr_t on all architectures, or that would > > be the appropriate thing to use in these 32/64 bit ABI scenarios. > > > > > >> Use unsigned long or uintptr_t instead. > > > > I suspect you mean "unsigned long long"... > > No he doesn't. "unsigned long" is guaranteed to be large enough to > hold a pointer (at least on Linux anyway). And yet when I used that, I got compiler warnings on some systems. ISTR that was the first solution I tried, but GCC really wanted to issue warnings. Either about casting 64-bit to pointer, or about casting it to "unsigned long", either way lost precision. > On a 32-bit arch "unsigned long" is 32-bit and pointers are 32-bit. > > On a 64-bit archi "unsigned long" is 64-bit and pointers are 64-bit. So with 32 bit userspace "unsigned long long" is the type to use when talking to a 64-bit kernel; and with pure 64-bit code, it's enough to write "unsigned long". I'm fairly sure that's the root cause of the pain I recall here; but I'd have to run experiments again to verify that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptrdiff_t is not uintptr_t, damnit
On Mon, Aug 20, 2007 at 01:27:13AM +0100, Anton Altaparmakov wrote: > And what the cast was doing I can't remember. I may well have just > copied it from the VFS or I was perhaps trying to silence a warning > and this happened to work... ... due to sparse bug (it miscalculated address space of pointed to, picking top-level qualifiers for some reason; __user pointer to char and pointer to __user char gave the same result and so did __user long). That cast still made no sense... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
> -Original Message- > From: David Miller [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 19, 2007 5:40 PM > To: Felix Marti > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED] > Subject: Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate > PS_TCPportsfrom the host TCP port space. > > From: "Felix Marti" <[EMAIL PROTECTED]> > Date: Sun, 19 Aug 2007 17:32:39 -0700 > > [ Why do you put that "[Felix Marti]" everywhere you say something? > It's annoying and superfluous. The quoting done by your mail client > makes clear who is saying what. ] > > > Hmmm, interesting... I guess it is impossible to even have > > a discussion on the subject. > > Nice try, Herbert Xu gave a great explanation. [Felix Marti] David and Herbert, so you agree that the user<>kernel space memory copy overhead is a significant overhead and we want to enable zero-copy in both the receive and transmit path? - Yes, copy avoidance is mainly an API issue and unfortunately the so widely used (synchronous) sockets API doesn't make copy avoidance easy, which is one area where protocol offload can help. Yes, some apps can resort to sendfile() but there are many apps which seem to have trouble switching to that API... and what about the receive path? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
uncached page allocator
Hi all, I've started doing some work with using the new DRM memory manager from TG for pixmaps in the X server using Intel 9xx series hardware. The intel hardware pretty much requires pages to be uncached for the GPU to access them. It can use cached memory for some operations but it isn't very useful and my attempts to use it ended in a lot of crashiness.. Now one of the major usage patterns for pixmaps is allocate pixmap copy data into pixmap use pixmap from hardware free pixmap with the current memory manager + updated change_page_attr (to use clflush when we have it) fixes from Andi Kleen, it operates something like this allocate pixmap gets cached memory copy data into the pixmap pre-use from hardware we flush the cache lines and tlb use the pixmap in hardware pre-free we need to set the page back to cached so we flush the tlb free the memory. The other path is if we don't want to use the memory cached ever is just allocate pixmap flush cache lines/tlb use uncached from CPU use uncached from GPU pre-free set the page back to cached, flush the TLB free the page Now the big issue here on SMP is that the cache and/or tlb flushes require IPIs and they are very noticeable on the profiles, So after all that I'd like to have some sort of uncached page list I can allocate pages from, so with frequent pixmap creation/destruction I don't spend a lot of time in the cache flushing routines and avoid the IPI in particular. The options I can sorta see roughly are: 1. the DRM just allocates a bunch of uncached pages and manages a cache of them for interacting with the hardware, this sounds wrong and we run into how do we correctly size the pool issues. 2. (Is this idea crazy??) We modify the VM somehow so we have an uncached list, when we first allocate pages with the GFP_UNCACHED they get migrated to the uncached zone and the pages use a page flag to say they are uncached. Then the DRM just re-uses things from that list. If later we end up with memory pressure, the free pages on the uncached list could be migrated back to the normal page lists by modifying the page attributes and flushing the tlb Any other ideas and suggestions? Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: "Felix Marti" <[EMAIL PROTECTED]> Date: Sun, 19 Aug 2007 17:32:39 -0700 [ Why do you put that "[Felix Marti]" everywhere you say something? It's annoying and superfluous. The quoting done by your mail client makes clear who is saying what. ] > Hmmm, interesting... I guess it is impossible to even have > a discussion on the subject. Nice try, Herbert Xu gave a great explanation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
> -Original Message- > From: David Miller [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 19, 2007 4:04 PM > To: Felix Marti > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED] > Subject: Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate > PS_TCPportsfrom the host TCP port space. > > From: "Felix Marti" <[EMAIL PROTECTED]> > Date: Sun, 19 Aug 2007 12:49:05 -0700 > > > You're not at all addressing the fact that RDMA does solve the > > memory BW problem and stateless offload doesn't. > > It does, I just didn't retort to your claims because they were > so blatantly wrong. [Felix Marti] Hmmm, interesting... I guess it is impossible to even have a discussion on the subject. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: group ownership of tun devices -- nonfunctional?
On 08/19/2007 11:42 PM, Bodo Eggert wrote:
On Sun, 19 Aug 2007, Rene Herman wrote:
On 08/19/2007 06:05 PM, Bodo Eggert wrote:
IMHO the check is broken:
+ if (((tun->owner != -1 &&
+ current->euid != tun->owner) ||
+(tun->group != -1 &&
+ current->egid != tun->group)) &&
+!capable(CAP_NET_ADMIN))
return -EPERM;
It should be something like:
+ if (!((tun->owner == tun->owner) ||
+ (tun->group == tun->group) ||
???
Argh, I edited asuming the same order of variables. Substitute
current->e{uid,gid} for one of the sides.
Okay. Just had to ask. That looked so odd...
+ capable(CAP_NET_ADMIN)))
return -EPERM;
The intended semantics is If the user is not
* the allowed user
or
* member of the allowed group
or
* cabable of CAP_NET_ADMIN
then error out. I'm asuming
There is a short description of the desired semantics in the link that was
posted:
http://lkml.org/lkml/2007/6/18/228
===
The user now is allowed to send packages if either his euid or his egid
matches the one specified via tunctl (via -u or -g respecitvely). If both
gid and uid are set via tunctl, both have to match.
===
Paraphrasing the original code above, it's saying:
if ((owner_is_set && does_not_match) || (group_is_set && does_not_match))
bugger_off_unless(CAP_NET_ADMIN);
or reverting the logic:
if ((owner_is_unset || does_match) && (group_is_unset || does_match))
good_to_go();
which probably matches the intention -- we're good to go only if the
credentials that are set also match.
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ptrdiff_t is not uintptr_t, damnit
Hi, On 20 Aug 2007, at 01:19, David Brownell wrote: On Sunday 19 August 2007, Al Viro wrote: is wrong; for one thing, it's a bad C (it's what uintptr_t is for; in general we are not even promised that ptrdiff_t is large enough to hold a pointer, ISTR we don't *have* a uintptr_t on all architectures, or that would be the appropriate thing to use in these 32/64 bit ABI scenarios. Use unsigned long or uintptr_t instead. I suspect you mean "unsigned long long"... No he doesn't. "unsigned long" is guaranteed to be large enough to hold a pointer (at least on Linux anyway). On a 32-bit arch "unsigned long" is 32-bit and pointers are 32-bit. On a 64-bit archi "unsigned long" is 64-bit and pointers are 64-bit. Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptrdiff_t is not uintptr_t, damnit
On 19 Aug 2007, at 23:55, Al Viro wrote:
Use of ptrdiff_t in
- if (!access_ok(VERIFY_WRITE, u_tmp->rx_buf,
u_tmp->len))
+ if (!access_ok(VERIFY_WRITE, (u8 __user *)
+ (ptrdiff_t) u_tmp-
>rx_buf,
+ u_tmp->len))
is wrong; for one thing, it's a bad C (it's what uintptr_t is for;
in general
we are not even promised that ptrdiff_t is large enough to hold a
pointer,
just enough to hold a difference between two pointers within the
same object).
For another, it confuses the fsck out of sparse.
Use unsigned long or uintptr_t instead. There are several places
misusing
ptrdiff_t (one - in a very odd way; WTF did that cast to __user
ptrdiff_t
in ntfs expect to happen, anyway?) Fixed...
My current NTFS code has this already fixed. I used unsigned long
instead of uintptr_t though... Feel free to apply this though as I
have no idea when I will have time/permission to push an update
upstream...
And what the cast was doing I can't remember. I may well have just
copied it from the VFS or I was perhaps trying to silence a warning
and this happened to work... But yes I noticed that more recent
versions of sparse complained about it and fixed it with an unsigned
long cast.
Best regards,
Anton
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/
commctrl.c
index 72b0393..1e6d7a9 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -391,7 +391,7 @@ static int close_getadapter_fib(struct aac_dev
* dev, void __user *arg)
/*
* Extract the fibctx from the input parameters
*/
- if (fibctx->unique == (u32)(ptrdiff_t)arg) /* We found a winner
*/
+ if (fibctx->unique == (u32)(uintptr_t)arg) /* We found a winner
*/
break;
entry = entry->next;
fibctx = NULL;
@@ -590,7 +590,7 @@ static int aac_send_raw_srb(struct aac_dev*
dev, void __user * arg)
}
addr = (u64)upsg->sg[i].addr[0];
addr += ((u64)upsg->sg[i].addr[1]) << 32;
- sg_user[i] = (void __user *)(ptrdiff_t)addr;
+ sg_user[i] = (void __user *)(uintptr_t)addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
@@ -633,7 +633,7 @@ static int aac_send_raw_srb(struct aac_dev*
dev, void __user * arg)
rcode = -ENOMEM;
goto cleanup;
}
- sg_user[i] = (void __user
*)(ptrdiff_t)usg->sg[i].addr;
+ sg_user[i] = (void __user
*)(uintptr_t)usg->sg[i].addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
@@ -664,7 +664,7 @@ static int aac_send_raw_srb(struct aac_dev*
dev, void __user * arg)
if (actual_fibsize64 == fibsize) {
struct user_sgmap64* usg = (struct user_sgmap64 *)upsg;
for (i = 0; i < upsg->count; i++) {
- u64 addr;
+ uintptr_t addr;
void* p;
/* Does this really need to be GFP_DMA? */
p =
kmalloc(usg->sg[i].count,GFP_KERNEL|__GFP_DMA);
@@ -676,7 +676,7 @@ static int aac_send_raw_srb(struct aac_dev*
dev, void __user * arg)
}
addr = (u64)usg->sg[i].addr[0];
addr += ((u64)usg->sg[i].addr[1]) << 32;
- sg_user[i] = (void __user *)(ptrdiff_t)addr;
+ sg_user[i] = (void __user *)addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
@@ -704,7 +704,7 @@ static int aac_send_raw_srb(struct aac_dev*
dev, void __user * arg)
rcode = -ENOMEM;
goto cleanup;
}
- sg_user[i] = (void __user
*)(ptrdiff_t)upsg->sg[i].addr;
+ sg_user[i] = (void __user
*)(uintptr_t)upsg->sg[i].addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
diff --git a/drivers/scsi/aacraid/comminit.c b/drivers/scsi/aacraid/
comminit.c
index 3009ad8..8736813 100644
--- a/drivers/scsi/aacraid/comminit.c
+++
[M68KNOMMU]: include linux/fs.h for do_pip()
Include linux/fs.h to get the prototype for do_pipe(). Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naur ORG.linux-2.6.23-rc3/arch/m68knommu/kernel/sys_m68k.c linux-2.6.23-rc3/arch/m68knommu/kernel/sys_m68k.c --- ORG.linux-2.6.23-rc3/arch/m68knommu/kernel/sys_m68k.c 2007-07-09 09:32:17.0 +1000 +++ linux-2.6.23-rc3/arch/m68knommu/kernel/sys_m68k.c 2007-08-14 16:17:27.0 +1000 @@ -18,6 +18,7 @@ #include #include #include +#include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[M68KNOMMU]: include asm-generic/pgtable.h
Include asm-generic/pgtable.h to pick up the lazy_mmu_mode and lazy_cpu_mode macros. Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naur ORG.linux-2.6.23-rc3/include/asm-m68knommu/pgtable.h linux-2.6.23-rc3/include/asm-m68knommu/pgtable.h --- ORG.linux-2.6.23-rc3/include/asm-m68knommu/pgtable.h2007-08-14 15:31:17.0 +1000 +++ linux-2.6.23-rc3/include/asm-m68knommu/pgtable.h2007-08-14 16:17:10.0 +1000 @@ -65,4 +65,6 @@ #defineVMALLOC_START 0 #defineVMALLOC_END 0x +#include + #endif /* _M68KNOMMU_PGTABLE_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/
[M68KNOMMU]: include linux/fs.h for getname()
Include linux/fs.h to get the prototype for getname(). Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naur ORG.linux-2.6.23-rc3/arch/m68knommu/kernel/process.c linux-2.6.23-rc3/arch/m68knommu/kernel/process.c --- ORG.linux-2.6.23-rc3/arch/m68knommu/kernel/process.c2007-08-14 15:30:46.0 +1000 +++ linux-2.6.23-rc3/arch/m68knommu/kernel/process.c2007-08-14 16:17:36.0 +1000 @@ -28,6 +28,7 @@ #include #include #include +#include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MOTU Fastlane USB MIDI interface
On Fri, 17 Aug 2007, Clemens Ladisch wrote: > David Griffith wrote: > > On Thu, 16 Aug 2007, Clemens Ladisch wrote: > > > Please try "amidi -d -p virtual" and playing a .mid file to this port with > > > aplaymidi. > > > > $ aplaymidi -p "virtual" castle2.mid > > Invalid port virtual - No such file or directory > > Sorry, the name of the correspondig sequencer port is different, > probably "128:0"; see the output of "aplaymidi -l". $ aplaymidi -l PortClient name Port name 14:0Midi Through Midi Through Port-0 16:0Ensoniq AudioPCI ES1371 20:0Fastlane Fastlane MIDI A 20:1Fastlane Fastlane MIDI B $ aplaymidi -p 20:0 casablan.mid Nothing is written to the Fastlane. No lights. Nothing. -- David Griffith [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptrdiff_t is not uintptr_t, damnit
On Sunday 19 August 2007, Al Viro wrote: > is wrong; for one thing, it's a bad C (it's what uintptr_t is for; in general > we are not even promised that ptrdiff_t is large enough to hold a pointer, ISTR we don't *have* a uintptr_t on all architectures, or that would be the appropriate thing to use in these 32/64 bit ABI scenarios. > Use unsigned long or uintptr_t instead. I suspect you mean "unsigned long long"... - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
Felix Marti <[EMAIL PROTECTED]> wrote:
>
> [Felix Marti] Aren't you confusing memory and bus BW here? - RDMA
> enables DMA from/to application buffers removing the user-to-kernel/
> kernel-to-user memory copy with is a significant overhead at the
> rates we're talking about: memory copy at 20Gbps (10Gbps in and 10Gbps
> out) requires 60Gbps of BW on most common platforms. So, receiving and
> transmitting at 10Gbps with LRO and TSO requires 80Gbps of system
> memory BW (which is beyond what most systems can do) whereas RDMA can
> do with 20Gbps!
Actually this is false. TSO only requires a copy if the user
chooses to use the sendmsg interface instead of sendpage. The
same is true for RDMA really. Except that instead of having to
switch your application to sendfile/splice, you're switching it
to RDMA.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] update .gitignore
On Mon, Aug 20, 2007 at 01:01:36AM +0200, Adrian Bunk wrote: > On Wed, Aug 01, 2007 at 09:10:37PM +0200, Adrian Bunk wrote: > > On Wed, Aug 01, 2007 at 11:07:53PM +0400, Alexey Dobriyan wrote: > > > On Wed, Aug 01, 2007 at 03:10:51PM +0200, Adrian Bunk wrote: > > > > --- linux-2.6.23-rc1-mm2/.gitignore.old > > > > +++ linux-2.6.23-rc1-mm2/.gitignore > > > > @@ -14,18 +14,25 @@ > > > > *.so > > > > *.mod.c > > > > *.i > > > > +!include/asm-*/*.i > > > > > > I think these should be renamed to .S and let .i alone for preprocessed > > > stuff. > > >... > > > > Fine with me if Andi agrees. > > Andi? Hmm, perhaps rename alternative-asm.i to .h and stick a #ifdef __ASSEMBLY__ around it. There is actually only one includer currently, but there might be more in the future again. -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: sending raw packets via PPP
On Aug 6, 2007, at 6:30 PM, James Carlson wrote: Kevin K writes: Is it possible to send raw packets via ppp under Linux? More specifically, in 2.4 series kernels such as RH's 2.4.21-47 kernel? I've trying to modify the DHCP 3.0.1 code provided with RH 3 so I can send requests via a PPP connection (standard RS-232), and it is just being dropped by the stack according to ifconfig and debug statements in ppp_generic.c. I'm not sure what sort of "raw" packets you're talking about (IP raw or something else), but you shouldn't need to send any raw packets to do this. DHCP runs over UDP, and, unlike Ethernet, there's no link layer addressing to worry about. -- James Carlson 42.703N 71.076W <[EMAIL PROTECTED]> I would like to thank the people who responded to this posting for their help. It helped keep me from wasting additional time trying to use SOCK_PACKET over PPP just because the DHCP code in Red Hat used it for ethernet. (The dhclient code did it to ensure that the ethernet/IP/UDP headers were to their satisfaction, and to avoid some bugs in older versions of the Linux kernel). I've tested through a serial/PPP connection without issues. This is obviously not a normal configuration, having to run a DHCP client through PPP, but the IP addresses are assigned via a DHCP server, but he router we connect to via PPP won't retrieve addresses from the DHCP server for us. Thanks, Kevin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/3] x86_64 EFI runtime service support
On 8/19/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > "Huang, Ying" <[EMAIL PROTECTED]> writes: > > > On Thu, 2007-08-16 at 07:22 +0800, H. Peter Anvin wrote: > >> Andrew Morton wrote: > >> > On Mon, 13 Aug 2007 15:30:19 +0800 > >> > "Huang, Ying" <[EMAIL PROTECTED]> wrote: > >> > > >> >> Following sets of patches add EFI/UEFI (Unified Extensible Firmware > >> >> Interface) runtime services support to x86_64 architecture. > >> > > >> > OK, we have a major trainwreck when these patches meet Peter's > >> > get-newsetup.patch. > >> > > >> > I'm halfway into fixing it when I see this. You have: > >> > > >> > #define SYS_DESC_TABLE (*(struct sys_desc_table_struct*)(PARAM > >> +0xa0)) > >> > +#define EFI_LOADER_SIG ((unsigned char *)(PARAM+0x1c0)) > >> > +#define EFI_MEMDESC_SIZE (*((unsigned int *) (PARAM+0x1c4))) > >> > +#define EFI_MEMDESC_VERSION (*((unsigned int *) (PARAM+0x1c8))) > >> > +#define EFI_MEMMAP_SIZE (*((unsigned int *) (PARAM+0x1cc))) > >> > +#define EFI_MEMMAP (*((unsigned long *)(PARAM+0x1d0))) > >> > +#define EFI_SYSTAB (*((unsigned long *)(PARAM+0x1d8))) > >> > #define MOUNT_ROOT_RDONLY (*(unsigned short *) (PARAM+0x1F2)) > >> > > >> > >> Please, no more of these kinds of macros. We have already had > >> collisions. Go ahead and redefine the efi_info structure if > >> necessary, > > > > according to the git-newsetup.patch. > > > > One question: > > > > The boot_params.efi_info.efi_systab is defined as u32. But it should be > > u64 on x86_64, because it comes from firmware and is not controlled by > > bootloader. But, changing it from u32 to u64 will break current i386 EFI > > support, should we change it and fix the i386 EFI bootloader? > > Be very very very careful how you talk about this. > > I have seen machines in the wild a 64bit processor and a 32bit EFI. > So this is not a linux architecture issue, or a cpu architecture > issue. This is an EFI architecture issue. > > This is an issue of do you have a 32bit or a 64bit EFI implementation > on your machine. Which is very different. > > We should be able to boot a 32bit kernel with a 64bit EFI. > We should be able to boot a 64bit kernel with a 32bit EFI. > > Maybe our response is to ignore the information from elilo so > we don't attempt EFI runtime calls but the boot information should > be unambiguous. > > So we need to be able to look at the data and answer these questions. > - Is EFI present? > - Is EFI 32bit? > - Is EFI 64bit? > someone told me that EFI PEI will be 32 bit ( for mem etc initialization), and after that will be 64 bit, so the Run time service will be 64 bit only, and it will only support 64 bit OS with EFI. and they have another mode to emulate the legacy BIOS to boot 32bit OS. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 trivial] include/asm-*/system.h: remove unused set_rmb(), set_wmb() macros
Stefan Richter wrote: These don't appear anywhere else in the kernel anymore. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> Cc: Bryan Wu <[EMAIL PROTECTED]> Cc: Yoshinori Sato <[EMAIL PROTECTED]> Cc: Greg Ungerer <[EMAIL PROTECTED]> Cc: Paul Mundt <[EMAIL PROTECTED]> Cc: Miles Bader <[EMAIL PROTECTED]> --- include/asm-blackfin/system.h |4 +--- include/asm-h8300/system.h |3 +-- include/asm-m68knommu/system.h |3 +-- include/asm-sh64/system.h |3 +-- include/asm-v850/system.h |3 +-- 5 files changed, 5 insertions(+), 11 deletions(-) Index: linux/include/asm-blackfin/system.h Index: linux/include/asm-m68knommu/system.h === --- linux.orig/include/asm-m68knommu/system.h +++ linux/include/asm-m68knommu/system.h Acked-by: Greg Ungerer <[EMAIL PROTECTED]> Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: Andi Kleen <[EMAIL PROTECTED]> Date: 20 Aug 2007 01:27:35 +0200 > "Felix Marti" <[EMAIL PROTECTED]> writes: > > > what benefits does the TSO infrastructure give the > > non-TSO capable devices? > > It improves performance on software queueing devices between guests > and hypervisors. This is a more and more important application these > days. Even when the system running the Hypervisor has a non TSO > capable device in the end it'll still save CPU cycles this way. Right now > virtualized IO tends to much more CPU intensive than direct IO so any > help it can get is beneficial. > > It also makes loopback faster, although given that's probably not that > useful. > > And a lot of the "TSO infrastructure" was needed for zero copy TX anyways, > which benefits most reasonable modern NICs (anything with hardware > checksumming) And also, you can enable TSO generation for a non-TSO-hw device and get all of the segmentation overhead reduction gains which works out as a pure win as long as the device can at a minimum do checksumming. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: "Felix Marti" <[EMAIL PROTECTED]> Date: Sun, 19 Aug 2007 12:49:05 -0700 > You're not at all addressing the fact that RDMA does solve the > memory BW problem and stateless offload doesn't. It does, I just didn't retort to your claims because they were so blatantly wrong. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: convert #include "linux/..." to #include [PATCH]s follow
On Mon, 2007-08-20 at 00:33 +0200, Jan Engelhardt wrote: > Not only that. All directories in include should be checked against > (e.g. ) Should any file in include/ have a line like: #include "[path/]file" Shouldn't these all be #include ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Marvell 88E8056 gigabit ethernet controller
On 19-Aug-07, at 2:34 PM, Stephen Hemminger wrote: The driver prints some chip version info at startup, that might be helpful in disambiguating good/bad versions: dmesg | grep sky2 sky2 :03:00.0: v1.16 addr 0xfa00 irq 16 Yukon-EC Ultra (0xb4) rev 2 sky2 eth0: addr XX:XX:XX:XX:XX sky2 eth0: enabling interface sky2 eth0: ram buffer 0K sky2 eth0: disabling interface -E --- Eric Preston, RHCA, RHCSS, RHCE Open Source Software Consultant // Administrator, Developer, Trainer 514-312-7072 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] update .gitignore
On Wed, Aug 01, 2007 at 09:10:37PM +0200, Adrian Bunk wrote: > On Wed, Aug 01, 2007 at 11:07:53PM +0400, Alexey Dobriyan wrote: > > On Wed, Aug 01, 2007 at 03:10:51PM +0200, Adrian Bunk wrote: > > > --- linux-2.6.23-rc1-mm2/.gitignore.old > > > +++ linux-2.6.23-rc1-mm2/.gitignore > > > @@ -14,18 +14,25 @@ > > > *.so > > > *.mod.c > > > *.i > > > +!include/asm-*/*.i > > > > I think these should be renamed to .S and let .i alone for preprocessed > > stuff. > >... > > Fine with me if Andi agrees. Andi? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
Marc Perkel wrote: > The important point that you are missing here is that > the Linux world is willing to live with an rm command > that is broken and the Windows and DOS world isn't. > This isn't about the rm command it's about programming > standards. It's about that the Linux community isn't > committed to getting it right. Thanks man, you've made my day. I haven't laughed this hard at a mildly technical discussion in weeks. > Just like my thinking outside the box thread when I > try to say "this is broken" people don't go fix it. > Instead I get an explanation why Linux isn't capable > of having an rm command that will delete an unlimited > number of files. Calling something that bas been working for decades broken, and offering a vague idea that is not only riddled with usability issues but also unimplementable in an even remotely efficient manner, and yet expecting people to jump into action and write it for you while deprecating an enormous amount of existing code, is something best described as surreal. Disregarding peer review and calling it an "attack" is just icing on the cake. > I bet there are Microsoft people out there laughing at > this. Probably at you. > THINK ABOUT IT PEOPLE !!! > > 20 years, a million programmers, tens of millions of > users and RM is BROKEN. Am I the only one who has a > problem with this? If so - I'm normal - and Linux is a > cult. All hail Linus the great. -- m. tharp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: convert #include "linux/..." to #include [PATCH]s follow
On Sun, Aug 19, 2007 at 03:49:16PM -0700, Joe Perches wrote: > On Sun, 2007-08-19 at 23:44 +0100, Al Viro wrote: > > Except that some instances are legitimate (e.g. there was a bunch in > > arch/um, IIRC)... > > I guess it's a good thing that vger seems to have rejected > that 140KB patch I sent against arch/um and include/asm-um. It would be a better thing if you * did builds of the patched trees (allmodconfig for uml/i386 and uml/amd64 in this case) * figured out that one can send a reference to branch in git tree (with summary/shortlog/diffstat) using somewhat less than 140KB... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ptrdiff_t is not uintptr_t, damnit
Use of ptrdiff_t in
- if (!access_ok(VERIFY_WRITE, u_tmp->rx_buf, u_tmp->len))
+ if (!access_ok(VERIFY_WRITE, (u8 __user *)
+ (ptrdiff_t) u_tmp->rx_buf,
+ u_tmp->len))
is wrong; for one thing, it's a bad C (it's what uintptr_t is for; in general
we are not even promised that ptrdiff_t is large enough to hold a pointer,
just enough to hold a difference between two pointers within the same object).
For another, it confuses the fsck out of sparse.
Use unsigned long or uintptr_t instead. There are several places misusing
ptrdiff_t (one - in a very odd way; WTF did that cast to __user ptrdiff_t
in ntfs expect to happen, anyway?) Fixed...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 72b0393..1e6d7a9 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -391,7 +391,7 @@ static int close_getadapter_fib(struct aac_dev * dev, void
__user *arg)
/*
* Extract the fibctx from the input parameters
*/
- if (fibctx->unique == (u32)(ptrdiff_t)arg) /* We found a winner
*/
+ if (fibctx->unique == (u32)(uintptr_t)arg) /* We found a winner
*/
break;
entry = entry->next;
fibctx = NULL;
@@ -590,7 +590,7 @@ static int aac_send_raw_srb(struct aac_dev* dev, void
__user * arg)
}
addr = (u64)upsg->sg[i].addr[0];
addr += ((u64)upsg->sg[i].addr[1]) << 32;
- sg_user[i] = (void __user *)(ptrdiff_t)addr;
+ sg_user[i] = (void __user *)(uintptr_t)addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
@@ -633,7 +633,7 @@ static int aac_send_raw_srb(struct aac_dev* dev, void
__user * arg)
rcode = -ENOMEM;
goto cleanup;
}
- sg_user[i] = (void __user
*)(ptrdiff_t)usg->sg[i].addr;
+ sg_user[i] = (void __user
*)(uintptr_t)usg->sg[i].addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
@@ -664,7 +664,7 @@ static int aac_send_raw_srb(struct aac_dev* dev, void
__user * arg)
if (actual_fibsize64 == fibsize) {
struct user_sgmap64* usg = (struct user_sgmap64 *)upsg;
for (i = 0; i < upsg->count; i++) {
- u64 addr;
+ uintptr_t addr;
void* p;
/* Does this really need to be GFP_DMA? */
p =
kmalloc(usg->sg[i].count,GFP_KERNEL|__GFP_DMA);
@@ -676,7 +676,7 @@ static int aac_send_raw_srb(struct aac_dev* dev, void
__user * arg)
}
addr = (u64)usg->sg[i].addr[0];
addr += ((u64)usg->sg[i].addr[1]) << 32;
- sg_user[i] = (void __user *)(ptrdiff_t)addr;
+ sg_user[i] = (void __user *)addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
@@ -704,7 +704,7 @@ static int aac_send_raw_srb(struct aac_dev* dev, void
__user * arg)
rcode = -ENOMEM;
goto cleanup;
}
- sg_user[i] = (void __user
*)(ptrdiff_t)upsg->sg[i].addr;
+ sg_user[i] = (void __user
*)(uintptr_t)upsg->sg[i].addr;
sg_list[i] = p; // save so we can clean up later
sg_indx = i;
diff --git a/drivers/scsi/aacraid/comminit.c b/drivers/scsi/aacraid/comminit.c
index 3009ad8..8736813 100644
--- a/drivers/scsi/aacraid/comminit.c
+++ b/drivers/scsi/aacraid/comminit.c
@@ -110,7 +110,7 @@ static int aac_alloc_comm(struct aac_dev *dev, void
**commaddr, unsigned long co
/*
* Align the beginning of Headers to commalign
*/
- align = (commalign - ((ptrdiff_t)(base) & (commalign - 1)));
+ align = (commalign - ((uintptr_t)(base) & (commalign - 1)));
base = base + align;
phys = phys + align;
/*
diff --git a/drivers/scsi/aacraid/dpcsup.c b/drivers/scsi/aacraid/dpcsup.c
index fcd25f7..e6032ff 100644
--- a/drivers/scsi/aacraid/dpcsup.c
+++ b/drivers/scsi/aacraid/dpcsup.c
@@ -254,7 +254,7 @@ unsigned
Re: general protection fault with powernow-k8 frequency scaling on x86-64
Hamish Moffatt <[EMAIL PROTECTED]> writes: > I'm running 2.6.22.1 (Debian's package) although this started happening > at first with about 2.6.17. If you can reproduce it you could bisect it. But it's unlikely that it is a software problem. However it might just be that powernow wasn't used in the old kernel and some change made it work. Also newer kernels tend to change frequencies more often especially with ondemand; that might have also triggered it. > > Here's an example fault; a few more occur a few minutes after that, then > the whole system locks up soon after. The complete kernel log is below. > > Any ideas? It sounds like some kind of hardware issue. The Voltage Regulation Module on the motherboard could have problems with the power supply to the CPU and that can then cause all kinds of weird effects. On K7 such problems were fairly common; on K8 less so because powernow is more widdespread but can happen occasionally. It might also be that your hardware degenerated (e.g cheap boards often have not very long lived components). You could double check that by running the 2.6.17 kernel again (making sure it does powernow) Exchanging the motherboard could potentially safe a lot of trouble. Or not run powernow anymore. -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: convert #include "linux/..." to #include [PATCH]s follow
On Sun, 2007-08-19 at 23:44 +0100, Al Viro wrote: > Except that some instances are legitimate (e.g. there was a bunch in > arch/um, IIRC)... I guess it's a good thing that vger seems to have rejected that 140KB patch I sent against arch/um and include/asm-um. cheers, Joe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Marvell 88E8056 gigabit ethernet controller
> The working board has a different version of the Marvell chip: > $ grep Marvell working-MB > 04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 14) > $ grep Marvell broken-MB > 04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12) Just to add a bit more information, I've just build up a GA-965P-DS3 with a Q6600 and the onboard Marvell doesn't seem to be working either with 2.6.21.3, 2.6.23-rc3 or a recent gentoo-sources kernel. $ grep Marvell lspci 03:00.0 Ethernet controller: Marvell Technology Group Ltd. Unknown device 4364 (rev 12) I've attached the lspci -vvv. I haven't had a chance to do much investigation since I just threw an 10/100 in for the time being. Let me know if I can provide any assistance in diagnosing or testing. -E --- Eric Preston, RHCA, RHCSS, RHCE Open Source Software Consultant // Administrator, Developer, Trainer 514-312-7072 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: convert #include "linux/..." to #include [PATCH]s follow
On Mon, Aug 20, 2007 at 12:33:21AM +0200, Jan Engelhardt wrote: > > On Aug 19 2007 15:17, Joe Perches wrote: > >There are several files that: > > > >#include "linux/file" not #include > >#include "asm/file" not #include > > Not only that. All directories in include should be checked against > (e.g. ) Except that some instances are legitimate (e.g. there was a bunch in arch/um, IIRC)... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/5] Documentation/firmware/... convert #include "linux/..." to #include
On Sun, 2007-08-19 at 15:41 -0700, Randy Dunlap wrote:
> It's not only included in that directory.
> I find it included in 88 source files throughout the kernel tree.
I see, sorry. I didn't read the file.
I thought it was a sample driver with a binary blob.
cheers, Joe
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/Documentation/firmware_class/firmware_sample_driver.c
b/Documentation/firmware_class/firmware_sample_driver.c
index 6865cbe..754ded2 100644
--- a/Documentation/firmware_class/firmware_sample_driver.c
+++ b/Documentation/firmware_class/firmware_sample_driver.c
@@ -13,7 +13,7 @@
#include
#include
-#include "linux/firmware.h"
+#include
static struct device ghost_device = {
.bus_id= "ghost0",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/5] Documentation/firmware/... convert #include "linux/..." to #include
On Sun, 19 Aug 2007 15:31:57 -0700 Joe Perches wrote: > On Sun, 2007-08-19 at 15:34 -0700, Randy Dunlap wrote: > > > -#include "linux/firmware.h" > > > +#include "firmware.h" > > I believe that it should be . > > OK. > > That's not my taste though, especially if only > included by files in the firmware_class directory. > Less pollution/namespace collision in include/linux It's not only included in that directory. I find it included in 88 source files throughout the kernel tree. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
"Felix Marti" <[EMAIL PROTECTED]> writes: > what benefits does the TSO infrastructure give the > non-TSO capable devices? It improves performance on software queueing devices between guests and hypervisors. This is a more and more important application these days. Even when the system running the Hypervisor has a non TSO capable device in the end it'll still save CPU cycles this way. Right now virtualized IO tends to much more CPU intensive than direct IO so any help it can get is beneficial. It also makes loopback faster, although given that's probably not that useful. And a lot of the "TSO infrastructure" was needed for zero copy TX anyways, which benefits most reasonable modern NICs (anything with hardware checksumming) -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: convert #include "linux/..." to #include [PATCH]s follow
On Aug 19 2007 15:17, Joe Perches wrote: >There are several files that: > >#include "linux/file" not #include >#include "asm/file" not #include Not only that. All directories in include should be checked against (e.g. ) Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] Documentation/firmware/... convert #include "linux/..." to #include
On Sun, 2007-08-19 at 15:34 -0700, Randy Dunlap wrote: > > -#include "linux/firmware.h" > > +#include "firmware.h" > I believe that it should be . OK. That's not my taste though, especially if only included by files in the firmware_class directory. Less pollution/namespace collision in include/linux cheers, Joe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/5] Documentation/firmware/... convert #include "linux/..." to #include
On Sun, 19 Aug 2007 15:19:32 -0700 Joe Perches wrote:
> (untested)
>
> There are several files that
> #include "linux/file" not #include
> #include "asm/file" not #include
>
> Here's a little script that converts them:
>
> egrep -i -r -l --include=*.[ch] \
> "^[[:space:]]*\#[[:space:]]*include[[:space:]]*\"(linux|asm)/(.*)\"" * \
> | xargs sed -i -e
> 's/^[[:space:]]*#[[:space:]]*include[[:space:]]*"\(linux\|asm\)\/\(.*\)"/#include
> <\1\/\2>/g'
>
> This one is probably wrong.
>
> It should likely keep firmware.h in
> the same directory as firmware.c
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/Documentation/firmware_class/firmware_sample_driver.c
> b/Documentation/firmware_class/firmware_sample_driver.c
> index 6865cbe..754ded2 100644
> --- a/Documentation/firmware_class/firmware_sample_driver.c
> +++ b/Documentation/firmware_class/firmware_sample_driver.c
> @@ -13,7 +13,7 @@
> #include
> #include
>
> -#include "linux/firmware.h"
> +#include "firmware.h"
I believe that it should be .
> static struct device ghost_device = {
> .bus_id= "ghost0",
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/3] x86_64 EFI runtime service support
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Huang, Ying wrote: >> >> One question: >> >> The boot_params.efi_info.efi_systab is defined as u32. But it should be >> u64 on x86_64, because it comes from firmware and is not controlled by >> bootloader. But, changing it from u32 to u64 will break current i386 EFI >> support, should we change it and fix the i386 EFI bootloader? >> > > The other option is to have a union of a 32-bit and a 64-bit structure. > I personally don't care, as long as it's consistent, but I think you > need to deal with the people working on EFI currently about that... It sounds like the 64bit EFI is currently binary incompatible with the 32bit EFI. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] x86_64 EFI runtime service support
"Huang, Ying" <[EMAIL PROTECTED]> writes: > On Thu, 2007-08-16 at 07:22 +0800, H. Peter Anvin wrote: >> Andrew Morton wrote: >> > On Mon, 13 Aug 2007 15:30:19 +0800 >> > "Huang, Ying" <[EMAIL PROTECTED]> wrote: >> > >> >> Following sets of patches add EFI/UEFI (Unified Extensible Firmware >> >> Interface) runtime services support to x86_64 architecture. >> > >> > OK, we have a major trainwreck when these patches meet Peter's >> > get-newsetup.patch. >> > >> > I'm halfway into fixing it when I see this. You have: >> > >> > #define SYS_DESC_TABLE (*(struct sys_desc_table_struct*)(PARAM >> +0xa0)) >> > +#define EFI_LOADER_SIG ((unsigned char *)(PARAM+0x1c0)) >> > +#define EFI_MEMDESC_SIZE (*((unsigned int *) (PARAM+0x1c4))) >> > +#define EFI_MEMDESC_VERSION (*((unsigned int *) (PARAM+0x1c8))) >> > +#define EFI_MEMMAP_SIZE (*((unsigned int *) (PARAM+0x1cc))) >> > +#define EFI_MEMMAP (*((unsigned long *)(PARAM+0x1d0))) >> > +#define EFI_SYSTAB (*((unsigned long *)(PARAM+0x1d8))) >> > #define MOUNT_ROOT_RDONLY (*(unsigned short *) (PARAM+0x1F2)) >> > >> >> Please, no more of these kinds of macros. We have already had >> collisions. Go ahead and redefine the efi_info structure if >> necessary, > > according to the git-newsetup.patch. > > One question: > > The boot_params.efi_info.efi_systab is defined as u32. But it should be > u64 on x86_64, because it comes from firmware and is not controlled by > bootloader. But, changing it from u32 to u64 will break current i386 EFI > support, should we change it and fix the i386 EFI bootloader? Be very very very careful how you talk about this. I have seen machines in the wild a 64bit processor and a 32bit EFI. So this is not a linux architecture issue, or a cpu architecture issue. This is an EFI architecture issue. This is an issue of do you have a 32bit or a 64bit EFI implementation on your machine. Which is very different. We should be able to boot a 32bit kernel with a 64bit EFI. We should be able to boot a 64bit kernel with a 32bit EFI. Maybe our response is to ignore the information from elilo so we don't attempt EFI runtime calls but the boot information should be unambiguous. So we need to be able to look at the data and answer these questions. - Is EFI present? - Is EFI 32bit? - Is EFI 64bit? Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] mm/... convert #include "linux/..." to #include
(untested) There are several files that #include "linux/file" not #include #include "asm/file" not #include Here's a little script that converts them: egrep -i -r -l --include=*.[ch] \ "^[[:space:]]*\#[[:space:]]*include[[:space:]]*\"(linux|asm)/(.*)\"" * \ | xargs sed -i -e 's/^[[:space:]]*#[[:space:]]*include[[:space:]]*"\(linux\|asm\)\/\(.*\)"/#include <\1\/\2>/g' Signed-off-by: Joe Perches <[EMAIL PROTECTED]> diff --git a/mm/slab.c b/mm/slab.c index a684778..976aeff 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -334,7 +334,7 @@ static __always_inline int index_of(const size_t size) return i; \ else \ i++; -#include "linux/kmalloc_sizes.h" +#include #undef CACHE __bad_size(); } else - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] Documentation/firmware/... convert #include "linux/..." to #include
(untested)
There are several files that
#include "linux/file" not #include
#include "asm/file" not #include
Here's a little script that converts them:
egrep -i -r -l --include=*.[ch] \
"^[[:space:]]*\#[[:space:]]*include[[:space:]]*\"(linux|asm)/(.*)\"" * \
| xargs sed -i -e
's/^[[:space:]]*#[[:space:]]*include[[:space:]]*"\(linux\|asm\)\/\(.*\)"/#include
<\1\/\2>/g'
This one is probably wrong.
It should likely keep firmware.h in
the same directory as firmware.c
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/Documentation/firmware_class/firmware_sample_driver.c
b/Documentation/firmware_class/firmware_sample_driver.c
index 6865cbe..754ded2 100644
--- a/Documentation/firmware_class/firmware_sample_driver.c
+++ b/Documentation/firmware_class/firmware_sample_driver.c
@@ -13,7 +13,7 @@
#include
#include
-#include "linux/firmware.h"
+#include "firmware.h"
static struct device ghost_device = {
.bus_id= "ghost0",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: convert #include "linux/..." to #include [PATCH]s follow
On 20/08/07, Joe Perches <[EMAIL PROTECTED]> wrote: > There are several files that: > > #include "linux/file" not #include > #include "asm/file" not #include > > Here's a little script that converts them: > If you've actually checked that such conversions are correct and work fine, how about a patch (or patches)? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] drivers/char/... convert #include "linux/..." to #include
(untested)
There are several files that
#include "linux/file" not #include
#include "asm/file" not #include
Here's a little script that converts them:
egrep -i -r -l --include=*.[ch] \
"^[[:space:]]*\#[[:space:]]*include[[:space:]]*\"(linux|asm)/(.*)\"" * \
| xargs sed -i -e
's/^[[:space:]]*#[[:space:]]*include[[:space:]]*"\(linux\|asm\)\/\(.*
\)"/#include <\1\/\2>/g'
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/drivers/char/drm/drm_ioctl.c b/drivers/char/drm/drm_ioctl.c
index b195e10..902c4a1 100644
--- a/drivers/char/drm/drm_ioctl.c
+++ b/drivers/char/drm/drm_ioctl.c
@@ -36,7 +36,7 @@
#include "drmP.h"
#include "drm_core.h"
-#include "linux/pci.h"
+#include
/**
* Get the bus id.
diff --git a/drivers/char/pcmcia/synclink_cs.c
b/drivers/char/pcmcia/synclink_cs.c
index 2b88931..4a186ed 100644
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -87,7 +87,7 @@
#include
-#include "linux/synclink.h"
+#include
static MGSL_PARAMS default_params = {
MGSL_MODE_HDLC, /* unsigned long mode */
diff --git a/drivers/char/synclink.c b/drivers/char/synclink.c
index fdc256b..eb1d90a 100644
--- a/drivers/char/synclink.c
+++ b/drivers/char/synclink.c
@@ -114,7 +114,7 @@
#include
-#include "linux/synclink.h"
+#include
#define RCLRVALUE 0x
diff --git a/drivers/char/synclink_gt.c b/drivers/char/synclink_gt.c
index bbb7f12..cb3d061 100644
--- a/drivers/char/synclink_gt.c
+++ b/drivers/char/synclink_gt.c
@@ -81,7 +81,7 @@
#include
#include
-#include "linux/synclink.h"
+#include
#if defined(CONFIG_HDLC) || (defined(CONFIG_HDLC_MODULE) &&
defined(CONFIG_SYNCLINK_GT_MODULE))
#define SYNCLINK_GENERIC_HDLC 1
diff --git a/drivers/char/synclinkmp.c b/drivers/char/synclinkmp.c
index c63013b..726581e 100644
--- a/drivers/char/synclinkmp.c
+++ b/drivers/char/synclinkmp.c
@@ -80,7 +80,7 @@
#include
-#include "linux/synclink.h"
+#include
static MGSL_PARAMS default_params = {
MGSL_MODE_HDLC, /* unsigned long mode */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] drivers/scsi/... convert #include "linux/..." to #include
(untested) There are several files that #include "linux/file" not #include #include "asm/file" not #include Here's a little script that converts them: egrep -i -r -l --include=*.[ch] \ "^[[:space:]]*\#[[:space:]]*include[[:space:]]*\"(linux|asm)/(.*)\"" * \ | xargs sed -i -e 's/^[[:space:]]*#[[:space:]]*include[[:space:]]*"\(linux\|asm\)\/\(.*\)"/#include <\1\/\2>/g' Signed-off-by: Joe Perches <[EMAIL PROTECTED]> diff --git a/drivers/scsi/aic94xx/aic94xx_dump.c b/drivers/scsi/aic94xx/aic94xx_dump.c index 6bd8e30..ddf5f10 100644 --- a/drivers/scsi/aic94xx/aic94xx_dump.c +++ b/drivers/scsi/aic94xx/aic94xx_dump.c @@ -29,7 +29,7 @@ * */ -#include "linux/pci.h" +#include #include "aic94xx.h" #include "aic94xx_reg.h" #include "aic94xx_reg_def.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/
convert #include "linux/..." to #include [PATCH]s follow
There are several files that: #include "linux/file" not #include #include "asm/file" not #include Here's a little script that converts them: egrep -i -r -l --include=*.[ch] \ "^[[:space:]]*\#[[:space:]]*include[[:space:]]*\"(linux|asm)/(.*)\"" * \ | xargs sed -i -e 's/^[[:space:]]*#[[:space:]]*include[[:space:]]*"\(linux\|asm\)\/\(.*\)"/#include <\1\/\2>/g' Maybe a similar check could be added to checkpatch.pl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HTC as USB gprs/edge modem on linux
Hi,
bizu pisze:
> Hi,
>
> I've got an HTC P4350 running Win Mobile 5.
>
> I can synchronize data with synce, everything work fine.
>
> But i can't use it as an USB modem on linux, where as everything work
> fine on windows.
>
> To get it working with windows, i activate the 'internet share' on the
> HTC and plug it to the laptop by USB. Then a virtual network interface
> called 'Windows Mobile-base Internet Sharing Device' is mounted, its
> address is attributed by DHCP, and its speed connection is fixed to
> 10Mbps.
> And everything work fine, i can surf to the web by edge
>
>
>
> So now, let's go on linux!
> i'm on debian leeny/sid with a recompiled kernel 2.6.22.1 (see my
> config file at bottom)
> my USB Controller is:
> USB Controller: Intel Corporation 82801CA/CAM USB (Hub #1) (rev 02)
> and i use udev as device manager
>
> at boot, there are my loaded modules:
> Module Size Used by
> apm19284 2
> ipv6 234596 14
> sr_mod 15396 0
> pcmcia 37780 0
> firmware_class 9472 1 pcmcia
> ide_cd 38048 0
> e100 34316 0
> mii 5632 1 e100
> uhci_hcd 32400 0
> cdrom 35616 2 sr_mod,ide_cd
> rtc11800 0
> yenta_socket 25868 5
> rsrc_nonstatic 11136 1 yenta_socket
> pcmcia_core38288 3 pcmcia,yenta_socket,rsrc_nonstatic
> parport_pc 24740 0
> parport23616 1 parport_pc
> 8250_pnp9728 0
> usbcore 141336 2 uhci_hcd
> 8250_pci 20608 0
> 8250 22132 2 8250_pnp,8250_pci
> serial_core19840 1 8250
>
>
>
> Now i connect the HTC in modem mode:
> $> dmesg:
> usb usb1: usb resume
> usb usb1: finish resume
> hub 1-0:1.0: hub_resume
> usb usb1: wakeup_rh
> hub 1-0:1.0: state 7 ports 2 chg evt
> uhci_hcd :00:1d.0: port 1 portsc 0093,00
> hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
> hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
> usb 1-1: new full speed USB device using uhci_hcd and address 2
> usb 1-1: skipped 3 descriptors after interface
> usb 1-1: default language 0x0409
> usb 1-1: new device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-1: Product: Generic RNDIS
> usb 1-1: Manufacturer: HTC
> usb 1-1: SerialNumber: fb511207-593d-1103-a800-0050bf3f5173
> usb 1-1: uevent
> usb 1-1: usb_probe_device
> usb 1-1: configuration #1 chosen from 1 choice
> usb 1-1: adding 1-1:1.0 (config #1, interface 0)
> usb 1-1:1.0: uevent
> usb 1-1:1.0: uevent
> usb 1-1: adding 1-1:1.1 (config #1, interface 1)
> usb 1-1:1.1: uevent
> usb 1-1:1.1: uevent
> drivers/usb/core/inode.c: creating file '002'
> hub 1-0:1.0: state 7 ports 2 chg evt 0002
> usb 1-1: usb auto-suspend
> hub 1-0:1.0: hub_suspend
> usb usb1: suspend_rh
> usb usb1: usb auto-suspend
>
> I don't understand why there is a suspend action on my usb-hub
> Furthermore the HTC ask me to check the USB connexion.
>
This patch (against 2.6.23-rc3-git2) disables auto-suspend for this device.
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index b7917c5..d715d46 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -64,6 +64,8 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x05d8, 0x4005), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Agfa Snapscan1212u */
{ USB_DEVICE(0x06bd, 0x2061), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* High Tech Computer Corp. Generic RNDIS */
+ { USB_DEVICE(0x0bb4, 0x0303), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Umax [hex] Astra 3400U */
{ USB_DEVICE(0x1606, 0x0060), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sched.c: why -fno-omit-frame-pointer?
Adrian Bunk <[EMAIL PROTECTED]> writes: > > Is the -fno-omit-frame-pointer still required for some reason, or is > this a relict that could be removed? It's needed so that the WCHAN /proc display can backtrace one level up out of schedule() -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/12] Blackfin arch: Add label to call new GPIO API
On Saturday 18 August 2007, Robin Getz wrote:
> I don't see how early/late makes the problem easier/worse to debug. No matter
> when you do it - the driver refuses to install (or at least should).
If you arrange to *reliably* detect the pinmux/setup problems by
the time the system starts ""init" (early), that means one large
class of hard-to-sort problems never needs runtime troubleshooting.
Think of it this way: folk have observed that pin setup issues can
be painful to sort out. So they adopt a strategy ("failfast"/"early")
which helps surface them early and basically removes them as issues
in later debugging. I think you're hoping that by adding extra
resource tracking code, you can make that later debugging easier
even though, by "late" binding, you've introduced extra error paths.
> Right - for us - the code handing the hardware differences is easier in the
> drivers, rather than the bootloaders.
Remember that I didn't argue in favor of putting that code into
boot loaders ... I just pointed out that some product lines work
that way, so Linux needs to cope with that strategy. (One of the
many examples involves OpenFirmware device tables.)
But regardless: I can't buy any argument that it's better to put
lots of board-specific code into drivers. That adds up quickly,
making maintaining the drivers painful. "Real" updates (bugfixes,
new features, API updates, cleanup, and so on) regularly end up
in conflict with patches to support a few more boards, and board
support patches must then always involve those driver maintainers.
So merging new boards involves many more people than necessary...
> For other systems - where you can have a UART on any pin - I completely
> understand your point.
UART on any pin? Few kernels dynamically reprogram FPGAs! :)
> > Sure ... you'd need to say "this board uses "
> > and if integrated in the SOC that's often enough.
>
> with the kernel .config - that is what happens. If you have 2 serial drivers
> connected - you enable 2 serial drivers in Kconfig.
Your language is incorrect here. What your Kconfig does is
not configure two different *drivers* ... but some number of
different serial *devices* handled by the same driver.
One obvious downside of that is that making it needlessly hard
to support several boards with one kernel. As a rule, those
boards can have different serial devices, and the devices can
be configured differently. Yet you said you wanted to make it
easy to support many boards with one kernel...
> > External
> > devices need more configuration. Even for integrated ones,
> > that knowledge doesn't belong in the driver ... "which of the
> > many UARTs to use as console" isn't standard, and neither
> > is "what hardware handshaking pins are in use".
>
> When hardware handshaking pins are fixed - it sure is.
Not unless the UART for some odd reason *requires* those pins to work.
There's almost always support for pure software handshaking (XON/XOFF),
with one board option being "don't handshake". Board A might use two
pins for UART2 RTS/CTS; board B might use UART as well, but use those
two pins for another I2C bus. The differences belong in board-specific
configuration, not in drivers.
> When they are not (when
> the hardware doesn't support hardware handshaking, and you need to do it in
> software) - we still allow you do to it via Kconfig.
>
> linux-2.6.x/drivers/serial/Kconfig:
That can work, at least for *single-board* kernel builds. Of course,
that gets into territory some people will say is Kconfig abuse ...
and the need for many ugly #ifdefs is very obvious. :)
In fact one could argue that those bits of Kconfig syntax are really
just support for one Blackfin board (ezkit), and so they don't belong
in that Kconfig file or with those names...
Plus, that approach only works with fairly simple types of device glue.
It's routine to find chip hookups that can't fit smoothly into some
pre-planned Kconfig, since they require board-specific function hooks.
(Sometimes even with UARTs, but clearly not in this case.)
> Board configs are in one place - under source control - the kernel .config
And in arch/blackfin/mach-*/boards/*.c ... all that stuff you set up
in Kconfig could as easily have been coded in those files, without any
need for #ifdefs or confusing Kconfig. Still under source control,
plus it's a lot harder to break. :)
> I guess we thought it was easier for people to select a few things in config,
> rather than have to write C code/include files for board specific
> implementations options - It is like you said - everything is all in one
> place...
Doing that in Kconfig is atypical ... it may well be a bit easier to
pick up at the beginning of a developer's learning curve, but I think
it doesn't scale very well as multi-board product lines evolve.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH] rtc: Make rtc-ds1742 driver hotplug-aware
On Sun, 2007-08-19 at 21:57 +0900, Atsushi Nemoto wrote: > On Fri, 17 Aug 2007 18:32:19 +0200, "Kay Sievers" <[EMAIL PROTECTED]> wrote: > > > I guess there are some out-of-tree users of this driver, but fixing > > > them is really trivial, so I don't think this is a big compatibility > > > problem. > > > > Again, the only sane solution is to provide MODALIAS="platform:" > > from the platform bus, and adding the aliases to drivers who support > > autoloading. Modalias strings are not free-text strings, they are > > required to be prefixed by the subsystem. > > I guess your objection is to my usage of MODULE_ALIAS, right? No, I object to the concept of "platform" to disable all uevents by default, just to work around its MODALIAS misuse. The rest of the kernel works properly, and userspace has a unified way to handle events and module loading. There is absolutely no reason for "platform" to be different and break all reasonable assumptions of module-init-tools, udev and HAL. Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: group ownership of tun devices -- nonfunctional?
On Sun, 19 Aug 2007, Rene Herman wrote:
> On 08/19/2007 06:05 PM, Bodo Eggert wrote:
>
> > IMHO the check is broken:
> >
> > + if (((tun->owner != -1 &&
> > + current->euid != tun->owner) ||
> > +(tun->group != -1 &&
> > + current->egid != tun->group)) &&
> > +!capable(CAP_NET_ADMIN))
> > return -EPERM;
> >
> > It should be something like:
> >
> > + if (!((tun->owner == tun->owner) ||
> > + (tun->group == tun->group) ||
>
> ???
Argh, I edited asuming the same order of variables. Substitute
current->e{uid,gid} for one of the sides.
> > + capable(CAP_NET_ADMIN)))
> > return -EPERM;
The intended semantics is If the user is not
* the allowed user
or
* member of the allowed group
or
* cabable of CAP_NET_ADMIN
then error out. I'm asuming
Thinking about it, maybe you should check each group, not just the
effective group. In that case, my change would be still wrong. However,
I'm not going to fix this anytime soon.
--
Funny quotes:
15. I drive way too fast to worry about cholesterol.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Smack: Simplified Mandatory Access Control Kernel
On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said: > XFCE. If you can show me a security system other than SELinux which > is sufficiently flexible to secure those 2 million lines of code > along with the other 50 million lines of code found in various pieces > of software on my Debian box then I'll go put on my dunce hat and sit > in the corner. /me hands Kyle a dunce cap. :) Unfortunately, I have to agree that both AppArmor and Smack have at least the potential of qualifying as "securing the 2M lines of code". The part that Kyle forgot was what most evals these days call the "protection profile" - What's the threat model, who are you defending against, and just how good a job does it have to do? I'll posit that for a computer that is (a) not networked, (b) doesn't process sensitive information, and (c) has reasonable physical security, a security policy of "return(permitted);" for everything may be quite sufficient. (Of course, I also have boxes where "the SELinux reference policy with all the MCS extensions plus all the LSPP work" is someplace I'm trying to get to). pgpimMGzUVBKj.pgp Description: PGP signature
Re: sched.c: why -fno-omit-frame-pointer?
On Sun, 2007-08-19 at 16:17 +0200, Adrian Bunk wrote: > kernel/sched.c gets compiled with -fno-omit-frame-pointer, and this was > already done in kernel 1.0 (sic). > > Later, it has been modified to be this way only on some architectures. > > It might not be an earthshaking amount, but removing it saves some > bytes, and there's no visible breakage when running the modified kernel > on i386. > vague memory: this was needed for wchan to work properly - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at lib/list_debug.c:27!
Hi, According to dmesg, I encountered a kernel bug on my system. I'm not sure if this is the appropriate place to report this problem as this occured on a Fedora kernel. Maybe its a general problem? kernel BUG at lib/list_debug.c:27! invalid opcode: [2] SMP === = What was I doing when this happened. == I was doing a rm -rf /media/somedir/ command on a USB harddisk. This USB harddisk casing contained a flaky IDE harddisk. (smartd had been giving warnings about this drive for a while, that it was about to break doing. What happened. The rm stuck, (couldn't be killed, even with a kill -9 command). dmesg showed a kernel bug. === = Version Fedora core 7. [EMAIL PROTECTED] ~]# uname -a Linux localhost.localdomain 2.6.22.1-41.fc7 #1 SMP Fri Jul 27 18:21:43 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED] scripts]$ ./ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux localhost.localdomain 2.6.22.1-41.fc7 #1 SMP Fri Jul 27 18:21:43 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17.50.0.12-4 util-linux 2.13-pre7 mount 2.13-pre7 module-init-tools 3.3-pre11 e2fsprogs 1.39 pcmciautils014 quota-tools3.14. PPP2.4.4 Linux C Library> libc.2.6 Dynamic linker (ldd) 2.6 Procps 3.2.7 Net-tools 1.60 Kbd1.12 oprofile 0.9.2 Sh-utils 6.9 udev 113 wireless-tools 28 Modules Loaded loop ppdev tun nls_utf8 autofs4 hidp rfcomm l2cap bluetooth sunrpc nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp ipt_REJECT x_tables cpufreq_ondemand acpi_cpufreq vfat fat dm_mirror dm_multipath dm_mod video sbs button dock battery ac ipv6 sr_mod cdrom parport_pc parport snd_hda_intel snd_seq_dummy via_rhine i2c_viapro snd_seq_oss snd_seq_midi_event snd_seq serio_raw snd_seq_device rtc_cmos snd_pcm_oss mii i2c_core usb_storage snd_mixer_oss floppy pata_via shpchp snd_pcm snd_timer snd soundcore snd_page_alloc sg ahci sata_via ata_generic libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd = OOPS/kernel output kernel BUG at lib/list_debug.c:27! invalid opcode: [2] SMP last sysfs file: /block/sdf/size CPU 1 Modules linked in: loop ppdev tun nls_utf8 autofs4 hidp rfcomm l2cap bluetooth sunrpc nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp ipt_REJECT x_tables cpufreq_ondemand acpi_cpufreq vfat fat dm_mirror dm_multipath dm_mod video sbs button dock battery ac ipv6 sr_mod cdrom parport_pc parport snd_hda_intel snd_seq_dummy via_rhine i2c_viapro snd_seq_oss snd_seq_midi_event snd_seq serio_raw snd_seq_device rtc_cmos snd_pcm_oss mii i2c_core usb_storage snd_mixer_oss floppy pata_via shpchp snd_pcm snd_timer snd soundcore snd_page_alloc sg ahci sata_via ata_generic libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd Pid: 11136, comm: rm Not tainted 2.6.22.1-41.fc7 #1 RIP: 0010:[] [] __list_add+0x27/0x5b RSP: 0018:810027079de8 EFLAGS: 00010282 RAX: 0079 RBX: RCX: 0004f977 RDX: RSI: 8100076fd7c8 RDI: RBP: 81001f9029c8 R08: 0010 R09: 0010 R10: R11: R12: 810018398400 R13: 8100076fd7c8 R14: 81001f902900 R15: 810027079e08 FS: 2aae0270() GS:810001591280() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 00f183e0 CR3: 11668000 CR4: 06e0 Process rm (pid: 11136, threadinfo 810027078000, task 81000b5ff000) Stack: 810027079e08 8804303e 8100076fd7c8 81001f902990 810017fc9888 0180 0029 8803dc8e 8100072d17b8 81001f9029c8 8100076fd7c8 810017ebf9c8 Call Trace: [] :ext3:ext3_orphan_add+0x14b/0x187 [] :ext3:ext3_mark_inode_dirty+0x44/0x4d [] :ext3:ext3_unlink+0x16e/0x1d5 [] vfs_unlink+0xbc/0x102 [] do_unlinkat+0xaa/0x144 [] sys_getdents+0xaf/0xbd [] sys_fcntl+0x2d7/0x2e3 [] system_call+0x7e/0x83 Code: 0f 0b eb fe 4c 8b 00 49 39 f0 74 18 48 89 c1 4c 89 c2 48 c7 RIP [] __list_add+0x27/0x5b RSP WARNING: at kernel/exit.c:814 do_exit() (Not tainted) Call Trace: [] do_exit+0x59/0x7db [] kernel_math_error+0x0/0x71 [] do_invalid_op+0x85/0x8f [] __list_add+0x27/0x5b [] printk+0x52/0xaf [] :jbd:do_get_write_access+0x4c1/0x4f6 [] error_exit+0x0/0x84 [] __list_add+0x27/0x5b [] __list_add+0x27/0x5b []
Re: CONFIG_SUSPEND and power consumption
Hi, On Sunday, 19 August 2007 15:32, Jean Delvare wrote: > Hi all, hi Rafael, > > Running kernel 2.6.23-rc3-git1, I noticed yesterday that my CPU (AMD > Sempron 2600+) was running at a much lower temperature when > CONFIG_SUSPEND was enabled. Hm, interesting. > The temperature difference was quite significant, about 6 degrees Celsius at > idle. Measuring the power consumption of my system confirmed that the energy > savings were real: with CONFIG_SUSPEND=n, the system consumes 80 W of power > (idle), while with CONFIG_SUSPEND=y, the system consumes only 69 W (idle)! > Can anyone explain how this works? I can't. > I didn't expect CONFIG_SUSPEND to make any difference before actually > switching the system to standby or suspend state. Yes, that's the expected behavior. > I tried the same trick on two Intel motherboards I use for testing, but > this option didn't seem to make any difference in the power consumption > for these. Do you have CONFIG_HIBERNATION set? If not, please see if setting it instead of CONFIG_SUSPEND leads to the same result on the affected box (ie. running at lower temperatures). 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/
Re: [RFC,PATCH 5/5] exec: RT sub-thread can livelock and monopolize CPU on exec
> ? This becomes a busy-wait loop if the leader sleeps, wait_task_inactive() > doesn't sleep/yield in this case. Not good. Ah, I see. Yes, you're right, that will not fly. (I was thinking of the apparently forthcoming wait_task_inactive change to avoid yield, but that will still busy-wait in fact.) > This means we should put something in exit_notify(), like this patch does. > It could be simplified a bit, we don't in fact need a negative ->notify_count, > we can tolerate a false wakeup. We can even skip the "thread_group_leader()" > check for the same reason. > > (Of course, we can also add wait_queue_head_t to ->signal, but I don't think > you have this in mind). I had in mind unifying this need with what's now done by the notify_count check that's in __exit_signal. Aside from those BUG_ON's, I'm not sure de_thread really cares whether the other non-leader threads are finished self reaping, or only if they are dead. Adding some field to signal_struct for this new mechanism is certainly fine if it goes along with removing a word or two from task_struct (notify_count, group_exit_task). (The single other use overloaded on group_exit_task is for a similar need in the pre-coredump synchronization. So maybe that can be done more cleanly too.) Any new field could be kept to a single pointer; since it's only needed while one given thread is blocking, it can point to something larger on its stack if necessary. While we are considering cleaning up the exec synchronization, there is a long-standing issue it would be nice to address. That is, the race of a group fatal signal with exec. (I've mentioned this before, but never come up with an adequate solution.) As things are, one thread can be processing a fatal signal while another thread does exec (de_thread). If de_thread gets the siglock first and sets SIGNAL_GROUP_EXIT, then the fatal-signal thread will see an exit already in process and just drop its signal on the floor. But, it was not an exit at all, but really an exec. A fatal signal from shared_pending should have killed the whole process, but was swallowed. This is a POSIX violation, and potentially usable in a racy DoS exploit to let a runaway process keep exec'ing and never get killed (though probably not). An obvious path to a fix for that is to avoid overloading SIGNAL_GROUP_EXIT in de_thread. In coming up with different synchronization method we might find a way that cleans that up too. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
On Sat, 18 Aug 2007 22:20:34 PDT, Marc Perkel said: > Let me give you and example of the difference between > Linux open source world brain damaged thinking and > what it's like out here in the real world. > > Go to a directory with 10k files and type: > > rm * > > What do you get? > > /bin/rm: Argument list too long Given that you don't even understand that this message is issued by the *shell* and not /bin/rm, and *why* it issues that sort of error message when an argument string expands to be bigger than MAX_ARGV, and the fact that there are extant patches to increase that to essentially any reasonable size, why should we listen to you when you proclaim that you have any sort of enlightenment about systems design? pgp0YD9j1hMWY.pgp Description: PGP signature
Re: tracking MAINTAINERS versus tracking SUBSYSTEMS
"Robert P. J. Day" <[EMAIL PROTECTED]> writes: > i'm confused -- i thought that was sort of the whole purpose of this > exercise, to match parts of the kernel source tree against the > maintainer for those parts, and to do that via the defined > "subsystem" which is currently used in MAINTAINERS. > > you can, of course, banish the concept of a subsystem entirely and > work purely from a file and directory perspective, but i think the > notion of the kernel tree being composed of subsystems is a useful > idea. that's just my opinion, though. Obviously the concept of subsystems is the right one, except that the subsystems aren't that well defined (or they are but not for average kernel user) - thus "file masks". -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: List stripping out cc's
Jeff Garzik wrote: > Avi Kivity wrote: >> Heiko Carstens wrote: The only thing remotely relevant in the list config is that 'Filter out duplicate messages to list members (if possible)' is set as a default for new members. Maybe this means that if a cc is also part of the list, that cc is stripped (which seems a wierd implementation; I'd have expected that cc be kept and just one copy sent out). Anybody have a clue? >>> >>> I got also removed when I was cc'ed. IIRC that started when I >>> subscribed to >>> the list. So it looks like people who are subscribed to the list get >>> removed from the cc list. >>> That's very annoying btw. ;) >>> >> >> I think I see what is happening. The list gets a message that you >> are copied on. It sees you have opted not to receive duplicates, it >> strips you from the cc list, since it knows that you will receive >> another copy by direct routing (outside the list). > > Well, there is also /quite/ the problem with the Mail-Followup-To > header, which causes most mailers to ignore the preferences of the > community in favor of the preferences of the message author -- which > totally screws up traditional To/CC handling on LKML. > Sorry, this was about kvm-devel, not lkml -- I should have taken linux-kernel off the cc list here to avoid increasing confusion. Somehow that felt wrong in an email about the evils of stripping out the cc list. I don't think there's an issue with M-F-T: here. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH 5/5] exec: RT sub-thread can livelock and monopolize CPU on exec
On 08/19, Roland McGrath wrote: > > > The group_leader can sleep before it enters exit_notify(). In that case > > wait_task_inactive() returns, and we still need some polling to wait for > > EXIT_ZOMBIE. > > It could be a loop as now with yield. It's still polling, but only one > poll per wakeup of the target. I guess I misunderstand you. Do you mean de_thread: /* * Wait for the thread group leader to be a zombie. * It should already be zombie at this point, most * of the time. */ while (leader->exit_state != EXIT_ZOMBIE) wait_task_inactive(leader); ? This becomes a busy-wait loop if the leader sleeps, wait_task_inactive() doesn't sleep/yield in this case. Not good. > > Yes sure. But in any case I think we should avoid polling, we need some > > notification from exit_notify(). > > Indeed. This means we should put something in exit_notify(), like this patch does. It could be simplified a bit, we don't in fact need a negative ->notify_count, we can tolerate a false wakeup. We can even skip the "thread_group_leader()" check for the same reason. (Of course, we can also add wait_queue_head_t to ->signal, but I don't think you have this in mind). Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: List stripping out cc's
Avi Kivity wrote: Heiko Carstens wrote: The only thing remotely relevant in the list config is that 'Filter out duplicate messages to list members (if possible)' is set as a default for new members. Maybe this means that if a cc is also part of the list, that cc is stripped (which seems a wierd implementation; I'd have expected that cc be kept and just one copy sent out). Anybody have a clue? I got also removed when I was cc'ed. IIRC that started when I subscribed to the list. So it looks like people who are subscribed to the list get removed from the cc list. That's very annoying btw. ;) I think I see what is happening. The list gets a message that you are copied on. It sees you have opted not to receive duplicates, it strips you from the cc list, since it knows that you will receive another copy by direct routing (outside the list). Well, there is also /quite/ the problem with the Mail-Followup-To header, which causes most mailers to ignore the preferences of the community in favor of the preferences of the message author -- which totally screws up traditional To/CC handling on LKML. 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: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
> -Original Message- > From: David Miller [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 19, 2007 12:32 PM > To: Felix Marti > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED] > Subject: Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate > PS_TCPportsfrom the host TCP port space. > > From: "Felix Marti" <[EMAIL PROTECTED]> > Date: Sun, 19 Aug 2007 10:33:31 -0700 > > > I know that you don't agree that TSO has drawbacks, as outlined by > > Roland, but its history showing something else: the addition of TSO > > took a fair amount of time and network performance was erratic for > > multiple kernel revisions and the TSO code is sprinkled across the > > network stack. > > This thing you call "sprinkled" is a necessity of any hardware > offload when it is possible for a packet to later get "steered" > to a device which cannot perform the offload. > > Therefore we need a software implementation of TSO so that those > packets can still get output to the non-TSO-capable device. > > We do the same thing for checksum offloading. > > And for free we can use the software offloading mechanism to > get batching to arbitrary network devices, even those which cannot > do TSO. > > What benefits does RDMA infrastructure give to non-RDMA capable > devices? None? I see, that's great. > > And again the TSO bugs and issues are being overstated and, also for > the second time, these issues are more indicative of my bad > programming skills then they are of intrinsic issues of TSO. The > TSO implementation was looking for a good design, and it took me > a while to find it because I personally suck. > > Face it, stateless offloads are always going to be better in the long > term. And this is proven. > > You RDMA folks really do live in some kind of fantasy land. [Felix Marti] You're not at all addressing the fact that RDMA does solve the memory BW problem and stateless offload doesn't. Apart from that, I don't quite understand your argument with respect to the benefits of the RDMA infrastructure; what benefits does the TSO infrastructure give the non-TSO capable devices? Isn't the answer none and yet you added TSO support?! I don't think that the argument is stateless _versus_ stateful offload both have their advantages and disadvantages. Stateless offload does help, i.e. TSO/LRO do improve performance in back-to-back benchmarks. It seems me that _you_ claim that there is no benefit to statefull offload and that is where we're disagreeing; there is benefit and i.e. the much lower memory BW requirements is just one example, yet an important one. We'll probably never agree but it seems to me that we're asking only for small changes to the software stack and then we can give the choice to the end users: they can opt for stateless offload if it fits the performance needs or for statefull offload if their apps require the extra boost in performance. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH 5/5] exec: RT sub-thread can livelock and monopolize CPU on exec
> The group_leader can sleep before it enters exit_notify(). In that case > wait_task_inactive() returns, and we still need some polling to wait for > EXIT_ZOMBIE. It could be a loop as now with yield. It's still polling, but only one poll per wakeup of the target. > Yes sure. But in any case I think we should avoid polling, we need some > notification from exit_notify(). Indeed. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add all thread stats for TASKSTATS_CMD_ATTR_TGID
TASKSTATS_CMD_ATTR_TGID used to return only the delay accounting stats,
not the basic and extended accounting. With this patch,
TASKSTATS_CMD_ATTR_TGID returns also the min, max or sum (depending on
the semantic of the field) of the accounting info for all threads of a
thread group. This makes TASKSTATS_CMD_ATTR_TGID usable in a similar
fashion to TASKSTATS_CMD_ATTR_PID, for commands like iotop -P
(http://guichaz.free.fr/misc/iotop.py).
Changelog since V1 (http://lkml.org/lkml/2007/8/2/185):
- Update combined stats of exited threads in fill_tgid_exit() as
suggested by Balbir Singh.
- Very light cleanup of fill_tgid_exit() by the way.
- bacct fields are also combined for all threads.
- Instead of assuming memory stats are identical for all threads, we
take the max of all threads (hiwater_rss and hiwater_vm).
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <[EMAIL PROTECTED]>
---
kernel/taskstats.c | 15 ++-
kernel/tsacct.c| 43 ++-
2 files changed, 32 insertions(+), 26 deletions(-)
diff -r 73eff559debc kernel/taskstats.c
--- a/kernel/taskstats.cSat Aug 18 17:15:17 2007 -0700
+++ b/kernel/taskstats.cSun Aug 19 17:20:15 2007 +0200
@@ -246,6 +246,8 @@ static int fill_tgid(pid_t tgid, struct
stats->nvcsw += tsk->nvcsw;
stats->nivcsw += tsk->nivcsw;
+ bacct_add_tsk(stats, tsk);
+ xacct_add_tsk(stats, tsk);
} while_each_thread(first, tsk);
unlock_task_sighand(first, );
@@ -265,21 +267,24 @@ static void fill_tgid_exit(struct task_s
static void fill_tgid_exit(struct task_struct *tsk)
{
unsigned long flags;
+ struct taskstats *tg_stats;
spin_lock_irqsave(>sighand->siglock, flags);
- if (!tsk->signal->stats)
+ tg_stats = tsk->signal->stats;
+ if (!tg_stats)
goto ret;
/*
* Each accounting subsystem calls its functions here to
* accumalate its per-task stats for tsk, into the per-tgid structure
*
-* per-task-foo(tsk->signal->stats, tsk);
-*/
- delayacct_add_tsk(tsk->signal->stats, tsk);
+* per-task-foo(tg_stats, tsk);
+*/
+ bacct_add_tsk(tg_stats, tsk);
+ xacct_add_tsk(tg_stats, tsk);
+ delayacct_add_tsk(tg_stats, tsk);
ret:
spin_unlock_irqrestore(>sighand->siglock, flags);
- return;
}
static int add_del_listener(pid_t pid, cpumask_t *maskp, int isadd)
diff -r 73eff559debc kernel/tsacct.c
--- a/kernel/tsacct.c Sat Aug 18 17:15:17 2007 -0700
+++ b/kernel/tsacct.c Sun Aug 19 17:20:43 2007 +0200
@@ -38,8 +38,9 @@ void bacct_add_tsk(struct taskstats *sta
/* rebase elapsed time to usec */
ac_etime = timespec_to_ns();
do_div(ac_etime, NSEC_PER_USEC);
- stats->ac_etime = ac_etime;
- stats->ac_btime = get_seconds() - ts.tv_sec;
+ stats->ac_etime = max_t(u64, stats->ac_etime, ac_etime);
+ stats->ac_btime = min_t(u32, stats->ac_btime,
+ get_seconds() - ts.tv_sec);
if (thread_group_leader(tsk)) {
stats->ac_exitcode = tsk->exit_code;
if (tsk->flags & PF_FORKNOEXEC)
@@ -60,10 +61,12 @@ void bacct_add_tsk(struct taskstats *sta
stats->ac_ppid = pid_alive(tsk) ?
rcu_dereference(tsk->real_parent)->tgid : 0;
rcu_read_unlock();
- stats->ac_utime = cputime_to_msecs(tsk->utime) * USEC_PER_MSEC;
- stats->ac_stime = cputime_to_msecs(tsk->stime) * USEC_PER_MSEC;
- stats->ac_minflt = tsk->min_flt;
- stats->ac_majflt = tsk->maj_flt;
+ stats->ac_utime = max_t(u64, stats->ac_utime,
+cputime_to_msecs(tsk->utime) * USEC_PER_MSEC);
+ stats->ac_stime = max_t(u64, stats->ac_stime,
+cputime_to_msecs(tsk->stime) * USEC_PER_MSEC);
+ stats->ac_minflt = max_t(u64, stats->ac_minflt, tsk->min_flt);
+ stats->ac_majflt = max_t(u64, stats->ac_majflt, tsk->maj_flt);
strncpy(stats->ac_comm, tsk->comm, sizeof(stats->ac_comm));
}
@@ -81,27 +84,25 @@ void xacct_add_tsk(struct taskstats *sta
struct mm_struct *mm;
/* convert pages-jiffies to Mbyte-usec */
- stats->coremem = jiffies_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
- stats->virtmem = jiffies_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
+ stats->coremem += jiffies_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
+ stats->virtmem += jiffies_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
mm = get_task_mm(p);
if (mm) {
/* adjust to KB unit */
- stats->hiwater_rss = mm->hiwater_rss * PAGE_SIZE / KB;
- stats->hiwater_vm= mm->hiwater_vm * PAGE_SIZE / KB;
+ stats->hiwater_rss =
Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
From: "Felix Marti" <[EMAIL PROTECTED]> Date: Sun, 19 Aug 2007 10:33:31 -0700 > I know that you don't agree that TSO has drawbacks, as outlined by > Roland, but its history showing something else: the addition of TSO > took a fair amount of time and network performance was erratic for > multiple kernel revisions and the TSO code is sprinkled across the > network stack. This thing you call "sprinkled" is a necessity of any hardware offload when it is possible for a packet to later get "steered" to a device which cannot perform the offload. Therefore we need a software implementation of TSO so that those packets can still get output to the non-TSO-capable device. We do the same thing for checksum offloading. And for free we can use the software offloading mechanism to get batching to arbitrary network devices, even those which cannot do TSO. What benefits does RDMA infrastructure give to non-RDMA capable devices? None? I see, that's great. And again the TSO bugs and issues are being overstated and, also for the second time, these issues are more indicative of my bad programming skills then they are of intrinsic issues of TSO. The TSO implementation was looking for a good design, and it took me a while to find it because I personally suck. Face it, stateless offloads are always going to be better in the long term. And this is proven. You RDMA folks really do live in some kind of fantasy land. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
