On Jan 24 2008 15:17, Linus Torvalds wrote:
>
>The release is out there (both git trees and as tarballs/patches), and for
>the next week many kernel developers will be at (or flying into/out of)
>LCA in Melbourne, so let's hope it's a good one.
|type commit
|tag v2.6.24
|tagger Linus Torvalds <
Li Zefan wrote:
> Miguel Botón 写道:
>> Li Zefan wrote:
>>> Add CCs:
>>>
>>> CC: [EMAIL PROTECTED]
>>> CC: [EMAIL PROTECTED]
>>> CC: [EMAIL PROTECTED]
>>>
>>> Li Zefan wrote:
drivers/net/b44.c: In function 'b44_remove_one':
drivers/net/b44.c:2231: error: implicit declaration of function
>>
Miguel Botón 写道:
> Li Zefan wrote:
>> Add CCs:
>>
>> CC: [EMAIL PROTECTED]
>> CC: [EMAIL PROTECTED]
>> CC: [EMAIL PROTECTED]
>>
>> Li Zefan wrote:
>>> drivers/net/b44.c: In function 'b44_remove_one':
>>> drivers/net/b44.c:2231: error: implicit declaration of function
>>> 'ssb_pcihost_set_power_sta
Li Zefan wrote:
> Add CCs:
>
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
>
> Li Zefan wrote:
>> drivers/net/b44.c: In function 'b44_remove_one':
>> drivers/net/b44.c:2231: error: implicit declaration of function
>> 'ssb_pcihost_set_power_state'
>> make[2]: *** [driver
Add CCs:
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Li Zefan wrote:
> drivers/net/b44.c: In function 'b44_remove_one':
> drivers/net/b44.c:2231: error: implicit declaration of function
> 'ssb_pcihost_set_power_state'
> make[2]: *** [drivers/net/b44.o] Error 1
> make[1]: **
* Stefan Richter <[EMAIL PROTECTED]> wrote:
> [...] How will subscribers of LKML decide which discussion threads in
> the huge amount of traffic are worth to glance at? Each of us has
> only a limited amount of time for LKML consumption.
uhm. How do you decide which of the 1 git commits p
On Sat, 26 Jan 2008 01:42:43 +0100, Stefan Richter said:
> Even if you only look at the Subject: and number of postings in a
> thread, how to judge whether there is a stability risk for the next -rc
> in the making, without experience or personal interest in the domain?
My general rule of thumb i
On Sat, 26 Jan 2008 00:50:44 +0100, Stefan Richter said:
> How often is "bisectability" being broken already before merge in
> subsystem trees, and how often only in the context of the merge result?
I don't bisect git trees often - but I'd say that at least half the time
I have to bisect -mm, I'll
(I already deleted the posting I'm going to reply to, therefore
References and In-Reply-To are wrong. Sorry.)
On 2008-01-25, Ingo Molnar wrote in http://lkml.org/lkml/2008/1/25/320:
> * Giacomo A. Catenazzi <[EMAIL PROTECTED]> wrote:
>> As a tester, I'm not so happy.
>> The last few merge windows
Giacomo A. Catenazzi wrote:
>> On Friday, 25 of January 2008, [EMAIL PROTECTED] wrote:
[-mm]
>>> should flush out most of the truly stupid mistakes, but those are
>>> usually found and fixed literally within hours. Anyhow, the proper
>>> time for test compiles is *before* it goes into the git tree
Rafael J. Wysocki wrote:
On Friday, 25 of January 2008, [EMAIL PROTECTED] wrote:
On Fri, 25 Jan 2008 10:10:11 +0100, "Giacomo A. Catenazzi" said:
- you will introduce a new step on git management:
Every changeset is compile-tested before going out to the world.
I think this can be done a
On Friday, 25 of January 2008, [EMAIL PROTECTED] wrote:
> On Fri, 25 Jan 2008 10:10:11 +0100, "Giacomo A. Catenazzi" said:
>
> > As a tester I would like:
> > - slow merges, so that developer could rebase and test
> >(compile test) the interaction of the new code.
>
> An amazing amount of stu
* Giacomo A. Catenazzi <[EMAIL PROTECTED]> wrote:
> Linus Torvalds wrote:
>>
>> On Thu, 24 Jan 2008, Linus Torvalds wrote:
>>> The release is out there (both git trees and as tarballs/patches), and
>>> for the next week many kernel developers will be at (or flying into/out
>>> of) LCA in Melbou
On Fri, 25 Jan 2008 10:10:11 +0100, "Giacomo A. Catenazzi" said:
> As a tester I would like:
> - slow merges, so that developer could rebase and test
>(compile test) the interaction of the new code.
An amazing amount of stuff gets caught when it's tested in Andrew Morton's -mm
tree. You thin
Linus Torvalds wrote:
On Thu, 24 Jan 2008, Linus Torvalds wrote:
The release is out there (both git trees and as tarballs/patches), and for
the next week many kernel developers will be at (or flying into/out of)
LCA in Melbourne, so let's hope it's a good one.
Since I already had two kernel
On Thu, 24 Jan 2008, Linus Torvalds wrote:
>
> The release is out there (both git trees and as tarballs/patches), and for
> the next week many kernel developers will be at (or flying into/out of)
> LCA in Melbourne, so let's hope it's a good one.
Since I already had two kernel developers aski
On Jan 16, 2008 12:50 PM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 16 Jan 2008, Dave Young wrote:
> >
> > The kernel.org downloading seems not available, could you update?
>
> It should be there, but it may take a while to mirror out. It's definitely
> there on the master site alread
On Wed, 16 Jan 2008, Dave Young wrote:
>
> The kernel.org downloading seems not available, could you update?
It should be there, but it may take a while to mirror out. It's definitely
there on the master site already (and gitweb shows it, so the git repo has
already mirrored out at least to t
Hi, linus
The kernel.org downloading seems not available, could you update?
Regards
dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
J.A. Magallón wrote:
> I finally found the bad drive (the most obvious one as I would expect,
> it was recycled from an older box...).
> I tried removing completely the drive from power and controller, and then
> running with it powered but not connected. No single error any more on
> any of the ot
On Mon, 14 Jan 2008 08:57:35 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> J.A. Magallón wrote:
> > I'm still pending to pysically remove the disks (or at least unplug the
> > cable...), but I have realized a cusious thing: after some errors, the
> > kernel is lowering the disk speed (UDMA/133, th
J.A. Magallón wrote:
> I'm still pending to pysically remove the disks (or at least unplug the
> cable...), but I have realized a cusious thing: after some errors, the
> kernel is lowering the disk speed (UDMA/133, then 100, then 33):
That's the standard error handling behavior. Timeouts are like
On Thu, 10 Jan 2008 22:10:08 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> J.A. Magallón wrote:
> > It reproduces also with 2.6.23.13.
> > Finally I think the problematic disk is sdc:
>
> Okay, then, it's less likely a regression and more likely a newly
> developed hardware problem.
>
>
Hi,
J.A. Magallón wrote:
> It reproduces also with 2.6.23.13.
> Finally I think the problematic disk is sdc:
Okay, then, it's less likely a regression and more likely a newly
developed hardware problem.
> ICH5 PATA -> sda
> ICH5 SATA0 -> sdb
> ICH5 SATA1 -> sdc
> Promise SATA -> sdd
>
> The pro
On Wed, 09 Jan 2008 10:56:02 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> J.A. Magallón wrote:
> > HI all...
> >
> > On Sun, 6 Jan 2008 14:19:16 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
> > wrote:
> >
> >> It's been two weeks since rc6, but let's face it, with xmas and new years
> >> (
Hello,
> >>> Got this when doing usual looping over /proc entries on fresh test
> >>> kernel:
> >> What is the usual looping, please?
> >
> > #!/bin/bash
> >
> > for i in `find /proc -type f`; do
> > echo -n "cat $i > /dev/null ... ";
> > ( cat $i > /dev/null & );
> >
J.A. Magallón wrote:
> HI all...
>
> On Sun, 6 Jan 2008 14:19:16 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
> wrote:
>
>> It's been two weeks since rc6, but let's face it, with xmas and new years
>> (and birthdays) in between, there hasn't actually been a lot of working
>> days, and the i
Maciej Rutecki wrote:
> I have this message when resume from suspend to disk:
>
> hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> hda: MWDMA2 mode selected
> sd 0:0:0:0: [sda] Starting disk
> [...]
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ACPI cmd f5/00:00:00
On Jan 7, 2008 4:50 PM, J.A. Magallón <[EMAIL PROTECTED]> wrote:
> HI all...
>
> On Sun, 6 Jan 2008 14:19:16 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
> wrote:
>
> >
> > It's been two weeks since rc6, but let's face it, with xmas and new years
> > (and birthdays) in between, there hasn't act
On Sun, Jan 06, 2008 at 02:19:16PM -0800, Linus Torvalds wrote:
> Both git trees and tar-balls/patches pushed out, should be mirroring out
> within minutes. So there are no excuses to not try it out, and see if your
> favorite regression has been fixed.
At first glance, looks fine and fast here
* David Miller <[EMAIL PROTECTED]> wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Tue, 8 Jan 2008 23:56:31 +0100
>
> > is this anything the core lockdep code could help improve? Let us know
> > if any aspect is hindering you.
>
> No, it's a sparc64 issue.
>
> Another problem I ran int
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Tue, 8 Jan 2008 23:56:31 +0100
> is this anything the core lockdep code could help improve? Let us know
> if any aspect is hindering you.
No, it's a sparc64 issue.
Another problem I ran into are the huge static table sizes
lockdep uses. They really n
* David Miller <[EMAIL PROTECTED]> wrote:
> > WARNING: at kernel/lockdep_proc.c:267 lockdep_stats_show()
> > Call Trace:
> > [00492704] lockdep_stats_show+0x6ac/0x6c0
> > [004eb4b4] seq_read+0x5c/0x340
> > [0050b2bc] proc_reg_read+0x64/0xa0
> > [004cd72c] vfs_r
From: Mariusz Kozlowski <[EMAIL PROTECTED]>
Date: Tue, 8 Jan 2008 19:42:16 +0100
> Hello,
>
> Got this when doing usual looping over /proc entries on fresh test
> kernel:
>
> WARNING: at kernel/lockdep_proc.c:267 lockdep_stats_show()
> Call Trace:
> [00492704] lockdep_stats_show+
Mariusz Kozlowski wrote:
Hello,
Got this when doing usual looping over /proc entries on fresh test
kernel:
What is the usual looping, please?
#!/bin/bash
for i in `find /proc -type f`; do
echo -n "cat $i > /dev/null ... ";
( cat $i > /dev/null & );
echo "don
Hello,
> > Got this when doing usual looping over /proc entries on fresh test
> > kernel:
>
> What is the usual looping, please?
#!/bin/bash
for i in `find /proc -type f`; do
echo -n "cat $i > /dev/null ... ";
( cat $i > /dev/null & );
echo "done";
done
Regards,
On Tue, 8 Jan 2008 19:42:16 +0100 Mariusz Kozlowski wrote:
> Hello,
>
> Got this when doing usual looping over /proc entries on fresh test
> kernel:
What is the usual looping, please?
---
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Hello,
Got this when doing usual looping over /proc entries on fresh test
kernel:
WARNING: at kernel/lockdep_proc.c:267 lockdep_stats_show()
Call Trace:
[00492704] lockdep_stats_show+0x6ac/0x6c0
[004eb4b4] seq_read+0x5c/0x340
[0050b2bc] proc_reg_read+0x64/0xa0
On Tue, 8 Jan 2008 17:26:05 +0100
"Maciej Rutecki" <[EMAIL PROTECTED]> wrote:
> I have this message when resume from suspend to disk:
Looks fine to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
* Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi,
>
> When booting the 2.6.24-rc7 kernel on the powerpc, kernel bug at
> kernel.sched.c is triggered
>
> [0.00] Kernel command line: ro console=hvc0 rhgb quiet root=LABEL=/
> [0.149567] BUG: scheduling while atomic: kthreadd/2/0x000
I have this message when resume from suspend to disk:
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: MWDMA2 mode selected
sd 0:0:0:0: [sda] Starting disk
[...]
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
ata1.00: ACPI c
El Tue, 8 Jan 2008 16:30:30 +0100
Michael Buesch <[EMAIL PROTECTED]> escribió:
> On Monday 07 January 2008 21:23:44 Alejandro Riveira Fernández wrote:
>
> >
> > How can I check? The source code I build does indeed have the line
> > you quoted on net/mac80211/rx.c:1486 Is that what you are aski
On Monday 07 January 2008 21:23:44 Alejandro Riveira Fernández wrote:
> > > [ 37.043990] WARNING: at
> > > /home/alex/kernel/linux-2.6/net/mac80211/rx.c:1486 __ieee80211_rx()
> > > [ 37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3
> > >
On Tue, Jan 08, 2008 at 04:21:04PM +0530, Kamalesh Babulal wrote:
> Sam Ravnborg wrote:
> > On Mon, Jan 07, 2008 at 02:18:27PM +0530, Kamalesh Babulal wrote:
> >> Hi,
> >>
> >> The make allyesconfig build fails on x86_64 (AMD box) with the following
> >> error
> >>
> >> CHK include/linux/vers
Sam Ravnborg wrote:
> On Mon, Jan 07, 2008 at 02:18:27PM +0530, Kamalesh Babulal wrote:
>> Hi,
>>
>> The make allyesconfig build fails on x86_64 (AMD box) with the following
>> error
>>
>> CHK include/linux/version.h
>> CHK include/linux/utsrelease.h
>> CALLscripts/checksyscalls.s
On Tue, Jan 08, 2008 at 10:56:09AM +0100, Jean Delvare wrote:
> Hi Andrew, hi Chritoph,
>
> On Mon, 7 Jan 2008 11:38:31 -0800, Andrew Morton wrote:
> > On Mon, 7 Jan 2008 10:31:53 -0800 (PST)
> > Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, 7 Jan 2008, Andrew Morton wrote:
> > >
Hi Andrew, hi Chritoph,
On Mon, 7 Jan 2008 11:38:31 -0800, Andrew Morton wrote:
> On Mon, 7 Jan 2008 10:31:53 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 7 Jan 2008, Andrew Morton wrote:
> >
> > > > : undefined reference to `__you_cannot_kmalloc_that_much'
> >
> > T
Kamalesh Babulal wrote:
> Andrew Morton wrote:
>> On Mon, 07 Jan 2008 16:06:20 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
>> wrote:
>>
>>> The defconfig make fails on x86_64 (AMD box) with following error
>>>
>>> CHK include/linux/utsrelease.h
>>> CALLscripts/checksyscalls.sh
>>> CHK
Andrew Morton wrote:
> On Mon, 07 Jan 2008 16:06:20 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
>> The defconfig make fails on x86_64 (AMD box) with following error
>>
>> CHK include/linux/utsrelease.h
>> CALLscripts/checksyscalls.sh
>> CHK include/linux/compile.h
>> GE
On Mon, 07 Jan 2008 16:06:20 +0530, Kamalesh Babulal wrote:
> The defconfig make fails on x86_64 (AMD box) with following error
>
> CHK include/linux/utsrelease.h
> CALLscripts/checksyscalls.sh
> CHK include/linux/compile.h
> GEN .version
> CHK include/linux/compile.h
On Mon, 7 Jan 2008, Arjan van de Ven wrote:
> sounds like a bad idea; a compile time failure is of course nicer than
> a runtime failure for the cases we can find the bug at compile-time already.
>
There is not much chance of a runtime failure these days since kmalloc now
supports up to 4MB all
On Mon, 7 Jan 2008 10:31:53 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> We could replace the __you_cannot_kmalloc_that_much() with a BUG()
> statement so we have the same effect in SLAB?
>
sounds like a bad idea; a compile time failure is of course nicer than
a runtime failure fo
HI all...
On Sun, 6 Jan 2008 14:19:16 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
> It's been two weeks since rc6, but let's face it, with xmas and new years
> (and birthdays) in between, there hasn't actually been a lot of working
> days, and the incremental patch from -rc6 is a
El Mon, 7 Jan 2008 18:30:51 +0100
Michael Buesch <[EMAIL PROTECTED]> escribió:
> On Monday 07 January 2008 17:52:48 Alejandro Riveira Fernández wrote:
> > El Mon, 7 Jan 2008 17:24:03 +0100
> > Michael Buesch <[EMAIL PROTECTED]> escribió:
> >
> >
On Mon, 7 Jan 2008 10:31:53 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Mon, 7 Jan 2008, Andrew Morton wrote:
>
> > > : undefined reference to `__you_cannot_kmalloc_that_much'
>
> There is also a kernel.org bugzilla for this at
>
> http://bugzilla.kernel.org/show_bug.cgi?id=96
On Mon, 7 Jan 2008, Andrew Morton wrote:
> > : undefined reference to `__you_cannot_kmalloc_that_much'
There is also a kernel.org bugzilla for this at
http://bugzilla.kernel.org/show_bug.cgi?id=9669
For some reason my adds to this do not show up.
In both cases we have a
k(z/m)alloc(sizeof(*po
On Mon, 07 Jan 2008 16:06:20 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> The defconfig make fails on x86_64 (AMD box) with following error
>
> CHK include/linux/utsrelease.h
> CALLscripts/checksyscalls.sh
> CHK include/linux/compile.h
> GEN .version
> CHK inc
On Monday 07 January 2008 17:52:48 Alejandro Riveira Fernández wrote:
> El Mon, 7 Jan 2008 17:24:03 +0100
> Michael Buesch <[EMAIL PROTECTED]> escribió:
>
>
>
> >
> > Can you post the lines above this?
> > This
El Mon, 7 Jan 2008 17:24:03 +0100
Michael Buesch <[EMAIL PROTECTED]> escribió:
>
> Can you post the lines above this?
> This might be a WARN_ON_ONCE() triggering, for which fixes are on their way
> into
> the
On Monday 07 January 2008 17:14:15 Alejandro Riveira Fernández wrote:
> El Sun, 6 Jan 2008 14:19:16 -0800 (PST)
> Linus Torvalds <[EMAIL PROTECTED]> escribió:
>
> >
> > It's been two weeks since rc6, but let's face it, with xmas and new years
> > (and birthdays) in between, there hasn't actually
El Sun, 6 Jan 2008 14:19:16 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> escribió:
>
> It's been two weeks since rc6, but let's face it, with xmas and new years
> (and birthdays) in between, there hasn't actually been a lot of working
> days, and the incremental patch from -rc6 is about half
El Sun, 6 Jan 2008 14:19:16 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> escribió:
>
> It's been two weeks since rc6, but let's face it, with xmas and new years
> (and birthdays) in between, there hasn't actually been a lot of working
> days, and the incremental patch from -rc6 is about half
Hi,
When booting the 2.6.24-rc7 kernel on the powerpc, kernel bug at
kernel.sched.c is triggered
[0.00] Kernel command line: ro console=hvc0 rhgb quiet root=LABEL=/
[0.149567] BUG: scheduling while atomic: kthreadd/2/0x0006f34c
[0.149655] BUG: scheduling while atomic: kthreadd/3/
Hi,
The defconfig make fails on x86_64 (AMD box) with following error
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/linux/compile.h
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD
On Mon, Jan 07, 2008 at 02:18:27PM +0530, Kamalesh Babulal wrote:
> Hi,
>
> The make allyesconfig build fails on x86_64 (AMD box) with the following
> error
>
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALLscripts/checksyscalls.sh
> CHK include/linux/
Hi,
The make allyesconfig build fails on x86_64 (AMD box) with the following
error
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/linux/compile.h
CHK include/linux/version.h
make[2]: `scripts/unifdef' is up to date
Hello,
Linus Torvalds wrote:
> On Sun, 6 Jan 2008, Mark Lord wrote:
>> We're still missing the sata_qstor regression fix from Tejun,
>> and the patch from Venkatesh Pallipadi that reinstates max_cstate
>> in sysfs for !CPU_IDLE.
>
> I'm not seeing those in my inbox. I don't go out trolling for pa
On Sun, 6 Jan 2008, Mark Lord wrote:
>
> We're still missing the sata_qstor regression fix from Tejun,
> and the patch from Venkatesh Pallipadi that reinstates max_cstate
> in sysfs for !CPU_IDLE.
I'm not seeing those in my inbox. I don't go out trolling for patches,
because I expect that if th
Linus Torvalds wrote:
..
Both git trees and tar-balls/patches pushed out, should be mirroring out
within minutes. So there are no excuses to not try it out, and see if your
favorite regression has been fixed.
..
We're still missing the sata_qstor regression fix from Tejun,
and the patch from V
Hi;
21 Ara 2007 Cum tarihinde, Linus Torvalds şunları yazmıştı:
> Here's to a merry christmas, doing the whole druidic festival around the
> tree thing,
With -rc6, dmesg shows following Unknown symbols;
[...]
[ 26.883635] Bluetooth: Core ver 2.11
[ 26.913123] hci_usb: Unknown symbol hci_sus
On 2007.12.22 01:25:16 +0100, Harald Welte wrote:
>
> I'm running an Intel DQ35JO mainboard (Q35 chipset, Q6600 CPU) and I am
> observing a regression with linux-2.6.24-rc1 through -rc6 (linux-2.6.git as
> of today, ea67db4cdbbf7f4e74150e71da0984e25121f500).
>
> The last working version is 2.6.24
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Actually, the code to finding one '\n' is still needed to avoid the
> (pathological) case of getting a "\No newline", so scrap that one which
> was too aggressive, and use this (simpler) one instead.
>
> Not that it matters in real life, since nobody
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > +/*
> > + * Migration helpers - the proper API is the local_read_flags API.
> > + * Will go away in v2.6.26.
> > + */
> > +#define local_save_flags local_read_flags
> > +#define __local_save_flags __local_read_flags
> > +#define raw
On Fri, 21 Dec 2007 12:12:07 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > I'd suggest that we add a local_read_flags() along with
> > local_save_flags(). Then I can merge the parts of the patch which
> > don't get destroyed by ongoing churn
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> I'd suggest that we add a local_read_flags() along with
> local_save_flags(). Then I can merge the parts of the patch which
> don't get destroyed by ongoing churn and then we can come in and clean
> up the stragglers later.
ah, indeed.
like the pa
On Fri, 21 Dec 2007 11:27:27 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > local_read_flags().
> >
> > > that should have been raw_local_irq_save(flags)!
> >
> > So raw_local_save_flags() and raw_local_irq_save() have different semantics.
> >
> > omigawd, what have we done?
>
> i really tri
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > raw_local_save_flags() doesn't disable interrupts?
> >
> > argh. Indeed! (I wanted us to fix that misleading name eons ago, to
>
> The naming of those functions is truly awful and it goes back to year 0.
>
> > *_save_flags_only(), but some stup
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > btw, I think we should track this as a regression, please.
>
> Added, http://bugzilla.kernel.org/show_bug.cgi?id=9610, thanks.
fixed by:
commit c0a698b7443a9fce76b0a849f06c45ac78f3b0a0
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date: Fri Dec
On Thu, 20 Dec 2007, Linus Torvalds wrote:
>
> And here's the git patch to avoid this optimization when there is
> context.
Actually, the code to finding one '\n' is still needed to avoid the
(pathological) case of getting a "\No newline", so scrap that one which
was too aggressive, and use t
On Thu, Dec 20, 2007 at 08:40:54PM -0800, Linus Torvalds wrote:
> That was a rather long-winded explanation of what happened, mainly because
> it was all very unexpected to me, and I had personally mistakenly thought
> the git optimization was perfectly valid and actually had to go through
> the
On Thu, 20 Dec 2007, Linus Torvalds wrote:
>
> It only happened for a few files that had lots of repeated lines - so that
> the diff could literally be done multiple different ways - and in fact,
> the file that caused the problems really had a bogus commit that
> duplicated *way* too much da
On Thu, 20 Dec 2007, Linus Torvalds wrote:
>
> The tar-ball and the git archive itself is fine, but yes, the diff from
> 2.6.23 to 2.6.24-rc6 is bad. It's the "trim_common_tail()" optimization
> that has caused way too much pain.
Very interesting breakage. The patch was actually "correct" in
On Thu, 20 Dec 2007, Kyle McMartin wrote:
>
> I think I see the problem, it's lack of context in the diff,
No, the problem is that "git diff" is apparently broken by a recent
optimization. The diff is simply broken.
The tar-ball and the git archive itself is fine, but yes, the diff from
2.6.
On Thu, Dec 20, 2007 at 07:49:05PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 20 Dec 2007, Kyle McMartin wrote:
> >
> > I think I see the problem, it's lack of context in the diff,
>
> No, the problem is that "git diff" is apparently broken by a recent
> optimization. The diff is simply broken
On Thu, Dec 20, 2007 at 09:48:05PM -0500, Kyle McMartin wrote:
> 1 out of 3 hunks FAILED -- saving rejects to file
> drivers/video/mbx/reg_bits.h.rej
> error: Bad exit status from /var/tmp/rpm-tmp.22316 (%prep)
>
I think I see the problem, it's lack of context in the diff,
commit ba282daa919f89c
On Thu, Dec 20, 2007 at 05:41:09PM -0800, Linus Torvalds wrote:
> The regression list keeps shrinking, so we're still on track for a full
> 2.6.24 release in early January. Assuming we don't all overeat during the
> holidays and nobody gets any work done. But we all know that the holidays
> are
On Thu, 2007-12-20 at 17:41 -0800, Linus Torvalds wrote:
> The most noticeable part here (both to users and in the diffstat) should
> be the libata-acpi fixes by Tejun Heo, which should hopefully take care of
> all of the regressions that were caused by teaching SATA about doing the
> proper ACP
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > + raw_local_irq_save(flags);
> > __raw_spin_lock(&die.lock);
> > - raw_local_save_flags(flags);
> > die.lock_owner = smp_processor_id();
> > die.lock_owner_depth = 0;
> > bust_spinlo
On Fri, 21 Dec 2007 01:30:35 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 21 Dec 2007 00:47:59 +0100
> > Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > > __raw_spin_lock(&die.lock);
> > > > raw_local_
On Thursday, 20 of December 2007, Andrew Morton wrote:
> On Thu, 20 Dec 2007 14:54:15 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 20 Dec 2007 17:40:47 -0500
> > Trond Myklebust <[EMAIL PROTECTED]> wrote:
> >
> > > I just got the following interesting behaviour. Never mind why t
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Dec 2007 00:47:59 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > __raw_spin_lock(&die.lock);
> > > raw_local_save_flags(flags);
> > > - die.lock_owner = smp_processor_id();
> > > + die.lock_owner
On Fri, 21 Dec 2007 00:47:59 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > __raw_spin_lock(&die.lock);
> > raw_local_save_flags(flags);
> > - die.lock_owner = smp_processor_id();
> > + die.lock_owner = raw_smp_processor_id();
>
> we just disabled irq
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Dec 2007 00:47:59 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > it needs to be found out why the preempt_count suddenly went to zero. Is
> > task struct corruption out of question?
>
> Strictly we shouldn't care - we _know_ we've a
On Fri, 21 Dec 2007 00:47:59 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> it needs to be found out why the preempt_count suddenly went to zero. Is
> task struct corruption out of question?
Strictly we shouldn't care - we _know_ we've already hit a kernel bug and
who knows, perhaps that buggy c
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> Yes - I don't know why the smp_processor_id() test has suddenly
> started triggering in there.
it's a "must not happen".
here:
> __raw_spin_lock(&die.lock);
> raw_local_save_flags(flags);
> - die.lock_owner =
On Thu, 2007-12-20 at 14:56 -0800, Andrew Morton wrote:
> btw, I think we should track this as a regression, please. It may not
> strictly be a regression: the same problem might happen under 2.6.23,
> although reports are only agaisnt 2.6.24-rc.
>
> But things which impact our ability to get cl
On Thu, 2007-12-20 at 14:54 -0800, Andrew Morton wrote:
> On Thu, 20 Dec 2007 17:40:47 -0500
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> > I just got the following interesting behaviour. Never mind why the
> > original Oops (I was testing some experimental RPC patches), but there
> > appears
On Thu, 20 Dec 2007 14:54:15 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Dec 2007 17:40:47 -0500
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> > I just got the following interesting behaviour. Never mind why the
> > original Oops (I was testing some experimental RPC patches), b
On Thu, 20 Dec 2007 17:40:47 -0500
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> I just got the following interesting behaviour. Never mind why the
> original Oops (I was testing some experimental RPC patches), but there
> appears to be a BUG_ON() triggered inside the dump() call.
>
> Oops occurre
As usually, if someone finds errors in http://kernelnewbies.org/Linux_2_6_24 ,
let me know it or change it yourself.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info
1 - 100 of 119 matches
Mail list logo
