ECTED]>; "Geoff Levand"
<[EMAIL PROTECTED]>; "Greg Kroah-Hartman" <[EMAIL PROTECTED]>; "Tony
Olech" <[EMAIL PROTECTED]>; ;
Sent: Thursday, March 29, 2007 11:06 PM
Subject: Re: 2.6.20-rc4-mm1: different values for OHCI_QUIRK_ZFMICRO
On Tue
On Thursday 29 March 2007 3:06 pm, Randy Dunlap wrote:
> On Tue, 20 Feb 2007 01:06:54 +0100 Adrian Bunk wrote:
>
> > On Sun, Jan 14, 2007 at 06:36:10AM -0800, David Brownell wrote:
> > > On Sunday 14 January 2007 1:10 am, Adrian Bunk wrote:
> > > > <-- snip -->
> > >
> > > Waiting for Tony to s
On Tue, 20 Feb 2007 01:06:54 +0100 Adrian Bunk wrote:
> On Sun, Jan 14, 2007 at 06:36:10AM -0800, David Brownell wrote:
> > On Sunday 14 January 2007 1:10 am, Adrian Bunk wrote:
> > > <-- snip -->
> >
> > Waiting for Tony to submit bugfixes to his driver...
>
> Still unfixed as of 2.6.20-mm1.
Hello,
Randy Dunlap wrote:
>> Erm, before I do that, could somebody explain what
>>
>> #define HAVE_PCI_REQ_REGIONS 2
>>
>> accompanying their declaration is for? I have't found any references to it
>> in
>> the source. Should I duplicate it for CONFIG_PCI=n case (I guess not)?
>
> I wouldn
On Tue, 06 Mar 2007 19:15:12 +0300 Sergei Shtylyov wrote:
> Hello.
>
> Greg KH wrote:
>
> >>>3x59x-fix-pci-resource-management.patch causes the following compile
> >>>error with CONFIG_PCI=n:
>
> >>><-- snip -->
>
> >>>...
> >>> CC drivers/net/3c59x.o
> >>>/hom
Hello.
Greg KH wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
<-- snip -->
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:
In function 'vortex_init_one':
/home/bunk/linux/kernel
On Mon, Feb 26, 2007 at 09:26:44AM -0800, Randy Dunlap wrote:
> On Mon, 26 Feb 2007 16:22:27 +0300 Sergei Shtylyov wrote:
>
> > Hello, I wrote:
> >
> > 3x59x-fix-pci-resource-management.patch causes the following compile
> > error with CONFIG_PCI=n:
> >
> > <-- snip -->
> >
>
On Mon, 26 Feb 2007 16:22:27 +0300 Sergei Shtylyov wrote:
> Hello, I wrote:
>
> 3x59x-fix-pci-resource-management.patch causes the following compile
> error with CONFIG_PCI=n:
>
> <-- snip -->
>
> ...
> CC drivers/net/3c59x.o
> /home/bunk/linux/kernel-2.6
Hello, I wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
<-- snip -->
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:
In function 'vortex_init_one':
/home/bunk/linux/kernel-2.6/l
On Sun, Jan 14, 2007 at 06:36:10AM -0800, David Brownell wrote:
> On Sunday 14 January 2007 1:10 am, Adrian Bunk wrote:
> > <-- snip -->
>
> Waiting for Tony to submit bugfixes to his driver...
Still unfixed as of 2.6.20-mm1.
> > ...
> > CC drivers/usb/misc/ftdi-elan.o
> > /home/bunk/li
Hello.
Sergei Shtylyov wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
<-- snip -->
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:
In function 'vortex_init_one':
/home/bunk/lin
Hello, I wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
<-- snip -->
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:
In function 'vortex_init_one':
/home/bunk/linux/kernel-2.6/li
Hello.
Adrian Bunk wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
<-- snip -->
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c: In
function 'vortex_init_one':
/home/bunk/linux/kerne
> On Wed, 17 Jan 2007 16:09:41 -0500 [EMAIL PROTECTED] wrote:
> commit d8238afa7eedc047b57da7ec98e98fb051fc4e85
> Author: Chris Leech <[EMAIL PROTECTED]>
> Date: Fri Nov 17 11:37:29 2006 -0800
>
> I/OAT: Add documentation for the tcp_dma_copybreak sysctl
>
> Signed-off-by: Chris Leech <
On Wed, Jan 17, 2007 at 07:00:48AM -0500, David Hollis wrote:
> > 'rmmod asix' takes a really long time (45-80s) with any setting, and
> > sometimes coincides with ksoftirqd pegging (99.9% CPU) for several
> > seconds.
>
> This I haven't seen before. Does it occur even when the device is able
> t
On Tue, 2007-01-16 at 17:59 -0500, Eric Buddington wrote:
> On Mon, Jan 15, 2007 at 08:32:17PM +, David Hollis wrote:
> > Interesting. It would really be something if your devices happen to
> > work better with 0. Wouldn't make much sense at all unfortunately. If
> > 0 works, could you also
On Mon, Jan 15, 2007 at 08:32:17PM +, David Hollis wrote:
> Interesting. It would really be something if your devices happen to
> work better with 0. Wouldn't make much sense at all unfortunately. If
> 0 works, could you also try setting it to 2 or 3? The PHY select value
> is a bit field w
On Mon, Jan 15 2007, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > In a previous write invoked by: fsck.ext3(1896): WRITE block 8552 on
> > > sdb1 end_buffer_async_write() is invoked.
> > >
> > > sdb1 is not a part of a raid device.
> >
> > When I briefly tested this b
On Mon, 2007-01-15 at 14:50 -0500, Eric Buddington wrote:
> The asix_write_cmd argument in question did indeed change from 0 to 1
> between 2.6.20-rc3-mm1 and -rc4-mm1. I'll change it back, rebuild,
> and test. Probably tomorrow.
>
Interesting. It would really be something if your devices happe
On Sat, 2007-01-13 at 15:31 -0500, Eric Buddington wrote:
> The following problem occured on an Athlon64 X2 under 2.6.20-rc4-mm1,
> but not 2.6.20-rc3-mm1.
>
> I'm using two D-Link DUB-E100 USB ethernet adapters, using the 'asix'
> driver. When I upgraded to 2.6.20-rc4-mm1, they were still recogni
On Mon, Jan 15, 2007 at 07:27:56PM +, David Hollis wrote:
> Do you happen to have a Rev. B1 DLink adapter? If so, the only change
> that was put in (PHY Select fix) should actually make these devices
> work. Can you check the top of the ax88772_bind() call in your file and
> see if it has thi
Hi Adrian,
Em Sáb, 2007-01-13 às 08:27 +0100, Adrian Bunk escreveu:
> On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.20-rc3-mm1:
> >...
> > git-dvb.patch
> >...
> > git trees
> >...
>
> drivers/media/video/sn9c102/sn9c102_pas202bca.c is no longer us
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> > In a previous write invoked by: fsck.ext3(1896): WRITE block 8552 on
> > sdb1 end_buffer_async_write() is invoked.
> >
> > sdb1 is not a part of a raid device.
>
> When I briefly tested this before I left (and found it broken), doing
> a cat /proc/m
On Mon, 2007-01-15 at 08:17 +0100, Ingo Molnar wrote:
> > Debug plan:
> > - revert md-* patches
> > - binary search
> >
> > Does someone have a better idea?
>
> Thomas saw something similar yesterday and he the partial results that
> git.block (between rc2-mm1 and rc4-mm1) breaks certain disk dr
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> My system hangs on this
> http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/bug2.jpg
> http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/mm-config
>
> Debug plan:
> - revert md-* patches
> - binary search
>
> Does
On Sun, Jan 14 2007, Thomas Gleixner wrote:
> On Sun, 2007-01-14 at 11:46 +0100, Thomas Gleixner wrote:
> > > Boot proceeds, but gets stuck hard at:
> > > "Remounting root filesystem in read-write mode:"
> > >
> > > No SysRq-T, nothing.
> > >
> > > The above BUG seems unrelated to that. Investiga
On Sun, Jan 14 2007, Thomas Gleixner wrote:
> On Mon, 2007-01-15 at 09:05 +1100, Jens Axboe wrote:
> > raid seems to have severe problems with the plugging change. I'll try
> > and find Neil and have a chat with him, hopefully we can work it out.
>
> Some hints:
>
> mount(1899): WRITE block 16424
On Mon, 2007-01-15 at 09:05 +1100, Jens Axboe wrote:
> raid seems to have severe problems with the plugging change. I'll try
> and find Neil and have a chat with him, hopefully we can work it out.
Some hints:
mount(1899): WRITE block 16424 on md3
call md_write_start
md3_raid1(438): WRITE block 40
On Fri, Jan 12 2007, Michal Piotrowski wrote:
> On 12/01/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> >On 12/01/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> >> On Friday, 12 January 2007 14:33, Michal Piotrowski wrote:
> >> > My system hangs on this
> >> >
> >http://www.stardust.webpag
On Sun, Jan 14 2007, Thomas Gleixner wrote:
> On Sun, 2007-01-14 at 11:46 +0100, Thomas Gleixner wrote:
> > > Boot proceeds, but gets stuck hard at:
> > > "Remounting root filesystem in read-write mode:"
> > >
> > > No SysRq-T, nothing.
> > >
> > > The above BUG seems unrelated to that. Investiga
On Sunday 14 January 2007 1:10 am, Adrian Bunk wrote:
> <-- snip -->
Waiting for Tony to submit bugfixes to his driver...
> ...
> CC drivers/usb/misc/ftdi-elan.o
> /home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/usb/misc/ftdi-elan.c:2307:1:
> warning: "OHCI_QUIRK_ZFMICRO" rede
On Sun, 2007-01-14 at 11:46 +0100, Thomas Gleixner wrote:
> > Boot proceeds, but gets stuck hard at:
> > "Remounting root filesystem in read-write mode:"
> >
> > No SysRq-T, nothing.
> >
> > The above BUG seems unrelated to that. Investigating further.
>
> Bisect identified: git-block.patch
Doe
On Sun, 2007-01-14 at 10:48 +0100, Thomas Gleixner wrote:
> ata_scsi_rbuf_get requests KM_IRQ0 type memory and calls kmap_atomic
> with interrupts enabled.
>
> Boot proceeds, but gets stuck hard at:
> "Remounting root filesystem in read-write mode:"
>
> No SysRq-T, nothing.
>
> The above BUG see
On Thu, 2007-01-11 at 22:26 -0800, Andrew Morton wrote:
> - Merged the "filesystem AIO patches".
Hotfixes alreday applied.
BUG: at
/home/tglx/work/kernel/vanilla/linux-2.6.20-rc4-mm1/arch/i386/mm/highmem.c:60
kmap_atomic()
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack
On Sat, Jan 13, 2007 at 01:08:46AM +0100, Michal Piotrowski wrote:
> Jiri Slaby napisał(a):
> > Frederik Deweerdt wrote:
> >> On Fri, Jan 12, 2007 at 05:53:08PM -0500, Len Brown wrote:
> >>> On Friday 12 January 2007 05:20, Frederik Deweerdt wrote:
> On Thu, Jan 11, 2007 at 10:26:27PM -0800, A
Jiri Slaby wrote:
>> On Fri, Jan 12, 2007 at 05:53:08PM -0500, Len Brown wrote:
>>> What do you see if on failure you also print out the params, like below?
[...]
> ACPI: acpi_table_parse(17, ) HPET NULL handler!
After re-enabling HPET, it disappeared.
regards,
--
http://www.fi.muni.cz/~
Jiri Slaby napisał(a):
> Frederik Deweerdt wrote:
>> On Fri, Jan 12, 2007 at 05:53:08PM -0500, Len Brown wrote:
>>> On Friday 12 January 2007 05:20, Frederik Deweerdt wrote:
On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/peop
Frederik Deweerdt wrote:
> On Fri, Jan 12, 2007 at 05:53:08PM -0500, Len Brown wrote:
>> On Friday 12 January 2007 05:20, Frederik Deweerdt wrote:
>>> On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3
On Fri, Jan 12, 2007 at 05:53:08PM -0500, Len Brown wrote:
> On Friday 12 January 2007 05:20, Frederik Deweerdt wrote:
> > On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
> > >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc4-mm1/
>
On Friday 12 January 2007 05:20, Frederik Deweerdt wrote:
> On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
> >
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc4-mm1/
> >
> Hi,
>
> The git-acpi.patch replaces earlier "if(!handler) retur
On Fri, 12 Jan 2007 14:00:16 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 12 Jan 2007, Paul Jackson wrote:
>
> > It might look clearer to someone who is focused on that particular
> > change, but it adds unnecessary noise for the other 90% of the readers
> > of that code who
Christoph wrote:
> If this is hidden in a macro then it may be overlooked.
Sooner or later, every line of code is important.
Shouting any one of them in #ifdef brackets creates
a noisier environment, increasing the chance of missing
another.
And besides ... the other umpteen cpuset hooks all use
On Fri, 12 Jan 2007, Paul Jackson wrote:
> It might look clearer to someone who is focused on that particular
> change, but it adds unnecessary noise for the other 90% of the readers
> of that code who are not concerned with cpusets at that point in time.
This is in NUMA specific code. And they s
> Sorry but there will be number of those once we get the dirty writeback
> for cpusets fixed. Did you review that patchset (only internally mailed
> so far).
I haven't reviewed it - sorry. Too much stuff; too little time.
If only I had Alan's bots, which are apparently on loan now to Andrew.
On Fri, 12 Jan 2007, Paul Jackson wrote:
> Argh - minor detail, but this is the first (outside of fs/proc/base.c)
> "#ifdef CONFIG_CPUSETS" in a kernel *.c file. I prefer to avoid that.
Sorry but there will be number of those once we get the dirty writeback
for cpusets fixed. Did you review tha
Christoph wrote:
> +++ linux-2.6.20-rc4-mm1/mm/mempolicy.c 2007-01-12 13:21:30.220968608
> -0600
> ...
> +#ifdef CONFIG_CPUSETS
Argh - minor detail, but this is the first (outside of fs/proc/base.c)
"#ifdef CONFIG_CPUSETS" in a kernel *.c file. I prefer to avoid that.
How about doing this
On Fri, 12 Jan 2007, Paul Jackson wrote:
> I'll leave the honors to Christoph (added to CC), since this is his patch.
Ok. Here it is
mems_allowed only exists if CONFIG_CPUSETS is set. So put an #ifdef around
it. Also move the masking of the nodes behind the error check (looks
better) and add a
On 12/01/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
On 12/01/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> On Friday, 12 January 2007 14:33, Michal Piotrowski wrote:
> > My system hangs on this
> > http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/bug2.jpg
> > http://ww
On 12/01/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
On Friday, 12 January 2007 14:33, Michal Piotrowski wrote:
> My system hangs on this
> http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/bug2.jpg
> http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/mm-config
Hello,
> This may help
> http://lkml.org/lkml/2007/1/12/45
True. Now it boots fine. Tanks for the tip.
Dzięki Michał.
--
Regards,
Mariusz Kozlowski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
On Friday, 12 January 2007 14:33, Michal Piotrowski wrote:
> My system hangs on this
> http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/bug2.jpg
> http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/mm-config
>
> Debug plan:
> - revert md-* patches
> - binary search
On 12/01/07, Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
Hello,
> That's because mmc_lock_unlock should depend on CONFIG_KEYS, it uses struct
key.
> Could you try the following patch (compile tested)?
Thanks. Compiles ok but now I run into another problem and the laptop doesn't
boot.
The las
Hello,
> That's because mmc_lock_unlock should depend on CONFIG_KEYS, it uses struct
> key.
> Could you try the following patch (compile tested)?
Thanks. Compiles ok but now I run into another problem and the laptop doesn't
boot.
The last thing I see is grub. So no way to test it now. Time to
On Fri, Jan 12, 2007 at 11:25:58AM +0100, Mariusz Kozlowski wrote:
> Hello,
>
> Doesn't build on my laptop.
>
> drivers/mmc/mmc.c: In function 'mmc_lock_unlock':
> drivers/mmc/mmc.c:1527: error: dereferencing pointer to incomplete type
> drivers/mmc/mmc.c:1527: warning: type defaults to 'in
Sander wrote:
> > +mbind-restrict-nodes-to-the-currently-allowed-cpuset.patch
>
> I had to revert this patch because of:
>
> ===
> mm/mempolicy.c: In function 'sys_mbind':
> mm/mempolicy.c:885: error: 'struct task_struct' has no member named
> 'mems_allowed'
You're right - this patch won't buil
Andrew Morton wrote (ao):
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc4-mm1/
> x86/x86_64 things
> +mbind-restrict-nodes-to-the-currently-allowed-cpuset.patch
I had to revert this patch because of:
===
mm/mempolicy.c: In function 'sys_mbind':
mm/mem
Hello,
Doesn't build on my laptop.
drivers/mmc/mmc.c: In function 'mmc_lock_unlock':
drivers/mmc/mmc.c:1527: error: dereferencing pointer to incomplete type
drivers/mmc/mmc.c:1527: warning: type defaults to 'int' in declaration of
'_p1'
drivers/mmc/mmc.c:1527: error: dereferencin
On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc4-mm1/
>
Hi,
The git-acpi.patch replaces earlier "if(!handler) return -EINVAL" by
"BUG_ON(!handler)". This locks my machine early at boot with
On Fri, 12 Jan 2007 01:18:17 -0600
"Miles Lane" <[EMAIL PROTECTED]> wrote:
> WARNING: "profile_hits" [drivers/kvm/kvm-intel.ko] undefined!
This?
From: Andrew Morton <[EMAIL PROTECTED]>
export profile_hits() on !SMP too.
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Avi Kivity <[EMAIL PROTECTED]>
Sig
WARNING: vmlinux - Section mismatch: reference to .init.text: from
.text between 'rest_init' (at offset 0xc0101131) and 'try_name'
WARNING: vmlinux - Section mismatch: reference to .init.text: from
.text between 'iret_exc' (at offset 0xc02d9ffa) and '_etext'
WARNING: vmlinux - Section mismatch: re
60 matches
Mail list logo
