[PPC64] Remove nested feature sections
Andrew, please apply:
The {BEGIN,END}_FTR_SECTION asm macros used in ppc64 to nop out
sections of code at runtime cannot be nested. However, we do nest
them in hash_low.S. We get away with it there, because there is
nothing between the BEGIN markers for each section. However, that's
confusing to someone reading the code.
This patch removes the nested ifset and ifclr feature sections,
replacing them with a single feature section in the full mask/value
form.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/arch/ppc64/mm/hash_low.S
===
--- working-2.6.orig/arch/ppc64/mm/hash_low.S 2005-07-26 10:36:48.0
+1000
+++ working-2.6/arch/ppc64/mm/hash_low.S2005-07-26 17:35:49.0
+1000
@@ -129,12 +129,10 @@
* code rather than call a C function...)
*/
BEGIN_FTR_SECTION
-BEGIN_FTR_SECTION
mr r4,r30
mr r5,r7
bl .hash_page_do_lazy_icache
-END_FTR_SECTION_IFSET(CPU_FTR_NOEXECUTE)
-END_FTR_SECTION_IFCLR(CPU_FTR_COHERENT_ICACHE)
+END_FTR_SECTION(CPU_FTR_NOEXECUTE|CPU_FTR_COHERENT_ICACHE, CPU_FTR_NOEXECUTE)
/* At this point, r3 contains new PP bits, save them in
* place of "access" in the param area (sic)
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: Assume PM Timer to be reliable on broken board/BIOS
On Tue, 2005-07-26 at 17:34 -0600, Robert Hancock wrote: > > In a nutshell, sometimes, the PIT/TSC timer runs 3x too fast [1]. That > > causes many issues, including DMA errors, MCE, and clock running way too > > fast (making the laptop unusable for any software development). So far, > > no BIOS update was able to fix the issue for me. > > Shouldn't this be looked into further rather than adding this > workaround? Surely Windows is using the PIT as well, so there must be > some way to get it to behave properly.. Surely, but I've been desesperatly trying to find the cause w/out success for months. My first idea was that the BIOS doesn't set the CPU voltage properly at boot, so I made up a patch that sets the right fid/vid before any calibration but that didn't help. The BIOS is wrong (ie the BIOS reports a 1/3 of the actual CPU speed), memtest86+ which doesn't use any ACPI or whatever reports wrong time too, so it's definitely not a Linux bug. My guess is that Windows reinitialize some register but it's hard to tell. Cheers, Olivier. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: define-auxiliary-vector-size-at_vector_size.patch added to -mm tree
"H. J. Lu" <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 26, 2005 at 09:53:23PM -0700, Andrew Morton wrote: > > "H. J. Lu" <[EMAIL PROTECTED]> wrote: > > > > > > My patch breaks x86_64 build. This patch will fix x86_64 build. I am > > > also enclosing the updated full patch. > > > > It now breaks ppc64 > > > > include/asm/elf.h: In function `dump_task_regs': > > include/asm/elf.h:177: error: dereferencing pointer to incomplete type > > > > That's because pt_regs isn't known, because sched.h is including elf.h > > before pt_regs gets defined. This is a pretty fragile area I'm afraid. > > Should we creat a new header file like auxvector.h? Auxiliary isn't > ELF specific anyway. That would 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/
Re: define-auxiliary-vector-size-at_vector_size.patch added to -mm tree
On Tue, Jul 26, 2005 at 09:53:23PM -0700, Andrew Morton wrote: > "H. J. Lu" <[EMAIL PROTECTED]> wrote: > > > > My patch breaks x86_64 build. This patch will fix x86_64 build. I am > > also enclosing the updated full patch. > > It now breaks ppc64 > > include/asm/elf.h: In function `dump_task_regs': > include/asm/elf.h:177: error: dereferencing pointer to incomplete type > > That's because pt_regs isn't known, because sched.h is including elf.h > before pt_regs gets defined. This is a pretty fragile area I'm afraid. Should we creat a new header file like auxvector.h? Auxiliary isn't ELF specific anyway. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: define-auxiliary-vector-size-at_vector_size.patch added to -mm tree
"H. J. Lu" <[EMAIL PROTECTED]> wrote: > > My patch breaks x86_64 build. This patch will fix x86_64 build. I am > also enclosing the updated full patch. It now breaks ppc64 include/asm/elf.h: In function `dump_task_regs': include/asm/elf.h:177: error: dereferencing pointer to incomplete type That's because pt_regs isn't known, because sched.h is including elf.h before pt_regs gets defined. This is a pretty fragile area I'm afraid. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12 sound problem
On Tue, 2005-07-26 at 19:35 -0400, Stephen Clark wrote: > Additional info I don't see any interrupts in /proc/interrupts for the > Allegro which is on int 5. > I just tried the same laptop with knoppix and a 2.4.27 kernel and sound > works great and I do > see interrupts for Allegro on int 5. So the same ALSA driver works on 2.6 but fails on 2.4? Or are you really saying 2.4 + the OSS driver works and 2.6 + ALSA does not? Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kernel optimization
On Wed, 2005-07-27 at 06:53 +0300, Al Boldi wrote: > Gettimeofday loops using gcc-3.2.2 on 2.4.31 and 2.6.12. > > Also, 2.4 is faster than 2.6! All this proves is that gettimeofday() is faster on 2.4 than 2.6. Hardly surprising. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kernel optimization
Adrian Bunk wrote: {
On Tue, Jul 26, 2005 at 08:22:59AM +0300, Al Boldi wrote:
> Dr. Horst H. von Brand wrote: {
> Al Boldi <[EMAIL PROTECTED]> wrote:
> > Adrian Bunk wrote: {
> > On Fri, Jul 22, 2005 at 07:55:48PM +0100, christos gentsis wrote:
> > > i would like to ask if it possible to change the optimization of the
> > > kernel from -O2 to -O3 :D, how can i do that? if i change it to the
> > > top level Makefile does it change to all the Makefiles?
> > And since it's larger, it's also slower.
> > }
>
> > It's faster but it's flawed. Root-NFS boot failed!
>
> How do you know that it is faster if it is busted?
> }
>
> The -O3 compile produces a faster kernel, which seems to work perfectly,
> albeit the Root-NFS boot flaw!
How did you measure that you that your -O3 kernel isn't slower?
}
Gettimeofday loops using gcc-3.2.2 on 2.4.31 and 2.6.12.
Also, 2.4 is faster than 2.6!
Try this:
#define __USE_GNU
#include
#include
unsigned long elapsed(int start) {
static struct timeval s,e;
if (start) return gettimeofday(, NULL);
gettimeofday(, NULL);
return ((e.tv_sec - s.tv_sec) * 1000 + (e.tv_usec - s.tv_usec) /
1000);
}
int main(int argc, char *argv[]) {
int i;
elapsed(1);
for (i = 0; elapsed(0) < 100; i++) {
int ret = i;
if (ret > i)
break;
else if (ret < 0) {
perror("not here");
break;
}
ret++;
}
printf("Elapsed: %lu in %lums %lu/ms",i,elapsed(0),i/elapsed(0));
int tmo=i;
elapsed(1);
for (i = 0; i < 100*tmo ; i++) {
int ret = i;
if (ret > i)
break;
else if (ret < 0) {
perror("not here");
break;
}
ret++;
}
printf(" - %lu/ms",i/elapsed(0));
elapsed(1);
for (i = 0; i < 100*tmo ; i++);
printf(" - %lu/ms\n",i/elapsed(0));
return 0;
}
--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Weird USB errors on HD
On Tue, 26 Jul 2005 20:34:10 -0600, Robert Hancock <[EMAIL PROTECTED]> wrote: >Karim Yaghmour wrote: >> That being said, shouldn't there be a way for the kernel to refuse to >> use this hd if it's not getting enough power. I don't know enough about >> USB to say, but isn't there something more elegant that could be done in >> software? > >Not really.. It seems like pretty much a matter of the controller saying > it can supply so much power, the drive says it uses so much power, but >one of them is lying and the drive ends up tripping the overcurrent. The drive itself may shutdown until power cycled. I sorted this issue some months ago with a 2.5" 6GB drive in USB enclosure and the fix was hardware, adding bypass capacitors to supply peak HDD current. Software cannot fix that. No dataloss, just apparent lockup from OS point of view. Drive fails to work on one laptop with a single USB port, but asking for 700mA from a 500mA USB port is too much, needs external 5V instead. Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question re the dot releases such as 2.6.12.3
On Tuesday 26 July 2005 21:50, Steven Rostedt wrote: >On Tue, 2005-07-26 at 21:28 -0400, Kurt Wall wrote: >> On Mon, Jul 25, 2005 at 12:38:43PM -0400, Brian Gerst took 21 lines to write: >> > Gene Heskett wrote: >> > >Greetings; >> > > >> > >I just built what I thought was 2.6.12.3, but my script got a >> > > tummy ache because I didn't check the Makefile's >> > > EXTRA_VERSION, which was set to .2 in the .2 patch. Now my >> > > 2.6.12 modules will need a refresh build. :( >> > > >> > >So whats the proper patching sequence to build a 2.6.12.3? >> > >> > The dot-release patches are not incremental. You apply each one >> > to the base 2.6.12 tree. >> >> This bit me a while back, too. I'll submit a patch to the >> top-level README to spell it out. > >Someone should also fix the home page of kernel.org. Since there's > no link on that page that points to the full 2.6.12. Since a lot of > the patches on that page go directly against the 2.6.12 kernel and > not 2.6.12.3, it would be nice to get the full source of that > kernel from the home page. > Apparently you are useing a browser to suck that stuff? Use gftp and walk right up the dir structure to it. Its not hidden at all that way. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] schedule obsolete OSS drivers for removal
On Tuesday 26 July 2005 14:13, Adrian Bunk wrote: >On Tue, Jul 26, 2005 at 01:03:39PM -0400, Gene Heskett wrote: >> On Tuesday 26 July 2005 11:48, Jeff Garzik wrote: >> >Adrian Bunk wrote: >> >> This patch schedules obsolete OSS drivers (with ALSA drivers >> >> that support the same hardware) for removal. [...] >> >ACK for via82cxxx. >> >> I'm still running a box that needs this one. The darned thing >> refuses to die. :) >>... > >Why doesn't the ALSA driver work for you? Humm, I missread that it was OSS you were talking about, my bad. I'll go quietly officer. :( -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] NETCONSOLE must depend on INET
From: Matt Mackall <[EMAIL PROTECTED]> Date: Tue, 26 Jul 2005 19:36:37 -0700 > [sch added to cc: as I think he's the effective pktgen maintainer] No, that would be Robert Olsson. > Move in_aton from net/ipv4/utils.c to net/core/utils.c Fair enough. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with SMP and NCCH-DL motherboard
Hi Again, I've done some further tests disabling hyperthreading which then lets me disable apic on the motherboard and when I disable these I can boot a kernel compiled with smp, however it boots detecting only 1 cpu rather than the 2 on the motherboard. If I then reenable APIC in the bios with hyperthreading still disabled it fails in the same way, so the problem seems to be with APIC. Any ideas what more I can try? Thanks in advance!! Pedro Pedro Pla wrote: >Hello, > >I'm running a system with an Asus NCCH-DL motherboard with dual Nocona >Xeon 3.2 GHZ cpu's, when I boot the system with a single cpu kernel with >acpi not compiled in it works fine, however when I try to boot a kernel >with smp it gives a timeout detecting the cpus and then the machine >reboots after I think trying to work out the irq tables, I say I think >because it happens so fast that I can barely see what is on the screen >before it reboots. > >I've tried recompiling the kernel with many different options both in >and out and the only one that lets me boot is a single cpu without acpi, >apic and hpet, I tried googling for similar problems but haven't been >able to find anything that applies. I've also tried using an EM64T >kernel in case it had to do with the Nocona being incompatible with smp >in 32bit mode but that didn't seem to work and gave the same error. > >Is it a kernel problem or a hardware issue? I tried swapping cpu's in >case one was broken but that didn't help, I also tried flashing the bios >to the latest one from Asus in case there was some issue with that but >no luck either. > >Also in case this is helpful in locating the problem, when I get it to >boot a single cpu 2.6.12.1 kernel without acpi or apic I get the >following errors with the PCI: > >NET: Registered protocol family 16 >PCI: PCI BIOS revision 2.10 entry at 0xf1d30, last bus=4 >PCI: Using configuration type 1 >SCSI subsystem initialized >PCI: Probing PCI hardware >PCI: Probing PCI hardware (bus 00) >PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 >Boot video device is :01:00.0 >PCI: Transparent bridge - :00:1e.0 >PCI: Using IRQ router PIIX/ICH [8086/25a1] at :00:1f.0 >PCI: IRQ 0 for device :00:1f.1 doesn't match PIRQ mask - try >pci=usepirqmask >PCI: Found IRQ 11 for device :00:1f.1 >PCI: Cannot allocate resource region 0 of device :01:00.0 > >Any ideas or advice would be greatly appreciated. > >Best regards, >Pedro > > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird USB errors on HD
Karim Yaghmour wrote: That being said, shouldn't there be a way for the kernel to refuse to use this hd if it's not getting enough power. I don't know enough about USB to say, but isn't there something more elegant that could be done in software? Not really.. It seems like pretty much a matter of the controller saying it can supply so much power, the drive says it uses so much power, but one of them is lying and the drive ends up tripping the overcurrent. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: [2.6 patch] NETCONSOLE must depend on INET
[sch added to cc: as I think he's the effective pktgen maintainer]
On Tue, Jul 26, 2005 at 05:03:49PM -0700, David S. Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Tue, 26 Jul 2005 16:58:24 -0700
>
> > On Tue, Jul 26, 2005 at 04:32:02PM -0700, David S. Miller wrote:
> > > More seriously, please submit a version of whatever you
> > > believe to be the more correct fix so it can be reviewed
> > > and integrated.
> >
> > Do you have a preferred location to put this function or
> > shall I invent one?
>
> I actually can't wait to see where you're going to
> to put a function that transforms "IPV4 addresses"
> from ascii other than some place protected by CONFIG_INET.
> :-)
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 6cdd6f36d53678a016cfbf5ce667cbd91504d538
# Parent 75716ae25f9d87ee2a5ef7c4df2d8f86e0f3f762
Move in_aton from net/ipv4/utils.c to net/core/utils.c
Move in_aton to allow netpoll and pktgen to work without the rest of
the IPv4 stack. Fix whitespace and add comment for the odd placement.
Delete now-empty net/ipv4/utils.c
Re-enable netpoll/netconsole without CONFIG_INET
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
diff -r 75716ae25f9d -r 6cdd6f36d536 drivers/net/Kconfig
--- a/drivers/net/Kconfig Tue Jul 26 23:21:24 2005
+++ b/drivers/net/Kconfig Wed Jul 27 02:31:24 2005
@@ -2544,7 +2544,7 @@
config NETCONSOLE
tristate "Network console logging support (EXPERIMENTAL)"
- depends on NETDEVICES && INET && EXPERIMENTAL
+ depends on NETDEVICES && EXPERIMENTAL
---help---
If you want to log kernel messages over the network, enable this.
See for details.
diff -r 75716ae25f9d -r 6cdd6f36d536 net/core/utils.c
--- a/net/core/utils.c Tue Jul 26 23:21:24 2005
+++ b/net/core/utils.c Wed Jul 27 02:31:24 2005
@@ -23,9 +23,9 @@
#include
#include
+#include
#include
#include
-
/*
This is a maximally equidistributed combined Tausworthe generator
@@ -153,3 +153,38 @@
EXPORT_SYMBOL(net_random);
EXPORT_SYMBOL(net_ratelimit);
EXPORT_SYMBOL(net_srandom);
+
+/*
+ * Convert an ASCII string to binary IP.
+ * This is outside of net/ipv4/ because various code that uses IP addresses
+ * is otherwise not dependent on the TCP/IP stack.
+ */
+
+__u32 in_aton(const char *str)
+{
+ unsigned long l;
+ unsigned int val;
+ int i;
+
+ l = 0;
+ for (i = 0; i < 4; i++)
+ {
+ l <<= 8;
+ if (*str != '\0')
+ {
+ val = 0;
+ while (*str != '\0' && *str != '.')
+ {
+ val *= 10;
+ val += *str - '0';
+ str++;
+ }
+ l |= val;
+ if (*str != '\0')
+ str++;
+ }
+ }
+ return(htonl(l));
+}
+
+EXPORT_SYMBOL(in_aton);
diff -r 75716ae25f9d -r 6cdd6f36d536 net/ipv4/Makefile
--- a/net/ipv4/Makefile Tue Jul 26 23:21:24 2005
+++ b/net/ipv4/Makefile Wed Jul 27 02:31:24 2005
@@ -2,7 +2,7 @@
# Makefile for the Linux TCP/IP (INET) layer.
#
-obj-y := utils.o route.o inetpeer.o protocol.o \
+obj-y := route.o inetpeer.o protocol.o \
ip_input.o ip_fragment.o ip_forward.o ip_options.o \
ip_output.o ip_sockglue.o \
tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o \
diff -r 75716ae25f9d -r 6cdd6f36d536 net/ipv4/utils.c
--- a/net/ipv4/utils.c Tue Jul 26 23:21:24 2005
+++ /dev/null Wed Jul 27 02:31:24 2005
@@ -1,59 +0,0 @@
-/*
- * INETAn implementation of the TCP/IP protocol suite for the
LINUX
- * operating system. INET is implemented using the BSD Socket
- * interface as the means of communication with the user level.
- *
- * Various kernel-resident INET utility functions; mainly
- * for format conversion and debugging output.
- *
- * Version:$Id: utils.c,v 1.8 2000/10/03 07:29:01 anton Exp $
- *
- * Author: Fred N. van Kempen, <[EMAIL PROTECTED]>
- *
- * Fixes:
- * Alan Cox: verify_area check.
- * Alan Cox: removed old debugging.
- * Andi Kleen : add net_ratelimit()
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include
-#include
-#include
-
-/*
- * Convert an ASCII string to binary IP.
- */
-
-__u32 in_aton(const char *str)
-{
- unsigned long l;
- unsigned int val;
- int i;
-
- l = 0;
- for (i = 0; i < 4; i++)
- {
- l <<= 8;
- if (*str != '\0')
-
Re: Question re the dot releases such as 2.6.12.3
On Tue, 26 Jul 2005 21:50:50 EDT, Steven Rostedt said: > Someone should also fix the home page of kernel.org. Since there's no > link on that page that points to the full 2.6.12. Since a lot of the > patches on that page go directly against the 2.6.12 kernel and not > 2.6.12.3, it would be nice to get the full source of that kernel from > the home page. Even more to the point - when 2.6.13 comes out, there will be a patch against 2.6.12, not 2.6.12.N, which means you get to download the 2.6.12.N tarball, the 2.6.12.N patch, patch -R that, and *then* apply the 2.6.13 patch. Blegga. :) pgp7HDY7VNRKF.pgp Description: PGP signature
Re: [patch 2.6.13-rc3] i386: clean up user_mode macros
On Mon, 25 Jul 2005 at 16:13:13 -0700 (PDT), Linus Torvalds wrote:
> On Mon, 25 Jul 2005, Chuck Ebbert wrote:
> >
> > Recent patches from the Xen group changed the X86 user_mode macros.
> >
> > This patch does the following:
> >
> > 1. Makes the new user_mode() return 0 or 1 (same as x86_64)
>
> I _really_ prefer
>
> x != 0
>
> over
>
> !!x
Take 2: compile tested only.
Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
===
--- 2.6.13-rc3.orig/include/asm-i386/ptrace.h
+++ 2.6.13-rc3/include/asm-i386/ptrace.h
@@ -57,14 +57,21 @@
#ifdef __KERNEL__
struct task_struct;
extern void send_sigtrap(struct task_struct *tsk, struct pt_regs *regs, int
error_code);
-#define user_mode(regs)(3 & (regs)->xcs)
-#define user_mode_vm(regs) ((VM_MASK & (regs)->eflags) || user_mode(regs))
+
+static inline int user_mode(struct pt_regs *regs)
+{
+ return (regs->xcs & 3) != 0;
+}
+static inline int user_mode_vm(struct pt_regs *regs)
+{
+ return ((regs->xcs & 3) | (regs->eflags & VM_MASK)) != 0;
+}
#define instruction_pointer(regs) ((regs)->eip)
#if defined(CONFIG_SMP) && defined(CONFIG_FRAME_POINTER)
extern unsigned long profile_pc(struct pt_regs *regs);
#else
#define profile_pc(regs) instruction_pointer(regs)
#endif
-#endif
+#endif /* __KERNEL__ */
#endif
__
Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Question re the dot releases such as 2.6.12.3
On Tue, 2005-07-26 at 21:28 -0400, Kurt Wall wrote: > On Mon, Jul 25, 2005 at 12:38:43PM -0400, Brian Gerst took 21 lines to write: > > Gene Heskett wrote: > > >Greetings; > > > > > >I just built what I thought was 2.6.12.3, but my script got a tummy > > >ache because I didn't check the Makefile's EXTRA_VERSION, which was > > >set to .2 in the .2 patch. Now my 2.6.12 modules will need a refresh > > >build. :( > > > > > >So whats the proper patching sequence to build a 2.6.12.3? > > > > > > > The dot-release patches are not incremental. You apply each one to the > > base 2.6.12 tree. > > This bit me a while back, too. I'll submit a patch to the top-level > README to spell it out. Someone should also fix the home page of kernel.org. Since there's no link on that page that points to the full 2.6.12. Since a lot of the patches on that page go directly against the 2.6.12 kernel and not 2.6.12.3, it would be nice to get the full source of that kernel from the home page. If I want to incremently build the 2.6.13-rc3-mm1, would I need to download the 2.6.12 tar ball, followed by the 2.6.13-rc3 patch and then the 2.6.13-rc3-mm1 patch and apply them that way? If so, I can get all the patches but the starting point. Yes I could also download the full version of any of these, but it still seems to make sense to include the starting point of the patches on the home page. Just a thought, -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
> I don't think so. We're getting the wrong answer out of > calculate_zone_totalpages() which is an init-time thing. > > Maybe nr_free_zone_pages() is supposed to fix that up post-facto somehow, > but calculate_zone_totalpages() sure as heck shouldn't be putting 1568768 > into my ZONE_NORMAL's ->node_present_pages. Humpf. I'll look at it again later. nr_free_pagecache_pages -> nr_free_zone_pages -> nr_free_zone_pages is it not? M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> > This machine only has 4G of memory, so the platform code is overestimating
> > the number of pages by 50%. Can you please check your dmesg, see if your
> > system is also getting this wrong?
>
>
>
> On node 0 totalpages: 1572863
> DMA zone: 4096 pages, LIFO batch:1
> Normal zone: 1568767 pages, LIFO batch:31
> HighMem zone: 0 pages, LIFO batch:1
> On node 1 totalpages: 131071
> DMA zone: 0 pages, LIFO batch:1
> Normal zone: 131071 pages, LIFO batch:31
> HighMem zone: 0 pages, LIFO batch:1
> On node 2 totalpages: 131071
> DMA zone: 0 pages, LIFO batch:1
> Normal zone: 131071 pages, LIFO batch:31
> HighMem zone: 0 pages, LIFO batch:1
> On node 3 totalpages: 131071
> DMA zone: 0 pages, LIFO batch:1
> Normal zone: 131071 pages, LIFO batch:31
> HighMem zone: 0 pages, LIFO batch:1
That's 7.7GB, yes? On a 6GB machine?
If so, that's a bit off, but not grossly.
Here's the dopey debug patch which I used:
- boot
- dmesg -s 100 | grep total_pages > foo
- kill off syslogd (sudo service syslog stop)
- run the dd command
- wait for it to hit steady state (max dirty memory)
- dmesg -s 100 >> foo
diff -puN mm/page-writeback.c~a mm/page-writeback.c
--- 25/mm/page-writeback.c~a2005-07-26 15:53:46.0 -0700
+++ 25-akpm/mm/page-writeback.c 2005-07-26 16:21:55.0 -0700
@@ -161,7 +161,8 @@ get_dirty_limits(struct writeback_state
dirty_ratio = vm_dirty_ratio;
if (dirty_ratio > unmapped_ratio / 2)
dirty_ratio = unmapped_ratio / 2;
-
+ printk("vm_dirty_ratio=%d unmapped_ratio=%d dirty_ratio=%d\n",
+ vm_dirty_ratio, unmapped_ratio, dirty_ratio);
if (dirty_ratio < 5)
dirty_ratio = 5;
@@ -171,6 +172,8 @@ get_dirty_limits(struct writeback_state
background = (background_ratio * available_memory) / 100;
dirty = (dirty_ratio * available_memory) / 100;
+ printk("dirty_ratio=%d available_memory=%lu dirty=%lu\n",
+ dirty_ratio, available_memory, dirty);
tsk = current;
if (tsk->flags & PF_LESS_THROTTLE || rt_task(tsk)) {
background += background / 4;
@@ -209,6 +212,12 @@ static void balance_dirty_pages(struct a
get_dirty_limits(, _thresh,
_thresh, mapping);
nr_reclaimable = wbs.nr_dirty + wbs.nr_unstable;
+ printk("background_thresh=%ld dirty_thresh=%ld "
+ "nr_dirty=%ld nr_unstable=%ld "
+ "nr_reclaimable=%ld wbs.nr_writeback=%ld\n",
+ background_thresh, dirty_thresh,
+ wbs.nr_dirty, wbs.nr_unstable,
+ nr_reclaimable, wbs.nr_writeback);
if (nr_reclaimable + wbs.nr_writeback <= dirty_thresh)
break;
@@ -532,6 +541,8 @@ void __init page_writeback_init(void)
total_pages = nr_free_pagecache_pages();
+ printk("total_pages=%ld\n", total_pages);
+
correction = (100 * 4 * buffer_pages) / total_pages;
if (correction < 100) {
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
> Since fxsave leaves the FPU state intact, there ought to be a better way
> to do this but it gets tricky. Maybe using the TSC to put a timestamp
> in every thread save area?
>
> when saving FPU state:
> put cpu# and timestamp in thread state info
> also store timestamp in per-cpu data
>
> on task switch:
> compare cpu# and timestamps for next task
> if equal, clear TS and set TS_USEDFPU
>
> when state becomes invalid for some reason:
> zero cpu's timestamp
>
> But the extra overhead might be too much in many cases.
Simpler:
- Thread has "CPU that I last used FPU on" pointer. Never NULL.
- Each CPU has "thread whose FPU state I hold" pointer. May be NULL.
When *loading* FPU state:
- Set up both pointers.
On task switch:
- If the pointers point to each other, then clear TS and skip restore.
("Preloaded")
When state becomes invalid (kernel MMX use, or whatever)
- Set CPU's pointer to NULL.
On thread creation:
- If current CPU's thread pointer points to the newly allocated thread,
clear it to NULL.
- Set thread's CPU pointer to current CPU.
The UP case just omits the per-thread CPU pointer. (Well, stores
it in zero bits.)
An alternative SMP thread-creation case would be to have a NULL value for
the thread-to-CPU pointer and initialize the thread's CPU pointer to that,
but that then complicates the UP case.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc2] pci: restore BAR values from pci_set_power_state for D3hot->D0
On Tue, Jul 26, 2005 at 04:49:34PM -0700, Greg KH wrote:
> On Fri, Jul 08, 2005 at 02:34:56PM -0400, John W. Linville wrote:
> > @@ -301,6 +335,16 @@ pci_set_power_state(struct pci_dev *dev,
> > udelay(200);
> > dev->current_state = state;
> >
> > + /* According to section 5.4.1 of the "PCI BUS POWER MANAGEMENT
> > +* INTERFACE SPECIFICATION, REV. 1.2", a device transitioning
> > +* from D3hot to D0 _may_ perform an internal reset, thereby
> > +* going to "D0 Uninitialized" rather than "D0 Initialized".
> > +* In that case, we need to restore at least the BARs so that
> > +* the device will be accessible to its driver.
> > +*/
> > + if (need_restore)
> > + pci_restore_bars(dev);
> > +
>
> This code doesn't even build, as need_restore isn't a global variable.
Hmmm...you must be missing this hunk from the patch posted on July 8?
@@ -239,7 +270,7 @@ pci_find_parent_resource(const struct pc
int
pci_set_power_state(struct pci_dev *dev, pci_power_t state)
{
- int pm;
+ int pm, need_restore = 0;
u16 pmcsr, pmc;
/* bound the state we're entering */
> Care to redo this patch (and merge it with your other one) and resend
> it?
I'll be happy to do so, and include the other comment tweaks that
Grant requested. I should get to it tomorrow morning.
Thanks,
John
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add text for dealing with "dot releases" to README
The emergence of so-called "dot releases" that are non-incremental patches against a base kernel requires different handling of patches (revert previous patches before applying the newest one). This patch adds a paragrach to $TOPDIR/README explaining how to do deal with dot release patches. The patch is against 2.6.12.3. A possibly too quick glance at MAINTAINERS didn't show one for README. Signed-off-by: Kurt Wall <[EMAIL PROTECTED]> --- linux-2.6.12.3/README 2005-07-26 21:18:18.0 -0400 +++ b/README2005-07-26 21:25:13.0 -0400 @@ -87,6 +87,16 @@ kernel source. Patches are applied from the current directory, but an alternative directory can be specified as the second argument. + - If you are upgrading between releases using the stable series patches + (for example, patch-2.6.xx.y), note that these "dot-releases" are + not incremental and must be applied to the 2.6.xx base tree. For + example, if your base kernel is 2.6.12 and you want to apply the + 2.6.12.3 patch, you do not and indeed must not first apply the + 2.6.12.1 and 2.6.12.2 patches. Similarly, if you are running kernel + version 2.6.12.2 and want to jump to 2.6.12.3, you must first + reverse the 2.6.12.2 patch (that is, patch -R) _before_ applying + the 2.6.12.3 patch. + - Make sure you have no stale .o files and dependencies lying around: cd linux -- The first myth of management is that it exists. The second myth of management is that success equals skill. -- Robert Heller - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
On Tue, 2005-07-26 at 17:31 -0700, Andrew Morton wrote: > Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > > > On Tue, 2005-07-26 at 16:07 -0700, Andrew Morton wrote: > > > Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > > > > > > > Here is the data with 5 ext2 filesystems. I also collected > > /proc/meminfo > > > > every 5 seconds. As you can see, we seem to dirty 6GB of data in 20 > > > > seconds of starting the test. I am not sure if its bad, since we have > > > > lots of free memory.. > > > > > > It's bad. The logic in balance_dirty_pages() should block those write() > > > callers as soon as we hit 40% dirty memory or whatever is in > > > /proc/sys/vm/dirty_ratio. So something is horridly busted. > > > > > > Can you try reducing the number of filesystems even further? > > > > Single ext2 filesystem. We still dirty pretty quickly (data collected > > every 5 seconds). > > It happens here, a bit. My machine goes up to 60% dirty when it should be > clamping at 40%. > > The variable `total_pages' in page-writeback.c (from > nr_free_pagecache_pages()) is too high. I trace it back to here: > > On node 0 totalpages: 1572864 > DMA zone: 4096 pages, LIFO batch:1 > Normal zone: 1568768 pages, LIFO batch:31 > HighMem zone: 0 pages, LIFO batch:1 > > This machine only has 4G of memory, so the platform code is overestimating > the number of pages by 50%. Can you please check your dmesg, see if your > system is also getting this wrong? On node 0 totalpages: 1572863 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 1568767 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 On node 1 totalpages: 131071 DMA zone: 0 pages, LIFO batch:1 Normal zone: 131071 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 On node 2 totalpages: 131071 DMA zone: 0 pages, LIFO batch:1 Normal zone: 131071 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 On node 3 totalpages: 131071 DMA zone: 0 pages, LIFO batch:1 Normal zone: 131071 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question re the dot releases such as 2.6.12.3
On Mon, Jul 25, 2005 at 12:38:43PM -0400, Brian Gerst took 21 lines to write: > Gene Heskett wrote: > >Greetings; > > > >I just built what I thought was 2.6.12.3, but my script got a tummy > >ache because I didn't check the Makefile's EXTRA_VERSION, which was > >set to .2 in the .2 patch. Now my 2.6.12 modules will need a refresh > >build. :( > > > >So whats the proper patching sequence to build a 2.6.12.3? > > > > The dot-release patches are not incremental. You apply each one to the > base 2.6.12 tree. This bit me a while back, too. I'll submit a patch to the top-level README to spell it out. Kurt -- You cannot propel yourself forward by patting yourself on the back. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>
>
> > It happens here, a bit. My machine goes up to 60% dirty when it should be
> > clamping at 40%.
> >
> > The variable `total_pages' in page-writeback.c (from
> > nr_free_pagecache_pages()) is too high. I trace it back to here:
> >
> > On node 0 totalpages: 1572864
> > DMA zone: 4096 pages, LIFO batch:1
> > Normal zone: 1568768 pages, LIFO batch:31
> > HighMem zone: 0 pages, LIFO batch:1
> >
> > This machine only has 4G of memory, so the platform code is overestimating
> > the number of pages by 50%. Can you please check your dmesg, see if your
> > system is also getting this wrong?
>
> I think we're repeatedly iterating over the same zones by walking the
> zonelists:
>
> static unsigned int nr_free_zone_pages(int offset)
> {
> pg_data_t *pgdat;
> unsigned int sum = 0;
> int i;
>
> for_each_pgdat(pgdat) {
> struct zone *zone;
>
> for (i = 0; i < MAX_NR_ZONES; i++) {
> unsigned long size, high;
>
> zone = pgdat->node_zones[i];
> size = zone->present_pages;
> high = zone->pages_high;
>
> if (size > high)
> sum += size - high;
> }
> }
> }
I don't think so. We're getting the wrong answer out of
calculate_zone_totalpages() which is an init-time thing.
Maybe nr_free_zone_pages() is supposed to fix that up post-facto somehow,
but calculate_zone_totalpages() sure as heck shouldn't be putting 1568768
into my ZONE_NORMAL's ->node_present_pages.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
> It happens here, a bit. My machine goes up to 60% dirty when it should be
> clamping at 40%.
>
> The variable `total_pages' in page-writeback.c (from
> nr_free_pagecache_pages()) is too high. I trace it back to here:
>
> On node 0 totalpages: 1572864
> DMA zone: 4096 pages, LIFO batch:1
> Normal zone: 1568768 pages, LIFO batch:31
> HighMem zone: 0 pages, LIFO batch:1
>
> This machine only has 4G of memory, so the platform code is overestimating
> the number of pages by 50%. Can you please check your dmesg, see if your
> system is also getting this wrong?
I think we're repeatedly iterating over the same zones by walking the
zonelists:
static unsigned int nr_free_zone_pages(int offset)
{
pg_data_t *pgdat;
unsigned int sum = 0;
int i;
for_each_pgdat(pgdat) {
struct zone *zone;
for (i = 0; i < MAX_NR_ZONES; i++) {
unsigned long size, high;
zone = pgdat->node_zones[i];
size = zone->present_pages;
high = zone->pages_high;
if (size > high)
sum += size - high;
}
}
}
Does that look more sensible? I'd send you a real patch, except the
box just crashed ;-)
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
Andrew Morton wrote: Michael Krufky <[EMAIL PROTECTED]> wrote: However, sometimes there are patches in -mm that are incompatable with -linus. An example of this is "Pavel's pm_message_t mangling" ... OK. The way I handle an exceptional case like that is to merge the -linus-compatible patch into -mm and then have another patch on top of that which fixes things up for the -mm tree. Later, that patch gets folded into your patch if Pavel's stuff gets merged. Or gets dropped if it doesn't get merged. Or gets folded into Pavel's stuff if your patch goes in first. IOW: for a bunch of reasons we really do want to make the "fix up V4l for -mm differences" patch be a separate patch file. And I very much prefer that people work against -linus and when these things occasionally pop up I'll just fix stuff up. It's only if someone is explicitly working against a patch which is only in -mm that they should have to care about -mm vs -linus differences. I think you may have misunderstood me here. v4l didnt make the patches... You (akpm) did... We included them in our cvs when you merged them into -mm: add-type-checking-to-pm_message_t-bttv-fix.patch added to -mm tree add-type-checking-to-pm_message_t-tuner-core-fix.patch added to -mm tree add-type-checking-to-pm_message_t-msp-fix.patch added to -mm tree add-type-checking-to-pm_message_t-tda9887-fix.patch added to -mm tree Trust me, nobody did anything wrong here, and everything that needs to be done with regards to this is already done, AFAIK. I'm just saying it would be handy for the cvs to be able to compile separately with both -mm and -linus trees automatically. I just sent you a patch that solves the issue. -- Michael Krufky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
Michael Krufky <[EMAIL PROTECTED]> wrote: > > Andrew Morton wrote: > > >Michael Krufky <[EMAIL PROTECTED]> wrote: > > > > > >>[ tracking mm stuff ] > >> > >> > While we're on the topic of how -mm works, I have a question for you. > How can I test a kernel source tree (during compilation) to determine > whether it is a -mm tree or a -linus tree? > > I will give you an example of what I am trying to do: > > video4linux cvs is backwards compatible with older 2.6 kernels. We keep > backwards compatibility so that users can install newer device drivers > without having to compile an entire kernel. There are things like: > > #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13) > > ...all over the code that allows it to compile cleanly with many > different versions. Our patching scripts eliminate these "compatibility > tests" from the source when building patches, and only presents the code > compatible with the correct kernel version, so this doesn't interfere > with development or the patching process. I'd really rather not have to get into that level of divergence. Usually, patches in -mm should be directly applicable to -linus. > However, sometimes there are patches in -mm that are incompatable with > -linus. An example of this is "Pavel's pm_message_t mangling" ... OK. The way I handle an exceptional case like that is to merge the -linus-compatible patch into -mm and then have another patch on top of that which fixes things up for the -mm tree. Later, that patch gets folded into your patch if Pavel's stuff gets merged. Or gets dropped if it doesn't get merged. Or gets folded into Pavel's stuff if your patch goes in first. IOW: for a bunch of reasons we really do want to make the "fix up V4l for -mm differences" patch be a separate patch file. And I very much prefer that people work against -linus and when these things occasionally pop up I'll just fix stuff up. It's only if someone is explicitly working against a patch which is only in -mm that they should have to care about -mm vs -linus differences. > Testing for the numbered 2.6.x version isn't enough of a test in a case > like this, but it would be nice to be able to develop against the most > recent version of both the -mm tree and the -linus tree without having > to revert patches. Of course, v4l has chosen to maintain compatibility > with -mm, for the sake of patch generation, and I have a handy > -linus-compat.patch on the side for now if I want to build cvs against > -linus, until Pavel's patches get merged later on. But I'm sure things > like this must happen all the time. How do others deal with issues like > these automatically? > > It doesn't matter which -mm version or which -linus version it is... I > can already test for 2.6.x ... All that matters is if it is -mm or > -linus. If there isn't already an answer to this question, maybe you > can create a /linux/.mm file, or something like that. A Makefile can > test for the presence of that file... or is there already a file present > that is unique to the -mm tree? Well, if you really, really, really feel a need to do this then feel free to send along a patch which does whatever you need it to do. But as I say, I'd prefer that you be raising patches against -linus and testing them in -mm. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
Michael Krufky wrote: However, sometimes there are patches in -mm that are incompatable with -linus. An example of this is "Pavel's pm_message_t mangling" ... Testing for the numbered 2.6.x version isn't enough of a test in a case like this, but it would be nice to be able to develop against the most recent version of both the -mm tree and the -linus tree without having to revert patches. Of course, v4l has chosen to maintain compatibility with -mm, for the sake of patch generation, and I have a handy -linus-compat.patch on the side for now if I want to build cvs against -linus, until Pavel's patches get merged later on. But I'm sure things like this must happen all the time. How do others deal with issues like these automatically? It doesn't matter which -mm version or which -linus version it is... I can already test for 2.6.x ... All that matters is if it is -mm or -linus. If there isn't already an answer to this question, maybe you can create a /linux/.mm file, or something like that. A Makefile can test for the presence of that file... or is there already a file present that is unique to the -mm tree? Here's a patch, if you so choose to go this route. This should NEVER be merged to -linus ;-) Signed-off-by: Michael Krufky <[EMAIL PROTECTED]> diff -upN a/.mm b/.mm --- a/.mm 1970-01-01 00:00:00.0 + +++ b/.mm 2005-07-26 20:57:41.0 + @@ -0,0 +1 @@ +1
RE: [2.6.13-rc3-git4] VIA686A polymorphs into VIA586!
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>Giancarlo Formicuccia
>Sent: Tuesday, July 26, 2005 2:09 PM
>To: Aleksey Gorelov
>Cc: linux-kernel@vger.kernel.org
>Subject: Re: [2.6.13-rc3-git4] VIA686A polymorphs into VIA586!
>
>Does this patch look good for you?
>Who's the right developer to ask for inclusion? I'd like to
>see this problem addressed before 2.6.13...
Yep, this is better. Please add appropriate patch description &
Signed-off-by and resend it to Greg and Andrew.
Aleks.
>
>Thanks,
>Giancarlo
>
>
>--- linux-2.6.13-git4/arch/i386/pci/irq.c.org 2005-07-23
>11:15:12.0 +0200
>+++ linux-2.6.13-git4/arch/i386/pci/irq.c 2005-07-26
>20:53:11.0 +0200
>@@ -550,6 +550,13 @@
> static __init int via_router_probe(struct irq_router *r,
>struct pci_dev *router, u16 device)
> {
> /* FIXME: We should move some of the quirk fixup stuff here */
>+
>+ if (router->device == PCI_DEVICE_ID_VIA_82C686 &&
>+ device == PCI_DEVICE_ID_VIA_82C586_0) {
>+ /* Asus k7m bios wrongly reports 82C686A as
>586-compatible */
>+ device = PCI_DEVICE_ID_VIA_82C686;
>+ }
>+
> switch(device)
> {
> case PCI_DEVICE_ID_VIA_82C586_0:
>-
>To unsubscribe from this list: send the line "unsubscribe
>linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
Andrew Morton wrote: Michael Krufky <[EMAIL PROTECTED]> wrote: [ tracking mm stuff ] While we're on the topic of how -mm works, I have a question for you. How can I test a kernel source tree (during compilation) to determine whether it is a -mm tree or a -linus tree? I will give you an example of what I am trying to do: video4linux cvs is backwards compatible with older 2.6 kernels. We keep backwards compatibility so that users can install newer device drivers without having to compile an entire kernel. There are things like: #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13) ...all over the code that allows it to compile cleanly with many different versions. Our patching scripts eliminate these "compatibility tests" from the source when building patches, and only presents the code compatible with the correct kernel version, so this doesn't interfere with development or the patching process. However, sometimes there are patches in -mm that are incompatable with -linus. An example of this is "Pavel's pm_message_t mangling" ... Testing for the numbered 2.6.x version isn't enough of a test in a case like this, but it would be nice to be able to develop against the most recent version of both the -mm tree and the -linus tree without having to revert patches. Of course, v4l has chosen to maintain compatibility with -mm, for the sake of patch generation, and I have a handy -linus-compat.patch on the side for now if I want to build cvs against -linus, until Pavel's patches get merged later on. But I'm sure things like this must happen all the time. How do others deal with issues like these automatically? It doesn't matter which -mm version or which -linus version it is... I can already test for 2.6.x ... All that matters is if it is -mm or -linus. If there isn't already an answer to this question, maybe you can create a /linux/.mm file, or something like that. A Makefile can test for the presence of that file... or is there already a file present that is unique to the -mm tree? -- Michael Krufky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/23] Don't export machine_restart, machine_halt, or machine_power_off.
On Tue, 26 Jul 2005, Eric W. Biederman wrote: > > I suspect a call to panic would be more appropriate there. Absolutely. Then the sysadmin can say whether they want reboot-on-panic behaviour or not. A filesystem should definitely _not_ decide to reboot the machine. Ever. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > On Tue, 2005-07-26 at 16:07 -0700, Andrew Morton wrote: > > Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > > > > > Here is the data with 5 ext2 filesystems. I also collected /proc/meminfo > > > every 5 seconds. As you can see, we seem to dirty 6GB of data in 20 > > > seconds of starting the test. I am not sure if its bad, since we have > > > lots of free memory.. > > > > It's bad. The logic in balance_dirty_pages() should block those write() > > callers as soon as we hit 40% dirty memory or whatever is in > > /proc/sys/vm/dirty_ratio. So something is horridly busted. > > > > Can you try reducing the number of filesystems even further? > > Single ext2 filesystem. We still dirty pretty quickly (data collected > every 5 seconds). It happens here, a bit. My machine goes up to 60% dirty when it should be clamping at 40%. The variable `total_pages' in page-writeback.c (from nr_free_pagecache_pages()) is too high. I trace it back to here: On node 0 totalpages: 1572864 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 1568768 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 This machine only has 4G of memory, so the platform code is overestimating the number of pages by 50%. Can you please check your dmesg, see if your system is also getting this 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: [PATCH 6/23] Don't export machine_restart, machine_halt, or machine_power_off.
[EMAIL PROTECTED] (Eric W. Biederman) wrote: > > Marc Ballarin <[EMAIL PROTECTED]> writes: > > > On Tue, 26 Jul 2005 11:36:01 -0600 > > [EMAIL PROTECTED] (Eric W. Biederman) wrote: > > > >> > >> machine_restart, machine_halt and machine_power_off are machine > >> specific hooks deep into the reboot logic, that modules > >> have no business messing with. Usually code should be calling > >> kernel_restart, kernel_halt, kernel_power_off, or > >> emergency_restart. So don't export machine_restart, > >> machine_halt, and machine_power_off so we can catch buggy users. > > > > The first is reiser4 in fs/reiser4/vfs_ops.c, line 1338. > > (Are filesystems supposed to restart the machine at all?!) > > I suspect a call to panic would be more appropriate there. > That's all stuff which the reiser4 team are supposed to be removing, so I'll add this patch to -mm for now just to keep things happy, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: define-auxiliary-vector-size-at_vector_size.patch added to -mm tree
On Tue, Jul 26, 2005 at 02:46:20PM -0700, [EMAIL PROTECTED] wrote:
>
> The patch titled
>
> Define auxiliary vector size, AT_VECTOR_SIZE
>
> has been added to the -mm tree. Its filename is
>
> define-auxiliary-vector-size-at_vector_size.patch
>
> Patches currently in -mm which might be from [EMAIL PROTECTED] are
>
> define-auxiliary-vector-size-at_vector_size.patch
>
>
My patch breaks x86_64 build. This patch will fix x86_64 build. I am
also enclosing the updated full patch.
H.J.
--- linux/arch/x86_64/ia32/ia32_binfmt.c.auxv 2005-07-08 11:50:04.0
-0700
+++ linux/arch/x86_64/ia32/ia32_binfmt.c2005-07-26 16:13:58.312017331
-0700
@@ -9,6 +9,7 @@
#include
#include
#include
+#define __ASM_X86_64_ELF_H 1
#include
#include
#include
@@ -181,10 +182,7 @@ struct elf_prpsinfo
#define user user32
-#define __ASM_X86_64_ELF_H 1
#define elf_read_implies_exec(ex, have_pt_gnu_stack) (!(have_pt_gnu_stack))
-//#include
-#include
typedef struct user_i387_ia32_struct elf_fpregset_t;
typedef struct user32_fxsr_struct elf_fpxregset_t;
--- linux/arch/x86_64/ia32/ia32_binfmt.c.auxv 2005-07-08 11:50:04.0
-0700
+++ linux/arch/x86_64/ia32/ia32_binfmt.c2005-07-26 16:13:58.312017331
-0700
@@ -9,6 +9,7 @@
#include
#include
#include
+#define __ASM_X86_64_ELF_H 1
#include
#include
#include
@@ -181,10 +182,7 @@ struct elf_prpsinfo
#define user user32
-#define __ASM_X86_64_ELF_H 1
#define elf_read_implies_exec(ex, have_pt_gnu_stack) (!(have_pt_gnu_stack))
-//#include
-#include
typedef struct user_i387_ia32_struct elf_fpregset_t;
typedef struct user32_fxsr_struct elf_fpxregset_t;
--- linux/include/linux/elf.h.auxv 2005-03-01 23:37:49.0 -0800
+++ linux/include/linux/elf.h 2005-07-26 16:13:24.185651900 -0700
@@ -181,6 +181,8 @@ typedef __s64 Elf64_Sxword;
#define AT_SECURE 23 /* secure mode boolean */
+#define AT_VECTOR_SIZE 42 /* Size of auxiliary table. */
+
typedef struct dynamic{
Elf32_Sword d_tag;
union{
--- linux/include/linux/sched.h.auxv2005-07-08 11:50:09.0 -0700
+++ linux/include/linux/sched.h 2005-07-26 16:13:24.204648764 -0700
@@ -35,6 +35,8 @@
#include
#include
+#include /* For AT_VECTOR_SIZE */
+
struct exec_domain;
/*
@@ -243,7 +245,7 @@ struct mm_struct {
mm_counter_t _rss;
mm_counter_t _anon_rss;
- unsigned long saved_auxv[42]; /* for /proc/PID/auxv */
+ unsigned long saved_auxv[AT_VECTOR_SIZE]; /* for /proc/PID/auxv */
unsigned dumpable:1;
cpumask_t cpu_vm_mask;
Re: [patch] properly stop devices before poweroff
[EMAIL PROTECTED] wrote: > > Andrew Morton wrote: > > "Luck, Tony" <[EMAIL PROTECTED]> wrote: > > > > > > I started on my OLS homework from Andrew ... and began looking > > > into what is going on here. > > > > > > > Thanks ;) I guess we'll end up with a better kernel, even though you appear > > to be an innocent victim here. > > The "Badness in iosapic_unregister_intr at arch/ia64/kernel/iosapic.c:851" > messages are caused by a missing call to free_irq() in the mpt/fusion driver. > I think that it should go here ... but someone with a clue should verify: > > diff --git a/drivers/message/fusion/mptbase.c > b/drivers/message/fusion/mptbase.c > --- a/drivers/message/fusion/mptbase.c > +++ b/drivers/message/fusion/mptbase.c > @@ -1384,6 +1384,8 @@ mpt_suspend(struct pci_dev *pdev, pm_mes > /* Clear any lingering interrupt */ > CHIPREG_WRITE32(>chip->IntStatus, 0); > > + free_irq(ioc->pci_irq, ioc); > + > pci_disable_device(pdev); > pci_set_power_state(pdev, device_state); > OK, great. Pavel, can you check this over please? > But even this doesn't fix the hang during shutdown :-( > > The remaining problem is cause by the order of the calls in sys_reboot: > > device_suspend(PMSG_SUSPEND); > device_shutdown(); > > The call to device_suspend() shuts down the mpt/fusion driver. But then > device_shutdown() calls sd_shutdown() which prints: > > Synchronizing SCSI cache for disk sdb > > and then calls sd_sync_cache(). Now since we suspended mpt/fusion, this is > going to go nowhere. > > I don't know how to fix this. Re-ordering the suspend & shutdown just looks > wrong. Again, Pavel has been working on this code and might be able to suggest something which is appropriate for 2.6.13... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/6] remove PageReserved
Kumar Gala wrote: Most of the arch code is just reserved memory reporting, which isn't very interesting and could easily be removed. Some arch users are a bit more subtle, however they *should not* break, because all the places that set and clear PageReserved are basically intact. What is the desired fix look like for arch users? It really depends on how it is used. Firstly, we want to retain all the places that do SetPageReserved and ClearPageReserved to ensure that remaining places that test PageReserved will continue to work. So users of PageReserved need to be removed. For example, on i386 this is simply reserved memory accounting - which isn't very meaningful and can probably be simply deleted. i386 ioremap also tests PageReserved to ensure it isn't remapping usable RAM, which is a similar need to swsusp's, so one solution would likely cover that ioremap and swsusp. For now, the main thing to keep in mind is to not add a new user of PageReserved. We can start looking at how to cut down existing users when the core patch gets into -mm or further upstream. Nick Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/23] Don't export machine_restart, machine_halt, or machine_power_off.
Marc Ballarin <[EMAIL PROTECTED]> writes: > On Tue, 26 Jul 2005 11:36:01 -0600 > [EMAIL PROTECTED] (Eric W. Biederman) wrote: > >> >> machine_restart, machine_halt and machine_power_off are machine >> specific hooks deep into the reboot logic, that modules >> have no business messing with. Usually code should be calling >> kernel_restart, kernel_halt, kernel_power_off, or >> emergency_restart. So don't export machine_restart, >> machine_halt, and machine_power_off so we can catch buggy users. > > The first is reiser4 in fs/reiser4/vfs_ops.c, line 1338. > (Are filesystems supposed to restart the machine at all?!) I suspect a call to panic would be more appropriate there. I actually missed this one as I generated the patches against Linus's latest tree. Are we in process context where we can afford to do a clean shutdown of the machine? I would have expected an error handling path to not be able to do better than emergency_restart. Regardless a panic sounds much more appropriate and will let the action taken depend on the users policy. 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] properly stop devices before poweroff
Andrew Morton wrote: > "Luck, Tony" <[EMAIL PROTECTED]> wrote: > > > > I started on my OLS homework from Andrew ... and began looking > > into what is going on here. > > > > Thanks ;) I guess we'll end up with a better kernel, even though you appear > to be an innocent victim here. The "Badness in iosapic_unregister_intr at arch/ia64/kernel/iosapic.c:851" messages are caused by a missing call to free_irq() in the mpt/fusion driver. I think that it should go here ... but someone with a clue should verify: diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c --- a/drivers/message/fusion/mptbase.c +++ b/drivers/message/fusion/mptbase.c @@ -1384,6 +1384,8 @@ mpt_suspend(struct pci_dev *pdev, pm_mes /* Clear any lingering interrupt */ CHIPREG_WRITE32(>chip->IntStatus, 0); + free_irq(ioc->pci_irq, ioc); + pci_disable_device(pdev); pci_set_power_state(pdev, device_state); But even this doesn't fix the hang during shutdown :-( The remaining problem is cause by the order of the calls in sys_reboot: device_suspend(PMSG_SUSPEND); device_shutdown(); The call to device_suspend() shuts down the mpt/fusion driver. But then device_shutdown() calls sd_shutdown() which prints: Synchronizing SCSI cache for disk sdb and then calls sd_sync_cache(). Now since we suspended mpt/fusion, this is going to go nowhere. I don't know how to fix this. Re-ordering the suspend & shutdown just looks wrong. -Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
Radoslaw "AstralStorm" Szkodzinski <[EMAIL PROTECTED]> wrote: > > On Tue, 26 Jul 2005 16:35:21 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > I did? > > > > Exactly, I did untar it and I already had a directory called patches. > Of course cleaning it up took no time, as fortunately I had no patches with > exactly the same name and no series file in the directory above, > hmm, I'll replace patches/ with broken-out/ to make those files the same as the broken-out.tar.gz from -mm releases. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.4.31 panics on boot on 486 box: TSC requires pentium
On Tue, Jul 26, 2005 at 08:22:58PM +0200, [EMAIL PROTECTED] wrote:
> 2.4.31 compiled with -m486, panics on boot (486DX) and says something about
> TSC requires pentium, bang.
The processor type is wrong, you're on at least a pentium instead of a 486.
If you changed the config by hand (vi .config), you must do "make oldconfig"
after, to propagate values along the options.
> enabling the obscure flag
>
> [*] Unsynced TSC support
>
> seems to fix this - the corresponding .config label name is actually *more*
> helpful than the documentation.
Seems to me that it simply disables use of TSC. But if you see this option,
it means that your kernel has been compiled with SMP enabled, which is not
possible on 486 (I may be wrong here). Most probably, you took a config from
an inadequate kernel for your machine.
> - Obscure-sound-bug
> jazz16 on Travelmate 4000M doesn't seem to work either, sb.o
> complains about DSP version being "only" 3.01.
>
> (#insmod sb type=10 io=0x220 irq={5,7} dma=1 dma16=7)
>
> there is sound but mpg123 says 44100 is impossible.
mpg123 requires at least around 486 DX4-100 to play mp3 at 44100, so
perhaps it fails a self-test and complains because of that ?
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
Andrew Morton said: > Radoslaw "AstralStorm" Szkodzinski <[EMAIL PROTECTED]> wrote: >> >> On Tue, 26 Jul 2005 16:11:49 -0700 >> Andrew Morton <[EMAIL PROTECTED]> wrote: >> >> > >> > All done - let me know if it needs anything else. >> > >> >> You got me with a tarball w/o a directory inside. Now I have to clean >> up the mess. >> Not the first time in life. I think I'll never learn. :) > > I did? I thought that he meant without a top-level directory... > bix:/home/akpm/.mm> tar tvfj broken-out-2005-07-26-15-07.tar.bz2 | head > -rw-r--r-- akpm/akpm 35426 2005-07-26 15:10:32 series > -rw-r--r-- akpm/akpm593326 2005-07-26 12:46:37 patches/linus.patch > -rw-r--r-- akpm/akpm 3076 2005-07-16 14:28:43 > patches/i2c-mpc-restore-code-removed.patch > -rw-r--r-- akpm/akpm 888 2005-07-16 14:28:45 > patches/really-__nocast-annotate-kmalloc_node.patch > -rw-r--r-- akpm/akpm 3071 2005-07-26 00:37:34 > patches/mips-fbdev-kconfig-fix.patch > -rw-r--r-- akpm/akpm 4097 2005-07-26 00:37:34 > patches/max_user_rt_prio-and-max_rt_prio-are-wrong.patch > -rw-r--r-- akpm/akpm 2053 2005-07-26 00:39:53 > patches/md-when-resizing-an-array-we-need-to-update-resync_max_sectors-as-well-as-size.patch > -rw-r--r-- akpm/akpm 946 2005-07-26 00:39:55 > patches/uml-readd-missing-define-to-arch-um-makefile-i386.patch -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] NETCONSOLE must depend on INET
From: Matt Mackall <[EMAIL PROTECTED]> Date: Tue, 26 Jul 2005 16:58:24 -0700 > On Tue, Jul 26, 2005 at 04:32:02PM -0700, David S. Miller wrote: > > More seriously, please submit a version of whatever you > > believe to be the more correct fix so it can be reviewed > > and integrated. > > Do you have a preferred location to put this function or > shall I invent one? I actually can't wait to see where you're going to to put a function that transforms "IPV4 addresses" from ascii other than some place protected by CONFIG_INET. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 16:35:21 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > I did? > Exactly, I did untar it and I already had a directory called patches. Of course cleaning it up took no time, as fortunately I had no patches with exactly the same name and no series file in the directory above, -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpcNiBSpWL7C.pgp Description: PGP signature
Re: [2.6 patch] NETCONSOLE must depend on INET
On Tue, Jul 26, 2005 at 04:32:02PM -0700, David S. Miller wrote: > From: Matt Mackall <[EMAIL PROTECTED]> > Date: Tue, 26 Jul 2005 16:20:43 -0700 > > > This problem also exists in PKTGEN. And this fix is incorrect as > > neither is dependent on the IP part of the networking stack in any > > substantive way. The right fix is to make inet_aton available outside > > of CONFIG_INET (preferred) or making private copies of inet_aton. > > Adrian posted a fix, you whine, that's why Adrian's fix > went in :-) Adrian's fix is the moral equivalent of throwing in a cast to shut up a compiler warning for a legitimate bug. > More seriously, please submit a version of whatever you > believe to be the more correct fix so it can be reviewed > and integrated. Do you have a preferred location to put this function or shall I invent one? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/23] Don't export machine_restart, machine_halt, or machine_power_off.
On Tue, 26 Jul 2005 11:36:01 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > > machine_restart, machine_halt and machine_power_off are machine > specific hooks deep into the reboot logic, that modules > have no business messing with. Usually code should be calling > kernel_restart, kernel_halt, kernel_power_off, or > emergency_restart. So don't export machine_restart, > machine_halt, and machine_power_off so we can catch buggy users. The first is reiser4 in fs/reiser4/vfs_ops.c, line 1338. (Are filesystems supposed to restart the machine at all?!) Patch not tested properly, since this seems to be in error handling code, but compiles und runs fine. --- linux-2.6.13-rc3-mm1/fs/reiser4/vfs_ops.c.orig 2005-07-27 01:41:41.326382750 +0200 +++ linux-2.6.13-rc3-mm1/fs/reiser4/vfs_ops.c 2005-07-27 01:42:56.783098500 +0200 @@ -1335,7 +1335,7 @@ reiser4_internal void reiser4_handle_err sb->s_flags |= MS_RDONLY; break; case 2: - machine_restart(NULL); + kernel_restart(NULL); } } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [swsusp] encrypt suspend data for easy wiping
On Wed, Jul 27, 2005 at 01:12:49AM +0200, Pavel Machek wrote: > Hi! > > > > Well, "how long are my keys going to stay in swap after > > > swsusp"... that's pretty scary. > > > > Either they're likely in RAM _anyway_ and are thus already trivially > > accessible to the attacker (for things like dm_crypt or IPSEC or > > ssh-agent), or the application took care to zero them out, or the > > application has a security bug. > > > > There are about 4 attack cases, in order of likelihood: > > > > 1) An attacker steals your suspended laptop. He has access to all your > > suspended data. This patch gets us exactly nothing. > > Wrong. Without this Andreas' patch, he'll get access to your > half-a-year-old GPG passphrases, too. Ok, I'll revise that to "very close to nothing". See below. > > 2) An attacker breaks into your machine remotely while you're using > > it. He has access to all your RAM, which if you're actually using it, > > very likely including the same IPSEC, dm_crypt, and ssh-agent keys as > > are saved on suspend. Further, he can trivially capture your > > keystrokes and thus capture any keys you use from that point forward. > > This patch gets us very close to nothing. > > > > 3) An attacker steals your unsuspended laptop. He has access to all > > your RAM, which in all likelihood includes your IPSEC, dm_crypt, and > > ssh-agent keys. Odds are good that he invokes swsusp by closing the > > laptop. This patch gets us very close to nothing. > > > > 4) You suspend your laptop between typing your GPG key password and > > hitting enter, thus leaving your password in memory when it would > > otherwise be cleared. Then you resume your laptop and hit enter, thus > > clearing the password from RAM but leaving it on the suspend > > partition. Then an attacker steals your machine (without re-suspending > > it!) and manages to recover the swsusp image which contains the > > Why without resuspending it? Position of critical data in swap is > pretty much random. Typical swap partition sizes are about the same as RAM sizes. So the odds of any given thing in a previous suspend getting overwritten by the next one are high. > What I'm worried is: attacker steals your laptop after you were using > swsusp for half a year. Now your swap partition contains random pieces > of GPG keys you were using for last half a year. That's bad. And it's incredibly unlikely. Suspending while a supposedly short-lived key is in RAM should be rare. Surviving on disk after half a year of swapping and suspending should be negligible probability. It's not worth even thinking about when we have real suspended laptops getting stolen every day in REAL LIFE. Anyone who cares about your highly contrived case also cares about 1000 times more about the real life case of the stolen laptop. Otherwise they're fooling themselves. This code is bad. It attacks a very rare problem, gives its users (and apparently its authors) a false sense of security, reimplements dm_crypt functionality apparently without much attention to the subtleties of block device encryption and without serious review, and it stands in the way of doing things right. If we're going to encrypt the suspend image, let's do it right. Let's cover the real life cases and reuse code that's intended for this purpose. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc2] pci: restore BAR values from pci_set_power_state for D3hot->D0
On Fri, Jul 08, 2005 at 02:34:56PM -0400, John W. Linville wrote: > @@ -301,6 +335,16 @@ pci_set_power_state(struct pci_dev *dev, > udelay(200); > dev->current_state = state; > > + /* According to section 5.4.1 of the "PCI BUS POWER MANAGEMENT > + * INTERFACE SPECIFICATION, REV. 1.2", a device transitioning > + * from D3hot to D0 _may_ perform an internal reset, thereby > + * going to "D0 Uninitialized" rather than "D0 Initialized". > + * In that case, we need to restore at least the BARs so that > + * the device will be accessible to its driver. > + */ > + if (need_restore) > + pci_restore_bars(dev); > + This code doesn't even build, as need_restore isn't a global variable. Care to redo this patch (and merge it with your other one) and resend it? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ppc32: Fix building of TQM8260 board
Added missing include of cpm2.h in correct order to allow TQM8260 to build Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- commit 2fd8dd75c93a89c465a08d1d0085772cad225927 tree b322bf8a4e146fe7c88e39eac88bc923ac1a567e parent ca451627946729719d17b7e6c1376ec273a501b5 author Kumar K. Gala <[EMAIL PROTECTED]> Tue, 26 Jul 2005 18:43:16 -0500 committer Kumar K. Gala <[EMAIL PROTECTED]> Tue, 26 Jul 2005 18:43:16 -0500 arch/ppc/platforms/tqm8260_setup.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/ppc/platforms/tqm8260_setup.c b/arch/ppc/platforms/tqm8260_setup.c --- a/arch/ppc/platforms/tqm8260_setup.c +++ b/arch/ppc/platforms/tqm8260_setup.c @@ -16,8 +16,8 @@ #include -#include #include +#include #include static int - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power consumption HZ250 vs. HZ1000
On Mon, 25 Jul 2005, Marc Ballarin wrote: > Hmm, just did. I even tried the rather minimalistic configuration below. > Still no C3. (And what seems even stranger: no C1.) there's no point to going into C1 if the C2 entry/exit latencies are acceptable. (winxp generally never uses C1 if C2 is available and within the specs msft dictates for C2 latencies...) -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
Radoslaw "AstralStorm" Szkodzinski <[EMAIL PROTECTED]> wrote: > > On Tue, 26 Jul 2005 16:11:49 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > All done - let me know if it needs anything else. > > > > You got me with a tarball w/o a directory inside. Now I have to clean up the > mess. > Not the first time in life. I think I'll never learn. :) I did? bix:/home/akpm/.mm> tar tvfj broken-out-2005-07-26-15-07.tar.bz2 | head -rw-r--r-- akpm/akpm 35426 2005-07-26 15:10:32 series -rw-r--r-- akpm/akpm593326 2005-07-26 12:46:37 patches/linus.patch -rw-r--r-- akpm/akpm 3076 2005-07-16 14:28:43 patches/i2c-mpc-restore-code-removed.patch -rw-r--r-- akpm/akpm 888 2005-07-16 14:28:45 patches/really-__nocast-annotate-kmalloc_node.patch -rw-r--r-- akpm/akpm 3071 2005-07-26 00:37:34 patches/mips-fbdev-kconfig-fix.patch -rw-r--r-- akpm/akpm 4097 2005-07-26 00:37:34 patches/max_user_rt_prio-and-max_rt_prio-are-wrong.patch -rw-r--r-- akpm/akpm 2053 2005-07-26 00:39:53 patches/md-when-resizing-an-array-we-need-to-update-resync_max_sectors-as-well-as-size.patch -rw-r--r-- akpm/akpm 946 2005-07-26 00:39:55 patches/uml-readd-missing-define-to-arch-um-makefile-i386.patch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: Assume PM Timer to be reliable on broken board/BIOS
Olivier Fourdan wrote: Hi all, Background == I have a laptop (Compaq R3480EA, AMD 64 3400+ with NForce3) and reported multiple problems related to timer issues. In a nutshell, sometimes, the PIT/TSC timer runs 3x too fast [1]. That causes many issues, including DMA errors, MCE, and clock running way too fast (making the laptop unusable for any software development). So far, no BIOS update was able to fix the issue for me. Shouldn't this be looked into further rather than adding this workaround? Surely Windows is using the PIT as well, so there must be some way to get it to behave properly.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: [SOLVED ?] VIA KT400 + Kernel 2.6.12 + IO-APIC + ehci_hcd = IRQ trouble
On Tue, 26 Jul 2005 21:39:26 +0200, Michel Bouissou <[EMAIL PROTECTED]> wrote: > >Yes, but it doesn't tell us why kernels 2.4x felt perfectly happy with the old >BIOS... You turned off 4k stacks? I have a Via KM400 chipset box locked up a few times, once under 2.4.31-hf2 after 4.5 hours compiling kernels, fixed with some .config tuning. Done 48+ hours continuous compiling kernels with 2.6.12.3 + 8k stacks, load ~2.2. Just adding a datapoint... Dunno if this relevant. Simpler, older box with Intel 440BX chipset is happy with 4k stacks, only 2 USB ports. Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.12 sound problem
Hello List,
I recently upgraded my laptop, HP Pavilion N5430, from a 2.4.21 kernel
to 2.6.12. As a result of
doing this my sound no longer works correctly. It plays the same thing
repeatedly some number
of times - if it plays at all.
Any ideas on how to debug this would be appreciated.
Additional info I don't see any interrupts in /proc/interrupts for the
Allegro which is on int 5.
I just tried the same laptop with knoppix and a 2.4.27 kernel and sound
works great and I do
see interrupts for Allegro on int 5.
Thanks,
Steve
aplay -v and aadebug output follow.
[EMAIL PROTECTED] ~]# aplay -v /usr/share/apps/kget/sounds/started.wav
Playing WAVE '/usr/share/apps/kget/sounds/started.wav' : Unsigned 8 bit,
Rate 11128 Hz,Mono
Plug PCM: Hardware PCM card 0 'ESS Allegro PCI' device 0 subdevice 1
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : U8
subformat: STD
channels : 1
rate : 11128
exact rate : 11128 (11128/1)
msbits : 8
buffer_size : 5564
period_size : 1391
period_time : 125000
tick_time: 1000
tstamp_mode : NONE
period_step : 1
sleep_min: 0
avail_min: 1391
xfer_align : 1391
start_threshold : 5564
stop_threshold : 5564
silence_threshold: 0
silence_size : 0
boundary : 1458569216
aplay: pcm_write:1171: write error: Input/output error
aadebug output:
ALSA Audio Debug v0.0.9 - Mon Jul 25 14:49:10 EDT 2005
http://alsa.opensrc.org/?page=aadebug
Kernel
Linux joker4.seclark.com 2.6.12-prep #1 Sun Jul 24 22:39:46 EDT 2005
i686 athlon i386 GNU/Linux
Loaded Modules
snd_maestro3 25252 2
snd_ac97_codec 76408 1 snd_maestro3
snd_seq_dummy 3972 0
snd_seq_oss37760 0
snd_seq_midi_event 9600 1 snd_seq_oss
snd_seq62992 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device 9228 3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss51760 0
snd_mixer_oss 18304 1 snd_pcm_oss
snd_pcm 100744 4 snd_maestro3,snd_ac97_codec,snd_pcm_oss
snd_timer 33924 2 snd_seq,snd_pcm
snd_page_alloc 10116 1 snd_pcm
snd57860 12
snd_maestro3,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
Modprobe Conf -
alias snd-card-0 snd-maestro3
options snd-card-0 index=0
options snd-maestro3 index=0
remove snd-maestro3 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ;
}; /sbin/modprobe -r --ignore-remove snd-maestro3
Proc Asound ---
Advanced Linux Sound Architecture Driver Version 1.0.9rc2 (Thu Mar 24
10:33:392005 UTC).
0 [PCI]: Allegro - ESS Allegro PCI
ESS Allegro PCI at 0x1400, irq 5
1: : sequencer
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
0: [0- 0]: ctl
33: : timer
00-00: Allegro : Allegro : playback 2 : capture 1
Dev Snd ---
controlC0 pcmC0D0c pcmC0D0p seq timer
CPU ---
model name : mobile AMD Duron(tm) Processor
cpu MHz : 299.999
RAM ---
MemTotal: 255652 kB
SwapTotal: 524280 kB
Hardware --
00:00.0 Host bridge: ALi Corporation M1647 Northbridge [MAGiK 1 /
MobileMAGiK 1] (rev 04)
00:08.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1
(rev 12)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: problem while executing insmod
deepak jose wrote: sir/madam, i written a module function similar to hello, world in C .i compiled it.but when i ,m loading the module i'm getting the error that "the kernel compiled is kernel 2.4.20 whereas i'm having 2.4.20-8". wat i have to do to load it properly without forcing it to load. did i have to change my kernel. please suggest me a solution without changing the kernel. Are you compiling against the same kernel version that's actually running on the machine? 2.4.20-8 sounds like a Red Hat 9 kernel version (an out of date one, BTW), you cannot build modules against vanilla 2.4.20 kernel sources and load them into the Red Hat 9 version. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: [2.6 patch] NETCONSOLE must depend on INET
From: Matt Mackall <[EMAIL PROTECTED]> Date: Tue, 26 Jul 2005 16:20:43 -0700 > This problem also exists in PKTGEN. And this fix is incorrect as > neither is dependent on the IP part of the networking stack in any > substantive way. The right fix is to make inet_aton available outside > of CONFIG_INET (preferred) or making private copies of inet_aton. Adrian posted a fix, you whine, that's why Adrian's fix went in :-) More seriously, please submit a version of whatever you believe to be the more correct fix so it can be reviewed and integrated. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reclaim space from unused ramdisk?
On Tue, 26 Jul 2005 15:16:58 -0700 Mike Mohr <[EMAIL PROTECTED]> wrote: > I wonder if it would be possible to somehow reclaim space that has > been previously reserved for a ramdisk without rebooting. I read the > ramdisk docs in the latest kernel source and it seems that it is not > currently possible. However, the kernel keeps track of the memory > allocated for said ramdisks; would it not be possible with root (or > even kernel) permissions to remove the flag that prevents the VM > subsystem from reclaiming that space? I realize that rot permissions > may not be high enough. In that case, could a module be written that > takes a device name as a parameter then uses it to look up the > reserved memory that device uses, then resets the necessary flag and > finally unloads itself? It would have to check that the filesystem > was unmounted, of course. > > How difficult would this be to write? Hi, ramfs (always there) and tmpfs (optional) already do this. tmpfs can be swapped out, ramfs always uses physical memory. mount -t ramfs none /mnt/blah mount -t tmpfs none /mnt/blah Regards - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
On Tue, 2005-07-26 at 16:07 -0700, Andrew Morton wrote: > Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > > > Here is the data with 5 ext2 filesystems. I also collected /proc/meminfo > > every 5 seconds. As you can see, we seem to dirty 6GB of data in 20 > > seconds of starting the test. I am not sure if its bad, since we have > > lots of free memory.. > > It's bad. The logic in balance_dirty_pages() should block those write() > callers as soon as we hit 40% dirty memory or whatever is in > /proc/sys/vm/dirty_ratio. So something is horridly busted. > > Can you try reducing the number of filesystems even further? Single ext2 filesystem. We still dirty pretty quickly (data collected every 5 seconds). # grep Dirty OUT Dirty: 312 kB Dirty: 1121852 kB Dirty: 2896952 kB Dirty: 4344564 kB Dirty: 5310856 kB Dirty: 5507812 kB Dirty: 5714884 kB Dirty: 5865132 kB Dirty: 6004276 kB Dirty: 6206544 kB Dirty: 6380524 kB Dirty: 6583200 kB Dirty: 6727296 kB Dirty: 6708564 kB Dirty: 6733768 kB Dirty: 6737868 kB Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 16:11:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > All done - let me know if it needs anything else. > You got me with a tarball w/o a directory inside. Now I have to clean up the mess. Not the first time in life. I think I'll never learn. :) -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpPJmrxbwqBI.pgp Description: PGP signature
Re: [2.6 patch] NETCONSOLE must depend on INET
On Tue, Jul 19, 2005 at 02:01:04PM -0700, David S. Miller wrote: > From: Adrian Bunk <[EMAIL PROTECTED]> > Date: Tue, 19 Jul 2005 20:29:19 +0200 > > > NETCONSOLE=y and INET=n results in the following compile error: > > Also applied, thanks Adrian. I should have been cc:ed on this. This problem also exists in PKTGEN. And this fix is incorrect as neither is dependent on the IP part of the networking stack in any substantive way. The right fix is to make inet_aton available outside of CONFIG_INET (preferred) or making private copies of inet_aton. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Obsolete files in 2.6 tree
> > drivers/char/drm/gamma_dma.c > > drivers/char/drm/gamma_drv.c Gamma is defunct certainly > > drivers/media/video/zr36120.c > > drivers/media/video/zr36120_i2c.c > > drivers/media/video/zr36120_mem.c Being discussed on the V4L list > > drivers/scsi/NCR5380.c > > drivers/scsi/NCR5380.h These are used - check your scripts handle .c includes > > fs/binfmt_som.c pa-risc > > sound/oss/skeleton.c Reference for writing drivers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [swsusp] encrypt suspend data for easy wiping
Hi! > > Well, "how long are my keys going to stay in swap after > > swsusp"... that's pretty scary. > > Either they're likely in RAM _anyway_ and are thus already trivially > accessible to the attacker (for things like dm_crypt or IPSEC or > ssh-agent), or the application took care to zero them out, or the > application has a security bug. > > There are about 4 attack cases, in order of likelihood: > > 1) An attacker steals your suspended laptop. He has access to all your > suspended data. This patch gets us exactly nothing. Wrong. Without this Andreas' patch, he'll get access to your half-a-year-old GPG passphrases, too. > 2) An attacker breaks into your machine remotely while you're using > it. He has access to all your RAM, which if you're actually using it, > very likely including the same IPSEC, dm_crypt, and ssh-agent keys as > are saved on suspend. Further, he can trivially capture your > keystrokes and thus capture any keys you use from that point forward. > This patch gets us very close to nothing. > > 3) An attacker steals your unsuspended laptop. He has access to all > your RAM, which in all likelihood includes your IPSEC, dm_crypt, and > ssh-agent keys. Odds are good that he invokes swsusp by closing the > laptop. This patch gets us very close to nothing. > > 4) You suspend your laptop between typing your GPG key password and > hitting enter, thus leaving your password in memory when it would > otherwise be cleared. Then you resume your laptop and hit enter, thus > clearing the password from RAM but leaving it on the suspend > partition. Then an attacker steals your machine (without re-suspending > it!) and manages to recover the swsusp image which contains the Why without resuspending it? Position of critical data in swap is pretty much random. What I'm worried is: attacker steals your laptop after you were using swsusp for half a year. Now your swap partition contains random pieces of GPG keys you were using for last half a year. That's bad. Current GPG keys can be found in RAM; unfortunately your swap partition can contain current and old GPG keys that were never supposed to be on disk. That's bad and I think we can agree on that. Andreas's patch solves it; if it was not supposed to go on disk, it will be erased after you resume. You can not do much better. It is equivalent of clearing swsusp data from swap after resume, just implemented somewhat clever... Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.12 1/1] docs: updated some code docs
Xose Vazquez Perez said: > Updated docs about how to write and submit patches/code. > Parts of this should conflict with a patch in -mm from a few weeks ago. then I check and don't see it there hrm, wonder what happened to it. -Separate each logical change into its own patch. +Separate each _logical changes_ into its own patch. change or drop "each" and change "its own patch" to "a single patch file." On the other hand, if you make a single change to numerous files, -group those changes into a single patch. Thus a single logical change -is contained within a single patch. +group those changes into a single patch. Thus single logical changes +are contained within a single patch. It's better in the original form. +Do not send more than 15 patches at once to the vger mailing lists!!! Only in one place, please. -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
Radoslaw "AstralStorm" Szkodzinski <[EMAIL PROTECTED]> wrote: > > On Tue, 26 Jul 2005 14:41:49 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Michael Krufky <[EMAIL PROTECTED]> wrote: > > > > > > [ tracking mm stuff ] > > > > > > > Sigh, sorry. It's hard. -mm is always in flux. I no longer send out the > > `patch was dropped' message because it disturbs people. > > There were too many? > Or you were receiving a lot of mail from particular developers with > requests of explanation? :) I got lots of "waah, why did you drop my patch" from people whose patches had been merged by Linus. Which is a bit odd given that those people were previously cc'ed on the me->linus patch anyway. Ho hum. Adding a "why this was dropped" to the email seemed too tricky. > > The mm-commits > > list does not resend a patch when it is changed (other patches folded into > > it, rejects fixed, changelog updated, rediffed, etc). > > This isn't so much a problem as the previous point. When there are rejects, > it's easy (most of the time) to fix them by hand anyway as I pull the tree. > > > Sometimes I'll comment out a patch but not fully drop it. > > Now I can see that, I can diff the series. > But if the change was large, the diff isn't very instructive. OK. I'm uploading the stripped series file at present (all the comments are removed) because some versions of quilt don't like my new comments-at-the-end-of-the-line feature. That actually breaks some of my stuff too, so I'll probably stop using it ;) > > > > I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5 > > times a day), but there's no guarantee that it'll compile, let alone run. > > I could also send a notification to mm-commits when I do so. Would that > > help? > > > > Really, it would. Especially if it contained an up-to-date series file. > I'd be very grateful. (And would test and fix it up some more.) All done - let me know if it needs anything 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/
Re: Memory pressure handling with iSCSI
Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > Here is the data with 5 ext2 filesystems. I also collected /proc/meminfo > every 5 seconds. As you can see, we seem to dirty 6GB of data in 20 > seconds of starting the test. I am not sure if its bad, since we have > lots of free memory.. It's bad. The logic in balance_dirty_pages() should block those write() callers as soon as we hit 40% dirty memory or whatever is in /proc/sys/vm/dirty_ratio. So something is horridly busted. Can you try reducing the number of filesystems even further? Either the underlying block driver is doing something most bizarre to the VFS or something has gone wrong with the arithmetic in page-writeback.c. If total_pages or ratelimit_pages are totally wrong or if get_dirty_limits() is returning junk then we'd be seeing something like this. It'll be something simple - if you have time, stick some printks in balance_dirty_pages(), work out why it is not remaining in that `for' loop until dirty memory has fallen below the 40%. I'll take a shot at reproducing this on my 4G x86_64 box, but this is so grossly wrong that I'm sure it would have been noted before now if it was commonly happening (famous last words). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 2/4]delayed allocation for ext3
On Tue, 2005-07-26 at 15:52 -0700, Andrew Morton wrote:
> Mingming Cao <[EMAIL PROTECTED]> wrote:
> >
> > Here is the updated patch from Badari for delayed allocation for ext3.
> > Delayed allocation defers block allocation from prepare-write time to
> > page writeout time.
>
> For data=writeback only, yes?
Yes.
>
> > ...
> > --- linux-2.6.12/fs/ext3/inode.c~ext3-delalloc 2005-07-14
> > 23:15:34.866752480 -0700
> > +++ linux-2.6.12-ming/fs/ext3/inode.c 2005-07-14 23:15:34.889748984
> > -0700
> > @@ -1340,6 +1340,9 @@ static int ext3_prepare_write(struct fil
> > handle_t *handle;
> > int retries = 0;
> >
> > +
> > + if (test_opt(inode->i_sb, DELAYED_ALLOC))
> > + return __nobh_prepare_write(page, from, to, ext3_get_block, 0);
>
> Rather than performing this test on each ->prepare_write(), would it not be
> better to set up a new set of address_space_operations for this mode?
>
> __nobh_prepare_write() seems like a poor choice of name?
You are correct. I was trying to minimize the changes to interfaces.
Once we get it working, I will do it as part of cleanups.
>
> > retry:
> > handle = ext3_journal_start(inode, needed_blocks);
> > if (IS_ERR(handle)) {
> > @@ -1439,6 +1442,9 @@ static int ext3_writeback_commit_write(s
> > else
> > ret = generic_commit_write(file, page, from, to);
> >
> > + if (test_opt(inode->i_sb, DELAYED_ALLOC))
> > + return ret;
> > +
>
> Here too, perhaps.
>
> > + }
> > + }
> > /*
> > * The journal_load will have done any necessary log recovery,
> > * so we can safely mount the rest of the filesystem now.
> > diff -puN fs/buffer.c~ext3-delalloc fs/buffer.c
> > --- linux-2.6.12/fs/buffer.c~ext3-delalloc 2005-07-14 23:15:34.875751112
> > -0700
> > +++ linux-2.6.12-ming/fs/buffer.c 2005-07-14 23:15:34.903746856 -0700
> > @@ -2337,8 +2337,8 @@ static void end_buffer_read_nobh(struct
> > * On entry, the page is fully not uptodate.
> > * On exit the page is fully uptodate in the areas outside (from,to)
> > */
> > -int nobh_prepare_write(struct page *page, unsigned from, unsigned to,
> > - get_block_t *get_block)
> > +int __nobh_prepare_write(struct page *page, unsigned from, unsigned to,
> > + get_block_t *get_block, int create)
>
> Suggest you make this static and update the comment.
>
Sure.
> > {
> > struct inode *inode = page->mapping->host;
> > const unsigned blkbits = inode->i_blkbits;
> > @@ -2370,10 +2370,8 @@ int nobh_prepare_write(struct page *page
> > block_start < PAGE_CACHE_SIZE;
> > block_in_page++, block_start += blocksize) {
> > unsigned block_end = block_start + blocksize;
> > - int create;
> >
> > map_bh.b_state = 0;
> > - create = 1;
> > if (block_start >= to)
> > create = 0;
> > ret = get_block(inode, block_in_file + block_in_page,
>
> What's going on here? Seems that we'll call get_block() with `create=0'.
> Is there any point in doing that? For delayed allocation we shuld be able
> to skip get_block() altogether here and, err, delay it.
For delayed allocation, I need to delay the block allocation - but I
still need to do get_block(READ) and read the data from the block - if
the block already exists.
>
> > +int nobh_prepare_write(struct page *page, unsigned from, unsigned
> > + get_block_t *get_block)
> > +{
> > + return __nobh_prepare_write(page, from, to, get_block, 1);
> > +}
> > +
> > EXPORT_SYMBOL(nobh_prepare_write);
>
> Here you add nobh_dalloc_prepare_write() and remember to export it to
> modules this time ;)
>
Will do.
Thanks,
Badari
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 15:32:51 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5 > > times a day), > > OK, I did that. > Great! > The kernel.org propagation delay is a bit of a hassle. I could use > zip.com.au but I suspect they hate me enough already. > Right now the delay is about one hour. I can certainly live with that. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpsdmlgqdZ2F.pgp Description: PGP signature
Re: [swsusp] encrypt suspend data for easy wiping
On Wed, Jul 27, 2005 at 12:14:46AM +0200, Pavel Machek wrote: > Hi! > > > > > the attached patches are acked by Pavel and signed off by me > > > > > > OK, well I queued this up, without a changelog. Because you didn't send > > > one. Please do so. As it adds a new feature, quite a bit of info is > > > relevant. > > > > I don't like this patch. It reinvents a fair amount of dm_crypt and > > cryptoloop but badly. > > > > Further, the model of security it's using is silly. In case anyone > > hasn't noticed, it stores the password on disk in the clear. This is > > so it can erase it after resume and thereby make recovery of the > > suspend image hard. > > > > But laptops get stolen while they're suspended, not while they're up > > and running. And if your box is up and running and an attacker gains > > access, the contents of your suspend partition are the least of your > > worries. It makes no sense to expend any effort defending against this > > case, especially as it's liable to become a barrier to doing this > > right, namely with real dm_crypt encrypted swap. > > Well, "how long are my keys going to stay in swap after > swsusp"... that's pretty scary. Either they're likely in RAM _anyway_ and are thus already trivially accessible to the attacker (for things like dm_crypt or IPSEC or ssh-agent), or the application took care to zero them out, or the application has a security bug. There are about 4 attack cases, in order of likelihood: 1) An attacker steals your suspended laptop. He has access to all your suspended data. This patch gets us exactly nothing. 2) An attacker breaks into your machine remotely while you're using it. He has access to all your RAM, which if you're actually using it, very likely including the same IPSEC, dm_crypt, and ssh-agent keys as are saved on suspend. Further, he can trivially capture your keystrokes and thus capture any keys you use from that point forward. This patch gets us very close to nothing. 3) An attacker steals your unsuspended laptop. He has access to all your RAM, which in all likelihood includes your IPSEC, dm_crypt, and ssh-agent keys. Odds are good that he invokes swsusp by closing the laptop. This patch gets us very close to nothing. 4) You suspend your laptop between typing your GPG key password and hitting enter, thus leaving your password in memory when it would otherwise be cleared. Then you resume your laptop and hit enter, thus clearing the password from RAM but leaving it on the suspend partition. Then an attacker steals your machine (without re-suspending it!) and manages to recover the swsusp image which contains the password. But with this patch, he's foiled because the password is encrypted and the key's been erased! He's got all your other data though, including all the aforementioned long-lived keys. The right fix for case 1 is dm_crypt with a password prompt. The right fix for 2 is beyond the scope of this email, but probably begins with the letters s and e. The fix for 1 goes a long way towards fixing 3 as well, provided the attacker suspends your machine. And I claim that anyone who is paranoid enough to actually care about corner cases like 4 should damn well care about case 1 too, and should be more than willing to type a password on resume, otherwise they're just fooling themselves. Together with the fact that this reimplements dm_crypt functionality with an unreviewed and cryptographically naive replacement, I don't think this patch makes any sense at all. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (2/9)
On Mon, Jul 25, 2005 at 07:28:27PM +0200, Jean Delvare wrote: > Hi Greg, > > > Ah, much better, thanks. Sounds like a great plan, I'll go apply your > > patches in a day or so when I catch up from my travels. > > OK, thanks. > > Note that there are a few patches which you should apply before this > series, in particular Mark Hoffman's 3 hwmon class patches. There are no > hard dependencies between both series but applying them in order is > likely to ease your work. > > You can take a look at my current stack here for reference: > http://khali.linux-fr.org/devel/i2c/linux-2.6/series Ok, should be caught up now. I have a pci patch or two still left to apply that i know you were also tracking. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
patch i2c-hwmon-split-08.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled
Subject: I2C: Separate non-i2c hwmon drivers from i2c-core (8/9)
to my gregkh-2.6 tree. Its filename is
i2c-hwmon-split-08.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are
i2c/i2c-max6875-documentation-update.patch
i2c/i2c-max6875-simplify.patch
i2c/i2c-hwmon-class-01.patch
i2c/i2c-hwmon-class-02.patch
i2c/i2c-hwmon-class-03.patch
i2c/i2c-missing-space.patch
i2c/i2c-nforce2-cleanup.patch
i2c/i2c-hwmon-split-01.patch
i2c/i2c-hwmon-split-02.patch
i2c/i2c-hwmon-split-03.patch
i2c/i2c-hwmon-split-04.patch
i2c/i2c-hwmon-split-05.patch
i2c/i2c-hwmon-split-06.patch
i2c/i2c-hwmon-split-07.patch
i2c/i2c-hwmon-split-08.patch
i2c/i2c-hwmon-split-09.patch
>From [EMAIL PROTECTED] Tue Jul 19 18:06:45 2005
Date: Wed, 20 Jul 2005 00:05:33 +0200
From: Jean Delvare <[EMAIL PROTECTED]>
To: LKML , LM Sensors
<[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Subject: I2C: Separate non-i2c hwmon drivers from i2c-core (8/9)
Message-Id: <[EMAIL PROTECTED]>
Kill all uses of i2c_is_isa_adapter except for the hybrid drivers (it87,
lm78, w83781d). The i2c-isa adapter not being registered with the i2c
core anymore, drivers don't have to fear being erroneously attached to
it.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
Documentation/i2c/writing-clients | 11 +--
drivers/hwmon/adm1021.c |9 -
drivers/hwmon/asb100.c|8
drivers/hwmon/lm75.c | 10 --
drivers/hwmon/lm85.c |5 -
5 files changed, 5 insertions(+), 38 deletions(-)
--- gregkh-2.6.orig/Documentation/i2c/writing-clients 2005-07-26
15:16:45.0 -0700
+++ gregkh-2.6/Documentation/i2c/writing-clients2005-07-26
15:16:46.0 -0700
@@ -315,11 +315,10 @@
const char *type_name = "";
int is_isa = i2c_is_isa_adapter(adapter);
-if (is_isa) {
+/* Do this only if the chip can additionally be found on the ISA bus
+ (hybrid chip). */
- /* If this client can't be on the ISA bus at all, we can stop now
- (call `goto ERROR0'). But for kicks, we will assume it is all
- right. */
+if (is_isa) {
/* Discard immediately if this ISA range is already used */
if (check_region(address,FOO_EXTENT))
@@ -495,10 +494,10 @@
return err;
}
-/* SENSORS ONLY START */
+/* HYBRID SENSORS CHIP ONLY START */
if i2c_is_isa_client(client)
release_region(client->addr,LM78_EXTENT);
-/* SENSORS ONLY END */
+/* HYBRID SENSORS CHIP ONLY END */
kfree(client); /* Frees client data too, if allocated at the same time */
return 0;
--- gregkh-2.6.orig/drivers/hwmon/adm1021.c 2005-07-26 15:16:45.0
-0700
+++ gregkh-2.6/drivers/hwmon/adm1021.c 2005-07-26 15:16:46.0 -0700
@@ -198,15 +198,6 @@
int err = 0;
const char *type_name = "";
- /* Make sure we aren't probing the ISA bus!! This is just a safety check
- at this moment; i2c_detect really won't call us. */
-#ifdef DEBUG
- if (i2c_is_isa_adapter(adapter)) {
- dev_dbg(>dev, "adm1021_detect called for an ISA bus
adapter?!?\n");
- return 0;
- }
-#endif
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
goto error0;
--- gregkh-2.6.orig/drivers/hwmon/asb100.c 2005-07-26 15:16:45.0
-0700
+++ gregkh-2.6/drivers/hwmon/asb100.c 2005-07-26 15:16:46.0 -0700
@@ -714,14 +714,6 @@
struct i2c_client *new_client;
struct asb100_data *data;
- /* asb100 is SMBus only */
- if (i2c_is_isa_adapter(adapter)) {
- pr_debug("asb100.o: detect failed, "
- "cannot attach to legacy adapter!\n");
- err = -ENODEV;
- goto ERROR0;
- }
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
pr_debug("asb100.o: detect failed, "
"smbus byte data not supported!\n");
--- gregkh-2.6.orig/drivers/hwmon/lm75.c2005-07-26 15:16:45.0
-0700
+++ gregkh-2.6/drivers/hwmon/lm75.c 2005-07-26 15:16:46.0 -0700
@@ -121,16 +121,6 @@
int err = 0;
const char *name = "";
- /* Make sure we aren't probing the ISA bus!! This is just a safety check
- at this moment; i2c_detect really won't call us. */
-#ifdef DEBUG
- if (i2c_is_isa_adapter(adapter)) {
- dev_dbg(>dev,
- "lm75_detect called for an ISA bus adapter?!?\n");
- goto exit;
- }
-#endif
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
I2C_FUNC_SMBUS_WORD_DATA))
goto
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 14:41:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > Michael Krufky <[EMAIL PROTECTED]> wrote: > > > > [ tracking mm stuff ] > > > > Sigh, sorry. It's hard. -mm is always in flux. I no longer send out the > `patch was dropped' message because it disturbs people. There were too many? Or you were receiving a lot of mail from particular developers with requests of explanation? :) > The mm-commits > list does not resend a patch when it is changed (other patches folded into > it, rejects fixed, changelog updated, rediffed, etc). This isn't so much a problem as the previous point. When there are rejects, it's easy (most of the time) to fix them by hand anyway as I pull the tree. > Sometimes I'll comment out a patch but not fully drop it. Now I can see that, I can diff the series. But if the change was large, the diff isn't very instructive. > I pull all the git trees at > least twice a day and that's not reflected on the mm-commits list either. > That's not a problem, I can pull them too. They're public. > You can always tell when a -mm release is coming by watching the shower of > stupid compile fixes emerging :( I do notice that using the RSS already, :) And the usual shower isn't as frequent and large nowadays as before. > > I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5 > times a day), but there's no guarantee that it'll compile, let alone run. > I could also send a notification to mm-commits when I do so. Would that > help? > Really, it would. Especially if it contained an up-to-date series file. I'd be very grateful. (And would test and fix it up some more.) -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpwUvpoLjMQU.pgp Description: PGP signature
Re: [RFC] [PATCH 2/4]delayed allocation for ext3
Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> Here is the updated patch from Badari for delayed allocation for ext3.
> Delayed allocation defers block allocation from prepare-write time to
> page writeout time.
For data=writeback only, yes?
> ...
> --- linux-2.6.12/fs/ext3/inode.c~ext3-delalloc2005-07-14
> 23:15:34.866752480 -0700
> +++ linux-2.6.12-ming/fs/ext3/inode.c 2005-07-14 23:15:34.889748984 -0700
> @@ -1340,6 +1340,9 @@ static int ext3_prepare_write(struct fil
> handle_t *handle;
> int retries = 0;
>
> +
> + if (test_opt(inode->i_sb, DELAYED_ALLOC))
> + return __nobh_prepare_write(page, from, to, ext3_get_block, 0);
Rather than performing this test on each ->prepare_write(), would it not be
better to set up a new set of address_space_operations for this mode?
__nobh_prepare_write() seems like a poor choice of name?
> retry:
> handle = ext3_journal_start(inode, needed_blocks);
> if (IS_ERR(handle)) {
> @@ -1439,6 +1442,9 @@ static int ext3_writeback_commit_write(s
> else
> ret = generic_commit_write(file, page, from, to);
>
> + if (test_opt(inode->i_sb, DELAYED_ALLOC))
> + return ret;
> +
Here too, perhaps.
> + }
> + }
> /*
>* The journal_load will have done any necessary log recovery,
>* so we can safely mount the rest of the filesystem now.
> diff -puN fs/buffer.c~ext3-delalloc fs/buffer.c
> --- linux-2.6.12/fs/buffer.c~ext3-delalloc2005-07-14 23:15:34.875751112
> -0700
> +++ linux-2.6.12-ming/fs/buffer.c 2005-07-14 23:15:34.903746856 -0700
> @@ -2337,8 +2337,8 @@ static void end_buffer_read_nobh(struct
> * On entry, the page is fully not uptodate.
> * On exit the page is fully uptodate in the areas outside (from,to)
> */
> -int nobh_prepare_write(struct page *page, unsigned from, unsigned to,
> - get_block_t *get_block)
> +int __nobh_prepare_write(struct page *page, unsigned from, unsigned to,
> + get_block_t *get_block, int create)
Suggest you make this static and update the comment.
> {
> struct inode *inode = page->mapping->host;
> const unsigned blkbits = inode->i_blkbits;
> @@ -2370,10 +2370,8 @@ int nobh_prepare_write(struct page *page
> block_start < PAGE_CACHE_SIZE;
> block_in_page++, block_start += blocksize) {
> unsigned block_end = block_start + blocksize;
> - int create;
>
> map_bh.b_state = 0;
> - create = 1;
> if (block_start >= to)
> create = 0;
> ret = get_block(inode, block_in_file + block_in_page,
What's going on here? Seems that we'll call get_block() with `create=0'.
Is there any point in doing that? For delayed allocation we shuld be able
to skip get_block() altogether here and, err, delay it.
> +int nobh_prepare_write(struct page *page, unsigned from, unsigned
> + get_block_t *get_block)
> +{
> + return __nobh_prepare_write(page, from, to, get_block, 1);
> +}
> +
> EXPORT_SYMBOL(nobh_prepare_write);
Here you add nobh_dalloc_prepare_write() and remember to export it to
modules this time ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
On Tue, 2005-07-26 at 15:10 -0700, Andrew Morton wrote: > Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > > > On Tue, 2005-07-26 at 14:24 -0700, Andrew Morton wrote: > > > Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > > > > > > > ext2 is incredibly better. Machine is very responsive. > > > > > > > > > > OK. Please, always monitor and send /proc/meminfo. I assume that the > > > dirty-memory clamping is working OK with ext2 and that perhaps it'll work > > > OK with ext3/data=writeback. > > > > Nope. Dirty is still very high.. > > That's a relief in a way. Can you please try decreasing the number of > filesystems now? Here is the data with 5 ext2 filesystems. I also collected /proc/meminfo every 5 seconds. As you can see, we seem to dirty 6GB of data in 20 seconds of starting the test. I am not sure if its bad, since we have lots of free memory.. Thanks, Badari procs ---memory-- ---swap-- -io --system-- cpu r b swpd free buff cache si sobibo incs us sy id wa 2 11120 32912 10624 681347600 0 6766 10364 485 0 4 0 96 0 11120 33036 10652 681396400 2 8889 10079 475 0 4 0 96 0 11120 33036 10712 681390400 0 8077 9984 469 0 4 0 96 0 11120 32912 10752 681438000 0 15576 10226 514 0 4 0 95 0 11120 33036 10668 681343200 0 11334 10112 488 0 4 0 96 0 11120 33656 10600 681350000 0 11811 10238 497 0 4 0 96 0 11120 33036 10596 681402000 0 12713 10191 489 0 4 0 96 0 11120 33036 10648 681396800 1 15775 10195 508 0 4 0 96 0 10120 33780 10656 681292800 2 5390 10265 503 0 3 5 92 0 11120 33036 10660 681344000 0 9700 10217 518 0 4 2 94 MemTotal: 7143628 kB MemFree: 7001860 kB Buffers: 5080 kB Cached: 23300 kB SwapCached: 0 kB Active: 48600 kB Inactive: 5872 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 7143628 kB LowFree: 7001860 kB SwapTotal: 1048784 kB SwapFree: 1048780 kB Dirty: 0 kB Writeback: 0 kB Mapped: 45948 kB Slab:56348 kB CommitLimit: 4620596 kB Committed_AS: 148436 kB PageTables: 1544 kB VmallocTotal: 34359738367 kB VmallocUsed: 9888 kB VmallocChunk: 34359728447 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB MemTotal: 7143628 kB MemFree: 4871864 kB Buffers: 14564 kB Cached:2091232 kB SwapCached: 0 kB Active: 51380 kB Inactive: 2081780 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 7143628 kB LowFree: 4871864 kB SwapTotal: 1048784 kB SwapFree: 1048780 kB Dirty: 2070752 kB Writeback: 0 kB Mapped: 46368 kB Slab: 107912 kB CommitLimit: 4620596 kB Committed_AS: 148524 kB PageTables: 1608 kB VmallocTotal: 34359738367 kB VmallocUsed: 9888 kB VmallocChunk: 34359728447 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB MemTotal: 7143628 kB MemFree:406384 kB Buffers: 18940 kB Cached:6443960 kB SwapCached: 0 kB Active: 55688 kB Inactive: 6435048 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 7143628 kB LowFree:406384 kB SwapTotal: 1048784 kB SwapFree: 1048780 kB Dirty: 6144652 kB Writeback: 252152 kB Mapped: 46380 kB Slab: 216580 kB CommitLimit: 4620596 kB Committed_AS: 148756 kB PageTables: 1608 kB VmallocTotal: 34359738367 kB VmallocUsed: 9888 kB VmallocChunk: 34359728447 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB MemTotal: 7143628 kB MemFree: 32772 kB Buffers: 10028 kB Cached:6817680 kB SwapCached: 4 kB Active: 48180 kB Inactive: 6804552 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 7143628 kB LowFree: 32772 kB SwapTotal: 1048784 kB SwapFree: 1048664 kB Dirty: 6489496 kB Writeback: 285264 kB Mapped: 46000 kB Slab: 228172 kB CommitLimit: 4620596 kB Committed_AS: 148756 kB PageTables: 1608 kB VmallocTotal: 34359738367 kB VmallocUsed: 9888 kB VmallocChunk: 34359728447 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB MemTotal: 7143628 kB MemFree: 32524 kB Buffers: 10056 kB Cached:6816620 kB SwapCached: 4 kB Active: 48672 kB Inactive: 6803212 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 7143628 kB LowFree: 32524 kB SwapTotal: 1048784 kB SwapFree: 1048664 kB Dirty: 6465124 kB Writeback: 268876 kB Mapped: 46008 kB Slab:
Re: [PATCH 2.6.12 1/1] docs: updated some code docs
Xose Vazquez Perez <[EMAIL PROTECTED]> wrote: > > Updated docs about how to write and submit patches/code. Thanks. I'd like some words in there pointing out that "Andrew Morton's patch scripts" are a pile of crap and people should use quilt. Could you mention that and resend the patch? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Assume PM Timer to be reliable on broken board/BIOS
Hi all,
Background
==
I have a laptop (Compaq R3480EA, AMD 64 3400+ with NForce3) and reported
multiple problems related to timer issues.
In a nutshell, sometimes, the PIT/TSC timer runs 3x too fast [1]. That
causes many issues, including DMA errors, MCE, and clock running way too
fast (making the laptop unusable for any software development). So far,
no BIOS update was able to fix the issue for me.
As I first reported this the LKML back in march [2], the only reliable
time source on this laptop seems to be the PM timer. However, the time
in Linux is tick based and forcing the PM timer doesn't help.
Also, the PIT timer being used to calibrate the lpj, the wrong LP was
causing the nasty errors I had with DMA and other MCE. Although the lpj
can be forced at boot, having it right in the first place even on such
broken hardware as my laptop can save quite a lot of time and
investigations for novice users.
Many similar reports can be found on the web for the Compaq R3000 and HP
zv5000 laptops, either with 64 or 32 bit CPU [3]. Similar bug reports
with no fix can be also found in SuSE and Red Hat bugzilla databases.
What the patch does
===
Basically, the patch adjusts the PIT/TSC passed values based on the PM
timer rate.
The PM timer is compared to the TSC/PIT rate and a a multiplier is
computed. On a "normal" system, the ratio is 1. On my broken laptop, the
ratio is 3.
That ration is then applied to all values passed to the PIT timer.
For example, instead of using:
outb_p(LATCH & 0xff, PIT_CH0);
outb(LATCH >> 8, PIT_CH0);
The patch uses :
outb_p((LATCH * timer_mult) & 0xff, PIT_CH0);
outb((LATCH * timer_mult) >> 8, PIT_CH0);
Also, the ratio is computed/used only if the user has specified the
"clock=pmtmr" boot option on i386 or "pmtmr" on x86_64. If the user has
not explicitly asked for the PM timer to be used, and if there is a
delta of more than 5% between the PM timer and the PIT, then the PM
timer is not used (just like it is in the current implementation for
i386 arch).
What is included in the patch
=
The patch includes the code that implements the workaround described
above for x86_64 and i386 arch.
The patch applies in Linux 2.6.12.3.
Documentation is also updated.
==
Please let me know if there are some fixes or improvements to add and if
such a patch could be suitable in the kernel.
As a side note, this patch is very useful for me as it makes the laptop
usable under Linux and I plan to keep it available somewhere on xfce.org
so that other Compaq R3000 and HP zv5000 owners can use it.
Ref.
[1] http://kerneltrap.org/mailarchive/1/message/43741/thread
[2] http://lkml.org/lkml/2005/3/29/265
[3] http://lists.pcxperience.com/pipermail/linuxr3000/2004-
September/003678.html
http://lists.pcxperience.com/pipermail/linuxr3000/2004-
September/003788.html
http://lists.pcxperience.com/pipermail/linuxr3000/2005-
July/006763.html
http://lists.pcxperience.com/pipermail/linuxr3000/2005-
January/004650.html
Thanks,
Regards,
Olivier.
diff -Naur linux-2.6.12.3/arch/i386/kernel/time.c linux-2.6.12.3-pmtimer/arch/i386/kernel/time.c
--- linux-2.6.12.3/arch/i386/kernel/time.c 2005-06-17 21:48:29.0 +0200
+++ linux-2.6.12.3-pmtimer/arch/i386/kernel/time.c 2005-07-26 22:30:52.0 +0200
@@ -77,6 +77,12 @@
EXPORT_SYMBOL(jiffies_64);
+/*
+ * timer_mult is a mutiplier used to work arround some very buggy BIOS
+ * or hardware where the PIT/TSC timer runs n times too fast.
+ */
+u16 timer_mult = 1;
+
unsigned long cpu_khz; /* Detected as we calibrate the TSC */
extern unsigned long wall_jiffies;
diff -Naur linux-2.6.12.3/arch/i386/kernel/timers/timer_cyclone.c linux-2.6.12.3-pmtimer/arch/i386/kernel/timers/timer_cyclone.c
--- linux-2.6.12.3/arch/i386/kernel/timers/timer_cyclone.c 2005-06-17 21:48:29.0 +0200
+++ linux-2.6.12.3-pmtimer/arch/i386/kernel/timers/timer_cyclone.c 2005-07-26 22:52:24.0 +0200
@@ -21,6 +21,12 @@
extern spinlock_t i8253_lock;
+/*
+ * timer_mult is a mutiplier used to work arround some very buggy BIOS
+ * or hardware where the PIT/TSC timer runs n times too fast.
+ */
+extern u16 timer_mult;
+
/* Number of usecs that the last interrupt was delayed */
static int delay_at_last_interrupt;
@@ -70,8 +76,8 @@
*/
if (count > LATCH) {
outb_p(0x34, PIT_MODE);
- outb_p(LATCH & 0xff, PIT_CH0);
- outb(LATCH >> 8, PIT_CH0);
+ outb_p((LATCH * timer_mult) & 0xff, PIT_CH0);
+ outb((LATCH * timer_mult) >> 8, PIT_CH0);
count = LATCH - 1;
}
spin_unlock(_lock);
diff -Naur linux-2.6.12.3/arch/i386/kernel/timers/timer_pit.c linux-2.6.12.3-pmtimer/arch/i386/kernel/timers/timer_pit.c
--- linux-2.6.12.3/arch/i386/kernel/timers/timer_pit.c 2005-06-17 21:48:29.0 +0200
+++ linux-2.6.12.3-pmtimer/arch/i386/kernel/timers/timer_pit.c
Re: [2.6 patch] fix ip_conntrack_put prototype
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Tue, 26 Jul 2005 16:56:59 +0200 > The function is not inline. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied, thanks Adrian. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 i2c-hwmon-split-05.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled
Subject: I2C: Separate non-i2c hwmon drivers from i2c-core (5/9)
to my gregkh-2.6 tree. Its filename is
i2c-hwmon-split-05.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are
i2c/i2c-max6875-documentation-update.patch
i2c/i2c-max6875-simplify.patch
i2c/i2c-hwmon-class-01.patch
i2c/i2c-hwmon-class-02.patch
i2c/i2c-hwmon-class-03.patch
i2c/i2c-missing-space.patch
i2c/i2c-nforce2-cleanup.patch
i2c/i2c-hwmon-split-01.patch
i2c/i2c-hwmon-split-02.patch
i2c/i2c-hwmon-split-03.patch
i2c/i2c-hwmon-split-04.patch
i2c/i2c-hwmon-split-05.patch
i2c/i2c-hwmon-split-06.patch
i2c/i2c-hwmon-split-07.patch
i2c/i2c-hwmon-split-08.patch
i2c/i2c-hwmon-split-09.patch
>From [EMAIL PROTECTED] Tue Jul 19 18:00:07 2005
Date: Tue, 19 Jul 2005 23:56:35 +0200
From: Jean Delvare <[EMAIL PROTECTED]>
To: LKML , LM Sensors
<[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Subject: I2C: Separate non-i2c hwmon drivers from i2c-core (5/9)
Message-Id: <[EMAIL PROTECTED]>
Call the ISA chip drivers detection function directly instead of relying
on i2c_detect. The net effect is that address lists won't be handled
anymore, but they were mostly useless in the ISA case anyway (pc87360,
smsc47m1, smsc47b397 had already dropped them).
We don't need to handle multiple devices, all we may need is a way to
force a given address instead of the original one (some drivers already
do: sis5595, via686a, w83627hf), and, for drivers supporting multiple
chips, a way to force one given kind. All this may be added later on
demand, but I actually don't think there will be much demand.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/hwmon/it87.c | 16 ++
drivers/hwmon/lm78.c | 11 --
drivers/hwmon/pc87360.c| 38 --
drivers/hwmon/sis5595.c| 41 -
drivers/hwmon/smsc47b397.c | 48 +++-
drivers/hwmon/smsc47m1.c | 42 --
drivers/hwmon/via686a.c| 41 +++--
drivers/hwmon/w83627ehf.c | 35
drivers/hwmon/w83627hf.c | 49 +++--
drivers/hwmon/w83781d.c| 12 +--
10 files changed, 98 insertions(+), 235 deletions(-)
--- gregkh-2.6.orig/drivers/hwmon/pc87360.c 2005-07-26 15:14:08.0
-0700
+++ gregkh-2.6/drivers/hwmon/pc87360.c 2005-07-26 15:16:29.0 -0700
@@ -39,25 +39,17 @@
#include
#include
#include
-#include
#include
#include
#include
#include
-static unsigned short normal_i2c[] = { I2C_CLIENT_END };
-static unsigned int normal_isa[] = { 0, I2C_CLIENT_ISA_END };
-static struct i2c_force_data forces[] = {{ NULL }};
static u8 devid;
-static unsigned int extra_isa[3];
+static unsigned short address;
+static unsigned short extra_isa[3];
static u8 confreg[4];
enum chips { any_chip, pc87360, pc87363, pc87364, pc87365, pc87366 };
-static struct i2c_address_data addr_data = {
- .normal_i2c = normal_i2c,
- .normal_isa = normal_isa,
- .forces = forces,
-};
static int init = 1;
module_param(init, int, 0);
@@ -228,8 +220,7 @@
* Functions declaration
*/
-static int pc87360_attach_adapter(struct i2c_adapter *adapter);
-static int pc87360_detect(struct i2c_adapter *adapter, int address, int kind);
+static int pc87360_detect(struct i2c_adapter *adapter);
static int pc87360_detach_client(struct i2c_client *client);
static int pc87360_read_value(struct pc87360_data *data, u8 ldi, u8 bank,
@@ -246,8 +237,7 @@
static struct i2c_driver pc87360_driver = {
.owner = THIS_MODULE,
.name = "pc87360",
- .flags = I2C_DF_NOTIFY,
- .attach_adapter = pc87360_attach_adapter,
+ .attach_adapter = pc87360_detect,
.detach_client = pc87360_detach_client,
};
@@ -636,12 +626,7 @@
* Device detection, registration and update
*/
-static int pc87360_attach_adapter(struct i2c_adapter *adapter)
-{
- return i2c_detect(adapter, _data, pc87360_detect);
-}
-
-static int pc87360_find(int sioaddr, u8 *devid, int *address)
+static int pc87360_find(int sioaddr, u8 *devid, unsigned short *addresses)
{
u16 val;
int i;
@@ -687,7 +672,7 @@
continue;
}
- address[i] = val;
+ addresses[i] = val;
if (i==0) { /* Fans */
confreg[0] = superio_inb(sioaddr, 0xF0);
@@ -731,9 +716,7 @@
return 0;
}
-/* We don't really care about the address.
- Read from extra_isa instead. */
-int pc87360_detect(struct i2c_adapter *adapter, int address, int
patch i2c-hwmon-split-09.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled Subject: I2C: Separate non-i2c hwmon drivers from i2c-core (9/9) to my gregkh-2.6 tree. Its filename is i2c-hwmon-split-09.patch This tree can be found at http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are i2c/i2c-max6875-documentation-update.patch i2c/i2c-max6875-simplify.patch i2c/i2c-hwmon-class-01.patch i2c/i2c-hwmon-class-02.patch i2c/i2c-hwmon-class-03.patch i2c/i2c-missing-space.patch i2c/i2c-nforce2-cleanup.patch i2c/i2c-hwmon-split-01.patch i2c/i2c-hwmon-split-02.patch i2c/i2c-hwmon-split-03.patch i2c/i2c-hwmon-split-04.patch i2c/i2c-hwmon-split-05.patch i2c/i2c-hwmon-split-06.patch i2c/i2c-hwmon-split-07.patch i2c/i2c-hwmon-split-08.patch i2c/i2c-hwmon-split-09.patch >From [EMAIL PROTECTED] Tue Jul 19 18:12:04 2005 Date: Wed, 20 Jul 2005 00:09:03 +0200 From: Jean Delvare <[EMAIL PROTECTED]> To: LKML , LM Sensors <[EMAIL PROTECTED]> Cc: Greg KH <[EMAIL PROTECTED]> Subject: I2C: Separate non-i2c hwmon drivers from i2c-core (9/9) Message-Id: <[EMAIL PROTECTED]> Move the definitions of i2c_is_isa_client and i2c_is_isa_adapter from i2c.h to i2c-isa.h. Only hybrid drivers still need them. Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- include/linux/i2c-isa.h |7 +++ include/linux/i2c.h |7 --- 2 files changed, 7 insertions(+), 7 deletions(-) --- gregkh-2.6.orig/include/linux/i2c-isa.h 2005-07-26 15:14:08.0 -0700 +++ gregkh-2.6/include/linux/i2c-isa.h 2005-07-26 15:16:51.0 -0700 @@ -26,4 +26,11 @@ extern int i2c_isa_add_driver(struct i2c_driver *driver); extern int i2c_isa_del_driver(struct i2c_driver *driver); +/* Detect whether we are on the isa bus. This is only useful to hybrid + (i2c+isa) drivers. */ +#define i2c_is_isa_client(clientptr) \ +((clientptr)->adapter->algo->id == I2C_ALGO_ISA) +#define i2c_is_isa_adapter(adapptr) \ +((adapptr)->algo->id == I2C_ALGO_ISA) + #endif /* _LINUX_I2C_ISA_H */ --- gregkh-2.6.orig/include/linux/i2c.h 2005-07-26 15:16:45.0 -0700 +++ gregkh-2.6/include/linux/i2c.h 2005-07-26 15:16:51.0 -0700 @@ -575,11 +575,4 @@ .force =force, \ } -/* Detect whether we are on the isa bus. If this returns true, all i2c - access will fail! */ -#define i2c_is_isa_client(clientptr) \ -((clientptr)->adapter->algo->id == I2C_ALGO_ISA) -#define i2c_is_isa_adapter(adapptr) \ -((adapptr)->algo->id == I2C_ALGO_ISA) - #endif /* _LINUX_I2C_H */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels - how to keep on the bleeding edge?
Andrew Morton <[EMAIL PROTECTED]> wrote: > > I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5 > times a day), but there's no guarantee that it'll compile, let alone run. > I could also send a notification to mm-commits when I do so. Would that > help? OK, I did that. The directory at kernel.org will get quite large, so I'll probably manually delete things occasionally. The kernel.org propagation delay is a bit of a hassle. I could use zip.com.au but I suspect they hate me enough already. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [swsusp] encrypt suspend data for easy wiping
Hi! > > > the attached patches are acked by Pavel and signed off by me > > > > OK, well I queued this up, without a changelog. Because you didn't send > > one. Please do so. As it adds a new feature, quite a bit of info is > > relevant. > > I don't like this patch. It reinvents a fair amount of dm_crypt and > cryptoloop but badly. > > Further, the model of security it's using is silly. In case anyone > hasn't noticed, it stores the password on disk in the clear. This is > so it can erase it after resume and thereby make recovery of the > suspend image hard. > > But laptops get stolen while they're suspended, not while they're up > and running. And if your box is up and running and an attacker gains > access, the contents of your suspend partition are the least of your > worries. It makes no sense to expend any effort defending against this > case, especially as it's liable to become a barrier to doing this > right, namely with real dm_crypt encrypted swap. I do not see why it should be liability. Even if you "properly" encrypt the swap, you'll want to wipe old data after resume. If you take the random key (currently used), and encrypt with public key; then ask for private key on reboot; it should do the trick. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12 1/1] docs: updated some code docs
Updated docs about how to write and submit patches/code. diff -Nuar old/Documentation/CodingStyle new/Documentation/CodingStyle --- old/Documentation/CodingStyle 2005-07-26 00:10:55.0 +0200 +++ new/Documentation/CodingStyle 2005-07-25 23:58:37.0 +0200 @@ -422,10 +422,13 @@ URL: http://cm.bell-labs.com/cm/cs/tpop/ GNU manuals - where in compliance with K and this text - for cpp, gcc, -gcc internals and indent, all available from http://www.gnu.org +gcc internals and indent, all available from http://www.gnu.org/manual/ WG14 is the international standardization working group for the programming language C, URL: http://std.dkuug.dk/JTC1/SC22/WG14/ +Kernel CodingStyle by [EMAIL PROTECTED] at OLS 2002: +http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ + -- Last updated on 16 February 2004 by a community effort on LKML. diff -Nuar old/Documentation/SubmittingDrivers new/Documentation/SubmittingDrivers --- old/Documentation/SubmittingDrivers 2005-07-26 00:11:01.0 +0200 +++ new/Documentation/SubmittingDrivers 2005-07-27 00:07:10.0 +0200 @@ -26,17 +26,17 @@ Linux 2.0: - No new drivers are accepted for this kernel tree + No new drivers are accepted for this kernel tree. Linux 2.2: + No new drivers are accepted for this kernel tree. + +Linux 2.4: If the code area has a general maintainer then please submit it to the maintainer listed in MAINTAINERS in the kernel file. If the maintainer does not respond or you cannot find the appropriate - maintainer then please contact Alan Cox <[EMAIL PROTECTED]> - -Linux 2.4: - The same rules apply as 2.2. The final contact point for Linux 2.4 - submissions is Marcelo Tosatti <[EMAIL PROTECTED]>. + maintainer then please contact Marcelo Tosatti + <[EMAIL PROTECTED]>. Linux 2.6: The same rules apply as 2.4 except that you should follow linux-kernel @@ -51,6 +51,7 @@ of exclusively GPL licensing, and if you wish the driver to be useful to other communities such as BSD you may well wish to release under multiple licenses. + See accepted licenses at include/linux/module.h Copyright: The copyright owner must agree to use of GPL. It's best if the submitter and copyright owner @@ -141,5 +142,13 @@ http://kernelnewbies.org/ Linux USB project: - http://sourceforge.net/projects/linux-usb/ + http://linux-usb.sourceforge.net/ + +How to NOT write kernel driver by [EMAIL PROTECTED] + http://people.redhat.com/arjanv/olspaper.pdf + +Kernel Janitor: + http://janitor.kernelnewbies.org/ +-- +Last updated on 25 Jul 2005. diff -Nuar old/Documentation/SubmittingPatches new/Documentation/SubmittingPatches --- old/Documentation/SubmittingPatches 2005-07-26 00:11:01.0 +0200 +++ new/Documentation/SubmittingPatches 2005-07-27 00:03:56.0 +0200 @@ -35,7 +35,7 @@ To create a patch for a single file, it is often sufficient to do: - SRCTREE= linux-2.4 + SRCTREE= linux-2.6 MYFILE= drivers/net/mydriver.c cd $SRCTREE @@ -48,9 +48,9 @@ or unmodified kernel source tree, and generate a diff against your own source tree. For example: - MYSRC= /devel/linux-2.4 + MYSRC= /devel/linux-2.6 - tar xvfz linux-2.4.0-test11.tar.gz + tar xvfz linux-2.6.0.tar.gz mv linux linux-vanilla wget http://www.moses.uklinux.net/patches/dontdiff diff -uprN -X dontdiff linux-vanilla $MYSRC > /tmp/patch @@ -77,7 +77,7 @@ http://developer.osdl.org/rddunlap/scripts/patching-scripts.tgz Andrew Morton's patch scripts: -http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.16 +http://www.zip.com.au/~akpm/linux/patches/ 2) Describe your changes. @@ -94,7 +94,7 @@ 3) Separate your changes. -Separate each logical change into its own patch. +Separate each _logical changes_ into its own patch. For example, if your changes include both bug fixes and performance enhancements for a single driver, separate those changes into two @@ -102,13 +102,17 @@ driver which uses that new API, separate those into two patches. On the other hand, if you make a single change to numerous files, -group those changes into a single patch. Thus a single logical change -is contained within a single patch. +group those changes into a single patch. Thus single logical changes +are contained within a single patch. If one patch depends on another patch in order for a change to be complete, that is OK. Simply note "this patch depends on patch X" in your patch description. +If you cannot condense your patch set into a smaller set of patches, +then only post say 15 or so at a time and wait for review and integration. + + 4) Select e-mail destination. @@ -121,6 +125,8 @@ [EMAIL PROTECTED] Most kernel developers monitor this e-mail list, and can comment on your changes. +Do not send more than 15 patches at once to the vger mailing lists!!! + Linus Torvalds is the final arbiter of all changes accepted into the Linux kernel. His e-mail address is <[EMAIL PROTECTED]>.
Reclaim space from unused ramdisk?
I wonder if it would be possible to somehow reclaim space that has been previously reserved for a ramdisk without rebooting. I read the ramdisk docs in the latest kernel source and it seems that it is not currently possible. However, the kernel keeps track of the memory allocated for said ramdisks; would it not be possible with root (or even kernel) permissions to remove the flag that prevents the VM subsystem from reclaiming that space? I realize that rot permissions may not be high enough. In that case, could a module be written that takes a device name as a parameter then uses it to look up the reserved memory that device uses, then resets the necessary flag and finally unloads itself? It would have to check that the filesystem was unmounted, of course. How difficult would this be to write? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [swsusp] encrypt suspend data for easy wiping
Hi! > > > the attached patches are acked by Pavel and signed off by me > > > > OK, well I queued this up, without a changelog. Because you didn't send > > one. Please do so. As it adds a new feature, quite a bit of info is > > relevant. > > I don't like this patch. It reinvents a fair amount of dm_crypt and > cryptoloop but badly. > > Further, the model of security it's using is silly. In case anyone > hasn't noticed, it stores the password on disk in the clear. This is > so it can erase it after resume and thereby make recovery of the > suspend image hard. > > But laptops get stolen while they're suspended, not while they're up > and running. And if your box is up and running and an attacker gains > access, the contents of your suspend partition are the least of your > worries. It makes no sense to expend any effort defending against this > case, especially as it's liable to become a barrier to doing this > right, namely with real dm_crypt encrypted swap. Well, "how long are my keys going to stay in swap after swsusp"... that's pretty scary. To prevent "stolen while suspended" case... you'd either need to enter password both during suspend and during resume, or you'd need asymetric crypto... Rather heavy. > At the very least, this should be renamed SWSUSP_QUICK_WIPE and any > mention of encryption should be taken out of the description so users > don't mistakenly think it provides any sort of useful protection. SWSUSP_WIPE seems like a better name, right. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
On Tue, 2005-07-26 at 16:33, Martin J. Bligh wrote:
> >> > After KS & OLS discussions about memory pressure, I wanted to re-do
> >> > iSCSI testing with "dd"s to see if we are throttling writes.
> >>
> >> Could you also try with shared writable mmap, to see if that
> >> works ok or triggers a deadlock ?
> >
> >
> > I can, but lets finish addressing one issue at a time. Last time,
> > I changed too many things at the same time and got no where :(
>
> Adam is working that one, but not over iSCSI.
I wrote a simple/ugly C program to demonstrate the MAP_SHARED,PROT_WRITE
case. I was able to saturate the system with 75% of all memory in dirty
pages before I got bored.
To reproduce:
- Create a 3GB file with dd
- ./map-shared-dirty bigfile
I break up the mmap & dirty operation into chunks in case the system is
tight on memory. Choose a large enough number of chunks so the
individual mmaps will be small enough for your system to accomodate.
--
MemTotal: 4092492 kB
MemFree:786988 kB
Buffers: 6372 kB
Cached:3211388 kB
SwapCached: 0 kB
Active:3197428 kB
Inactive:36696 kB
HighTotal: 3211264 kB
HighFree: 1024 kB
LowTotal: 881228 kB
LowFree:785964 kB
SwapTotal: 0 kB
SwapFree:0 kB
Dirty: 3117300 kB
Writeback:3568 kB
Mapped: 24780 kB
Slab:59316 kB
Committed_AS:49760 kB
PageTables:780 kB
VmallocTotal: 114680 kB
VmallocUsed:32 kB
VmallocChunk: 114648 kB
/*
* map-shared-dirty.c - Demonstrate a loophole in dirty-ratio when
* heavily dirtying MAP_SHARED memory.
*
* Usage: (I know it's ugly)
* ./map-shared-dirty
*/
#include
#include
#include
#include
#include
#include
#include
size_t page_size;
void dirty_file(int fd, unsigned long bytes, size_t map_offset) {
char *addr;
addr = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_SHARED, fd,
map_offset);
if (addr == MAP_FAILED) {
fprintf(stderr, "Failed to map file\n");
fprintf(stderr, "bytes: %i offset: %i\n", bytes,map_offset);
exit(1);
}
/* Dirty the pages */
memset(addr, map_offset%255, bytes);
munmap(addr, bytes);
}
int main(int argc, char **argv)
{
char *filename = argv[1];
int chunks = atoi(argv[2]);
int fd;
unsigned long i, chunk_size, bytes;
struct stat file_info;
fd = open(filename, O_RDWR|010); /* O_LARGEFILE */
if (fd <= 0) {
fprintf(stderr, "Failed to open file\n");
exit(1);
}
fstat(fd, _info);
bytes = file_info.st_size;
page_size = getpagesize();
chunk_size = (bytes / chunks) & ~(page_size - 1);
printf("Chunk size = %i\n", chunk_size);
for (i = 0; i < bytes; i+=chunk_size)
dirty_file(fd, chunk_size, i);
exit(0);
}
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > On Tue, 2005-07-26 at 14:24 -0700, Andrew Morton wrote: > > Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > > > > > ext2 is incredibly better. Machine is very responsive. > > > > > > > OK. Please, always monitor and send /proc/meminfo. I assume that the > > dirty-memory clamping is working OK with ext2 and that perhaps it'll work > > OK with ext3/data=writeback. > > Nope. Dirty is still very high.. That's a relief in a way. Can you please try decreasing the number of filesystems 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: [swsusp] encrypt suspend data for easy wiping
On Mon, Jul 25, 2005 at 08:10:36PM -0700, Andrew Morton wrote: > Andreas Steinmetz <[EMAIL PROTECTED]> wrote: > > > > the attached patches are acked by Pavel and signed off by me > > OK, well I queued this up, without a changelog. Because you didn't send > one. Please do so. As it adds a new feature, quite a bit of info is > relevant. I don't like this patch. It reinvents a fair amount of dm_crypt and cryptoloop but badly. Further, the model of security it's using is silly. In case anyone hasn't noticed, it stores the password on disk in the clear. This is so it can erase it after resume and thereby make recovery of the suspend image hard. But laptops get stolen while they're suspended, not while they're up and running. And if your box is up and running and an attacker gains access, the contents of your suspend partition are the least of your worries. It makes no sense to expend any effort defending against this case, especially as it's liable to become a barrier to doing this right, namely with real dm_crypt encrypted swap. At the very least, this should be renamed SWSUSP_QUICK_WIPE and any mention of encryption should be taken out of the description so users don't mistakenly think it provides any sort of useful protection. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
patch i2c-ds1337-12-24-mode-fix.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled Subject: I2C: ds1337 - fix 12/24 hour mode bug to my gregkh-2.6 tree. Its filename is i2c-ds1337-12-24-mode-fix.patch This tree can be found at http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are devfs/devfs-remove-devfs-tape.patch devfs/devfs-die-die-die.patch devfs/devfs-remove-devfs_mk_symlink.patch devfs/devfs-remove-devfs_mk_bdev.patch devfs/devfs-remove-devfs_mk_dir.patch devfs/devfs-scrub-partitions.patch devfs/devfs-scrub-init.patch devfs/devfs-remove-devfs_mk_cdev.patch devfs/devfs-remove-devfs_remove.patch devfs/devfs-remove-devfs_fs_kernel.h.patch devfs/devfs-remove-misc-devfs_name.patch devfs/devfs-remove-genhd-devfs_name.patch devfs/devfs-remove-videodev-devfs_name.patch devfs/devfs-remove-serial-devfs_name.patch devfs/devfs-remove-ide-devfs_name.patch devfs/devfs-remove-line-devfs_name.patch devfs/devfs-remove-scsi-devfs_name.patch devfs/devfs-remove-tty-devfs_name.patch devfs/devfs-remove-usb-mode.patch devfs/devfs-tty_driver_no_devfs.patch devfs/devfs-minor-cleanups.patch devfs/devfs-remove-documentation.patch devfs/ndevfs.patch driver/securityfs.patch driver/driver-sample.sh.patch gregkh/gregkh-debugfs_example.patch gregkh/gregkh-kobject-warn.patch gregkh/gregkh-laptop-sysrq.patch gregkh/gregkh-usb-hacking.patch gregkh/gregkh-usb-minors.patch i2c/i2c-max6875-documentation-update.patch i2c/i2c-max6875-simplify.patch i2c/i2c-mpc-restore-code-removed.patch i2c/i2c-hwmon-class-01.patch i2c/i2c-hwmon-class-02.patch i2c/i2c-hwmon-class-03.patch i2c/i2c-missing-space.patch i2c/i2c-ds1337-12-24-mode-fix.patch i2c/i2c-nforce2-cleanup.patch pci/pci-acpi-mcfg-04.patch >From [EMAIL PROTECTED] Mon Jul 25 10:41:08 2005 Date: Mon, 25 Jul 2005 10:24:36 +0200 To: Greg KH <[EMAIL PROTECTED]> Cc: James Chapman <[EMAIL PROTECTED]>, LKML Subject: I2C: ds1337 - fix 12/24 hour mode bug Message-ID: <[EMAIL PROTECTED]> From: Ladislav Michl <[EMAIL PROTECTED]> DS1339 manual, page 6, chapter Date and time operation: The DS1339 can be run in either 12-hour or 24-hour mode. Bit 6 of the hours register is defined as the 12-hour or 24-hour mode-select bit. When high, the 12-hour mode is selected. Patch below makes ds1337 driver work as documented in manual. Signed-off-by: Ladislav Michl <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/i2c/chips/ds1337.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) --- gregkh-2.6.orig/drivers/i2c/chips/ds1337.c 2005-07-13 09:45:05.0 -0700 +++ gregkh-2.6/drivers/i2c/chips/ds1337.c 2005-07-26 15:02:26.0 -0700 @@ -165,7 +165,7 @@ buf[0] = 0; /* reg offset */ buf[1] = BIN2BCD(dt->tm_sec); buf[2] = BIN2BCD(dt->tm_min); - buf[3] = BIN2BCD(dt->tm_hour) | (1 << 6); + buf[3] = BIN2BCD(dt->tm_hour); buf[4] = BIN2BCD(dt->tm_wday) + 1; buf[5] = BIN2BCD(dt->tm_mday); buf[6] = BIN2BCD(dt->tm_mon) + 1; @@ -344,9 +344,9 @@ /* Ensure that device is set in 24-hour mode */ val = i2c_smbus_read_byte_data(client, DS1337_REG_HOUR); - if ((val >= 0) && (val & (1 << 6)) == 0) + if ((val >= 0) && (val & (1 << 6))) i2c_smbus_write_byte_data(client, DS1337_REG_HOUR, - val | (1 << 6)); + val & 0x3f); } static int ds1337_detach_client(struct i2c_client *client) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.13-rc3-git4] VIA686A polymorphs into VIA586!
Aleksey Gorelov wrote:
> >This patch brings my board back to the correct behaviour
> >[Aleksey Gorelov CC'd for review/comments/suggestions]:
> >
> >--- linux-2.6.13-git4/arch/i386/pci/irq.c.org2005-07-23
> >11:15:12.0 +0200
> >+++ linux-2.6.13-git4/arch/i386/pci/irq.c2005-07-23
> >11:55:50.0 +0200
> >@@ -553,10 +553,12 @@
> > switch(device)
> > {
> > case PCI_DEVICE_ID_VIA_82C586_0:
> >-r->name = "VIA";
> >-r->get = pirq_via586_get;
> >-r->set = pirq_via586_set;
> >-return 1;
> >+if (router->device==PCI_DEVICE_ID_VIA_82C586_0) {
> >+r->name = "VIA";
> >+r->get = pirq_via586_get;
> >+r->set = pirq_via586_set;
> >+return 1;
> >+}
> > case PCI_DEVICE_ID_VIA_82C596:
> > case PCI_DEVICE_ID_VIA_82C686:
> > case PCI_DEVICE_ID_VIA_8231:
>
> Probably, comments on buggy BIOS would be nice here..
>
Does this patch look good for you?
Who's the right developer to ask for inclusion? I'd like to see this problem
addressed before 2.6.13...
Thanks,
Giancarlo
--- linux-2.6.13-git4/arch/i386/pci/irq.c.org 2005-07-23 11:15:12.0
+0200
+++ linux-2.6.13-git4/arch/i386/pci/irq.c 2005-07-26 20:53:11.0
+0200
@@ -550,6 +550,13 @@
static __init int via_router_probe(struct irq_router *r, struct pci_dev
*router, u16 device)
{
/* FIXME: We should move some of the quirk fixup stuff here */
+
+ if (router->device == PCI_DEVICE_ID_VIA_82C686 &&
+ device == PCI_DEVICE_ID_VIA_82C586_0) {
+ /* Asus k7m bios wrongly reports 82C686A as 586-compatible */
+ device = PCI_DEVICE_ID_VIA_82C686;
+ }
+
switch(device)
{
case PCI_DEVICE_ID_VIA_82C586_0:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
On Sat, 23 Jul 2005 at 10:38:40 -0700 (PDT), Linus Torvalds wrote: > On Sat, 23 Jul 2005, Chuck Ebbert wrote: > > > > This patch (may not apply cleanly to unpatched -rc3) drops overhead > > a few more percent: > > That really is pretty ugly. > > I'd rather hope for something like function-sections to just make games > like this be unnecessary. The link stage might cause meltdown on typical machines, though. __ Chuck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI: fix up errors after dma bursting patch and CONFIG_PCI=n -- bug?
On Jul 26, 2005, at 12:50 PM, Greg KH wrote:
On Mon, Jul 25, 2005 at 11:52:43PM -0500, Kumar Gala wrote:
Andrew,
In the patch from:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0506.3/0985.html
Is the the following line suppose inside the if CONFIG_PCI=n
#define pci_dma_burst_advice(pdev, strat, strategy_parameter) do
{ }
while (0)
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
Hm, how did that work?
I'm somewhat baffled by that as well. I did a full build regression
of the 50 PPC32 defconfigs and only one broke because of this. I'm
still a bit confused as to why.
Bah, that pci.h file needs some major cleanups, I'll apply this patch
and clean up the rest to make it more sane.
Cool, just want to make sure the minor fix makes it to linus before
2.6.13.
- kumar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
On Tue, 26 Jul 2005, Chuck Ebbert wrote: > > Since fxsave leaves the FPU state intact, there ought to be a better way to > do > this but it gets tricky. Maybe using the TSC to put a timestamp in every > thread > save area? We used to have totally lazy FP saving, and not toucht he FP state at _all_ in the scheduler except to just set the TS bit. It worked wonderfully well on UP, but getting it working on SMP is a major pain, since the lazy state you want to switch back into might be cached on some other CPU's registers, so we never did it on SMP. Eventually it got too painful to maintain two totally different logical code-paths between UP and SMP, and some bug or other ended up resulting in the current "lazy on a time slice level" thing which works well in SMP too. Also, a lot of the cost is really the save, and before SSE2 the fnsave would clear the FPU state, so you couldn't just do a save and try to elide just the restore in the lazy case. In SSE2 (with fxsave) we _could_ try to do that, but the thing is, I doubt it really helps. First off, 99% of all programs don't hit the nasty case at all, and for something broken like volanomark that _does_ hit it, I bet that there i smore than one thread using the FP, so you can't just cache the FP state in the CPU _anyway_. So we could enhance the current state by having a "nonlazy" mode like in the example patch, except we'd have to make it a dynamic flag. Which could either be done by explicitly marking binaries we want to be non-lazy, or by just dynamically noticing that the rate of FP restores is very high. Does anybody really care about volanomark? Quite frankly, I think you'd see a _lot_ more performance improvement if you could instead teach the Java stuff not to use FP all the time, so it feels a bit like papering over the _real_ bug if we'd try to optimize this abnormal and silly case in the kernel. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
On Tue, 2005-07-26 at 14:24 -0700, Andrew Morton wrote: > Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > > > ext2 is incredibly better. Machine is very responsive. > > > > OK. Please, always monitor and send /proc/meminfo. I assume that the > dirty-memory clamping is working OK with ext2 and that perhaps it'll work > OK with ext3/data=writeback. Nope. Dirty is still very high.. # cat /proc/meminfo MemTotal: 7143628 kB MemFree: 33248 kB Buffers: 8368 kB Cached:6789932 kB SwapCached: 0 kB Active: 51316 kB Inactive: 6769144 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 7143628 kB LowFree: 33248 kB SwapTotal: 1048784 kB SwapFree: 1048780 kB Dirty: 6605704 kB Writeback: 168452 kB Mapped: 49724 kB Slab: 252200 kB CommitLimit: 4620596 kB Committed_AS: 163524 kB PageTables: 2284 kB VmallocTotal: 34359738367 kB VmallocUsed: 9888 kB VmallocChunk: 34359728447 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] schedule obsolete OSS drivers for removal
Zach Brown <[EMAIL PROTECTED]> writes: > I haven't touched the maestro drivers in so long (for near-total lack of > docs, etc.) that I can't be considered authoritative for approving it's > removal. Maestro3 ALSA does work fine for me. -- 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: MM kernels - how to keep on the bleeding edge?
Michael Krufky <[EMAIL PROTECTED]> wrote: > > [ tracking mm stuff ] > Sigh, sorry. It's hard. -mm is always in flux. I no longer send out the `patch was dropped' message because it disturbs people. The mm-commits list does not resend a patch when it is changed (other patches folded into it, rejects fixed, changelog updated, rediffed, etc). Sometimes I'll comment out a patch but not fully drop it. I pull all the git trees at least twice a day and that's not reflected on the mm-commits list either. You can always tell when a -mm release is coming by watching the shower of stupid compile fixes emerging :( I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5 times a day), but there's no guarantee that it'll compile, let alone run. I could also send a notification to mm-commits when I do so. Would that help? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] e1000: no need for reboot notifier
>> sys_reboot() now calls device_suspend(), so it is no longer necessary for >> the e1000 driver to register a reboot notifier [in fact doing so results >> in e1000_suspend() getting called twice]. > >Does this fix the ia64 reboot, or do we still have the >mpt-fusion problem? We still have the mpt-fusion problem :-( That one appears to be more convoluted ... we don't seem to be calling the suspend functions more than once, but I still see the "Badness" messages from iosapic_unregister_intr(). There may also be an ordering problem where we shutdown some bits of mpt-fusion, and then later call the suspend function for another layer to sync out some SCSI stuff, but it is toast because the device is already down. -Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [PATCH] 2.6.13-rc3-git5: fix Bug #4416 (2/2)
On Tuesday, 26 of July 2005 23:11, Peter Buckingham wrote: > Rafael J. Wysocki wrote: > > On Tuesday, 26 of July 2005 14:25, Carl-Daniel Hailfinger wrote: > >>The current in-kernel sk98lin driver is years behind the version > >>downloadable from Syskonnect. Maybe it would make sense to update > >>it first before applying any new patches. > >>http://www.syskonnect.com/support/driver/d0102_driver.html > > > > > > You are right, but I don't know who should do this. I have only submitted > > the patch to eliminate a problem with the current kernel. > > have a look at the skge driver, this is a cleaned up version of the > sk98lin. Although it doesn't support all of the devices, ie ones based > on the Yukon 2. Thanks for the hint, I will. From the first look it's missing the free_irq()/request_irq() on suspend/resume however. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory pressure handling with iSCSI
>> > After KS & OLS discussions about memory pressure, I wanted to re-do >> > iSCSI testing with "dd"s to see if we are throttling writes. >> >> Could you also try with shared writable mmap, to see if that >> works ok or triggers a deadlock ? > > > I can, but lets finish addressing one issue at a time. Last time, > I changed too many things at the same time and got no where :( Adam is working that one, but not over iSCSI. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
On Fri, 22 Jul 2005 at 11:13:21 -0700 (PDT), Linus Torvalds wrote: > Something like the following (totally untested) should make it be > non-lazy. It's going to slow down normal task switches, but might speed up > the "restoring FP context all the time" case. > > Chuck? This should work fine with or without your inline thing. Does it > make any difference? Now that I am looking at the right output file -- yes, it does (after fixing one small bug.) Volanomark set a new record of 6125 messages/sec and the profile shows almost zero hits in math_state_restore. Since fxsave leaves the FPU state intact, there ought to be a better way to do this but it gets tricky. Maybe using the TSC to put a timestamp in every thread save area? when saving FPU state: put cpu# and timestamp in thread state info also store timestamp in per-cpu data on task switch: compare cpu# and timestamps for next task if equal, clear TS and set TS_USEDFPU when state becomes invalid for some reason: zero cpu's timestamp But the extra overhead might be too much in many cases. (Below is what I changed in the original patch, if anyone wants to try it.) + if (tsk_used_math(next_p)) should be: + if (!tsk_used_math(next_p)) __ Chuck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] e1000: no need for reboot notifier
[EMAIL PROTECTED] wrote: > > sys_reboot() now calls device_suspend(), so it is no longer necessary for > the e1000 driver to register a reboot notifier [in fact doing so results > in e1000_suspend() getting called twice]. Does this fix the ia64 reboot, or do we still have the mpt-fusion 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/
