"Thomas Maier" <[EMAIL PROTECTED]> writes:
> this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20:
>
> - update documentation
> - removed DECLARE_BUF_AS_STRING macro
This part looks good.
> - use clear_bdi_congested/set_bdi_congested functions directly instead of old
Thomas Maier [EMAIL PROTECTED] writes:
this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20:
- update documentation
- removed DECLARE_BUF_AS_STRING macro
This part looks good.
- use clear_bdi_congested/set_bdi_congested functions directly instead of old
wrappers
Please attach patches as inline text, not as a binary file, so that we
can all read it.
Thomas Maier wrote:
Hello,
this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20:
- update documentation
- use clear_bdi_congested/set_bdi_congested functions directly instead of
ktcdvd-2.6.20-rc1-mm1.patch
Description: Binary data
-2.6.20-rc1-mm1.patch
Description: Binary data
Please attach patches as inline text, not as a binary file, so that we
can all read it.
Thomas Maier wrote:
Hello,
this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20:
- update documentation
- use clear_bdi_congested/set_bdi_congested functions directly instead of
Hi,
On Friday, 22 December 2006 18:30, Larry Finger wrote:
> I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on
> an HPC nx6325, with no luck, so far, although I'm using a firmware that has
> been reported to work with these boxes
> (http://gen
Hi,
On Friday, 22 December 2006 18:30, Larry Finger wrote:
I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on
an HPC nx6325, with no luck, so far, although I'm using a firmware that has
been reported to work with these boxes
(http://gentoo-wiki.com
I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on
an HPC nx6325, with no luck, so far, although I'm using a firmware that has
been reported to work with these boxes
(http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29).
The driver
I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on
an HPC nx6325, with no luck, so far, although I'm using a firmware that has
been reported to work with these boxes
(http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29).
The driver
Hi,
I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on
an HPC nx6325, with no luck, so far, although I'm using a firmware that has
been reported to work with these boxes
(http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29
At Wed, 20 Dec 2006 21:47:44 -0800,
Andrew Morton wrote:
>
> On Wed, 20 Dec 2006 20:20:45 +0300
> "Eugene Ilkov" <[EMAIL PROTECTED]> wrote:
>
> > There was some INIT_WORK related changes, here is patch against
> > wm8750 codec driver. Tested on sharp sl-
At Wed, 20 Dec 2006 21:47:44 -0800,
Andrew Morton wrote:
On Wed, 20 Dec 2006 20:20:45 +0300
Eugene Ilkov [EMAIL PROTECTED] wrote:
There was some INIT_WORK related changes, here is patch against
wm8750 codec driver. Tested on sharp sl-c1000
--- linux-2.6.20-rc1-mm1/sound/soc
Hi,
I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on
an HPC nx6325, with no luck, so far, although I'm using a firmware that has
been reported to work with these boxes
(http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29
On Wed, 20 Dec 2006 20:20:45 +0300
"Eugene Ilkov" <[EMAIL PROTECTED]> wrote:
> There was some INIT_WORK related changes, here is patch against
> wm8750 codec driver. Tested on sharp sl-c1000
>
>
> --- linux-2.6.20-rc1-mm1/sound/soc/codecs/wm8750.c2006-1
On Wed, 20 Dec 2006 15:06:28 -0500
"Bob Picco" <[EMAIL PROTECTED]> wrote:
> Sorry I was looking for AIM VII and/or reaim which are multiuser loads.
> The results (2.6.20-rc1-mm1) for EXTREME, SPARSEMEM+VMEMMAP and
> SPARSEMEM+VMEMMAP+your+patch are below. Note SPARSEMEM
s.
>
> I attaches my easy test result with *micro* benchmark on SMP system.
> I'm glad if you give me an advice about testing.
Sorry I was looking for AIM VII and/or reaim which are multiuser loads.
The results (2.6.20-rc1-mm1) for EXTREME, SPARSEMEM+VMEMMAP and
SPARSEMEM+VMEMMAP+your+patc
There was some INIT_WORK related changes, here is patch against
wm8750 codec driver. Tested on sharp sl-c1000
--- linux-2.6.20-rc1-mm1/sound/soc/codecs/wm8750.c 2006-12-20
19:23:27.0 +0300
+++ linux-2.6.20-rc1-mm.z1/sound/soc/codecs/wm8750.c2006-12-20
19:27:28.0 +0300
There was some INIT_WORK related changes, here is patch against
wm8750 codec driver. Tested on sharp sl-c1000
--- linux-2.6.20-rc1-mm1/sound/soc/codecs/wm8750.c 2006-12-20
19:23:27.0 +0300
+++ linux-2.6.20-rc1-mm.z1/sound/soc/codecs/wm8750.c2006-12-20
19:27:28.0 +0300
test result with *micro* benchmark on SMP system.
I'm glad if you give me an advice about testing.
Sorry I was looking for AIM VII and/or reaim which are multiuser loads.
The results (2.6.20-rc1-mm1) for EXTREME, SPARSEMEM+VMEMMAP and
SPARSEMEM+VMEMMAP+your+patch are below. Note SPARSEMEM+VMEMMAP
On Wed, 20 Dec 2006 15:06:28 -0500
Bob Picco [EMAIL PROTECTED] wrote:
Sorry I was looking for AIM VII and/or reaim which are multiuser loads.
The results (2.6.20-rc1-mm1) for EXTREME, SPARSEMEM+VMEMMAP and
SPARSEMEM+VMEMMAP+your+patch are below. Note SPARSEMEM+VMEMMAP AIM VII
wasn't
On Wed, 20 Dec 2006 20:20:45 +0300
Eugene Ilkov [EMAIL PROTECTED] wrote:
There was some INIT_WORK related changes, here is patch against
wm8750 codec driver. Tested on sharp sl-c1000
--- linux-2.6.20-rc1-mm1/sound/soc/codecs/wm8750.c2006-12-20
19:23:27.0 +0300
+++ linux
--- Damien Wyart <[EMAIL PROTECTED]> wrote:
> > > > The reiser4 failure is unexpected. Could you please see if you can
> > > > capture a trace, let the people at [EMAIL PROTECTED] know?
>
> > > Ok, I've handwritten the messages, here they are :
>
> > > reiser4 panicked cowardly :
On Thu, 2006-12-14 at 22:59 -0800, Tilman Schmidt wrote:
> [] rb_insert_color+0x55/0xbe
> [] enqueue_hrtimer+0x10a/0x116
> [] hrtimer_start+0x78/0x93
> [] get_signal_to_deliver+0xf3/0x74e
> [] do_notify_resume+0x93/0x655
> [] work_notifysig+0x13/0x1a
> [] 0xb7f5f410
Not really helpful.
>
On Fri, 15 Dec 2006 22:59:12 +0100, Jan Engelhardt said:
> I take it that people will automatically DTRT for obscure cases like
> shown before. Well, and if they don't, hopefully some reviewer catches
> things like 3*i + l<<2.
So I hacked up a few very ugly 'find|egrep' to look for some cases of
I tried kernel 2.6.20-rc1-mm1 with the "tickless" option on my P3/933
but it has now for the second time in a row caused a system freeze
as soon as I left the system idle for a couple of hours. The second
time I was warned and switched to a text console before I left the
system, an
I tried kernel 2.6.20-rc1-mm1 with the tickless option on my P3/933
but it has now for the second time in a row caused a system freeze
as soon as I left the system idle for a couple of hours. The second
time I was warned and switched to a text console before I left the
system, and was able
On Fri, 15 Dec 2006 22:59:12 +0100, Jan Engelhardt said:
I take it that people will automatically DTRT for obscure cases like
shown before. Well, and if they don't, hopefully some reviewer catches
things like 3*i + l2.
So I hacked up a few very ugly 'find|egrep' to look for some cases of
On Thu, 2006-12-14 at 22:59 -0800, Tilman Schmidt wrote:
[c021d049] rb_insert_color+0x55/0xbe
[c012d15b] enqueue_hrtimer+0x10a/0x116
[c012d9b4] hrtimer_start+0x78/0x93
[c0123453] get_signal_to_deliver+0xf3/0x74e
[c01026ee] do_notify_resume+0x93/0x655
[c0102ef5] work_notifysig+0x13/0x1a
--- Damien Wyart [EMAIL PROTECTED] wrote:
The reiser4 failure is unexpected. Could you please see if you can
capture a trace, let the people at [EMAIL PROTECTED] know?
Ok, I've handwritten the messages, here they are :
reiser4 panicked cowardly : reiser4[umount(2451)] :
On Mon, 18 Dec 2006 17:18:12 -0800 (PST)
David Rientjes <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Dec 2006, Andrew Morton wrote:
>
> > diff -puN mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling mm/vmscan.c
> > --- a/mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling
> > +++ a/mm/vmscan.c
> >
On Mon, 18 Dec 2006, Andrew Morton wrote:
> diff -puN mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling mm/vmscan.c
> --- a/mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling
> +++ a/mm/vmscan.c
> @@ -1484,6 +1484,16 @@ static unsigned long shrink_all_zones(un
> return ret;
> }
>
>
On Tuesday, 19 December 2006 00:17, Andrew Morton wrote:
> On Mon, 18 Dec 2006 23:38:23 +0100
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> > > > Looks like we have a problem with slab shrinking here.
> > > >
> > > > Could you please use gdb to check what exactly is at shrink_slab+0x9e?
>
On Mon, 18 Dec 2006 16:29:02 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote:
>
> Got this on booting up on x86_64 test box.
> Didn't happen on next boot.
>
>
> BUG: scheduling while atomic: hald-addon-stor/0x2000/3300
>
> Call Trace:
On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote:
Got this on booting up on x86_64 test box.
Didn't happen on next boot.
BUG: scheduling while atomic: hald-addon-stor/0x2000/3300
Call Trace:
[] show_trace+0x34/0x47
[] dump_stack+0x12/0x17
[] __sched_text_start+0x5d/0x7ba
[]
On Mon, 18 Dec 2006 23:38:23 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > Looks like we have a problem with slab shrinking here.
> > >
> > > Could you please use gdb to check what exactly is at shrink_slab+0x9e?
> >
> > Sure, but not till Friday, sorry (I am away).
>
> I
gt; > >> [ 310.030991] Shrinking memory... -<0>divide error: [#1]
> > > > >> [ 310.456669] SMP
> > > > >> [ 310.456814] last sysfs file:
> > > > >> /devices/pci:00/0000:00:1e.0/0000:02:08.0/eth0/statistics/collisions
sysfs file:
> > > >> /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions
> > > >> [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd
> > > >> ieee1394 cdrom
> > > >> [ 310.457259] CPU:0
> >
in: eth1394 floppy ohci1394 ide_cd
> > >> ieee1394 cdrom
> > >> [ 310.457259] CPU:0
> > >> [ 310.457260] EIP:0060:[]Not tainted VLI
> > >> [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
> > >> [ 310.457478]
14] last sysfs file:
> >> /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions
> >> [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394
> >> cdrom
> >> [ 310.457259] CPU:0
> >> [ 310.457260] EIP:0060:[
> >> [ 310.456814] last sysfs file:
> >> /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions
> >> [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394
> >> cdrom
> >> [ 310.457259] CPU:0
> >
On 12/15/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
+toshiba-tc86c001-ide-driver-take-2.patch
Acked-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
IMO this can be merged for 2.6.20 as it is new driver
(which is clean, tested and acked by Alan already)
All 693 patches:
Miles Lane wrote:
> On 12/18/06, Jiri Slaby <[EMAIL PROTECTED]> wrote:
>> Miles Lane wrote:
>> > Sorry, I am not finding who maintains highmem. Please forward.
>> >
>> > WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
>> > [] dump_trace+0x68/0x1d2
>> > [] show_trace_log_lvl+0x18/0x2c
>> >
On 12/18/06, Jiri Slaby <[EMAIL PROTECTED]> wrote:
Miles Lane wrote:
> Sorry, I am not finding who maintains highmem. Please forward.
>
> WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
> [] dump_trace+0x68/0x1d2
> [] show_trace_log_lvl+0x18/0x2c
> [] show_trace+0xf/0x11
> []
Miles Lane wrote:
> Sorry, I am not finding who maintains highmem. Please forward.
>
> WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
> [] dump_trace+0x68/0x1d2
> [] show_trace_log_lvl+0x18/0x2c
> [] show_trace+0xf/0x11
> [] dump_stack+0x12/0x14
> [] kmap_atomic+0x6f/0x1ca
> []
> > > The reiser4 failure is unexpected. Could you please see if you can
> > > capture a trace, let the people at [EMAIL PROTECTED] know?
> > Ok, I've handwritten the messages, here they are :
> > reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom
> >
] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394
>> cdrom
>> [ 310.457259] CPU:0
>> [ 310.457260] EIP:0060:[]Not tainted VLI
>> [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
>> [ 310.457478] EIP is at shrink_slab+0x9e/
(Yes, I *know* the answer is probably "Get Dell to fix the BIOS settings",
but I'll need some more info on exactly what to tell them so it gets fixed
right.
Scenario - I recently got a Dell Latitude D820 to replace my aging C840.
Am running Fedora Core Rawhide in (mostly) 64-bit mode.
Folly 1:
I'd never have noticed an issue if I hadn't looked in the dmesg for something
else, so it isn't a high-priority item.. I admit being fuzzy on what, if
anything, even *actually* needs fixing (ISTR for some people, there was some
config issue with the transparent bridges being only translucent, but
.457259] CPU:0
> [ 310.457260] EIP:0060:[]Not tainted VLI
> [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
> [ 310.457478] EIP is at shrink_slab+0x9e/0x169
Looks like we have a problem with slab shrinking here.
Could you please use gdb to check what exactly is a
s file:
/devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions
[ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 cdrom
[ 310.457259] CPU:0
[ 310.457260] EIP:0060:[]Not tainted VLI
[ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
[ 310.
Le 17.12.2006 12:07, Damien Wyart a écrit :
Also, I got panics when unmounting reiser4 filesystems with
2.6.20-rc1-mm1 but I guess this is related to your waring about
reiser4 being broken in 2.6.19-mm1 (even if it is not listed in
notes for 2.6.20-rc1-mm1)... I attach dmesg and config
Le 17.12.2006 12:07, Damien Wyart a écrit :
Also, I got panics when unmounting reiser4 filesystems with
2.6.20-rc1-mm1 but I guess this is related to your waring about
reiser4 being broken in 2.6.19-mm1 (even if it is not listed in
notes for 2.6.20-rc1-mm1)... I attach dmesg and config
:
/devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions
[ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 cdrom
[ 310.457259] CPU:0
[ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI
[ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207
]Not tainted VLI
[ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
[ 310.457478] EIP is at shrink_slab+0x9e/0x169
Looks like we have a problem with slab shrinking here.
Could you please use gdb to check what exactly is at shrink_slab+0x9e?
[ 310.457548] eax: ebx: ecx
I'd never have noticed an issue if I hadn't looked in the dmesg for something
else, so it isn't a high-priority item.. I admit being fuzzy on what, if
anything, even *actually* needs fixing (ISTR for some people, there was some
config issue with the transparent bridges being only translucent, but
(Yes, I *know* the answer is probably Get Dell to fix the BIOS settings,
but I'll need some more info on exactly what to tell them so it gets fixed
right.
Scenario - I recently got a Dell Latitude D820 to replace my aging C840.
Am running Fedora Core Rawhide in (mostly) 64-bit mode.
Folly 1: If
:0060:[c0150c9a]Not tainted VLI
[ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
[ 310.457478] EIP is at shrink_slab+0x9e/0x169
Looks like we have a problem with slab shrinking here.
Could you please use gdb to check what exactly is at shrink_slab+0x9e?
Sure, but not till
The reiser4 failure is unexpected. Could you please see if you can
capture a trace, let the people at [EMAIL PROTECTED] know?
Ok, I've handwritten the messages, here they are :
reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom
(fs/reiser4/txmngr.c:1087)
Miles Lane wrote:
Sorry, I am not finding who maintains highmem. Please forward.
WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
[c0103c25] dump_trace+0x68/0x1d2
[c0103da7] show_trace_log_lvl+0x18/0x2c
[c0104410] show_trace+0xf/0x11
[c010449b] dump_stack+0x12/0x14
[c01144d9]
On 12/18/06, Jiri Slaby [EMAIL PROTECTED] wrote:
Miles Lane wrote:
Sorry, I am not finding who maintains highmem. Please forward.
WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
[c0103c25] dump_trace+0x68/0x1d2
[c0103da7] show_trace_log_lvl+0x18/0x2c
[c0104410] show_trace+0xf/0x11
On 12/15/06, Andrew Morton [EMAIL PROTECTED] wrote:
+toshiba-tc86c001-ide-driver-take-2.patch
Acked-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
IMO this can be merged for 2.6.20 as it is new driver
(which is clean, tested and acked by Alan already)
All 693 patches:
floppy ohci1394 ide_cd ieee1394
cdrom
[ 310.457259] CPU:0
[ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI
[ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
[ 310.457478] EIP is at shrink_slab+0x9e/0x169
Looks like we have a problem with slab shrinking here
ide_cd ieee1394
cdrom
[ 310.457259] CPU:0
[ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI
[ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
[ 310.457478] EIP is at shrink_slab+0x9e/0x169
Looks like we have a problem with slab shrinking here.
Could you please
/statistics/collisions
[ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd
ieee1394 cdrom
[ 310.457259] CPU:0
[ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI
[ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
[ 310.457478] EIP is at shrink_slab+0x9e
] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
[ 310.457478] EIP is at shrink_slab+0x9e/0x169
Looks like we have a problem with slab shrinking here.
Could you please use gdb to check what exactly is at shrink_slab+0x9e?
Sure, but not till Friday, sorry (I am away).
I
] CPU:0
[ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI
[ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
[ 310.457478] EIP is at shrink_slab+0x9e/0x169
Looks like we have a problem with slab shrinking here.
Could you please use gdb to check
On Mon, 18 Dec 2006 23:38:23 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Looks like we have a problem with slab shrinking here.
Could you please use gdb to check what exactly is at shrink_slab+0x9e?
Sure, but not till Friday, sorry (I am away).
I reproduced this on one box,
On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote:
Got this on booting up on x86_64 test box.
Didn't happen on next boot.
BUG: scheduling while atomic: hald-addon-stor/0x2000/3300
Call Trace:
[8020ac30] show_trace+0x34/0x47
[8020ac55] dump_stack+0x12/0x17
On Mon, 18 Dec 2006 16:29:02 -0800
Randy Dunlap [EMAIL PROTECTED] wrote:
On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote:
Got this on booting up on x86_64 test box.
Didn't happen on next boot.
BUG: scheduling while atomic: hald-addon-stor/0x2000/3300
Call Trace:
On Tuesday, 19 December 2006 00:17, Andrew Morton wrote:
On Mon, 18 Dec 2006 23:38:23 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Looks like we have a problem with slab shrinking here.
Could you please use gdb to check what exactly is at shrink_slab+0x9e?
Sure, but not
On Mon, 18 Dec 2006, Andrew Morton wrote:
diff -puN mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling mm/vmscan.c
--- a/mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling
+++ a/mm/vmscan.c
@@ -1484,6 +1484,16 @@ static unsigned long shrink_all_zones(un
return ret;
}
+static
On Mon, 18 Dec 2006 17:18:12 -0800 (PST)
David Rientjes [EMAIL PROTECTED] wrote:
On Mon, 18 Dec 2006, Andrew Morton wrote:
diff -puN mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling mm/vmscan.c
--- a/mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling
+++ a/mm/vmscan.c
@@ -1484,6
On Fri, Dec 15 2006, Andrew Morton wrote:
> On Fri, 15 Dec 2006 21:39:36 +0100
> Damien Wyart <[EMAIL PROTECTED]> wrote:
>
> > With this new kernel, I notice two messages I do not have with
> > 2.6.19-rc6-mm2 :
> >
> > Dec 15 20:00:47 brouette kernel: Filesystem "sdb9": Disabling
> >
> > Also, I got panics when unmounting reiser4 filesystems with
> > 2.6.20-rc1-mm1 but I guess this is related to your waring about
> > reiser4 being broken in 2.6.19-mm1 (even if it is not listed in
> > notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the
> &
Also, I got panics when unmounting reiser4 filesystems with
2.6.20-rc1-mm1 but I guess this is related to your waring about
reiser4 being broken in 2.6.19-mm1 (even if it is not listed in
notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the
reiser4 panics did not get logged
On Fri, Dec 15 2006, Andrew Morton wrote:
On Fri, 15 Dec 2006 21:39:36 +0100
Damien Wyart [EMAIL PROTECTED] wrote:
With this new kernel, I notice two messages I do not have with
2.6.19-rc6-mm2 :
Dec 15 20:00:47 brouette kernel: Filesystem sdb9: Disabling
barriers,trial barrier
On Sat, 16 Dec 2006 10:38:53 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Sat, 16 Dec 2006, KAMEZAWA Hiroyuki wrote:
>
> > By this, we'll not access mem_section[] in usual ops.
>
> Why do we need mem_section? We have a page table that fulfills the same
> role.
>
Basically, we
On Sat, 16 Dec 2006, KAMEZAWA Hiroyuki wrote:
> By this, we'll not access mem_section[] in usual ops.
Why do we need mem_section? We have a page table that fulfills the same
role.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Any ideas? Happens only on some archs (not affected is alpha, i386, ia64, sparc,
sparc64). Happens not with 2.6.19(.1). See http://l4x.org/k/ for more logs.
2.6.20-rc1 is also affected.
# make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE=
O=/tmp/tmp.abUIc11429/out/um defconfig
# make
Hiroyuki <[EMAIL PROTECTED]>
arch/ia64/Kconfig|4
arch/ia64/mm/fault.c |4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
Index: devel-2.6.20-rc1-mm1/arch/ia64/Kconfig
===
--- devel-2.6.20-rc1-mm1.ori
range.
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
include/linux/mmzone.h | 10 ++
mm/Kconfig |4
mm/sparse.c|7 +++
3 files changed, 21 insertions(+)
Index: devel-2.6.20-rc1-mm1/include/linux/mm
This patch implements pfn_valid() micro optimization.
This uses ia64_pfn_valid() idea to check mem_map is valid or not instead of
sparsemem's logic.
By this, we'll not access mem_section[] in usual ops.
I attaches my easy test result with *micro* benchmark on SMP system.
I'm glad if you give me
This patch implements pfn_valid() micro optimization.
This uses ia64_pfn_valid() idea to check mem_map is valid or not instead of
sparsemem's logic.
By this, we'll not access mem_section[] in usual ops.
I attaches my easy test result with *micro* benchmark on SMP system.
I'm glad if you give me
range.
Signed-Off-By: KAMEZAWA Hiroyuki [EMAIL PROTECTED]
include/linux/mmzone.h | 10 ++
mm/Kconfig |4
mm/sparse.c|7 +++
3 files changed, 21 insertions(+)
Index: devel-2.6.20-rc1-mm1/include/linux/mmzone.h
Hiroyuki [EMAIL PROTECTED]
arch/ia64/Kconfig|4
arch/ia64/mm/fault.c |4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
Index: devel-2.6.20-rc1-mm1/arch/ia64/Kconfig
===
--- devel-2.6.20-rc1-mm1.orig/arch/ia64
Any ideas? Happens only on some archs (not affected is alpha, i386, ia64, sparc,
sparc64). Happens not with 2.6.19(.1). See http://l4x.org/k/ for more logs.
2.6.20-rc1 is also affected.
# make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE=
O=/tmp/tmp.abUIc11429/out/um defconfig
cut
#
On Sat, 16 Dec 2006, KAMEZAWA Hiroyuki wrote:
By this, we'll not access mem_section[] in usual ops.
Why do we need mem_section? We have a page table that fulfills the same
role.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Sat, 16 Dec 2006 10:38:53 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Sat, 16 Dec 2006, KAMEZAWA Hiroyuki wrote:
By this, we'll not access mem_section[] in usual ops.
Why do we need mem_section? We have a page table that fulfills the same
role.
Basically, we don't
On Sat, 16 Dec 2006 00:25:43 +0059
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
> >
> > Will appear later at
> >
> >
> > ftp://ftp.kerne
On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-mm1:
>...
> +debugging-feature-proc-timer_list.patch
>
> Refreshed, refactored dynticks/hrtimer queue.
>...
I'd assume sysrq_timer_list_show() wasn't intended to be unused?
cu
Adrian
--
"Is
On Fri, 15 Dec 2006 11:24:12 -0800, Andrew Morton wrote:
>On Fri, 15 Dec 2006 15:45:55 +0059
>Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>> > Temporarily at
>> >
>> > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>>
Mikael Pettersson wrote:
> Applying the trivial patch below on top of 2.6.20-rc1-mm1 should
Yup, Jeff fwd me this yet and it works.
thanks,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pub
Andrew Morton wrote:
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>
> Will appear later at
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
Ok, after fixing sata_promise, I got thi
Andrew Morton wrote:
> On Fri, 15 Dec 2006 15:45:55 +0059
> Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>>> Temporarily at
>>>
>>> http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>>>
>>> Will appear late
I'd expect that
something got broken in sata, ata_piix or the block core which caused the
"trial barrier write" to start failing. Various cc's hopefully added.
> Also, I got panics when unmounting reiser4 filesystems with
> 2.6.20-rc1-mm1 but I guess this is related to your war
On Fri, 15 Dec 2006 15:45:55 +0059
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
> >
> > Will appear later at
> >
> >
> > ftp://ftp.kerne
Andrew Morton wrote:
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>
> Will appear later at
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
The kernel panics at boot in pdc_port_start
Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
http
On Fri, 15 Dec 2006 15:45:55 +0059
Jiri Slaby [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1
1 - 100 of 109 matches
Mail list logo
