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
eparate function seems to help. This is
> a no-op for gcc 4.1 which will successfully inline the code anyway.
Hi Jean,
Thank you, I have tested the patch, it fixes the build failure.
Tested-by: Kamalesh Babulal <[EMAIL PROTECTED]>
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
his is
a no-op for gcc 4.1 which will successfully inline the code anyway.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
---
drivers/firmware/dmi-id.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
--- linux-2.6.24-rc7.orig/drivers/firmware/dmi-id.c 2007-1
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
Software Visibility by default
Unify /proc/slabinfo configuration
Fix kernel/ptrace.c compile problem (missing "may_attach()")
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
Linux 2.6.24-rc7
Mark McLoughlin (1):
[INET]: Fix
51 matches
Mail list logo
