* Help !!!!!!!! Does this Bug fixed ?
From: sairam k @ 2005-12-07 4:43 UTC (permalink / raw)
To: linuxppc-embedded
1) I used linuxppc_2_4_devel PowerPC development tree source(from
ppc.bkbits.net) to build kernel for PowerPC
IBM405EP(evb405ep_defconfig) and montavista's gcc cross compiler for
ppc_405-
2)I gave the following commands..
make evb405ep_config
make mrproper
make clean
make dep
make zImage
3) when i gave 'make zImage' command, the compilation stopped
abnormally and gave error that OPB_BASE_START symbol is unknown in
file ibm405ep.c
(arch/ppc/platforms/ibm405ep.c)
4) The point in source code where problem is arising is shown below....
-----------------------------------------------------------------------
..................
struct ocp_def core_ocp[] __initdata =3D {
{ .vendor=09=3D OCP_VENDOR_IBM,
.function=09=3D OCP_FUNC_OPB,
.index=09=3D 0,
=09 .paddr=09=3D OPB_BASE_START, // UNKOWN SYMBOL
.irq=09=09=3D OCP_IRQ_NA,
.pm=09=09=3D OCP_CPM_NA,
.........
..........
----------------------------------------------------------------------
Suggestion 1) I fixed this bug by providing the OPB_BASE_START address.
Since the core of ibm405EP is same as that of ibm405Gp & ibm405Gpr,
the OPB_BASE_START address will be same for all.
So just include the following line in ibm405ep.h
(ie., in arch/ppc/platforms/ibm405ep.h)
#define OPB_BASE_START 0x40000000
2) After adding the above line, I recompiled the sources
again....and this time it compiled and i am able to work on IBM405Ep
board.
(configuration file for IBm405ep is 'evb405ep_defconfig' in configs folder)
Does anyone fixed this bug........if so why it is not reflected in bkbits
^ permalink raw reply
* Re: MPC8245 with its internal UART
From: Dan Malek @ 2005-12-07 4:43 UTC (permalink / raw)
To: HappyPhot; +Cc: linuxppc-embedded
In-Reply-To: <000a01c5fae0$98ae1150$0760120a@photon>
On Dec 6, 2005, at 7:44 PM, HappyPhot wrote:
> Who can tell me which flatform is similar to mine ? I've tried
> "make sandpoint_defconfig", but seems not the right one.
That's the one I would have recommended. I don't think there
is any Linux platform port that uses the 8245 internal DUART,
at least not in the public source tree. The DUART is actually
pretty easy, just use the generic 8250 driver and point the address
to the Embedded Utilities Block DUART.
-- Dan
^ permalink raw reply
* Re: MPC85xx i2c interface bug
From: Dan Wilson @ 2005-12-07 4:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc list
In-Reply-To: <C7B817D4-457A-414A-BA2B-4A80DF0FA3E0@kernel.crashing.org>
On 12/6/2005 at 11:24 AM Kumar Gala wrote:
> Dan,
>
> I'm in agreement with your change for the 2.4 kernel. It looks like
> the 2.6 kernel driver is handing TXAK correctly. The following is a
> snippet from the 2.6 driver:
>
> if (length) {
> if (length == 1)
> writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA
> | CCR_TXAK);
> else
> writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA);
> /* Dummy read */
> readb(i2c->base + MPC_I2C_DR);
> }
>
> for (i = 0; i < length; i++) {
> if (i2c_wait(i2c, timeout, 0) < 0)
> return -1;
>
> /* Generate txack on next to last byte */
> if (i == length - 2)
> writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA
> | CCR_TXAK);
> /* Generate stop on last byte */
> if (i == length - 1)
> writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_TXAK);
> data[i] = readb(i2c->base + MPC_I2C_DR);
> }
>
>
> If I'm reading it correctly it matches your changes. If you dont
> mind looking at this and verifying that you agree that we are setting
> TXAK as expected.
>
> - kumar
>
Kumar,
Yes, the 2.6 code looks good to me too. Thanks much for your help!
Dan.
^ permalink raw reply
* Problem with customized MPC5200 board(copy from lite5200 design)
From: zhouzao @ 2005-12-07 20:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 442 bytes --]
Hello:
Yeo Kee Wee!
Can you resolve the problem on lite5200 or MPC5200 on your board?
The same problem is puzzling for me, But I kwon where is problem, the
cause is that U-boot has working on the lite5200 before BDI2000 control the
CPU, U-boot has init MPC5200.If you set the BDI2000 waiting time as reset in
the cfg file, you will find the same error on the lite5200!
Best regard!
Kabin chou
2005-12-7
[-- Attachment #2: Type: text/html, Size: 3005 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] ppc32: verbose error checking for Yucca PCIE initialization
From: Roland Dreier @ 2005-12-07 5:17 UTC (permalink / raw)
To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1133873391.16347.42.camel@mephisto.spb.rtsoft.ru>
Ruslan> I haven't saw any error but this is potential issue
Ruslan> because this flag asserts only then PCI Express port
Ruslan> initialization is completed. I guess the initialization
Ruslan> sequences assumes time using. Therefore the error may
Ruslan> appears in future revision of the boards if Core clock
Ruslan> will grow up. Nevertheless I do not know the time which
Ruslan> is necessary for completeness, so I add this just to be
Ruslan> safe.
Hmm, I guess this is OK. Matt, go ahead and apply this.
- R.
^ permalink raw reply
* Re: [PATCH 1/5] ppc32: Removes dead code from original Yucca PCIE initialization sequence
From: Roland Dreier @ 2005-12-07 5:13 UTC (permalink / raw)
To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1133873322.16347.39.camel@mephisto.spb.rtsoft.ru>
Looks good. Matt, please apply.
- R.
^ permalink raw reply
* Re: [PATCH 3/5] ppc32: Fix config space address calculation for Yucca PCIE initialization
From: Roland Dreier @ 2005-12-07 5:15 UTC (permalink / raw)
To: Ruslan V. Sushko; +Cc: rollandd, linuxppc-embedded
In-Reply-To: <1133873425.16347.43.camel@mephisto.spb.rtsoft.ru>
Looks good. Matt, please apply.
- R.
^ permalink raw reply
* Re: [PATCH 4/5] ppc32: Fix the PCI bus numbering assignment for Yucca PCI initialization.
From: Roland Dreier @ 2005-12-07 5:15 UTC (permalink / raw)
To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1133873432.16347.45.camel@mephisto.spb.rtsoft.ru>
Looks good. Matt, please apply.
- R.
^ permalink raw reply
* Re: [PATCH 5/5] ppc32: Add PCI-X support for Yucca board
From: Roland Dreier @ 2005-12-07 5:16 UTC (permalink / raw)
To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1133873451.16347.47.camel@mephisto.spb.rtsoft.ru>
Looks good. Matt, please apply.
- R.
^ permalink raw reply
* MPC8245 with its internal UART
From: Heiko Schocher @ 2005-12-07 7:36 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: happyphot
Hello,
> Who can tell me which flatform is similar to mine ? I've tried
> "make sandpoint_defconfig", but seems not the right one.
If you want to use Linux 2.4.25, you can try CPC45_defconfig
from the Denx Kernel ...
Best regards,
Heiko
^ permalink raw reply
* MPC8245 with its internal UART
From: Heiko Schocher @ 2005-12-07 7:33 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
> Who can tell me which flatform is similar to mine ? I've tried
> "make sandpoint_defconfig", but seems not the right one.
If you want to use Linux 2.4.25, you can try CPC45_defconfig
from the Denx Kernel ...
Best regards,
Heiko
^ permalink raw reply
* linux 2.4 on Xilinx ml403
From: Paulinha @ 2005-12-07 8:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
Hi all,
I have been trying to run linux 2.4.26 on Virtex 4 for a while and without
success.
I am trying to implement a simple design, with an UART, SystemACE and
everything interrupt driven. When I try to make bzImage, there is an error
in (SysACE) adapter.c file, because XPAR_INTC_0_SYSACE_0_VEC_ID is not
defined.
I have applied the patch given by Xilinx for switching from the ml300 to the
ml403, which copies the bsp, .config and xparameter files into the kernel.
I am stucked here, and do not know how to keep going from that.
Could anyone help me a little bit?
Thanks and have a good day!
[-- Attachment #2: Type: text/html, Size: 668 bytes --]
^ permalink raw reply
* Re: no IRQ from USB on MPC8248
From: Mike Rapoport @ 2005-12-07 8:58 UTC (permalink / raw)
To: Nathael PAJANI; +Cc: linuxppc-embedded
In-Reply-To: <4395AA59.5030209@cpe.fr>
Nathael PAJANI wrote:
[snip]
> which means the hub detects a device, and tries to configure it.
The root hub is virtual and implemented in SW. It detects the device any
time there's a pull-up on one of the D+ or D- lines, no matter if
controller is working properly or not.
>
> second: the device is happy to see a request and replies correctly....
> but there's no interrupt fired, whether using SUI_INT_USB (==11) or
> the SCC3 interrupt (==42)
>
Make sure you've adopted the following functions to your board:
static int board_configure(struct m8xxhci_private *hp)
static int setup_usb_clock(struct m8xxhci_private *hp)
so the controller will get proper USB clock.
--
Sincerely yours,
Mike Rapoport
^ permalink raw reply
* Help needed : MCC driver for MPC8260 ADS
From: s.maiti @ 2005-12-07 10:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051207061210.C32AD68896@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 988 bytes --]
Hello All,
For our project we need to have a MCC driver for MPC8260 ADS board. I
couldn't find any driver in the linux source tree for the same.
Any help in this regard will be highly appreciated.
Thanks and regards,
Souvik Maiti
Tata Consultancy Services Limited
Bengal Intelligent Park
Bldg. - D, Plots - A2, M2 & N2
Block - GP, Sector V
Salt Lake Electronics Complex
Kolkata - 700091, West Bengal
India
Mailto: s.maiti@tcs.com
Website: http://www.tcs.com
Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 1325 bytes --]
^ permalink raw reply
* Help required on mpc8260 kernel boot
From: batsayan.das @ 2005-12-07 9:50 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]
Hello,
I am using customs board with MPC8260 processor. I have RAM version of
U-Boot and I am able to get U-Boot prompt when I load and run u-bbot.srec
by TRACE32. My memory map is as follows
SDRAM start address :0x30000000 and 128MB
Flash start address: 0x00000000 and 1MB
I copied the kernel image at 0x30000000 by kermit. The load address and
the entry point of the UImage is set at 0x34000000 and 0x34000000. At
U-boot prompt when I run "bootm 0x30000000" . The kernel hangs with the
message " Uncompressing Kernel Image..OK"
My questions are
1. Is the above memory configuration is correct to run kernel from RAM
U-boot?
2. The U-Boot documentation says that SDRAM should be at 0. Does the
kernel will run if SDRAM is not set to 0?
3. How can I debug where in kernel source tree it got hanged?
Any pointer will be helpful. Thanks in advance.
Regards,
Batsayan Das
Tata Consultancy Services Limited
Mailto: batsayan.das@tcs.com
Website: http://www.tcs.com
Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 2130 bytes --]
^ permalink raw reply
* Re: linux 2.4 on Xilinx ml403
From: Yoshio Kashiwagi @ 2005-12-07 11:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <259581790512070010s3be8b3cfg6cfd17d2f503b0f7@mail.gmail.com>
Hi,
libgen of EDK should generate the definition of
XPAR_INTC_0_SYSACE_0_VEC_ID as follows according to your design to
xparameters.h.
[snip]
#define XPAR_INTC_0_SYSACE_0_VEC_ID XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_
SYSACE_IRQ_INTR
[snip]
Have you copied xparameters.h which EDK generated to the kernel tree?
Best Regards,
Yoshio Kashiwagi
> Hi all,
>
> I have been trying to run linux 2.4.26 on Virtex 4 for a while and
without
> success.
>
> I am trying to implement a simple design, with an UART, SystemACE and
> everything interrupt driven. When I try to make bzImage, there is an
error
> in (SysACE) adapter.c file, because XPAR_INTC_0_SYSACE_0_VEC_ID is not
> defined.
>
> I have applied the patch given by Xilinx for switching from the ml300
to the
> ml403, which copies the bsp, .config and xparameter files into the
kernel.
>
> I am stucked here, and do not know how to keep going from that.
> Could anyone help me a little bit?
>
> Thanks and have a good day!
>
^ permalink raw reply
* Re: Help required on mpc8260 kernel boot
From: Wolfgang Denk @ 2005-12-07 12:19 UTC (permalink / raw)
To: batsayan.das; +Cc: linuxppc-embedded
In-Reply-To: <OFCBD37606.7E278616-ON652570D0.0028C041-652570D0.00360A00@tcs.com>
In message <OFCBD37606.7E278616-ON652570D0.0028C041-652570D0.00360A00@tcs.com> you wrote:
>
> I am using customs board with MPC8260 processor. I have RAM version of
> U-Boot and I am able to get U-Boot prompt when I load and run u-bbot.srec
> by TRACE32. My memory map is as follows
>
> SDRAM start address :0x30000000 and 128MB
> Flash start address: 0x00000000 and 1MB
One of your fellows (mail address pritha.bhattacharya@tcs.com) posted
this before, and received pretty clear hints that your configuration
is not correct.
Also, you continue to ignore answers from the FAQs.
Please read the answers you received before, and follow the advice
given.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
panic: can't find /
^ permalink raw reply
* Re: Help needed : MCC driver for MPC8260 ADS
From: Stevan Ignjatovic @ 2005-12-07 12:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OFE97B5EA0.D9C1175E-ON652570D0.00392019-652570D0.003AB2EA@tcs.com>
Start point for your MCC driver could be at
http://sourceforge.net/projects/mcc8260/
On Wed, 2005-12-07 at 11:41, s.maiti@tcs.com wrote:
> Hello All,
>
> For our project we need to have a MCC driver for MPC8260 ADS board. I
> couldn't find any driver in the linux source tree for the same.
> Any help in this regard will be highly appreciated.
> Thanks and regards,
>
> Souvik Maiti
> Tata Consultancy Services Limited
> Bengal Intelligent Park
> Bldg. - D, Plots - A2, M2 & N2
> Block - GP, Sector V
> Salt Lake Electronics Complex
> Kolkata - 700091, West Bengal
> India
> Mailto: s.maiti@tcs.com
> Website: http://www.tcs.com
> Notice: The information contained in this e-mail message and/or
> attachments to it may contain confidential or privileged information.
> If you are not the intended recipient, any dissemination, use, review,
> distribution, printing or copying of the information contained in this
> e-mail message and/or attachments to it are strictly prohibited. If
> you have received this communication in error, please notify us by
> reply e-mail or telephone and immediately and permanently delete the
> message and any attachments. Thank you
>
> ______________________________________________________________________
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Wade Farnsworth @ 2005-12-07 15:15 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
Hi Eugene,
I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
the Ocotea when it's connected to a 10baseT hub, and it's put under
heavy load. I'm using the most current 2.6 git tree.
This can be reproduced by ssh'ing into the Ocotea and running the
command "ping <host-machine> -A -s 1200", then also doing the same ping
command from the host to the Ocotea. The pings will be successful for a
short time, then all transmits on the Ocotea will stop for a few seconds
(usually preceded by a few duplicate packets). Transmits begin again
once the timeout occurs. /proc/net/dev doesn't report any errors, just a
few dropped packets.
Do you know what might be causing the EMAC to stop transmitting in this
situation?
Thanks,
Wade Farnsworth
^ permalink raw reply
* Re: MPC8245 with its internal UART
From: Kumar Gala @ 2005-12-07 16:39 UTC (permalink / raw)
To: Dan Malek; +Cc: HappyPhot, linuxppc-embedded
In-Reply-To: <03f747f66110e0d5976c2c03a76945aa@embeddededge.com>
On Dec 6, 2005, at 10:43 PM, Dan Malek wrote:
>
> On Dec 6, 2005, at 7:44 PM, HappyPhot wrote:
>
>> Who can tell me which flatform is similar to mine ? I've tried
>> "make sandpoint_defconfig", but seems not the right one.
>
> That's the one I would have recommended. I don't think there
> is any Linux platform port that uses the 8245 internal DUART,
> at least not in the public source tree. The DUART is actually
> pretty easy, just use the generic 8250 driver and point the address
> to the Embedded Utilities Block DUART.
The 2.6 kernel tree has support for the DUART on 8245 Sandpoint
systems. (We added it in the last few months).
- kumar
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Kumar Gala @ 2005-12-07 16:54 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Arnd Bergmann, linuxppc64-dev
In-Reply-To: <20051207001720.GB25533@localhost.localdomain>
On Dec 6, 2005, at 6:17 PM, David Gibson wrote:
> On Tue, Dec 06, 2005 at 08:48:55PM +0100, Arnd Bergmann wrote:
>> On Maandag 05 Dezember 2005 22:06, Jon Loeliger wrote:
>>> Included below is a proposed Revision 0.5 of the
>>> "Booting the Linux/ppc kernel without Open Firmware"
>>> document. This modification primarily extends the
>>> Revision 0.4 by adding definitions for OF Nodes that
>>> cover the System-On-a-Chip features found on PPC parts.
>>> It also generalizes some earlier wording that pertained
>>> to only PPC64 parts and covers the new, merged PPC 32
>>> and 64 parts together. Finally, minor typos, style
>>> consistency and grammar problems were corrected.
>>
>> A few points are not clear yet, either because I don't understand the
>> document or one it references correctly or because I might have
>> different requirements:
>
> All comments below IMHO, and subject to persuasion otherwise.
>
>> - Do we need a way to identify the type of soc bus? There are
>> different
>> standards for this, e.g. PLB4 on PPC440 or the EIB on the Cell BE.
>> My initial idea was to have different device-type properties for
>> these,
>> but I now think that device_type = "soc" makes sense for all of
>> them.
>> Maybe we could add a model or compatible property for them.
>
> It think it would be a good idea to have something labelling the
> specific type of SOC bus, though I'm not immediately sure where.
> "model" perhaps, if it rarely has an effect on how to operate the bus.
I think this should be optional since it rarely has an effect on usage.
>> - It does not really belong into this document, but is related
>> anyway:
>> how do you want to represent this in Linux? Currently, most of
>> these
>> would be of_platform_device, but I think it would be good to have
>> a new bus_type for it. The advantage would be that you can see the
>> devices in /sys/devices/soc@xxx/ even if the driver is not loaded
>> and the driver can even be autoloaded by udev.
>> Also, which properties should show up in sysfs? All of them or just
>> those specified in this document or a subset of them?
>
> I concur - I believe we already have a bus_type for on-chip devices on
> 4xx.
Not, sure what the 4xx reference is but, we have be using the
platform bus in the kernel for "soc" connected devices. I dont see
the need to invent a new bus type unless there is a specific reason to.
>> - What do we do with pci root devices? They are often physically
>> connected
>> to the internal CPU bus, so it would make sense to represent them
>> this way in the device tree. Should we add them to the
>> specification
>> here? Would it even work the expected way in Linux?
>
> The host bridges should sit on the soc bus then, as you suggest (just
> as the PCI busses hang off HyperTransport on the G5). I think you
> need to refer to the OF docs for how to represent the PCI host bridge
> and devices themselves.
We need to provide some details on PCI nodes based on the OF docs.
Ben and I have talked a little about this. Its mainly about what
parts of the OF spec are truly required. We will probably add some
additional information that the OF spec doesnt handle for host
bridges setup.
>> - For some devices, you mandate a model property, for others you
>> don't.
>> Is this intentional? It might be easier to find the right device
>> driver if the match string always contains a model name.
>
> You rarely want to match model name to find a device - generally you
> want to match either on "compatible" or "device_type", or possibly
> both.
>
>> - How would I represent nested interrupt controllers? E.g. suppose I
>> have a Cell internal interrupt controller on one SOC bus and
>> and an external interrupt controller on another SOC bus but have
>> that deliver interrupts to the first one.
>
> Again, I believe this is in the OF docs - interrupt controllers have
> an interrupt-parent property IIRC, which gives the phandle of the next
> interrupt controller up the chain.
Yep, you need to check out the "Interrupt Mapping" OF spec for
details. It handles describing the chaining you speak of. However,
you will need to provide some "spec" for any properties of the
interrupt controllers that you may need.
>> - Should it mention nested SOC buses, e.g. a PLB4 bus connected to a
>> PLB5 bus?
>
> Yes.
Is there anything special about this? are these PLB4/5 busses
software visible?
>
>> - The title says 'without Open Firmware', but it should also be
>> allowed
>> to use the same SOC bus layout when using SLOF or some other OF
>> implementation, right?
>
> I guess so.
>
>> - Also not new in this version, but still: Should there be support
>> for
>> specifying CPUs with multiple SMT threads?
>
> Umm.. maybe.
- kumar
^ permalink raw reply
* Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Wade Farnsworth @ 2005-12-07 16:54 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <1133968527.8299.50.camel@rhino.az.mvista.com>
On Wed, 2005-12-07 at 08:15, Wade Farnsworth wrote:
> Hi Eugene,
>
> I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
> the Ocotea when it's connected to a 10baseT hub, and it's put under
> heavy load. I'm using the most current 2.6 git tree.
>
> This can be reproduced by ssh'ing into the Ocotea and running the
> command "ping <host-machine> -A -s 1200", then also doing the same ping
> command from the host to the Ocotea. The pings will be successful for a
> short time, then all transmits on the Ocotea will stop for a few seconds
> (usually preceded by a few duplicate packets). Transmits begin again
> once the timeout occurs. /proc/net/dev doesn't report any errors, just a
> few dropped packets.
>
> Do you know what might be causing the EMAC to stop transmitting in this
> situation?
One more data point to consider: I ran this test on an Ebony board, but
don't encounter any timeouts. Do you know of any 440GX-specific issues
that might cause this?
Thanks again,
Wade Farnsworth
^ permalink raw reply
* Re: Video Card to Lite5200
From: roger blofeld @ 2005-12-07 17:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051205203941.GA16695@mail.gnudd.com>
What is the status of the mpc5200 support? I see Sylvain's repository
is still at 2.6.12 (5 months old).
http://gitbits.246tnt.com/gitweb.cgi?p=linux-2.6-mpc52xx.git;a=summary
The current kernel.org kernel doesn't appear to support fec/DMA. Is
there a plan to get networking support into the mainstream kernel?
Thanks
-rb
--- Alessandro Rubini <rubini@gnudd.com> wrote:
>
> > Note that the 5200 code in the kernel is work in progress. I do
> not
> > cleaim that it does work in any way. If you want stable code use
> our
> > 2.4.25 kernel instead.
>
> FWIW, I have your 2.6.14 happily running on the lite5200, with PCI,
> IDE (no DMA though) and flash.
>
> I can publish the patches, if anyone is interested. Until now I
> didn't,
> as Sylvain's work is considered the official one (but it didn't have
> IDE last time I checked -- and I don't have bitkeeper to pull it).
>
> /alessandro
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________________
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
^ permalink raw reply
* Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Eugene Surovegin @ 2005-12-07 17:35 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <1133968527.8299.50.camel@rhino.az.mvista.com>
On Wed, Dec 07, 2005 at 08:15:28AM -0700, Wade Farnsworth wrote:
> Hi Eugene,
>
> I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
> the Ocotea when it's connected to a 10baseT hub, and it's put under
> heavy load. I'm using the most current 2.6 git tree.
>
> This can be reproduced by ssh'ing into the Ocotea and running the
> command "ping <host-machine> -A -s 1200", then also doing the same ping
> command from the host to the Ocotea. The pings will be successful for a
> short time, then all transmits on the Ocotea will stop for a few seconds
> (usually preceded by a few duplicate packets). Transmits begin again
> once the timeout occurs. /proc/net/dev doesn't report any errors, just a
> few dropped packets.
>
> Do you know what might be causing the EMAC to stop transmitting in this
> situation?
Hmm, I think this should have been fixed in the latest 2.6. Check
that you tree has this patch:
[PATCH] ibm_emac: fix graceful stop timeout handling
It went in on 01 Dec. Although this fix assumed FDX operation for
timeouts, without collisions. Maybe I was too optimistic thinking that
nobody uses 10/HDX :).
Try making STOP_TIMEOUT_10 bigger, say twice as big.
If this doesn't help, I'll send you patch with enables some additional
debugging, so I can check that stop you are experiencing is the same
problem I had last month.
--
Eugene
^ permalink raw reply
* Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Wade Farnsworth @ 2005-12-07 18:00 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20051207173554.GA21578@gate.ebshome.net>
On Wed, 2005-12-07 at 10:35, Eugene Surovegin wrote:
> Hmm, I think this should have been fixed in the latest 2.6. Check
> that you tree has this patch:
>
> [PATCH] ibm_emac: fix graceful stop timeout handling
>
> It went in on 01 Dec. Although this fix assumed FDX operation for
> timeouts, without collisions. Maybe I was too optimistic thinking that
> nobody uses 10/HDX :).
That was my first thought as well, but I've tried it with the patch, and
still get the timeouts.
>
> Try making STOP_TIMEOUT_10 bigger, say twice as big.
That doesn't seem to help any.
>
> If this doesn't help, I'll send you patch with enables some additional
> debugging, so I can check that stop you are experiencing is the same
> problem I had last month.
Much appreciated. Thanks!
Regards,
Wade Farnsworth
^ 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