* Re: Frustrated question with insmod
From: Wolfgang Grandegger @ 2008-02-20 14:04 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
In-Reply-To: <OF5B1D6538.27F4BDEE-ON882573F4.0000830F-882573F4.0001FF46@selinc.com>
Bruce_Leonard@selinc.com wrote:
>> Bruce_Leonard@selinc.com wrote:
>>> Sorry if this is the wrong place to post this question. I'm
> developing a
>>> NAND flash driver and I need to do some detailed dubugging using GDB
> with
>>> a BDI2K. According to the Denx web site, to find out the address that
> the
>>> module is loading at you load it using the -m parameter to insmod
> (i.e.,
>>> "insmod -m mymodule"). However, every version of insmod I've tried
>>> doesn't recognize ANY options much less -m. Can anyone please point
> me in
>>> the right direction, or give me another way of knowing what the load
>>> address of my module is?
>> # cat /sys/module/<name>/sections/.text
>>
>> Do not forget to enable CONFIG_KALLSYMS.
>>
>
> Well, okay I guess the address I'm getting is the right one because both
> the above cat and 'cat /proc/modules' gives me the same thing, 0xe1188000.
> I've got CONFIG_KALLSYMS and CONFIG_KALLSYMS_ALL set, though
> CONFIG_KALLSYMS_EXTRA_PASS is not set, don't know if that makes a
> difference.
>
> So it would seem that there's something wrong with my BDI setup that isn't
> allowing address translation in the kernel's dynamically allocated memory
> area. I've got PTBASE set to 0xf0 in the BDI config file so it should be
> finding the virtual address of the page tables just fine. I've also got
> CONFIG_BDI_SWITCH set in .config and I know that works with the BDI,
> because I can set breakpoints at places in the kernel code that are called
> by my module (like nand_scan_ident() ) and everything works just fine.
> It's just when I try to access memory in the dynamic area where my module
> is located that the BDI can't do an address translation. At least I
> assume it's the BDI, because I can load the module and use it with out
> GDB/BDI, so the processor and kernel must be able to handle the addresses
> okay. Can anyone think of where I should go dig? I've had this working
> exactly once in the past, but I don't know what I've changed to cause it
> to stop working.
Try to specify the addresses of the other sections listed by "cat
/sys/module/my-mod/sections/:
add-symbol-file my-mod.o 0xcf030060\
-s .rodata 0xcf030354\
-s .data 0xcf030488\
-s .sdata 0xcf030488\
-s .bss 0xcf030519\
-s .sbss 0xcf03051c
Wolfgang.
^ permalink raw reply
* Re: mpc8548amc vs mpc8548cds
From: Jon Loeliger @ 2008-02-20 14:41 UTC (permalink / raw)
To: maxime louvel; +Cc: linuxppc-embedded
In-Reply-To: <dda529d0802200601t2db82c67o808c8407215396c@mail.gmail.com>
maxime louvel wrote:
> Hi,
>
> first of all I am sorry if this is not the good place to ask that but I
> don't know where else ...
> My question is:
>
> Does anyone knows the difference between the mpc8548amc and mpc8548cds
> platforms ?
Sorry, no knowledge of the AMC board here.
> I am working on an amc one but the 2.6.24 kernel is supporting only the
> cds one.
> Do you know if I can use the dts file form the mpc8548cds for the
> mpc8548amc ?
They will be similar, but I doubt you can use it directly.
jdl
^ permalink raw reply
* initramfs problem - /init file
From: raul.moreno @ 2008-02-20 14:44 UTC (permalink / raw)
To: linuxppc-embedded
Hello everybody,
I created a tiny root filesystem, just with Busybox, that I want to use=
as
rootfs through initramfs (and keep it as the final root filesystem).
First of all, I probed this root filesystem using NFS to be sure it wor=
ked
and in fact, it did. Then I created an init file which is a link to
/sbin/init and I inserted the created cpio file with this filesystem in=
CONFIG_INITRAMFS_SOURCE. When I boot the system up, I get the following=
error:
Failed to execute /init
Kernel panic - not syncing: No init found. Try passing init=3D option =
to
kernel.
If I also tried with an init script instead to a link to /sbin/init, bu=
t
this error happens again.
I think the kernel finds the initramfs right, because if I don't add th=
e
init file, I get a different error:
VFS: Cannot open root device "<NULL>" or unknown-block(0,0)
Please append a correct "root=3D" boot option;
What is the problem with "init"?
Could anyone help me? Thanks in advance,
Ra=FAl Moreno
***********Internet Email Confidentiality Footer*************
This email and any files transmitted with it are confidential and inten=
ded
solely for the use of the organization or individual to whom they are
addressed. It is expressly forbidden to retransmit or copy email and/o=
r
this attached files without our permission . If you are not the
addressee indicated in this message (or responsible for delivery of the=
message to such person), you may not copy or deliver this message
to anyone. In such case, you should destroy this message and kindly
notify the sender by reply email. Please advise immediately if you or
your employer does not consent to Internet email for messages of this
kind. Opinions, conclusions and other information in this message that=
do not relate to the official business of my firm shall be understood a=
s
neither given nor endorsed by it.=
^ permalink raw reply
* [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
From: Kamalesh Babulal @ 2008-02-20 15:01 UTC (permalink / raw)
To: kernel list, linux-next, linuxppc-dev, paulus, Andrew Morton,
Andy Whitcroft, Balbir Singh
Hi,
The Kernel oopses is seen while running the kernbench followed by tbench with 2.6.25-rc2-git4
kernel on powerpc, this oops was reported for the 2.6.24-rc8-mm1 kernel (http://lkml.org/lkml/2008/1/18/71)
and is visible with almost all of the main line ,rc(s) and their git(s) release from then.
This oops is visible in the linux-next-20080220 kernel also.The machine is power4+ box with four cpus and
has 30 GB RAM.
oops while running kernbench
-----------------------------
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 NUMA pSeries
Modules linked in:
NIP: 0000000000004570 LR: 000000000ff0135c CTR: 000000000ff012f0
REGS: c000000771a678c0 TRAP: 0300 Not tainted (2.6.25-rc2-autotest-next-20080220)
MSR: 8000000000001000 <ME> CR: 28000282 XER: 00000000
DAR: c000000771a67ce0, DSISR: 000000000a000000
TASK = c00000077b9d2c00[22046] 'cc1' THREAD: c000000771a64000 CPU: 3
GPR00: 0000000000004000 c000000771a67b40 0000000000000052 000000000000d032
GPR04: 0000000000000052 0000000000000400 00000000106823e0 000000000000000e
GPR08: 0000000000000000 0000000044000288 c000000771a67e30 0000998be2321500
GPR12: 8000000000001030 c0000000005d7e00 0000000010030000 0000000010030000
GPR16: 00000000105b0000 00000000105b0000 0000000010440000 00000000105b0000
GPR20: 00000000105b0000 00000000105b0000 00000000105b0000 00000000105b0000
GPR24: 00000000105b41e8 0000000000000020 00000000105b0000 0000000000000400
GPR28: 000000000ffec408 00000000f7ff8000 000000000ffebff4 0000000000000400
NIP [0000000000004570] 0x4570
LR [000000000ff0135c] 0xff0135c
Call Trace:
[c000000771a67b40] [c00000000062d558] 0xc00000000062d558 (unreliable)
[c000000771a67e08] [00000000f7ff8000] 0xf7ff8000
Instruction dump:
48000000 XXXXXXXX XXXXXXXX XXXXXXXX 41820008 XXXXXXXX XXXXXXXX XXXXXXXX
48000010 XXXXXXXX XXXXXXXX XXXXXXXX f92101a0 XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 26a7439b76b3cbab ]---
oops while running tbench
--------------------------
Unable to handle kernel paging request for data at address 0xc00000077e2e3ce0
Faulting instruction address: 0x00004570
Oops: Kernel access of bad area, sig: 11 [#2]
SMP NR_CPUS=32 NUMA pSeries
Modules linked in:
NIP: 0000000000004570 LR: c00000000000872c CTR: 0000000000000000
REGS: c00000077e2e38c0 TRAP: 0300 Tainted: G D (2.6.25-rc2-autotest-next-20080220)
MSR: 8000000000001000 <ME> CR: 28022822 XER: 20000000
DAR: c00000077e2e3ce0, DSISR: 000000000a000000
TASK = c00000077cb55800[3900] 'zmd' THREAD: c00000077e2e0000 CPU: 3
GPR00: 0000000000000000 c00000077e2e3b40 c0000000006a29b8 000000000000006e
GPR04: 000000000fe7bac8 0000000054022888 0000000000004000 000000000fe7bae4
GPR08: 000000000000d032 0000000044022824 c00000077e2e3e30 0000998be2321500
GPR12: 8000000000001030 c0000000005d7e00 0000000000000001 0000000000000000
GPR16: 0000000000000000 00000000f7c16708 00000000f7fa0800 00000000100e0040
GPR20: 00000000f7ffe018 0000000000000001 00000000f5397550 00000000f5397548
GPR24: 0000000000000000 0000000000004a19 00000000f7d66474 00000000f53975a8
GPR28: 0000000000000000 0000000000009433 000000000fe94ff4 00000000f7d66490
NIP [0000000000004570] 0x4570
LR [c00000000000872c] syscall_exit+0x0/0x40
Call Trace:
[c00000077e2e3b40] [00000496000729b8] 0x496000729b8 (unreliable)
Instruction dump:
48000000 XXXXXXXX XXXXXXXX XXXXXXXX 41820008 XXXXXXXX XXXXXXXX XXXXXXXX
48000010 XXXXXXXX XXXXXXXX XXXXXXXX f92101a0 XXXXXXXX XXXXXXXX XXXXXXXX
The machine
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* ELDK on 64-bit host
From: Kalle Pokki @ 2008-02-20 15:03 UTC (permalink / raw)
To: linuxppc-embedded, wd
Hi,
I tried to copy the ELDK 4.0 installation I had to a new Core 2 Quad
machine running 64-bit Ubuntu 7.10, but the new machine refuses to
execute the cross compiler. Has anyone succeeded in running ELDK in
this kind of environment?
I also tried compiling the ELDK from source RPMs as described in the
documentation, but at least some of the RPMs the scripts try to
download are no longer available on the net, and the build environment
described doesn't seem to quite match the one on the source rpm ISO
image.
^ permalink raw reply
* Re: Sample driver
From: Jeff Mock @ 2008-02-20 15:13 UTC (permalink / raw)
To: Josh Boyer, linuxppc-embedded; +Cc: Silwer star
In-Reply-To: <20080220060653.7593ffa9@zod.rchland.ibm.com>
Josh Boyer wrote:
>> Does anyone have sample drivers in Linux for the EBC interface for PPC405Ex?
>> I would be thankful if someone could put in a sample code here.
>
> Linux typically doesn't touch the EBC itself. That is normally set up
> by firmware such as U-Boot and Linux uses it as-is.
>
True, but there's always a lot of ways to do it. Here's an example that
might help you get started configuring the EBC from Linux. Here's a
device driver directory from a recent 440GX project:
http://www.mock.com/wsvn/listing.php?repname=mock.pdev&path=%2Ftrunk%2Fsw%2Fdriver%2F#_trunk_sw_driver_
You might look at pdev-gxctl.c. It is a simple module that sets up the
EBC address space for two sets of address ranges with 16-bit data paths.
These are for simple register read/writes to control some FPGAs.
Pdev-gxctl provides an mmap() interface to /dev/xxx so user code can
easily access the FPGA registers mapped onto the EBC. The difference
for the 405Ex should be pretty small.
jeff
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Clemens Koller @ 2008-02-20 15:43 UTC (permalink / raw)
To: linux-fbdev-devel
Cc: adaplas, linux-kernel, linuxppc-dev, Geert Uytterhoeven,
Andrew Morton
In-Reply-To: <18363.31427.989835.105966@cargo.ozlabs.ibm.com>
Paul Mackerras schrieb:
> Andrew Morton writes:
>
>> Bizarrely, the original author of the patch (Anton) has fallen off the cc.
>> Could whoever did that please thwap himself?
>>
>> Anyway, my head is now officially spinning. Did anyone actually have a
>> reason why we shouldn't proceed with Anton's patch?
>
> I was wondering if it would be sufficient to provide alternative
> versions of fb_readl, fb_writel etc. that do byte-swapping. That
> would mean that all framebuffers would have to have the same
> endianness, but that would suffice for embedded systems such as
> Anton's and would end up a lot simpler IMHO.
Yes. At least the affected PowerPC platforms can do byte-swapping on
the fly, so this should be sufficient and without performance
penalty, AFAICS.
Regards,
Clemens
^ permalink raw reply
* Re: ELDK on 64-bit host
From: Ben Warren @ 2008-02-20 15:49 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <a425f86c0802200703x6cbbd5acwa4b3a8dda455eeea@mail.gmail.com>
On Wed, Feb 20, 2008 at 10:03 AM, Kalle Pokki <kalle.pokki@eke.fi> wrote:
> Hi,
>
> I tried to copy the ELDK 4.0 installation I had to a new Core 2 Quad
> machine running 64-bit Ubuntu 7.10, but the new machine refuses to
> execute the cross compiler. Has anyone succeeded in running ELDK in
> this kind of environment?
>
Yes (at least with 64-bit Debian on a single core Xeon), but you need
a special library on the host. I think it's call 'ia32-libs'. It
should be available via aptitude.
regards,
Ben
^ permalink raw reply
* state of GEN_RTC vs rtc subsystem
From: Kumar Gala @ 2008-02-20 16:11 UTC (permalink / raw)
To: a.zummo; +Cc: linuxppc-dev list, rz, LKML Kernel, rtc-linux
Is the functionality provided by drivers/char/gen_rtc.c completely
handled by the rtc subsystem in drivers/rtc?
I ask for two reasons:
1. should we make it mutually exclusive in Kconfig
2. I've enabled both and get (we'll my defconfig did):
proc_dir_entry 'rtc' already registered
Call Trace:
[df82bd70] [c0006b8c] show_stack+0x3c/0x1b0 (unreliable)
[df82bda0] [c00cda48] proc_register+0xf8/0x1a0
[df82bdd0] [c00cdc44] create_proc_entry+0x64/0xf0
[df82bdf0] [c024a484] rtc_proc_add_device+0x54/0x90
[df82be00] [c0249048] rtc_device_register+0x1d8/0x220
[df82be40] [c046c0bc] cmos_platform_probe+0x13c/0x3c0
[df82be70] [c01cd524] platform_drv_probe+0x24/0x40
[df82be80] [c01cb15c] driver_probe_device+0xbc/0x200
[df82bea0] [c01cb4ac] __driver_attach+0xcc/0x100
[df82bec0] [c01ca0dc] bus_for_each_dev+0x5c/0xa0
[df82bef0] [c01caf44] driver_attach+0x24/0x40
[df82bf00] [c01cad70] bus_add_driver+0x1f0/0x270
[df82bf20] [c01cb778] driver_register+0x48/0x140
[df82bf40] [c01cd948] platform_driver_register+0x98/0xb0
[df82bf50] [c01cd97c] platform_driver_probe+0x1c/0x90
[df82bf60] [c046bf70] cmos_init+0x20/0x30
[df82bf70] [c0450218] kernel_init+0xa8/0x2b0
[df82bff0] [c000e638] kernel_thread+0x44/0x60
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
- k
^ permalink raw reply
* Re: MPC8641D PCI-Express error
From: Marco Stornelli @ 2008-02-20 16:13 UTC (permalink / raw)
To: LinuxPPC-Embedded
Kumar Gala wrote:
>> Marco Stornelli wrote:
>>
>>> No, but I can try to backport the PCI-E code from 2.6.24 to 2.6.18
>>> if it could help. What do you think about it? Do you think this
>>> problem could be not present in 2.6.24?
>>> I have no idea there, honestly. Sorry.
>As Jon said, try 2.6.24 and see if it has an issue, if so we can look
>at helping. if not, you know you need to back port the fixes.
>- k
I've "backported" the PCI-Express code from 2.6.24 to 2.6.18, but it
still doesn't work, I have the same problem (sigh), could you give me
any suggestions?
Thanks.
Marco
^ permalink raw reply
* Re: [patch v8 1/4] USB: add Cypress c67x00 low level interface code
From: Greg KH @ 2008-02-20 16:13 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell, stern, linux-usb
In-Reply-To: <20080220091400.882581000@sunsite.dk>
On Wed, Feb 20, 2008 at 10:07:28AM +0100, Peter Korsgaard wrote:
> This patch adds the low level support code for the Cypress c67x00 family of
> OTG controllers. The low level code is responsible for register access and
> implements the software protocol for communicating with the 16bit
> microcontroller inside the c67x00 device.
>
> Communication is done over the HPI interface (16bit SRAM-like parallel bus).
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> Acked-by: David Brownell <dbrownell@users.sourceforge.net>
> ---
> drivers/usb/c67x00/c67x00-ll-hpi.c | 405 +++++++++++++++++++++++++++++++++++++
> drivers/usb/c67x00/c67x00.h | 285 ++++++++++++++++++++++++++
Why not drivers/usb/hcd/c67x00/ instead?
thanks,
greg k-h
^ permalink raw reply
* Re: [patch v8 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: Greg KH @ 2008-02-20 16:14 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell, stern, linux-usb
In-Reply-To: <20080220090727.904160000@sunsite.dk>
On Wed, Feb 20, 2008 at 10:07:27AM +0100, Peter Korsgaard wrote:
> The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
> USB controllers. This patch series implements a HCD driver and shows the
> work-in-progress status of a gadget driver.
>
> I believe patch 1..3 are ready, and I would like to see them queued up for
> mainline.
>
> Changes since v7:
> - Moved dummy hcd probe/remove functions for conditional hcd support into
> udc patch.
> - Moved usb_disabled() check into c67x00_hcd_probe().
> - Moved c67x00_get_comm_reg() to udc patch as it is only needed for gadget
> support.
So this fixes the build errors/warnings I sent you?
Can you run them through scripts/checkpatch.pl to ensure that those
warnings are also fixed?
thanks,
greg k-h
^ permalink raw reply
* Re: [patch v7 3/4] USB: add Cypress c67x00 OTG controller HCD driver
From: Greg KH @ 2008-02-20 16:16 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell, stern, linux-usb
In-Reply-To: <87bq6cf1cb.fsf@macbook.be.48ers.dk>
On Wed, Feb 20, 2008 at 10:01:40AM +0100, Peter Korsgaard wrote:
> >>>>> "Greg" == Greg KH <greg@kroah.com> writes:
>
> Greg> On Tue, Feb 19, 2008 at 04:09:19PM +0100, Peter Korsgaard wrote:
> >> This patch adds HCD support for the Cypress c67x00 family of devices.
> >>
> >> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>
> Greg> And it doesn't build:
>
> Greg> CC [M] drivers/usb/c67x00/c67x00-hcd.o
> Greg> distcc[2413] ERROR: compile /home/gregkh/.ccache/c67x00-hcd.tmp.mini.2409.i on localhost failed
> Greg> drivers/usb/c67x00/c67x00-hcd.c:345: error: redefinition of 'c67x00_hcd_probe'
> Greg> drivers/usb/c67x00/c67x00-hcd.h:119: error: previous definition of 'c67x00_hcd_probe' was here
> Greg> drivers/usb/c67x00/c67x00-hcd.c:402: error: redefinition of 'c67x00_hcd_remove'
> Greg> drivers/usb/c67x00/c67x00-hcd.h:126: error: previous definition of 'c67x00_hcd_remove' was here
> Greg> make[2]: *** [drivers/usb/c67x00/c67x00-hcd.o] Error 1
> Greg> make[1]: *** [drivers/usb/c67x00] Error 2
> Greg> make: *** [_module_drivers/usb] Error 2
>
> Huh, that doesn't make any sense to me. The dumy definitions of
> c67x00_hcd_{probe,remove} are protected by an ifndef
> CONFIG_USB_C67X00_HCD, and c67x00-hcd.c which contains the real
> definitions only gets compiled if CONFIG_USB_C67X00_HCD is
> enabled. Could you perhaps provide some more details?
I don't know, I selected the config option, and yet, it built as if it
wasn't set.
> Anyway, the conditional hcd stuff isn't really needed at this point in
> the patch series, so I have moved it into patch 4 in the v8 series
> I'll post in a minute.
That's good.
> Greg> This is _after_ removing the obviously incorrect usb_disabled()
> Greg> function that you included in your .h file.
>
> That was again for conditional hcd/udc support. I have now moved the
> check into _hcd_probe() instead.
>
> Greg> I'm going to hold off applying any of these for now, as it
> Greg> doesn't look like something is configured properly here.
>
> Could you give the v8 series a try please?
Can you move the files under the hcd/ subdir, run it through
checkpatch.pl and fix up the __FUNCTION__ warnings, and then I'll be
willing to test it again :)
thanks,
greg k-h
^ permalink raw reply
* Problems with plb_temac+hard_temac+2.6.24rc3
From: A. Nolson @ 2008-02-20 16:33 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am working with a ML403 platform and I have my kernel 2.6.24rc3
perfectly running on it. Almost everything seems to work but the
ethernet. I am using the IP cores that come with the EDK 9.1sp2 (
plb_emac 3.00a + hard_temac 3.00b). The weird thing arises when I try to
bring up the interface and use it. If I do "ifconfig eth0 up" the
interface shows up but, strangely, it eithers not receives or send
packets. I will explain myself, if I assing an IP manually and try to
connect to another worksatation within the network ( by pinging from
just one of the sides for example ) the interface seems only to send or
receive packets , but generallty not both at the same time ( I can see
this through the evolution of the Rx/Tx bytes in ifconfig). The only few
times that both tx/rx work at the same time is when I do (ifconfig eth0
down and ifconfig eth0 up), but this only works sporadically and only
for around a second or less.
This is what I get after the first "ifconfig eth0 up":
[ 293.258765] eth0: XTemac: Options: 0xb8f2
[ 295.253048] eth0: XTemac: speed set to 10Mb/s
[ 295.256042] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
[ 295.256095] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
[ 297.252047] eth0: XTemac: PHY Link carrier lost.
[ 299.251657] eth0: XTemac: PHY Link carrier restored.
and this after some ifconfig up/down:
[ 293.258765] eth0: XTemac: Options: 0xb8f2
[ 295.253048] eth0: XTemac: speed set to 10Mb/s
[ 295.256042] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
[ 295.256095] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
[ 297.252047] eth0: XTemac: PHY Link carrier lost.
[ 299.251657] eth0: XTemac: PHY Link carrier restored.
[ 438.159833] eth0: XTemac: Options: 0xb8f2
[ 440.154122] eth0: XTemac: speed set to 1000Mb/s
[ 440.157316] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
[ 440.157369] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
[ 442.153739] eth0: XTemac: PHY Link carrier lost.
[ 511.255518] eth0: XTemac: Options: 0xb8f2
[ 513.249808] eth0: XTemac: speed set to 10Mb/s
[ 513.252729] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
[ 513.252784] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
[ 515.249462] eth0: XTemac: PHY Link carrier restored.
[ 992.441619] eth0: XTemac: Options: 0xb8f2
[ 994.435904] eth0: XTemac: speed set to 1000Mb/s
[ 994.438786] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
[ 994.438839] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
[ 996.435460] eth0: XTemac: PHY Link carrier lost.
[ 1099.850622] eth0: XTemac: Options: 0xb8f2
[ 1101.844907] eth0: XTemac: speed set to 10Mb/s
[ 1101.847816] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
[ 1101.847868] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
[ 1103.844479] eth0: XTemac: PHY Link carrier restored.
[ 1180.024979] eth0: XTemac: Options: 0xb8f2
[ 1182.019263] eth0: XTemac: speed set to 1000Mb/s
[ 1182.022265] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
[ 1182.022316] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
[ 1184.018815] eth0: XTemac: PHY Link carrier lost.
It also seems to negotiate wrongly the speed since my network is 100Mb/s.
This is my dmesg before "ifconfig eth0 up":
[ 0.000000] Linux version 2.6.24-rc3-gd7ed933b-dirty (ios@xxx) (gcc
versio
ion 4.0.0 (DENX ELDK 4.1 4.0.0)) #17 Mon Feb 18 11:52:47 CET
2008 [
[ 0.000000] Xilinx ML403 Reference System (Virtex-4
FX) [
[ 0.000000] Entering add_active_range(0, 0, 16384) 0 entries of 256
used [
[ 0.000000] Zone PFN
ranges: [
[ 0.000000] DMA 0 ->
16384 [
[ 0.000000] Normal 16384 ->
16384 [
[ 0.000000] HighMem 16384 ->
16384 [
[ 0.000000] Movable zone start PFN for each
node [
[ 0.000000] early_node_map[1] active PFN
ranges [
[ 0.000000] 0: 0 ->
16384 [
[ 0.000000] On node 0 totalpages:
16384 [
[ 0.000000] DMA zone: 128 pages used for
memmap [
[ 0.000000] DMA zone: 0 pages
reserved [
[ 0.000000] DMA zone: 16256 pages, LIFO
batch:3 [
[ 0.000000] Normal zone: 0 pages used for
memmap [
[ 0.000000] HighMem zone: 0 pages used for
memmap [
[ 0.000000] Movable zone: 0 pages used for
memmap [
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages
es:
16256
[
[ 0.000000] Kernel command line: console=ttyS0,57600 root=/dev/xsa2
rw init=/sb
sbin/init
[
[ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to
0xFDFFE000 [
[ 0.000000] PID hash table entries: 256 (order: 8, 1024
bytes) [
[ 0.000189] Console: colour dummy device
80x25 [
[ 0.000632] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes) [
[ 0.001411] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes) [
[ 0.015628] Memory: 61312k available (2744k kernel code, 780k data,
116k init,
, 0k
highmem)
[
[ 0.015942] SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4,
CPUs=1, Nod
odes=1
[
[ 0.015988] Calibrating delay loop... 199.47 BogoMIPS
(lpj=997376) [
[ 0.210274] Mount-cache hash table entries:
512 [
[ 0.214569] net_namespace: 64
bytes [
[ 0.220610] NET: Registered protocol family
16 [
[ 0.268325] NET: Registered protocol family
2 [
[ 0.350699] IP route cache hash table entries: 1024 (order: 0, 4096
bytes) [
[ 0.353529] TCP established hash table entries: 2048 (order: 2, 16384
bytes) [
[ 0.353862] TCP bind hash table entries: 2048 (order: 1, 8192
bytes) [
[ 0.354067] TCP: Hash tables configured (established 2048 bind
2048) [
[ 0.354107] TCP reno
registered [
[ 0.381445] sysctl table check failed: /kernel/l2cr .1.31 Missing
strategy [
[ 0.381529] Call
Trace: [
[ 0.381556] [c3c11e80] [c0008380] show_stack+0x4c/0x174
(unreliable) [
[ 0.381653] [c3c11eb0] [c0037170]
set_fail+0x50/0x68 [
[ 0.381735] [c3c11ed0] [c00377f8]
sysctl_check_table+0x670/0x6bc [
[ 0.381804] [c3c11f10] [c003780c]
sysctl_check_table+0x684/0x6bc [
[ 0.381871] [c3c11f50] [c0024e7c]
register_sysctl_table+0x5c/0xac [
[ 0.381953] [c3c11f70] [c034ab68]
register_ppc_htab_sysctl+0x18/0x2c [
[ 0.382040] [c3c11f80] [c034484c]
kernel_init+0xc8/0x284 [
[ 0.382103] [c3c11ff0] [c0004b18]
kernel_thread+0x44/0x60 [
[ 0.442249] Installing knfsd (copyright (C) 1996
okir@monad.swb.de). [
[ 0.447391] JFS: nTxBlock = 479, nTxLock =
3832 [
[ 0.450534] SGI XFS with ACLs, large block numbers, no debug
enabled [
[ 0.466636] io scheduler noop
registered [
[ 0.466687] io scheduler anticipatory
registered [
[ 0.466722] io scheduler deadline
registered [
[ 0.467224] io scheduler cfq registered
(default) [
[ 1.069672] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
sharing di
disabled
[
[ 1.078357] serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 3) is a
16550A [
[ 1.078443] console [ttyS0]
enabled [
[ 1.621990] RAMDISK driver initialized: 16 RAM disks of 4096K size
1024 blocksi
size
[
[ 1.644429] loop: module
loaded [
[ 1.651930] xsysace xsysace.0: Xilinx SystemACE revision
1.0.12 [
[ 1.664582] xsysace xsysace.0: capacity: 1019088
sectors [
[ 1.675836] xsa: xsa1 xsa2
xsa3 [
[ 1.688906] Xilinx SystemACE device driver,
major=254 [
[ 1.700197] nbd: registered device at major
43 [
[ 1.728380] XTemac: using sgDMA
mode. [
[ 1.735840] XTemac: using TxDRE
mode [
[ 1.743198] XTemac: using RxDRE
mode [
[ 1.750455] XTemac: buffer descriptor size: 32768
(0x8000) [
[ 1.762007] XTemac: (buffer_descriptor_init) phy: 0x3d98000, virt:
0xff100000,
, size:
0x8000 [
[ 1.785641] eth%d: XTemac: No PHY detected. Assuming a PHY at
address 0 [
[ 1.799277] eth0: Dropping NETIF_F_SG since no checksum
feature. [
[ 1.814696] eth0: Xilinx TEMAC #0 at 0x81200000 mapped to 0xC5060000,
irq=0 [
[ 1.828792] eth0: XTemac id 1.0f, block id 5, type
8 [
[ 1.840200] NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c
$Revision: 1
1.41
$ [
[ 1.856295] INFTL: inftlcore.c $Revision: 1.19 $, inftlmount.c
$Revision: 1.18
8
$
[
[ 1.872015] SSFDC read-only Flash Translation
layer [
[ 1.885404] i8042.c: No controller
found. [
[ 1.895700] mice: PS/2 mouse device common for all
mice [
[ 1.908819] i2c /dev entries
driver [
[ 1.917372] TCP cubic
registered [
[ 1.924238] NET: Registered protocol family
1 [
[ 1.933271] NET: Registered protocol family
17 [
[ 1.944649] RPC: Registered udp transport
module. [
[ 1.954206] RPC: Registered tcp transport
module. [
[ 4.575003] kjournald starting. Commit interval 5
seconds [
[ 4.586220] EXT3-fs warning: maximal mount count reached, running
e2fsck is rec
ecommended
[
[ 4.641727] EXT3 FS on xsa2, internal
journal [
[ 4.650587] EXT3-fs: recovery
complete. [
[ 4.697624] EXT3-fs: mounted filesystem with ordered data
mode. [
[ 4.709702] VFS: Mounted root (ext3
filesystem). [
[ 4.719390] Freeing unused kernel memory: 116k
init
ba
Any idea of what it can be?
Thanks in advance!
/A
^ permalink raw reply
* Re: [PATCH] powerpc: don't create two devices for each cpm_uart device tree node
From: Scott Wood @ 2008-02-20 16:40 UTC (permalink / raw)
To: Nikita V. Youshchenko; +Cc: linuxppc-dev
In-Reply-To: <200802200232.44486@blacky.localdomain>
On Wed, Feb 20, 2008 at 02:32:33AM +0300, Nikita V. Youshchenko wrote:
>
> powerpc: don't create two devices for each cpm_uart device tree node
>
> Code in arch/powerpc/sysdev/fsl_soc.c used to create two 'struct device'
> objects for each cpm_uart device tree node - one "fsl-cpm-scc:uart"
> in cpm_uart_of_init() and one "fsl-cpm-smc:uart" in cpm_smc_uart_of_init().
This is old code that only exists for non-CONFIG_PPC_CPM_NEW_BINDING
boards. As there are none of these remaining in-tree, this code should
go away soon.
-Scott
^ permalink raw reply
* Re: [PATCH] ehea: add kdump support
From: Jeff Garzik @ 2008-02-20 16:50 UTC (permalink / raw)
To: Thomas Klein
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
In-Reply-To: <47B30A49.8080404@de.ibm.com>
Thomas Klein wrote:
> This patch adds kdump support to the ehea driver. As the firmware doesn't free
> resource handles automatically, the driver has to run an as simple as possible
> free resource function in case of a crash shutdown. The function iterates over
> two arrays freeing all resource handles which are stored there. The arrays are
> kept up-to-date during normal runtime. The crash handler fn is triggered by the
> recently introduced PPC crash shutdown reg/unreg functions.
>
>
> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
>
> ---
> drivers/net/ehea/ehea.h | 34 +++++-
> drivers/net/ehea/ehea_main.c | 281 ++++++++++++++++++++++++++++++++++++++----
> 2 files changed, 290 insertions(+), 25 deletions(-)
applied
^ permalink raw reply
* Re: [PATCH] fs_enet: Don't call phy_mii_ioctl() in atomic context.
From: Jeff Garzik @ 2008-02-20 16:50 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, linuxppc-dev
In-Reply-To: <20080215210804.GA14468@loki.buserror.net>
Scott Wood wrote:
> The lock acquisition in fs_ioctl() does not appear to actually be necessary,
> and thus is simply removed.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> This fixes the following bug:
> http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051564.html
>
> drivers/net/fs_enet/fs_enet-main.c | 7 +------
> 1 files changed, 1 insertions(+), 6 deletions(-)
applied
^ permalink raw reply
* Re: [patch v7 3/4] USB: add Cypress c67x00 OTG controller HCD driver
From: Peter Korsgaard @ 2008-02-20 16:57 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, dbrownell, stern, linux-usb
In-Reply-To: <20080220161608.GE2658@kroah.com>
>>>>> "Greg" == Greg KH <greg@kroah.com> writes:
Hi,
Greg> I don't know, I selected the config option, and yet, it built
Greg> as if it wasn't set.
Sorry, I cannot reproduce that here. Could you try again?
Greg> Can you move the files under the hcd/ subdir
Sorry, I don't think that's a good idea as the hardware can do
peripheral as well, and as you can see in patch 4, a gadget driver is
on it's way.
Greg> run it through checkpatch.pl and fix up the __FUNCTION__
Greg> warnings, and then I'll be willing to test it again :)
Ahh, that seems to be a pretty new warning in checkpatch - I atleast
haven't seen it before. The other things it complains about seems to
be rubbish though (except for the single indented label).
I'll send a v9 series shortly.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [patch v8 1/4] USB: add Cypress c67x00 low level interface code
From: Peter Korsgaard @ 2008-02-20 16:59 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, dbrownell, stern, linux-usb
In-Reply-To: <20080220161343.GC2658@kroah.com>
>>>>> "Greg" == Greg KH <greg@kroah.com> writes:
Hi,
>> drivers/usb/c67x00/c67x00.h | 285 ++++++++++++++++++++++++++
Greg> Why not drivers/usb/hcd/c67x00/ instead?
Because the device can do both host and peripheral (E.G. see patch 4
in the series).
We could put it under hcd for now and then move it once the gadget
driver gets finished/merged, but that seems silly to me..
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [patch v8 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: Peter Korsgaard @ 2008-02-20 17:01 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, dbrownell, stern, linux-usb
In-Reply-To: <20080220161435.GD2658@kroah.com>
>>>>> "Greg" == Greg KH <greg@kroah.com> writes:
Greg> On Wed, Feb 20, 2008 at 10:07:27AM +0100, Peter Korsgaard wrote:
>> The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
>> USB controllers. This patch series implements a HCD driver and shows the
>> work-in-progress status of a gadget driver.
>>
>> I believe patch 1..3 are ready, and I would like to see them queued up for
>> mainline.
>>
>> Changes since v7:
>> - Moved dummy hcd probe/remove functions for conditional hcd support into
>> udc patch.
>> - Moved usb_disabled() check into c67x00_hcd_probe().
>> - Moved c67x00_get_comm_reg() to udc patch as it is only needed for gadget
>> support.
Greg> So this fixes the build errors/warnings I sent you?
Well, I cannot reproduce the errors you showed (with Linus -git), but
it does fix a warning about c67x00_get_comm_reg being unused.
Greg> Can you run them through scripts/checkpatch.pl to ensure that those
Greg> warnings are also fixed?
Yes, I'll send a new series shortly.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [patch v7 3/4] USB: add Cypress c67x00 OTG controller HCD driver
From: Greg KH @ 2008-02-20 17:03 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell, stern, linux-usb
In-Reply-To: <874pc3efbx.fsf@macbook.be.48ers.dk>
On Wed, Feb 20, 2008 at 05:57:06PM +0100, Peter Korsgaard wrote:
> >>>>> "Greg" == Greg KH <greg@kroah.com> writes:
>
> Hi,
> Greg> I don't know, I selected the config option, and yet, it built
> Greg> as if it wasn't set.
>
> Sorry, I cannot reproduce that here. Could you try again?
I will on the next round :)
> Greg> Can you move the files under the hcd/ subdir
Oops, I ment "host/" not, "hcd/".
> Sorry, I don't think that's a good idea as the hardware can do
> peripheral as well, and as you can see in patch 4, a gadget driver is
> on it's way.
Ok, that's fine, why can't the gadget stuff go into the gadget/
directory then also? As this device is a host controller, it makes
sense to me to keep it in the host-controller subdirectory.
> Greg> run it through checkpatch.pl and fix up the __FUNCTION__
> Greg> warnings, and then I'll be willing to test it again :)
>
> Ahh, that seems to be a pretty new warning in checkpatch - I atleast
> haven't seen it before. The other things it complains about seems to
> be rubbish though (except for the single indented label).
What other things do you think are rubbish?
And yes, it's a new warning with the advent of 2.6.25-rc1, but that's no
reason to ignore it :)
thanks,
greg k-h
^ permalink raw reply
* Re: [rtc-linux] state of GEN_RTC vs rtc subsystem
From: Alessandro Zummo @ 2008-02-20 17:03 UTC (permalink / raw)
To: rtc-linux; +Cc: linuxppc-dev list, rz, LKML Kernel
In-Reply-To: <47B18612-66A3-476C-B81C-F2FD11CE9A64@kernel.crashing.org>
On Wed, 20 Feb 2008 10:11:23 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> Is the functionality provided by drivers/char/gen_rtc.c completely
> handled by the rtc subsystem in drivers/rtc?
>
> I ask for two reasons:
> 1. should we make it mutually exclusive in Kconfig
> 2. I've enabled both and get (we'll my defconfig did):
They shouldn't be enabled at once. I think a patch
for Kconfig has been recently submitted to give a warning
in such a case.
rtc-cmos should be able to handle the vast majority of x86
rtcs out there.
The only real open issue is related to the ntp synchronization
mode and will be solved only when we can get rid of it :)
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Re: ELDK on 64-bit host
From: Kalle Pokki @ 2008-02-20 17:06 UTC (permalink / raw)
To: Ben Warren; +Cc: linuxppc-embedded
In-Reply-To: <f8328f7c0802200749h7a761fffha636f292b54182e5@mail.gmail.com>
On Wed, 20 Feb 2008, Ben Warren wrote:
> On Wed, Feb 20, 2008 at 10:03 AM, Kalle Pokki <kalle.pokki@eke.fi> wrote:
> > Hi,
> >
> > I tried to copy the ELDK 4.0 installation I had to a new Core 2 Quad
> > machine running 64-bit Ubuntu 7.10, but the new machine refuses to
> > execute the cross compiler. Has anyone succeeded in running ELDK in
> > this kind of environment?
> >
> Yes (at least with 64-bit Debian on a single core Xeon), but you need
> a special library on the host. I think it's call 'ia32-libs'. It
> should be available via aptitude.
Thanks, that was indeed the correct library to install. Now it works just
fine.
I'm a bit surprised there wasn't really any useful search results from
Google with obvious keywords. I was already about to install the 32-bit
version of Ubuntu to get the compiler working again. But then, perhaps
installing this library was obvious to everyone else :)
^ permalink raw reply
* Re: [patch v8 1/4] USB: add Cypress c67x00 low level interface code
From: Greg KH @ 2008-02-20 17:40 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell, stern, linux-usb
In-Reply-To: <87r6f7d0nb.fsf@macbook.be.48ers.dk>
On Wed, Feb 20, 2008 at 05:59:36PM +0100, Peter Korsgaard wrote:
> >>>>> "Greg" == Greg KH <greg@kroah.com> writes:
>
> Hi,
>
> >> drivers/usb/c67x00/c67x00.h | 285 ++++++++++++++++++++++++++
>
> Greg> Why not drivers/usb/hcd/c67x00/ instead?
>
> Because the device can do both host and peripheral (E.G. see patch 4
> in the series).
>
> We could put it under hcd for now and then move it once the gadget
> driver gets finished/merged, but that seems silly to me..
Moving files is trivial to do, if we need to do it in the future, we
can.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Fix Haleakala PCIe compatibility problem in dts
From: Josh Boyer @ 2008-02-20 18:08 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200802201416.54004.sr@denx.de>
On Wed, 20 Feb 2008 14:16:53 +0100
Stefan Roese <sr@denx.de> wrote:
> > > The 405EX and 405EXr are identical exept that the 2nd PCIe and the
> > > 2nd EMAC interfaces are missing.
> >
> > Does ppc405ex_pciex_core_init need to grow some logic to detect 405ex
> > from 405exr and return the correct number of ports then? It
> > unconditionally returns 2 today.
>
> Yes, this could be done. Right now it works because the 405EXr board
> (Haleakala) only instantiates one PCIe device in the dts.
>
> A simple solution would be to just do a PVR check. Would this be acceptable?
Looking more at the code, it seems like it's really not needed.
Essentially the only thing that is "wrong" is that we allocate an extra
structure that goes unused.
As long as the DTS file doesn't list a second bogus port, things work
fine. So I'm inclined to take your patch as-is.
josh
^ 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