* Re: Qt, forks and threads = segmentation faults?
From: David Jander @ 2006-01-30 9:42 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Russell McGuire
In-Reply-To: <000301c623a2$13b98fc0$6405a8c0@absolut>
Hi Russell,
On Saturday 28 January 2006 01:30, Russell McGuire wrote:
> This is a more general question, and if anyone knows of a more specialized
> list this should be posted to, I'd be happy to do so...
>
> Small picture of hardware:
> DENX Linux 2.4.25 / PowerPC MPC8280 / 32 MBs of RAM
>
> I am using QT Embedded for a small GUI that does BSD sockets, also using
> DENX's SM501 video driver. Everything is quite stable, recently I added a
> additional process to the application using fork() for the listening
> 'accept' call for the sockets.
>
> After many tests I decided that due to the nature of the fork() command and
> the GUI half of the program, that this was a large waste of memory, as I
> was duplicating the entire GUI system. So I started looking alternatives,
> and have landed at the 'pthread' library.
It shouldn't be a waste of memory, since Linux uses copy-on-write for memory
pages. That means, although it looks like your child process wates a lot of
memory (same initial VSS size as parent), it actually shares its memory with
the parent until the child starts modifying memory contents (write fault
occurs). At that moment the page being written to is copied, and the write
access succeeds on the copied page. So fork() is nowadays quite efficient in
linux systems..... exactly as efficient as creating a thread.
> However, now I have lots of segmentation faults, particularly when I send a
> message using QT's postEvent commands back to the main thread.
Eeek. You might want to compile QT with thread support compiled in (don't know
if that helps though).
Anyway, it is probably a better idea to stick with fork() (see above).
> I was curious if anyone had any better idea of a more stable or perhaps a
> suggestion on why I am able to only get about 30 seconds of run time out of
> the app using pthread, verses fork() seems to be much stabler.
Use fork().
Greetings,
--
David Jander
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: David S. Miller @ 2006-01-30 4:03 UTC (permalink / raw)
To: sdbrady
Cc: linux-mips, linux-ia64, spyro, ak, dhowells, linuxppc-dev, gerg,
sparclinux, uclinux-v850, ysato, takata, linuxsh-shmedia-dev,
grundler, torvalds, ink, mita, chris, dev-etrax, ultralinux,
linux-m68k, linux-kernel, linuxsh-dev, linux390, parisc-linux
In-Reply-To: <20060129071242.GA24624@miranda.arrow>
From: Stuart Brady <sdbrady@ntlworld.com>
Date: Sun, 29 Jan 2006 07:12:42 +0000
> There are versions of hweight*() for sparc64 which use POPC when
> ULTRA_HAS_POPULATION_COUNT is defined, but AFAICS, it's never defined.
That's right, the problem here is that no chips actually implement
the instruction in hardware, it is software emulated, ie. useless :-)
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Akinobu Mita @ 2006-01-30 3:29 UTC (permalink / raw)
To: Hirokazu Takata
Cc: akpm, linux-mips, linux-ia64, spyro, ak, dhowells, linuxppc-dev,
gerg, sparclinux, uclinux-v850, ysato, linuxsh-dev, torvalds, ink,
rth, chris, dev-etrax, ultralinux, linux-m68k, linux-kernel,
linuxsh-shmedia-dev, linux390, rmk, parisc-linux
In-Reply-To: <20060127.215147.670306403.takata.hirokazu@renesas.com>
On Fri, Jan 27, 2006 at 09:51:47PM +0900, Hirokazu Takata wrote:
> Could you tell me more about the new generic {set,clear,test}_bit()
> routines?
>
> Why do you copied these routines from parisc and employed them
> as generic ones?
> I'm not sure whether these generic {set,clear,test}_bit() routines
> are really generic or not.
I think it is the most portable implementation.
And I'm trying not to write my own code in this patch set.
>
> > +/* Can't use raw_spin_lock_irq because of #include problems, so
> > + * this is the substitute */
> > +#define _atomic_spin_lock_irqsave(l,f) do { \
> > + raw_spinlock_t *s = ATOMIC_HASH(l); \
> > + local_irq_save(f); \
> > + __raw_spin_lock(s); \
> > +} while(0)
> > +
> > +#define _atomic_spin_unlock_irqrestore(l,f) do { \
> > + raw_spinlock_t *s = ATOMIC_HASH(l); \
> > + __raw_spin_unlock(s); \
> > + local_irq_restore(f); \
> > +} while(0)
>
> Is there a possibility that these routines affect for archs
> with no HAVE_ARCH_ATOMIC_BITOPS for SMP ?
Currently there is no architecture using this atomic *_bit() routines
on SMP. But it may be the benefit of those who are trying to port Linux.
(See the comment by Theodore Ts'o in include/asm-generic/bitops.h)
> I think __raw_spin_lock() is sufficient and local_irqsave() is
> not necessary in general atomic routines.
If the interrupt handler also wants to do bit manipilation then
you can get a deadlock between the original caller of *_bit() and the
interrupt handler.
^ permalink raw reply
* Re: [PATCH 4/6] use include/asm-generic/bitops for each architecture
From: Akinobu Mita @ 2006-01-30 3:15 UTC (permalink / raw)
To: Hirokazu Takata
Cc: akpm, linux-mips, linux-ia64, spyro, ak, dhowells, linuxppc-dev,
gerg, sparclinux, uclinux-v850, ysato, linuxsh-dev, torvalds, ink,
rth, chris, dev-etrax, ultralinux, linux-m68k, linux-kernel,
linuxsh-shmedia-dev, linux390, rmk, parisc-linux
In-Reply-To: <20060127.220401.356433243.takata.hirokazu@renesas.com>
On Fri, Jan 27, 2006 at 10:04:01PM +0900, Hirokazu Takata wrote:
> compile and boot test on m32r: OK
Thanks.
> Code size became a little bigger... ;-)
>
> $ size linux-2.6.16-rc1*/vmlinux
> text data bss dec hex filename
> 1768030 124412 721632 2614074 27e33a linux-2.6.16-rc1.bitops/vmlinux
> 1755010 124412 721632 2601054 27b05e linux-2.6.16-rc1.org/vmlinux
The only difference I can find is __ffs()/ffz().
As Russel King clealy pointed out, it will generate larger code
than before.
^ permalink raw reply
* Re: Virtex-4 TEMAC device driver available?
From: David H. Lynch Jr. @ 2006-01-30 1:48 UTC (permalink / raw)
To: Yoshio Kashiwagi; +Cc: linuxppc-embedded
In-Reply-To: <JX2006011720543423.44411640@co-nss.co.jp>
Yoshio Kashiwagi wrote:
>Hi Patrick-san,
>
>GSRD of the following URL is downloaded and the driver of mvl is
>generated by EDK, the Xilinx temac driver and patch for 2.4 will be
>obtained.
>
>http://www.xilinx.co.jp/esp/wired/optical/xlnx_net/gsrd.htm
>
>Now, I'm just working temac driver to 2.6 and have not yet completed.
>
>Best Regards,
>Yoshio Kashiwagi - Nissin Systems
>
>
I could not get at the 2.4 driver at the url above.
How is the 2.6 driver going ?
Need any help ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net:8888
^ permalink raw reply
* Re: [PATCH] Add support for lite5200b board.
From: Sylvain Munaut @ 2006-01-29 22:21 UTC (permalink / raw)
To: John Rigby; +Cc: Txema Lopez, John Rigby, linuxppc-embedded
In-Reply-To: <4b73d43f0601261329n73971003n9217374a1cc2db6f@mail.gmail.com>
John Rigby wrote:
>
>
> On 1/25/06, *Sylvain Munaut* <tnt@246tnt.com <mailto:tnt@246tnt.com>> wrote:
>
>
>
> Should apply fine on vanilla. My suggestion for now is take vanilla,
> apply this patch, then the 2-3 patch from Andrey for BestComm and stuff.
>
>
> I was working on getting bestcomm and fec working, but forward porting
> my old 2.6.10 code to current is turning out to be more difficult than I
> expected.
> If you already have working code then I'll stop working on them.
>
> Where are these patches? I'm new to this list so I don't have much
> history.
> Would I find these patches in the archive?
Checkout (with git)
http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx
then apply
http://gitbits.246tNt.com/patches/bcomm-to-split.diff
(I haven't cleanly splitted it up yet and right now I must go, so it's
probably gonna be in the git tree this week, under the 'bestcomm' head ;)
Please report if it works fine on your board (both lite5200 and
lite5200b reports are welcome). I only did quick tests.
Sylvain
^ permalink raw reply
* Re: MPC875 porting
From: Dan Malek @ 2006-01-29 21:47 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <ITVFT5$D7FAA0BB780EC8B8F02A50A5AB92E2E0@libero.it>
On Jan 29, 2006, at 3:34 PM, dibacco@@inwind..it wrote:
> I have a custom board with a MPC875 and two ethernet ports. I think I
> need to modify the enet.c to have two ethernet ports working.
Please read the archives and use the new drivers/net/fs_net
driver and the new serial port drivers. This has all been updated
and should just work for you.
Thanks.
-- Dan
^ permalink raw reply
* MPC875 porting
From: dibacco @ 2006-01-29 20:36 UTC (permalink / raw)
To: linuxppc-embedded
I have a custom board with a MPC875 and two ethernet ports. I think I nee=
d to modify the enet.c to have two ethernet ports working. What happens i=
f I define both
CONFIG_SCC1_ENET and CONFIG_SCC2_ENET ? I saw in enet.c the following cod=
e:
#if defined(CONFIG_SCC3_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC3
#define PROFF_ENET PROFF_SCC3
#define SCC_ENET 2 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC3
#elif defined(CONFIG_SCC2_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC2
#define PROFF_ENET PROFF_SCC2
#define SCC_ENET 1 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC2
#elif defined(CONFIG_SCC1_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC1
#define PROFF_ENET PROFF_SCC1
#define SCC_ENET 0 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC1
#else
#error CONFIG_SCCx_ENET not defined
#endif
The point is that there is and elif here, only the SCC1 will work then, I=
'm confused!
Thank you for your help!
Bye.
^ permalink raw reply
* MPC875 porting
From: dibacco @ 2006-01-29 20:34 UTC (permalink / raw)
To: linuxppc-embedded
I have a custom board with a MPC875 and two ethernet ports. I think I nee=
d to modify the enet.c to have two ethernet ports working. What happens i=
f I define both
CONFIG_SCC1_ENET and CONFIG_SCC2_ENET ? I saw in enet.c the following cod=
e:
#if defined(CONFIG_SCC3_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC3
#define PROFF_ENET PROFF_SCC3
#define SCC_ENET 2 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC3
#elif defined(CONFIG_SCC2_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC2
#define PROFF_ENET PROFF_SCC2
#define SCC_ENET 1 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC2
#elif defined(CONFIG_SCC1_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC1
#define PROFF_ENET PROFF_SCC1
#define SCC_ENET 0 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC1
#else
#error CONFIG_SCCx_ENET not defined
#endif
The point is that there is and elif here, only the SCC1 will work then, I=
'm confused!
Thank you for your help!
Bye.
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Stuart Brady @ 2006-01-29 7:12 UTC (permalink / raw)
To: Grant Grundler, Akinobu Mita, linux-kernel, Ivan Kokshaysky,
Ian Molton, dev-etrax, David Howells, Yoshinori Sato,
Linus Torvalds, linux-ia64, Hirokazu Takata, linux-m68k,
Greg Ungerer, linux-mips, parisc-linux, linuxppc-dev, linux390,
linuxsh-dev, linuxsh-shmedia-dev, sparclinux, ultralinux,
Miles Bader, Andi Kleen, Chris Zankel
In-Reply-To: <20060126230353.GC27222@flint.arm.linux.org.uk>
On Thu, Jan 26, 2006 at 11:03:54PM +0000, Russell King wrote:
> Me too - already solved this problem once. However, I'd rather not
> needlessly take a step backwards in the name of generic bitops.
Indeed. However, I think we can actually improve bitops for some
architectures. Here's what I've found so far:
Versions of Alpha, ARM, MIPS, PowerPC and SPARC have bit counting
instructions which we're using in most cases. I may have missed some:
Alpha may have:
ctlz, CounT Leading Zeros
cttz, CounT Trailing Zeros
ARM (since v5) has:
clz, Count Leading Zeros
MIPS may have:
clz, Count Leading Zeros
clo, Count Leading Ones
PowerPC has:
cntlz[wd], CouNT Leading Zeros (for Word/Double-word)
SPARC v9 has:
popc, POPulation Count
PA-RISC has none. I've not checked any others.
The Alpha, ARM and PowerPC functions look fine to me.
On MIPS, fls() and flz() should probably use CLO. Curiously, MIPS is
the only arch with a flz() function.
On SPARC, the implementation of ffz() appears to be "cheese", and the
proposed generic versions would be better. ffs() looks quite generic,
and fls() uses the linux/bitops.h implementation.
There are versions of hweight*() for sparc64 which use POPC when
ULTRA_HAS_POPULATION_COUNT is defined, but AFAICS, it's never defined.
The SPARC v9 arch manual recommends using popc(x ^ ~-x) for functions
like ffs(). ffz() would return ffs(~x).
I've had an idea for fls():
static inline int fls(unsigned long x)
{
x |= x >> 1;
x |= x >> 2;
x |= x >> 4;
x |= x >> 8;
x |= x >> 16;
return popc(x);
}
I'm not sure how that compares to the generic fls(), but I suspect it's
quite a bit faster. Unfortunately, I don't have any MIPS or SPARC v9
hardware to test this on.
I'm not sure if this is of any use:
static inline int __ffs(unsigned long x)
{
return (int)hweight_long(x ^ ~-x) - 1;
}
The idea being that the generic hweight_long has no branches.
--
Stuart Brady
^ permalink raw reply
* MPC5200 - Problem with PSC mode
From: Moloko Vellocet @ 2006-01-28 23:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi, I'm configuring a MPC5200 in PSC3 mode to communicate with a
telephony board that send information to the MPC5200 continuously. In
the osciloscope I see the signals comming via RX pin, but when I read
RX buffer it doesn't contain anything and when I write in the TX
buffer the flags show that buffer is not empty, but in the osciloscope
I don't see any signal in TX pin. I can't enable the interrupt mode
too.
Can anyone help me?
Part of the configuration code:
out_8(&psc->command, MPC5xxx_PSC_TX_DISABLE | MPC5xxx_PSC_RX_DISABLE);
val32 =3D in_be32(&gpio->port_config);
val32 &=3D ~0x700;
val32 |=3D 0x600;
out_be32(&gpio->port_config, val32);
out_8(&psc->command, MPC5xxx_PSC_RST_RX |
MPC5xxx_PSC_RST_TX |
MPC5xxx_PSC_SEL_MODE_REG_1 |
MPC5xxx_PSC_RST_ERR_STAT);
out_be16(&psc->mpc5xxx_psc_imr, 0);
out_be16(&psc->rfalarm, 0x0004);
out_be16(&psc->tfalarm, 0x0004);
out_be32(&psc->sicr, 0x221000);
out_8(&psc->command, MPC5xxx_PSC_RST_RX |
MPC5xxx_PSC_RST_TX |
MPC5xxx_PSC_SEL_MODE_REG_1 |
MPC5xxx_PSC_RST_ERR_STAT);
spin_lock_irqsave(&mpc5xxx_serial_lock, my_flags);
val16 =3D in_be16(&psc->mpc5xxx_psc_imr);
val16 =3D MPC5xxx_PSC_IMR_TXRDY | MPC5xxx_PSC_IMR_RXRDY;
out_be16(&psc->mpc5xxx_psc_imr, val16);
spin_unlock_irqrestore(&mpc5xxx_serial_lock, my_flags);
out_8(&psc->command, MPC5xxx_PSC_RX_ENABLE | MPC5xxx_PSC_TX_ENABLE);
So.. with this I tried to read the RX and write in TX buffer.
Thank you.
--
_______________________________
Allann J. O. Silva
"I received the fundamentals of my education in school, but that was
not enough. My real education, the superstructure, the details, the
true architecture, I got out of the public library. For an
impoverished child whose family could not afford to buy books, the
library was the open door to wonder and achievement, and I can never
be sufficiently grateful that I had the wit to charge through that
door and make the most of it." (from I. Asimov, 1994)
^ permalink raw reply
* Qt, forks and threads = segmentation faults?
From: Russell McGuire @ 2006-01-28 0:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.126.1138386609.857.linuxppc-embedded@ozlabs.org>
Everyone,
This is a more general question, and if anyone knows of a more specialized
list this should be posted to, I'd be happy to do so...
Small picture of hardware:
DENX Linux 2.4.25 / PowerPC MPC8280 / 32 MBs of RAM
I am using QT Embedded for a small GUI that does BSD sockets, also using
DENX's SM501 video driver. Everything is quite stable, recently I added a
additional process to the application using fork() for the listening
'accept' call for the sockets.
After many tests I decided that due to the nature of the fork() command and
the GUI half of the program, that this was a large waste of memory, as I was
duplicating the entire GUI system. So I started looking alternatives, and
have landed at the 'pthread' library.
However, now I have lots of segmentation faults, particularly when I send a
message using QT's postEvent commands back to the main thread.
I was curious if anyone had any better idea of a more stable or perhaps a
suggestion on why I am able to only get about 30 seconds of run time out of
the app using pthread, verses fork() seems to be much stabler.
-Russ
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: David Hawkins @ 2006-01-27 23:29 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200601261120.48251.sr@denx.de>
Hey Stefan,
>>readl() and ioread32() read the registers in little-endian format!
>
> Correct. That's how it is implemented on all platforms. Think for
> example of an pci device driver. Using these IO functions, the
> driver will become platform independent, running without
> modifications on little- and big-endian machines.
I just stumbled across the section in Rubini 3rd Ed that mislead
me into believing that the readl()/writel() were machine endianness
dependent, i.e., LE on x86, BE on PPC.
p453 of his book has a PCI DMA example, where he uses the
cpu_to_le32() macros inside calls writel().
However, since these functions are internally implemented to
perform LE operations, this example appears to be incorrect.
Would you agree?
I just checked the Oreilly web site for errata's and this is not
listed. If you agree that the example is incorrect, then I'll
submit an errata.
Dave
^ permalink raw reply
* RE: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Clement Fabien @ 2006-01-27 18:09 UTC (permalink / raw)
To: Pantelis Antoniou, galak, Marcelo Tosatti, linuxppc-embedded
Hello Pantelis
What is the status for this patch - I did not see any approval in the
list.
For me it's ok and in "production" (except that I don't like the loss of
space but I can live with it)
Regards
Fabien
-----Original Message-----
From: Pantelis Antoniou [mailto:panto@intracom.gr]=20
Sent: jeudi 24 novembre 2005 12:04
To: Clement Fabien; Kumar Gala; Marcelo Tosatti; linuxppc-embedded
Subject: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
Hi all.
Alignments are currently handled bogusly for cpm2.
Please test.
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Grant Likely @ 2006-01-27 16:37 UTC (permalink / raw)
To: Paula Saameño; +Cc: linuxppc-embedded
In-Reply-To: <259581790601270401g279663c9k1472c4e8b2bd5406@mail.gmail.com>
On 27-Jan-06, at 5:01 AM, Paula Saame=F1o wrote:
> Hi!
>
> I have tested the patches on the git kernel 2.6 and the reference =20
> design for the ml403, and it boot sucessfully. Thanks for the support!
>
> Have any of you tried to mount the root fs via NFS? I haven't been =20
> able to. I think that, as long as there is no driver for the Xilinx =20=
> EMAC yet, I cannot do it, can I?
That's right. I've ported the 2.4 EMAC driver to 2.6, but I don't =20
have permission from my client to release it yet. I think MontaVista =20=
is also working on an updated driver; you could ping them
>
> Thanks one more time!
No problem.
^ permalink raw reply
* Re: mpc8260 fcc enet transmit time out
From: hubert.loewenguth @ 2006-01-27 8:40 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <9A63F321BC93984690A3CA6A1652C2ED0BC64500@exnanycmbx1.corp.root.ipc.com>
hello David and the community
So happy to see that I'm not alone against this matter :)
/I've not been able to work on the problem for some time (development
schedules and all that jazz)...
/Same situation :), but I will try your solution next week and send you i=
f it fix the problem /
/
Hubert loewenguth
Hunter, David a =E9crit :
>One day, hubert.loewenguth at thales-bm.com wrote:
> =20
>
>>Everything works fine, but, if I do successive plugs/unplugs during=20
>>important data transfert, The driver enter into an infinite loop:
>>...
>>Is there anybody having encounter the same problem?
>>Is there anybody having done some test of numerous plug/unplug
>> =20
>>
>during=20
> =20
>
>>important data transfert with a half-duplex connection on mpc8260?
>>Is there anybody having an idea to help me ?
>> =20
>>
>
>I have seen many symptoms involving the "NETDEV WATCHDOG: eth0: transmit=
>timed out" message, but so far I do not have a code fix for any of them.=
>:(
>
>We (my employer) use an MPC8270 (mask 2K49M) and LXT971A PHY, with Linux=
>2.4.18. In our case we do have MII PHY interrupt. Like you, when I get=
>the transmit timeout, it repeats forever. But I do not see the problem
>when doing successive plugs/unplugs of the Ethernet cable. Instead, I
>get timeout during normal board operation, without human interaction.
>
>In one customer site where our MPC8270 board is used, the customer uses
>100 Mb half duplex Ethernet. During many weeks of normal operation,
>several times the board did experience transmit timeout. One of the
>times, this was output:
>
><-------- DUMP STARTS HERE ---------->
>NETDEV WATCHDOG: eth0: transmit timed out
>eth0: transmit timed out.
> Ring data dump: cur_tx c01aa380 (full) cur_rx c01aa220.
> Tx @base c01aa308 :
>9c00 0051 070f79a2
>1c00 0056 070f7da2
>1c00 0056 070f7ea2
>1c00 0051 070f7ba2
>1c80 003f 070f51c2
>9c00 0056 070f50c2
>9c00 0051 070f52c2
>9c00 0056 070f53c2
>9c00 0056 070f55c2
>9c00 0051 070f54c2
>dc00 0038 070f56c2
>9c00 0056 070f57c2
>9c00 0051 070f58c2
>9c00 0056 070f59c2
>9c00 0056 070f5ac2
>bc00 0056 070f7ca2
> Rx @base c01aa208 :
>9c00 0040 0046f000
><--- snip: BD status are all 9c00 -->
>9c00 0040 00461000
>9c00 0040 00461800
>9c00 0040 00460000
>bc00 0040 00460800
><---------- DUMP ENDS HERE ---------->
>
>Note that one TxBD has the status 0x1c80, indicating late collision
>(BD_ENET_TX_LC). This is an unusual condition in Ethernet, but recovery=
>should still be possible. Like you, I suspect errata CPM 119, but I
>have not tried the patch yet. (Development schedules and all that
>jazz.)
>
>As a workaround, we placed a 10/100 Mb hub between the board and the
>customer's network, which negotiated the PHY up to 100 Mb full duplex.
>The transmit timeout problem has not been seen since (to the best of my
>knowledge.)
>
>Back in the lab I have been able to reproduce the transmit timeout on a
>100 Mb full duplex network. Like you, I added printk output where
>fcc_enet_interrupt tests each BD_ENET_TX_* flag. In one case, I saw
>this:
>
><-------- DUMP STARTS HERE ---------->
>eth0: BDP=3Dc01aa370: Carrier lost
>eth0: BDP=3Dc01aa370: Carrier lost
>eth0: BDP=3Dc01aa330: Carrier lost
>eth0: BDP=3Dc01aa360: Carrier lost
>eth0: BDP=3Dc01aa348: Carrier lost
>eth0: BDP=3Dc01aa310: Carrier lost
>eth0: BDP=3Dc01aa318: Carrier lost
><---- Carrier lost repeats 61 more times, random BDP ---->
>eth0: BDP=3Dc01aa348: Underrun
>eth0: Restarting transmitter!!!
>
>NETDEV WATCHDOG: eth0: transmit timed out
>eth0: transmit timed out.
><-------- DUMP ENDS HERE ---------->
>
>The Underrun message means TxBD status bit BD_ENET_TX_UN (0x0002) was
>set. The last Tx ring data dump in your post shows the same thing.
>That scares me, mainly because I don't know what it means. Does it mean=
>the SDMA transfer didn't end on time? I dunno. And what the heck is
>carrier lost during TX in full duplex mode? It makes sense for half
>duplex mode like your situation, but I can't make sense of it for full
>duplex. Further, the underrun case has only happened once; in most
>other cases, I get a transmit timeout wih absolutely no TxBD error bits
>whatsoever, and no indication that a TX restart was even attempted.
>That's even scarier. I also did try repeated plug/unplug of Ethernet
>during peak normal operation (probably 5-10 Mb traffic) on the 100 Mb
>full duplex network, but after 11 successive plugs I did not see any
>timeouts.
>
>I'm starting to wonder if I have a cache coherency problem. The buffer
>descriptors are in main RAM and the data cache is turned on... Its just=
>a thought I picked up reading some prior posts that I can't rightly
>recall.
>
>I noted that the MPC8280 manual (online from Freescale) does now detail
>the transmitter recovery procedure (section 30.10.1 FCC Transmit
>Errors), and it's not nearly as simple as what fcc_enet.c implements in
>any kernel version. Despite CPM37, they don't toggle GFMR[ENT] in
>combination with the RESTART_TX command. Also, in 30.12.1 FCC
>Transmitter Full Sequence, a command (either RESTART_TX or INIT_TRX)
>must be issued after GFMR[ENT] is cleared but _before_ it is set. You
>might try changing fcc_enet_interrupt to do this:
>
> if (must_restart) {
> volatile cpm8260_t *cp;
>
> cep->fccp->fcc_gfmr &=3D ~FCC_GFMR_ENT;
>
> cp =3D cpmp;
> cp->cp_cpcr =3D
> mk_cr_cmd(cep->fip->fc_cpmpage,
>cep->fip->fc_cpmblock,
> 0x0c, CPM_CR_RESTART_TX) | CPM_CR_FLG;
> while (cp->cp_cpcr & CPM_CR_FLG);
>
> cep->fccp->fcc_gfmr |=3D FCC_GFMR_ENT;
> }
>
>I've not been able to work on the problem for some time (development
>schedules and all that jazz), but I'll post my solution if I find one.
>
>-Dave
>
>
>DISCLAIMER:
>Important Notice *************************************************
>This e-mail may contain information that is confidential, privileged or =
otherwise protected from disclosure. If you are not an intended recipient=
of this e-mail, do not duplicate or redistribute it by any means. Please=
delete it and any attachments and notify the sender that you have receiv=
ed it in error. Unintended recipients are prohibited from taking action o=
n the basis of information in this e-mail.E-mail messages may contain com=
puter viruses or other defects, may not be accurately replicated on other=
systems, or may be intercepted, deleted or interfered with without the k=
nowledge of the sender or the intended recipient. If you are not comforta=
ble with the risks associated with e-mail messages, you may decide not to=
use e-mail to communicate with IPC. IPC reserves the right, to the exten=
t and under circumstances permitted by applicable law, to retain, monitor=
and intercept e-mail messages to and from its systems.
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> =20
>
^ permalink raw reply
* RE: mpc82xx USB host driver
From: Dubb, Benjamin @ 2006-01-27 14:55 UTC (permalink / raw)
To: rmcguire; +Cc: linuxppc-embedded
Russell,
8270 host usb support is what I'm after. The problem with what's on =
sourceforge is it's 2.6 kernel based. We are using 2.4 in our design. =
Before taking the hacksaw to get this ported back, I'd like to see if =
the 2.4 kernel driver exists. Let me know if you know of one.
Thanks,
- Ben
-----Original Message-----
From: Russell McGuire [mailto:rmcguire@videopresence.com]=20
Sent: Thursday, January 26, 2006 7:17 PM
To: Dubb, Benjamin
Subject: mpc82xx USB host driver
Ben,
I assume you mean a USB host driver only for the PQ2, as anything in the =
82xx series is only a PQ2. Some mpc83xx USB host drivers are 2.0 =
compliant and thus much different.
PQ2 driver
http://cpm2usb.sourceforge.net./
I have this driver running on a MPC8280 Rev A
Note older MPC8280 chips i.e. Rev 0.0, Rev 0.1, will not work with this =
driver, without extreme hoops to jump through. I.E. uCode patches, and =
hardware changes...
Not the problems on the web page about multiple full speed devices, I =
myself have bad luck with even a single full speed device.. But the =
older devices running at low speed work great.
Hope this helps
Russell McGuire
Message: 5
Date: Thu, 26 Jan 2006 12:55:00 -0500
From: "Dubb, Benjamin" <Benjamin.Dubb@ipc.com>
Subject: mpc82xx USB host driver
To: <linuxppc-embedded@ozlabs.org>
Message-ID:
=09
<9A63F321BC93984690A3CA6A1652C2ED091017CA@exnanycmbx1.corp.root.ipc.com>
=09
Content-Type: text/plain; charset=3D"iso-8859-1"
I'm unable to find a 2.4 usb host driver for the pq3/pq2. Can someone =
post a patch here or point me to it, please. Thanks,
=20
- Ben
DISCLAIMER:
Important Notice *************************************************
This e-mail may contain information that is confidential, privileged or =
otherwise protected from disclosure. If you are not an intended =
recipient of this e-mail, do not duplicate or redistribute it by any =
means. Please delete it and any attachments and notify the sender that =
you have received it in error. Unintended recipients are prohibited from =
taking action on the basis of information in this e-mail.E-mail messages =
may contain computer viruses or other defects, may not be accurately =
replicated on other systems, or may be intercepted, deleted or =
interfered with without the knowledge of the sender or the intended =
recipient. If you are not comfortable with the risks associated with =
e-mail messages, you may decide not to use e-mail to communicate with =
IPC. IPC reserves the right, to the extent and under circumstances =
permitted by applicable law, to retain, monitor and intercept e-mail =
messages to and from its systems.
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Hirokazu Takata @ 2006-01-27 12:51 UTC (permalink / raw)
To: mita
Cc: akpm, linux-mips, linux-ia64, spyro, ak, dhowells, linuxppc-dev,
gerg, sparclinux, uclinux-v850, ysato, takata, linuxsh-dev,
torvalds, ink, rth, chris, dev-etrax, ultralinux, linux-m68k,
linux-kernel, linuxsh-shmedia-dev, linux390, rmk, parisc-linux
In-Reply-To: <20060125113206.GD18584@miraclelinux.com>
Hello Mita-san, and folks,
From: mita@miraclelinux.com (Akinobu Mita)
Subject: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
Date: Wed, 25 Jan 2006 20:32:06 +0900
> o generic {,test_and_}{set,clear,change}_bit() (atomic bitops)
>
> This patch introduces the C-language equivalents of the functions below:
> void set_bit(int nr, volatile unsigned long *addr);
> void clear_bit(int nr, volatile unsigned long *addr);
...
> int test_and_change_bit(int nr, volatile unsigned long *addr);
>
> HAVE_ARCH_ATOMIC_BITOPS is defined when the architecture has its own
> version of these functions.
>
> This code largely copied from:
> include/asm-powerpc/bitops.h
> include/asm-parisc/bitops.h
> include/asm-parisc/atomic.h
Could you tell me more about the new generic {set,clear,test}_bit()
routines?
Why do you copied these routines from parisc and employed them
as generic ones?
I'm not sure whether these generic {set,clear,test}_bit() routines
are really generic or not.
> +/* Can't use raw_spin_lock_irq because of #include problems, so
> + * this is the substitute */
> +#define _atomic_spin_lock_irqsave(l,f) do { \
> + raw_spinlock_t *s = ATOMIC_HASH(l); \
> + local_irq_save(f); \
> + __raw_spin_lock(s); \
> +} while(0)
> +
> +#define _atomic_spin_unlock_irqrestore(l,f) do { \
> + raw_spinlock_t *s = ATOMIC_HASH(l); \
> + __raw_spin_unlock(s); \
> + local_irq_restore(f); \
> +} while(0)
Is there a possibility that these routines affect for archs
with no HAVE_ARCH_ATOMIC_BITOPS for SMP ?
I think __raw_spin_lock() is sufficient and local_irqsave() is
not necessary in general atomic routines.
If the parisc's LDCW instruction required disabling interrupts,
it would be parisc specific and not generic case, I think,
although I'm not familier with the parisc architecture...
-- Takata
^ permalink raw reply
* Re: [PATCH 4/6] use include/asm-generic/bitops for each architecture
From: Hirokazu Takata @ 2006-01-27 13:04 UTC (permalink / raw)
To: mita
Cc: akpm, linux-mips, linux-ia64, spyro, ak, dhowells, linuxppc-dev,
gerg, sparclinux, uclinux-v850, ysato, takata, linuxsh-dev,
torvalds, ink, rth, chris, dev-etrax, ultralinux, linux-m68k,
linux-kernel, linuxsh-shmedia-dev, linux390, rmk, parisc-linux
In-Reply-To: <20060126014934.GA6648@miraclelinux.com>
From: mita@miraclelinux.com (Akinobu Mita)
Subject: Re: [PATCH 4/6] use include/asm-generic/bitops for each architecture
Date: Thu, 26 Jan 2006 10:49:34 +0900
> On Wed, Jan 25, 2006 at 08:33:37PM +0900, mita wrote:
> > compile test on i386, x86_64, ppc, sparc, sparc64, alpha
> > boot test on i386, x86_64, ppc
...
>
> o m32r
>
> - remove __{,test_and_}{set,clear,change}_bit() and test_bit()
> - remove ffz()
> - remove find_{next,first}{,_zero}_bit()
> - remove __ffs()
> - remove fls()
> - remove fls64()
> - remove sched_find_first_bit()
> - remove ffs()
> - remove hweight()
> - remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
> - remove ext2_{set,clear}_bit_atomic()
> - remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
> - define HAVE_ARCH_ATOMIC_BITOPS
>
compile and boot test on m32r: OK
Code size became a little bigger... ;-)
$ size linux-2.6.16-rc1*/vmlinux
text data bss dec hex filename
1768030 124412 721632 2614074 27e33a linux-2.6.16-rc1.bitops/vmlinux
1755010 124412 721632 2601054 27b05e linux-2.6.16-rc1.org/vmlinux
-- Takata
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Paula Saameño @ 2006-01-27 12:01 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]
Hi!
I have tested the patches on the git kernel 2.6 and the reference design for
the ml403, and it boot sucessfully. Thanks for the support!
Have any of you tried to mount the root fs via NFS? I haven't been able to.
I think that, as long as there is no driver for the Xilinx EMAC yet, I
cannot do it, can I?
Thanks one more time!
Paula
[-- Attachment #2: Type: text/html, Size: 401 bytes --]
^ permalink raw reply
* RE: mpc82xx USB host driver
From: Martin Krause @ 2006-01-27 8:22 UTC (permalink / raw)
To: Dubb, Benjamin, linuxppc-embedded
Hi Ben,
linuxppc-embedded-bounces@ozlabs.org wrote on Thursday, January 26,
2006 6:55 PM:=20
> I'm unable to find a 2.4 usb host driver for the pq3/pq2. Can someone
> post a patch here or point me to it, please.=20
> Thanks,
The cpm2usb project might be what you are looking for:
http://cpm2usb.sourceforge.net
But I'm not sure if the driver runs on Linux 2.4, though.
Regards,
Martin
^ permalink raw reply
* ivtv 0.4.2 driver works on powerpc !!
From: vinai @ 2006-01-27 5:24 UTC (permalink / raw)
To: Debian PowerPC List, LinuxPPC Developers' List; +Cc: ivtv-devel
Hi Folks,
Don't know if this has been made widely known, but I thought I's share
the last couple of days worth of experimenting.
The setup - a PowerMac 8500, running "stock" Debian testing except for
my own kernel compiled from the 2.6.15.1 sources from kernel.org. The
machine has 1 G RAM, 200 MHz 604e PowerPC CPU and a Firmtek SATA drive
controller running a 36 G 10K WD Raptor drive, and the capture device
under testing is a Hauppage 350 PCI card.
In my kernel .config file, I have video4linux and I2C support enabled,
as per the instructions on the ivtv web site. I built and used only
hardware modules from the ivtv 0.4.2 sources. I grabbed the firmware
and installed it, again per instructions.
If I do:
cat /dev/video0 > test.mpg
after a reboot, the hardware won't respond. However, if I remove the
ivtv module then do a modprobe of that module again, the above command
will work. "modprobe"-ing without "rmmod"-ing did not allow the card
to function.
I was able to capture about 20 s of video, with no noticeable dropped
frames, even on this slow machine. This machine can't even play the
captured clips, but transfer to another machine gave me a valid and
playable MPEG-2 file. I plan to do some more testing over the next
few days, and see if I can get this to actually work predictably...
Cheers, and thanks to all whose work and efforts made this happen !!
cheers
vinai
^ permalink raw reply
* kernel access of bad area
From: Chris Wardman @ 2006-01-27 2:09 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]
I'm working on getting a MPC885 to interface with an onboard CPLD. I've
successfully talked to the CPLD from our diagnostic application and I
know that it works at the locations that I specified in the IMMR. I know
that when linux loads that the IMMR still has the settings. However,
when I try to do a read from the address I get the following error:
Oops: kernel access of bad area, sig: 11
NIP: C00BDED8 XER: 8000FF40 LR: C00BDCE0 SP: C1C81E30 REGS: c1c81d80
TRAP: 0300
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: F4000002, DSISR: 00000129
TASK = c1c80000[19] 'acc2test' Last syscall: 54
last math 00000000 last altivec 00000000
GPR00: 00000001 C1C81E30 C1C80000 FFFFFFFA C1C81E38 20004C0A 7FFFFE6C
3000B8A8
GPR08: 10000560 F4000002 00000001 00000000 538D6C93 10018688 00000000
40000000
GPR16: 00000000 00000000 00000001 00000000 00009032 01C81E80 00000000
C0002838
GPR24: C0002560 10000560 30024E9C 00000003 C015C198 C015C1C4 7FFFFE6C
20004C0A
Call backtrace:
C003D81C C0042AA4 C00025BC 100106E8 10000494 0FECED14 00000000
SIGSEGV
It appears it is dying in the memory manager because of a bad page
fault.
Does anyone have any suggestion as how to fix this?
Thanx,
-Chris
[-- Attachment #2: Type: text/html, Size: 4563 bytes --]
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of
From: John David Anglin @ 2006-01-27 0:28 UTC (permalink / raw)
To: Grant Grundler
Cc: linux-mips, linux-m68k, linux-ia64, spyro, ak, dhowells,
linuxppc-dev, gerg, sparclinux, uclinux-v850, ysato, takata,
linuxsh-shmedia-dev, grundler, torvalds, ink, mita, chris,
dev-etrax, ultralinux, linux-kernel, linuxsh-dev, linux390,
parisc-linux
In-Reply-To: <20060126230443.GC13632@colo.lackof.org>
> Yeah, about the same for parisc.
>
> > Clearly the smallest of the lot with the smallest register pressure,
> > being the best candidate out of the lot, whether we inline it or not.
>
> Agreed. But I expect parisc will have to continue using it's asm
> sequence and ignore the generic version. AFAIK, the compiler isn't that
> good with instruction nullification and I have other issues I'd
> rather work on.
I looked at the assembler code generated on parisc with 4.1.0 (prerelease).
The toernig code is definitely inferior. The mita sequence is four
instructions longer than the arm sequence, but it didn't have any branches.
The arm sequence has four branches. Thus, it's not clear to me which
would perform better in the real world. There were no nullified instructions
generated for any of the sequences. However, neither is as good as the
handcraft asm sequence currently being used.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply
* Question on USB gadget device driver for mpc 8272 on linux 2.6.14.
From: Jonathan Qiang @ 2006-01-27 0:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
Hi, all
Currently, I am doing on the USB gadget device driver for mpc8272, I
already got some packets on interruption route when my board in which
mpc82xx settled connect to Host.
But the SOF is always generated as the first interruption source. When
plugged USB cable in HOST, the USB controller will be set to reset
(USBER is [0x308]), and after reset, the interruption source event
changes its status to [0x108], which means running on IDLE and SOF. Why
It is not IN token?
I already disabled Frame timer when I probe the USB gadget controller.
[-- Attachment #2: Type: text/html, Size: 4483 bytes --]
^ 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