On Feb 12, 2008 9:57 AM, James Bottomley
<[EMAIL PROTECTED]> wrote:
> Added linux-scsi for the SCSI ones
>
> On Tue, 2008-02-12 at 00:18 -0800, Natalie Protasevich wrote:
> > Hello,
> >
> > The bugs listed are over a month old, and haven't been addressed
Hello,
The bugs listed are over a month old, and haven't been addressed yet.
It would be appreciated if corresponding maintainers identify whether
the bugs have been fixed, or need to be worked on, and take
appropriate action.
In most cases, reporters are standing by and ready to provide
Hello,
The bugs listed are over a month old, and haven't been addressed yet.
It would be appreciated if corresponding maintainers identify whether
the bugs have been fixed, or need to be worked on, and take
appropriate action.
In most cases, reporters are standing by and ready to provide
On Feb 12, 2008 9:57 AM, James Bottomley
[EMAIL PROTECTED] wrote:
Added linux-scsi for the SCSI ones
On Tue, 2008-02-12 at 00:18 -0800, Natalie Protasevich wrote:
Hello,
The bugs listed are over a month old, and haven't been addressed yet.
It would be appreciated if corresponding
On Dec 19, 2007 9:05 AM, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 19, 2007 at 10:50:40AM -0600, James Bottomley wrote:
> > So, to get the best of both worlds, file a bugzilla and note the bugid.
> > Then email a complete report to the relevant list, but add [BUG ]
> > to the subject
On Dec 19, 2007 9:05 AM, Matthew Wilcox [EMAIL PROTECTED] wrote:
On Wed, Dec 19, 2007 at 10:50:40AM -0600, James Bottomley wrote:
So, to get the best of both worlds, file a bugzilla and note the bugid.
Then email a complete report to the relevant list, but add [BUG bugid]
to the subject
On Dec 14, 2007 1:57 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 14 Dec 2007 10:46:36 -0800 Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> > The http://www.kerneloops.org website collects kernel oops and warning
> > reports from various mailing lists and bugzillas
>
> Well that would
On Dec 14, 2007 1:57 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 14 Dec 2007 10:46:36 -0800 Arjan van de Ven [EMAIL PROTECTED] wrote:
The http://www.kerneloops.org website collects kernel oops and warning
reports from various mailing lists and bugzillas
Well that would have been fun
This is the listing of open bugs that are not new time wise, mostly
over a month old, which is a long time for current rate of
development.
Most bugs need initial response, and all need attention (tlc).
It would be appreciated if the corresponding maintenance team could
take a look at the bugs,
This is the listing of open bugs that are not new time wise, mostly
over a month old, which is a long time for current rate of
development.
Most bugs need initial response, and all need attention (tlc).
It would be appreciated if the corresponding maintenance team could
take a look at the bugs,
On Dec 5, 2007 3:25 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> "Natalie Protasevich" <[EMAIL PROTECTED]> writes:
>
> > On Nov 27, 2007 10:21 PM, Len Brown <[EMAIL PROTECTED]> wrote:
> >> commit c434b7a6aedfe428ad17cd61b21b125a7b7a29
On Nov 27, 2007 10:21 PM, Len Brown <[EMAIL PROTECTED]> wrote:
> commit c434b7a6aedfe428ad17cd61b21b125a7b7a29ce
> (x86: avoid wasting IRQs for PCI devices)
> created a concept of "IRQ compression" on i386
> to conserve IRQ numbers on systems with many
> sparsely populated IO
On Nov 27, 2007 10:21 PM, Len Brown [EMAIL PROTECTED] wrote:
commit c434b7a6aedfe428ad17cd61b21b125a7b7a29ce
(x86: avoid wasting IRQs for PCI devices)
created a concept of IRQ compression on i386
to conserve IRQ numbers on systems with many
sparsely populated IO APICs.
On Dec 5, 2007 3:25 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Natalie Protasevich [EMAIL PROTECTED] writes:
On Nov 27, 2007 10:21 PM, Len Brown [EMAIL PROTECTED] wrote:
commit c434b7a6aedfe428ad17cd61b21b125a7b7a29ce
(x86: avoid wasting IRQs for PCI devices)
created
Here is also Rick's page:
http://kernelnewbies.org/KernelProjects
On Dec 4, 2007 12:10 AM, Chris Snook <[EMAIL PROTECTED]> wrote:
> Muhammad Nowbuth wrote:
> > Hi all,
> >
> > Could anyone give some ideas of future pending works which are needed
> > on the linux kernel?
>
>
Here is also Rick's page:
http://kernelnewbies.org/KernelProjects
On Dec 4, 2007 12:10 AM, Chris Snook [EMAIL PROTECTED] wrote:
Muhammad Nowbuth wrote:
Hi all,
Could anyone give some ideas of future pending works which are needed
on the linux kernel?
This is the listing of the open bugs that are relatively new, around
2.6.22 and up. They are vaguely classified by specific area.
(not a full list, there are more :)
The good part is that reporters of the bugs below are still around and
haven't dissipated, or disposed of their hardware, so it is
This is the listing of the open bugs that are relatively new, around
2.6.22 and up. They are vaguely classified by specific area.
(not a full list, there are more :)
The good part is that reporters of the bugs below are still around and
haven't dissipated, or disposed of their hardware, so it is
On 9/23/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-09-23 at 11:08 -0700, Natalie Protasevich wrote:
> > On 9/23/07, Diego Calleja <[EMAIL PROTECTED]> wrote:
> > > Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
> >
On 9/23/07, Diego Calleja <[EMAIL PROTECTED]> wrote:
> Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
>
> bugzilla tries to send a mail to the reporter, it fails ("unknown user
> account"),
> but the error failure is appended as a bugzilla comment. Then bugzilla tries
> to
> send
On 9/23/07, Diego Calleja [EMAIL PROTECTED] wrote:
Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
bugzilla tries to send a mail to the reporter, it fails (unknown user
account),
but the error failure is appended as a bugzilla comment. Then bugzilla tries
to
send that
On 9/23/07, David Woodhouse [EMAIL PROTECTED] wrote:
On Sun, 2007-09-23 at 11:08 -0700, Natalie Protasevich wrote:
On 9/23/07, Diego Calleja [EMAIL PROTECTED] wrote:
Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
bugzilla tries to send a mail to the reporter, it fails
On 9/8/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
> Hi lists,
>
> I copied the ancient linux1394 project TODO list from the static page at
> www.linux1394.org over to http://wiki.linux1394.org/ToDo and
> substantially updated it now. I certainly missed a few important TODOs
> and ideas, but
On 9/8/07, Stefan Richter [EMAIL PROTECTED] wrote:
Hi lists,
I copied the ancient linux1394 project TODO list from the static page at
www.linux1394.org over to http://wiki.linux1394.org/ToDo and
substantially updated it now. I certainly missed a few important TODOs
and ideas, but the list
> Bugzilla is for tracking bugs, not for discussing possible
> kernel features.
True, but some of them are categorized as bugs from the reporter's
prospective, when they say "man page says" or "according to POSIX it's
wrong". I am going to push ones that are feature suggestions,
re-design
n 8/27/07, David Rees <[EMAIL PROTECTED]> wrote:
> On 8/27/07, Daniel Walker <[EMAIL PROTECTED]> wrote:
> > Now that I'm looking at the kernel bugzilla .. If you set the kernel
> > version to 2.6.22 and set the "Regression" check box you could denote
> > the fact that it's a regression in that
n 8/27/07, David Rees [EMAIL PROTECTED] wrote:
On 8/27/07, Daniel Walker [EMAIL PROTECTED] wrote:
Now that I'm looking at the kernel bugzilla .. If you set the kernel
version to 2.6.22 and set the Regression check box you could denote
the fact that it's a regression in that kernel version
Bugzilla is for tracking bugs, not for discussing possible
kernel features.
True, but some of them are categorized as bugs from the reporter's
prospective, when they say man page says or according to POSIX it's
wrong. I am going to push ones that are feature suggestions,
re-design suggestions,
This is the first listing of the open bugs that will be sent out and will
contain bugs on specific areas.
The bugs on the list below are about a year old and most of them confirmed
(or claimed) to still be a problem.
It would be appreciated if the corresponding maintenance team could take
This is the first listing of the open bugs that will be sent out and will
contain bugs on specific areas.
The bugs on the list below are about a year old and most of them confirmed
(or claimed) to still be a problem.
It would be appreciated if the corresponding maintenance team could take
On 6/19/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Tue, 19 Jun 2007, Oleg Verych wrote:
>
> I'm proposing kind of smart tracking, summarized before. I'm not an
> idealist, doing manual work. Making tools -- is what i've picked up from
> one of your mails. Thus hope of having more
On 6/19/07, Linus Torvalds [EMAIL PROTECTED] wrote:
On Tue, 19 Jun 2007, Oleg Verych wrote:
I'm proposing kind of smart tracking, summarized before. I'm not an
idealist, doing manual work. Making tools -- is what i've picked up from
one of your mails. Thus hope of having more opinions on
On 6/18/07, Fortier,Vincent [Montreal] <[EMAIL PROTECTED]> wrote:
> -Message d'origine-
> De : Natalie Protasevich [mailto:[EMAIL PROTECTED]
> Envoyé : 18 juin 2007 18:56
>
> On 6/18/07, Martin Bligh <[EMAIL PROTECTED]> wrote:
> > >> > So if you
On 6/18/07, Martin Bligh <[EMAIL PROTECTED]> wrote:
> 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
On 6/18/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Mon, 18 Jun 2007, Martin Bligh wrote:
>
> Sorry to be a wet blanket, but I've seen those sort of things
> before, and they just don't seem to work, especially in the
> environment we're in with such a massive diversity of hardware.
I do
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 a
>> patchset
On 6/18/07, Fortier,Vincent [Montreal] <[EMAIL PROTECTED]> wrote:
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] De la part de
> Andrew Morton
>
> On Mon, 18 Jun 2007 01:15:15 +0200 Stefan Richter
> <[EMAIL PROTECTED]> wrote:
>
> > Tested-by
>
> Tested-by
On 6/18/07, Fortier,Vincent [Montreal] [EMAIL PROTECTED] wrote:
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de
Andrew Morton
On Mon, 18 Jun 2007 01:15:15 +0200 Stefan Richter
[EMAIL PROTECTED] wrote:
Tested-by
Tested-by would be good too.
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 a
patchset is being proposed a
On 6/18/07, Linus Torvalds [EMAIL PROTECTED] wrote:
On Mon, 18 Jun 2007, Martin Bligh wrote:
Sorry to be a wet blanket, but I've seen those sort of things
before, and they just don't seem to work, especially in the
environment we're in with such a massive diversity of hardware.
I do
On 6/18/07, Martin Bligh [EMAIL PROTECTED] wrote:
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
On 6/18/07, Fortier,Vincent [Montreal] [EMAIL PROTECTED] wrote:
-Message d'origine-
De : Natalie Protasevich [mailto:[EMAIL PROTECTED]
Envoyé : 18 juin 2007 18:56
On 6/18/07, Martin Bligh [EMAIL PROTECTED] wrote:
So if you make changes to random-driver.c you can do `git-log
On 6/17/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
On Sun, Jun 17, 2007 at 06:26:55PM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
> >>> And we should be aware that reverting is only a workaround for the real
> >>> problem which lies in our bug handling.
> >> ...
> >
> > And this is
On 6/17/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
On Sunday, 17 June 2007 16:29, Adrian Bunk wrote:
> On Sun, Jun 17, 2007 at 03:17:58PM +0200, Michal Piotrowski wrote:
> > On 17/06/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >...
> >> Fine with me, but:
> >>
> >> There are not so simple
On Wed, Jun 13, 2007 at 01:39:29PM -0700, Roland Dreier wrote:
> > Can you please try the attached patch? I have compiled it with
CONFIG_ES7000=y
> > and CONFIG_X86_GENERICARCH=n. But don't have any ES7000 machine to
test it.
>
> I actually don't have anything remotely like ES7000 iether. I
On Wed, Jun 13, 2007 at 01:39:29PM -0700, Roland Dreier wrote:
Can you please try the attached patch? I have compiled it with
CONFIG_ES7000=y
and CONFIG_X86_GENERICARCH=n. But don't have any ES7000 machine to
test it.
I actually don't have anything remotely like ES7000 iether. I just
On 6/17/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Sunday, 17 June 2007 16:29, Adrian Bunk wrote:
On Sun, Jun 17, 2007 at 03:17:58PM +0200, Michal Piotrowski wrote:
On 17/06/07, Adrian Bunk [EMAIL PROTECTED] wrote:
...
Fine with me, but:
There are not so simple cases like big
On 6/17/07, Adrian Bunk [EMAIL PROTECTED] wrote:
On Sun, Jun 17, 2007 at 06:26:55PM +0200, Stefan Richter wrote:
Adrian Bunk wrote:
And we should be aware that reverting is only a workaround for the real
problem which lies in our bug handling.
...
And this is something I want to
On 6/15/07, Vivek Goyal <[EMAIL PROTECTED]> wrote:
On Wed, Jun 13, 2007 at 03:22:55PM -0700, Natalie Protasevich wrote:
[..]
> >Seems it would be cleaner to figure out some way to build es7000.c for
> >if CONFIG_X86_ES7000 is set? Or just move them here all the time?
>
On 6/15/07, Vivek Goyal [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2007 at 03:22:55PM -0700, Natalie Protasevich wrote:
[..]
Seems it would be cleaner to figure out some way to build es7000.c for
if CONFIG_X86_ES7000 is set? Or just move them here all the time?
---
linux-2.6.22-rc4-git4
> Can you please try the attached patch? I have compiled it with
CONFIG_ES7000=y
> and CONFIG_X86_GENERICARCH=n. But don't have any ES7000 machine to
test it.
I actually don't have anything remotely like ES7000 iether. I just
found the problem while tracking down another randconfig failure.
From: Vivek Goyal [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 13, 2007 11:38 AM
To: Roland Dreier
Cc: linux-kernel@vger.kernel.org; Protasevich, Natalie;
[EMAIL PROTECTED]
Subject: Re: CONFIG_X86_ES7000=y, CONFIG_X86_GENERICARCH=n,
CONFIG_ACPI=y build broken
On Tue, Jun 12, 2007 at
From: Vivek Goyal [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 13, 2007 11:38 AM
To: Roland Dreier
Cc: linux-kernel@vger.kernel.org; Protasevich, Natalie;
[EMAIL PROTECTED]
Subject: Re: CONFIG_X86_ES7000=y, CONFIG_X86_GENERICARCH=n,
CONFIG_ACPI=y build broken
On Tue, Jun 12, 2007 at
Can you please try the attached patch? I have compiled it with
CONFIG_ES7000=y
and CONFIG_X86_GENERICARCH=n. But don't have any ES7000 machine to
test it.
I actually don't have anything remotely like ES7000 iether. I just
found the problem while tracking down another randconfig failure.
On 6/12/07, Natalie Protasevich <[EMAIL PROTECTED]> wrote:
>
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 12, 2007 1:14 PM
> To: linux-kernel@vger.kernel.org; Protasevich, Natalie; Vivek Goyal
> Cc: [EMAIL PROTECTED]
> Subject: CONFIG_X86_ES7000=y
From: Roland Dreier [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 12, 2007 1:14 PM
To: linux-kernel@vger.kernel.org; Protasevich, Natalie; Vivek Goyal
Cc: [EMAIL PROTECTED]
Subject: CONFIG_X86_ES7000=y, CONFIG_X86_GENERICARCH=n, CONFIG_ACPI=y
build broken
(sending to Vivek since he seems to be
From: Roland Dreier [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 12, 2007 1:14 PM
To: linux-kernel@vger.kernel.org; Protasevich, Natalie; Vivek Goyal
Cc: [EMAIL PROTECTED]
Subject: CONFIG_X86_ES7000=y, CONFIG_X86_GENERICARCH=n, CONFIG_ACPI=y
build broken
(sending to Vivek since he seems to be
On 6/12/07, Natalie Protasevich [EMAIL PROTECTED] wrote:
From: Roland Dreier [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 12, 2007 1:14 PM
To: linux-kernel@vger.kernel.org; Protasevich, Natalie; Vivek Goyal
Cc: [EMAIL PROTECTED]
Subject: CONFIG_X86_ES7000=y, CONFIG_X86_GENERICARCH=n
l> From: Eric W. Biederman [mailto:[EMAIL PROTECTED]
Sent: Friday, February 16, 2007 2:22 AM
To: Protasevich, Natalie
Cc: Len Brown; Andi Kleen; lkml - Kernel Mailing List;
linux-acpi@vger.kernel.org
Subject: Re: [PATCH] i386: irq: Kill IRQ compression
[EMAIL PROTECTED] (Eric W. Biederman)
From: Eric W. Biederman [mailto:[EMAIL PROTECTED]
Sent: Friday, February 16, 2007 12:44 AM
To: Len Brown
Cc: Andi Kleen; Protasevich, Natalie; lkml - Kernel Mailing List;
linux-acpi@vger.kernel.org
Subject: Re: [PATCH] i386: irq: Kill IRQ compression
Len Brown <[EMAIL PROTECTED]> writes:
> This
From: Eric W. Biederman [mailto:[EMAIL PROTECTED]
Sent: Friday, February 16, 2007 12:44 AM
To: Len Brown
Cc: Andi Kleen; Protasevich, Natalie; lkml - Kernel Mailing List;
linux-acpi@vger.kernel.org
Subject: Re: [PATCH] i386: irq: Kill IRQ compression
Len Brown [EMAIL PROTECTED] writes:
This
l From: Eric W. Biederman [mailto:[EMAIL PROTECTED]
Sent: Friday, February 16, 2007 2:22 AM
To: Protasevich, Natalie
Cc: Len Brown; Andi Kleen; lkml - Kernel Mailing List;
linux-acpi@vger.kernel.org
Subject: Re: [PATCH] i386: irq: Kill IRQ compression
[EMAIL PROTECTED] (Eric W. Biederman)
Signed-off-by: Natalie Protasevich <[EMAIL PROTECTED]>
---
arch/i386/kernel/acpi/boot.c |2 ++
arch/i386/kernel/irq.c|8
arch/i386/kernel/mpparse.c|4
arch/i386/kernel/smpboot.c|3 ++-
arch/i386/mach-default/topology.c |4 ++
-by: Natalie Protasevich [EMAIL PROTECTED]
---
arch/i386/kernel/acpi/boot.c |2 ++
arch/i386/kernel/irq.c|8
arch/i386/kernel/mpparse.c|4
arch/i386/kernel/smpboot.c|3 ++-
arch/i386/mach-default/topology.c |4 ++--
kernel/cpu.c
This is subarch update for ES7000. I've modified platform check code and
removed unnecessary OEM table parsing for newer systems that don't use
OEM information during boot. Parsing the table in fact is causing problems,
and the platform doesn't get recognized.
The patch only affects the ES7000
This is subarch update for ES7000. I've modified platform check code and
removed unnecessary OEM table parsing for newer systems that don't use
OEM information during boot. Parsing the table in fact is causing problems,
and the platform doesn't get recognized.
The patch only affects the ES7000
, and
therefore
cannot handle IRQ numbers assigned to its devices. The patch corrects this
problem
by allowing PCI IRQs below 16.
Signed-off by: Natalie Protasevich <[EMAIL PROTECTED]>
---
diff -puN arch/x86_64/kernel/mpparse.c~irq-pack-x86_64-update
arch/x86_64/kernel/mpparse.c
--- linux-
by original patch
assigning IRQs
starting 16 and up. The VIA chipset uses 4-bit IRQ register for internal
interrupt routing, and
therefore cannot handle IRQ numbers assigned to its devices. The patch corrects
this problem
by allowing PCI IRQs below 16.
Signed-off by: Natalie Protasevich <[EM
by original patch
assigning IRQs
starting 16 and up. The VIA chipset uses 4-bit IRQ register for internal
interrupt routing, and
therefore cannot handle IRQ numbers assigned to its devices. The patch corrects
this problem
by allowing PCI IRQs below 16.
Signed-off by: Natalie Protasevich [EMAIL
, and
therefore
cannot handle IRQ numbers assigned to its devices. The patch corrects this
problem
by allowing PCI IRQs below 16.
Signed-off by: Natalie Protasevich [EMAIL PROTECTED]
---
diff -puN arch/x86_64/kernel/mpparse.c~irq-pack-x86_64-update
arch/x86_64/kernel/mpparse.c
--- linux-2.6.13-rc2
70 matches
Mail list logo
