* 瓦版【最新号】
From: yanjing @ 2006-04-03 9:36 UTC (permalink / raw)
To: nfs
コミュニティサイトで繰り広げられるラブストーリー
http://staywithyou.be/kawara/
問）
fengyue@mail.goo.ne.jp
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: slow susped to disk
From: Rafael J. Wysocki @ 2006-04-03 9:28 UTC (permalink / raw)
To: Zaher Salman; +Cc: linux-acpi, Pavel Machek
In-Reply-To: <4430E44B.7070003@triumf.ca>
Hi,
On Monday 03 April 2006 11:00, Zaher Salman wrote:
> I upgraded the kernel from 2.6.15 to 2.6.16 on my presario 2100. Both
> kernels were compiled with the similar configuration files. Anyway I
> found that suspend to disk (and resume) is much slower on 2.6.16
> compared to 2.6.15. Any idea for why that might happen or how can I
> speed it up? There is also a big difference when suspending with the
> laptop plugged or not..
This is because the size of the suspend image is now greater than
for 2.6.15.
There's the /sys/power/image_size knob that controls the size of the image.
If you set it to 0 (eg. by echo 0 > /sys/power/image_size as root), the
2.6.15 behavior should be restored. However, if you set image_size > 0
it should improve the system responsiveness after resume.
Please refer to Documentation/power/interface.txt in the kernel tree for
details.
Greetings,
Rafael
^ permalink raw reply
* Re: 2.6.17-rc1 core_sys_select incompatible pointer types
From: Andrew Morton @ 2006-04-03 9:27 UTC (permalink / raw)
To: Keith Owens; +Cc: mitch, linux-kernel
In-Reply-To: <26766.1144055892@kao2.melbourne.sgi.com>
Keith Owens <kaos@sgi.com> wrote:
>
> When did arithmetic on void pointers become acceptable? I know that it
> is a gcc extension but AFAIK its use is discouraged. Or am I in the
> wrong parallel universe again?
Yes, it's a gccism, but we actually use it rather a lot here and there.
It's quite useful for avoiding casting.
^ permalink raw reply
* RAID rebuild I/O bandwidth
From: Yogesh Pahilwan @ 2006-04-03 9:24 UTC (permalink / raw)
To: linux-raid
Hi Folks,
I am doing some research on calculating I/O performance of a raid array.
I want to test the RAID rebuild.
Can anyone specify what raid rebuild I/O bandwidth is?
How should I set 10MB/sec of rebuild I/O bandwidth?
How should I measure time to rebuild a disk?
Thanks in advance,
Thanks,
Yogesh
^ permalink raw reply
* Re: [RESEND][2.6.15] New ATA error messages on upgrade to 2.6.15
From: Alan Cox @ 2006-04-03 9:29 UTC (permalink / raw)
To: Mikael Pettersson
Cc: mrmacman_g4, edmudama, hahn, hancockr, jujutama, linux-kernel
In-Reply-To: <200604030907.k33974O9020701@harpo.it.uu.se>
On Llu, 2006-04-03 at 11:07 +0200, Mikael Pettersson wrote:
> 20269 PCI controller card. The 20269+cable+disk does udma5
> just fine in a PC, but throws a few BadCRCs at bootup on
> the PowerMac, resets and drops to udma4, and then things work
> OK for me, but I don't stress it very much (no RAID).
Interesting.
> Since the card's bios doesn't get run at powerup, I always
> suspected that the driver fails to initialize some timing thing.
The BIOS does various bits of PCI bus setup on some systems including
latency setting. That might be relevant, especially latency to get
bursting.
> Another possibility is the "data coherency" issue in some
> G4 CPUs which requires mappings of memory shared with other
> agents to use some additional magic in the page table.
The CRC is computed between the controller as the bits get fired over
the cable and drive so it shouldn't be caused by any weird bus timings.
More info would be useful although it may be a while before I can look
at it
^ permalink raw reply
* Re: Float numbers in module programming
From: Jan Engelhardt @ 2006-04-03 9:20 UTC (permalink / raw)
To: Helge Hafting; +Cc: Phillip Susi, linux-os (Dick Johnson), beware, linux-kernel
In-Reply-To: <4430C6E5.20101@aitel.hist.no>
>
> To further complicate this: Your driver can save the FPU registers,
> but it too may get interrupted. Possibly even by another instance of
> itself, if the user have several devices.
>
In which case the drive author probably already uses interrupt disabling.
Jan Engelhardt
--
^ permalink raw reply
* Re: 2.6.17-rc1 core_sys_select incompatible pointer types
From: Keith Owens @ 2006-04-03 9:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: Mitchell Blank Jr, linux-kernel
In-Reply-To: <20060403020916.57c9eaec.akpm@osdl.org>
Andrew Morton (on Mon, 3 Apr 2006 02:09:16 -0700) wrote:
>Mitchell Blank Jr <mitch@sfgoth.com> wrote:
>> I posted a patch to fix this and another problem with the recent select
>> changes a couple days ago.
>>
>> Original version, with description:
>> http://lkml.org/lkml/2006/3/31/308
>> Slightly updated:
>> http://lkml.org/lkml/2006/3/31/316
>>
>> I'm hoping that Andrew picked it up.
>
>Nope. I queued up the below. If anything additional is needed, please
>resend.
>
>
>diff -puN fs/select.c~select-warning-fixes fs/select.c
>--- devel/fs/select.c~select-warning-fixes 2006-04-01 22:27:14.000000000 -0800
>+++ devel-akpm/fs/select.c 2006-04-01 22:28:50.000000000 -0800
>@@ -310,7 +310,7 @@ static int core_sys_select(int n, fd_set
> fd_set __user *exp, s64 *timeout)
> {
> fd_set_bits fds;
>- char *bits;
>+ void *bits;
> int ret, size, max_fdset;
> struct fdtable *fdt;
> /* Allocate small arguments on the stack to save memory and be faster */
>@@ -341,12 +341,12 @@ static int core_sys_select(int n, fd_set
> bits = kmalloc(6 * size, GFP_KERNEL);
> if (!bits)
> goto out_nofds;
>- fds.in = (unsigned long *) bits;
>- fds.out = (unsigned long *) (bits + size);
>- fds.ex = (unsigned long *) (bits + 2*size);
>- fds.res_in = (unsigned long *) (bits + 3*size);
>- fds.res_out = (unsigned long *) (bits + 4*size);
>- fds.res_ex = (unsigned long *) (bits + 5*size);
>+ fds.in = bits;
>+ fds.out = bits + size;
>+ fds.ex = bits + 2*size;
>+ fds.res_in = bits + 3*size;
>+ fds.res_out = bits + 4*size;
>+ fds.res_ex = bits + 5*size;
>
> if ((ret = get_fd_set(n, inp, fds.in)) ||
> (ret = get_fd_set(n, outp, fds.out)) ||
When did arithmetic on void pointers become acceptable? I know that it
is a gcc extension but AFAIK its use is discouraged. Or am I in the
wrong parallel universe again?
^ permalink raw reply
* [PATCH] arm's arch_local_page_offset() fix against 2.6.17-rc1
From: KAMEZAWA Hiroyuki @ 2006-04-03 9:19 UTC (permalink / raw)
To: LKML; +Cc: rmk+lkml, pavel, Andrew Morton
This patch fixes arch_local_page_offset(pfn,nid) in arm.
This new one (added by unify_pfn_to_page patches) is obviously buggy.
This macro calculate page offset in a node.
Note: about LOCAL_MAP_NR()
comment in arm's sub-archs says...
/*
* Given a kaddr, LOCAL_MAP_NR finds the owning node of the memory
* and returns the index corresponding to the appropriate page in the
* node's mem_map.
*/
but LOCAL_MAP_NR() is designed to be able to take both paddr and kaddr.
In this case, paddr is better.
Signed-Off-By:KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitu.com>
Index: linux-2.6.17-rc1/include/asm-arm/memory.h
===================================================================
--- linux-2.6.17-rc1.orig/include/asm-arm/memory.h
+++ linux-2.6.17-rc1/include/asm-arm/memory.h
@@ -188,7 +188,7 @@ static inline __deprecated void *bus_to_
*/
#include <linux/numa.h>
#define arch_pfn_to_nid(pfn) (PFN_TO_NID(pfn))
-#define arch_local_page_offset(pfn, nid) (LOCAL_MAP_NR((pfn) << PAGE_OFFSET))
+#define arch_local_page_offset(pfn, nid) LOCAL_MAP_NR((pfn) << PAGE_SHIFT)
#define pfn_valid(pfn) \
({ \
^ permalink raw reply
* [Xenomai-help] Problem with posix skin and Xenomai 2.1.0
From: Jens Niehaus @ 2006-04-03 9:17 UTC (permalink / raw)
To: xenomai
Hi,
I am experiencing problems with xenomai 2.1.0 and pthread_mutex_init. The second initialization in the following program returns with a value of 16 (EBUSY). What is wrong with the code (or with xenomai)?
Thanks in advance,
Jens
---------------------------------------
#include <pthread.h>
#include <stdio.h>
int main( int argc, char *argv[] )
{
pthread_mutex_t m1;
pthread_mutex_t m2;
int ret;
if ( (ret = pthread_mutex_init( &m1, NULL ) ) )
{
printf("First init failed, ret=%i\n", ret );
return ret;
}
/* sleep(1); */
if ( ( ret = pthread_mutex_init( &m2, NULL ) ) )
{
printf("Second init failed, ret=%i\n", ret );
return ret;
}
printf("Done\n");
return 0;
}
--------------------------------------
I am using xenomai 2.1.0 and kernel 2.6.15.7 compiled with gcc 3.3.5 (SuSE 9.3).
The program does work
- when using xenomai 2.1-rc2
- when compiling without xenomai
- when sleep(1) is inserted between the calls to pthread_mutex_init
The program does not work
- when using kernel 2.6.14.6
- with mutex initialization after pthread_setschedparam( pthread_self(), SCHED_FIFO, ... );
- with mutex initialization in a newly created, SCHED_FIFO enabled thread
- when using pthread_mutexattr_t structures for initialization
- on different processors: Athlon 64 2800+ (build system) and VIA Samuel 2 533Mhz (target system)
Here is some more information, which might be helpful:
root: cat /proc/cmdline
auto BOOT_IMAGE=xenomai rw root=100 init=/linuxrc ramdisk_size=8196 noapic noacpi noapm
root: grep /configure /usr/src/xenomai-build/config.log
$ ../xenomai-2.1.0/configure --enable-x86-tsc --enable-debug
root: zcat /proc/config.gz|grep XENO |grep -v "not set"
CONFIG_XENOMAI=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY=y
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=128
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_DEBUG=y
CONFIG_XENO_OPT_TIMING_PERIODIC=y
CONFIG_XENO_OPT_TIMING_PERIOD=0
CONFIG_XENO_OPT_TIMING_TIMERLAT=0
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
CONFIG_XENO_OPT_TIMER_LIST=y
CONFIG_XENO_HW_FPU=y
CONFIG_XENO_HW_SMI_DETECT=y
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
CONFIG_XENO_SKIN_POSIX=y
CONFIG_XENO_SKIN_RTDM=y
Compilation:
gcc -g $(shell xeno-config --posix-cflags) mutextst.c $(shell xeno-config --posix-ldflags) -o mutextstxeno
gcc -g mutextst.c -lpthread -o mutextst
^ permalink raw reply
* Re: Access to a text file with a proc file
From: beware @ 2006-04-03 9:16 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3fd7d9680603310633j230dceecoee49efe4e7de1c7a@mail.gmail.com>
Hi,
well anybody knows, or is just impossible ?
^ permalink raw reply
* xen2 system crashing: Badness in br_fdb_cleanup at net/bridge/br_fdb.c:140
From: Hans-Christian Armingeon @ 2006-04-03 9:16 UTC (permalink / raw)
To: xen-devel; +Cc: xen-users
Hi There,
I am having serious troubles with one of my servers.
I installed ubuntu 5.10 on a second partition.
And after that, I booted the old system.
Now I am having these errors. They appear 3 minutes after reboot.
Has anyone a similar behaviour?
Many thanks in advance,
Johnny
Badness in br_fdb_cleanup at net/bridge/br_fdb.c:140
[<c8a5d49e>] br_fdb_cleanup+0xfe/0x130 [bridge]
[<c0123b61>] run_timer_softirq+0xf1/0x220
[<c0138470>] handle_IRQ_event+0x40/0x90
[<c8a5d3a0>] br_fdb_cleanup+0x0/0x130 [bridge]
[<c011f595>] __do_softirq+0x95/0xb0
[<c011f5f5>] do_softirq+0x45/0x50
[<c011f6c5>] irq_exit+0x35/0x40
[<c010ec3e>] do_IRQ+0x1e/0x30
[<c0105e7d>] evtchn_do_upcall+0x6d/0x90
[<c0109423>] hypervisor_callback+0x37/0x40
[<c0106f59>] xen_idle+0x29/0x50
[<c0106fba>] cpu_idle+0x3a/0x50
[<c0542740>] start_kernel+0x180/0x1d0
[<c0542300>] unknown_bootoption+0x0/0x1b0
Badness in br_fdb_cleanup at net/bridge/br_fdb.c:140
[<c8a5d49e>] br_fdb_cleanup+0xfe/0x130 [bridge]
[<c0123b61>] run_timer_softirq+0xf1/0x220
[<c0138470>] handle_IRQ_event+0x40/0x90
[<c8a5d3a0>] br_fdb_cleanup+0x0/0x130 [bridge]
[<c011f595>] __do_softirq+0x95/0xb0
[<c011f5f5>] do_softirq+0x45/0x50
[<c011f6c5>] irq_exit+0x35/0x40
[<c010ec3e>] do_IRQ+0x1e/0x30
[<c0105e7d>] evtchn_do_upcall+0x6d/0x90
[<c0109423>] hypervisor_callback+0x37/0x40
[<c0106f59>] xen_idle+0x29/0x50
[<c0106fba>] cpu_idle+0x3a/0x50
[<c0542740>] start_kernel+0x180/0x1d0
[<c0542300>] unknown_bootoption+0x0/0x1b0
Unable to handle kernel paging request at virtual address 00200200
printing eip:
c8a5d415
*pde = ma 00000000 pa 55555000
[<c0123b61>] run_timer_softirq+0xf1/0x220
[<c0138470>] handle_IRQ_event+0x40/0x90
[<c8a5d3a0>] br_fdb_cleanup+0x0/0x130 [bridge]
[<c011f595>] __do_softirq+0x95/0xb0
[<c011f5f5>] do_softirq+0x45/0x50
[<c011f6c5>] irq_exit+0x35/0x40
[<c010ec3e>] do_IRQ+0x1e/0x30
[<c0105e7d>] evtchn_do_upcall+0x6d/0x90
[<c0109423>] hypervisor_callback+0x37/0x40
[<c0106f59>] xen_idle+0x29/0x50
[<c0106fba>] cpu_idle+0x3a/0x50
[<c0542740>] start_kernel+0x180/0x1d0
[<c0542300>] unknown_bootoption+0x0/0x1b0
Oops: 0002 [#1]
PREEMPT
Modules linked in: bridge atm fcdslusb2 capi capifs ipv6 tsdev evdev fcpci kernelcapi i2c_amd756 i2c_amd8111 pci_hotplug ohci_hcd usbcore aic79xx sata_sil libata w83781d i2c_sensor i2c_isa i2c_core e100 mii tg3
CPU: 0
EIP: 0061:[<c8a5d415>] Tainted: P VLI
EFLAGS: 00211246 (2.6.11.12-xen0)
EIP is at br_fdb_cleanup+0x75/0x130 [bridge]
eax: 00000000 ebx: c3a5144c ecx: c04b04d8 edx: 00200200
esi: c3a51440 edi: c6227b04 ebp: c3ac7e88 esp: c0541f00
ds: 007b es: 007b ss: 0069
Process swapper (pid: 0, threadinfo=c0540000 task=c04aaea0)
Stack: c8a63f11 c8a63e09 c8a63efd 0000008c 00007530 c764f000 c0540000 00000101
c3ac7a20 c0540000 c0123b61 c3ac7a20 c0138470 00000082 00000000 c8a5d3a0
c8b443b8 c6e9d0ac c0540000 00000001 c058ab28 0000000a fbffc000 c011f595
Call Trace:
[<c0123b61>] run_timer_softirq+0xf1/0x220
[<c0138470>] handle_IRQ_event+0x40/0x90
[<c8a5d3a0>] br_fdb_cleanup+0x0/0x130 [bridge]
[<c011f595>] __do_softirq+0x95/0xb0
[<c011f5f5>] do_softirq+0x45/0x50
[<c011f6c5>] irq_exit+0x35/0x40
[<c010ec3e>] do_IRQ+0x1e/0x30
[<c0105e7d>] evtchn_do_upcall+0x6d/0x90
[<c0109423>] hypervisor_callback+0x37/0x40
[<c0106f59>] xen_idle+0x29/0x50
[<c0106fba>] cpu_idle+0x3a/0x50
[<c0542740>] start_kernel+0x180/0x1d0
[<c0542300>] unknown_bootoption+0x0/0x1b0
Code: 65 90 8d 74 26 00 8d 73 f4 8b 54 24 10 a1 60 e0 4a c0 03 56 18 39 d0 0f 88 9c 00 00 00 80 7e 23 00 75 68 8b 43 f4 8b 56 04 85 c0 <89> 02 74 03 89 50 04 80 7e 23 00 c7 46 04 00 02 20 00 75 17 8b
<0>Kernel panic - not syncing: Fatal exception in interrupt
(XEN) Domain 0 shutdown: rebooting machine.
(XEN) Reboot disabled on cmdline: require manual reset
--
jabber:johnny@wh-netz.de
icq:236971856
^ permalink raw reply
* Summary: kernel/built-in.o: In function `do_exit':: undefined reference to `exit_io_context'
From: Will L Givens @ 2006-04-03 9:12 UTC (permalink / raw)
To: linux-kernel
Was attempting to build Kernel-2.6.16.1 and received the following error:
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
kernel/built-in.o: In function `do_exit':
: undefined reference to `exit_io_context'
kernel/built-in.o: In function `do_exit':
: undefined reference to `exit_io_context'
mm/built-in.o: In function `generic_write_checks':
: undefined reference to `bdev_read_only'
mm/built-in.o: In function `generic_write_checks':
: undefined reference to `bdev_read_only'
>>>> CONTINUE <<<<
I ran the the following:
[root@jericho linux-2.6.16.1]# sh scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux jericho.southkc.net 2.6.14.3 #2 Mon Mar 20 17:35:40 CST 2006 alpha
unknown unknown GNU/Linux
Gnu C 4.0.1
Gnu make 3.80
binutils 2.16.90.0.3
util-linux 2.11f
mount 2.11g
module-init-tools 3.1
e2fsprogs 1.38
reiserfsprogs 2001------------->
reiser4progs fsck.reiser4:
quota-tools 3.01.
PPP 2.4.1
isdn4k-utils 3.1pre1
nfs-utils 0.3.1
awk: cmd. line:2: (FILENAME=- FNR=1) fatal: attempt to access field -1
Dynamic linker (ldd) 2.3.2
Linux C++ Library 6.0.3
Procps 3.2.4
Net-tools 1.60
Console-tools 0.3.3
Sh-utils 5.2.1
Modules Loaded
I created a patch in order to include the 'block/' directory and everything
appears to run fine.
--- arch/alpha/Makefile-orig Mon Apr 3 03:58:00 2006
+++ arch/alpha/Makefile Mon Apr 3 04:03:08 2006
@@ -88,7 +88,7 @@
head-y := arch/alpha/kernel/head.o
-core-y += arch/alpha/kernel/ arch/alpha/mm/
+core-y += arch/alpha/kernel/ arch/alpha/mm/ block/
core-$(CONFIG_MATHEMU) += arch/alpha/math-emu/
drivers-$(CONFIG_OPROFILE) += arch/alpha/oprofile/
libs-y += arch/alpha/lib/
If you like, could you please include the following patch in your later
kernel releases? Thank you for you time... Will L Givens
[wlgivens@southkc.net]
^ permalink raw reply
* Re: Who wants to test cracklinux??
From: Jan Engelhardt @ 2006-04-03 9:11 UTC (permalink / raw)
To: Alan Cox; +Cc: Arjan van de Ven, Ben Ford, linux-kernel
In-Reply-To: <1144019771.31123.31.camel@localhost.localdomain>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 607 bytes --]
>> is there any difference? I mean... if you can outb you for all intents
>> and purposes are root anyway ;) (like you can overwrite any memory in
>> the system etc etc)
>
>There are two clear uses
>
>#1 Its possible to write such a module to allow only some ports to be
>accessed, eg to export a PCI device for learning purposes
>
You can do parts of that in userspace, which is A Good Thing(tm).
Write a SUID wrapper which ioperm's (or denies it) a range request, opens
/dev/mem or /dev/port and then drops privilegues. Voilà.
(Not sure if outb requires root too, besides ioperm.)
Jan Engelhardt
--
^ permalink raw reply
* Re: 2.6.17-rc1 core_sys_select incompatible pointer types
From: Andrew Morton @ 2006-04-03 9:09 UTC (permalink / raw)
To: Mitchell Blank Jr; +Cc: kaos, linux-kernel
In-Reply-To: <20060403084410.GD3157@gaz.sfgoth.com>
Mitchell Blank Jr <mitch@sfgoth.com> wrote:
>
> Keith Owens wrote:
> > 2.6.17-rc1, ia64, gcc 3.3.3
> >
> > fs/select.c: In function `core_sys_select':
> > fs/select.c:339: warning: assignment from incompatible pointer type
> > fs/select.c:376: warning: comparison of distinct pointer types lacks a cast
>
> I posted a patch to fix this and another problem with the recent select
> changes a couple days ago.
>
> Original version, with description:
> http://lkml.org/lkml/2006/3/31/308
> Slightly updated:
> http://lkml.org/lkml/2006/3/31/316
>
> I'm hoping that Andrew picked it up.
Nope. I queued up the below. If anything additional is needed, please
resend.
diff -puN fs/select.c~select-warning-fixes fs/select.c
--- devel/fs/select.c~select-warning-fixes 2006-04-01 22:27:14.000000000 -0800
+++ devel-akpm/fs/select.c 2006-04-01 22:28:50.000000000 -0800
@@ -310,7 +310,7 @@ static int core_sys_select(int n, fd_set
fd_set __user *exp, s64 *timeout)
{
fd_set_bits fds;
- char *bits;
+ void *bits;
int ret, size, max_fdset;
struct fdtable *fdt;
/* Allocate small arguments on the stack to save memory and be faster */
@@ -341,12 +341,12 @@ static int core_sys_select(int n, fd_set
bits = kmalloc(6 * size, GFP_KERNEL);
if (!bits)
goto out_nofds;
- fds.in = (unsigned long *) bits;
- fds.out = (unsigned long *) (bits + size);
- fds.ex = (unsigned long *) (bits + 2*size);
- fds.res_in = (unsigned long *) (bits + 3*size);
- fds.res_out = (unsigned long *) (bits + 4*size);
- fds.res_ex = (unsigned long *) (bits + 5*size);
+ fds.in = bits;
+ fds.out = bits + size;
+ fds.ex = bits + 2*size;
+ fds.res_in = bits + 3*size;
+ fds.res_out = bits + 4*size;
+ fds.res_ex = bits + 5*size;
if ((ret = get_fd_set(n, inp, fds.in)) ||
(ret = get_fd_set(n, outp, fds.out)) ||
_
^ permalink raw reply
* 2.6.14.6 BUG: spinlock cpu recursion on CPU#1, kswapd0/185
From: Frank van Maarseveen @ 2006-04-03 9:08 UTC (permalink / raw)
To: linux-kernel
Cannot reproduce but the stack trace might be useful:
kernel: BUG: spinlock cpu recursion on CPU#1, kswapd0/185
kernel: lock: cedef1d0, .magic: dead4ead, .owner: lk166/2501, .owner_cpu: 1
kernel: [dump_stack+23/32] dump_stack+0x17/0x20
kernel: [spin_bug+134/144] spin_bug+0x86/0x90
kernel: [_raw_spin_lock+85/128] _raw_spin_lock+0x55/0x80
kernel: [_spin_lock+9/16] _spin_lock+0x9/0x10
kernel: [page_check_address+27/128] page_check_address+0x1b/0x80
kernel: [page_referenced_one+71/208] page_referenced_one+0x47/0xd0
kernel: [page_referenced_file+128/192] page_referenced_file+0x80/0xc0
kernel: [page_referenced+125/144] page_referenced+0x7d/0x90
kernel: [shrink_list+200/1024] shrink_list+0xc8/0x400
kernel: [shrink_cache+262/672] shrink_cache+0x106/0x2a0
kernel: [shrink_zone+197/256] shrink_zone+0xc5/0x100
kernel: [balance_pgdat+598/832] balance_pgdat+0x256/0x340
kernel: [kswapd+220/272] kswapd+0xdc/0x110
kernel: [kernel_thread_helper+5/12] kernel_thread_helper+0x5/0xc
gcc version 3.3.5 (Debian 1:3.3.5-13)
--
Frank
^ permalink raw reply
* Re: include/asm-arm/memory.h changes break zaurus sl-5500 boot
From: KAMEZAWA Hiroyuki @ 2006-04-03 9:08 UTC (permalink / raw)
To: Russell King; +Cc: pavel, rpurdie, lenz, linux-kernel, akpm
In-Reply-To: <20060403090207.GB15606@flint.arm.linux.org.uk>
On Mon, 3 Apr 2006 10:02:07 +0100
Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> In turn, that means that we can pass it whatever address we happen to
> have available at the time, or whichever is simpler to calculate.
>
interesting :)
> In the cases you're looking at (pfn to map number) giving it pfn <<
> PAGE_SHIFT is entirely sufficient, and is in fact optimal for
> performance.
Ok, I'll post fixed patch, which uses LOCAL_MAP_NR((pfn) << PAGE_SHIFT)
Thank you for advices!
--Kame
^ permalink raw reply
* Re: [RESEND][2.6.15] New ATA error messages on upgrade to 2.6.15
From: Mikael Pettersson @ 2006-04-03 9:07 UTC (permalink / raw)
To: alan, mrmacman_g4; +Cc: edmudama, hahn, hancockr, jujutama, linux-kernel
On Sun, 02 Apr 2006 22:24:43 +0100, Alan Cox wrote:
>Unless anyone else is seeing the same problem with the same card variant
>or you have two cards that do it then there isn't much that can be done
>I suspect other than assume the hardware is iffy, rightly or wrongly.
>I'd have expected a lot more reports if it were the controller.
>
>(Having said that if you are reading this and your controller is a
>Promise and does the same, please say so it might be vital to deducing a
>pattern to problems)
I have a Beige G3 PowerMac upgraded with a 1GHz G4 CPU
(a 7455 on a Sonnet board) and a standard (for x86) Promise
20269 PCI controller card. The 20269+cable+disk does udma5
just fine in a PC, but throws a few BadCRCs at bootup on
the PowerMac, resets and drops to udma4, and then things work
OK for me, but I don't stress it very much (no RAID).
Since the card's bios doesn't get run at powerup, I always
suspected that the driver fails to initialize some timing thing.
Another possibility is the "data coherency" issue in some
G4 CPUs which requires mappings of memory shared with other
agents to use some additional magic in the page table.
This issue caused file system corruption when I used
my G4 + 20269 combo under load with 2.4 kernels, until
I found and backported a fix from 2.6 to 2.4.28. It's
supposed to be handled transparently by arch/{ppc,powerpc},
but it's possible the driver is mapping things incorrectly.
(This is just speculation.)
I can provide bootup logs and lspci dumps if you want.
/Mikael
^ permalink raw reply
* [U-Boot-Users] Re: [Skyeye-developer] U-Boot on simulated at91rm9200/ep7312 boards (skyeye)
From: Rohit @ 2006-04-03 9:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <586f5d00603312034q106c2abdve49907890a66ee43@mail.gmail.com>
On 4/1/06, Rohit <rohits79@gmail.com> wrote:
>
>
> On 3/31/06, Vijairaj <vijairaj.r@gmail.com> wrote:
> >
> >
> > Please let me know if you are successful in booting the linux kernel.
> > I have not looked in to it for a long time now, but I would love to
> > hear of any developments.
> >
>
>
Hi All,
I tried to load the kernel and got the following error. Can anyone suggest
me what could be wrong here?
thanks
rohit
[root at localhost at91rm]# skyeye
SKYEYE: If you have ELF kernel file, please use -e option to indicate your
ELF format kernel filename
SKYEYE: If you only have kernel binary image, you should put the filename of
kernel binary image in skyeye.conf file
arch: arm
cpu info: armv4, arm920t, 41009200, ff00fff0, 2
mach info: name at91rm92, mach_init addr 0x8069c80
uart info: input device is /dev/stdin, fd is 4.
uart info: output device is /dev/stdout, fd is 5.
SKYEYE: use arm920t mmu ops
Loaded RAM ./u-boot.bin
Loaded RAM ./uImage
U-Boot 1.1.4 (Apr 3 2006 - 14:31:42)
U-Boot code: 21F00000 -> 21F16EEC BSS: -> 21F33E04
RAM Configuration:
Bank #0: 20000000 32 MB
Atmel: Flash: 0 kB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
U-Boot> bootm
## Booting image at 21000000 ...
Image Name: Linux Kernel Image
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 534804 Bytes = 522.3 kB
Load Address: 02100000
Entry Point: 02100000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
undefined instruction
pc : [<2100000c>] lr : [<21f129f8>]
sp : 21eddc10 ip : 00000001 fp : 21eddca4
r10: 21f1a1d0 r9 : 21e59fb8 r8 : 21eddfdc
r7 : 21000040 r6 : 00000000 r5 : 00000000 r4 : 00000000
r3 : 02100000 r2 : 20000100 r1 : 000000fb r0 : 0001c200
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060403/78a459ce/attachment.htm
^ permalink raw reply
* Re: Occasional APC Smart-UPS CS 500 USB UPS troubles
From: Chris Boot @ 2006-04-03 9:04 UTC (permalink / raw)
To: Greg KH; +Cc: kernel list, linux-usb-devel
In-Reply-To: <20060402185229.GA5985@kroah.com>
On 2 Apr 2006, at 19:52, Greg KH wrote:
> On Sun, Apr 02, 2006 at 03:39:42PM +0100, Chris Boot wrote:
>> Hi all,
>>
>> I have an APC Smart-UPS CS 500, and most of the time it works really
>> nicely. I was stupefied to find it worked out of the box in Ubuntu
>> Dapper and pops up a nice little icon when the power goes out, etc...
>> The trouble is, that's only most of the time.
>>
>> I'm guessing the USB controller in the device is buggy or something,
>> because occasionally, when I reboot my machine with the UPS
>> plugged in,
>> the boot hangs or produces strange errors when detecting USB devices.
>> All it takes to get the machine to boot properly is yank the USB
>> plug on
>> the UPS, plug it in again, and reboot.
>
> What exactly are these "strange errors"?
Well I haven't seen them for a long time now, but error messages that
say very little other than an error code (which, from memory, was -47
or something).
>> Has anyone seen this before?
>
> It hasn't been reported, no.
Well next time it happens I'll try to gather as much information as
possible. What sort of stuff would help diagnose the problem?
>> Not exactly kernel related I must admit, but this never seems to
>> happen
>> on *shudder* Windows, and I wouldn't expect such severe behaviour in
>> case of trouble...
>>
>> I've seen this on all sorts of kernels starting with the early 2.6
>> series up to 2.6.16.1 and 2.6.16-ck3. My latest hang was with the
>> latter
>> kernel, and modprobe got stuck with the following trace:
>>
>> modprobe D ED465280 0 819 815
>> (NOTLB)
>> f7cfade4 f7d0366c f7d03540 ed465280 000f41fd 005b8d80 00000000
>> f7794d1c
>> 00000292 f7cfa000 f7d03540 c02d0e0e 00000001 f7d03540 c0113f02
>> f7794d24
>> f7794d24 f6e31c58 f9734f40 f97e2f44 c0257dc6 c02cf89f f97e2f44
>> f7794c58
>> Call Trace:
>> [__down+202/240] __down+0xca/0xf0
>> [default_wake_function+0/12] default_wake_function+0x0/0xc
>> [__driver_attach+0/89] __driver_attach+0x0/0x59
>> [__sched_text_start+7/12] __down_failed+0x7/0xc
>> [.text.lock.dd+39/188] .text.lock.dd+0x27/0xbc
>> [bus_for_each_dev+55/89] bus_for_each_dev+0x37/0x59
>> [driver_attach+17/19] driver_attach+0x11/0x13
>> [__driver_attach+0/89] __driver_attach+0x0/0x59
>> [bus_add_driver+90/211] bus_add_driver+0x5a/0xd3
>> [pg0+959850838/1069790208] usb_register_driver+0x50/0xae [usbcore]
>> [pg0+949030918/1069790208] hid_init+0x6/0x3d [usbhid]
>> [sys_init_module+4905/5197] sys_init_module+0x1329/0x144d
>> [cp_new_stat64+237/255] cp_new_stat64+0xed/0xff
>> [vma_prio_tree_insert+23/42] vma_prio_tree_insert+0x17/0x2a
>> [vma_link+162/223] vma_link+0xa2/0xdf
>> [do_mmap_pgoff+1202/1535] do_mmap_pgoff+0x4b2/0x5ff
>> [sys_mmap2+97/144] sys_mmap2+0x61/0x90
>> [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75
>>
>> Let me know if you need more info!
>
> That's really odd. What else is happening in the sysrq-t output at
> this
> moment in time?
Well, everything else is waiting for the modprobe to finish. There's
rather a lot of processes and fortunately by then klogd is running so
I can get the logs. Shall I send over the full bootlog and sysrq-t
trace for that boot? It's long and there doesn't appear to be
anything particularly juicy other than the above trace.
Actually with the above trace modprobe eventually returned, but USB
was unusable. I tried to rmmod it and it hung again, hard this time.
Again no interesting kernel messages, but the following sysrq-t trace:
rmmod D 0F203D40 0 4902 3752 (NOTLB)
f1068e9c f17001bc f1700090 0f203d40 000f4239 15382100 00000000 f7794d1c
00000282 f1068000 f1700090 c02d0e0e 00000001 f1700090
c0113f02 f7794d24
f7cfadf8 f7794c00 f972d359 f8cfad2c f779be28 c02cf89f
f7e3a000 f1068000
Call Trace:
[__down+202/240] __down+0xca/0xf0
[default_wake_function+0/12] default_wake_function+0x0/0xc
[__sched_text_start+7/12] __down_failed+0x7/0xc
[pg0+959837300/1069790208] .text.lock.hub+0xc7/0xef [usbcore]
[pg0+959838978/1069790208] usb_remove_hcd+0x7c/0xcd [usbcore]
[pg0+959869461/1069790208] usb_hcd_pci_remove+0x15/0x68 [usbcore]
[pci_device_remove+22/40] pci_device_remove+0x16/0x28
[__device_release_driver+83/107] __device_release_driver+0x53/0x6b
[driver_detach+117/165] driver_detach+0x75/0xa5
[bus_remove_driver+87/117] bus_remove_driver+0x57/0x75
[driver_unregister+11/19] driver_unregister+0xb/0x13
[pci_unregister_driver+12/103] pci_unregister_driver+0xc/0x67
[pg0+949181306/1069790208] uhci_hcd_cleanup+0xa/0x33 [uhci_hcd]
[sys_delete_module+353/393] sys_delete_module+0x161/0x189
[.text.lock.mlock+14/126] .text.lock.mlock+0xe/0x7e
[do_munmap+392/418] do_munmap+0x188/0x1a2
[sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75
It appears none of my other mishaps were actually logged... :-(
> Also CCing the linux-usb-devel list, as the people there can help out.
>
> thanks,
>
> greg k-h
--
Chris Boot
bootc@bootc.net
http://www.bootc.net/
^ permalink raw reply
* Re: include/asm-arm/memory.h changes break zaurus sl-5500 boot
From: Russell King @ 2006-04-03 9:02 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: pavel, rpurdie, lenz, linux-kernel, akpm
In-Reply-To: <20060403175603.7a3dd64f.kamezawa.hiroyu@jp.fujitsu.com>
On Mon, Apr 03, 2006 at 05:56:03PM +0900, KAMEZAWA Hiroyuki wrote:
> On Mon, 3 Apr 2006 16:44:34 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> > On Mon, 3 Apr 2006 08:36:53 +0100
> > Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > Hmm..from include/asm-arm/arch-clps711x/memory.h
> >
> > ==
> > /*
> > * Given a kaddr, LOCAL_MAR_NR finds the owning node of the memory
> > * and returns the index corresponding to the appropriate page in the
> > * node's mem_map.
> > */
> > #define LOCAL_MAP_NR(addr) \
> > (((unsigned long)(addr) & (NODE_MAX_MEM_SIZE - 1)) >> PAGE_SHIFT)
> > ==
> >
> > Is this comment wrong ???
The comment isn't entirely accurate.
> All of sub-arch's comment says "Given a kaddr" but all of them just uses
> "offset". So, paddr can be given as arg.
Yes.
> __va()(or pfn_to_kaddr()) adds unnecessary calcs, so paddr should be used
> instead of kaddr.
The problem with __va() and pfn_to_kaddr() is that it adds unnecessary
calculation which the compiler can not optimise away.
>From the use of LOCAL_MAP_NR(), we know that it's returning an offset
into a particular node, and that there's a 1:1 relationship between
the virtual and physical addresses within nodes. That means that
LOCAL_MAP_NR() can take either a virtual address, a physical address,
or even a byte offset into the node.
In turn, that means that we can pass it whatever address we happen to
have available at the time, or whichever is simpler to calculate.
In the cases you're looking at (pfn to map number) giving it pfn <<
PAGE_SHIFT is entirely sufficient, and is in fact optimal for
performance.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: Linux research projects
From: Sumit Narayan @ 2006-04-03 9:01 UTC (permalink / raw)
To: Tushar; +Cc: linux-kernel
In-Reply-To: <323d1f6f0604022038g4db29fb6vc489a163e53374f3@mail.gmail.com>
Check under "Projects" in http://www.kernelnewbies.org/
-- Sumit
On 4/3/06, Tushar <tushar.telichari@gmail.com> wrote:
> Hi guys,
>
> Can someone please point me to a list of todo things for Linux 2.6 ?.
>
> - Tushar
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* slow susped to disk
From: Zaher Salman @ 2006-04-03 9:00 UTC (permalink / raw)
To: linux-acpi
Hi,
I upgraded the kernel from 2.6.15 to 2.6.16 on my presario 2100. Both
kernels were compiled with the similar configuration files. Anyway I
found that suspend to disk (and resume) is much slower on 2.6.16
compared to 2.6.15. Any idea for why that might happen or how can I
speed it up? There is also a big difference when suspending with the
laptop plugged or not..
thanks
Zaher
--
Zaher Salman
TRIUMF
4004 Wesbrook Mall
Vancouver, B.C.
Canada V6T 2A3
Email: zaher@triumf.ca
Tel.: + 1 604 222 1047 ext. 6588
Fax: + 1 604 222 1074
^ permalink raw reply
* [ALSA - driver 0001424]: crash on snd-powermac initilize
From: bugtrack @ 2006-04-03 8:56 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1424>
======================================================================
Reported By: amir
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1424
Category: PPC - powermac
Reproducibility: always
Severity: crash
Priority: normal
Status: assigned
Distribution: GeeXboX
Kernel Version: 2.6.13.1
======================================================================
Date Submitted: 09-15-2005 20:38 CEST
Last Modified: 04-03-2006 10:56 CEST
======================================================================
Summary: crash on snd-powermac initilize
Description:
I have users reporting a reproducable, on init, crash of our powerpc
distro,
but this happens to only some of the ppc users.
the distro is geexbox, www.geexbox.org
this crash happens also when snd-powermac is compiled as module,
and crashes when module is loaded.
I can't reproduce the bug myself, but I have users who do the tests,
and those users report that debian and ubuntu works great for them.
this bug also happened with linux 2.6.12
======================================================================
----------------------------------------------------------------------
bugmenot - 04-03-06 10:47
----------------------------------------------------------------------
Why the dependence on i2c-powermac is not explicit?
$ modinfo /lib/modules/2.6.16-gentoo-r1/kernel/sound/ppc/snd-powermac.ko
filename:
/lib/modules/2.6.16-gentoo-r1/kernel/sound/ppc/snd-powermac.ko
license: GPL
description: PowerMac
depends: snd-pcm,snd
^^^^^^^
----------------------------------------------------------------------
Johannes Berg - 04-03-06 10:56
----------------------------------------------------------------------
Because it calls it implicitly via the i2c layer so the dependency cannot
be determined at link time.
The problem is just that snd-powermac detects a chip even if the i2c stuff
isn't there -- it shouldn't, it should do a proper i2c driver instead.
Note that there's some effort I am currently doing on writing a new sound
driver called snd-aoa (google) that does this correctly and will likely
deprecate snd-powermac in the future so I recommend not investing too much
time and brainpower into fixing it.
Issue History
Date Modified Username Field Change
======================================================================
09-15-05 20:38 amir New Issue
09-15-05 20:38 amir File Added: .config
09-15-05 20:38 amir Distribution => GeeXboX
09-15-05 20:38 amir Kernel Version => 2.6.13.1
03-01-06 07:20 netstar Note Added: 0008272
04-03-06 01:31 bugmenot Note Added: 0009075
04-03-06 01:32 bugmenot File Added: linux-2.6.16-gentoo-r1.config
04-03-06 08:54 Johannes Berg Note Added: 0009089
04-03-06 10:47 bugmenot Note Added: 0009092
04-03-06 10:56 Johannes Berg Note Added: 0009093
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [PATCH] aic79xx small cleanup
From: Emmanuel Fusté @ 2006-04-03 8:55 UTC (permalink / raw)
To: hare; +Cc: James.Bottomley, linux-scsi
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
[PATCH] aic79xx small cleanup
After Hannes Reinecke update to the aic79xx bus reset handling,
we could now remove ahd_freeze/release_simq like in the aic7xxx
driver.
Signed-off-by: Emmanuel Fusté <emmanuel.fuste@laposte.net>
---
Accédez au courrier électronique de La Poste : www.laposte.net ;
3615 LAPOSTENET (0,34 €/mn) ; tél : 08 92 68 13 50 (0,34€/mn)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: NEW-aic79xx-cleanup.patch --]
[-- Type: text/x-patch; name="NEW-aic79xx-cleanup.patch", Size: 1788 bytes --]
[PATCH] aic79xx small cleanup
After Hannes Reinecke update to the aic79xx bus reset handling,
we could now remove ahd_freeze/release_simq like in the aic7xxx
driver.
Signed-off-by: Emmanuel Fuste <emmanuel.fuste@laposte.net>
--- linux-source-2.6.16-orig1/drivers/scsi/aic7xxx/aic79xx_osm.c 2006-04-03 10:24:00.000000000 +0200
+++ linux-source-2.6.16/drivers/scsi/aic7xxx/aic79xx_osm.c 2006-04-03 10:43:34.000000000 +0200
@@ -1225,9 +1225,9 @@ ahd_linux_initialize_scsi_bus(struct ahd
ahd_unlock(ahd, &s);
/* Give the bus some time to recover */
if ((ahd->flags & AHD_RESET_BUS_A) != 0) {
- ahd_freeze_simq(ahd);
+ scsi_block_requests(ahd->platform_data->host);
msleep(AIC79XX_RESET_DELAY);
- ahd_release_simq(ahd);
+ scsi_unblock_requests(ahd->platform_data->host);
}
}
@@ -2081,18 +2081,6 @@ ahd_linux_queue_cmd_complete(struct ahd_
cmd->scsi_done(cmd);
}
-void
-ahd_freeze_simq(struct ahd_softc *ahd)
-{
- scsi_block_requests(ahd->platform_data->host);
-}
-
-void
-ahd_release_simq(struct ahd_softc *ahd)
-{
- scsi_unblock_requests(ahd->platform_data->host);
-}
-
static int
ahd_linux_queue_abort_cmd(struct scsi_cmnd *cmd)
{
--- linux-source-2.6.16-orig1/drivers/scsi/aic7xxx/aic79xx_osm.h 2006-04-03 10:24:00.000000000 +0200
+++ linux-source-2.6.16/drivers/scsi/aic7xxx/aic79xx_osm.h 2006-04-03 10:41:45.000000000 +0200
@@ -853,8 +853,6 @@ int ahd_platform_alloc(struct ahd_softc
void ahd_platform_free(struct ahd_softc *ahd);
void ahd_platform_init(struct ahd_softc *ahd);
void ahd_platform_freeze_devq(struct ahd_softc *ahd, struct scb *scb);
-void ahd_freeze_simq(struct ahd_softc *ahd);
-void ahd_release_simq(struct ahd_softc *ahd);
static __inline void
ahd_freeze_scb(struct scb *scb)
^ permalink raw reply
* Re: include/asm-arm/memory.h changes break zaurus sl-5500 boot
From: KAMEZAWA Hiroyuki @ 2006-04-03 8:56 UTC (permalink / raw)
To: rmk+lkml; +Cc: pavel, rpurdie, lenz, linux-kernel, akpm
In-Reply-To: <20060403164434.fdb5020c.kamezawa.hiroyu@jp.fujitsu.com>
On Mon, 3 Apr 2006 16:44:34 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Mon, 3 Apr 2006 08:36:53 +0100
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> Hmm..from include/asm-arm/arch-clps711x/memory.h
>
> ==
> /*
> * Given a kaddr, LOCAL_MAR_NR finds the owning node of the memory
> * and returns the index corresponding to the appropriate page in the
> * node's mem_map.
> */
> #define LOCAL_MAP_NR(addr) \
> (((unsigned long)(addr) & (NODE_MAX_MEM_SIZE - 1)) >> PAGE_SHIFT)
> ==
>
> Is this comment wrong ???
>
Russell-san
All of sub-arch's comment says "Given a kaddr" but all of them just uses "offset".
So, paddr can be given as arg.
__va()(or pfn_to_kaddr()) adds unnecessary calcs, so paddr should be used instead of kaddr.
Right ?
-Kame
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.