* Re: eth0 autonegotation 8260
From: aris @ 2005-06-30 14:11 UTC (permalink / raw)
To: Samuel Osorio Calvo; +Cc: linuxppc-embedded
In-Reply-To: <s2c4153f.011@scms1.sc.signaal.nl>
> First of all sorry if this answer has been answered before, I have looked into the archives and did not find the answer.
>
> We are using a 8260 processor with ELDK 3.1.1, kernel 2.4.25 patched with lck1. We have configured the kernel with USE_MDIO and LXT971.
> The problem we face is that the boot process stops after displaying the configuration of the card:
> eth0: config: autonegotiation on, 100FDX,...
> and after the board seems to freeze.
>
> Following the code, I located the error in the startup command of the LXT971, concretely in the line setting the autonegotiation:
> {mk_mii_write(MII_REG_CR, 0x1200), NULL}, /* autonegotiate */
I have the same here but it doesn't freezes, it just doesn't works :).
(maybe it "freezes" because next step depends on the eth like RARP?)
I digged into LXT971 datasheet and 0x1200 appears to be correct. I was thinking
in add an module option to manually set it (and thus avoiding the need to use
ethtool). Any MII guru around to help us on this?
--
Aristeu
^ permalink raw reply
* Re: eth0 autonegotation 8260
From: Alex Zeffertt @ 2005-06-30 14:32 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded
In-Reply-To: <006201c57d7c$b36bcb90$0301a8c0@chuck2>
> >We are using a 8260 processor with ELDK 3.1.1, kernel 2.4.25 patched with
> >lck1. We have configured the kernel with USE_MDIO
> >and LXT971.
> >The problem we face is that the boot process stops after displaying the
> >configuration of the card:
> >eth0: config: autonegotiation on, 100FDX,...
> >and after the board seems to freeze.
> >
> >Can anybody provide some feedback on how to check what can be misconfigured
> >or where to look for the error???
>
> Check that the interrupt from the LXT971 is configured correctly.
> The code is probably waiting for this interrupt to tell it that negotiation
> is complete
>
On a similar note... I've noticed that the fcc_enet driver does not appear to
detect when the link goes down, or re-autonegotiate when it comes back up. I
wonder if anybody has a fix for this?
PS I too am using the ELDK 3.1.1 linux-2.4.25 kernel, but with a PM828 devel
board.
^ permalink raw reply
* Re: eth0 autonegotation 8260
From: Mark Chambers @ 2005-06-30 14:04 UTC (permalink / raw)
To: Samuel Osorio Calvo, linuxppc-embedded
In-Reply-To: <s2c4153f.011@scms1.sc.signaal.nl>
>We are using a 8260 processor with ELDK 3.1.1, kernel 2.4.25 patched with
lck1. We have configured the kernel with USE_MDIO >and LXT971.
>The problem we face is that the boot process stops after displaying the
configuration of the card:
>eth0: config: autonegotiation on, 100FDX,...
>and after the board seems to freeze.
>
>Can anybody provide some feedback on how to check what can be misconfigured
or where to look for the error???
Check that the interrupt from the LXT971 is configured correctly.
The code is probably waiting for this interrupt to tell it that negotiation
is complete
Mark Chambers
^ permalink raw reply
* eth0 autonegotation 8260
From: Samuel Osorio Calvo @ 2005-06-30 13:52 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
First of all sorry if this answer has been answered before, I have looked =
into the archives and did not find the answer.
We are using a 8260 processor with ELDK 3.1.1, kernel 2.4.25 patched with =
lck1. We have configured the kernel with USE_MDIO and LXT971.
The problem we face is that the boot process stops after displaying the =
configuration of the card:
eth0: config: autonegotiation on, 100FDX,...
and after the board seems to freeze.
Following the code, I located the error in the startup command of the =
LXT971, concretely in the line setting the autonegotiation:
{mk_mii_write(MII_REG_CR, 0x1200), NULL}, /* autonegotiate */=20
Can anybody provide some feedback on how to check what can be misconfigured=
or where to look for the error???=20
Thanks in advance,
Samuel.
Unclassified.
^ permalink raw reply
* Re: [PATCH] 8xx: get_mmu_context() for (very) FEW_CONTEXTS and KERNEL_PREEMPT race/starvation issue
From: Guillaume Autran @ 2005-06-30 13:54 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050629193846.GA4748@logos.cnet>
[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]
Well, disabling preemption in the get_mmu_context() does not help much...
I'm trying to disable preemption only inside destroy_mmu_context() as
suggested.
Will keep you posted.
Guillaume.
Marcelo Tosatti wrote:
>On Thu, Jun 30, 2005 at 09:26:07AM +1000, Benjamin Herrenschmidt wrote:
>
>
>>>Execution is resumed exactly where it has been interrupted.
>>>
>>>
>>>
>>>>The idea behind my patch was to get rid of that nr_free_contexts counter
>>>>that is (I thing) redundant with the context_map.
>>>>
>>>>
>>>Apparently its there to avoid the spinlock exactly on !FEW_CONTEXTS machines.
>>>
>>>I suppose that what happens is that get_mmu_context() gets preempted after stealing
>>>a context (so nr_free_contexts = 0), but before setting next_mmu_context to the
>>>next entry
>>>
>>>next_mmu_context = (ctx + 1) & LAST_CONTEXT;
>>>
>>>
>>Ugh ? Can switch_mm() be preempted at all ? Did I miss yet another
>>"let's open 10 gazillion races for gun" Ingo patch ?
>>
>>
>
>Doh nope it can't - my bad.
>
>
>
>>>So if the now running higher prio tasks calls switch_mm() (which is likely to happen)
>>>it loops forever on atomic_dec_if_positive(&nr_free_contexts), while steal_context()
>>>sees "mm->context == CONTEXT".
>>>
>>>
>>I think the race is only when destroy_context() is preempted, but maybe
>>I missed something.
>>
>>
>
>Nope, I think you are right. My "theory" is obviously flawed now.
>
>There seem to be several contexts where destroy_context() could be called
>with preempt enabled - I should have been shutup in the first place :)
>
>Lets wait for Guillaume to test...
>
>
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: Type: text/html, Size: 2658 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH] ppc misusing NTP's time_offset value
From: Kumar Gala @ 2005-06-30 11:53 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: linuxppc-dev, linux-kernel, johnstul
In-Reply-To: <200506301015.j5UAFMOn023481@harpo.it.uu.se>
I think you forgot the patch.
- kumar
On Jun 30, 2005, at 5:15 AM, Mikael Pettersson wrote:
> On Wed, 29 Jun 2005 15:05:51 -0700, john stultz wrote:
>
>> As part of my timeofday rework, I've been looking at the NTP
>>
> code and I
>
>> noticed that the PPC architecture is apparently misusing the NTP's
>> time_offset (it is a terrible name!) value as some form of timezone
>> offset. This could cause problems when time_offset changed by the NTP
>> code.
>>
>> This patch changes the PPC code so it uses a more clear local
>>
> variable:
>
>> timezone_offset.
>>
>> Could a PPC maintainer verify this is correct?
>>
>> Let me know if you have any comments or feedback.
>>
>
> arch/ppc/kernel/time.c used to have a 'static long time_offset;'
> variable. Ulthough unrelated, this declaration clashed with the
> one for kernel/time.c, causing compile-time errors with gcc4.
> I submitted a fix for this in February, which renamed ppc's local
> variable, and it was ACKed by Tom Rini and queued for 2.6.12.
>
> However, the patch that actually went into 2.6.12 was different:
> it just removed ppc's local variable, making arch/ppc/kernel/time.c
> now share kernel/time.c's variable. At the time I assumed someone
> had proved that the two modules _should_ share state, so I didn't
> make a fuss about it.
>
> Your patch brings the semantics back to what it was prior to 2.6.12.
>
> /Mikael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* PCC440GX custom board configuration
From: David Grab @ 2005-06-30 11:26 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
i have a custom PPC 440 GX board which should run linux 2.6.11.6 kernel. I
initialized the board with u-boot getting boot console on UART1 to start the
kernel with bootm command.
Hardware details:
PPC 440 GX CPU
2 * 256 MB RAM
2 * 8 MB Flash
EM Marvin RTC V3020 (seems not supported by linux?)
Now i want to configure Linux to match my custom board. I ported my board
based on ocotea board configuration files and excluded all the stuff i don´t
need. My kernel seems to load but get stuck on calibrating delay loop and
loops between update_proces_times and __delay (at address 0xC0003400) until
it reboots. Seems like i didn´t match the BogoMips calculation. Actually i
don´t use the RTC (i comment out all TODC functions). I think this cause the
problem. So what i have to do to boot without RTC or has someone my RTC
running with linux?
Thanks for advice,
David
^ permalink raw reply
* Re: [RFC][PATCH] ppc misusing NTP's time_offset value
From: Mikael Pettersson @ 2005-06-30 10:15 UTC (permalink / raw)
To: benh, johnstul, linux-kernel, paulus; +Cc: linuxppc-dev
On Wed, 29 Jun 2005 15:05:51 -0700, john stultz wrote:
> As part of my timeofday rework, I've been looking at the NTP code and I
>noticed that the PPC architecture is apparently misusing the NTP's
>time_offset (it is a terrible name!) value as some form of timezone
>offset. This could cause problems when time_offset changed by the NTP
>code.
>
> This patch changes the PPC code so it uses a more clear local variable:
>timezone_offset.
>
>Could a PPC maintainer verify this is correct?
>
>Let me know if you have any comments or feedback.
arch/ppc/kernel/time.c used to have a 'static long time_offset;'
variable. Ulthough unrelated, this declaration clashed with the
one for kernel/time.c, causing compile-time errors with gcc4.
I submitted a fix for this in February, which renamed ppc's local
variable, and it was ACKed by Tom Rini and queued for 2.6.12.
However, the patch that actually went into 2.6.12 was different:
it just removed ppc's local variable, making arch/ppc/kernel/time.c
now share kernel/time.c's variable. At the time I assumed someone
had proved that the two modules _should_ share state, so I didn't
make a fuss about it.
Your patch brings the semantics back to what it was prior to 2.6.12.
/Mikael
^ permalink raw reply
* Re: [linux-usb-devel] USB host on Freescale MPC880
From: Jan Damborsky @ 2005-06-30 8:22 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linux-usb-devel, linuxppc-embedded
In-Reply-To: <41EE03FF.3040609@intracom.gr>
Pantelis Antoniou wrote:
>
> I have a fairly hacked over version of the original USB host driver that
> works for 87x/88x.
>
We have developed our board with MPC880 and we would like
to try to use 8xx USB host interface with kernel version 2.4.25.
I would like to ask you, if we could use your USB host driver
and if yes where it is possible to get it.
Best regards
Jan Damborsky
^ permalink raw reply
* Re: set_phys_avail() futures question
From: Kumar Gala @ 2005-06-30 5:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1120107968.31924.42.camel@gaston>
>>>> I'd like to get your opinion on what the future of
>>>> arch/ppc/mm/init.c/set_phys_avail() looks like.
>>>> Currently, its job is to traverse the mem_pieces data
>>>> and remove a whole series of #ifdef'ed regions of
>>>> memory based on configuration options. These regions
>>>> are the initrd, the RTAS data, and the AGP special page.
>>>>
>>>> Do you see these regions as being explicitly listed in
>>>> the proposed "reserved memory blocks" area of the Flat
>>>> Dev Tree header structure?
>>>>
>>>>
>>>
>>> Yes. initrd for sure, RTAS too, AGP special page well ... I have to
>>> check if we still use that one at all... but it's not allocated in
>>> prom_init so it may need it's own little bit here still.
>>>
>>
>> What this implies to me is that what a flattened OF tree we will no
>> longer need to call set_phys_avail().
>>
>
> It will have to do some equivalent to transfer the reserve map to
> mem_pieces tho ...
Agreed, but I think we expect that to happen in platform_init now.
When we walk the flatten tree we will build up the phys_avail
mem_pieces data structure.
- kumar
^ permalink raw reply
* Re: set_phys_avail() futures question
From: Benjamin Herrenschmidt @ 2005-06-30 5:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <3FD36254-F985-4040-A68A-72EEB212D8A3@freescale.com>
On Thu, 2005-06-30 at 00:06 -0500, Kumar Gala wrote:
> On Jun 29, 2005, at 6:56 PM, Benjamin Herrenschmidt wrote:
>
> > On Wed, 2005-06-29 at 16:14 -0500, Jon Loeliger wrote:
> >
> >> Ben (primarily),
> >>
> >> I'd like to get your opinion on what the future of
> >> arch/ppc/mm/init.c/set_phys_avail() looks like.
> >> Currently, its job is to traverse the mem_pieces data
> >> and remove a whole series of #ifdef'ed regions of
> >> memory based on configuration options. These regions
> >> are the initrd, the RTAS data, and the AGP special page.
> >>
> >> Do you see these regions as being explicitly listed in
> >> the proposed "reserved memory blocks" area of the Flat
> >> Dev Tree header structure?
> >>
> >
> > Yes. initrd for sure, RTAS too, AGP special page well ... I have to
> > check if we still use that one at all... but it's not allocated in
> > prom_init so it may need it's own little bit here still.
>
> What this implies to me is that what a flattened OF tree we will no
> longer need to call set_phys_avail().
It will have to do some equivalent to transfer the reserve map to
mem_pieces tho ...
Ben.
^ permalink raw reply
* Re: set_phys_avail() futures question
From: Kumar Gala @ 2005-06-30 5:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1120089411.31924.36.camel@gaston>
On Jun 29, 2005, at 6:56 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2005-06-29 at 16:14 -0500, Jon Loeliger wrote:
>
>> Ben (primarily),
>>
>> I'd like to get your opinion on what the future of
>> arch/ppc/mm/init.c/set_phys_avail() looks like.
>> Currently, its job is to traverse the mem_pieces data
>> and remove a whole series of #ifdef'ed regions of
>> memory based on configuration options. These regions
>> are the initrd, the RTAS data, and the AGP special page.
>>
>> Do you see these regions as being explicitly listed in
>> the proposed "reserved memory blocks" area of the Flat
>> Dev Tree header structure?
>>
>
> Yes. initrd for sure, RTAS too, AGP special page well ... I have to
> check if we still use that one at all... but it's not allocated in
> prom_init so it may need it's own little bit here still.
What this implies to me is that what a flattened OF tree we will no
longer need to call set_phys_avail().
- kumar
^ permalink raw reply
* [PATCH] ppc32: Fix pointer check for MPC8540 ADS device
From: Kumar Gala @ 2005-06-30 5:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Editor snafu in which the call to ppc_sys_get_pdata got inside the if
check instead of before it. Oops.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit e82df07a507588f1f0cc9da544934b4a737e2e84
tree 2e9642efcb34f846444bc288d3c4d7c384c00348
parent 6bd7d9f21de5992db4851f9be88c2e20b967f3d2
author Kumar K. Gala <kumar.gala@freescale.com> Thu, 30 Jun 2005 01:35:53 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 30 Jun 2005 01:35:53 -0500
arch/ppc/platforms/85xx/mpc8540_ads.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/platforms/85xx/mpc8540_ads.c b/arch/ppc/platforms/85xx/mpc8540_ads.c
--- a/arch/ppc/platforms/85xx/mpc8540_ads.c
+++ b/arch/ppc/platforms/85xx/mpc8540_ads.c
@@ -111,8 +111,8 @@ mpc8540ads_setup_arch(void)
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
+ pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_FEC);
if (pdata) {
- pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_FEC);
pdata->board_flags = 0;
pdata->interruptPHY = MPC85xx_IRQ_EXT5;
pdata->phyid = 3;
^ permalink raw reply
* Re: [PATCH] 8xx: get_mmu_context() for (very) FEW_CONTEXTS and KERNEL_PREEMPT race/starvation issue
From: Eugene Surovegin @ 2005-06-30 0:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ppc-embedded
In-Reply-To: <1120087568.31924.14.camel@gaston>
On Thu, Jun 30, 2005 at 09:26:07AM +1000, Benjamin Herrenschmidt wrote:
>
> > Execution is resumed exactly where it has been interrupted.
> >
> > > The idea behind my patch was to get rid of that nr_free_contexts counter
> > > that is (I thing) redundant with the context_map.
> >
> > Apparently its there to avoid the spinlock exactly on !FEW_CONTEXTS machines.
> >
> > I suppose that what happens is that get_mmu_context() gets preempted after stealing
> > a context (so nr_free_contexts = 0), but before setting next_mmu_context to the
> > next entry
> >
> > next_mmu_context = (ctx + 1) & LAST_CONTEXT;
>
> Ugh ? Can switch_mm() be preempted at all ? Did I miss yet another
> "let's open 10 gazillion races for gun" Ingo patch ?
No, it can't. schedule() disables preemption at the very beginning.
--
Eugene
^ permalink raw reply
* Re: [PATCH] 8xx: get_mmu_context() for (very) FEW_CONTEXTS and KERNEL_PREEMPT race/starvation issue
From: Marcelo Tosatti @ 2005-06-29 19:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ppc-embedded
In-Reply-To: <1120087568.31924.14.camel@gaston>
On Thu, Jun 30, 2005 at 09:26:07AM +1000, Benjamin Herrenschmidt wrote:
>
> > Execution is resumed exactly where it has been interrupted.
> >
> > > The idea behind my patch was to get rid of that nr_free_contexts counter
> > > that is (I thing) redundant with the context_map.
> >
> > Apparently its there to avoid the spinlock exactly on !FEW_CONTEXTS machines.
> >
> > I suppose that what happens is that get_mmu_context() gets preempted after stealing
> > a context (so nr_free_contexts = 0), but before setting next_mmu_context to the
> > next entry
> >
> > next_mmu_context = (ctx + 1) & LAST_CONTEXT;
>
> Ugh ? Can switch_mm() be preempted at all ? Did I miss yet another
> "let's open 10 gazillion races for gun" Ingo patch ?
Doh nope it can't - my bad.
> > So if the now running higher prio tasks calls switch_mm() (which is likely to happen)
> > it loops forever on atomic_dec_if_positive(&nr_free_contexts), while steal_context()
> > sees "mm->context == CONTEXT".
>
> I think the race is only when destroy_context() is preempted, but maybe
> I missed something.
Nope, I think you are right. My "theory" is obviously flawed now.
There seem to be several contexts where destroy_context() could be called
with preempt enabled - I should have been shutup in the first place :)
Lets wait for Guillaume to test...
^ permalink raw reply
* Re: set_phys_avail() futures question
From: Benjamin Herrenschmidt @ 2005-06-29 23:56 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1120079668.1798.98.camel@cashmere.sps.mot.com>
On Wed, 2005-06-29 at 16:14 -0500, Jon Loeliger wrote:
> Ben (primarily),
>
> I'd like to get your opinion on what the future of
> arch/ppc/mm/init.c/set_phys_avail() looks like.
> Currently, its job is to traverse the mem_pieces data
> and remove a whole series of #ifdef'ed regions of
> memory based on configuration options. These regions
> are the initrd, the RTAS data, and the AGP special page.
>
> Do you see these regions as being explicitly listed in
> the proposed "reserved memory blocks" area of the Flat
> Dev Tree header structure?
Yes. initrd for sure, RTAS too, AGP special page well ... I have to
check if we still use that one at all... but it's not allocated in
prom_init so it may need it's own little bit here still.
> If so, then they would follow the same conceptual flow
> as the ppc64 reservations in the LMB. They would then
> be SetPagReserved() and removed from the do_init_bootmem()
> regions of memory as well.
I'm not sure we actually need to explicitely call SetPageReserved(), do
we ? As long as they are not returned to the free pool ... Oh well,
that can't hurt :)
Ben.
^ permalink raw reply
* Re: [PATCH] use correct register names in arch/ppc/kernel/relocate_kernel.S
From: Benjamin Herrenschmidt @ 2005-06-29 23:54 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Andrew Morton, linuxppc-dev, Eric Biederman, Olaf Hering
In-Reply-To: <20750c905c7c0f2eccc3eba6dc1421db@kernel.crashing.org>
On Wed, 2005-06-29 at 20:08 +0200, Segher Boessenkool wrote:
> > --- linux-2.6.13-rc1.orig/arch/ppc/kernel/relocate_kernel.S
> > +++ linux-2.6.13-rc1/arch/ppc/kernel/relocate_kernel.S
> > @@ -34,9 +34,9 @@ relocate_new_kernel:
> >
> > mr r8, r0
> > ori r8, r8, MSR_RI|MSR_ME
> > - mtspr SRR1, r8
> > + mtspr SPRN_SRR1, r8
> > addi r8, r4, 1f - relocate_new_kernel
> > - mtspr SRR0, r8
> > + mtspr SPRN_SRR0, r8
> > sync
> > rfi
>
> Or just mtsrr0 c.q. mtsrr1
They are lovely but shits me when I grep for SPRN_SRR0 :) I tend to
prefer consistency here and so if we start using mtsrr0/1, then we
should change the whole kernel at once and not have a mix of SPRN_* and
mt*
Ben.
^ permalink raw reply
* Re: [PATCH] 8xx: map_page() skip pinned region and tlbie debugging aid
From: Benjamin Herrenschmidt @ 2005-06-29 23:31 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050629171906.GD4262@logos.cnet>
On Wed, 2005-06-29 at 14:19 -0300, Marcelo Tosatti wrote:
> Once the physical->virtual mapping for device IO space are set
> with io_block_mapping() (or with ioremap() for dynamic virtual
> addresses), why would you want to ioremap() the physical address
> again???
>
> PS: I've had a quick try at converting the IMMAP to use
> ioremap instead (and have that dynamic virtual address stored
> in a pointer), changed drivers to use that pointer instead of
> hardcoded "IMMAP". Didnt work immediately :) Its not that the
> idea?
No, you are missing the point. The idea is:
- Everything should use ioremap(), that is the proper interface for a
driver or whatever else to get a virtual address for a physical area.
- The architecture may use io_block_mapping() to create large fixed
mappings (BATs, CAMs, 8M TLBs, ...) for some physical areas as an
optimisation. Those should be transparent to later code, that is you
shouldn't have to care about their existence when you are driver. You
just call ioremap. If that space was already part of a large fixed
mapping, then ioremap will just return an address within that range.
- The debate between Dan and me here is about the semantics of
io_block_mapping(). Currently, it takes both the physical and virtual
address. Thus you hard-code your mappings at known virtual addresses. I
find this unnecessary and source of problems, and I want to add to
io_block_mapping() a way to "allocate" virtual addresses dynamically (by
simply moving down ioremap_bot like ioremap would do if called that
early). That way, there is no "magic" hard coded virtual addresses at
all anymore.
Ben.
^ permalink raw reply
* Re: [PATCH] 8xx: get_mmu_context() for (very) FEW_CONTEXTS and KERNEL_PREEMPT race/starvation issue
From: Benjamin Herrenschmidt @ 2005-06-29 23:26 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: ', linux-ppc-embedded
In-Reply-To: <20050629155445.GA3560@logos.cnet>
> Execution is resumed exactly where it has been interrupted.
>
> > The idea behind my patch was to get rid of that nr_free_contexts counter
> > that is (I thing) redundant with the context_map.
>
> Apparently its there to avoid the spinlock exactly on !FEW_CONTEXTS machines.
>
> I suppose that what happens is that get_mmu_context() gets preempted after stealing
> a context (so nr_free_contexts = 0), but before setting next_mmu_context to the
> next entry
>
> next_mmu_context = (ctx + 1) & LAST_CONTEXT;
Ugh ? Can switch_mm() be preempted at all ? Did I miss yet another
"let's open 10 gazillion races for gun" Ingo patch ?
> So if the now running higher prio tasks calls switch_mm() (which is likely to happen)
> it loops forever on atomic_dec_if_positive(&nr_free_contexts), while steal_context()
> sees "mm->context == CONTEXT".
I think the race is only when destroy_context() is preempted, but maybe
I missed something.
> I think that you should try "preempt_disable()/preempt_enable" pair at entry and
> exit of get_mmu_context() - I suppose around destroy_context() is not enough (you
> can try that also).
>
> spinlock ends up calling preempt_disable().
^ permalink raw reply
* Re: [PATCH] 8xx: get_mmu_context() for (very) FEW_CONTEXTS and KERNEL_PREEMPT race/starvation issue
From: Benjamin Herrenschmidt @ 2005-06-29 23:24 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linux-ppc-embedded
In-Reply-To: <42C2BF03.9000402@mrv.com>
> I'm still a bit confused with "kernel preemption". One thing for sure
> is that disabling kernel preemption does indeed fix my problem.
> So, my question is, what if a task in the middle of being schedule
> gets preempted by an IRQ handler, where will this task restart
> execution ? Back at the beginning of schedule or where it left of ?
I very much doubt that schedule itself can be preempted :)
> The idea behind my patch was to get rid of that nr_free_contexts
> counter that is (I thing) redundant with the context_map.
^ permalink raw reply
* Re: include/asm-ppc/atomic.h: fluff in inline assembly code?
From: Andreas Schwab @ 2005-06-29 22:34 UTC (permalink / raw)
To: Frank van Maarseveen; +Cc: linuxppc-dev
In-Reply-To: <20050629183628.GA23185@janus>
Frank van Maarseveen <frankvm@frankvm.com> writes:
> But v->counter is not supposed to be accessed directly by the
> compiler (i.e. by C code) at all, is it? so it shouldn't matter.
>
> Even if it would be: the counter itself is declared "volatile int"
> which basically tells the compiler not to cache it in a register.
Never lie to the compiler, or it gets its revenge, sooner or later.
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
* [RFC][PATCH] ppc misusing NTP's time_offset value
From: john stultz @ 2005-06-29 22:05 UTC (permalink / raw)
To: lkml, benh, paulus; +Cc: linuxppc-dev
Hey everyone,
As part of my timeofday rework, I've been looking at the NTP code and I
noticed that the PPC architecture is apparently misusing the NTP's
time_offset (it is a terrible name!) value as some form of timezone
offset. This could cause problems when time_offset changed by the NTP
code.
This patch changes the PPC code so it uses a more clear local variable:
timezone_offset.
Could a PPC maintainer verify this is correct?
Let me know if you have any comments or feedback.
thanks
-john
Signed-off-by: John Stultz <johnstul@us.ibm.com>
diff --git a/arch/ppc/kernel/time.c b/arch/ppc/kernel/time.c
--- a/arch/ppc/kernel/time.c
+++ b/arch/ppc/kernel/time.c
@@ -90,6 +90,9 @@ unsigned long tb_to_ns_scale;
extern unsigned long wall_jiffies;
+/* used for timezone offset */
+static long timezone_offset;
+
DEFINE_SPINLOCK(rtc_lock);
EXPORT_SYMBOL(rtc_lock);
@@ -171,7 +174,7 @@ void timer_interrupt(struct pt_regs * re
xtime.tv_sec - last_rtc_update >= 659 &&
abs((xtime.tv_nsec / 1000) - (1000000-1000000/HZ)) < 500000/HZ &&
jiffies - wall_jiffies == 1) {
- if (ppc_md.set_rtc_time(xtime.tv_sec+1 + time_offset) == 0)
+ if (ppc_md.set_rtc_time(xtime.tv_sec+1 + timezone_offset) == 0)
last_rtc_update = xtime.tv_sec+1;
else
/* Try again one minute later */
@@ -284,7 +287,7 @@ void __init time_init(void)
unsigned old_stamp, stamp, elapsed;
if (ppc_md.time_init != NULL)
- time_offset = ppc_md.time_init();
+ timezone_offset = ppc_md.time_init();
if (__USE_RTC()) {
/* 601 processor: dec counts down by 128 every 128ns */
@@ -329,10 +332,10 @@ void __init time_init(void)
set_dec(tb_ticks_per_jiffy);
/* If platform provided a timezone (pmac), we correct the time */
- if (time_offset) {
- sys_tz.tz_minuteswest = -time_offset / 60;
+ if (timezone_offset) {
+ sys_tz.tz_minuteswest = -timezone_offset / 60;
sys_tz.tz_dsttime = 0;
- xtime.tv_sec -= time_offset;
+ xtime.tv_sec -= timezone_offset;
}
set_normalized_timespec(&wall_to_monotonic,
-xtime.tv_sec, -xtime.tv_nsec);
^ permalink raw reply
* Re: [PATCH] 8xx: map_page() skip pinned region and tlbie debugging aid
From: Marcelo Tosatti @ 2005-06-29 17:19 UTC (permalink / raw)
To: Dan Malek; +Cc: linux-ppc-embedded
In-Reply-To: <3e7207cd8e98080f2f469a668e37a20f@embeddededge.com>
On Tue, Jun 28, 2005 at 09:53:26AM -0400, Dan Malek wrote:
>
> On Jun 28, 2005, at 2:30 AM, Benjamin Herrenschmidt wrote:
>
> >You should consider 8Mb pages the way we do BATs yes,
>
> It's always been considered, just never fully implemented :-)
>
> >Note that I'll soon send the patch I told you about that makes the
> >virtual address picked by io_block_mapping() dynamic, so we no longer
> >have to do crappy assumptions all over the place :)
>
> Whatever, I'll never use it that way and no one else should either.
Why not? AFAICS the idea is to have the virtual mappings dynamic
and not static - this is the _whole_ point of ioremap() instead
of io_block_mapping(), isnt it?
I fail to see any practical arguments against it...
> All of the io_block_mapping() calls should be used to set these 8M
> mapped IO spaces, everyone should use ioremap() to map them,
> and ioremap() has to be modified to find them for the 8xx.
What do you mean "everyone should use ioremap() to map them"?
Once the physical->virtual mapping for device IO space are set
with io_block_mapping() (or with ioremap() for dynamic virtual
addresses), why would you want to ioremap() the physical address
again???
PS: I've had a quick try at converting the IMMAP to use
ioremap instead (and have that dynamic virtual address stored
in a pointer), changed drivers to use that pointer instead of
hardcoded "IMMAP". Didnt work immediately :) Its not that the
idea?
^ permalink raw reply
* Re: [PATCH] 8xx: get_mmu_context() for (very) FEW_CONTEXTS and KERNEL_PREEMPT race/starvation issue
From: Marcelo Tosatti @ 2005-06-29 17:00 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linux-ppc-embedded
In-Reply-To: <42C311CD.1040405@mrv.com>
Hi!
On Wed, Jun 29, 2005 at 05:25:33PM -0400, Guillaume Autran wrote:
> In that case, what happen when a higher priority task steal the context
> of the lower priority task after get_mmu_context() but before
> set_mmu_context() ?
> Then when the lower priority task resumes, its context may no longer be
> valid...
> Do I get this right ?
Yep... but its OK and expected for the "lower prio task" in question to have
its context invalidated: In this case it will call get_mmu_context() again
and reserve the next one available before executing.
> I'm going to do like this instead of my previous attempt:
>
> /* Setup new userspace context */
> preempt_disable();
> get_mmu_context(next);
> set_context(next->context, next->pgd);
> preempt_enable();
>
> To make sure we don't loose our context in between.
There should be no need - the window for the race is inside
get_mmu_context().
ie. It should be safe to preempt after setting "next_mm_context".
^ permalink raw reply
* Re: [PATCH] 8xx: get_mmu_context() for (very) FEW_CONTEXTS and KERNEL_PREEMPT race/starvation issue
From: Guillaume Autran @ 2005-06-29 21:25 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: ', linux-ppc-embedded
In-Reply-To: <20050629155445.GA3560@logos.cnet>
[-- Attachment #1: Type: text/plain, Size: 3282 bytes --]
Hi Marcelo,
Marcelo Tosatti wrote:
>Hi Guillaume,
>
>On Wed, Jun 29, 2005 at 11:32:19AM -0400, Guillaume Autran wrote:
>
>
>>Benjamin Herrenschmidt wrote:
>>
>>
>>
>>>On Tue, 2005-06-28 at 09:42 -0400, Guillaume Autran wrote:
>>>
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>I happen to notice a race condition in the mmu_context code for the 8xx
>>>>with very few context (16 MMU contexts) and kernel preemption enable. It
>>>>is hard to reproduce has it shows only when many processes are
>>>>created/destroy and the system is doing a lot of IRQ processing.
>>>>
>>>>In short, one process is trying to steal a context that is in the
>>>>process of being freed (mm->context == NO_CONTEXT) but not completely
>>>>freed (nr_free_contexts == 0).
>>>>The steal_context() function does not do anything and the process stays
>>>>in the loop forever.
>>>>
>>>>Anyway, I got a patch that fixes this part. Does not seem to affect
>>>>scheduling latency at all.
>>>>
>>>>Comments are appreciated.
>>>>
>>>>
>>>>
>>>>
>>>Your patch seems to do a hell lot more than fixing this race ... What
>>>about just calling preempt_disable() in destroy_context() instead ?
>>>
>>>
>>>
>>>
>>I'm still a bit confused with "kernel preemption". One thing for sure is
>>that disabling kernel preemption does indeed fix my problem.
>>So, my question is, what if a task in the middle of being schedule gets
>>preempted by an IRQ handler, where will this task restart execution ?
>>Back at the beginning of schedule or where it left of ?
>>
>>
>
>Execution is resumed exactly where it has been interrupted.
>
In that case, what happen when a higher priority task steal the context
of the lower priority task after get_mmu_context() but before
set_mmu_context() ?
Then when the lower priority task resumes, its context may no longer be
valid...
Do I get this right ?
>>The idea behind my patch was to get rid of that nr_free_contexts counter
>>that is (I thing) redundant with the context_map.
>>
>>
>
>Apparently its there to avoid the spinlock exactly on !FEW_CONTEXTS machines.
>
>I suppose that what happens is that get_mmu_context() gets preempted after stealing
>a context (so nr_free_contexts = 0), but before setting next_mmu_context to the
>next entry
>
>next_mmu_context = (ctx + 1) & LAST_CONTEXT;
>
>So if the now running higher prio tasks calls switch_mm() (which is likely to happen)
>it loops forever on atomic_dec_if_positive(&nr_free_contexts), while steal_context()
>sees "mm->context == CONTEXT".
>
>I think that you should try "preempt_disable()/preempt_enable" pair at entry and
>exit of get_mmu_context() - I suppose around destroy_context() is not enough (you
>can try that also).
>
>spinlock ends up calling preempt_disable().
>
>
>
I'm going to do like this instead of my previous attempt:
/* Setup new userspace context */
preempt_disable();
get_mmu_context(next);
set_context(next->context, next->pgd);
preempt_enable();
To make sure we don't loose our context in between.
Thanks.
Guillaume.
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: Type: text/html, Size: 4293 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