Re: CVS commit: src/sys/arch/sparc/sparc

[Andrew Doran]

On Sun, Mar 15, 2020 at 11:38:03AM +1100, matthew green wrote:
> "Andrew Doran" writes:
> > Module Name:src
> > Committed By:   ad
> > Date:   Sat Mar 14 13:34:44 UTC 2020
> > 
> > Modified Files:
> > src/sys/arch/sparc/sparc: intr.c
> > 
> > Log Message:
> > sparc cpu_intr_p(): try to work around l_cpu not being set early on by
> > using curcpu().
> 
> ah, good idea.  this will involve one fewer deref, curcpu()
> is mapped at a fixed address, so it might even be faster now
> than it used to be.

Oh, hm..  Given that it's a fixed address is there a way the compiler can
screw this up in the face of a kernel preemption (theoretical right now for
sparc*)?  I don't think so..  None of the fanciness is required then.

bool
cpu_intr_p(void)
{

return curcpu()->ci_idepth != 0;
}

Andrew

re: CVS commit: src/sys/arch/sparc/sparc

[matthew green]

"Andrew Doran" writes:
> Module Name:  src
> Committed By: ad
> Date: Sat Mar 14 13:34:44 UTC 2020
> 
> Modified Files:
>   src/sys/arch/sparc/sparc: intr.c
> 
> Log Message:
> sparc cpu_intr_p(): try to work around l_cpu not being set early on by
> using curcpu().

ah, good idea.  this will involve one fewer deref, curcpu()
is mapped at a fixed address, so it might even be faster now
than it used to be.


.mrg.

re: CVS commit: src/sys/arch/sparc/sparc

[matthew green]

"Christos Zoulas" writes:
> Module Name:  src
> Committed By: christos
> Date: Wed Jan 17 02:39:16 UTC 2018
> 
> Modified Files:
>   src/sys/arch/sparc/sparc: cpuvar.h
> 
> Log Message:
> fix compilation

actually, this was renamed and moved, so this is also wrong.
i'll fix it.


.mrg.

Re: CVS commit: src/sys/arch/sparc

[Martin Husemann]

On Wed, Apr 06, 2016 at 06:02:33AM +1000, matthew green wrote:
> or convert it (back to?) a __cpu_simple_lock.

Yes, whatever is easiest and works.

Martin

re: CVS commit: src/sys/arch/sparc

[matthew green]

Martin Husemann writes:
> On Tue, Apr 05, 2016 at 03:02:25PM +0200, J. Hannken-Illjes wrote:
> > The attached hack works for me -- looks like we cannot use a mutex
> > so early ...
> 
> Or just skip the mutex_{enter,exit} while cold?

or convert it (back to?) a __cpu_simple_lock.


.mrg.

Re: CVS commit: src/sys/arch/sparc

[J. Hannken-Illjes]

> On 05 Apr 2016, at 15:05, Martin Husemann  wrote:
> 
> On Tue, Apr 05, 2016 at 03:02:25PM +0200, J. Hannken-Illjes wrote:
>> The attached hack works for me -- looks like we cannot use a mutex
>> so early ...
> 
> Or just skip the mutex_{enter,exit} while cold?

The first crash is the result of mutex_init -> lockdebug_alloc().

--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)

Re: CVS commit: src/sys/arch/sparc

[Martin Husemann]

On Tue, Apr 05, 2016 at 03:36:13PM +0200, J. Hannken-Illjes wrote:
> The first crash is the result of mutex_init -> lockdebug_alloc().

Yeah, and init it "later" - but I don't know what a good point for that
would be.

Martin

Re: CVS commit: src/sys/arch/sparc

[Martin Husemann]

On Tue, Apr 05, 2016 at 03:02:25PM +0200, J. Hannken-Illjes wrote:
> The attached hack works for me -- looks like we cannot use a mutex
> so early ...

Or just skip the mutex_{enter,exit} while cold?

Martin

Re: CVS commit: src/sys/arch/sparc

[J. Hannken-Illjes]

> On 01 Apr 2016, at 22:21, Palle Lyckegaard  wrote:
> 
> Module Name:  src
> Committed By: palle
> Date: Fri Apr  1 20:21:45 UTC 2016
> 
> Modified Files:
>   src/sys/arch/sparc/include: openfirm.h
>   src/sys/arch/sparc/sparc: openfirm.c promlib.c
> 
> Log Message:
> sun4v: Workaround for OpenBoot feature where a 64-bit address is truncated to 
> a 32-bit address. This happends when a write to the console 
> (/virtual-devices@100/console@1) is done. Avoid this by using a static buffer 
> that is mapped below 4GB. Thanks to Tarl Neustaedter for explaining how 
> OpenBoot works. ok martin@
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.9 -r1.10 src/sys/arch/sparc/include/openfirm.h
> cvs rdiff -u -r1.20 -r1.21 src/sys/arch/sparc/sparc/openfirm.c
> cvs rdiff -u -r1.44 -r1.45 src/sys/arch/sparc/sparc/promlib.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

This breaks (at least) LOCKDEBUG kernel on Sun V240:

Loading netbsd: 10104048+639024+609968 [638184+418249]=0xe33790
ERROR: Last Trap: Fast Data Access MMU Miss

The attached hack works for me -- looks like we cannot use a mutex
so early ...

--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)


openfirm.diff
Description: Binary data

re: CVS commit: src/sys/arch/sparc

[matthew green]

 Modified Files:
  src/sys/arch/sparc/dev: if_ie_obio.c kd.c tctrl.c ts102.c
  src/sys/arch/sparc/include: pmap.h
  src/sys/arch/sparc/sparc: cpuvar.h memecc.c timer.c
 
 Log Message:
 - remove unused but set variables.
 - use __USE() where necessary.
 - remove useless 'volatile' markers
 
 I am not sure that those volatile markers are useless.
 
 For example:
 
  #define raise_ipi(cpi,lvl)  do {\
 -volatile int x; \
 +int x;  \
  (cpi)-intreg_4m-pi_set = PINTR_SINTRLEV(lvl); \
 -x = (cpi)-intreg_4m-pi_pend;  \
 +x = (cpi)-intreg_4m-pi_pend; __USE(x);\
  } while (0)
 
 I think that the change from the use of volatile to the use of 
 __USE() is a change from reliance on the C standard's guarantee 
 that the memory location behind (cpi)-intreg_4m-pi_pend really 
 will be accessed, to a reliance on what a particular compiler 
 happens to do in this situation.

the volatile applies to the access to pi_pend, which is
marked a volatile (via the whole intreg_4m pointer.)

i'm not sure that volatile int x; actually means
anything useful.  it's pointer accesses that matter.
i could be wrong; volatile is a pretty tricky area.

certainly, the generated code is fine (and in most
cases, identical).


.mrg.

re: CVS commit: src/sys/arch/sparc

[matthew green]

 On Sat, Oct 19, 2013 at 07:40:23PM +, matthew green wrote:
  Log Message:
  - remove unused but set variables.
  - use __USE() where necessary.
  - remove useless 'volatile' markers
  
  kd.c:consinit() might be wrong for old proms, but i've not
  changed it really.
 
 And a continuum: it seems to me that many of these changes just add #if'0
 cruft to the code. Philopsophical question: why not such delete such code?

the kd.c ones at least i want mac to look at.  something is not
right there, but i'm not sure exactly how to fix it.


.mrg.

Re: CVS commit: src/sys/arch/sparc

[Alan Barrett]

On Mon, 21 Oct 2013, matthew green wrote:

 #define raise_ipi(cpi,lvl) do {\
-   volatile int x; \
+   int x;  \
(cpi)-intreg_4m-pi_set = PINTR_SINTRLEV(lvl);   \
-   x = (cpi)-intreg_4m-pi_pend;\
+   x = (cpi)-intreg_4m-pi_pend; __USE(x);  \
 } while (0)

I think that the change from the use of volatile to the use of 
__USE() is a change from reliance on the C standard's guarantee 
that the memory location behind (cpi)-intreg_4m-pi_pend 
really will be accessed, to a reliance on what a particular 
compiler happens to do in this situation.


the volatile applies to the access to pi_pend, which is marked a 
volatile (via the whole intreg_4m pointer.)


Oh, if cpi, or intreg_4m, or pi_pend, is volatile, then it's fine, 
and that would be the best way to deal with the issue.  In such a 
case, there's no need to use x at all.


i'm not sure that volatile int x; actually means anything 
useful.  it's pointer accesses that matter.  i could be wrong; 
volatile is a pretty tricky area.


Yes, the pointer access is the thing that really needs to be 
volatile, but I previously thought that it was not, and then I 
thought (incorrectly, I now believe) that making x volatile would 
be sufficient.


certainly, the generated code is fine (and in most cases, 
identical).


My concern was with other compilers in the future.  If the pointer 
access is volatile, then I think it's fine.


--apb (Alan Barrett)

Re: CVS commit: src/sys/arch/sparc

[Martin Husemann]

On Mon, Oct 21, 2013 at 05:14:18PM +1100, matthew green wrote:
 the volatile applies to the access to pi_pend, which is
 marked a volatile (via the whole intreg_4m pointer.)

So the (void)intreg_4m-... ; version should be fine - just compare the asm
output.

Martin

Re: CVS commit: src/sys/arch/sparc

[Martin Husemann]

On Sun, Oct 20, 2013 at 10:05:30AM +0200, Alan Barrett wrote:
 For example:
 
 #define raise_ipi(cpi,lvl)   do {\
 -volatile int x; \
 +int x;  \
  (cpi)-intreg_4m-pi_set = PINTR_SINTRLEV(lvl); \
 -x = (cpi)-intreg_4m-pi_pend;  \
 +x = (cpi)-intreg_4m-pi_pend; __USE(x);\
 } while (0)

I don't think this change is incorrect, but I would do this differently.

If the RHS is not properly marked volatile, the compiler might cache the
value and repeatadly store the same value again, so the volatile hidden
somewhere in the RHS is important. I wonder, however, why it does not
properly warn here (loss of qualifiers), so we should realy investigate
this closer.

However, assuming the RHS is ok, it is IMHO better to get rid of i completely
and do:

#define raise_ipi(cpi,lvl)  do {\
(cpi)-intreg_4m-pi_set = PINTR_SINTRLEV(lvl); \
(void)(cpi)-intreg_4m-pi_pend;\
} while (0)

See for example src/sys/dev/sun/cgsix.c:

/*
 * Run a blitter command
 */
#define CG6_BLIT(f) { (void)f-fbc_blit; }

/*
 * Run a drawing command
 */
#define CG6_DRAW(f) { (void)f-fbc_draw; }


Martin

Re: CVS commit: src/sys/arch/sparc

[Jukka Ruohonen]

On Sat, Oct 19, 2013 at 07:40:23PM +, matthew green wrote:
 Log Message:
 - remove unused but set variables.
 - use __USE() where necessary.
 - remove useless 'volatile' markers
 
 kd.c:consinit() might be wrong for old proms, but i've not
 changed it really.

And a continuum: it seems to me that many of these changes just add #if'0
cruft to the code. Philopsophical question: why not such delete such code?

- Jukka.

Re: CVS commit: src/sys/arch/sparc/sparc

[Chuck Silvers]

On Sun, Nov 04, 2012 at 01:35:04PM +1100, matthew green wrote:
 
  Module Name:src
  Committed By:   chs
  Date:   Sun Nov  4 00:32:47 UTC 2012
  
  Modified Files:
  src/sys/arch/sparc/sparc: locore.s pmap.c
  
  Log Message:
  in cpu_switchto(), remove the MP-unsafe code to mark a pmap active on a CPU,
  pmap_activate() already does this.  add MP locking to pmap_activate()
  and pmap_deactivate().  move flushing of user windows and virtual caches
  from pamp_activate() to pmap_deactivate().
 
 
 hmm.  this makes pmap_deactivate() do things in UP that weren't being
 done before at all.  switching to/from kernel/lwp for the same lwp will
 now be flushing the ctx every time.  that seems suboptimal?

do you just mean that I should have left the #ifdef MULTIPROCESSOR
around the sp_tlb_flush()?  or something more than that?


 we should really update PMAP_LOCK() to not be kernel lock.

agreed.

beyond that, there's still plenty of room for improvement on most platforms.
I think the best example in our tree at this point is the x86 scheme
of deferring the MMU-switch work to points where we're actually about to
reference user mappings, eg. returning to user mode, copyin/copyout, etc.


-Chuck

re: CVS commit: src/sys/arch/sparc/sparc

[matthew green]

 Module Name:  src
 Committed By: chs
 Date: Sun Nov  4 00:32:47 UTC 2012
 
 Modified Files:
   src/sys/arch/sparc/sparc: locore.s pmap.c
 
 Log Message:
 in cpu_switchto(), remove the MP-unsafe code to mark a pmap active on a CPU,
 pmap_activate() already does this.  add MP locking to pmap_activate()
 and pmap_deactivate().  move flushing of user windows and virtual caches
 from pamp_activate() to pmap_deactivate().


hmm.  this makes pmap_deactivate() do things in UP that weren't being
done before at all.  switching to/from kernel/lwp for the same lwp will
now be flushing the ctx every time.  that seems suboptimal?

we should really update PMAP_LOCK() to not be kernel lock.


.mrg.

Re: CVS commit: src/sys/arch/sparc

[Christos Zoulas]

On Aug 2,  3:10am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/sparc

| christos@ wrote:
| 
|  He did it by himself, but that was a good change.
| 
| Even if it was a good change, no announcement is always a bad thing.
| (unless it's approved by Core)

Absolutely, that is true. I think he underestimated the amount of things
that would break.

christos

re: CVS commit: src/sys/arch/sparc

[Christos Zoulas]

On Aug 2,  4:22am, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/sys/arch/sparc

| how can you say that commiting untsted code to sparc initialisation
| is the right thing?  there's absolutely nothing in the above statement
| (or any part of tiering) that supports this, nor has it ever been an
| OK thing to do in our community.

It was a judgement call. I thought that it has a good chance to work.
I was wrong.

| IMO, the right fix for you to get past the build problem originally
| would have been to disable -fno-common on sparc and file a PR.

Or just file a PR instead. I don't like adding kludges that would
certainly require undoing.

christos

Re: CVS commit: src/sys/arch/sparc

[Christos Zoulas]

On Jul 31,  8:51pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/sparc

| christos@ wrote:
| 
| Why don't you guys (as core? or individual developer?) post
| an announcement that mentions benefit of -fno-common and
| ask Tier II users to fix possible fallout, before putting
| random MD fixes that would cause annoying silent hangs?

I can say the same for the port-masters who leave their ports
broken for days. But the benefits of -fno-common are pretty
obvious: mistakes like having char *foo in one file and int foo in
another, now will cause a build failure.

| For sparc, the correct place seems in sparc/autoconf.c:bootstrap().
| For sun2 it's sun2/locore2.c:_bootstrap().
| Most other m68k ports foo_init() for pre-main initialization.

It would be nice if the individual port-masters would proactively
check their ports so that they would remain buildable, and people
who have cross-port knowledge like you, would work to harmonize
these disparate and undocumented interfaces.

christos

Re: CVS commit: src/sys/arch/sparc

[Izumi Tsutsui]

christos@ wrote:

 On Jul 31,  8:51pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
 -- Subject: Re: CVS commit: src/sys/arch/sparc
 
 | christos@ wrote:
 | 
 | Why don't you guys (as core? or individual developer?) post
 | an announcement that mentions benefit of -fno-common and
 | ask Tier II users to fix possible fallout, before putting
 | random MD fixes that would cause annoying silent hangs?
 
 I can say the same for the port-masters who leave their ports
 broken for days.

I agree you can blame port masters if they leave their ports broken
more than *weeks*.

But tier II ports are not primary even for their users and
few people check status everyday.
No chance to notice breakage without heads up about MI changes.

If you claim port-masters must check buildable state *everyday*
against all MI changes without review or announcement, I'll resign
from all maintainership.

 But the benefits of -fno-common are pretty
 obvious: mistakes like having char *foo in one file and int foo in
 another, now will cause a build failure.

Ok, but why should it be defined in MI sys/conf/Makefile.kern.inc?

Isn't it enought to define it per port (only tier I ports for example),
or per kernel config file for debug purpose?

 | For sparc, the correct place seems in sparc/autoconf.c:bootstrap().
 | For sun2 it's sun2/locore2.c:_bootstrap().
 | Most other m68k ports foo_init() for pre-main initialization.
 
 It would be nice if the individual port-masters would proactively
 check their ports so that they would remain buildable, and people
 who have cross-port knowledge like you, would work to harmonize
 these disparate and undocumented interfaces.

It would be nice if you guys asked proper persons to fix their ports
before you did try it yourself, so you don't have to check undocumented
MD kludges.

IMO buildable but non-bootable state is worse than non buildable.
It just hides actual problems and makes late debug harder.

---
Izumi Tsutsui

Re: CVS commit: src/sys/arch/sparc

[Christos Zoulas]

On Aug 1,  8:23pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/sparc

| I agree you can blame port masters if they leave their ports broken
| more than *weeks*.

Fine, let's create an SLA then. Without an SLA, people don't know
what's to be expected.

| But tier II ports are not primary even for their users and
| few people check status everyday.
| No chance to notice breakage without heads up about MI changes.

It is simple enough to arrange to be notified about autobuild failures.

| If you claim port-masters must check buildable state *everyday*
| against all MI changes without review or announcement, I'll resign
| from all maintainership.

No, read above.

| Ok, but why should it be defined in MI sys/conf/Makefile.kern.inc?
| 
| Isn't it enought to define it per port (only tier I ports for example),
| or per kernel config file for debug purpose?

Ideally we want to fix all the code ASAP.

|  | For sparc, the correct place seems in sparc/autoconf.c:bootstrap().
|  | For sun2 it's sun2/locore2.c:_bootstrap().
|  | Most other m68k ports foo_init() for pre-main initialization.
|  
|  It would be nice if the individual port-masters would proactively
|  check their ports so that they would remain buildable, and people
|  who have cross-port knowledge like you, would work to harmonize
|  these disparate and undocumented interfaces.
| 
| It would be nice if you guys asked proper persons to fix their ports
| before you did try it yourself, so you don't have to check undocumented
| MD kludges.
| 
| IMO buildable but non-bootable state is worse than non buildable.
| It just hides actual problems and makes late debug harder.

It is not you guys, it is just my fault. I don't know who you consider
co-responsible. As far as that goes, I will agree. I definitely seem to
have stirred the waters enough for the fix to be applied sooner than later,
but this is not the way to operate.

christos

Re: CVS commit: src/sys/arch/sparc

[Martin Husemann]

Well, the problem was that all details were hidden behind several layers
of fallout by evil conspiracy of openssl update and -Wno-common changes, and
a slow serious of partial fixes.

A heads up for both of those changes would have been nice, but I guess
we'll get over it.

It seems to be mostly fixed now, next autobuild should have most archs
building again (and hopefully working). Tests will resume...

Martin

Re: CVS commit: src/sys/arch/sparc

[Izumi Tsutsui]

christos@ wrote:

 On Aug 1,  8:23pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
 -- Subject: Re: CVS commit: src/sys/arch/sparc
 
 | I agree you can blame port masters if they leave their ports broken
 | more than *weeks*.
 
 Fine, let's create an SLA then. Without an SLA, people don't know
 what's to be expected.

We already have Tier definitions.

In Tier II:
 ... keeping it working is the responsibility of the user community. 
 :
 If the port is not working at release time, a release is done
 without the port and the port is moved down to the life support tier. 

In Tier III:
 Organic ports get moved here if they do not complete a build for
 6 months or are otherwise suspected to be broken. 

Tier was introduced to reduce extra work for developers working
on Tier I ports.  If these are not enough for you, what's better?

 | But tier II ports are not primary even for their users and
 | few people check status everyday.
 | No chance to notice breakage without heads up about MI changes.
 
 It is simple enough to arrange to be notified about autobuild failures.

All Tier II ports would have few MD new features, so
they don't need *daily* checks.  That's the point.

We can split autobuild script into Tier I/II ones
if people just want 0 failure in daily buidable status.

 | If you claim port-masters must check buildable state *everyday*
 | against all MI changes without review or announcement, I'll resign
 | from all maintainership.
 
 No, read above.

See above.  I'm afraid automated daily notifies which
won't stop until real fix are too annoying.

If it's sent ~bi-weelky like our gnats, it's fine for me.

 | Ok, but why should it be defined in MI sys/conf/Makefile.kern.inc?
 | 
 | Isn't it enought to define it per port (only tier I ports for example),
 | or per kernel config file for debug purpose?
 
 Ideally we want to fix all the code ASAP.

If we have enough man power to make it possible?

But unfortunately we also need reasonable compromise
and I think that's the what the Tier system intended.

 |  | For sparc, the correct place seems in sparc/autoconf.c:bootstrap().
 |  | For sun2 it's sun2/locore2.c:_bootstrap().
 |  | Most other m68k ports foo_init() for pre-main initialization.
 |  
 |  It would be nice if the individual port-masters would proactively
 |  check their ports so that they would remain buildable, and people
 |  who have cross-port knowledge like you, would work to harmonize
 |  these disparate and undocumented interfaces.
 | 
 | It would be nice if you guys asked proper persons to fix their ports
 | before you did try it yourself, so you don't have to check undocumented
 | MD kludges.
 | 
 | IMO buildable but non-bootable state is worse than non buildable.
 | It just hides actual problems and makes late debug harder.
 
 It is not you guys, it is just my fault. I don't know who you consider
 co-responsible. As far as that goes, I will agree. I definitely seem to
 have stirred the waters enough for the fix to be applied sooner than later,
 but this is not the way to operate.

I meant matt@, who committed the initial -fno-common change.
I don't know if it was done by Core's decision or not.

---
Izumi Tsutsui

Re: CVS commit: src/sys/arch/sparc

[David Brownlee]

On 1 August 2012 13:42, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
 christos@ wrote:
 It is simple enough to arrange to be notified about autobuild failures.
[...]

 See above.  I'm afraid automated daily notifies which
 won't stop until real fix are too annoying.

 If it's sent ~bi-weelky like our gnats, it's fine for me.

Possibly an on-failure/on-resume with a weekly current fails?

It could even collate the data nightly and include the details for all
ports, so for example dreamcast-builds@ list gets an email like they
below they can be pretty certain it was an MI change that broke
something...

| Subject: HEAD builds: dreamcast FAIL
|
| Build report for: HEAD 201209091130
|
| dreamcast: FAIL (was OK)
|
| All ports: FAIL (was OK)
| acorn26 acorn32 algor alpha amd64 amiga amigappc arc atari bebox
| cats cesfic cobalt dreamcast emips evbarm evbsh3-sh3eb evbsh3-sh3el
| ews4800mips hp300 hp700 hpcarm hpcmips hpcsh i386 ibmnws iyonix
| landisk luna68k mac68k macppc mipsco mmeye mvme68k mvmeppc netwinder
| news68k newsmips next68k ofppc pmax prep rs6000 sandpoint sbmips-mipseb
| sbmips-mipsel shark sparc sparc64 sun2 sun3 x68k zaurus
|
| All ports: FAIL (unchanged)
| evbmips-mips64eb evbmips-mips64el evbmips-mipseb evbmips-mipsel evbppc
| sgimips vax

Re: CVS commit: src/sys/arch/sparc

[Izumi Tsutsui]

christos@ wrote:

 He did it by himself, but that was a good change.

Even if it was a good change, no announcement is always a bad thing.
(unless it's approved by Core)

---
Izumi Tsutsui

re: CVS commit: src/sys/arch/sparc

[matthew green]

 | We already have Tier definitions.
 |
 | In Tier II:
 |  ... keeping it working is the responsibility of the user community. 
 |  :
 |  If the port is not working at release time, a release is done
 |  without the port and the port is moved down to the life support tier. 
 
 Yes, but this is nebulous; according to it, I did the right thing by stepping
 in and trying to fix it. If they fail to build constantly, then it is a
 waste of time to keep building them. We can say that if they fail to build
 for more than a month, they go to tier III.

how can you say that commiting untsted code to sparc initialisation
is the right thing?  there's absolutely nothing in the above statement
(or any part of tiering) that supports this, nor has it ever been an
OK thing to do in our community.

IMO, the right fix for you to get past the build problem originally
would have been to disable -fno-common on sparc and file a PR.


.mrg.

Re: CVS commit: src/sys/arch/sparc

[Martin Husemann]

Does sparc do early console at all?

Martin

re: CVS commit: src/sys/arch/sparc

[matthew green]

 Does sparc do early console at all?

yes, it uses the prom console.  my ss20 hangs at boot with -current:

3312000+121480 [213328+209074]=0x3adad4
OBP version 3, revision 2.25 (plugin rev 2)
[ hang ]


i think the cn_tab changes should be reverted, as well as the -fno-common
change.  perhaps -fno-common could remain on platforms known to work and
we can switch others over when they're working.

-current has been pretty broken recently, let's not make it worse with
this cleanup change.


.mrg.

re: CVS commit: src/sys/arch/sparc

[matthew green]

   Does sparc do early console at all?
  
  yes, it uses the prom console.  my ss20 hangs at boot with -current:
 
 Ah, yes, that counts.
 
  3312000+121480 [213328+209074]=0x3adad4
  OBP version 3, revision 2.25 (plugin rev 2)
  [ hang ]
 
 Ok, but fixing as the other matt suggested should be easy.

  i think the cn_tab changes should be reverted, as well as the -fno-common
  change.  perhaps -fno-common could remain on platforms known to work and
  we can switch others over when they're working.
 
 I like the -no-common one, and fallout is easy to fix...

if it is so easy, why hasn't someone done it already?  it's not
like normal development -- this hangs the machine hard and you
have to go reset by hand.

this isn't like openssl where we're actively trying to upgrade
something that is out of date before release, but is just a
basic and simple clean up that doesn't really change anything.

as such, and because it is such a simple change (one line!),
reverting is easy and to me the clear way forward...  even if
that means reverting sparc cn_tab changes and putting a sparc
conditional on Makefile.kern.conf..

i have *much* more important things to worry about in port
sparc land than unnecessary clean up where i'd have to sit in
my hot noisy machine room to reset it each time.  and that's
when i can find time for sparc...


.mrg.

Re: CVS commit: src/sys/arch/sparc

[Christos Zoulas]

On Jul 31,  9:40am, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/sys/arch/sparc

| Does sparc do early console at all?

I don't know. Perhaps it is easiest to make cn_tab MD.

christos

Re: CVS commit: src/sys/arch/sparc

[David Laight]

On Tue, Jul 31, 2012 at 07:14:03PM +1000, matthew green wrote:
  
  I like the -no-common one, and fallout is easy to fix...
 
 if it is so easy, why hasn't someone done it already?  it's not
 like normal development -- this hangs the machine hard and you
 have to go reset by hand.

If the intent of adding -fno-common is to remove issues with common
data, then it is really doing the wrong thing.
You really need to error 'common' data items, not convert them to bss.

That might need a check later on the generated files.

David

-- 
David Laight: da...@l8s.co.uk

Re: CVS commit: src/sys/arch/sparc

[David Holland]

On Tue, Jul 31, 2012 at 11:16:44AM +0100, David Laight wrote:
  If the intent of adding -fno-common is to remove issues with common
  data, then it is really doing the wrong thing.
  You really need to error 'common' data items, not convert them to bss.
  
  That might need a check later on the generated files.

er wot?

The issues are multiply defined symbols, and switching them from
common to bss does in fact cause them to error out. That's the point.

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/sys/arch/sparc

[Izumi Tsutsui]

christos@ wrote:

 On Jul 30, 11:37am, m...@3am-software.com (Matt Thomas) wrote:
 -- Subject: Re: CVS commit: src/sys/arch/sparc
 
 | 
 | On Jul 30, 2012, at 10:29 AM, Christos Zoulas wrote:
 | 
 |  Module Name:  src
 |  Committed By: christos
 |  Date: Mon Jul 30 17:29:55 UTC 2012
 |  Modified Files:
 |src/sys/arch/sparc/dev: kd.c
 |src/sys/arch/sparc/sparc: machdep.c
 |  
 |  Log Message:
 |  move cn_tab initializationt to cpu_startup
 | 
 | cn_tab was used for early console access
 | cpu_startup is too late.
 | 
 | it needs to be done sometime before main is
 | called.
 
 Should we make cn_tab md, and let the ports initialize it themselves?
 Any better ideas?

Why don't you guys (as core? or individual developer?) post
an announcement that mentions benefit of -fno-common and
ask Tier II users to fix possible fallout, before putting
random MD fixes that would cause annoying silent hangs?

For sparc, the correct place seems in sparc/autoconf.c:bootstrap().
For sun2 it's sun2/locore2.c:_bootstrap().
Most other m68k ports foo_init() for pre-main initialization.
---
Izumi Tsutsui

Re: CVS commit: src/sys/arch/sparc

[Matt Thomas]

On Jul 30, 2012, at 10:29 AM, Christos Zoulas wrote:

 Module Name:  src
 Committed By: christos
 Date: Mon Jul 30 17:29:55 UTC 2012
 Modified Files:
   src/sys/arch/sparc/dev: kd.c
   src/sys/arch/sparc/sparc: machdep.c
 
 Log Message:
 move cn_tab initializationt to cpu_startup

cn_tab was used for early console access
cpu_startup is too late.

it needs to be done sometime before main is
called.

Re: CVS commit: src/sys/arch/sparc

[Christos Zoulas]

On Jul 30, 11:37am, m...@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: CVS commit: src/sys/arch/sparc

| 
| On Jul 30, 2012, at 10:29 AM, Christos Zoulas wrote:
| 
|  Module Name:src
|  Committed By:   christos
|  Date:   Mon Jul 30 17:29:55 UTC 2012
|  Modified Files:
|  src/sys/arch/sparc/dev: kd.c
|  src/sys/arch/sparc/sparc: machdep.c
|  
|  Log Message:
|  move cn_tab initializationt to cpu_startup
| 
| cn_tab was used for early console access
| cpu_startup is too late.
| 
| it needs to be done sometime before main is
| called.

Should we make cn_tab md, and let the ports initialize it themselves?
Any better ideas?


christos

Re: CVS commit: src/sys/arch/sparc

[Matt Thomas]

On Jul 30, 2012, at 4:56 PM, Christos Zoulas wrote:

 On Jul 30, 11:37am, m...@3am-software.com (Matt Thomas) wrote:
 -- Subject: Re: CVS commit: src/sys/arch/sparc
 
 | 
 | On Jul 30, 2012, at 10:29 AM, Christos Zoulas wrote:
 | 
 |  Module Name:  src
 |  Committed By: christos
 |  Date: Mon Jul 30 17:29:55 UTC 2012
 |  Modified Files:
 |src/sys/arch/sparc/dev: kd.c
 |src/sys/arch/sparc/sparc: machdep.c
 |  
 |  Log Message:
 |  move cn_tab initializationt to cpu_startup
 | 
 | cn_tab was used for early console access
 | cpu_startup is too late.
 | 
 | it needs to be done sometime before main is
 | called.
 
 Should we make cn_tab md, and let the ports initialize it themselves?
 Any better ideas?

there should be a routine (its name varies) that gets called from the
assembly and in that you should set cn_tab.

Re: CVS commit: src/sys/arch/sparc

[Masao Uebayashi]

Having an MI routine that's called very early, just after C code can be run?

I think kernel bootstrap / initialization needs more granularity.

On Tue, Jul 31, 2012 at 8:56 AM, Christos Zoulas chris...@zoulas.com wrote:
 On Jul 30, 11:37am, m...@3am-software.com (Matt Thomas) wrote:
 -- Subject: Re: CVS commit: src/sys/arch/sparc

 |
 | On Jul 30, 2012, at 10:29 AM, Christos Zoulas wrote:
 |
 |  Module Name:src
 |  Committed By:   christos
 |  Date:   Mon Jul 30 17:29:55 UTC 2012
 |  Modified Files:
 |  src/sys/arch/sparc/dev: kd.c
 |  src/sys/arch/sparc/sparc: machdep.c
 | 
 |  Log Message:
 |  move cn_tab initializationt to cpu_startup
 |
 | cn_tab was used for early console access
 | cpu_startup is too late.
 |
 | it needs to be done sometime before main is
 | called.

 Should we make cn_tab md, and let the ports initialize it themselves?
 Any better ideas?


 christos

re: CVS commit: src/sys/arch/sparc/sparc

[matthew green]

 Module Name:  src
 Committed By: martin
 Date: Thu Sep  1 08:47:56 UTC 2011
 
 Modified Files:
   src/sys/arch/sparc/sparc: pmap.c
 
 Log Message:
 In pmap_unwire() fix an obvious editor mishap - enable kernel preemption
 before returning, not the other way around.
 Might fix PR kern/45137.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.345 -r1.346 src/sys/arch/sparc/sparc/pmap.c

thanks for fixing this.

hmm... code was like:

{
return;
foo();
}

it would be nice if we got warnings about this.


.mrg.

re: CVS commit: src/sys/arch/sparc/include

[matthew green]

 Module Name:  src
 Committed By: mrg
 Date: Sun Aug 28 22:30:09 UTC 2011
 
 Modified Files:
   src/sys/arch/sparc/include: psl.h
 
 Log Message:
 apply some always_inline attribute to setpsr and spl*.  while i am
 not yet sure exactly why this is necessary, but does avoid crashes
 seen on sparc INSTALL with gcc 4.5.

uwe@ helped me understand why this fixes the problem.  thanks!
it goes like this:

- srmmu_vcache_flush_context() turns off traps to do
its work.

- at the end, when it is trying to turn on traps again
which happens via the now no longer inlined setpsr()
call, the caller has a tail-call optimisation on the
call to setpsr() and the asm looks like:

0xf0012f08 srmmu_vcache_flush_context+108:b  0xf0012618 setpsr
0xf0012f0c srmmu_vcache_flush_context+112:restore

- but wait, we have traps turned off and we're going
to execute the restore, so any time we need to clean a
register window upon restore we go boom here.

the inlined version calls restore after setting %psr, and the
trap can be handled normally.


.mrg.

Re: CVS commit: src/sys/arch/sparc/stand/ofwboot

[Izumi Tsutsui]

 Modified Files:
   src/sys/arch/sparc/stand/ofwboot: ofdev.c
 
 Log Message:
 Add support for ffsv2 and lfs.

It's better to bump ofwboot/version too.
---
Izumi Tsutsui

Re: CVS commit: src/sys/arch/sparc/sparc

[Valeriy E. Ushakov]

On Wed, May 27, 2009 at 04:08:06 +, matthew green wrote:

 Modified Files:
   src/sys/arch/sparc/sparc: vm_machdep.c
 
 Log Message:
 sync this a little with sparc64: use cpu_setfunc() at the end of 
 cpu_lwp_fork()
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.98 -r1.99 src/sys/arch/sparc/sparc/vm_machdep.c

Is that correct?  It used to be in 4.0, but in 5.0 lwp trampoline
calls lwp_startup before calling the lwp function.  For SA the
trampoline used to be used for recycling lwps for upcalls.  Is that
correct to call lwp_startup in that case?  There never was any
official note on that when SA became undead.

SY, Uwe
-- 
u...@stderr.spb.ru   |   Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/  |   Ist zu Grunde gehen

Re: CVS commit: src/sys/arch/sparc/include

[Manuel Bouyer]

Hi,

On Sat, May 16, 2009 at 05:16:12PM +, Martin Husemann wrote:
 Module Name:  src
 Committed By: martin
 Date: Sat May 16 17:16:12 UTC 2009
 
 Modified Files:
   src/sys/arch/sparc/include: psl.h
 
 Log Message:
 Add memory clobbers to the inline assembler modifying/testing the %psr
 register, to avoid the compiler reordering instructions out of critical
 sections. Should fix PR port-sparc/41372.

thanks !
can you please request a pullup to netbsd-5 (and older branches if it
applies) ?

-- 
Manuel Bouyer bou...@antioche.eu.org
 NetBSD: 26 ans d'experience feront toujours la difference
--

re: CVS commit: src/sys/arch/sparc/sparc

[matthew green]

   Module Name: src
   Committed By:cegger
   Date:Sat May 16 17:01:16 UTC 2009
   
   Modified Files:
src/sys/arch/sparc/sparc: machdep.c process_machdep.c svr4_machdep.c
vm_machdep.c
   
   Log Message:
   KNF, same object code generated.


why are you doing this?  are you planning on touching all of these
files or are you doing a KNF rototill that you shouldn't?


.mrg.

Re: CVS commit: src/sys/arch/sparc/sparc

[Izumi Tsutsui]

Modified Files:
   src/sys/arch/sparc/sparc: machdep.c process_machdep.c svr4_machdep.c
   vm_machdep.c

Log Message:
KNF, same object code generated.
 
 
 why are you doing this?  are you planning on touching all of these
 files or are you doing a KNF rototill that you shouldn't?

The log message should be:
remove extra whitespace accidentally added on bcopy - memcpy changes

---
Izumi Tsutsui