>From: Thomas Gleixner, Dienstag, 19. Februar 2008 11:49
>Subject: Re: [BUG][RFC][GENERIC IRQ] linux-2.6.24 (delayed) disable IRQ
>feature not functional for handle_simple_irq
>
>On Tue, 19 Feb 2008, Hennerich, Michael wrote:
>> Thomas,
>>
>> I have reasonab
On Tue, 19 Feb 2008, Hennerich, Michael wrote:
> Thomas,
>
> I have reasonable doubt that the delayed disable feature on
> linux-2.6.24 for handle_simple_irq is broken.
>
> In 2.6.22 there was something like this:
>
> if (unlikely(!action || (des
Thomas,
I have reasonable doubt that the delayed disable feature on linux-2.6.24 for
handle_simple_irq is broken.
In 2.6.22 there was something like this:
if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
if (desc->chip->mask)
David Miller wrote:
From: Jozsef Kadlecsik <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 16:02:29 +0100 (CET)
Hi,
On Sun, 10 Feb 2008, Jeff Chua wrote:
Please note the lastest git commit is missing one part (which was in Jozsef's
original patch).
Sorry everyone, that's my fault: the patch I sen
From: Jozsef Kadlecsik <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 16:02:29 +0100 (CET)
> Hi,
>
> On Sun, 10 Feb 2008, Jeff Chua wrote:
>
> > Please note the lastest git commit is missing one part (which was in
> > Jozsef's
> > original patch).
>
> Sorry everyone, that's my fault: the patch I s
Hi,
On Sun, 10 Feb 2008, Jeff Chua wrote:
> Please note the lastest git commit is missing one part (which was in Jozsef's
> original patch).
Sorry everyone, that's my fault: the patch I sent for the stable branch
was correct, however I mistyped a state in the patch for the newest
git tree - Je
On Feb 5, 2008 9:47 PM, Patrick McHardy wrote:
On Feb 5, 2008 4:16 PM, Jozsef Kadlecsik wrote:
Patrick, I suppose you need a patch against the latest git, don't you?
Yes, please. I'll take you first patch for -stable though if you
send me a Signed-off-by: line.
Please note the lastest git com
Jozsef Kadlecsik wrote:
On Tue, 5 Feb 2008, Jeff Chua wrote:
On Feb 5, 2008 4:17 AM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
Actively closed connections are not handled properly, i.e. the initiator of
the active close should not be taken into account. So could you give a try
to the patch
On Tue, 5 Feb 2008, Jeff Chua wrote:
> On Feb 5, 2008 4:17 AM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
>
> > Actively closed connections are not handled properly, i.e. the initiator of
> > the active close should not be taken into account. So could you give a try
> > to the patch below? Does
On Feb 5, 2008 4:17 AM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
Actively closed connections are not handled properly, i.e. the initiator
of the active close should not be taken into account. So could you give
a try to the patch below? Does it just suppress the 'invalid packed
ignored' an
Hi,
On Mon, 4 Feb 2008, Jeff Chua wrote:
> > Attached are the dump files mentioned.
>
> Not sure whether the attached files got uploaded. So, I'm sending this one
> more time.
I could reproduce the slow-down by a loop of socat commands. The dump you
sent looks exactly like the traces I got at
On Feb 2, 2008 10:44 PM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
> Could I ask you to make two another tests? (I have been unable to
> reproduce the bug so far, but it must be my fault.)
You need to send more than 510 jobs to see the problem.
> In both cases enable loggin invalid messages as
|tagger Linus Torvalds <...> 1201215533 -0800
|
|Linux 2.6.24
|
|No new name? What's up with that? Have we run out of ridiculous animals
|or human behaviour? Talk like a pirate day was long long ago. We need
|the bug-free Weasel-series naming back!
What happened to the cunning ideas of h
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
Hi Jeff,
On Fri, 1 Feb 2008, Jeff Chua wrote:
> I recaptured it again, and attached are the logs.
[...]
Thank you! One can see a plain connection-initiating SYN, which triggers
the message. No reply from the server, then three seconds later comes a
retransmitted SYN and immediately after the S
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]: **
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]: *** [drivers/net] Error 2
I think it is caused by:
CONFIG_SSB_PCIHOST=n
CONFIG_B44=y
--
To unsubscrib
David Newall wrote:
I'm not debating that checksums are wrong. The question was how and
where? It's not as if there are any unreliable communication paths in a
loopback interface, so it's surprising that they could be wrong. How? Where?
As I said, loopback doesn't perform full checksum calcula
David Miller wrote:
> From: David Newall <[EMAIL PROTECTED]>
> Date: Fri, 01 Feb 2008 11:17:14 +1030
>
>
>> Patrick McHardy wrote:
>>
>>> Jozsef Kadlecsik wrote:
>>>
Strange, but there are a lot of incorrect checksum packets. How does
it come on the loopback interface?
From: David Newall <[EMAIL PROTECTED]>
Date: Fri, 01 Feb 2008 11:17:14 +1030
> Patrick McHardy wrote:
> > Jozsef Kadlecsik wrote:
> >> Strange, but there are a lot of incorrect checksum packets. How does
> >> it come on the loopback interface?
> >
> > Loopback doesn't perform full checksumming, so
Patrick McHardy wrote:
> Jozsef Kadlecsik wrote:
>> Strange, but there are a lot of incorrect checksum packets. How does
>> it come on the loopback interface?
>
> Loopback doesn't perform full checksumming, so thats expected.
The question remains: How do loopback packets get incorrect checksum?
W
Jozsef Kadlecsik wrote:
Hi Jeff,
On Thu, 31 Jan 2008, Jeff Chua wrote:
On the bad run, I got the following message ...
boston kernel: nf_ct_tcp: invalid packed ignored IN= OUT=
SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=8162
DF PROTO=TCP SPT=1016 DPT=515 SEQ=3834958843 AC
Hi Jeff,
On Thu, 31 Jan 2008, Jeff Chua wrote:
> On the bad run, I got the following message ...
>
> boston kernel: nf_ct_tcp: invalid packed ignored IN= OUT=
> SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=8162
> DF PROTO=TCP SPT=1016 DPT=515 SEQ=3834958843 ACK=0 WINDOW=32792
On Jan 31, 2008 11:25 AM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Actually its probably the SYN/ACK that is dropped. Please try whether
>
> modprobe ipt_LOG
> echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid
On the good run, I don't get any message, which is good.
On the bad run,
Jeff Chua wrote:
On Jan 31, 2008 10:41 AM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
Thanks. In the dump we can see that connections reusing ports
always have their first SYN dropped and retransmissted three
seconds later. I'm not sure whats causing this yet, do you have
any firewall rules
On Jan 31, 2008 10:41 AM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Thanks. In the dump we can see that connections reusing ports
> always have their first SYN dropped and retransmissted three
> seconds later. I'm not sure whats causing this yet, do you have
> any firewall rules that affect loo
Jeff Chua wrote:
On Jan 31, 2008 10:23 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
Again, using latest linux, one with
17311393f969090ab060540bd9dbe7dc885a76d5 reverted, and the other
without.
Sorry, here's the attached output files.
Thanks. In the dump we can see that connections reus
On Jan 30, 2008 9:47 PM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> A binary dump would be more useful:
>
> tcpdump -i lo -w
>
> and I guess Jozsef also wants "-s 0" so the full packets are included.
Attached. Again, both runs with this command to print ...
for((i=1; i<1001;i++)); do echo $i
Jeff Chua wrote:
On Jan 29, 2008 6:53 PM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
As the problem can be reproduced so easily, could you capture a full TCP
session and send the pcap file? Thus it could be analyzed, replayed, etc.
and found the reason why the patch above slows down the printi
On Tue, 29 Jan 2008, Jeff Chua wrote:
> On Jan 28, 2008 7:18 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
> > I'm sending printing jobs to a network printer (it's actually printing
> > to the localhost simply creating a file), and running this on
> > Linux-2.6.24
2008/1/29 Krzysztof Oledzki <[EMAIL PROTECTED]>:
> Strange. You stated that 2.6.23.12 is OK, however above patch
> was included in 2.6.23.4:
> Are you 100% sure that 2.6.23.12 is OK?
Sorry, my mistake. I had another system on 2.6.23.12 and was not OK,
so I bisected starting from 2.6.23.
git bise
On Tue, 29 Jan 2008, Jeff Chua wrote:
On Jan 28, 2008 7:18 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing t
On Jan 28, 2008 7:18 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing to slow down to 1 print every 3
seconds af
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing to slow down to 1 print every 3
seconds after printing 500 times.
No such symptoms on 2.6.23.12, or 2.6.20.21.
It&#x
* 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
In hidinput_configure_usage(device), IS_CHICONY_TACTICAL_PAD(devic) gets
passed the 'device' parameter. But that macro still references its
parameter by 'device' instead of by its local name 'x'.
Signed-off-by: Philipp Matthias Hahn <[EMAIL PROTECTED]>
--- linux/drivers/hid/hid-input.c 2008
On Fri, 25 Jan 2008, Philipp Matthias Hahn wrote:
> In hidinput_configure_usage(device), IS_CHICONY_TACTICAL_PAD(devic) gets
> passed the 'device' parameter. But that macro still references its
> parameter by 'device' instead of by its local name 'x'.
> Signed-off-by: Philipp Matthias Hahn <[EMAIL
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
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.
Nothing earth-shattering happened since -rc8, although the new set of ACPI
blacklist entries and s
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
d of open flags to determine needed permissions
Revert "writeback: introduce writeback_control.more_io to indicate more
io"
Fix ARM profiling/instrumentation configuration
Linux 2.6.24-rc8
Massimo Cirillo (1):
cache invalidation error for buffered write
Matheos
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/
1 - 100 of 177 matches
Mail list logo
