Linus Torvalds wrote:
On Wed, 14 Mar 2007, Ingo Molnar wrote:
and that's how i think unification of architectures should be done: move
code into kernel/* and drivers/*, _not_ into another architecture. That
way all architectures benefit.
Don't be silly.
Did you even *look* at the patches?
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Andi Kleen wrote:
x86_64 is going to acquire more functionality that will not be available
for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
What advantage would that have over the current setup?
We already should handle
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Martin Bligh wrote:
You have to do some sort of lookup anyway, and Andy seemed to have them
all folded into one.
What lookup would you need to do? On x86_64 even the TLB use is
hidden by the existing 2M entries for 1-1 mappings.
Or are you
We carefully set loglevel to 7, and print the sysrq messsage
as to what event we're doing, but we can't actually see
the output as it sets it back before calling the handler,
rather than after.
Move the assignment down one line.
Signed-off-by: Martin J. Bligh [EMAIL PROTECTED]
diff -aurpN -X
Roman Zippel wrote:
On Thu, 5 Apr 2007, Martin Bligh wrote:
We carefully set loglevel to 7, and print the sysrq messsage
as to what event we're doing, but we can't actually see
the output as it sets it back before calling the handler,
rather than after.
Move the assignment down one line.
I
None of this is going anywhere, is is it?
I will test my changes before I send them to you, but I cannot
promise you that you'll have the computers or software needed
to reproduce the problems. I doubt I'll have full time access
to such systems myself, either.
32GB is pretty much the minimum
Christoph Lameter wrote:
On Mon, 2 Apr 2007, Dave Hansen wrote:
I completely agree, it looks like it should be faster. The code
certainly has potential benefits. But, to add this neato, apparently
more performant feature, we unfortunately have to add code. Adding the
code has a cost: code
Note that these arguments on DISCONTIG are flame bait for many SGIers.
We usually see this as an attack on DISCONTIG/VMEMMAP which is the
existing best performing implementation for page_to_pfn and vice
versa. Please lets stop the polarization. We want one consistent scheme
to manage memory
Christoph Lameter wrote:
On Tue, 3 Apr 2007, Andi Kleen wrote:
If it works I would be inclined to replaced old sparsemem with Christoph's
new one on x86-64. Perhaps that could cut down the bewildering sparsemem
ifdef jungle that is there currently.
But I presume it won't work on 32bit because
Christoph Lameter wrote:
On Mon, 2 Apr 2007, Martin Bligh wrote:
For 64GB you'd need 256M which would be a quarter of low mem. Probably takes
up too much of low mem.
Yup.
We could move whatever you currently use to handle that into i386 arch
code. Or are there other platforms that do
Date: Sun, 06 Jan 2008 10:00:33 -0600
From: James Bottomley [EMAIL PROTECTED]
To: Adrian Bunk [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED], Peter Osterlund [EMAIL PROTECTED],
Linus Torvalds [EMAIL PROTECTED],
Matthew Wilcox [EMAIL PROTECTED], linux-kernel@vger.kernel.org,
Ingo Molnar wrote:
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
OK, changed it.
I don't think this is the right way to do it, as you'll get email
for every change to every bug until it's assigned, but seeing as
that's what you asked for, and we can't seem to get vger to take
bounces, I
Ingo Molnar wrote:
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Edit / Prefs / Email Preferences / Users to watch
add [EMAIL PROTECTED] to that list and you'll
be notified about new bugs and changes to existing bugs.
Still, I'd like the list to be notified, not only me (eg. I might be
http://bugzilla.kernel.org/show_bug.cgi?id=9267
Kernel: 2.6.23.1
No response from developers
Urm, well, if no-one ever tells the SCSI list it's unrealistic to expect
anyone to be working on it. As far as I can tell, email was sent to
Andrew Vasquez only on 31 October. However, the
- Lots of device IDs have been removed from the e1000 driver and
moved over to e1000e. So if your e1000 stops working, you forgot
to set CONFIG_E1000E.
Wouldn't it make sense to just default this to on if E1000 was on?
As far as I can see that's not true, which will screwing everybody
I can't see this compile failure posted anywhere:
http://test.kernel.org/results/IBM/126049/build/debug/stderr
arch/x86/vdso/vdso32/sigreturn.S: Assembler messages:
arch/x86/vdso/vdso32/sigreturn.S:23: Error: suffix or operands invalid
for `pop'
arch/x86/vdso/vdso32/syscall.S:25: Error:
Andrew Morton wrote:
On Thu, 18 Oct 2007 16:15:31 -0400
Marcelo Tosatti [EMAIL PROTECTED] wrote:
Hi,
AIX contains the SIGDANGER signal to notify applications to free up some
unused cached memory:
http://www.ussg.iu.edu/hypermail/linux/kernel/0007.0/0901.html
There have been a few
Rik van Riel wrote:
On Fri, 26 Oct 2007 14:11:12 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
Sure, but in terms of high-level userspace interface, being able to
select() on a group of priority buckets (spread across different
nodes, zones and cgroups) seems a lot more flexible than any
Bugzilla really shouldn't be accepting any mail with empty reverse-path
(MAIL FROM:)
Updated to handle this case.
Ah, then should be easy fix then. I don't have access to the system
though, will have to helplessly wait until one of the guys picks up...
:(
Sorry, can't fix this - I don't have
Chris Friesen wrote:
Randy Dunlap wrote:
+Thunderbird (GUI)
+
+By default, thunderbird likes to mangle text, but there are ways to
+coerce it into being nice.
Can someone describe the problems with just attaching the patch in
Thunderbird? It's what Martin says he does on the linked
Add seq_file howto to Documentation/
Signed-off-by: Martin J. Bligh [EMAIL PROTECTED]
Taken from kernelnewbies with Randy's permission.
diff -aurpN -X /home/mbligh/.diff.exclude
linux-2.6.22/Documentation/seq_file_howto.txt
2.6.22-seq_file_doc/Documentation/seq_file_howto.txt
---
Andrew Morton wrote:
On Wed, 08 Aug 2007 14:10:15 -0700
Martin J. Bligh [EMAIL PROTECTED] wrote:
Why isn't this easily fixable by just adding an additional dirty
flag that says atime has changed? Then we only cause a write
when we remove the inode from the inode cache, if only atime
is
The rules for sysfs files are the following:
- one value, in text format, per file.
- no action apon open/close
- binary files are only allowed for pass-through type files
that the kernel does not touch (like for firmware and pci
config space)
-
Greg KH wrote:
On Wed, Oct 10, 2007 at 10:24:43AM -0700, Martin Bligh wrote:
The rules for sysfs files are the following:
- one value, in text format, per file.
- no action apon open/close
- binary files are only allowed for pass-through type files
Nick Piggin wrote:
On Tue, Jul 31, 2007 at 11:14:08AM +0200, Andi Kleen wrote:
On Tuesday 31 July 2007 07:41, Nick Piggin wrote:
I haven't given this idea testing yet, but I just wanted to get some
opinions on it first. NUMA placement still isn't ideal (eg. tasks with
a memory policy will not
This topic seems to come up periodically every since we first introduced
the NUMA scheduler, and every time we decide it's a bad idea. What's
changed? What workloads does this improve (aside from some artificial
benchmark like stream)?
To repeat the conclusions of last time ... the primary
Nick Piggin wrote:
On Wed, Aug 01, 2007 at 03:52:11PM -0700, Martin Bligh wrote:
And so forth. Initial forks will balance. If the children refuse to
die, forks will continue to balance. If the parent starts seeing short
lived children, fork()s will eventually start to stay local.
Fork
Do you mean we can remove numaq x86 32bit code now?
Wouldn't bother me at all. The machine is from 1995, end of life c. 2000?
Was useful in the early days of getting NUMA up and running on Linux,
but is now too old to be a museum piece, really.
M.
--
To unsubscribe from this list: send the line
4, it does not CC to TJ and other numa guys...
attached workaround the problem for now.
but it will assume NUMAQ would not have SRAT table.
Martin, can you confirm that numaq does not have srat?
No, it's pre-SRAT. I forget the exact name of the table, but no SRAT until x440.
OTOH, you
On 1/24/07, Martin Bligh [EMAIL PROTECTED] wrote:
Two years ago, maddog tried to convince me that Brazil would be a
perfect place to hold a kernel summit, and that the Brazillian
government was 100% behind linux, and could provide a wonderful
location, yadda, yadda, yadda. What I told him
Wasn't it buildroot from Erik Andersen ?
http://buildroot.uclibc.org/
No, it was http://l4x.org/k/ It still appears to be operating, with
scary-looking results.
Jan, is there any way in which you can help us publish a full suite of
cross-compiler binaries?
That's going to be tricky,
Andrew Morton wrote:
On Tue, 30 Jan 2007 08:12:31 +0530
Suparna Bhattacharya [EMAIL PROTECTED] wrote:
On Sun, Jan 28, 2007 at 03:01:33PM -0800, Andrew Morton wrote:
On Sun, 28 Jan 2007 08:56:08 -0800
Martin J. Bligh [EMAIL PROTECTED] wrote:
- It seems that people have been busy creating the
Greg KH wrote:
On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote:
Seriously, though, please please pretty please do not allow a facility
for going through a simple interface to get accesses to irqs and
memory regions into the mainline kernel, with or without toy ISA
examples.
Wenji Wu wrote:
From: Wenji Wu [EMAIL PROTECTED]
Greetings,
For Linux TCP, when the network applcaiton make system call to move data
from
socket's receive buffer to user space by calling tcp_recvmsg(). The socket
will
be locked. During the period, all the incoming packet for the TCP socket
Fix up compiler warnings in megaraid driver
Signed-off-by: Martin J. Bligh [EMAIL PROTECTED]
diff -aurpN -X /home/mbligh/.diff.exclude linux-2.6.19/drivers/scsi/megaraid.c
2.6.19-megaraid/drivers/scsi/megaraid.c
--- linux-2.6.19/drivers/scsi/megaraid.c2006-12-04 17:52:00.0
Christoph Lameter wrote:
On Sun, 8 Jul 2007, Andi Kleen wrote:
Christoph Lameter [EMAIL PROTECTED] writes:
A cmpxchg is less costly than interrupt enabe/disable
That sounds wrong.
Martin Bligh was able to significantly increase his LTTng performance
by using cmpxchg. See his article
Christoph Lameter wrote:
On Mon, 9 Jul 2007, Martin Bligh wrote:
Those numbers came from Mathieu Desnoyers (LTTng) if you
want more details.
Okay the source for these numbers is in his paper for the OLS 2006: Volume
1 page 208-209? I do not see the exact number that you referred
~ 1% on 4-way x86_64
http://test.kernel.org/perf/kernbench.elm3b6.png
~ 4% on 16-way NUMA-Q (i386)
http://test.kernel.org/perf/kernbench.moe.png
~ 1.5% on 4-way i386
http://test.kernel.org/perf/kernbench.elm3b132.png
There's readprofiles and stuff available from here:
So if you make changes to random-driver.c you can do `git-log
random-driver.c|grep Tested-by to find people who can test
your changes for you.
You would'nt even need to search in GIT. Maybie even when ever a
patchset is being proposed a mail could be sent to appropriate
hardware/or feature
Natalie Protasevich wrote:
On 6/18/07, Martin Bligh [EMAIL PROTECTED] wrote:
So if you make changes to random-driver.c you can do `git-log
random-driver.c|grep Tested-by to find people who can test
your changes for you.
You would'nt even need to search in GIT. Maybie even when ever
Linus Torvalds wrote:
On Thu, 14 Jun 2007, Oleg Verych wrote:
I'm seeing this long (198) thread and just have no idea how it has
ended (wiki? hand-mailing?).
I'm hoping it's not ended.
IOW, I really don't think we _resolved_ anything, although the work that
Adrian started is continuing
Sure, simplicity is a key - but most of reporters on bugs are pretty
professional folks (or very well rounded amateurs :) We can try still
why not? the worst that can happen will be empty fields.
mmm. added complexity and interface clutter for little or no benefit
is what I'm trying to avoid -
Maybe searching free text fields can then be implemented. Then every
message exchange in bugzilla can be used for extracting such info -
questions about HW specifics are asked a lot, almost in every one.
It's a shame we cant' use this information. I was once searching for
VIA and got zero
Satyam Sharma wrote:
On 5/7/07, John Anthony Kazos Jr. [EMAIL PROTECTED] wrote:
In the linux-kernel -list subscribers domain popularity
analysis I got following results:
2101 gmail.com
49 googlemail.com
46 gmx.de
41 redhat.com
33 yahoo.com
23 suse.de
Wenji Wu wrote:
From: Wenji Wu <[EMAIL PROTECTED]>
Greetings,
For Linux TCP, when the network applcaiton make system call to move data
from
socket's receive buffer to user space by calling tcp_recvmsg(). The socket
will
be locked. During the period, all the incoming packet for the TCP socket
Fix up compiler warnings in megaraid driver
Signed-off-by: Martin J. Bligh <[EMAIL PROTECTED]>
diff -aurpN -X /home/mbligh/.diff.exclude linux-2.6.19/drivers/scsi/megaraid.c
2.6.19-megaraid/drivers/scsi/megaraid.c
--- linux-2.6.19/drivers/scsi/megaraid.c2006-12-04 17:52:00.0
Greg KH wrote:
On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote:
Seriously, though, please please pretty please do not allow a facility
for "going through a simple interface to get accesses to irqs and
memory regions" into the mainline kernel, with or without toy ISA
examples.
Linus Torvalds wrote:
On Wed, 14 Mar 2007, Ingo Molnar wrote:
and that's how i think unification of architectures should be done: move
code into kernel/* and drivers/*, _not_ into another architecture. That
way all architectures benefit.
Don't be silly.
Did you even *look* at the patches?
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Andi Kleen wrote:
x86_64 is going to acquire more functionality that will not be available
for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
What advantage would that have over the current setup?
We already should handle
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Martin Bligh wrote:
You have to do some sort of lookup anyway, and Andy seemed to have them
all folded into one.
What lookup would you need to do? On x86_64 even the TLB use is
hidden by the existing 2M entries for 1-1 mappings.
Or are you
None of this is going anywhere, is is it?
I will test my changes before I send them to you, but I cannot
promise you that you'll have the computers or software needed
to reproduce the problems. I doubt I'll have full time access
to such systems myself, either.
32GB is pretty much the minimum
Christoph Lameter wrote:
On Mon, 2 Apr 2007, Dave Hansen wrote:
I completely agree, it looks like it should be faster. The code
certainly has potential benefits. But, to add this neato, apparently
more performant feature, we unfortunately have to add code. Adding the
code has a cost: code
Note that these arguments on DISCONTIG are flame bait for many SGIers.
We usually see this as an attack on DISCONTIG/VMEMMAP which is the
existing best performing implementation for page_to_pfn and vice
versa. Please lets stop the polarization. We want one consistent scheme
to manage memory
Christoph Lameter wrote:
On Tue, 3 Apr 2007, Andi Kleen wrote:
If it works I would be inclined to replaced old sparsemem with Christoph's
new one on x86-64. Perhaps that could cut down the bewildering sparsemem
ifdef jungle that is there currently.
But I presume it won't work on 32bit because
Christoph Lameter wrote:
On Mon, 2 Apr 2007, Martin Bligh wrote:
For 64GB you'd need 256M which would be a quarter of low mem. Probably takes
up too much of low mem.
Yup.
We could move whatever you currently use to handle that into i386 arch
code. Or are there other platforms that do
We carefully set loglevel to 7, and print the sysrq messsage
as to what event we're doing, but we can't actually see
the output as it sets it back before calling the handler,
rather than after.
Move the assignment down one line.
Signed-off-by: Martin J. Bligh <[EMAIL PROTECTED]>
diff -aurpN -X
Roman Zippel wrote:
On Thu, 5 Apr 2007, Martin Bligh wrote:
We carefully set loglevel to 7, and print the sysrq messsage
as to what event we're doing, but we can't actually see
the output as it sets it back before calling the handler,
rather than after.
Move the assignment down one line.
I
On 1/24/07, Martin Bligh <[EMAIL PROTECTED]> wrote:
Two years ago, maddog tried to convince me that Brazil would be a
perfect place to hold a kernel summit, and that the Brazillian
government was 100% behind linux, and could provide a wonderful
location, yadda, yadda, yadda. What I to
> Wasn't it buildroot from Erik Andersen ?
>
>http://buildroot.uclibc.org/
>
No, it was http://l4x.org/k/ It still appears to be operating, with
scary-looking results.
Jan, is there any way in which you can help us publish a full suite of
cross-compiler binaries?
That's going to be
Andrew Morton wrote:
On Tue, 30 Jan 2007 08:12:31 +0530
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
On Sun, Jan 28, 2007 at 03:01:33PM -0800, Andrew Morton wrote:
On Sun, 28 Jan 2007 08:56:08 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
- It seems that people have been busy
> So if you make changes to random-driver.c you can do `git-log
> random-driver.c|grep Tested-by" to find people who can test
> your changes for you.
You would'nt even need to search in GIT. Maybie even when ever a
patchset is being proposed a mail could be sent to appropriate
hardware/or
Natalie Protasevich wrote:
On 6/18/07, Martin Bligh <[EMAIL PROTECTED]> wrote:
>> > So if you make changes to random-driver.c you can do `git-log
>> > random-driver.c|grep Tested-by" to find people who can test
>> > your changes for you.
>>
>>
Linus Torvalds wrote:
On Thu, 14 Jun 2007, Oleg Verych wrote:
I'm seeing this long (198) thread and just have no idea how it has
ended (wiki? hand-mailing?).
I'm hoping it's not "ended".
IOW, I really don't think we _resolved_ anything, although the work that
Adrian started is continuing
Sure, simplicity is a key - but most of reporters on bugs are pretty
professional folks (or very well rounded amateurs :) We can try still
why not? the worst that can happen will be empty fields.
mmm. added complexity and interface clutter for little or no benefit
is what I'm trying to avoid -
> Maybe searching free text fields can then be implemented. Then every
> message exchange in bugzilla can be used for extracting such info -
> questions about HW specifics are asked a lot, almost in every one.
> It's a shame we cant' use this information. I was once searching for
> "VIA" and got
Satyam Sharma wrote:
On 5/7/07, John Anthony Kazos Jr. <[EMAIL PROTECTED]> wrote:
> In the linux-kernel -list subscribers domain popularity
> analysis I got following results:
>
>2101 gmail.com
> 49 googlemail.com
> 46 gmx.de
> 41 redhat.com
> 33 yahoo.com
> 23
~ 1% on 4-way x86_64
http://test.kernel.org/perf/kernbench.elm3b6.png
~ 4% on 16-way NUMA-Q (i386)
http://test.kernel.org/perf/kernbench.moe.png
~ 1.5% on 4-way i386
http://test.kernel.org/perf/kernbench.elm3b132.png
There's readprofiles and stuff available from here:
Add seq_file howto to Documentation/
Signed-off-by: Martin J. Bligh <[EMAIL PROTECTED]>
Taken from kernelnewbies with Randy's permission.
diff -aurpN -X /home/mbligh/.diff.exclude
linux-2.6.22/Documentation/seq_file_howto.txt
2.6.22-seq_file_doc/Documentation/seq_file_howto.txt
---
Christoph Lameter wrote:
On Sun, 8 Jul 2007, Andi Kleen wrote:
Christoph Lameter <[EMAIL PROTECTED]> writes:
A cmpxchg is less costly than interrupt enabe/disable
That sounds wrong.
Martin Bligh was able to significantly increase his LTTng performance
by using cmpxchg. See his a
Christoph Lameter wrote:
On Mon, 9 Jul 2007, Martin Bligh wrote:
Those numbers came from Mathieu Desnoyers (LTTng) if you
want more details.
Okay the source for these numbers is in his paper for the OLS 2006: Volume
1 page 208-209? I do not see the exact number that you referred
Andrew Morton wrote:
On Wed, 08 Aug 2007 14:10:15 -0700
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
Why isn't this easily fixable by just adding an additional dirty
flag that says atime has changed? Then we only cause a write
when we remove the inode from the inode cache, if only atime
is
Nick Piggin wrote:
On Tue, Jul 31, 2007 at 11:14:08AM +0200, Andi Kleen wrote:
On Tuesday 31 July 2007 07:41, Nick Piggin wrote:
I haven't given this idea testing yet, but I just wanted to get some
opinions on it first. NUMA placement still isn't ideal (eg. tasks with
a memory policy will not
This topic seems to come up periodically every since we first introduced
the NUMA scheduler, and every time we decide it's a bad idea. What's
changed? What workloads does this improve (aside from some artificial
benchmark like stream)?
To repeat the conclusions of last time ... the primary
Nick Piggin wrote:
On Wed, Aug 01, 2007 at 03:52:11PM -0700, Martin Bligh wrote:
And so forth. Initial forks will balance. If the children refuse to
die, forks will continue to balance. If the parent starts seeing short
lived children, fork()s will eventually start to stay local.
Fork
Chris Friesen wrote:
Randy Dunlap wrote:
+Thunderbird (GUI)
+
+By default, thunderbird likes to mangle text, but there are ways to
+coerce it into being nice.
Can someone describe the problems with just attaching the patch in
Thunderbird? It's what Martin says he does on the linked
The rules for sysfs files are the following:
- one value, in text format, per file.
- no action apon open/close
- binary files are only allowed for "pass-through" type files
that the kernel does not touch (like for firmware and pci
config space)
Greg KH wrote:
On Wed, Oct 10, 2007 at 10:24:43AM -0700, Martin Bligh wrote:
The rules for sysfs files are the following:
- one value, in text format, per file.
- no action apon open/close
- binary files are only allowed for "pass-through"
Bugzilla really shouldn't be accepting any mail with empty reverse-path
(MAIL FROM:<>)
Updated to handle this case.
Ah, then should be easy fix then. I don't have access to the system
though, will have to helplessly wait until one of the guys picks up...
:(
Sorry, can't fix this - I don't
Andrew Morton wrote:
On Thu, 18 Oct 2007 16:15:31 -0400
Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
Hi,
AIX contains the SIGDANGER signal to notify applications to free up some
unused cached memory:
http://www.ussg.iu.edu/hypermail/linux/kernel/0007.0/0901.html
There have been a few
Rik van Riel wrote:
On Fri, 26 Oct 2007 14:11:12 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
Sure, but in terms of high-level userspace interface, being able to
select() on a group of priority buckets (spread across different
nodes, zones and cgroups) seems a lot more flexible than any
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9267
> > > Kernel: 2.6.23.1
> >
> > No response from developers
>
> Urm, well, if no-one ever tells the SCSI list it's unrealistic to expect
> anyone to be working on it. As far as I can tell, email was sent to
> Andrew Vasquez only on 31 October.
>>> 4, it does not CC to TJ and other numa guys...
>>
>> attached workaround the problem for now.
>> but it will assume NUMAQ would not have SRAT table.
>
> Martin, can you confirm that numaq does not have srat?
No, it's pre-SRAT. I forget the exact name of the table, but no SRAT until x440.
> Do you mean we can remove numaq x86 32bit code now?
Wouldn't bother me at all. The machine is from 1995, end of life c. 2000?
Was useful in the early days of getting NUMA up and running on Linux,
but is now too old to be a museum piece, really.
M.
--
To unsubscribe from this list: send the
Date: Sun, 06 Jan 2008 10:00:33 -0600
From: James Bottomley <[EMAIL PROTECTED]>
To: Adrian Bunk <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>, Peter Osterlund <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]>,
Matthew Wilcox <[EMAIL PROTECTED]>,
Ingo Molnar wrote:
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
OK, changed it.
I don't think this is the right way to do it, as you'll get email
for every change to every bug until it's assigned, but seeing as
that's what you asked for, and we can't seem to get vger to take
bounces, I
Ingo Molnar wrote:
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
Edit / Prefs / Email Preferences / Users to watch
add [EMAIL PROTECTED] to that list and you'll
be notified about new bugs and changes to existing bugs.
Still, I'd like the list to be notified, not only me (eg. I might be
>- Lots of device IDs have been removed from the e1000 driver and
> moved over to e1000e. So if your e1000 stops working, you forgot
> to set CONFIG_E1000E.
Wouldn't it make sense to just default this to on if E1000 was on?
As far as I can see that's not true, which will screwing everybody
I can't see this compile failure posted anywhere:
http://test.kernel.org/results/IBM/126049/build/debug/stderr
arch/x86/vdso/vdso32/sigreturn.S: Assembler messages:
arch/x86/vdso/vdso32/sigreturn.S:23: Error: suffix or operands invalid
for `pop'
arch/x86/vdso/vdso32/syscall.S:25: Error:
88 matches
Mail list logo
