* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Christian @ 2005-04-06 1:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Tom Rini
In-Reply-To: <42533FA1.1070001@gmx.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christian wrote:
> i booted vanilla 2.6.11.6 with noresidual (and "nopresidual" too, as Sven
> sugggested), but the scsi errors did not went away :(
um, no, worse that that: the scsi error kicks in for sym0:0:0:
sym0:0:0: DEVICE RESET operation started.
(...then it would continue until sym0:15:0, see [1])
then the machine locked up completely, not even SYSRQ works any more.
that happened when booting with "noresidual" and even with PREP_RESIDUAL=n
(in the .config).
thanks,
Christian.
[1] http://nerdbynature.de/bits/hal/2.6.11-rc5/dmesg
- --
BOFH excuse #48:
bad ether in the cables
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCU0ItC/PVm5+NVoYRAnVMAJ9L1eQLopn6ckMUkC+lNVnwsoKUCACfa2Tj
zqXc3jjKeiXpdYuih+wlZqs=
=GRwp
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Christian @ 2005-04-06 1:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Tom Rini
In-Reply-To: <20050405143802.GS25923@smtp.west.cox.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tom Rini wrote:
> Can either of you verify that say 2.6.11.6 w/ "noresidual" on the
> command-line works? Thanks.
i booted vanilla 2.6.11.6 with noresidual (and "nopresidual" too, as Sven
sugggested), but the scsi errors did not went away :(
on a side note, and perhaps totally unrelated: i always have
PROC_PREPRESIDUAL=y in my .config, but i never had /proc/residual as
promised from the help text.
thanks,
Christian.
- --
BOFH excuse #48:
bad ether in the cables
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCUz+hC/PVm5+NVoYRApdaAJ90DeNHRdmHHnQBflMrWyFt1/vO6gCfQixe
jLOm8vmTPNR+xKR9K6Yk9Fs=
=GnEk
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Marcelo Tosatti @ 2005-04-05 20:26 UTC (permalink / raw)
To: Dan Malek; +Cc: Paul Mackerras, linux-ppc-embedded
In-Reply-To: <20050405114109.GA888@logos.cnet>
On Tue, Apr 05, 2005 at 08:41:09AM -0300, Marcelo Tosatti wrote:
> On Tue, Apr 05, 2005 at 11:58:17AM -0400, Dan Malek wrote:
> >
> > On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
> >
> > >Problem is that the "dcbst" instruction will, _sometimes_ (the
> > >failure/success rate is about 1/4
> > >with my test application) fault as a _write_ operation on the data.
> >
> > Oh, geeze .... It's all coming back to me now ....
> >
> > The 8xx cache operations don't always operate as defined in the PEM.
> > There are likely to be some archive discussions within the Freescale
> > knowledge data base that describe the different behaviors I've seen
> > with the chip variants and revisions. I can't find any of those e-mail
> > discussions, so I'll try to recall from memory.
> >
> > The PEM cache instructions are all implemented in a microcode that
> > uses the 8xx unique cache control SPRs. Depending upon the state
> > of the cache and MMU, it seems in some cases the EA translation is
> > subject to a "normal" protection match instead of a load operation
> > match.
> >
> > The behavior of these operations isn't consistent across all of the 8xx
> > processor revisions, especially with early silicon if people are still
> > using those. During conversations with Freescale engineers, it seems
> > the only guaranteed operation was to use the 8xx unique SPRs, but
> > I think I only did that in 8xx specific functions.
>
> How sweet. :)
>
> > We have way too much code in the TLB exception handlers already,
> > so let's just try a tlbia of the EA in the update_mmu_cache, with an
> > #ifdef
> > for the 8xx.
>
> Are you sure this is the best solution ?
>
> Problem is that update_mmu_cache() is called from other context's where
> the tlb invalidate is not necessary (because it has already been invalidated).
>
> For example all ptep_set_access_flags() (which does the tlb invalidate) ->
> update_mmu_cache() sequences.
>
> Moreover jumping directly from DataTLBMiss to the page fault handler
> shortcuts the process: there is no need to jump back to execution if we
> know in advance that DataTLBError exception is going to happen.
>
> But hey, you are the boss. Even with the above facts you prefer
> to leave the DataTLBMiss untouched?
>
> About size: I think it is the smaller expection handler present.
Well, you know what you're talking about. Whatever you prefer.
Can we just ask someone to send the _tlbie patch around #ifdef CONFIG_M8XX?
^ permalink raw reply
* Re: Recommendations: Small Embedded PPC chip with FPU
From: Kumar Gala @ 2005-04-06 1:40 UTC (permalink / raw)
To: Joshua Lamorie; +Cc: linuxppc-embedded
In-Reply-To: <4252B50C.2080700@xiphos.ca>
While, I'm not sure about the industrial temp & package sizes, the 824x=20=
line from Freescale might be what you are looking for. Possibly, the=20
newer 834x line.
- kumar
On Apr 5, 2005, at 10:55 AM, Joshua Lamorie wrote:
> Gidday there,
>
> I am looking for a new PowerPC for some controls applications and I =
was
> wondering if anyone on this list might make some recommendations.=A0 I
> will be fabricating the board, so I'm just interested in the CPU.=A0
> Currently I'm doing everything on a Virtex-II Pro (PPC 405).
>
> I'm considering the MPC5200, but I would love to have something in a
> smaller package.
>
> Requirements:
> =A0=A0=A0 - Linux support
> =A0=A0=A0 - PowerPC w >=3D 16k D,I Cache
> =A0=A0=A0 - FPU
> =A0=A0=A0 - Onboard memory controller (SDRAM or DDR)
> =A0=A0=A0 - >=3D 300 MHz
> =A0=A0=A0 - Industrial temperature (-40 to +85)
> =A0=A0=A0 - package size < 27mmx27mm
> =A0=A0=A0 - everything else is icing
>
> Any suggestions welcome.
>
> I'm sorry if this is somewhat off topic.
>
> Joshua
>
> --=20
>
> Xiphos Technologies
> (514) 848-9640 x227
> (514) 848-9644 fax
>
> www.xiplink.com
> _______________________________________________
> The information transmitted is intended only for the
> person or entity to which it is addressed and may contain
> confidential and/or privileged material.=A0 If you have
> received this in error, please contact the sender and delete
> this communication and any copy immediately. Thank you.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [Fwd: Re: iBook G3 owners]
From: Benjamin Herrenschmidt @ 2005-04-05 23:50 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <jeacodv2z0.fsf@sykes.suse.de>
> I have the same problem. I'm also seeing the same hang when the KDED
> Media Manager is running (independent of hal/dbus). I believe the cause
> for this is that the ide subsystem wakes up too late, and the cdrom
> polling of hal or kded is resuming too early.
Yes, but that should not cause a hang... the ioctl should just be
blocked until the driver is resumed, though there must be some kind of
bug preventing that from working...
Ben.
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Andreas Schwab @ 2005-04-05 23:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1112742738.9517.45.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Tue, 2005-04-05 at 14:39 +0200, Andreas Schwab wrote:
>> Jerome Glisse <j.glisse@gmail.com> writes:
>>
>> > I will try t look at radeon framebuffer see if i can find anythings.
>> > Any idea of which change on that code may be the origin of this ?
>>
>> I'd suggest looking at the changes between rc1 and rc2 first. On my iBook
>> G3 with Radeon M6 I'm also having problems with rc2, whereas rc1 is
>> working fine. I haven't found the time to look closer yet.
>
> What problem specifically ?
<http://marc.theaimsgroup.com/?l=linux-kernel&m=111273873814456&w=2>
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Benjamin Herrenschmidt @ 2005-04-05 23:12 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list
In-Reply-To: <je1x9pv1mf.fsf@sykes.suse.de>
On Tue, 2005-04-05 at 14:39 +0200, Andreas Schwab wrote:
> Jerome Glisse <j.glisse@gmail.com> writes:
>
> > I will try t look at radeon framebuffer see if i can find anythings.
> > Any idea of which change on that code may be the origin of this ?
>
> I'd suggest looking at the changes between rc1 and rc2 first. On my iBook
> G3 with Radeon M6 I'm also having problems with rc2, whereas rc1 is
> working fine. I haven't found the time to look closer yet.
What problem specifically ?
Ben.
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Benjamin Herrenschmidt @ 2005-04-05 23:11 UTC (permalink / raw)
To: Jerome Glisse; +Cc: linuxppc-dev list
In-Reply-To: <4240b91605040504525fd877e5@mail.gmail.com>
On Tue, 2005-04-05 at 13:52 +0200, Jerome Glisse wrote:
> I almost successfully run the 2.6.12-rc2, there were some
> bad old stuff lying around. But i needed the two workaround
> to compile it. So maybe this two could be applied to the kernel ?
>
> Now the only issue which remains is that the radeon framebuffer
> no more set a proper mode for my screen. The screen complain
> about a out of range mode. But as soon as X start i get a proper
> mode set but can't switch to console.
>
> The screen is a crt one on a radeon 9600 with dvi->vga adapter.
> Which works well on 2.6.10
>
> I will try t look at radeon framebuffer see if i can find anythings.
> Any idea of which change on that code may be the origin of this ?
radeonfb picks the first mode in the list generated from DDC, which
unfortunately, on a lot of CRTs, is bullshit...
Ben.
^ permalink raw reply
* 8xx v2.6 TLB problems and suggested workaround
From: Joakim Tjernlund @ 2005-04-05 21:51 UTC (permalink / raw)
To: marcelo.tosatti, linuxppc-embedded
Hi Marcelo
Reading your report it doesn't sound likely but I will ask anyway:
Is it possible that the problem you are seeing isn't caused by the
"famous" CPU bug mentioned here:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016351.html
The DTLB error handler needs DAR to be set correctly and since the
dcbX instructions doesn't set DAR in either DTLB Miss nor DTLB Error you
may end up trying to fix the wrong address.
Jocke
^ permalink raw reply
* Re: PCI Arbiter on PPC440GX?
From: Matt Porter @ 2005-04-05 21:41 UTC (permalink / raw)
To: Sanjay Bajaj; +Cc: linuxppc-embedded
In-Reply-To: <0007F077BB3476449151699150E8FEA20592AE@exchange.tsi-telsys.com>
On Tue, Apr 05, 2005 at 05:20:22PM -0400, Sanjay Bajaj wrote:
<snip>
Please don't post the same message to linuxppc-dev and linuxppc-embedded.
Pick one or the other based on the list description.
-Matt
^ permalink raw reply
* Re: PCI Arbiter on PPC440GX?
From: Matt Porter @ 2005-04-05 21:36 UTC (permalink / raw)
To: Sanjay Bajaj; +Cc: linuxppc-embedded
In-Reply-To: <0007F077BB3476449151699150E8FEA20592AF@exchange.tsi-telsys.com>
[This is clearly embedded stuff, redirecting to the embedded list]
On Tue, Apr 05, 2005 at 05:21:22PM -0400, Sanjay Bajaj wrote:
> How do I enable/disable PCI Arbiter on PPC440GX?
You must RTFM the PPC440GX UM in PLB-PCIX Bridge Controller chapter.
In the PCI Arbiter section, it tells you how to set CPC0_STRP1[PAE]
to enable/disable the internal PCI arbiter. They didn't even try to
hide it...
-Matt
^ permalink raw reply
* PCI Arbiter on PPC440GX?
From: Sanjay Bajaj @ 2005-04-05 21:21 UTC (permalink / raw)
To: linuxppc-dev
How do I enable/disable PCI Arbiter on PPC440GX?
Thanks in advance.
Sanjay
^ permalink raw reply
* PCI Arbiter on PPC440GX?
From: Sanjay Bajaj @ 2005-04-05 21:20 UTC (permalink / raw)
To: linuxppc-embedded
How do I enable/disable PCI Arbiter on PPC440GX?
Thanks in advance.
Sanjay
^ permalink raw reply
* RE: FCC Ethernet startup crash
From: Rune Torgersen @ 2005-04-05 18:53 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
> From: Dan Malek [mailto:dan@embeddededge.com]=20
> On Apr 5, 2005, at 12:41 PM, Rune Torgersen wrote:
>=20
> > Without calling fcc_restart in the start, I get lots of=20
> "eth0: tx queue
> > full!." messages.
>=20
> Do you tftp boot your kernel using the boot rom? Does the
> boot rom disable the Ethernet before calling the kernel?
Yes, I tftp the kernel, using U-Boot (1.1.2 CVS Head as of 11-20-04).
Haven't looked at the code, but I think it disablesd the FCC Ethernets
(Have seen discussions about htat on u-boot mailing list before)
The patch Stefan Nickl gave to me works perfectly, and all it does is
basically move the fcc_restart.
The kernel was still calling fcc_restart twiche per FCC at startup (one
time on init_fcc_startup, and then again in fcc_open), now it just calls
it twice in fcc_open. Seems to work.
^ permalink raw reply
* Re: somewhat OT -- trying to build code on the fly then run it
From: Chris Friesen @ 2005-04-05 17:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1112663005.26086.134.camel@gaston>
Benjamin Herrenschmidt wrote:
> bla can only be used for small addresses (or very high addresses), and
> it doesn't take a register argument but an absolute address. You want
> something different, more like
>
> mtctr %2
> bctrl
>
> Though you also need to add proper "clobber" constraints to indicate to
> the compiler what will be clobbered by the routine you are calling (look
> at the syscall macros of the kernel for an example of rather standard
> clobber lists).
Thanks for the tip. With those changes, the code runs perfectly. For
posterity, the new function looks like this:
int dotest(void *p)
{
int i=0;
asm volatile (" \n\
mr 3,%1 \n\
mtctr %2 \n\
bctrl \n\
mr %0,3 \n"
: "=r" (i)
: "r" (i), "r" (p)
: "ctr", "lr");
return i;
}
The bad news is that it seems to indicate that our kernel code to flush
the icache doesn't seem to work. I'll open a new thread for that.
Chris
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Marcelo Tosatti @ 2005-04-05 11:41 UTC (permalink / raw)
To: Dan Malek; +Cc: Paul Mackerras, linux-ppc-embedded
In-Reply-To: <ba633c3356ff1ec71f53d4a0998132ff@embeddededge.com>
On Tue, Apr 05, 2005 at 11:58:17AM -0400, Dan Malek wrote:
>
> On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
>
> >Problem is that the "dcbst" instruction will, _sometimes_ (the
> >failure/success rate is about 1/4
> >with my test application) fault as a _write_ operation on the data.
>
> Oh, geeze .... It's all coming back to me now ....
>
> The 8xx cache operations don't always operate as defined in the PEM.
> There are likely to be some archive discussions within the Freescale
> knowledge data base that describe the different behaviors I've seen
> with the chip variants and revisions. I can't find any of those e-mail
> discussions, so I'll try to recall from memory.
>
> The PEM cache instructions are all implemented in a microcode that
> uses the 8xx unique cache control SPRs. Depending upon the state
> of the cache and MMU, it seems in some cases the EA translation is
> subject to a "normal" protection match instead of a load operation
> match.
>
> The behavior of these operations isn't consistent across all of the 8xx
> processor revisions, especially with early silicon if people are still
> using those. During conversations with Freescale engineers, it seems
> the only guaranteed operation was to use the 8xx unique SPRs, but
> I think I only did that in 8xx specific functions.
How sweet. :)
> We have way too much code in the TLB exception handlers already,
> so let's just try a tlbia of the EA in the update_mmu_cache, with an
> #ifdef
> for the 8xx.
Are you sure this is the best solution ?
Problem is that update_mmu_cache() is called from other context's where
the tlb invalidate is not necessary (because it has already been invalidated).
For example all ptep_set_access_flags() (which does the tlb invalidate) ->
update_mmu_cache() sequences.
Moreover jumping directly from DataTLBMiss to the page fault handler
shortcuts the process: there is no need to jump back to execution if we
know in advance that DataTLBError exception is going to happen.
But hey, you are the boss. Even with the above facts you prefer
to leave the DataTLBMiss untouched?
About size: I think it is the smaller expection handler present.
> It seems if the dcbst causes a TLB miss during execution,
> it does the right thing.
It should always cause a miss because the TLB entry is marked as invalid
(DataTLBMiss just created the invalid TLB entry).
So even when a miss happens, it can do the wrong thing.
Right?
> We may want to make the dcbxxx instructions
> some
> kind of macro, so on 8xx we can include such operations in otherwise
> "standard" software.
I'm a bit lost here: you're talking about the kernel side of things only
or userspace also?
The latter would require "GNU as" dcbxxx macro? Hum...
> Thanks for the great work!
Your help has been invaluable!
I feel very good after many days of debugging pain. :)
^ permalink raw reply
* Re: FCC Ethernet startup crash
From: Dan Malek @ 2005-04-05 16:56 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859338@ismail.innsys.innovsys.com>
On Apr 5, 2005, at 12:41 PM, Rune Torgersen wrote:
> Without calling fcc_restart in the start, I get lots of "eth0: tx queue
> full!." messages.
Do you tftp boot your kernel using the boot rom? Does the
boot rom disable the Ethernet before calling the kernel?
Thanks.
-- Dan
^ permalink raw reply
* Recommendations: Small Embedded PPC chip with FPU
From: Joshua Lamorie @ 2005-04-05 15:55 UTC (permalink / raw)
To: linuxppc-embedded
Gidday there,
I am looking for a new PowerPC for some controls applications and I was
wondering if anyone on this list might make some recommendations. I
will be fabricating the board, so I'm just interested in the CPU.
Currently I'm doing everything on a Virtex-II Pro (PPC 405).
I'm considering the MPC5200, but I would love to have something in a
smaller package.
Requirements:
- Linux support
- PowerPC w >= 16k D,I Cache
- FPU
- Onboard memory controller (SDRAM or DDR)
- >= 300 MHz
- Industrial temperature (-40 to +85)
- package size < 27mmx27mm
- everything else is icing
Any suggestions welcome.
I'm sorry if this is somewhat off topic.
Joshua
--
Xiphos Technologies
(514) 848-9640 x227
(514) 848-9644 fax
www.xiplink.com
_______________________________________________
The information transmitted is intended only for the
person or entity to which it is addressed and may contain
confidential and/or privileged material. If you have
received this in error, please contact the sender and delete
this communication and any copy immediately. Thank you.
^ permalink raw reply
* Re: ASM formatting rules?
From: Dan Malek @ 2005-04-05 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Tom Rini, ML linuxppc-embedded
In-Reply-To: <16976.57251.983884.605143@cargo.ozlabs.ibm.com>
On Apr 4, 2005, at 2:33 AM, Paul Mackerras wrote:
> However, apart from that - i.e. for code that is used on all PPC
> platforms, or if people are asking what the style should be - then the
> style is no spaces between the operands.
OK .... I'll try to change my old habits :-)
-- Dan
^ permalink raw reply
* Re: somewhat OT -- trying to build code on the fly then run it
From: Chris Friesen @ 2005-04-05 16:43 UTC (permalink / raw)
To: Fillod Stephane; +Cc: linuxppc-dev
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D4F0D2D@rennsmail02.eu.thmulti.com>
Fillod Stephane wrote:
> Chris Friesen wrote:
>
>>I'm writing a testcase to test some code we wrote to allow userspace
> to flush the whole dcache and invalidate the whole icache.
>
>
> Your testcase sounds like this kernel module for RT load generator:
>
> http://rtai.dk/cgi-bin/gratiswiki.pl?Latency_Killer/Flushy
Unfortunately that code calls flush_instruction_cache(), which doesn't
work on the 970 in the ppc tree, and doesn't even exist anymore in the
ppc64 tree.
Chris
^ permalink raw reply
* RE: FCC Ethernet startup crash
From: Rune Torgersen @ 2005-04-05 16:41 UTC (permalink / raw)
To: Stefan Nickl; +Cc: linuxppc-embedded
Thanks....
That whole patch works beautifully.
Had to apply the whole thing (so fcc_restart gets called in the start,
and end of fcc_open) for it to work.
Without calling fcc_restart in the start, I get lots of "eth0: tx queue
full!." messages.
> -----Original Message-----
> From: Stefan Nickl [mailto:Stefan.Nickl@kontron.com]=20
> Sent: Tuesday, April 05, 2005 10:57
> To: Rune Torgersen
> Cc: linuxppc-embedded
> Subject: Re: FCC Ethernet startup crash
>=20
> On Tue, 2005-04-05 at 10:37 -0500, Rune Torgersen wrote:
> > I've been running into the old problem of the kernel ip=20
> stack crasheing
> > the kernel, because of early packets again.
> >=20
> > This has been mentioned on this list several times before, but the
> > worarounds that used to work doesn't seem to work anymore.
> > (like changing the order of things in ip_init())
> >=20
> > As far as I can tell, it is because the FCC enet drivers starts to
> > receive packets way before the ip stack is initialized.
> >=20
> > Does anybody have any good ideas on how to fix this?
>=20
> Maybe you want to try my version:
>=20
> http://ozlabs.org/ppc32-patches/patch.pl?id=3D14
>=20
> Or is it equal to your (no longer working) solution?
>=20
> --=20
> Stefan Nickl
> Kontron Modular Computers
>=20
>=20
>=20
>=20
^ permalink raw reply
* RE: FCC Ethernet startup crash
From: Rune Torgersen @ 2005-04-05 16:27 UTC (permalink / raw)
To: Stefan Nickl; +Cc: linuxppc-embedded
Ahhh....
I see what happened....
Basically only the last part of that patch has been applied to the 2.6
kernels..
fcc_restart gets called both in init_fcc_startup *and* fcc_open.
=20
I'll try to remove the fcc_restart in init_fcc_startup, and see what
happens.
> -----Original Message-----
> From: Stefan Nickl [mailto:Stefan.Nickl@kontron.com]=20
> Sent: Tuesday, April 05, 2005 10:57
> To: Rune Torgersen
> Cc: linuxppc-embedded
> Subject: Re: FCC Ethernet startup crash
>=20
> On Tue, 2005-04-05 at 10:37 -0500, Rune Torgersen wrote:
> > I've been running into the old problem of the kernel ip=20
> stack crasheing
> > the kernel, because of early packets again.
> >=20
> > This has been mentioned on this list several times before, but the
> > worarounds that used to work doesn't seem to work anymore.
> > (like changing the order of things in ip_init())
> >=20
> > As far as I can tell, it is because the FCC enet drivers starts to
> > receive packets way before the ip stack is initialized.
> >=20
> > Does anybody have any good ideas on how to fix this?
>=20
> Maybe you want to try my version:
>=20
> http://ozlabs.org/ppc32-patches/patch.pl?id=3D14
>=20
> Or is it equal to your (no longer working) solution?
>=20
> --=20
> Stefan Nickl
> Kontron Modular Computers
>=20
>=20
>=20
>=20
^ permalink raw reply
* Perfmon feature
From: Andy Fleming @ 2005-04-05 16:21 UTC (permalink / raw)
To: Linux/PPC Development
I'm adding oprofile support for 7450 (and derivative) processors, and
I'm considering adding a couple PPC_FEATURE bits (one for classic, and
one for fsl-book-e perfmon).
Reasons:
1) The need to distinguish between Freescale Book-E processors with
performance monitor support, Classic PPC processors with perfmon
support, and processors without perfmon support. (ie - 7450 parts will
have support, but 7410 parts will not for now).
2) Applications could determine if these features were present, and
decide between using mfspr and mfpmr instructions to read the counters
from user-space.
Thoughts, objections?
Andy Fleming
Open Source Team
Freescale Semiconductor, Inc
^ permalink raw reply
* Re: [PATCH] invalid instructions in kernel mode
From: Dan Malek @ 2005-04-05 16:16 UTC (permalink / raw)
To: Fillod Stephane; +Cc: linuxppc-dev
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D4F0D30@rennsmail02.eu.thmulti.com>
On Apr 5, 2005, at 8:24 AM, Fillod Stephane wrote:
> Speaking for myself, I don't plan on using the SPE FPU of the e500,
Why?
> It seems you didn't like my last patch which lets make enter the
> math-emu
> subdirectory only to compile the load/store (8xx could do that too).
> Would you prefer a fix along the line of Soft_emulate_8xx() ?
I'm not sure. I need to think about it for a moment. I was rushed to
do some travel, and now I'm back to work on it.
> I don't know what Kumar and his team have in mind for the e500,
The e500 tools use the SPE FPU for all single precision floating
point. For our initial development we used the floating point
emulation.
-- Dan
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Dan Malek @ 2005-04-05 15:58 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Paul Mackerras, linux-ppc-embedded
In-Reply-To: <20050404191718.GA30281@logos.cnet>
On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
> Problem is that the "dcbst" instruction will, _sometimes_ (the
> failure/success rate is about 1/4
> with my test application) fault as a _write_ operation on the data.
Oh, geeze .... It's all coming back to me now ....
The 8xx cache operations don't always operate as defined in the PEM.
There are likely to be some archive discussions within the Freescale
knowledge data base that describe the different behaviors I've seen
with the chip variants and revisions. I can't find any of those e-mail
discussions, so I'll try to recall from memory.
The PEM cache instructions are all implemented in a microcode that
uses the 8xx unique cache control SPRs. Depending upon the state
of the cache and MMU, it seems in some cases the EA translation is
subject to a "normal" protection match instead of a load operation
match.
The behavior of these operations isn't consistent across all of the 8xx
processor revisions, especially with early silicon if people are still
using those. During conversations with Freescale engineers, it seems
the only guaranteed operation was to use the 8xx unique SPRs, but
I think I only did that in 8xx specific functions.
We have way too much code in the TLB exception handlers already,
so let's just try a tlbia of the EA in the update_mmu_cache, with an
#ifdef
for the 8xx. It seems if the dcbst causes a TLB miss during execution,
it does the right thing. We may want to make the dcbxxx instructions
some
kind of macro, so on 8xx we can include such operations in otherwise
"standard" software.
Thanks for the great work!
-- Dan
^ 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