* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Jean Delvare @ 2007-11-06 18:10 UTC (permalink / raw)
To: Scott Wood; +Cc: Tjernlund, linuxppc-dev, i2c
In-Reply-To: <4730A617.9040502@freescale.com>
Hi Scott,
On Tue, 06 Nov 2007 11:36:23 -0600, Scott Wood wrote:
> Jean Delvare wrote:
> >>>> We might as well just use i2c_new_device() instead of messing around
> >>>> with bus numbers. Note that this is technically no longer platform
> >>>> code, so it's harder to justify claiming the static numberspace.
> >>> I was allowing control of the bus number with "cell-index" and
> >>> i2c_add_numbered_adapter().
> >>> Should I get rid of this and switch to i2c_add_adapter()?
> >> Yes.
> >
> > No! If you don't call i2c_add_numbered_adapter() then new-style i2c
> > clients will never work on your i2c adapter.
>
> I thought that was what i2c_new_device() was for?
Sorry, I've not been completely clear. Yes, you can use
i2c_new_device() on an adapter that has been added with
i2c_add_adapter(). However, this requires that you have a reference to
that i2c_adapter, which is usually not the case with system-wide I2C
buses. Embedded platforms would rather use i2c_add_numbered_adapter(),
give a list of chips to i2c_register_board_info() and let i2c-core
instantiate them. i2c_new_device was primarily meant for multimedia
adapters.
> By handling all the device tree stuff in the driver, it acts more like
> an add-on adapter than a platform device.
--
Jean Delvare
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Scott Wood @ 2007-11-06 17:36 UTC (permalink / raw)
To: Jean Delvare; +Cc: Tjernlund, linuxppc-dev, i2c
In-Reply-To: <20071106182953.3c1a57e3@hyperion.delvare>
Jean Delvare wrote:
>>>> We might as well just use i2c_new_device() instead of messing around
>>>> with bus numbers. Note that this is technically no longer platform
>>>> code, so it's harder to justify claiming the static numberspace.
>>> I was allowing control of the bus number with "cell-index" and
>>> i2c_add_numbered_adapter().
>>> Should I get rid of this and switch to i2c_add_adapter()?
>> Yes.
>
> No! If you don't call i2c_add_numbered_adapter() then new-style i2c
> clients will never work on your i2c adapter.
I thought that was what i2c_new_device() was for?
By handling all the device tree stuff in the driver, it acts more like
an add-on adapter than a platform device.
-Scott
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Jon Smirl @ 2007-11-06 17:45 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, Tjernlund, i2c
In-Reply-To: <20071106182953.3c1a57e3@hyperion.delvare>
On 11/6/07, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Scott, Jon,
>
> On Mon, 05 Nov 2007 14:51:51 -0600, Scott Wood wrote:
> > Jon Smirl wrote:
> > > How about renaming the old driver file and leaving it hooked to ppc?
> > > Then it would get deleted when ppc goes away. That would let work
> > > progress on the powerpc version.
> >
> > Or we could have one driver that has two probe methods. I don't like
> > forking the driver.
>
> I agree with Scott here, I don't want to fork the drivers. It is
> possible (and easy) to support both methods in the same module, let's
> just to that. See for example David Brownell's work on the lm75 driver:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2007-September/021270.html
I agree that it is easy to make make a chip driver support both new
and old style.
But when I call i2c_new_device() on an old style chip driver it exits
saying that it doesn't work for the old style adapters. Checks for
is_newstyle_driver() are in the i2c_new_device code. That's what
caused me to rewrite the rtc-pcf8563 driver for the new style. This
probably related to probing, I have to pass the address in struct
i2c_board_info. The old style drivers don't support having their
address passed in.
This may be complicated by the fact that the rtc drivers I'm working
on are not probable. That's why I want to add device tree support for
them.
If this is going to work on an old style driver, how do I get the address to it?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Jean Delvare @ 2007-11-06 17:32 UTC (permalink / raw)
To: Matt Sealey; +Cc: Tjernlund, i2c, linuxppc-dev
In-Reply-To: <472F9086.2060606@genesi-usa.com>
On Mon, 05 Nov 2007 21:52:06 +0000, Matt Sealey wrote:
> Well, all i2c devices have a chip id you can probe for (...)
This statement is completely incorrect. I2C devices do NOT have
standard ID registers. Some devices have proprietary ID registers, some
don't, it's really up to the manfacturer.
--
Jean Delvare
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Jean Delvare @ 2007-11-06 17:29 UTC (permalink / raw)
To: Scott Wood; +Cc: Tjernlund, linuxppc-dev, i2c
In-Reply-To: <472F8267.8070106@freescale.com>
Hi Scott, Jon,
On Mon, 05 Nov 2007 14:51:51 -0600, Scott Wood wrote:
> Jon Smirl wrote:
> > How about renaming the old driver file and leaving it hooked to ppc?
> > Then it would get deleted when ppc goes away. That would let work
> > progress on the powerpc version.
>
> Or we could have one driver that has two probe methods. I don't like
> forking the driver.
I agree with Scott here, I don't want to fork the drivers. It is
possible (and easy) to support both methods in the same module, let's
just to that. See for example David Brownell's work on the lm75 driver:
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-September/021270.html
> > i2c_new_device() doesn't work with legacy-style client drivers.
>
> No, but they should still work the old way.
Definitely.
> > This is not hard to do but the i2c people will have to agree. I need
> > to change the i2c_driver structure to include the additional names.
>
> I got a fair bit of resistance from them on the topic of multiple match
> names for i2c clients.
Really? All I said is that you were a bit late in the game because this
had been discussed before. I know that David Brownell doesn't agree
with you (he designed what we have now), but me, I am still open to
discussing the matter, especially when more people complain about the
situation every month.
> >> We might as well just use i2c_new_device() instead of messing around
> >> with bus numbers. Note that this is technically no longer platform
> >> code, so it's harder to justify claiming the static numberspace.
> >
> > I was allowing control of the bus number with "cell-index" and
> > i2c_add_numbered_adapter().
> > Should I get rid of this and switch to i2c_add_adapter()?
>
> Yes.
No! If you don't call i2c_add_numbered_adapter() then new-style i2c
clients will never work on your i2c adapter.
--
Jean Delvare
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Scott Wood @ 2007-11-06 17:02 UTC (permalink / raw)
To: Jon Smirl; +Cc: Tjernlund, linuxppc-dev, Jean Delvare, i2c
In-Reply-To: <9e4733910711051641m5ff0e651ke9a43daa51fd14b@mail.gmail.com>
Jon Smirl wrote:
> On 11/5/07, Scott Wood <scottwood@freescale.com> wrote:
>>>>> One side effect is that legacy style i2c drivers won't work anymore.
>>>> If you mean legacy-style client drivers, why not?
>>> i2c_new_device() doesn't work with legacy-style client drivers.
>> No, but they should still work the old way.
>
> I'm not in favor trying to support both legacy and new style i2c
> drivers.
I don't understand what it is that you did that would break support for
legacy clients, though.
> It took me all of five minutes to convert an existing legacy
> driver to the new style. Pretty much all you need to do is delete code
> (about 100 lines). So I'd recommend converting the drivers we are
> interest in instead of trying to support both types.
Sure, conversion is good, but that doesn't mean we want things to
suddenly break for users.
-Scott
^ permalink raw reply
* Re: problem in follow_hugetlb_page on ppc64 architecture with get_user_pages
From: Hoang-Nam Nguyen @ 2007-11-06 16:39 UTC (permalink / raw)
To: aglitke
Cc: Roland Dreier, linux-kernel, linux-ppc, Christoph Raisch,
Hoang-Nam Nguyen, general
In-Reply-To: <1194361532.20383.4.camel@localhost.localdomain>
Hi Adam!
On Tuesday 06 November 2007 16:05, aglitke wrote:
> Please try this patch and see if it helps.
Tested on 2.6.22 (don't have the system with 2.6.23 at the moment) and
the testcase ran perfectly.
Thanks!
Nam
^ permalink raw reply
* Re: serial GDBServer PPC405 problems
From: khollan @ 2007-11-06 16:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40711020757y7591ce1eh3902f1856f254e3e@mail.gmail.com>
Grant Likely-2 wrote:
>
>
>> Do I need to add kgdb even if I just want to debug a user application
>> over
>> serial?
>
> No you don't. gdbserver is the right tool.
>
> --
>
>
So has anyone seen this problem before?
--
View this message in context: http://www.nabble.com/serial-GDBServer-PPC405--problems-tf4732593.html#a13610744
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: 2.6.24-rc1-git15 Kernel build fails on powerpc - Unrecognized opcode: `dssall'
From: Andy Whitcroft @ 2007-11-06 15:44 UTC (permalink / raw)
To: Balbir Singh
Cc: linux-kernel, Kamalesh Babulal, linuxppc-dev, johannes, sam,
David Miller
In-Reply-To: <47306E9C.4090202@linux.vnet.ibm.com>
On Tue, Nov 06, 2007 at 07:09:40PM +0530, Balbir Singh wrote:
> Kamalesh Babulal wrote:
> > David Miller wrote:
> >> From: Johannes Berg <johannes@sipsolutions.net>
> >> Date: Tue, 06 Nov 2007 11:54:46 +0100
> >>
> >>>>> CHK include/linux/compile.h
> >>>>> AS arch/powerpc/kernel/swsusp_32.o
> >>>>> arch/powerpc/kernel/swsusp_32.S: Assembler messages:
> >>>>> arch/powerpc/kernel/swsusp_32.S:138: Error: Unrecognized opcode: `dssall'
> >>>>> make[1]: *** [arch/powerpc/kernel/swsusp_32.o] Error 1
> >>>>> make: *** [arch/powerpc/kernel] Error 2
> >>>>>
> >>>> Looks suspiciously like an altivec issue. Could you compile with make
> >>>> V=1 and/or do a git bisect and see what broke?
> >>> Looks more like a toolchain issue to me.
> >> Or, this is another instance of the "CFLAGS environment variable"
> >> problem.
> >>
> >> For a few days, the kbuild stuff would integrate any CFLAGS,
> >> AFLAGS, etc. settings you might have set in your environment.
> >
> > Hi Balbir,
> >
> > The Build error of kernel compilation with V=1
> >
> > make -f scripts/Makefile.build obj=arch/powerpc/kernel
> > make -f scripts/Makefile.build obj=arch/powerpc/kernel/vdso32
> > gcc -m32 -Wp,-MD,arch/powerpc/kernel/.swsusp_32.o.d -nostdinc -isystem /usr/lib/gcc/ppc64-redhat-linux/4.1.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Iarch/powerpc -D__ASSEMBLY__ -Iarch/powerpc -Wa,-m405 -gdwarf-2 -c -o arch/powerpc/kernel/swsusp_32.o arch/powerpc/kernel/swsusp_32.S
> > arch/powerpc/kernel/swsusp_32.S: Assembler messages:
> > arch/powerpc/kernel/swsusp_32.S:138: Error: Unrecognized opcode: `dssall'
> > make[1]: *** [arch/powerpc/kernel/swsusp_32.o] Error 1
> > make: *** [arch/powerpc/kernel] Error 2
> >
>
> I looked at your .config and now your build. It looks like you select
> CONFIG_4xx (I see -Wa,-m405) and compile swsusp_32.S. The
> compiler/toolchain does not enable altivec instructions for CONFIG_4xx.
> If CONFIG_HIBERNATION is enabled as in your case, it compiles
> swsusp_32.S which assumes that ALTIVEC is enabled (see CPU_FTR_ALTIVEC).
>
> You ideally need to have -Wa,-maltivec passed in your CFLAGS.
So that sounds like a Kconfig problem then? That HIBERATION requires
ALITIVEC and yet does not depend on it or set it.
-apw
^ permalink raw reply
* Problem with PHYS_64BIT on E500 Core (2.6.23.1)
From: Morrison, Tom @ 2007-11-06 15:02 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <mailman.2202.1194358987.3099.linuxppc-dev@ozlabs.org>
I have a MPC8548E Board in which with an earlier version of=20
the kernel (2.6.11++), we customized head_e500.S and other=20
files to support the PHYS_64BIT & PTE_64BIT based upon=20
the work done for PPC64. It works very well.
I am attempting to update our kernel to the latest and have
gotten the basic system up & running (with some hacks/problems
that I won't until I am finished). We are using cuboot.85xx=20
image because our u-boot does NOT support dtb.
I noticed that the head_fsl_booke.S had the Large Physical=20
Address support, and I ported the other changes required, but
I get nowhere close to the code before the processor hangs.
I have tracked it down to where it is booting into the vmlinux
(which I assume is into the head_fsl_booke.S). We haven't=20
hooked a debugger up to this yet - but I am positive that it
isn't making out of this initialization code in the initial=20
assembly code.
The question is: Has anyone actually tried this to do this yet?
Thanks in advance for your responses!
Tom Morrison
Principal S/W Engineer
Empirix, Inc (www.empirix.com)
tmorrison@empirix.com
(781) 266 - 3567
^ permalink raw reply
* Re: problem in follow_hugetlb_page on ppc64 architecture with get_user_pages
From: Hoang-Nam Nguyen @ 2007-11-06 15:06 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-kernel, linux-ppc, Christoph Raisch, Hoang-Nam Nguyen,
general
In-Reply-To: <OF6FC435A0.F59C9AD9-ONC125738B.002A5195-C125738B.002A424A@de.ibm.com>
Hello Roland!
> We currently see this when testing Infiniband on ppc64 with ehca +
> hugetlbfs.
> From reading the code this should also be an issue on other architectures.
> Roland, Adam, are you aware of anything in this area with mellanox
> Infiniband cards or other usages with I/O adapters?
Below is a testcase demonstrating this problem. You need to install
libhugetlbfs.so and run it as below:
HUGETLB_MORECORE=yes LD_PRELOAD=libhugetlbfs.so ./hugetlb_ibtest 100
This testcase does the following steps (high level desc):
1. malloc two buffers each of 100MB for send and recv
2. register them as memory regions
3. create queue pair QP
4. send data in send buffer using QP to itself (target is then recv buffer)
5. compare those buffers content
It runs fine without libhugetlbsf. If you call it with libhugetlbfs as
above, step 5 will fail. If you do memset() of the buffers before step 2
(register mr), then it runs without errors.
It appears that hugetlb_cow() is called when first write access is performed
after mrs have been registered. That means the testcase is seeing other pages
than the ones registered to the adapter...
I was able reproduce this with mthca on 2.6.23/ppc64 and fc6/intel.
Regards
Nam
#include <stdio.h>
#include <string.h>
#include <assert.h>
#include <malloc.h>
#include <unistd.h>
#include <infiniband/verbs.h>
static unsigned int pagesize;
static unsigned int bufsize=1024*1024*19;
int cmp_data(void *s, void *d, unsigned long len, unsigned long *fail_pos)
{
unsigned char *cs = s, *cd = d;
assert(cs);
assert(cd);
assert(fail_pos);
*fail_pos = 0;
while (len) {
if (*cs < *cd)
return -1;
if (*cs > *cd)
return 1;
len--;
cs++;
cd++;
*fail_pos += 1;
}
return 0;
}
int hugetlb_ibtest(struct ibv_device* device)
{
struct ibv_context *context = NULL;
struct ibv_port_attr port_attr;
struct ibv_pd *pd = NULL;
struct ibv_cq *send_cq = NULL;
struct ibv_cq *recv_cq = NULL;
struct ibv_qp *qp = NULL;
struct ibv_mr *send_mr = NULL;
struct ibv_mr *recv_mr = NULL;
unsigned char *send_buffer = NULL;
unsigned char *recv_buffer = NULL;
int port = 1; // hardcoded for now
int rc = 0;
context = ibv_open_device(device);
assert(context!=NULL);
// query port
memset(&port_attr, 0, sizeof(port_attr));
rc = ibv_query_port(context, port, &port_attr);
assert(rc==0);
// pd
pd = ibv_alloc_pd(context);
assert(pd!=NULL);
// ah
struct ibv_ah_attr ah_attr = {
.is_global = 0,
.dlid = port_attr.lid,
.sl = 0,
.src_path_bits = 0,
.port_num = port,
.static_rate = 3
};
struct ibv_ah *ah = ibv_create_ah(pd, &ah_attr);
assert(ah!=NULL);
// send cq
send_cq = ibv_create_cq(context, 1, NULL, NULL, 0);
assert(send_cq!=NULL);
// recv cq
recv_cq = ibv_create_cq(context, 1, NULL, NULL, 0);
assert(recv_cq!=NULL);
// qp
struct ibv_qp_init_attr attr = {
.send_cq = send_cq,
.recv_cq = recv_cq,
.cap = {
.max_send_wr = 2,
.max_recv_wr = 2,
.max_send_sge = 1,
.max_recv_sge = 1
},
.qp_type = IBV_QPT_RC,
};
qp = ibv_create_qp(pd, &attr);
assert(qp!=NULL);
// qp RESET -> INIT
struct ibv_qp_attr qp_attr;
memset(&qp_attr, 0, sizeof(qp_attr));
qp_attr.qp_state = IBV_QPS_INIT;
qp_attr.pkey_index = 0;
qp_attr.port_num = port;
qp_attr.qp_access_flags = 0;
rc = ibv_modify_qp(qp, &qp_attr,
IBV_QP_STATE |
IBV_QP_PKEY_INDEX |
IBV_QP_PORT |
IBV_QP_ACCESS_FLAGS);
assert(rc==0);
// qp INIT -> RTR
memset(&qp_attr, 0, sizeof(qp_attr));
qp_attr.qp_state = IBV_QPS_RTR;
qp_attr.rq_psn = 0;
qp_attr.max_rd_atomic = 1;
qp_attr.dest_qp_num = qp->qp_num;
qp_attr.path_mtu = IBV_MTU_2048;
qp_attr.ah_attr = ah_attr;
qp_attr.min_rnr_timer = 0;
rc = ibv_modify_qp(qp, &qp_attr,
IBV_QP_STATE | IBV_QP_RQ_PSN |
IBV_QP_MAX_DEST_RD_ATOMIC |
IBV_QP_DEST_QPN | IBV_QP_PATH_MTU |
IBV_QP_AV | IBV_QP_MIN_RNR_TIMER);
assert(rc==0);
// qp RTR -> RTS
memset(&qp_attr, 0, sizeof(qp_attr));
qp_attr.qp_state = IBV_QPS_RTS;
qp_attr.sq_psn = 0;
qp_attr.max_dest_rd_atomic = 1;
qp_attr.timeout = 18;
qp_attr.retry_cnt = 1;
qp_attr.rnr_retry = 1;
rc = ibv_modify_qp(qp, &qp_attr,
IBV_QP_STATE | IBV_QP_SQ_PSN |
IBV_QP_MAX_QP_RD_ATOMIC |
IBV_QP_TIMEOUT | IBV_QP_RETRY_CNT |
IBV_QP_RNR_RETRY);
assert(rc==0);
// mr recv
recv_buffer = malloc(bufsize);
assert(recv_buffer);
unsigned int i;
recv_mr = ibv_reg_mr(pd, recv_buffer, bufsize,
IBV_ACCESS_LOCAL_WRITE);
assert(recv_mr!=NULL);
for (i = 0; i < bufsize; i++)
recv_buffer[i] = ~(i & 0xff);
// qp post_recv
rc = ibv_req_notify_cq(recv_cq, 0);
struct ibv_sge sge_recv = {
.addr = (uintptr_t) recv_buffer,
.length = bufsize,
.lkey = recv_mr->lkey
};
struct ibv_recv_wr recv_wr = {
.next = NULL,
.wr_id = 0x5003,
.sg_list = &sge_recv,
.num_sge = 1
};
struct ibv_recv_wr *bad_recv_wr = NULL;
rc = ibv_post_recv(qp, &recv_wr, &bad_recv_wr);
assert(rc==0);
// mr send
send_buffer = malloc(bufsize);
assert(send_buffer);
send_mr = ibv_reg_mr(pd, send_buffer, bufsize,
IBV_ACCESS_LOCAL_WRITE);
assert(send_mr!=NULL);
for (i = 0; i < bufsize; i++)
send_buffer[i] = (i & 0xff);
rc = ibv_req_notify_cq(send_cq, 0);
strcpy(send_buffer, "300 lines for one packet");
int slen = strlen(send_buffer);
if (bufsize > slen*2+2)
strcpy(send_buffer+bufsize-slen-1, send_buffer);
struct ibv_sge sge_send = {
.addr = (uintptr_t) send_buffer,
.length = bufsize,
.lkey = send_mr->lkey
};
struct ibv_send_wr send_wr = {
.wr_id = 0x71032,
.sg_list = &sge_send,
.num_sge = 1,
.opcode = IBV_WR_SEND,
.send_flags = IBV_SEND_SIGNALED,
};
struct ibv_send_wr *bad_send_wr = NULL;
rc = ibv_post_send(qp, &send_wr, &bad_send_wr);
assert(rc==0);
// poll send completion
struct ibv_wc wc;
int ne;
memset(&wc, 0, sizeof(wc));
do {
ne = ibv_poll_cq(send_cq, 1, &wc);
} while (ne < 1);
assert(ne==1);
assert(wc.status==IBV_WC_SUCCESS);
// poll recv completion
memset(&wc, 0, sizeof(wc));
do {
ne = ibv_poll_cq(recv_cq, 1, &wc);
} while (ne < 1);
assert(ne==1);
assert(wc.status==IBV_WC_SUCCESS);
// check what we received is what we sent
printf("send: \"%s\"\n", send_buffer);
printf("recv: \"%s\"\n", recv_buffer);
unsigned long fail_pos;
rc = cmp_data(send_buffer, recv_buffer, bufsize, &fail_pos);
if (rc) {
printf("fail_pos=%lx send_buffer=%p recv_buffer=%p "
"%02x<>%02x\n", fail_pos, send_buffer, recv_buffer,
send_buffer[fail_pos], recv_buffer[fail_pos]);
FILE *f = fopen("hugetlb_ibtest.log", "w");
fprintf(f, "fail_pos=%lx send_buffer=%p recv_buffer=%p "
"%02x<>%02x\n", fail_pos, send_buffer, recv_buffer,
send_buffer[fail_pos], recv_buffer[fail_pos]);
for (i = 0; i < bufsize; i += 16) {
unsigned int j;
fprintf(f, "%016lx %p ", (unsigned long)i, send_buffer + i);
for (j = 0; j < 16; j++)
fprintf(f, "%02x ", send_buffer[i + j]);
fprintf(f, " %p ", recv_buffer + i);
for (j = 0; j < 16; j++)
fprintf(f, "%02x ", recv_buffer[i + j]);
fprintf(f, "\n");
}
fclose(f);
printf("see log file hugetlb_ibtest.log\n");
}
// clean up
rc = ibv_dereg_mr(recv_mr);
assert(rc==0);
rc = ibv_dereg_mr(send_mr);
assert(rc==0);
rc = ibv_destroy_ah(ah);
assert(rc==0);
rc = ibv_destroy_qp(qp);
assert(rc==0);
rc = ibv_destroy_cq(send_cq);
assert(rc==0);
rc = ibv_destroy_cq(recv_cq);
assert(rc==0);
rc = ibv_dealloc_pd(pd);
assert(rc==0);
rc = ibv_close_device(context);
assert(rc==0);
return rc;
}
int main(int argc, char *argv[])
{
struct ibv_device **dev_array = ibv_get_device_list(NULL);
struct ibv_device *device = NULL;
assert(dev_array!=NULL);
device = dev_array[0]; // take first IB device
assert(device!=NULL);
pagesize = sysconf(_SC_PAGESIZE);;
printf("pagesize=0x%x\n", pagesize);
if (argc > 1) {
int l = atoi(argv[1]);
if (l)
bufsize = 1024*1024*l;
}
printf("bufsize=0x%x\n", bufsize);
int rc = hugetlb_ibtest(device);
assert(rc==0);
printf("OK!\n");
return 0;
}
^ permalink raw reply
* Re: problem in follow_hugetlb_page on ppc64 architecture with get_user_pages
From: aglitke @ 2007-11-06 15:05 UTC (permalink / raw)
To: Christoph Raisch
Cc: linux-ppc, Roland Dreier, Hoang-Nam Nguyen, linux-kernel, general
In-Reply-To: <OF6FC435A0.F59C9AD9-ONC125738B.002A5195-C125738B.002A424A@de.ibm.com>
Please try this patch and see if it helps.
commit 6decbd17d6fb70d50f6db2c348bb41d7246a67d1
Author: Adam Litke <agl@us.ibm.com>
Date: Tue Nov 6 06:59:12 2007 -0800
hugetlb: follow_hugetlb_page for write access
When calling get_user_pages(), a write flag is passed in by the caller to
indicate if write access is required on the faulted-in pages. Currently,
follow_hugetlb_page() ignores this flag and always faults pages for
read-only access.
This patch passes the write flag down to follow_hugetlb_page() and makes
sure hugetlb_fault() is called with the right write_access parameter.
Test patch only. Not Signed-off.
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 3a19b03..31fa0a0 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -19,7 +19,7 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
int hugetlb_sysctl_handler(struct ctl_table *, int, struct file *, void __user *, size_t *, loff_t *);
int hugetlb_treat_movable_handler(struct ctl_table *, int, struct file *, void __user *, size_t *, loff_t *);
int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct vm_area_struct *);
-int follow_hugetlb_page(struct mm_struct *, struct vm_area_struct *, struct page **, struct vm_area_struct **, unsigned long *, int *, int);
+int follow_hugetlb_page(struct mm_struct *, struct vm_area_struct *, struct page **, struct vm_area_struct **, unsigned long *, int *, int, int);
void unmap_hugepage_range(struct vm_area_struct *, unsigned long, unsigned long);
void __unmap_hugepage_range(struct vm_area_struct *, unsigned long, unsigned long);
int hugetlb_prefault(struct address_space *, struct vm_area_struct *);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index eab8c42..b645985 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -621,7 +621,8 @@ int hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
int follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
struct page **pages, struct vm_area_struct **vmas,
- unsigned long *position, int *length, int i)
+ unsigned long *position, int *length, int i,
+ int write)
{
unsigned long pfn_offset;
unsigned long vaddr = *position;
@@ -643,7 +644,7 @@ int follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
int ret;
spin_unlock(&mm->page_table_lock);
- ret = hugetlb_fault(mm, vma, vaddr, 0);
+ ret = hugetlb_fault(mm, vma, vaddr, write);
spin_lock(&mm->page_table_lock);
if (!(ret & VM_FAULT_ERROR))
continue;
diff --git a/mm/memory.c b/mm/memory.c
index f82b359..1bcd444 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1039,7 +1039,7 @@ int get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
if (is_vm_hugetlb_page(vma)) {
i = follow_hugetlb_page(mm, vma, pages, vmas,
- &start, &len, i);
+ &start, &len, i, write);
continue;
}
On Tue, 2007-11-06 at 08:42 +0100, Christoph Raisch wrote:
> Hello,
> if get_user_pages is used on a hugetlb vma, and there was no previous write
> to the pages,
> follow_hugetlb_page will call
> ret = hugetlb_fault(mm, vma, vaddr, 0),
> although the page should be used for write access in get_user_pages.
>
> We currently see this when testing Infiniband on ppc64 with ehca +
> hugetlbfs.
> From reading the code this should also be an issue on other architectures.
> Roland, Adam, are you aware of anything in this area with mellanox
> Infiniband cards or other usages with I/O adapters?
>
> Gruss / Regards
> Christoph R. + Nam Ng.
>
>
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
^ permalink raw reply related
* JTAG init of MPC5200B
From: lokowich @ 2007-11-06 13:30 UTC (permalink / raw)
To: linuxppc-embedded
I've been unable to properly initialize my MPC5200B from a GDB session
or OCD Commander using a OCDemon JTAG emulator unless the device is
first initialized by U-Boot. I've used same register setup as defined
in the U-Boot startup code. This prevents me from loading a RAM-based
U-Boot onto a bare board over the JTAG interface. Any guidance?
--
Mark Lokowich
Systems Engineer
Advanced Communication Design
^ permalink raw reply
* Re: [PATCH 0/3] Add device-tree aware NDFC driver
From: Valentine Barshak @ 2007-11-06 14:21 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linuxppc-dev, sr, linux-mtd
In-Reply-To: <alpine.LFD.0.9999.0711042118460.3089@localhost.localdomain>
Thomas Gleixner wrote:
> Valentine,
>> You know, you're really too tense Thomas. I'm not sure of the reason why
>> you're being a complete nerve, but I'm feeling sorry for you.
>
> You have a perception problem. I'm not tense, I'm grumpy.
:)
>
> Rest assured, that my nerves are completely fine despite of the fact
> that you try to rack them.
That's good to hear :)
>
>> I'm not saying my approach is the best, but I was hoping for a discussion.
>> I've reworked the patches according to the comments to the previous version
>> and used my arguments to explain why I don't see much reason to mess with the
>> code we currently have and added a separate _of version.
>
> This is the exact point. You were asked to fix up the existing driver
> instead of replacing it and to do it with a series of incremental
> patches. You copied the old code anyway and modified it, so we want to
> have this documented in the history. This is not my obsession, it's
> common kernel coding practise. The fact that you do not see much
> reason to do it does not change this at all.
Replacing the original driver is not my obsession either.
I just don't see the "right" way to modify the original driver to
support both platform devices and the new OF implementation. I see some
initialization order problems with the original version, and I think
that the easiest way to handle ndfc and chips attached to it would be to
do it in a single probe() function instead of having separate chip
devices and a separate ndfc platform device on top of that.
So, my opinion is that modifying the original code involves ndfc users'
modification. Considering the fact that ppc removal is scheduled for the
next summer, I thought that we could leave the original version intact
and build the new OF one.
I know the common kernel practice, but if we always followed it we'd
never bring up arch/powerpc.
BTW, I've posted some of the ndfc questions to the MTD mailing list
(http://lists.infradead.org/pipermail/linux-mtd/2007-November/019769.html).
If I had the answers I might get a more clear idea about the right way
to do it. I'd appreciate if you could take a look.
>
>> I'm sure you'd find some time to do it yourself "the right way once and
>> forever" with a "nice series of incremental patches" to fix what we currently
>> have (call it a "dump" or anything you like) and even maybe add new device
>> tree support.
>
> It might be time for you to try to understand how OSS development
> works.
I do understand how it works.
>
>> I'm sorry if for some reason I've made you feel bad.
>
> What do you expect, after you abused my Signed-off-by in a way which
> might have tricked David into pulling your code as is? This was
> pointed out to you and you did not even bother to apologize.
I apologize.
If I wanted to abuse or trick somebody and get my code in as fast as
possible no matter what, I wouldn't cc the maintainer, the other people
interested and send it to both mtd and ppc mailing lists.
I don't see any possible way for a guy who hasn't worked with the MTD
community much to trick someone and get his patches in.
>
>> This is the last time I disturb you with my e-mail, so please, forget it.
>
> Interesting. I thought you wanted to get the patch in, so you probably
> should ask yourself whether it is a good idea _not_ to talk to the
> responsible maintainer.
As I said above, I don't see the "right" way to do it. And actually I
didn't expect you to share your thoughts and reasons on how to support
both implementations and why this way is preferred. All I heard were
cursing and direct orders to stop tying to explain my reasons and do it
the "right" way. It looked like the responsible maintainer just wouldn't
listen. Why talk then?
>
> If you gave up on that, it just makes it more obvious that you do not
> want to work with the community and just wanted to dump your patch and
> move along.
I never give up ;) and I didn't say I was going to stop working with the
community.
>
> tglx
Cheers,
Valentine.
^ permalink raw reply
* Re: 2.6.24-rc1-git15 Kernel build fails on powerpc - Unrecognized opcode: `dssall'
From: Balbir Singh @ 2007-11-06 13:39 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, johannes, sam, David Miller, linux-kernel
In-Reply-To: <47304FE5.2010309@linux.vnet.ibm.com>
Kamalesh Babulal wrote:
> David Miller wrote:
>> From: Johannes Berg <johannes@sipsolutions.net>
>> Date: Tue, 06 Nov 2007 11:54:46 +0100
>>
>>>>> CHK include/linux/compile.h
>>>>> AS arch/powerpc/kernel/swsusp_32.o
>>>>> arch/powerpc/kernel/swsusp_32.S: Assembler messages:
>>>>> arch/powerpc/kernel/swsusp_32.S:138: Error: Unrecognized opcode: `dssall'
>>>>> make[1]: *** [arch/powerpc/kernel/swsusp_32.o] Error 1
>>>>> make: *** [arch/powerpc/kernel] Error 2
>>>>>
>>>> Looks suspiciously like an altivec issue. Could you compile with make
>>>> V=1 and/or do a git bisect and see what broke?
>>> Looks more like a toolchain issue to me.
>> Or, this is another instance of the "CFLAGS environment variable"
>> problem.
>>
>> For a few days, the kbuild stuff would integrate any CFLAGS,
>> AFLAGS, etc. settings you might have set in your environment.
>
> Hi Balbir,
>
> The Build error of kernel compilation with V=1
>
> make -f scripts/Makefile.build obj=arch/powerpc/kernel
> make -f scripts/Makefile.build obj=arch/powerpc/kernel/vdso32
> gcc -m32 -Wp,-MD,arch/powerpc/kernel/.swsusp_32.o.d -nostdinc -isystem /usr/lib/gcc/ppc64-redhat-linux/4.1.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Iarch/powerpc -D__ASSEMBLY__ -Iarch/powerpc -Wa,-m405 -gdwarf-2 -c -o arch/powerpc/kernel/swsusp_32.o arch/powerpc/kernel/swsusp_32.S
> arch/powerpc/kernel/swsusp_32.S: Assembler messages:
> arch/powerpc/kernel/swsusp_32.S:138: Error: Unrecognized opcode: `dssall'
> make[1]: *** [arch/powerpc/kernel/swsusp_32.o] Error 1
> make: *** [arch/powerpc/kernel] Error 2
>
I looked at your .config and now your build. It looks like you select
CONFIG_4xx (I see -Wa,-m405) and compile swsusp_32.S. The
compiler/toolchain does not enable altivec instructions for CONFIG_4xx.
If CONFIG_HIBERNATION is enabled as in your case, it compiles
swsusp_32.S which assumes that ALTIVEC is enabled (see CPU_FTR_ALTIVEC).
You ideally need to have -Wa,-maltivec passed in your CFLAGS.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: [PATCH] Replace some #includes of asm/of_platform.h with linux/of_platform.h.
From: Jon Loeliger @ 2007-11-06 13:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20071106093607.329b29f6.sfr@canb.auug.org.au>
So, like, the other day Stephen Rothwell mumbled:
>
> Hi Jon,
>
> Thanks for starting this.
No problem.
> > #include <asm/of_device.h>
>
> asm/of_device.h -> linux/of_device.h as well? :-)
Oh! Sure! I'll respin these two.
jdl
^ permalink raw reply
* Re: While booting montavista kernel for PPC sometimes Kernel Panic occurs
From: Clemens Koller @ 2007-11-06 13:05 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <13604112.post@talk.nabble.com>
Misbah khan schrieb:
> Hi all...
> Please find the print message when kernel panic occured while booting the
> Montavista kernel for PPC. This happens rarely and i am not able to find the
> real cause of it ....
> Please do suggest me how to debug it and the cause of it .
I suggest you to ask Montavista support about their kernels
or use a standard vanilla kernel.
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: [PATCH v2 05/12] [POWERPC] Export mpc52xx_map_node() routine symbol
From: Marian Balakowicz @ 2007-11-06 12:23 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071104150920.d0eac1ef.sfr@canb.auug.org.au>
Hi Stephan,
Stephen Rothwell wrote:
>
> On Sun, 04 Nov 2007 00:52:40 +0100 Marian Balakowicz <m8@semihalf.com> wrote:
>> -static void __iomem *
>> +void __iomem *
>> mpc52xx_map_node(struct device_node *ofn)
>> {
>> const u32 *regaddr_p;
>> @@ -48,6 +48,8 @@ mpc52xx_map_node(struct device_node *ofn)
>> return ioremap((u32)regaddr64, (u32)size64);
>> }
>>
>> +EXPORT_SYMBOL(mpc52xx_map_node);
>> +
>
> We generally don't leave a blank line between a function an its
> EXPORT_SYMBOL().
Will fix that.
> Also, any reason not to use EXPORT_SYMBOL_GPL?
No, no particular reason, I used EXPORT_SYMBOL because it's used for
exporting symbols in this file. But that's good point, I'll switch to
EXPORT_SYMBOL_GPL and I guess it would be nice to convert other
EXPORT_SYMBOL to EXPORT_SYMBOL_GPL as well, but that would be a
separate patch.
Cheers,
m.
^ permalink raw reply
* Re: [PATCH v2 10/12] [POWERPC] Motion-PRO: Add LED support.
From: Marian Balakowicz @ 2007-11-06 11:58 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071104152716.a38dc9f7.sfr@canb.auug.org.au>
Hi Stephen,
Stephen Rothwell wrote:
> On Sun, 04 Nov 2007 00:53:11 +0100 Marian Balakowicz <m8@semihalf.com> wrote:
>> +++ b/drivers/leds/leds-motionpro.c
[snip]
>> +#include <asm/io.h>
>> +#include <asm/of_platform.h>
>
> You want <linux/of_platform.h> instead of <asm/..> and probably not
> <linux/platform_device.h> above.
[snip]
Thanks for comments, I'll apply your suggestions for v3 respin of the
patches.
Cheers,
m.
^ permalink raw reply
* Re: 2.6.24-rc1-git15 Kernel build fails on powerpc - Unrecognized opcode: `dssall'
From: Kamalesh Babulal @ 2007-11-06 11:28 UTC (permalink / raw)
To: balbir; +Cc: linuxppc-dev, johannes, sam, David Miller, linux-kernel
In-Reply-To: <20071106.031001.189578769.davem@davemloft.net>
David Miller wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Tue, 06 Nov 2007 11:54:46 +0100
>
>>
>>>> CHK include/linux/compile.h
>>>> AS arch/powerpc/kernel/swsusp_32.o
>>>> arch/powerpc/kernel/swsusp_32.S: Assembler messages:
>>>> arch/powerpc/kernel/swsusp_32.S:138: Error: Unrecognized opcode: `dssall'
>>>> make[1]: *** [arch/powerpc/kernel/swsusp_32.o] Error 1
>>>> make: *** [arch/powerpc/kernel] Error 2
>>>>
>>> Looks suspiciously like an altivec issue. Could you compile with make
>>> V=1 and/or do a git bisect and see what broke?
>> Looks more like a toolchain issue to me.
>
> Or, this is another instance of the "CFLAGS environment variable"
> problem.
>
> For a few days, the kbuild stuff would integrate any CFLAGS,
> AFLAGS, etc. settings you might have set in your environment.
Hi Balbir,
The Build error of kernel compilation with V=1
make -f scripts/Makefile.build obj=arch/powerpc/kernel
make -f scripts/Makefile.build obj=arch/powerpc/kernel/vdso32
gcc -m32 -Wp,-MD,arch/powerpc/kernel/.swsusp_32.o.d -nostdinc -isystem /usr/lib/gcc/ppc64-redhat-linux/4.1.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Iarch/powerpc -D__ASSEMBLY__ -Iarch/powerpc -Wa,-m405 -gdwarf-2 -c -o arch/powerpc/kernel/swsusp_32.o arch/powerpc/kernel/swsusp_32.S
arch/powerpc/kernel/swsusp_32.S: Assembler messages:
arch/powerpc/kernel/swsusp_32.S:138: Error: Unrecognized opcode: `dssall'
make[1]: *** [arch/powerpc/kernel/swsusp_32.o] Error 1
make: *** [arch/powerpc/kernel] Error 2
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: 2.6.24-rc1-git15 Kernel build fails on powerpc - Unrecognized opcode: `dssall'
From: David Miller @ 2007-11-06 11:10 UTC (permalink / raw)
To: johannes; +Cc: linuxppc-dev, kamalesh, sam, linux-kernel, balbir
In-Reply-To: <1194346486.4066.13.camel@johannes.berg>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 06 Nov 2007 11:54:46 +0100
>
>
> > > CHK include/linux/compile.h
> > > AS arch/powerpc/kernel/swsusp_32.o
> > > arch/powerpc/kernel/swsusp_32.S: Assembler messages:
> > > arch/powerpc/kernel/swsusp_32.S:138: Error: Unrecognized opcode: `dssall'
> > > make[1]: *** [arch/powerpc/kernel/swsusp_32.o] Error 1
> > > make: *** [arch/powerpc/kernel] Error 2
> > >
> >
> > Looks suspiciously like an altivec issue. Could you compile with make
> > V=1 and/or do a git bisect and see what broke?
>
> Looks more like a toolchain issue to me.
Or, this is another instance of the "CFLAGS environment variable"
problem.
For a few days, the kbuild stuff would integrate any CFLAGS,
AFLAGS, etc. settings you might have set in your environment.
^ permalink raw reply
* Re: 2.6.24-rc1-git15 Kernel build fails on powerpc - Unrecognized opcode: `dssall'
From: Johannes Berg @ 2007-11-06 10:54 UTC (permalink / raw)
To: Balbir Singh; +Cc: linuxppc-dev, Sam Ravnborg, LKML, Kamalesh Babulal
In-Reply-To: <661de9470711060246s3040f68drf0a6310aeec4e1e8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
> > CHK include/linux/compile.h
> > AS arch/powerpc/kernel/swsusp_32.o
> > arch/powerpc/kernel/swsusp_32.S: Assembler messages:
> > arch/powerpc/kernel/swsusp_32.S:138: Error: Unrecognized opcode: `dssall'
> > make[1]: *** [arch/powerpc/kernel/swsusp_32.o] Error 1
> > make: *** [arch/powerpc/kernel] Error 2
> >
>
> Looks suspiciously like an altivec issue. Could you compile with make
> V=1 and/or do a git bisect and see what broke?
Looks more like a toolchain issue to me.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: 2.6.24-rc1-git15 Kernel build fails on powerpc - Unrecognized opcode: `dssall'
From: Balbir Singh @ 2007-11-06 10:46 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, Sam Ravnborg, LKML
In-Reply-To: <47304343.2010709@linux.vnet.ibm.com>
On Nov 6, 2007 4:04 PM, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi,
>
> The build fails on the power6 machine while compiling 2.6.24-rc1-git15 kernel,
> with randconfig,
>
> CHK include/linux/compile.h
> AS arch/powerpc/kernel/swsusp_32.o
> arch/powerpc/kernel/swsusp_32.S: Assembler messages:
> arch/powerpc/kernel/swsusp_32.S:138: Error: Unrecognized opcode: `dssall'
> make[1]: *** [arch/powerpc/kernel/swsusp_32.o] Error 1
> make: *** [arch/powerpc/kernel] Error 2
>
Looks suspiciously like an altivec issue. Could you compile with make
V=1 and/or do a git bisect and see what broke?
Balbir
^ permalink raw reply
* Re: what is difference between interrupt context and process context?
From: Misbah khan @ 2007-11-06 10:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <80bb1bc60711012311v772a509di616e9190d7be391a@mail.gmail.com>
Interrupt context mean that there will not be scheduling taking place untill
and unless that task ends while in the process context every task gets the
CPU time
Barisa Kisku-2 wrote:
>
> Hi,
>
> What is difference between interrupt context and process
> context.Fromhardware(register context) view
> how they are different.In linux-2.6 interrupt stack is separate from
> kernel
> stack.How interrupt stack pointer
> is retrieved?How is the implementation in freescale ppc/powerpc.
>
> please comment.
>
> thanks in advance.
>
> Barisa Kisku
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/what-is-difference-between-interrupt-context-and-process-context--tf4735753.html#a13604115
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* While booting montavista kernel for PPC sometimes Kernel Panic occurs
From: Misbah khan @ 2007-11-06 10:37 UTC (permalink / raw)
To: linuxppc-embedded
Hi all...
Please find the print message when kernel panic occured while booting the
Montavista kernel for PPC. This happens rarely and i am not able to find th=
e
real cause of it ....
Please do suggest me how to debug it and the cause of it .
=20
################################################################
Hit any key to stop autoboot: 0
## Booting image at fc000000 ...
Image Name: Linux-2.6.10_mvl401-8272ads
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1214112 Bytes =3D 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.6.10_mvl401-8272ads (root@localhost.localdomain) (gcc
version 3.4.3 (MontaVista 3.4.3-25.0.70.057
Motorola PQ2 ADS PowerPC port
Built 1 zonelists
Kernel command line: root=3D/dev/nfs rw
nfsroot=3D192.168.178.110:/home/filesys/svn/target ip=3D192.168.178.89:192.=
168f
PID hash table entries: 1024 (order: 10, 16384 bytes)
hr_time_init: arch_to_nsec =3D 83886080, nsec_to_arch =3D 107374182
Warning: real time clock seems stuck!
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 126976k available (2144k kernel code, 544k data, 156k init, 0k
highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
mpc8272ads: Init
Registering platform device 'fsl-cpm-fcc.1'. Parent at platform
Registering platform device 'fsl-cpm-fcc.2'. Parent at platform
Registering platform device 'fsl-bb-mdio.0'. Parent at platform
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xf0011a00 (irq =3D 40) is a CPM UART
ttyCPM1 at MMIO 0xf0011a60 (irq =3D 43) is a CPM UART
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
elevator: using anticipatory as default io scheduler
nbd: registered device at major 43
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=3D256).
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=3D=
xx
hda: probing with STATUS(0x50) instead of ALTSTATUS(0x0a)
hda: SanDisk SDCFB-1024, CFA DISK drive
hdb: probing with STATUS(0x50) instead of ALTSTATUS(0x0a)
hdb: probing with STATUS(0x51) instead of ALTSTATUS(0x0a)
ide0 at 0xf8000000-0xf8000007,0xf800002c on irq 5
hda: attached ide-default driver.
hda: attached ide-disk driver.
hda: max request size: 128KiB
hda: 2001888 sectors (1024 MB) w/1KiB Cache, CHS=3D1986/16/63
/dev/ide/host0/bus0/target0/lun0: p1
physmap flash device: 4000000 at fc000000
Number of erase regions: 1
Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
Primary Algorithm Table at 0040
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
No Vpp line
Typical byte/word write timeout: 128 =C2=B5s
Maximum byte/word write timeout: 1024 =C2=B5s
Typical full buffer write timeout: 128 =C2=B5s
Maximum full buffer write timeout: 4096 =C2=B5s
Typical block erase timeout: 1024 ms
Maximum block erase timeout: 16384 ms
Chip erase not supported
cfip->DevSize=3D0x1a
cfip->DevSize=3D0x19
Device size: 0x2000000 bytes (32 MiB)
Flash Device Interface description: 0x0002
- supports x8 and x16 via BYTE# with asynchronous interface
Max. bytes in buffer write: 0x20
Number of Erase Block Regions: 1
Erase Region #0: BlockSize 0x20000 bytes, 512 blocks
phys_mapped_flash: Found 2 x16 devices at 0x0 in 32-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
cfi->cfiq->DevSize=3D0x19
number of CFI chips: 1
ersize=3D0x40000
ersize=3D0x40000
ernum=3D0x100
offset=3D0x4000000
devsize=3D0x4000000
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
Using physmap partition definition
Creating 7 MTD partitions on "phys_mapped_flash":
0x00000000-0x00200000 : "Kernel 1"
0x00200000-0x00400000 : "Kernel 2"
0x00400000-0x00c00000 : "Application 1"
0x00c00000-0x01400000 : "Application 2"
0x02900000-0x03d00000 : "JFFS2 FS"
0x03f00000-0x03f40000 : "U-BOOT"
0x03f40000-0x03f80000 : "bootloader env"
fip->fc_clockmask 0x0ff000000
fip->fc_clockroute 0x02e000000
The immap->im_cpmux.cmx_fcr value is 2e000000
The immap->im_cpmux.cmx_fcr value is 2e000000
eth0: FCC ENET Version for Cashel Board, 00:90:45:e0:ab:dc
fip->fc_clockmask 0x0ff0000
fip->fc_clockroute 0x02c0000
The immap->im_cpmux.cmx_fcr value is 2e2c0000
The immap->im_cpmux.cmx_fcr value is 2e2c0000
eth1: FCC ENET Version for Cashel Board, 00:90:45:60:ab:dc
NET: Registered protocol family 2
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C0173540 LR: C015CB58 SP: C7C29DD0 REGS: c7c29d20 TRAP: 0300 Not
tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000004, DSISR: 20000000
TASK =3D c7c10ab0[1] 'swapper' THREAD: c7c28000
Last syscall: 120
GPR00: 00000001 C7C29DD0 C7C10AB0 C7C275C0 C7C92000 C026D8D4 C7EB0C15
C02A4598
GPR08: 0000001E C02B993C C7C28000 00000000 07C10C80 1001A108 07FFD000
00000000
GPR16: 00000001 00000001 FFFFFFFF 007FFF00 07FF87E4 00000000 00000002
07BC5680
GPR24: C0270000 FFFB78A9 C02B9708 C7C92000 C02A0000 C7C275C0 C7C275C0
C7C275C0
Call backtrace: c015cb58 c015cc74 c015cdf8 c001a020 c001a0e8 c001a18c=
=20
c001a258 c00054e0 c000469c c0299f
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
################################################################
Hoping for a reply from your side soon=20
-----Misbah <><
--=20
View this message in context: http://www.nabble.com/While-booting-montavist=
a-kernel-for-PPC-sometimes-Kernel-Panic-occurs-tf4757236.html#a13604112
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ 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