* [PATCH 02/59] arch/mips: Add missing "space"
From: Joe Perches @ 2007-11-20 1:47 UTC (permalink / raw)
To: linux-kernel; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <ee1678e1bc8b80b7ae420059fffc7241486ea91a.1195454434.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/mips/kernel/vpe.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/kernel/vpe.c b/arch/mips/kernel/vpe.c
index 38bd33f..c06eb81 100644
--- a/arch/mips/kernel/vpe.c
+++ b/arch/mips/kernel/vpe.c
@@ -470,7 +470,7 @@ static int apply_r_mips_lo16(struct module *me, uint32_t *location,
*/
if (v != l->value) {
printk(KERN_DEBUG "VPE loader: "
- "apply_r_mips_lo16/hi16: "
+ "apply_r_mips_lo16/hi16: \t"
"inconsistent value information\n");
return -ENOEXEC;
}
@@ -629,7 +629,7 @@ static void simplify_symbols(Elf_Shdr * sechdrs,
break;
case SHN_MIPS_SCOMMON:
- printk(KERN_DEBUG "simplify_symbols: ignoring SHN_MIPS_SCOMMON"
+ printk(KERN_DEBUG "simplify_symbols: ignoring SHN_MIPS_SCOMMON "
"symbol <%s> st_shndx %d\n", strtab + sym[i].st_name,
sym[i].st_shndx);
// .sbss section
--
1.5.3.5.652.gf192c
^ permalink raw reply related
* how to use memory before kernel load address?
From: zhuzhenhua @ 2007-11-20 1:06 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
hello,all
i want to place my kernel loadaddr=0x81008000 and set
EBASE=0x81000000, it workes.
but there is still some memory usable before 0x81000000, for
example from 0x80100000 ~ 0x80200000
i have try to pass param as mem=1M@1M mem=16M@16M to the kernel,
it seems only take the 0x8000000 ~ kernel_end as reserved.
is there any other options to set the memory useable? ( my kernel
version is 2.6.14)
thanks for any hints
zzh
[-- Attachment #2: Type: text/html, Size: 726 bytes --]
^ permalink raw reply
* RE: "exportfs -a" -> stale NFS filehandle
From: Kaz Kylheku @ 2007-11-19 22:26 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C54DC8F6@exchange.ZeugmaSystems.local>
Last week, I wrote:
> Ralf Baechle wrote:
>> On Thu, Nov 15, 2007 at 11:26:06AM -0800, Kaz Kylheku wrote:
>>
>>> After backing out the nfsutils patch, the diskless node does boot.
>>>
>>> However, the original "exportfs -a" problem comes back!
>>>
>>> So this problem is not resolved simply by using the correct compat
>>> routine; it's deeper.
>>>
>>> Sigh.
>>
>> Thanks for testing anyway!
>
> I'm continuing to dig into the problem.
>
> The export logic doesn't even go through nfsctl() anyway,
> which is why I
> originally hadn't even suspected that syscall.
>
> The nfsexport() function in nfsutils first tries opening
> "/proc/net/rpc/nfsd.fh./channel". If that works, it uses that, via a
> text-based protocol. Only if that interface doesn't exist does it fall
> back on the nfsctl(NFSCTL_EXPORT, ...) interface.
Basically, the export table is being mismanaged. Simply restarting NFS
(service nfs restart) will cause this problem to appear.
When the system is first booted up and NFS is started in runlevel 3 by
the nfs init script, the exportfs command correctly populates the export
table based on the /etc/exports file.
However, after that, further management of the export table fails. Doing
an "exportfs -a" clears it out. You can see the table in
/proc/net/rpc/nfsd.export/content. Before the operation, the table has
valid entries. After the operation, it simply clears out and stays
empty.
This is in spite of the fact that the exportfs command seems to be doing
exactly what it did the first time when NFS was successfully started
(i.e. it's a kernel problem; user space is doing the same thing that
worked before).
I verified that by turning on various additional tracing with sysctl
(sunrpc.nfsd_debug), and I added some extra traces to the function that
adds exports (svc_export_parse) to view the messages that are coming
down the nfsd.fh/channel pipe in /proc.
So the summary is that this problem appears to be some kind of
corruption of the RPC cache for exports.
I did see the kernel crash with an alignment exception once upon
reproducing the problem, but haven't been able to repro that.
^ permalink raw reply
* RE: "exportfs -a" -> stale NFS filehandle
From: Kaz Kylheku @ 2007-11-19 22:26 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C54DC8F6@exchange.ZeugmaSystems.local>
Last week, I wrote:
> Ralf Baechle wrote:
>> On Thu, Nov 15, 2007 at 11:26:06AM -0800, Kaz Kylheku wrote:
>>
>>> After backing out the nfsutils patch, the diskless node does boot.
>>>
>>> However, the original "exportfs -a" problem comes back!
>>>
>>> So this problem is not resolved simply by using the correct compat
>>> routine; it's deeper.
>>>
>>> Sigh.
>>
>> Thanks for testing anyway!
>
> I'm continuing to dig into the problem.
>
> The export logic doesn't even go through nfsctl() anyway,
> which is why I
> originally hadn't even suspected that syscall.
>
> The nfsexport() function in nfsutils first tries opening
> "/proc/net/rpc/nfsd.fh./channel". If that works, it uses that, via a
> text-based protocol. Only if that interface doesn't exist does it fall
> back on the nfsctl(NFSCTL_EXPORT, ...) interface.
Basically, the export table is being mismanaged. Simply restarting NFS
(service nfs restart) will cause this problem to appear.
When the system is first booted up and NFS is started in runlevel 3 by
the nfs init script, the exportfs command correctly populates the export
table based on the /etc/exports file.
However, after that, further management of the export table fails. Doing
an "exportfs -a" clears it out. You can see the table in
/proc/net/rpc/nfsd.export/content. Before the operation, the table has
valid entries. After the operation, it simply clears out and stays
empty.
This is in spite of the fact that the exportfs command seems to be doing
exactly what it did the first time when NFS was successfully started
(i.e. it's a kernel problem; user space is doing the same thing that
worked before).
I verified that by turning on various additional tracing with sysctl
(sunrpc.nfsd_debug), and I added some extra traces to the function that
adds exports (svc_export_parse) to view the messages that are coming
down the nfsd.fh/channel pipe in /proc.
So the summary is that this problem appears to be some kind of
corruption of the RPC cache for exports.
I did see the kernel crash with an alignment exception once upon
reproducing the problem, but haven't been able to repro that.
^ permalink raw reply
* RE: futex_wake_op deadlock?
From: Kaz Kylheku @ 2007-11-19 21:42 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C54DCDE2@exchange.ZeugmaSystems.local>
Earlier, I wrote:
> I have hacked up little a test program which hosed my board within
> seconds. The system is not completely hung. However:
>
> - I can't kill the test program with Ctrl-C.
> - I can log into the box with telnet.
> - If I run "ps aux" to see all processes, the ps command hangs partway
> through the table, and cannot be killed with Ctrl-C.
> - System hangs on soft reboot attempt; requires hard reset.
Furthermore: my console loglevel was too high to see the crash on the
serial console, but, surely enough, the syslog has this:
Nov 19 14:19:57 [kernel] [14:19:57.846017] BUG: soft lockup detected on
CPU#1!
Nov 19 14:19:57 [kernel] [14:19:57.846051] Call Trace:
Nov 19 14:19:58 [kernel] [14:19:57.846069] [<ffffffff8016de8c>]
softlockup_tick+0x1bc/0x208
Nov 19 14:19:58 [kernel] [14:19:57.846112] [<ffffffff8014cc54>]
update_process_times+0x9c/0xe8
Nov 19 14:19:58 [kernel] [14:19:57.846147] [<ffffffff801098bc>]
ll_local_timer_interrupt+0x94/0xa8
Nov 19 14:19:58 [kernel] [14:19:57.846180] [<ffffffff801098bc>]
ll_local_timer_interrupt+0x94/0xa8
Nov 19 14:19:58 [kernel] [14:19:57.846205] [<ffffffff801026a0>]
plat_irq_dispatch+0x120/0x1a0
Nov 19 14:19:58 [kernel] [14:19:57.846232] [<ffffffff80163f28>]
compat_sys_futex+0x0/0x188
Nov 19 14:19:58 [kernel] [14:19:57.846258] [<ffffffff801637e0>]
do_futex+0x8f8/0xb58
Nov 19 14:19:58 [kernel] [14:19:57.846281] [<ffffffff8011db28>]
tlb_do_page_fault_1+0x110/0x128
Nov 19 14:19:58 [kernel] [14:19:57.846317] [<ffffffff80163758>]
do_futex+0x870/0xb58
Nov 19 14:19:58 [kernel] [14:19:57.846339] [<ffffffff80163f28>]
compat_sys_futex+0x0/0x188
Nov 19 14:19:58 [kernel] [14:19:57.846364] [<ffffffff80163170>]
do_futex+0x288/0xb58
Nov 19 14:19:58 [kernel] [14:19:57.846385] [<ffffffff801637e0>]
do_futex+0x8f8/0xb58
Nov 19 14:19:58 [kernel] [14:19:57.846407] [<ffffffff80163764>]
do_futex+0x87c/0xb58
Nov 19 14:19:58 [kernel] [14:19:57.846430] [<ffffffff80177500>]
__alloc_pages+0x70/0x398
Nov 19 14:19:58 [kernel] [14:19:57.846456] [<ffffffff80130d1c>]
try_to_wake_up+0x3c4/0x4f8
Nov 19 14:19:58 [kernel] [14:19:57.846489] [<ffffffff802f3c28>]
__up_read+0xe8/0x130
Nov 19 14:19:58 [kernel] [14:19:57.846528] [<ffffffff80163fac>]
compat_sys_futex+0x84/0x188
Nov 19 14:19:58 [kernel] [14:19:57.846552] [<ffffffff80116314>]
handle_sysn32+0x54/0xb0
Nov 19 14:19:58 [kernel] [14:19:57.846578] [<ffffffff80163f28>]
compat_sys_futex+0x0/0x188
^ permalink raw reply
* RE: futex_wake_op deadlock?
From: Kaz Kylheku @ 2007-11-19 21:42 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C54DCDE2@exchange.ZeugmaSystems.local>
Earlier, I wrote:
> I have hacked up little a test program which hosed my board within
> seconds. The system is not completely hung. However:
>
> - I can't kill the test program with Ctrl-C.
> - I can log into the box with telnet.
> - If I run "ps aux" to see all processes, the ps command hangs partway
> through the table, and cannot be killed with Ctrl-C.
> - System hangs on soft reboot attempt; requires hard reset.
Furthermore: my console loglevel was too high to see the crash on the
serial console, but, surely enough, the syslog has this:
Nov 19 14:19:57 [kernel] [14:19:57.846017] BUG: soft lockup detected on
CPU#1!
Nov 19 14:19:57 [kernel] [14:19:57.846051] Call Trace:
Nov 19 14:19:58 [kernel] [14:19:57.846069] [<ffffffff8016de8c>]
softlockup_tick+0x1bc/0x208
Nov 19 14:19:58 [kernel] [14:19:57.846112] [<ffffffff8014cc54>]
update_process_times+0x9c/0xe8
Nov 19 14:19:58 [kernel] [14:19:57.846147] [<ffffffff801098bc>]
ll_local_timer_interrupt+0x94/0xa8
Nov 19 14:19:58 [kernel] [14:19:57.846180] [<ffffffff801098bc>]
ll_local_timer_interrupt+0x94/0xa8
Nov 19 14:19:58 [kernel] [14:19:57.846205] [<ffffffff801026a0>]
plat_irq_dispatch+0x120/0x1a0
Nov 19 14:19:58 [kernel] [14:19:57.846232] [<ffffffff80163f28>]
compat_sys_futex+0x0/0x188
Nov 19 14:19:58 [kernel] [14:19:57.846258] [<ffffffff801637e0>]
do_futex+0x8f8/0xb58
Nov 19 14:19:58 [kernel] [14:19:57.846281] [<ffffffff8011db28>]
tlb_do_page_fault_1+0x110/0x128
Nov 19 14:19:58 [kernel] [14:19:57.846317] [<ffffffff80163758>]
do_futex+0x870/0xb58
Nov 19 14:19:58 [kernel] [14:19:57.846339] [<ffffffff80163f28>]
compat_sys_futex+0x0/0x188
Nov 19 14:19:58 [kernel] [14:19:57.846364] [<ffffffff80163170>]
do_futex+0x288/0xb58
Nov 19 14:19:58 [kernel] [14:19:57.846385] [<ffffffff801637e0>]
do_futex+0x8f8/0xb58
Nov 19 14:19:58 [kernel] [14:19:57.846407] [<ffffffff80163764>]
do_futex+0x87c/0xb58
Nov 19 14:19:58 [kernel] [14:19:57.846430] [<ffffffff80177500>]
__alloc_pages+0x70/0x398
Nov 19 14:19:58 [kernel] [14:19:57.846456] [<ffffffff80130d1c>]
try_to_wake_up+0x3c4/0x4f8
Nov 19 14:19:58 [kernel] [14:19:57.846489] [<ffffffff802f3c28>]
__up_read+0xe8/0x130
Nov 19 14:19:58 [kernel] [14:19:57.846528] [<ffffffff80163fac>]
compat_sys_futex+0x84/0x188
Nov 19 14:19:58 [kernel] [14:19:57.846552] [<ffffffff80116314>]
handle_sysn32+0x54/0xb0
Nov 19 14:19:58 [kernel] [14:19:57.846578] [<ffffffff80163f28>]
compat_sys_futex+0x0/0x188
^ permalink raw reply
* RE: futex_wake_op deadlock?
From: Kaz Kylheku @ 2007-11-19 21:27 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071119184837.GA12287@linux-mips.org>
Ralf Baechle wrote:
> On Fri, Nov 16, 2007 at 03:52:47PM -0800, Kaz Kylheku wrote:
>
>> From time to time, on 2.6.17.7, I see a deadlock situation go off.
>> The soft lockup tick occurs in the middle of do_futex, which is
>> heavily inlined. The system is actually hosed; it's not one of those
>> recoverable CPU busy situations that can sometimes trigger the lockup
>> detector.
>
> Can you reproduce thing hang also if you're not running in a
> binary compat
> mode, that is either running o32 binaries on a 32-bit kernel or
> 64-bit binaries on a 64-bit kernel?
I have hacked up little a test program which hosed my board within
seconds.
The system is not completely hung. However:
- I can't kill the test program with Ctrl-C.
- I can log into the box with telnet.
- If I run "ps aux" to see all processes, the ps command hangs partway
through the table, and cannot be killed with Ctrl-C.
- System hangs on soft reboot attempt; requires hard reset.
The program basically uses several threads to beat up the FUTEX_WAKE_OP.
The key trick is that there is an interfering thread which does a
mmap/munmap on the futexes in parallel with the threads which are using
them. .
If I just stick the futexes into a permanently good memory location,
nothing bad happens; the program just churns away taking up 400% of the
CPU time across the four cores of the 1480. If you call the function
with permanently bad addresses, nothing bad happens either; the syscalls
bail nicely with EFAULT.
The idea is to tickle some race condition or other bug in the
interaction between futexes and mmap. I put a little delay into the
interfering thread so that the memory is held in a good state most of
the time, with a quick unmap/remap. We want the memory to be good most
of the time, but an unmap to happen from time to time at an inopportune
time, while the kernel is executing the futex code on one or more cores
This needs to be compiled -pthread, obviously, and you need -lrt to link
in the library for clock_nanosleep.
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>
#include <sys/syscall.h>
#include <sys/mman.h>
#define FUTEX_WAIT 0
#define FUTEX_WAKE 1
#define FUTEX_FD 2
#define FUTEX_REQUEUE 3
#define FUTEX_CMP_REQUEUE 4
#define FUTEX_WAKE_OP 5
#define FUTEX_OP_SET 0 /* *(int *)UADDR2 = OPARG; */
#define FUTEX_OP_ADD 1 /* *(int *)UADDR2 += OPARG; */
#define FUTEX_OP_OR 2 /* *(int *)UADDR2 |= OPARG; */
#define FUTEX_OP_ANDN 3 /* *(int *)UADDR2 &= ~OPARG; */
#define FUTEX_OP_XOR 4 /* *(int *)UADDR2 ^= OPARG; */
#define FUTEX_OP_OPARG_SHIFT 8 /* Use (1 << OPARG) instead of
OPARG. */
#define FUTEX_OP_CMP_EQ 0 /* if (oldval == CMPARG) wake */
#define FUTEX_OP_CMP_NE 1 /* if (oldval != CMPARG) wake */
#define FUTEX_OP_CMP_LT 2 /* if (oldval < CMPARG) wake */
#define FUTEX_OP_CMP_LE 3 /* if (oldval <= CMPARG) wake */
#define FUTEX_OP_CMP_GT 4 /* if (oldval > CMPARG) wake */
#define FUTEX_OP_CMP_GE 5 /* if (oldval >= CMPARG) wake */
#define NUM_THREADS 8
int futex_wake_op(int *addr1, int *addr2,
int nr_wake_1, int nr_wake_2, int encoded_op)
{
syscall(SYS_futex, addr1, FUTEX_WAKE_OP, nr_wake_1,
nr_wake_2, addr2, encoded_op);
}
int futex1 = 0, futex2 = 0;
struct {
int futex1;
int futex2;
} *shared;
void *mapper(void *arg)
{
for (;;) {
struct timespec delay;
void *mem;
delay.tv_sec = 0;
delay.tv_nsec = 100000000;
mem = mmap(0, 16384, PROT_READ | PROT_WRITE, MAP_PRIVATE |
MAP_ANONYMOUS, -1, 0);
if (mem == (void *) -1) {
perror("mmap");
exit(EXIT_FAILURE);
}
shared = mem;
clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &delay, 0);
if (munmap(mem, 16384) < 0) {
perror("munmap");
exit(EXIT_FAILURE);
}
}
}
void *waker(void *arg)
{
int rand_state = 1;
for (;;) {
int val = rand_r(&rand_state) & 0xFFFF;
const int op = (FUTEX_OP_SET << 28) | (FUTEX_OP_CMP_GT << 24) |
val;
int result = futex_wake_op(&shared->futex1, &shared->futex2, 1,
1, op);
if (result < 0 && errno != EFAULT) {
perror("futex_wake_op");
exit(EXIT_FAILURE);
}
}
/* notreached */
return 0;
}
int main(void)
{
int i;
srand(1);
for (i = 0; i < NUM_THREADS; i++) {
pthread_t thr;
void *(*func)(void *) = (i == 0) ? mapper : waker;
int result = errno = pthread_create(&thr, 0, func, 0);
if (result != 0) {
perror("pthread_create");
return EXIT_FAILURE;
}
}
pthread_exit(0);
}
^ permalink raw reply
* RE: futex_wake_op deadlock?
From: Kaz Kylheku @ 2007-11-19 21:27 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071119184837.GA12287@linux-mips.org>
Ralf Baechle wrote:
> On Fri, Nov 16, 2007 at 03:52:47PM -0800, Kaz Kylheku wrote:
>
>> From time to time, on 2.6.17.7, I see a deadlock situation go off.
>> The soft lockup tick occurs in the middle of do_futex, which is
>> heavily inlined. The system is actually hosed; it's not one of those
>> recoverable CPU busy situations that can sometimes trigger the lockup
>> detector.
>
> Can you reproduce thing hang also if you're not running in a
> binary compat
> mode, that is either running o32 binaries on a 32-bit kernel or
> 64-bit binaries on a 64-bit kernel?
I have hacked up little a test program which hosed my board within
seconds.
The system is not completely hung. However:
- I can't kill the test program with Ctrl-C.
- I can log into the box with telnet.
- If I run "ps aux" to see all processes, the ps command hangs partway
through the table, and cannot be killed with Ctrl-C.
- System hangs on soft reboot attempt; requires hard reset.
The program basically uses several threads to beat up the FUTEX_WAKE_OP.
The key trick is that there is an interfering thread which does a
mmap/munmap on the futexes in parallel with the threads which are using
them. .
If I just stick the futexes into a permanently good memory location,
nothing bad happens; the program just churns away taking up 400% of the
CPU time across the four cores of the 1480. If you call the function
with permanently bad addresses, nothing bad happens either; the syscalls
bail nicely with EFAULT.
The idea is to tickle some race condition or other bug in the
interaction between futexes and mmap. I put a little delay into the
interfering thread so that the memory is held in a good state most of
the time, with a quick unmap/remap. We want the memory to be good most
of the time, but an unmap to happen from time to time at an inopportune
time, while the kernel is executing the futex code on one or more cores
This needs to be compiled -pthread, obviously, and you need -lrt to link
in the library for clock_nanosleep.
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>
#include <sys/syscall.h>
#include <sys/mman.h>
#define FUTEX_WAIT 0
#define FUTEX_WAKE 1
#define FUTEX_FD 2
#define FUTEX_REQUEUE 3
#define FUTEX_CMP_REQUEUE 4
#define FUTEX_WAKE_OP 5
#define FUTEX_OP_SET 0 /* *(int *)UADDR2 = OPARG; */
#define FUTEX_OP_ADD 1 /* *(int *)UADDR2 += OPARG; */
#define FUTEX_OP_OR 2 /* *(int *)UADDR2 |= OPARG; */
#define FUTEX_OP_ANDN 3 /* *(int *)UADDR2 &= ~OPARG; */
#define FUTEX_OP_XOR 4 /* *(int *)UADDR2 ^= OPARG; */
#define FUTEX_OP_OPARG_SHIFT 8 /* Use (1 << OPARG) instead of
OPARG. */
#define FUTEX_OP_CMP_EQ 0 /* if (oldval == CMPARG) wake */
#define FUTEX_OP_CMP_NE 1 /* if (oldval != CMPARG) wake */
#define FUTEX_OP_CMP_LT 2 /* if (oldval < CMPARG) wake */
#define FUTEX_OP_CMP_LE 3 /* if (oldval <= CMPARG) wake */
#define FUTEX_OP_CMP_GT 4 /* if (oldval > CMPARG) wake */
#define FUTEX_OP_CMP_GE 5 /* if (oldval >= CMPARG) wake */
#define NUM_THREADS 8
int futex_wake_op(int *addr1, int *addr2,
int nr_wake_1, int nr_wake_2, int encoded_op)
{
syscall(SYS_futex, addr1, FUTEX_WAKE_OP, nr_wake_1,
nr_wake_2, addr2, encoded_op);
}
int futex1 = 0, futex2 = 0;
struct {
int futex1;
int futex2;
} *shared;
void *mapper(void *arg)
{
for (;;) {
struct timespec delay;
void *mem;
delay.tv_sec = 0;
delay.tv_nsec = 100000000;
mem = mmap(0, 16384, PROT_READ | PROT_WRITE, MAP_PRIVATE |
MAP_ANONYMOUS, -1, 0);
if (mem == (void *) -1) {
perror("mmap");
exit(EXIT_FAILURE);
}
shared = mem;
clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &delay, 0);
if (munmap(mem, 16384) < 0) {
perror("munmap");
exit(EXIT_FAILURE);
}
}
}
void *waker(void *arg)
{
int rand_state = 1;
for (;;) {
int val = rand_r(&rand_state) & 0xFFFF;
const int op = (FUTEX_OP_SET << 28) | (FUTEX_OP_CMP_GT << 24) |
val;
int result = futex_wake_op(&shared->futex1, &shared->futex2, 1,
1, op);
if (result < 0 && errno != EFAULT) {
perror("futex_wake_op");
exit(EXIT_FAILURE);
}
}
/* notreached */
return 0;
}
int main(void)
{
int i;
srand(1);
for (i = 0; i < NUM_THREADS; i++) {
pthread_t thr;
void *(*func)(void *) = (i == 0) ? mapper : waker;
int result = errno = pthread_create(&thr, 0, func, 0);
if (result != 0) {
perror("pthread_create");
return EXIT_FAILURE;
}
}
pthread_exit(0);
}
^ permalink raw reply
* Re: IP22 64Bit arcboot - current git crashes on 3 machines at different points
From: Ralf Baechle @ 2007-11-19 19:31 UTC (permalink / raw)
To: Florian Lohoff; +Cc: linux-mips
In-Reply-To: <20071119160954.GA12244@paradigm.rfc822.org>
On Mon, Nov 19, 2007 at 05:09:54PM +0100, Florian Lohoff wrote:
> i am seeing strange issues with 64 Bit kernels IP22 on different
> machines. This came up when i tried the debian distribution kernel
> which fails for me on 2 machines.
I still haven't sorted out all the workarounds for the read-from-compare
bug in early R4000 / R4400 with the new time code. It may not be the
issue that's hitting you but the new time code definately has the potencial
to trigger the issue.
Ralf
^ permalink raw reply
* Confirmation Request (1498870506)
From: linux administration @ 2007-11-19 19:16 UTC (permalink / raw)
To: linux-mips
This is an automated message from the
<linux@complife.ru> mailing list manager
Somebody (probably you) have requested the subscribe(feed) operation
for your <linux-mips@linux-mips.org> address
If you want to confirm this operation,
use the Reply command in your mailer.
Check that the Subject of the reply message contains
the confirmation ID: 1498870506,
the reply is directed to <linux-feed@complife.ru>,
and the 'From' address of your reply is <linux-mips@linux-mips.org>.
If you do not want to confirm the requested operation, simply do nothing
All requests about this mailing list
should be sent to <linux-request@complife.ru>
^ permalink raw reply
* Re: futex_wake_op deadlock?
From: Ralf Baechle @ 2007-11-19 18:48 UTC (permalink / raw)
To: Kaz Kylheku; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C54DCBD2@exchange.ZeugmaSystems.local>
On Fri, Nov 16, 2007 at 03:52:47PM -0800, Kaz Kylheku wrote:
> From time to time, on 2.6.17.7, I see a deadlock situation go off. The
> soft lockup tick occurs in the middle of do_futex, which is heavily
> inlined. The system is actually hosed; it's not one of those
> recoverable CPU busy situations that can sometimes trigger the lockup
> detector.
Can you reproduce thing hang also if you're not running in a binary compat
mode, that is either running o32 binaries on a 32-bit kernel or 64-bit
binaries on a 64-bit kernel?
Ralf
^ permalink raw reply
* Re: ohci-ssb driver on a Broadcom BCM5354
From: Michael Buesch @ 2007-11-19 18:23 UTC (permalink / raw)
To: John W. Linville; +Cc: Steve Brown, linux-mips
In-Reply-To: <20071118224752.GB12263@tuxdriver.com>
On Sunday 18 November 2007 23:47:52 John W. Linville wrote:
> You probably want to make Michael Buesch aware of this issue.
I'm not sure anyone really tested this beyond some insmod tests.
I did not test this, as I don't have such a device.
So if you have any patches to fix this, please send them. I'm
certainly the wrong person who can fix this. ;)
--
Greetings Michael.
^ permalink raw reply
* IP22 64Bit arcboot - current git crashes on 3 machines at different points
From: Florian Lohoff @ 2007-11-19 16:09 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 17877 bytes --]
Subject: Re: Bug#451805: linux-image-2.6.22-3-r4k-ip22 dies early on boot / Starting ELF64 kernel
Hi,
i am seeing strange issues with 64 Bit kernels IP22 on different
machines. This came up when i tried the debian distribution kernel
which fails for me on 2 machines.
Current git does not work on all 3
IP22 Indy R5k 150Mhz
r4k-ip22-2.6.22-6 works
current git 2.6.24-rc2 breaks in Zilog serial driver (see end)
PROM Monitor SGI Version 5.3 Rev B10 R4X00/R5000 IP24 Feb 12, 1996 (BE)
IP22 Indy R4k 100Mhz
r4k-ip22-2.6.22-6 dies after "Starting ELF64 Kernel"
current git 2.6.24-rc2 dies with a backtrace in cache_alloc_refill (see end)
PROM Monitor SGI Version 5.1.2 Rev B4 R4X00 IP24 Dec 9, 1993 (BE)
IP22 Indigo2 R4k 250Mhz
r4k-ip22-2.6.22-6 dies after "Starting ELF64 Kernel"
current git 2.6.24-rc2 dies after initializing hash tables (see end)
PROM Monitor SGI Version 5.3 Rev E IP22 Sep 28, 1995 (BE)
IP22 r5k 150Mhz Indy 2.6.24-rc2
>> boot
60928+176+320 entry: 0x88802d9c
arcsboot: ARCS Linux ext2fs loader 0.3.8.8
Loading linux2624 from scsi(0)disk(1)partition(1)
Allocated 0x70 bytes for segments
Loading 64-bit executable
Loading program segment 1 at 0x88004000, offset=0x0 4000, size = 0x0 40e085
c000 (cache: 22.2%)18000 (cache: 34.7%)24000 (cache: 46.6%)30000 (cache: 57.5%)3c000 (cache: 67.8%)48000 (cache: 74.3%)54000 (cache: 77.7%)60000 (cache: 77.6%)6c000 (cache: 77.5%)78000 (cache: 78.7%)84000 (cache: 78.9%)90000 (cache: 79.1%)9c000 (cache: 80.3%)a8000 (cache: 82.6%)b4000 (cache: 82.5%)c0000 (cache: 82.7%)cc000 (cache: 84.3%)d8000 (cache: 85.0%)e4000 (cache: 85.3%)f0000 (cache: 86.1%)fc000 (cache: 85.9%)108000 (cache: 86.8%)114000 (cache: 87.5%)120000 (cache: 88.2%)12c000 (cache: 88.7%)138000 (cache: 89.2%)144000 (cache: 89.6%)150000 (cache: 90.0%)15c000 (cache: 90.3%)168000 (cache: 90.6%)174000 (cache: 90.8%)180000 (cache: 91.1%)18c000 (cache: 91.3%)198000 (cache: 91.5%)1a4000 (cache: 91.6%)1b0000 (cache: 91.8%)1bc000 (cache: 92.0%)1c8000 (cache: 92.1%)1d4000 (cache: 92.2%)1e0000 (cache: 92.4%)1ec000 (cache: 92.5%)1f8000 (cache: 92.6%)204000 (cache: 92.7%)210000 (cache: 92.8%)21c000 (cache: 92.9%)228000 (cache: 92.9%)234000 (cache: 93.0%)240000 (cache: 93.1%)24c000 (cache: 93.2%)258000 (cache: 93.2%)264000 (cache: 93.3%)270000 (cache: 93.4%)27c000 (cache: 93.4%)288000 (cache: 93.5%)294000 (cache: 93.5%)2a0000 (cache: 93.6%)2ac000 (cache: 93.6%)2b8000 (cache: 93.7%)2c4000 (cache: 93.7%)2d0000 (cache: 93.8%)2dc000 (cache: 93.8%)2e8000 (cache: 93.8%)2f4000 (cache: 93.9%)300000 (cache: 93.9%)30c000 (cache: 93.9%)318000 (cache: 94.0%)324000 (cache: 94.0%)330000 (cache: 94.0%)33c000 (cache: 94.1%)348000 (cache: 94.1%)354000 (cache: 94.1%)360000 (cache: 94.2%)36c000 (cache: 94.2%)378000 (cache: 94.2%)384000 (cache: 94.2%)390000 (cache: 94.3%)39c000 (cache: 94.3%)3a8000 (cache: 94.3%)3b4000 (cache: 94.3%)3c0000 (cache: 94.3%)3cc000 (cache: 94.4%)3d8000 (cache: 94.4%)3e4000 (cache: 94.4%)3f0000 (cache: 94.4%)3fc000 (cache: 94.4%)408000 (cache: 94.5%)414000 (cache: 94.5%)420000 (cache: 94.5%)42c000 (cache: 94.5%)438000 (cache: 94.5%)444000 (cache: 94.5%)450000 (cache: 94.6%)45c000 (cache: 94.6%)468000 (cache: 94.6%)474000 (cache: 94.6%)480000 (cache: 94.6%)48c000 (cache: 94.6%)498000 (cache: 94.6%)Zeroing memory at 0x710210, size = 0x0
Starting ELF64 kernel
Linux version 2.6.24-rc2-gcd60878b-dirty (flo@firewall) (gcc version 4.2.2) #1 Mon Nov 19 14:33:08 CET 2007
ARCH: SGI-IP22
PROMLIB: ARC firmware Version 1 Revision 10
console [early0] enabled
CPU revision is: 00002321 (R5000)
FPU revision is: 00002310
MC: SGI memory controller Revision 3
MC: Probing memory configuration:
bank0: 32M @ 08000000
bank1: 32M @ 0a000000
Determined physical RAM map:
memory: 0000000004000000 @ 0000000008000000 (usable)
Wasting 1835008 bytes for tracking 32768 unused pages
Initrd not found or empty - disabling initrd
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 48480
Kernel command line: root=/dev/sda2
Primary instruction cache 32kB, VIPT, 2-way, linesize 32 bytes.
Primary data cache 32kB, 2-way, VIPT, cache aliases, linesize 32 bytes
Synthesized clear page handler (15 instructions).
Synthesized copy page handler (24 instructions).
Synthesized TLB refill handler (38 instructions).
Synthesized TLB load handler fastpath (51 instructions).
Synthesized TLB store handler fastpath (51 instructions).
Synthesized TLB modify handler fastpath (50 instructions).
PID hash table entries: 1024 (order: 10, 8192 bytes)
Calibrating system timer... 300000 [150.0000 MHz CPU]
Using 75.000 MHz high precision timer.
NG1: Revision 6, 8 bitplanes, REX3 revision B, VC2 revision A, xmap9 revision A, cmap revision C, bt445 revision D
NG1: Screensize 1024x768
Console: colour SGI Newport 128x48
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Memory: 57600k/65536k available (2925k kernel code, 7524k reserved, 955k data, 272k init, 0k highmem)
Security Framework initialized
SELinux: Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 256
Checking for the multiply/shift bug... no.
Checking for the daddi bug... no.
Checking for the daddiu bug... no.
net_namespace: 120 bytes
NET: Registered protocol family 16
EISA bus registered
SCSI subsystem initialized
Time: MIPS clocksource has been installed.
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 2, 16384 bytes)
TCP established hash table entries: 8192 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1195479647.784:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
DS1286 Real Time Clock Driver v1.0
Serial: IP22 Zilog driver (1 chips).
IP22 r4k 250Mhz Indigo2 2.6.24-rc2:
arcsboot: ARCS Linux ext2fs loader 0.3.8.8
Loading linux2624 from scsi(1)disk(5)rdisk(0)partition(0)
Allocated 0x70 bytes for segments
Loading 64-bit executable
Loading program segment 1 at 0x88004000, offset=0x0 4000, size = 0x0 40e085
c000 (cache: 46.1%)18000 (cache: 69.3%)24000 (cache: 78.0%)30000 (cache: 82.4%)3c000 (cache: 85.1%)48000 (cache: 86.8%)54000 (cache: 88.1%)60000 (cache: 89.1%)6c000 (cache: 89.8%)78000 (cache: 90.4%)84000 (cache: 90.9%)90000 (cache: 91.3%)9c000 (cache: 91.6%)a8000 (cache: 91.9%)b4000 (cache: 92.2%)c0000 (cache: 92.4%)cc000 (cache: 92.6%)d8000 (cache: 92.8%)e4000 (cache: 92.9%)f0000 (cache: 93.1%)fc000 (cache: 93.2%)108000 (cache: 93.3%)114000 (cache: 93.4%)120000 (cache: 93.5%)12c000 (cache: 93.6%)138000 (cache: 93.7%)144000 (cache: 93.8%)150000 (cache: 93.9%)15c000 (cache: 93.9%)168000 (cache: 94.0%)174000 (cache: 94.0%)180000 (cache: 94.1%)18c000 (cache: 94.1%)198000 (cache: 94.2%)1a4000 (cache: 94.2%)1b0000 (cache: 94.3%)1bc000 (cache: 94.3%)1c8000 (cache: 94.4%)1d4000 (cache: 94.4%)1e0000 (cache: 94.4%)1ec000 (cache: 94.5%)1f8000 (cache: 94.5%)204000 (cache: 94.5%)210000 (cache: 94.6%)21c000 (cache: 94.6%)228000 (cache: 94.6%)234000 (cache: 94.6%)240000 (cache: 94.7%)24c000 (cache: 94.7%)258000 (cache: 94.7%)264000 (cache: 94.7%)270000 (cache: 94.7%)27c000 (cache: 94.8%)288000 (cache: 94.8%)294000 (cache: 94.8%)2a0000 (cache: 94.8%)2ac000 (cache: 94.8%)2b8000 (cache: 94.9%)2c4000 (cache: 94.9%)2d0000 (cache: 94.9%)2dc000 (cache: 94.9%)2e8000 (cache: 94.9%)2f4000 (cache: 94.9%)300000 (cache: 94.9%)30c000 (cache: 95.0%)318000 (cache: 95.0%)324000 (cache: 95.0%)330000 (cache: 95.0%)33c000 (cache: 95.0%)348000 (cache: 95.0%)354000 (cache: 95.0%)360000 (cache: 95.0%)36c000 (cache: 95.0%)378000 (cache: 95.1%)384000 (cache: 95.1%)390000 (cache: 95.1%)39c000 (cache: 95.1%)3a8000 (cache: 95.1%)3b4000 (cache: 95.1%)3c0000 (cache: 95.1%)3cc000 (cache: 95.1%)3d8000 (cache: 95.1%)3e4000 (cache: 95.1%)3f0000 (cache: 95.1%)3fc000 (cache: 95.1%)408000 (cache: 95.2%)414000 (cache: 95.2%)Zeroing memory at 0x710210, size = 0x0
Starting ELF64 kernel
Linux version 2.6.24-rc2-gcd60878b-dirty (flo@firewall) (gcc version 4.2.2) #1 Mon Nov 19 14:33:08 CET 2007
ARCH: SGI-IP22
PROMLIB: ARC firmware Version 1 Revision 10
console [early0] enabled
CPU revision is: 00000460 (R4400SC)
FPU revision is: 00000500
MC: SGI memory controller Revision 3
MC: Probing memory configuration:
bank0: 64M @ 10000000
bank1: 64M @ 14000000
bank2: 128M @ 08000000
Determined physical RAM map:
memory: 0000000010000000 @ 0000000008000000 (usable)
Wasting 1835008 bytes for tracking 32768 unused pages
Initrd not found or empty - disabling initrd
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 96960
Kernel command line: root=/dev/sdf1 console=ttyS0 auto
Primary instruction cache 16kB, VIPT, direct mapped, linesize 16 bytes.
Primary data cache 16kB, direct mapped, VIPT, cache aliases, linesize 16 bytes
Unified secondary cache 2048kB direct mapped, linesize 128 bytes.
Synthesized clear page handler (22 instructions).
Synthesized copy page handler (39 instructions).
Synthesized TLB refill handler (38 instructions).
Synthesized TLB load handler fastpath (50 instructions).
Synthesized TLB store handler fastpath (50 instructions).
Synthesized TLB modify handler fastpath (49 instructions).
EISA: Probing bus...
EISA: Detected 0 card.
ISA support compiled in.
PID hash table entries: 2048 (order: 11, 16384 bytes)
Calibrating system timer... 500000 [250.0000 MHz CPU]
Using 125.000 MHz high precision timer.
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Memory: 251104k/262144k available (2925k kernel code, 10628k reserved, 955k data, 272k init, 0k highmem)
IP22 R4k 100Mhz Indy - 2.6.24-rc2:
Loading linux2624 from scsi(0)disk(1)rdisk(0)partition(0)
Allocated 0x70 bytes for segments
Loading 64-bit executable
Loading program segment 1 at 0x88004000, offset=0x0 4000, size = 0x0 40e085
c000 (cache: 44.0%)18000 (cache: 68.7%)24000 (cache: 77.7%)30000 (cache: 82.2%)3c000 (cache: 85.0%)48000 (cache: 86.8%)54000 (cache: 88.0%)60000 (cache: 89.0%)6c000 (cache: 89.8%)78000 (cache: 90.4%)84000 (cache: 90.9%)90000 (cache: 91.3%)9c000 (cache: 91.6%)a8000 (cache: 91.9%)b4000 (cache: 92.2%)c0000 (cache: 92.4%)cc000 (cache: 92.6%)d8000 (cache: 92.8%)e4000 (cache: 92.9%)f0000 (cache: 93.1%)fc000 (cache: 93.2%)108000 (cache: 93.3%)114000 (cache: 93.4%)120000 (cache: 93.5%)12c000 (cache: 93.6%)138000 (cache: 93.7%)144000 (cache: 93.8%)150000 (cache: 93.8%)15c000 (cache: 93.9%)168000 (cache: 94.0%)174000 (cache: 94.0%)180000 (cache: 94.1%)18c000 (cache: 94.1%)198000 (cache: 94.2%)1a4000 (cache: 94.2%)1b0000 (cache: 94.3%)1bc000 (cache: 94.3%)1c8000 (cache: 94.4%)1d4000 (cache: 94.4%)1e0000 (cache: 94.4%)1ec000 (cache: 94.5%)1f8000 (cache: 94.5%)204000 (cache: 94.5%)210000 (cache: 94.6%)21c000 (cache: 94.6%)228000 (cache: 94.6%)234000 (cache: 94.6%)240000 (cache: 94.7%)24c000 (cache: 94.7%)258000 (cache: 94.7%)264000 (cache: 94.7%)270000 (cache: 94.7%)27c000 (cache: 94.8%)288000 (cache: 94.8%)294000 (cache: 94.8%)2a0000 (cache: 94.8%)2ac000 (cache: 94.8%)2b8000 (cache: 94.8%)2c4000 (cache: 94.9%)2d0000 (cache: 94.9%)2dc000 (cache: 94.9%)2e8000 (cache: 94.9%)2f4000 (cache: 94.9%)300000 (cache: 94.9%)30c000 (cache: 95.0%)318000 (cache: 95.0%)324000 (cache: 95.0%)330000 (cache: 95.0%)33c000 (cache: 95.0%)348000 (cache: 95.0%)354000 (cache: 95.0%)360000 (cache: 95.0%)36c000 (cache: 95.0%)378000 (cache: 95.1%)384000 (cache: 95.1%)390000 (cache: 95.1%)39c000 (cache: 95.1%)3a8000 (cache: 95.1%)3b4000 (cache: 95.1%)3c0000 (cache: 95.1%)3cc000 (cache: 95.1%)3d8000 (cache: 95.1%)3e4000 (cache: 95.1%)3f0000 (cache: 95.1%)3fc000 (cache: 95.1%)408000 (cache: 95.2%)414000 (cache: 95.2%)Zeroing memory at 0x710210, size = 0x0
Starting ELF64 kernel
Linux version 2.6.24-rc2-gcd60878b-dirty (flo@firewall) (gcc version 4.2.2) #1 Mon Nov 19 14:33:08 CET 2007
ARCH: SGI-IP22
PROMLIB: ARC firmware Version 1 Revision 10
console [early0] enabled
CPU revision is: 00000430 (R4000SC)
FPU revision is: 00000500
MC: SGI memory controller Revision 3
MC: Probing memory configuration:
bank0: 64M @ 08000000
bank1: 64M @ 0c000000
Determined physical RAM map:
memory: 0000000008000000 @ 0000000008000000 (usable)
Wasting 1835008 bytes for tracking 32768 unused pages
Initrd not found or empty - disabling initrd
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64640
Kernel command line: root=/dev/sda1
Primary instruction cache 8kB, VIPT, direct mapped, linesize 16 bytes.
Primary data cache 8kB, direct mapped, VIPT, cache aliases, linesize 16 bytes
Unified secondary cache 1024kB direct mapped, linesize 128 bytes.
Synthesized clear page handler (22 instructions).
Synthesized copy page handler (39 instructions).
Synthesized TLB refill handler (38 instructions).
Synthesized TLB load handler fastpath (50 instructions).
Synthesized TLB store handler fastpath (50 instructions).
Synthesized TLB modify handler fastpath (49 instructions).
PID hash table entries: 1024 (order: 10, 8192 bytes)
Calibrating system timer... 200000 [100.0000 MHz CPU]
Using 50.000 MHz high precision timer.
NG1: Revision 3, 8 bitplanes, REX3 revision B, VC2 revision A, xmap9 revision A, cmap revision C, bt445 revision A
NG1: Screensize 1040x768
Console: colour SGI Newport 130x48
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Memory: 122336k/131072k available (2925k kernel code, 8448k reserved, 955k data, 272k init, 0k highmem)
Kernel bug detected[#1]:
Cpu 0
$ 0 : 0000000000000000 000000001400cce0 0000000000000001 0000000000000000
$ 4 : ffffffff8fc16140 00000000000000d0 00000000000000d0 0000000000000000
$ 8 : ffffffff8fc15000 0000000000000000 ffffffff8fc15030 0000000000000000
$12 : 0000000000100100 0000000000200200 ffffffff883f59a8 ffffffff883f59b8
$16 : ffffffff8fc15180 ffffffff8fc16140 00000000000000d0 ffffffff8fc16140
$20 : 0000000000000080 0000000000000000 0000000000042000 0000000000000000
$24 : 0000000000001463 0000000000000001
$28 : ffffffff88398000 ffffffff8839bde0 00000000000000d0 ffffffff8808bac8
Hi : 0000000000000000
Lo : 0000000000000080
epc : ffffffff8808bb5c cache_alloc_refill+0x8c/0x710 Not tainted
ra : ffffffff8808bac8 kmem_cache_alloc+0xe0/0xe8
Status: 1400cce2 KX SX UX KERNEL EXL
Cause : 00000034
PrId : 00000430 (R4000SC)
Modules linked in:
Process swapper (pid: 0, threadinfo=ffffffff88398000, task=ffffffff8839c2a8)
Stack : 00000000000000d0 0000000000000000 000000001400cce1 ffffffff88430000
00000000000000d0 ffffffff8fc16140 0000000000000080 0000000000000000
0000000000042000 0000000000042000 ffffffff8834c568 ffffffff8808bac8
ffffffff8fc16140 ffffffff88430000 ffffffff883acfa0 0000000000000080
ffffffff882da754 0000000000000080 0000000000000100 0000000000000000
ffffffff8fc16140 ffffffff8808cdb4 0000001e00000000 0000000000000000
0000000000000001 ffffffffffffff80 0000000000000000 0000000000000000
0000000000000000 0000000000000014 ffffffff883acfb0 ffffffff883f57f8
0000000000040000 ffffffff883acfa0 ffffffff883ad118 ffffffff88430058
ffffffff883f0000 ffffffff883b0000 ffffffff88430000 ffffffff883e69a0
...
Call Trace:
[<ffffffff8808bb5c>] cache_alloc_refill+0x8c/0x710
[<ffffffff8808bac8>] kmem_cache_alloc+0xe0/0xe8
[<ffffffff882da754>] setup_cpu_cache+0x64/0x168
[<ffffffff8808cdb4>] kmem_cache_create+0x37c/0x548
[<ffffffff883e69a0>] kmem_cache_init+0x428/0x430
[<ffffffff883cfb18>] start_kernel+0x270/0x3d8
Code: 14e00002 24020001 2d620001 <00028036> dd720040 1240000d 00000000 8e030004 8e450000
Kernel panic - not syncing: Attempted to kill the idle task!
--
Florian Lohoff flo@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ohci-ssb driver on a Broadcom BCM5354
From: John W. Linville @ 2007-11-18 22:47 UTC (permalink / raw)
To: Steve Brown; +Cc: linux-mips, mb
In-Reply-To: <47408305.5090804@cortland.com>
You probably want to make Michael Buesch aware of this issue.
John
On Sun, Nov 18, 2007 at 01:23:01PM -0500, Steve Brown wrote:
> The 5354 has a dual ohci/ehci usb core. It's in an ASUS WL520gu wifi
> router. The ohci hcd driver registers, but times out reading a descriptor
> from the device.
>
> Any suggestions on how to track down the problem?
>
> I'm using 2.6.32.1 kernel from the openwrt project with the "ohci SSB bus
> glue" and "Fix ohci-ssb with !CONFIG_PM" patches from linux-mips. If there
> is a better test frame, let me know and I'll build it and test that.
>
> Is this driver known to work with some combination of Broadcom hardware?
>
> The ohci/usb interface does work w/ the software provided with the WL520gu.
>
> Steve
>
> usbcore: registered new interface driver usbfs
>
> usbcore: registered new interface driver hub
>
> usbcore: registered new device driver usb
>
> ohci_hcd ssb0:1: SSB OHCI Controller
>
> ohci_hcd ssb0:1: new USB bus registered, assigned bus number 1
>
> ohci_hcd ssb0:1: irq 5, io mem 0x18003000
>
> usb usb1: configuration #1 chosen from 1 choice
>
> hub 1-0:1.0: USB hub found
>
> hub 1-0:1.0: 2 ports detected
>
> USB Universal Host Controller Interface driver v3.0
>
> Initializing USB Mass Storage driver...
>
> usbcore: registered new interface driver usb-storage
>
> USB Mass Storage support registered. usb 1-1: new full speed USB device
> using ohci_hcd and address 2
>
> usb 1-1: device descriptor read/64, error -145
>
>
> ===================
>
>> root@OpenWrt:/# cat /proc/bus/usb/devices
>>
>>
>>
>> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
>>
>> B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
>>
>> D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>>
>> P: Vendor=0000 ProdID=0000 Rev= 2.06
>>
>> S: Manufacturer=Linux 2.6.23.1 ssb-usb-ohci
>>
>> S: Product=SSB OHCI Controller
>>
>> S: SerialNumber=ssb0:1
>>
>> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
>>
>> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00
>> Driver=hub
>> E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
>>
>>
>
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* INVITATION
From: inseguro @ 2007-11-18 20:40 UTC (permalink / raw)
To: INVITATION
INVITE YOU TO VISITE MOST IMPORTANTE BRAZILIAN WEB SITE, PORTUGUESE/ SPANINSH/ ENGLISH.
WWW.INSEGURO.COM.BR
SEND ME A MESSAGE ABOUT
. 2.260.000 VIEWS.
ADM@INSEGURO.COM.BR
TKS, FERNANDO DOMINGOS
^ permalink raw reply
* Re: ohci-ssb driver on a Broadcom BCM5354
From: Franck Bui-Huu @ 2007-11-18 19:53 UTC (permalink / raw)
To: Steve Brown; +Cc: linux-mips
In-Reply-To: <47408305.5090804@cortland.com>
Steve Brown wrote:
> The 5354 has a dual ohci/ehci usb core. It's in an ASUS WL520gu wifi
> router. The ohci hcd driver registers, but times out reading a
> descriptor from the device.
>
You'd better post this to linux-usb-devel@lists.sourceforge.net
> Any suggestions on how to track down the problem?
>
CONFIG_USB_DEBUG=y
and
usbmon perhaps.
Franck
^ permalink raw reply
* ohci-ssb driver on a Broadcom BCM5354
From: Steve Brown @ 2007-11-18 18:23 UTC (permalink / raw)
To: linux-mips
The 5354 has a dual ohci/ehci usb core. It's in an ASUS WL520gu wifi
router. The ohci hcd driver registers, but times out reading a
descriptor from the device.
Any suggestions on how to track down the problem?
I'm using 2.6.32.1 kernel from the openwrt project with the "ohci SSB
bus glue" and "Fix ohci-ssb with !CONFIG_PM" patches from linux-mips.
If there is a better test frame, let me know and I'll build it and test
that.
Is this driver known to work with some combination of Broadcom hardware?
The ohci/usb interface does work w/ the software provided with the WL520gu.
Steve
usbcore: registered new interface driver
usbfs
usbcore: registered new interface driver
hub
usbcore: registered new device driver
usb
ohci_hcd ssb0:1: SSB OHCI
Controller
ohci_hcd ssb0:1: new USB bus registered, assigned bus number
1
ohci_hcd ssb0:1: irq 5, io mem
0x18003000
usb usb1: configuration #1 chosen from 1
choice
hub 1-0:1.0: USB hub
found
hub 1-0:1.0: 2 ports
detected
USB Universal Host Controller Interface driver
v3.0
Initializing USB Mass Storage
driver...
usbcore: registered new interface driver
usb-storage
USB Mass Storage support registered.
usb 1-1: new full speed USB device using ohci_hcd and address
2
usb 1-1: device descriptor read/64, error
-145
===================
> root@OpenWrt:/# cat
> /proc/bus/usb/devices
>
>
>
> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh=
> 2
>
> B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso=
> 0
>
> D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs=
> 1
>
> P: Vendor=0000 ProdID=0000 Rev=
> 2.06
>
> S: Manufacturer=Linux 2.6.23.1
> ssb-usb-ohci
>
> S: Product=SSB OHCI
> Controller
>
> S:
> SerialNumber=ssb0:1
>
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=
> 0mA
>
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00
> Driver=hub
>
> E: Ad=81(I) Atr=03(Int.) MxPS= 2
> Ivl=255ms
>
^ permalink raw reply
* [PATCH, REPOST] Fix/Rewrite of the mipsnet driver
From: Thiemo Seufer @ 2007-11-17 22:29 UTC (permalink / raw)
To: netdev; +Cc: linux-mips, ralf
Hello All,
currently the mipsnet driver fails after transmitting a number of
packages because SKBs are allocated but never freed. I fixed that
and coudn't refrain from removing the most egregious warts.
- mipsnet.h folded into mipsnet.c, as it doesn't provide any
useful external interface.
- Free SKB after transmission.
- Call free_irq in mipsnet_close, to balance the request_irq in
mipsnet_open.
- Removed duplicate read of rxDataCount.
- Some identifiers are now less verbose.
- Removed dead and/or unnecessarily complex code.
- Code formatting fixes.
Tested on Qemu's mipssim emulation, with this patch it can boot a
Debian NFSroot.
Thiemo
Signed-off-by: Thiemo Seufer <ths@networkno.de>
---
b/drivers/net/mipsnet.c | 201 ++++++++++++++++++++++++++++++++----------------
drivers/net/mipsnet.h | 112 --------------------------
2 files changed, 134 insertions(+), 179 deletions(-)
diff --git a/drivers/net/mipsnet.c b/drivers/net/mipsnet.c
index aafc3ce..6d343ef 100644
--- a/drivers/net/mipsnet.c
+++ b/drivers/net/mipsnet.c
@@ -4,8 +4,6 @@
* for more details.
*/
-#define DEBUG
-
#include <linux/init.h>
#include <linux/io.h>
#include <linux/kernel.h>
@@ -15,11 +13,93 @@
#include <linux/platform_device.h>
#include <asm/mips-boards/simint.h>
-#include "mipsnet.h" /* actual device IO mapping */
+#define MIPSNET_VERSION "2007-11-17"
+
+/*
+ * Net status/control block as seen by sw in the core.
+ */
+struct mipsnet_regs {
+ /*
+ * Device info for probing, reads as MIPSNET%d where %d is some
+ * form of version.
+ */
+ u64 devId; /*0x00 */
-#define MIPSNET_VERSION "2005-06-20"
+ /*
+ * read only busy flag.
+ * Set and cleared by the Net Device to indicate that an rx or a tx
+ * is in progress.
+ */
+ u32 busy; /*0x08 */
-#define mipsnet_reg_address(dev, field) (dev->base_addr + field_offset(field))
+ /*
+ * Set by the Net Device.
+ * The device will set it once data has been received.
+ * The value is the number of bytes that should be read from
+ * rxDataBuffer. The value will decrease till 0 until all the data
+ * from rxDataBuffer has been read.
+ */
+ u32 rxDataCount; /*0x0c */
+#define MIPSNET_MAX_RXTX_DATACOUNT (1 << 16)
+
+ /*
+ * Settable from the MIPS core, cleared by the Net Device.
+ * The core should set the number of bytes it wants to send,
+ * then it should write those bytes of data to txDataBuffer.
+ * The device will clear txDataCount has been processed (not
+ * necessarily sent).
+ */
+ u32 txDataCount; /*0x10 */
+
+ /*
+ * Interrupt control
+ *
+ * Used to clear the interrupted generated by this dev.
+ * Write a 1 to clear the interrupt. (except bit31).
+ *
+ * Bit0 is set if it was a tx-done interrupt.
+ * Bit1 is set when new rx-data is available.
+ * Until this bit is cleared there will be no other RXs.
+ *
+ * Bit31 is used for testing, it clears after a read.
+ * Writing 1 to this bit will cause an interrupt to be generated.
+ * To clear the test interrupt, write 0 to this register.
+ */
+ u32 interruptControl; /*0x14 */
+#define MIPSNET_INTCTL_TXDONE (1u << 0)
+#define MIPSNET_INTCTL_RXDONE (1u << 1)
+#define MIPSNET_INTCTL_TESTBIT (1u << 31)
+
+ /*
+ * Readonly core-specific interrupt info for the device to signal
+ * the core. The meaning of the contents of this field might change.
+ */
+ /* XXX: the whole memIntf interrupt scheme is messy: the device
+ * should have no control what so ever of what VPE/register set is
+ * being used.
+ * The MemIntf should only expose interrupt lines, and something in
+ * the config should be responsible for the line<->core/vpe bindings.
+ */
+ u32 interruptInfo; /*0x18 */
+
+ /*
+ * This is where the received data is read out.
+ * There is more data to read until rxDataReady is 0.
+ * Only 1 byte at this regs offset is used.
+ */
+ u32 rxDataBuffer; /*0x1c */
+
+ /*
+ * This is where the data to transmit is written.
+ * Data should be written for the amount specified in the
+ * txDataCount register.
+ * Only 1 byte at this regs offset is used.
+ */
+ u32 txDataBuffer; /*0x20 */
+};
+
+#define regaddr(dev, field) \
+ (dev->base_addr + offsetof(struct mipsnet_regs, field))
static char mipsnet_string[] = "mipsnet";
@@ -29,32 +109,27 @@ static char mipsnet_string[] = "mipsnet";
static int ioiocpy_frommipsnet(struct net_device *dev, unsigned char *kdata,
int len)
{
- uint32_t available_len = inl(mipsnet_reg_address(dev, rxDataCount));
-
- if (available_len < len)
- return -EFAULT;
-
for (; len > 0; len--, kdata++)
- *kdata = inb(mipsnet_reg_address(dev, rxDataBuffer));
+ *kdata = inb(regaddr(dev, rxDataBuffer));
- return inl(mipsnet_reg_address(dev, rxDataCount));
+ return inl(regaddr(dev, rxDataCount));
}
-static inline ssize_t mipsnet_put_todevice(struct net_device *dev,
+static inline void mipsnet_put_todevice(struct net_device *dev,
struct sk_buff *skb)
{
int count_to_go = skb->len;
char *buf_ptr = skb->data;
- outl(skb->len, mipsnet_reg_address(dev, txDataCount));
+ outl(skb->len, regaddr(dev, txDataCount));
for (; count_to_go; buf_ptr++, count_to_go--)
- outb(*buf_ptr, mipsnet_reg_address(dev, txDataBuffer));
+ outb(*buf_ptr, regaddr(dev, txDataBuffer));
dev->stats.tx_packets++;
dev->stats.tx_bytes += skb->len;
- return skb->len;
+ dev_kfree_skb(skb);
}
static int mipsnet_xmit(struct sk_buff *skb, struct net_device *dev)
@@ -69,18 +144,20 @@ static int mipsnet_xmit(struct sk_buff *skb, struct net_device *dev)
return 0;
}
-static inline ssize_t mipsnet_get_fromdev(struct net_device *dev, size_t count)
+static inline ssize_t mipsnet_get_fromdev(struct net_device *dev, size_t len)
{
struct sk_buff *skb;
- size_t len = count;
- skb = alloc_skb(len + 2, GFP_KERNEL);
+ if (!len)
+ return len;
+
+ skb = dev_alloc_skb(len + NET_IP_ALIGN);
if (!skb) {
dev->stats.rx_dropped++;
return -ENOMEM;
}
- skb_reserve(skb, 2);
+ skb_reserve(skb, NET_IP_ALIGN);
if (ioiocpy_frommipsnet(dev, skb_put(skb, len), len))
return -EFAULT;
@@ -92,50 +169,42 @@ static inline ssize_t mipsnet_get_fromdev(struct net_device *dev, size_t count)
dev->stats.rx_packets++;
dev->stats.rx_bytes += len;
- return count;
+ return len;
}
static irqreturn_t mipsnet_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
-
- irqreturn_t retval = IRQ_NONE;
- uint64_t interruptFlags;
-
- if (irq == dev->irq) {
- retval = IRQ_HANDLED;
-
- interruptFlags =
- inl(mipsnet_reg_address(dev, interruptControl));
-
- if (interruptFlags & MIPSNET_INTCTL_TXDONE) {
- outl(MIPSNET_INTCTL_TXDONE,
- mipsnet_reg_address(dev, interruptControl));
- /* only one packet at a time, we are done. */
- netif_wake_queue(dev);
- } else if (interruptFlags & MIPSNET_INTCTL_RXDONE) {
- mipsnet_get_fromdev(dev,
- inl(mipsnet_reg_address(dev, rxDataCount)));
- outl(MIPSNET_INTCTL_RXDONE,
- mipsnet_reg_address(dev, interruptControl));
-
- } else if (interruptFlags & MIPSNET_INTCTL_TESTBIT) {
- /*
- * TESTBIT is cleared on read.
- * And takes effect after a write with 0
- */
- outl(0, mipsnet_reg_address(dev, interruptControl));
- } else {
- /* Maybe shared IRQ, just ignore, no clearing. */
- retval = IRQ_NONE;
- }
-
- } else {
- printk(KERN_INFO "%s: %s(): irq %d for unknown device\n",
- dev->name, __FUNCTION__, irq);
- retval = IRQ_NONE;
+ u32 int_flags;
+ irqreturn_t ret = IRQ_NONE;
+
+ if (irq != dev->irq)
+ goto out_badirq;
+
+ /* TESTBIT is cleared on read. */
+ int_flags = inl(regaddr(dev, interruptControl));
+ if (int_flags & MIPSNET_INTCTL_TESTBIT) {
+ /* TESTBIT takes effect after a write with 0. */
+ outl(0, regaddr(dev, interruptControl));
+ ret = IRQ_HANDLED;
+ } else if (int_flags & MIPSNET_INTCTL_TXDONE) {
+ /* Only one packet at a time, we are done. */
+ dev->stats.tx_packets++;
+ netif_wake_queue(dev);
+ outl(MIPSNET_INTCTL_TXDONE,
+ regaddr(dev, interruptControl));
+ ret = IRQ_HANDLED;
+ } else if (int_flags & MIPSNET_INTCTL_RXDONE) {
+ mipsnet_get_fromdev(dev, inl(regaddr(dev, rxDataCount)));
+ outl(MIPSNET_INTCTL_RXDONE, regaddr(dev, interruptControl));
+ ret = IRQ_HANDLED;
}
- return retval;
+ return ret;
+
+out_badirq:
+ printk(KERN_INFO "%s: %s(): irq %d for unknown device\n",
+ dev->name, __FUNCTION__, irq);
+ return ret;
}
static int mipsnet_open(struct net_device *dev)
@@ -144,18 +213,15 @@ static int mipsnet_open(struct net_device *dev)
err = request_irq(dev->irq, &mipsnet_interrupt,
IRQF_SHARED, dev->name, (void *) dev);
-
if (err) {
- release_region(dev->base_addr, MIPSNET_IO_EXTENT);
+ release_region(dev->base_addr, sizeof(struct mipsnet_regs));
return err;
}
netif_start_queue(dev);
/* test interrupt handler */
- outl(MIPSNET_INTCTL_TESTBIT,
- mipsnet_reg_address(dev, interruptControl));
-
+ outl(MIPSNET_INTCTL_TESTBIT, regaddr(dev, interruptControl));
return 0;
}
@@ -163,7 +229,7 @@ static int mipsnet_open(struct net_device *dev)
static int mipsnet_close(struct net_device *dev)
{
netif_stop_queue(dev);
-
+ free_irq(dev->irq, dev);
return 0;
}
@@ -194,10 +260,11 @@ static int __init mipsnet_probe(struct device *dev)
*/
netdev->base_addr = 0x4200;
netdev->irq = MIPS_CPU_IRQ_BASE + MIPSCPU_INT_MB0 +
- inl(mipsnet_reg_address(netdev, interruptInfo));
+ inl(regaddr(netdev, interruptInfo));
/* Get the io region now, get irq on open() */
- if (!request_region(netdev->base_addr, MIPSNET_IO_EXTENT, "mipsnet")) {
+ if (!request_region(netdev->base_addr, sizeof(struct mipsnet_regs),
+ "mipsnet")) {
err = -EBUSY;
goto out_free_netdev;
}
@@ -217,7 +284,7 @@ static int __init mipsnet_probe(struct device *dev)
return 0;
out_free_region:
- release_region(netdev->base_addr, MIPSNET_IO_EXTENT);
+ release_region(netdev->base_addr, sizeof(struct mipsnet_regs));
out_free_netdev:
free_netdev(netdev);
@@ -231,7 +298,7 @@ static int __devexit mipsnet_device_remove(struct device *device)
struct net_device *dev = dev_get_drvdata(device);
unregister_netdev(dev);
- release_region(dev->base_addr, MIPSNET_IO_EXTENT);
+ release_region(dev->base_addr, sizeof(struct mipsnet_regs));
free_netdev(dev);
dev_set_drvdata(device, NULL);
diff --git a/drivers/net/mipsnet.h b/drivers/net/mipsnet.h
deleted file mode 100644
index 0132c67..0000000
--- a/drivers/net/mipsnet.h
+++ /dev/null
@@ -1,112 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- */
-#ifndef __MIPSNET_H
-#define __MIPSNET_H
-
-/*
- * Id of this Net device, as seen by the core.
- */
-#define MIPS_NET_DEV_ID ((uint64_t) \
- ((uint64_t) 'M' << 0)| \
- ((uint64_t) 'I' << 8)| \
- ((uint64_t) 'P' << 16)| \
- ((uint64_t) 'S' << 24)| \
- ((uint64_t) 'N' << 32)| \
- ((uint64_t) 'E' << 40)| \
- ((uint64_t) 'T' << 48)| \
- ((uint64_t) '0' << 56))
-
-/*
- * Net status/control block as seen by sw in the core.
- * (Why not use bit fields? can't be bothered with cross-platform struct
- * packing.)
- */
-struct net_control_block {
- /*
- * dev info for probing
- * reads as MIPSNET%d where %d is some form of version
- */
- uint64_t devId; /* 0x00 */
-
- /*
- * read only busy flag.
- * Set and cleared by the Net Device to indicate that an rx or a tx
- * is in progress.
- */
- uint32_t busy; /* 0x08 */
-
- /*
- * Set by the Net Device.
- * The device will set it once data has been received.
- * The value is the number of bytes that should be read from
- * rxDataBuffer. The value will decrease till 0 until all the data
- * from rxDataBuffer has been read.
- */
- uint32_t rxDataCount; /* 0x0c */
-#define MIPSNET_MAX_RXTX_DATACOUNT (1<<16)
-
- /*
- * Settable from the MIPS core, cleared by the Net Device. The core
- * should set the number of bytes it wants to send, then it should
- * write those bytes of data to txDataBuffer. The device will clear
- * txDataCount has been processed (not necessarily sent).
- */
- uint32_t txDataCount; /* 0x10 */
-
- /*
- * Interrupt control
- *
- * Used to clear the interrupted generated by this dev.
- * Write a 1 to clear the interrupt. (except bit31).
- *
- * Bit0 is set if it was a tx-done interrupt.
- * Bit1 is set when new rx-data is available.
- * Until this bit is cleared there will be no other RXs.
- *
- * Bit31 is used for testing, it clears after a read.
- * Writing 1 to this bit will cause an interrupt to be generated.
- * To clear the test interrupt, write 0 to this register.
- */
- uint32_t interruptControl; /*0x14 */
-#define MIPSNET_INTCTL_TXDONE ((uint32_t)(1 << 0))
-#define MIPSNET_INTCTL_RXDONE ((uint32_t)(1 << 1))
-#define MIPSNET_INTCTL_TESTBIT ((uint32_t)(1 << 31))
-#define MIPSNET_INTCTL_ALLSOURCES (MIPSNET_INTCTL_TXDONE | \
- MIPSNET_INTCTL_RXDONE | \
- MIPSNET_INTCTL_TESTBIT)
-
- /*
- * Readonly core-specific interrupt info for the device to signal the
- * core. The meaning of the contents of this field might change.
- *
- * TODO: the whole memIntf interrupt scheme is messy: the device should
- * have no control what so ever of what VPE/register set is being
- * used. The MemIntf should only expose interrupt lines, and
- * something in the config should be responsible for the
- * line<->core/vpe bindings.
- */
- uint32_t interruptInfo; /* 0x18 */
-
- /*
- * This is where the received data is read out.
- * There is more data to read until rxDataReady is 0.
- * Only 1 byte at this regs offset is used.
- */
- uint32_t rxDataBuffer; /* 0x1c */
-
- /*
- * This is where the data to transmit is written. Data should be
- * written for the amount specified in the txDataCount register. Only
- * 1 byte at this regs offset is used.
- */
- uint32_t txDataBuffer; /* 0x20 */
-};
-
-#define MIPSNET_IO_EXTENT 0x40 /* being generous */
-
-#define field_offset(field) (offsetof(struct net_control_block, field))
-
-#endif /* __MIPSNET_H */
^ permalink raw reply related
* Re: Preliminary patch for ip32 ttyS* device
From: Martin Michlmayr @ 2007-11-17 19:35 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Giuseppe Sacco, mips kernel list
In-Reply-To: <Pine.LNX.4.64N.0711071716470.14970@blysk.ds.pg.gda.pl>
* Maciej W. Rozycki <macro@linux-mips.org> [2007-11-07 17:21]:
> > If mapbase isn't mandatory, the second part of my patch is
> > probably right and fixes a bug.
>
> You ought to use mapbase and ioremap() with new code as you are not
> allowed to use readb()/writeb()/etc. on addresses obtained otherwise
> than by calling ioremap(). The use of request_mem_region(), etc. is
> not strictly mandatory, but it is nice to have. Many serial drivers
> use these functions, so I cannot see a reason why it would be a
> hassle for ip32.
Can someone propose a patch? It's quote unfortuntely that serial on
IP32 is still broken (including 2.6.23).
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Franck Bui-Huu @ 2007-11-17 8:38 UTC (permalink / raw)
To: David Daney; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <473C8006.2070902@avtrex.com>
David Daney wrote:
> I am liking the idea of putting the trampoline code in the (as of yet
> non-existent vdso). This eliminates the need to flush the icache, but
> maintains the ability of user code to unwind through signal frames.
>
> Putting a .eh_frame section in the vdso would be even better as that
> would eliminate the need for libgcc to do code reading and let the
> kernel use any means desired to return from signal handlers.
>
You're very welcome to improve the ld script for VDSO generation, I
sent a couple days ago. I would be happy to integrate your
improvements in my patch for the future version.
thanks,
Franck
^ permalink raw reply
* futex_wake_op deadlock?
From: Kaz Kylheku @ 2007-11-16 23:52 UTC (permalink / raw)
To: linux-mips
Hey everyone,
From time to time, on 2.6.17.7, I see a deadlock situation go off. The
soft lockup tick occurs in the middle of do_futex, which is heavily
inlined. The system is actually hosed; it's not one of those
recoverable CPU busy situations that can sometimes trigger the lockup
detector.
The instruction that is interrupted by the soft lockup tick appears to
be in the assembly code (__futex_atomic_op) used by the futex_wake_op
function; the case is FUTEX_OP_SET. It's the instruction just before
the load-linked; i.e. the interrupt is outside of the ll/sc loop.
I can't figure out how the code would get into a loop here. The ll/sc
logic should eventually succeed. There is a large loop in the overall
futex operation, but that is bounded by an interation variable
(attempt++).
(I checked the 2.6.17 head, but there doesn't appear to be any
futex-related work).
This lockup has reproduced more than once for us. Once at bootup, and
several times on shutdown.
The call stack always includes several do_futex frames, and a
compat_sys_futex/handle_sysn32 at the top of the chain.
This is from syslog (the unusual format is due to running metalog rather
than syslog in our distribution, and the human-readable time in the
square-bracketed printk timestamps is a locally developed patch):
Jan 3 02:47:02 [kernel] [02:47:02.953075] [<ffffffff8016de8c>]
softlockup_tick+0x1bc/0x208
Jan 3 02:47:02 [kernel] [02:47:02.953121] [<ffffffff8014cc54>]
update_process_times+0x9c/0xe8
Jan 3 02:47:02 [kernel] [02:47:02.953158] [<ffffffff801098bc>]
ll_local_timer_interrupt+0x94/0xa8
Jan 3 02:47:02 [kernel] [02:47:02.953194] [<ffffffff801026a0>]
plat_irq_dispatch+0x120/0x1a0
Jan 3 02:47:02 [kernel] [02:47:02.953221] [<ffffffff80163758>]
do_futex+0x870/0xb58
Jan 3 02:47:02 [kernel] [02:47:02.953251] [<ffffffff801637e0>]
do_futex+0x8f8/0xb58
Jan 3 02:47:02 [kernel] [02:47:02.953275] [<ffffffff8047b16c>]
__lock_text_end+0x1b3c/0x474c
Jan 3 02:47:02 [kernel] [02:47:02.953312] [<ffffffff8036fc40>]
sys_sendto+0xe8/0x140
Jan 3 02:47:02 [kernel] [02:47:02.953345] [<ffffffff80163fac>]
compat_sys_futex+0x84/0x188
Jan 3 02:47:02 [kernel] [02:47:02.953372] [<ffffffff80116314>]
handle_sysn32+0x54/0xb0
The sys_sendto is a red herring, since the backtrace function dumps
every single word on the stack as an address, not having any frame
pointers to go by.
The code surrounding ffffffff80163758:
ffffffff8016374c: 00023000 sll a2,v0,0x0
ffffffff80163750: 08058c77 j ffffffff801631dc
<do_futex+0x2f4>
ffffffff80163754: 00034000 sll a4,v1,0x0
ffffffff80163758: 0000102d move v0,zero <----<<
ffffffff8016375c: c2030000 ll v1,0(s0)
ffffffff80163760: 00a0082d move at,a1
ffffffff80163764: e2010000 sc at,0(s0)
ffffffff80163768: 1020fffc beqz at,ffffffff8016375c
<do_futex+0x874>
ffffffff8016376c: 00000000 nop
ffffffff80163770: 0000000f sync
ffffffff80163774: 8f870024 lw a3,36(gp)
ffffffff80163778: 00023000 sll a2,v0,0x0
ffffffff8016377c: 08058c77 j ffffffff801631dc
<do_futex+0x2f4>
You can tell from the "move at, a1" that it's the FUTEX_OP_SET case.
^ permalink raw reply
* futex_wake_op deadlock?
From: Kaz Kylheku @ 2007-11-16 23:52 UTC (permalink / raw)
To: linux-mips
Hey everyone,
^ permalink raw reply
* [PATCH] Introduce __fill_user() and kill __bzero() [take #3]
From: Franck Bui-Huu @ 2007-11-16 12:43 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Thiemo Seufer, Geert Uytterhoeven, linux-mips
Currently memset() is used to fill a user space area (clear_user) or
kernel one (memset). These two functions don't have the same
prototype, the former returning the number of bytes not copied and the
latter returning the start address of the area to clear. This forces
memset() to actually returns two values in an unconventional way ie
the number of bytes not copied is given by $a2. Therefore clear_user()
needs to call memset() using inline assembly.
Instead this patch creates __fill_user() which is the same as memset()
except it always returns the number of bytes not copied. This simplify
clear_user() and makes its definition saner. This patch also renames
memset.S into fill_user.S as suggested by Thiemo.
Also an out of line version of memset is given because gcc generates
some calls to it since builtin functions have been disabled. It allows
assembly code to call it too. It has been put into a new file called
string.c.
Eventually __bzero() has been removed because it's not part of the
Linux uaccess API. And the nano-optimization it brings is not
worthing.
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
---
Ralf,
Since you use git, this patch has been generated with rename detection
enabled. It makes the review a lot easier.
Please consider,
Franck
arch/mips/kernel/mips_ksyms.c | 2 +-
arch/mips/lib/Makefile | 4 +-
arch/mips/lib/csum_partial.S | 2 +-
arch/mips/lib/{memset.S => fill_user.S} | 34 +++++++++++++++---------------
arch/mips/lib/memcpy.S | 2 +-
arch/mips/lib/string.c | 13 +++++++++++
include/asm-mips/string.h | 7 +++++-
include/asm-mips/uaccess.h | 17 ++------------
8 files changed, 44 insertions(+), 37 deletions(-)
rename arch/mips/lib/{memset.S => fill_user.S} (90%)
create mode 100644 arch/mips/lib/string.c
diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c
index 225755d..c7613d3 100644
--- a/arch/mips/kernel/mips_ksyms.c
+++ b/arch/mips/kernel/mips_ksyms.c
@@ -38,7 +38,7 @@ EXPORT_SYMBOL(kernel_thread);
*/
EXPORT_SYMBOL(__copy_user);
EXPORT_SYMBOL(__copy_user_inatomic);
-EXPORT_SYMBOL(__bzero);
+EXPORT_SYMBOL(__fill_user);
EXPORT_SYMBOL(__strncpy_from_user_nocheck_asm);
EXPORT_SYMBOL(__strncpy_from_user_asm);
EXPORT_SYMBOL(__strlen_user_nocheck_asm);
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index 8810dfb..1c3fea4 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -2,8 +2,8 @@
# Makefile for MIPS-specific library files..
#
-lib-y += csum_partial.o memcpy.o memcpy-inatomic.o memset.o strlen_user.o \
- strncpy_user.o strnlen_user.o uncached.o
+lib-y += csum_partial.o fill_user.o memcpy.o memcpy-inatomic.o string.o \
+ strlen_user.o strncpy_user.o strnlen_user.o uncached.o
obj-y += iomap.o
obj-$(CONFIG_PCI) += iomap-pci.o
diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S
index c0a77fe..8d3fa1e 100644
--- a/arch/mips/lib/csum_partial.S
+++ b/arch/mips/lib/csum_partial.S
@@ -694,7 +694,7 @@ l_exc:
ADD dst, t0 # compute start address in a1
SUB dst, src
/*
- * Clear len bytes starting at dst. Can't call __bzero because it
+ * Clear len bytes starting at dst. Can't call memset because it
* might modify len. An inefficient loop for these rare times...
*/
beqz len, done
diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/fill_user.S
similarity index 90%
rename from arch/mips/lib/memset.S
rename to arch/mips/lib/fill_user.S
index 3f8b8b3..4329811 100644
--- a/arch/mips/lib/memset.S
+++ b/arch/mips/lib/fill_user.S
@@ -46,17 +46,19 @@
.endm
/*
- * memset(void *s, int c, size_t n)
+ * __kernel_size_t __fill_user(void __user *s, long c, __kernel_size_t n)
*
* a0: start of area to clear
* a1: char to fill with
* a2: size of area to clear
+ *
+ * Returns the number of bytes NOT set or 0 on success.
*/
.set noreorder
.align 5
-LEAF(memset)
+LEAF(__fill_user)
beqz a1, 1f
- move v0, a0 /* result */
+ move v0, zero /* result */
andi a1, 0xff /* spread fillword */
LONG_SLL t1, a1, 8
@@ -68,8 +70,6 @@ LEAF(memset)
#endif
or a1, t1
1:
-
-FEXPORT(__bzero)
sltiu t0, a2, LONGSIZE /* very small region? */
bnez t0, small_memset
andi t0, a0, LONGMASK /* aligned? */
@@ -127,7 +127,7 @@ memset_partial:
EX(LONG_S_L, a1, -1(a0), last_fixup)
#endif
1: jr ra
- move a2, zero
+ nop
small_memset:
beqz a2, 2f
@@ -138,29 +138,29 @@ small_memset:
sb a1, -1(a0)
2: jr ra /* done */
- move a2, zero
- END(memset)
+ nop
+END(__fill_user)
first_fixup:
- jr ra
- nop
+ jr ra
+ move v0, a2
fwd_fixup:
PTR_L t0, TI_TASK($28)
LONG_L t0, THREAD_BUADDR(t0)
- andi a2, 0x3f
- LONG_ADDU a2, t1
+ andi v0, a2, 0x3f
+ LONG_ADDU v0, t1
jr ra
- LONG_SUBU a2, t0
+ LONG_SUBU v0, t0
partial_fixup:
PTR_L t0, TI_TASK($28)
LONG_L t0, THREAD_BUADDR(t0)
- andi a2, LONGMASK
- LONG_ADDU a2, t1
+ andi v0, a2, LONGMASK
+ LONG_ADDU v0, t1
jr ra
- LONG_SUBU a2, t0
+ LONG_SUBU v0, t0
last_fixup:
jr ra
- andi v1, a2, LONGMASK
+ andi v0, a2, LONGMASK
diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S
index a526c62..425f2c3 100644
--- a/arch/mips/lib/memcpy.S
+++ b/arch/mips/lib/memcpy.S
@@ -443,7 +443,7 @@ l_exc:
ADD dst, t0 # compute start address in a1
SUB dst, src
/*
- * Clear len bytes starting at dst. Can't call __bzero because it
+ * Clear len bytes starting at dst. Can't call memset because it
* might modify len. An inefficient loop for these rare times...
*/
beqz len, done
diff --git a/arch/mips/lib/string.c b/arch/mips/lib/string.c
new file mode 100644
index 0000000..42fb613
--- /dev/null
+++ b/arch/mips/lib/string.c
@@ -0,0 +1,13 @@
+#include <linux/kernel.h>
+
+#include <asm/uaccess.h>
+
+/*
+ * An outline version of memset, which should be used either by gcc or
+ * by assembly code.
+ */
+void *memset(void *s, int c, __kernel_size_t len)
+{
+ __fill_user(s, c, len);
+ return s;
+}
diff --git a/include/asm-mips/string.h b/include/asm-mips/string.h
index 436e3ad..2bba927 100644
--- a/include/asm-mips/string.h
+++ b/include/asm-mips/string.h
@@ -10,6 +10,7 @@
#ifndef _ASM_STRING_H
#define _ASM_STRING_H
+#include <asm/uaccess.h> /* __fill_user() */
/*
* Most of the inline functions are rather naive implementations so I just
@@ -132,7 +133,11 @@ strncmp(__const__ char *__cs, __const__ char *__ct, size_t __count)
#endif /* CONFIG_32BIT */
#define __HAVE_ARCH_MEMSET
-extern void *memset(void *__s, int __c, size_t __count);
+extern inline void *memset(void *s, int c, size_t count)
+{
+ __fill_user(s, c, count);
+ return s;
+}
#define __HAVE_ARCH_MEMCPY
extern void *memcpy(void *__to, __const__ void *__from, size_t __n);
diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h
index c30c718..8c0d226 100644
--- a/include/asm-mips/uaccess.h
+++ b/include/asm-mips/uaccess.h
@@ -11,7 +11,6 @@
#include <linux/kernel.h>
#include <linux/errno.h>
-#include <linux/thread_info.h>
#include <asm-generic/uaccess.h>
/*
@@ -633,23 +632,13 @@ extern size_t __copy_user_inatomic(void *__to, const void *__from, size_t __n);
* Returns number of bytes that could not be cleared.
* On success, this will be zero.
*/
+extern __kernel_size_t __fill_user(void __user *s, long c, __kernel_size_t n);
+
static inline __kernel_size_t
__clear_user(void __user *addr, __kernel_size_t size)
{
- __kernel_size_t res;
-
might_sleep();
- __asm__ __volatile__(
- "move\t$4, %1\n\t"
- "move\t$5, $0\n\t"
- "move\t$6, %2\n\t"
- __MODULE_JAL(__bzero)
- "move\t%0, $6"
- : "=r" (res)
- : "r" (addr), "r" (size)
- : "$4", "$5", "$6", __UA_t0, __UA_t1, "$31");
-
- return res;
+ return __fill_user(addr, 0, size);
}
#define clear_user(addr,n) \
--
1.5.3.5
^ permalink raw reply related
* Re: "exportfs -a" -> stale NFS filehandle
From: Ralf Baechle @ 2007-11-15 23:02 UTC (permalink / raw)
To: Kaz Kylheku; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C54DC8F6@exchange.ZeugmaSystems.local>
On Thu, Nov 15, 2007 at 12:15:39PM -0800, Kaz Kylheku wrote:
> Ralf Baechle wrote:
> > On Thu, Nov 15, 2007 at 11:26:06AM -0800, Kaz Kylheku wrote:
> >
> >> After backing out the nfsutils patch, the diskless node does boot.
> >>
> >> However, the original "exportfs -a" problem comes back!
> >>
> >> So this problem is not resolved simply by using the correct compat
> >> routine; it's deeper.
> >>
> >> Sigh.
> >
> > Thanks for testing anyway!
>
> I'm continuing to dig into the problem.
>
> The export logic doesn't even go through nfsctl() anyway, which is why I
> originally hadn't even suspected that syscall.
>
> The nfsexport() function in nfsutils first tries opening
> "/proc/net/rpc/nfsd.fh./channel". If that works, it uses that, via a
> text-based protocol. Only if that interface doesn't exist does it fall
> back on the nfsctl(NFSCTL_EXPORT, ...) interface.
After checking that latest glibc still isn't trying to compensate for the
N32 nfsservctl issue in userland I've applied the patch I sent you earlier.
Ralf
^ permalink raw reply
* Re: [PATCH] Introduce __fill_user() and kill __bzero() [take #2]
From: Geert Uytterhoeven @ 2007-11-15 22:09 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Ralf Baechle, Thiemo Seufer, linux-mips
In-Reply-To: <473CB727.8010106@gmail.com>
On Thu, 15 Nov 2007, Franck Bui-Huu wrote:
> Geert Uytterhoeven wrote:
> > On Thu, 15 Nov 2007, Franck Bui-Huu wrote:
> >> I put the out of line version of memset in kernel/mips_ksym.c. I
> >> haven't found a better place. But if you really think we should
> >> create a lib/memset.c and rename lib/memset.S into lib/fill_user.S, I
> >> can change it.
> >
> > kernel/mips_ksym.c is not a good place.
>
> Sigh... thanks for spotting this.
>
> So since I've no idea where I could put this function I'll follow
> Thiemo's suggestion but instead of calling the new file lib/memset.c,
> I'll use lib/string.c since we could move or implement other stuffs in
> it.
>
> Is it ok ?
lib/string.c sounds fine to me. That's where m68k and s390 implement it
as well.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox