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
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
"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
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
"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
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
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
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
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
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
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
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
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
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
[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
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
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
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
> 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
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:
> 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
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
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
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
> >
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
"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
> 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
>
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
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)
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
>-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
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
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.
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
[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
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
[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
> >
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
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.
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
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
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
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
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
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
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
> >
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,
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
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
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
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
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
>
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
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
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.
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.
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
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
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
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
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
> > 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
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
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
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
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.
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
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
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
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 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
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.
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-delalloc
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.
> > > >
>
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
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
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
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
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
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.
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
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:
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
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
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
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
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
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
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.c
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
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
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
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
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
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,
>> 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
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
>
>> > 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
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
[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?
1 - 100 of 674 matches
Mail list logo
