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 address
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
informat
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 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 ha
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, clo
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 AP
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?
>
> http://kernelnewbies.or
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 a
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/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
> 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 suggesti
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 kern
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 a
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 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
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 clutte
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 is
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
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 somethin
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 jus
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?
>
> 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 12:13:50PM
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 o
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) write
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
rs.
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 |
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 s
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-
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
35 matches
Mail list logo