Re: CVS commit: src/sys/arch/sparc/sparc
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
"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
"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
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
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
> 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
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
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
> 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
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
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
> 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
> >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
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
On Sun, Oct 20, 2013 at 11:26:24AM +0200, Martin Husemann wrote: > 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) If pi_pend isn't volatile you need something like: *(volatile * typeof ((cpi)->intreg_4m->pi_pend))&(cpi)->intreg_4m->pi_pend You might choose to know the type :-) David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/sparc
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
On Sat, 19 Oct 2013, matthew green wrote: Module Name:src Committed By: mrg Date: Sat Oct 19 19:40:23 UTC 2013 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. --apb (Alan Barrett)
Re: CVS commit: src/sys/arch/sparc/sparc
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
> 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
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
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
On Aug 1, 4:38pm, a...@netbsd.org (David Brownlee) wrote: -- Subject: Re: CVS commit: src/sys/arch/sparc | On 1 August 2012 13:42, Izumi Tsutsui 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... That sounds good to me. christos
re: CVS commit: src/sys/arch/sparc
> | 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
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
On Aug 1, 9:42pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/sys/arch/sparc | 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. 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. | 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? | All Tier II ports would have few MD new features, so | they don't need *daily* checks. That's the point. But this is not true in practice. | We can split autobuild script into Tier I/II ones | if people just want "0 failure" in daily buidable status. Yes, that would be better. | | > | 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. It is easy enough to put them in a folder with todays' MUA's. | If it's sent ~bi-weelky like our gnats, it's fine for me. That's fine too. | 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. We are trying to reach it. | I meant matt@, who committed the initial -fno-common change. | I don't know if it was done by Core's decision or not. He did it by himself, but that was a good change. christos
Re: CVS commit: src/sys/arch/sparc
On 1 August 2012 13:42, Izumi Tsutsui 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
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
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
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
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
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
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
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
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
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
> > > 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
On Tue, Jul 31, 2012 at 05:57:58PM +1000, matthew green wrote: > > > 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... > -current has been pretty broken recently, let's not make it worse with > this cleanup change. ... unlike other major fallout that prevents 23 out of 60 builds to complete (as of last night). But you are right, it has been broken way to long, we need to push forward and fix it ASAP. Martin
re: CVS commit: src/sys/arch/sparc
> 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
Does sparc do early console at all? Martin
Re: CVS commit: src/sys/arch/sparc
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 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
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
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
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/sparc
> 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
> 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 :b 0xf0012618 0xf0012f0c :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
> 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
On Wed, May 27, 2009 at 01:35:49PM +0400, Valeriy E. Ushakov wrote: > 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. Good catch - lwp_startup() should only be called at "lwp birth time" (according to Andrew) - we need to review all ports and split the trampolines used. Martin
Re: CVS commit: src/sys/arch/sparc/sparc
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
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 NetBSD: 26 ans d'experience feront toujours la difference --
re: CVS commit: src/sys/arch/sparc/sparc
>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" ah, thanks! .mrg.
Re: CVS commit: src/sys/arch/sparc/sparc
>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
re: CVS commit: src/sys/arch/sparc/sparc
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.