Re: Build Error
On Mon, Apr 01, 2002 at 12:14:27AM -0500, Scott Sipe wrote: > When doing buildworld on current from a couple hours ago. This is an alpha, > if that makes a difference. This is my first time compiling current > (currently running stable), so apologies if this is something that is my > fault. I just applied the following patch. I think this is what the fix is going to look like anyway. Index: Makefile === RCS file: /home/ncvs/src/sbin/savecore/Makefile,v retrieving revision 1.8 diff -u -r1.8 Makefile --- Makefile31 Mar 2002 22:26:56 - 1.8 +++ Makefile1 Apr 2002 06:40:18 - @@ -1,5 +1,5 @@ # $FreeBSD: src/sbin/savecore/Makefile,v 1.8 2002/03/31 22:26:56 phk Exp $ -PROG= savekerneldump +PROG= savecore WARNS= 4 NOMAN= sorry, not yet. LDADD= -lmd -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
At Sat, 30 Mar 2002 11:02:47 +0100, Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes: > >In message <[EMAIL PROTECTED]>, David Malone writes: > >>On Tue, Mar 26, 2002 at 09:59:29AM +0100, Poul-Henning Kamp wrote: > >>> This is an interesting machine: A K6 wiht ACPI, havn't seen that > >>> before. > >> > >>I had one of these machines and concluded that the ACPI time counter > >>was busted. I dunno if it is possible to sanity check the time > >>counter before using it? I just switched to using the TSC early in > >>boot and forgot about it. > > > >That is what I try to do, and I recently rewrote the code in current > >for that exact reason, so I'm very interested in seeing the diagnostic > >output (boot -v) from a -current kernel on these motherboards. > > I've stared at the data file and I'll be damned if I can find anything > which would case the clock to double its speed :-( Perhaps something else is causing the clock to run twice as fast? Maybe two things that are working properly are both incrementing the clock? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Build Error
When doing buildworld on current from a couple hours ago. This is an alpha, if that makes a difference. This is my first time compiling current (currently running stable), so apologies if this is something that is my fault. The error: ===> sbin/savecore make: don't know how to make savekerneldump.c. Stop *** Error code 2 Stop in /usr/src/sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 The Makefile (which doesn't seem ok): # $FreeBSD: src/sbin/savecore/Makefile,v 1.8 2002/03/31 22:26:56 phk Exp $ PROG= savekerneldump WARNS= 4 NOMAN= sorry, not yet. LDADD= -lmd .include I tried making it similar to the Makefile for savecore from STABLE, but it still wouldn't compile (undefined consts/defines I believe). thanks, Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installing Cross Builds
On Sun, Mar 31, 2002 at 07:39:33PM -0800, Crist J. Clark wrote:
> On Sun, Mar 31, 2002 at 05:57:31PM -0800, Marcel Moolenaar wrote:
> > On Fri, Mar 29, 2002 at 01:10:17PM -0800, Crist J. Clark wrote:
> > > After reviewing the world Makefiles, it sure looks like FreeBSD does
> > > not support 'installworld' of a cross build?
> >
> > Running installworld on machine X, when you did a cross-build for
> > machine X on machine Y is broken. All other cases should work,
> > AFACT.
> >
> > The brokenness is directly caused by inconsistent setting of OBJTREE.
> > This is indirectly caused make release, for make release expects the
> > object tree to be under /usr/obj and not /usr/obj/${TARGET_ARCH}.
>
> Well, the more direct reason for the breakage is caused by the fact
> that the PATH during install is,
>
> ${WORLDTMP}/usr/sbin:${WORLDTMP}/usr/bin:${WORLDTMP}/usr/games:${INSTALLTMP}
>
> Which is usually ${OBJTREE}${.CURDIR}/${MACHINE_ARCH}. But that
> directory doesn't exist. (Or is that what you are saying?)
It's not what I was saying, but you're right. I ran into this as well.
See below.
What I was saying is that a native build populates /usr/obj/,
but a cross build populates /usr/obj//. It
would be more consistent to always populate /usr/obj/,
and fix make release.
> If you fix
> that, there is the same issue with ${OBJFORMAT_PATH}. Once you fix
> that, you have shared lib problems. (I've never quite figured out what
> ${INSTALLTMP} is even there for.)
The fix would be to populate WORLDTMP, or otherwise make sure those
binaries are in INSTALLTMP as well. The reason for INSTALLTMP is to
avoid pulling the rug from under your feet when you have a single
pass upgrade. We don't have that (yet?). We tell people to install
a new kernel, reboot and then run installworld. A single pass upgrade
would save enough programs and libraries to complete the upgrade and
then do a reboot. Another problem is parallelism. You may run into
the situation that you both install and run the same binary. This can
cause breakages.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Installing Cross Builds
On Sun, Mar 31, 2002 at 05:57:31PM -0800, Marcel Moolenaar wrote:
> On Fri, Mar 29, 2002 at 01:10:17PM -0800, Crist J. Clark wrote:
> > After reviewing the world Makefiles, it sure looks like FreeBSD does
> > not support 'installworld' of a cross build?
>
> Running installworld on machine X, when you did a cross-build for
> machine X on machine Y is broken. All other cases should work,
> AFACT.
>
> The brokenness is directly caused by inconsistent setting of OBJTREE.
> This is indirectly caused make release, for make release expects the
> object tree to be under /usr/obj and not /usr/obj/${TARGET_ARCH}.
Well, the more direct reason for the breakage is caused by the fact
that the PATH during install is,
${WORLDTMP}/usr/sbin:${WORLDTMP}/usr/bin:${WORLDTMP}/usr/games:${INSTALLTMP}
Which is usually ${OBJTREE}${.CURDIR}/${MACHINE_ARCH}. But that
directory doesn't exist. (Or is that what you are saying?) If you fix
that, there is the same issue with ${OBJFORMAT_PATH}. Once you fix
that, you have shared lib problems. (I've never quite figured out what
${INSTALLTMP} is even there for.)
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Installing Cross Builds
On Fri, Mar 29, 2002 at 01:10:17PM -0800, Crist J. Clark wrote:
> After reviewing the world Makefiles, it sure looks like FreeBSD does
> not support 'installworld' of a cross build?
Running installworld on machine X, when you did a cross-build for
machine X on machine Y is broken. All other cases should work,
AFACT.
The brokenness is directly caused by inconsistent setting of OBJTREE.
This is indirectly caused make release, for make release expects the
object tree to be under /usr/obj and not /usr/obj/${TARGET_ARCH}.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Ports broken by OpenPAM
On Mon, 2002-03-25 at 10:00, Dag-Erling Smorgrav wrote: > Joe Clarke <[EMAIL PROTECTED]> writes: > > Really? I never received it. Please send it again. Thanks. > > Here's an updated (but untested) version. > I think I found why pam_ldap wouldn't work with OpenPAM on -CURRENT. Attached is my proposed patch to OpenPAM. With this applied, pam_ldap works like a champ. Joe -- PGP Key: http://www.marucscom.com/pgp.asc Index: lib/pam_set_data.c === RCS file: /home/ncvs/src/contrib/openpam/lib/pam_set_data.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 pam_set_data.c --- lib/pam_set_data.c 14 Mar 2002 20:42:06 - 1.1.1.4 +++ lib/pam_set_data.c 31 Mar 2002 22:43:21 - @@ -77,8 +77,10 @@ free(data); return (PAM_BUF_ERR); } + dp->data = data; + dp->cleanup = cleanup dp->next = pamh->module_data; - pamh->module_data = data; + pamh->module_data = dp; return (PAM_SUCCESS); } signature.asc Description: This is a digitally signed message part
Re: asr can not map memory?
On Sun, 31 Mar 2002, Michael Smith wrote: > You will tell me where I can buy disks for $1/GB and hotswap carriers at > $20 a pop, right? 8) eBay. :) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vmware
On Mon, 1 Apr 2002, Makoto Matsushita wrote: > > never> Maybe it's better to make two different ports vmware-tools and > never> vmware-tools3, first of which is for vmware2? > > Ancient ports/emulators/vmware-tools (FreeBSD native vmware-tools for > VMware _1.x_) is outdated for VMware 2.x; it doesn't have time sync > feature. > > If you're VMware 2.x user, you may want to consider to install > ports/emulators/linux-vmware-toolbox. I use the same virtual machine I made under 1.x under 2.x so it's still running the tools I installed on it under 1.x.. They work great. > > -- - > Makoto `MAR' Matsushita > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vmware
never> Maybe it's better to make two different ports vmware-tools and never> vmware-tools3, first of which is for vmware2? Ancient ports/emulators/vmware-tools (FreeBSD native vmware-tools for VMware _1.x_) is outdated for VMware 2.x; it doesn't have time sync feature. If you're VMware 2.x user, you may want to consider to install ports/emulators/linux-vmware-toolbox. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vmware
Hello, Makoto Matsushita! On Mon, Feb 04, 2002 at 12:35:51AM +0900, you wrote: > ggombert> VMware tools for FreeBSD is woefully out of date as well, > % cd /usr/ports/emulators/vmware-tools > % make -V PORTVERSION > 3.0.0.1455 > > VMware 3.0 bundles a new VMware tools, and it is up-to-date version as > of Linux guests. Is there any reason why we should use vmware-tools from VMware 3.x? Maybe it's better to make two different ports vmware-tools and vmware-tools3, first of which is for vmware2? -- NEVE-RIPE To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'moused' (on /dev/ums0) freezing system
On 31 Mär, Ollivier Robert wrote: >> I encountered a problem when using 'moused' on /dev/ums0: On shutdown >> or if 'moused' gets killed manually, the system freezes completely and >> silently, no further shutdown is possible, only the resetbutton >> operates... > > I think it is more of an USB problem than just moused. If I have loaded the > usb module (which create a usb0 kernel thread) when I do a suspend, on resume > the machine hangs. Just a data point: With a mar 12 kernel I didn't see this behavior, with a mar 27 kernel my system hangs too. Bye, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asr can not map memory?
Michael Smith wrote: > > > > Should I hold onto this card or should I suck it up and get > > > > a 3ware online somewhere? > > > > Be a man and buy a SCSI RAID controller. The Adaptec 5400S is > > all you'll ever need =-) > > You will tell me where I can buy disks for $1/GB and hotswap carriers at > $20 a pop, right? 8) The controller is all you'll ever need, because you won't be able to afford the disks or carriers... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asr can not map memory?
Michael Smith wrote: > > Yeah, you do. I fully understood _that_ context; I think Mike > > was talking about other context. It's pretty clear to me that > > ranges ought to be per bridge chipset, rather than global... I > > thought that that was what the option was working around: that > > they were not. > > I can't imagine how you came to this conclusion. You won't get it from > reading the code, or from understanding how PCI works. Maybe you need > sleep too. I got it from assuming that reading the code didn't tell me how the code was supposed to work, because if it had, then this would never had been a discussion, because the code would always do the right thing. 8-). My 1.0 copy of the PCI-PCI bridge documentation doesn't say that what Alfred's system is doing is bad; maybe it's just outdated. > The problem is twofold: > > - The code is broken, it fails to take into account both prefetched and >non-prefetched bridge mappings. It also appears to miscompute the >start of one of the attempted range accesses. Cool... this is the bug description I was fishing for here. > - There is anecdotal evidence that some bridges pass ranges other than >those advertised in their mappings, so even if the first problem is >resolved, enforcing correctness may result in occasional lossage. This sounds like a job for a "panic: anecdotal is real!" that Alfred could jam into the code, since he has the magic hardware. > And, since you ask, the whole reason behind having this code in the > first place is that we need to be able to correctly assign resources for > devices behind bridges. Yeah; it was the "it not doing it for Alfred's weird hardware" thing that threw me off. 8-) 8-). > I got run over by a car last time I worked on this code. Time for > someone else to pick it up. Oh yeah, we're *all* going to jump on hacking that code, now that you told us it's cursed! }B^D. Alfred, since you have the hardware that can (maybe) prove the anedote real, and can demonstrably show that Mike's problem #1 is fixed, once it's fixed... care to brave the curse? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
Emiel Kollof wrote: > On Sun, 2002-03-31 at 09:51, Terry Lambert wrote: > > Perhaps if the kernel printf also "ignored" the request to print > > the little S.O.B. out, there would be less confusion... > > I'm still sticking to the idea that one could test for kldxref, and if > it isn't there, don't execute it. > > [ -x /usr/sbin/kldxref ] && /usr/sbin/kldxref > > like so, which is perfectly sane bourne shell syntax, which is also used > by BSD make. Like someone else says, work around it or deal with the > users that don't get the (ignored) part. If failures are ignorable, then it shouldn't try, since attempts are ignorable (might as well "fail" up front by not even trying, and not generate the message, if failing's an OK thing to do). It seems to me that there are four potential cases: 1) It's not there, and it's not OK. 2) It's there, and that's fantastic. 3) It's not there, and it's not OK, but instead of stopping, the code is going to do some half job where you don't get everything, and then bitch about it in such a way that it will be hard to find the source of some failure later, if someone really cared about the failure enough that complaining about it is important in the first place. 4) It's not there, and it's OK, but the code is going to bitch about it not being there anyway because it likes to add to the amount of entropy in the universe, and this is an easy way to do it that's unlikely to get fixed. It seems to me that #3 and #4 are bad, and should be removed from the realm of allowable output. I think the "test to see if it's available" hack you suggested is #3, without the code bitching about it, which is even worse than #3 as it is. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asr can not map memory?
> > > Should I hold onto this card or should I suck it up and get > > > a 3ware online somewhere? > > Be a man and buy a SCSI RAID controller. The Adaptec 5400S is > all you'll ever need =-) You will tell me where I can buy disks for $1/GB and hotswap carriers at $20 a pop, right? 8) -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asr can not map memory?
On Sat, Mar 30, 2002 at 10:28:05PM -0800, Michael Smith wrote: > > > > This avoids a panic when probing, there's probably still some > > badness going on with make/destroy dev in this driver. > > Pending commentary from Scott, I think you should commit this. Yes, there is a lot of evilness in the asr driver. A whole lot. The original author does not have time/desire to maintain it, so obrien volunteered to take over maintainership. I suspect that real life (or a different cool project, like sparc64) has intruded on his plans to do so, and I don't really blame him =-). I give my blessing to anyone who is brave/stupid enough to want to touch this driver. Fix it, delete it, use it in pagan rituals, even let JMjr touch it, I really don't care. > > > Should I hold onto this card or should I suck it up and get > > a 3ware online somewhere? Be a man and buy a SCSI RAID controller. The Adaptec 5400S is all you'll ever need =-) Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Sun, 2002-03-31 at 09:51, Terry Lambert wrote: > > Perhaps if the kernel printf also "ignored" the request to print > the little S.O.B. out, there would be less confusion... I'm still sticking to the idea that one could test for kldxref, and if it isn't there, don't execute it. [ -x /usr/sbin/kldxref ] && /usr/sbin/kldxref like so, which is perfectly sane bourne shell syntax, which is also used by BSD make. Like someone else says, work around it or deal with the users that don't get the (ignored) part. Just my .02 Euro's Cheers, Emiel signature.asc Description: This is a digitally signed message part
Re: asr can not map memory?
> Yeah, you do. I fully understood _that_ context; I think Mike > was talking about other context. It's pretty clear to me that > ranges ought to be per bridge chipset, rather than global... I > thought that that was what the option was working around: that > they were not. I can't imagine how you came to this conclusion. You won't get it from reading the code, or from understanding how PCI works. Maybe you need sleep too. The problem is twofold: - The code is broken, it fails to take into account both prefetched and non-prefetched bridge mappings. It also appears to miscompute the start of one of the attempted range accesses. - There is anecdotal evidence that some bridges pass ranges other than those advertised in their mappings, so even if the first problem is resolved, enforcing correctness may result in occasional lossage. And, since you ask, the whole reason behind having this code in the first place is that we need to be able to correctly assign resources for devices behind bridges. I got run over by a car last time I worked on this code. Time for someone else to pick it up. = Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stdout changes break some ports
Garance A Drosihn wrote: > >How does one fix this in a library? I've been moving the > >initialization to main() for applications. > > If all else fails, have some global static variable, and check > the value in the routine(s) which care. if the flag variable > is still zero, then initialize the stdout variable and change > the flag variable to 1. > > I imagine there's plenty of smarter ways to do it though. The smartest way would be to have "all zeros" be the correct default for the initial state data. The next smartest way would be to pick the first zeroed value as an "initialized" variable, and check it each time, setting it to 1, once the initialization has taken place. The next smartest way would be to treat it as if it were a static class declaration that needed to be automatically constructed before it could be used (see the code for this in my previous posting). This one is kind of a tossup, since it gets the extra check out of the main path, but relies on weird glue code. The least smartest way would be to create an init function which had to be called by main() before you could use stdio, unlike all other UNIX systems on the planet. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stdout changes break some ports
* Kris Kennaway <[EMAIL PROTECTED]> [2002-03-31 08:48]: > On Sun, Mar 24, 2002 at 05:54:36PM -0800, Kris Kennaway wrote: > > On Sun, Mar 24, 2002 at 06:43:13PM -0700, M. Warner Losh wrote: > > > > > : David O'Brien committed a workaround to the clog port yesterday to > > > : move the initializer to main() instead of trying to do it statically. > > > : > > > : Is this something which is supposed to work? > > > > > > No. This isn't something that is guaranteed to work per the > > > standards, iirc. The proper fix is to put the initializer in main. > > > > OK. Someone needs to go and fix those 84 ports then. > How does one fix this in a library? I've been moving the > initialization to main() for applications. Unfortunately it is not so straight forward. IMO, the best solution is to initialise to NULL and test for this when called and change them to stdin and stdout where necessary. This is a little overhead but the cleanest way IMO. I heard of the possibility to do things like static FILE*fpout=NULL; #define fp (fpout?fpout:stdout) But I never tested this. I can help you a little bit changing this in the concerning libraries, if you want, since this seems to be a lot of work. Regards, Olli -- Department of Computing Science Federal Armed Forces University Munich http://ist.unibw-muenchen.de/People/obraun/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asr can not map memory?
Alfred Perlstein wrote: > * Terry Lambert <[EMAIL PROTECTED]> [020331 00:05] wrote: > > Michael Smith wrote: > > > > What's the basis of the assumption that the I/O range is > > > > unsupported in the first place, and why isn't it true for this > > > > bridge chip, if it's a valid assumption for others? > > > > > > The information was provided in the debugging output and code that Alfred > > > supplied in earlier messages. The short answer is "programmer error". > > > > > > You're walking into another conversation with insufficient context. 8) > > > > Hey, I'll always sit still for someone willing to give me context... > > 8-). > > > > I was thinking it would be easier to get enough info to Alfred, > > and let the patch pop out there. 8-) 8-). > > Issue is that there's something wonky with the PCI code such that > it doesn't realize that the bus hanging off of a bus wants another > memory range outside the PCI device's range. I wonder if there > should be a flag to allow this? Some sort of escape mechanism? > > I need sleep. :) Yeah, you do. I fully understood _that_ context; I think Mike was talking about other context. It's pretty clear to me that ranges ought to be per bridge chipset, rather than global... I thought that that was what the option was working around: that they were not. The option might as well have "DO_NOT_USE_THIS_MAGIC_OPTION_" as a prefix on it, the way it was being discussed. If that's the case, then something is broken with the bridge handling code. We all await your patch, since you have hardware to demonstrate the problem and the fix... 8-) 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stdout changes break some ports
At 10:46 PM -0800 3/30/02, Kris Kennaway wrote: >On Sun, Mar 24, 2002 at 05:54:36PM -0800, Kris Kennaway wrote: > > On Sun, Mar 24, 2002 at 06:43:13PM -0700, M. Warner Losh wrote: > > > No. This isn't something that is guaranteed to work per > > > the standards, iirc. The proper fix is to put the > > > initializer in main. > > >> OK. Someone needs to go and fix those 84 ports then. > >How does one fix this in a library? I've been moving the >initialization to main() for applications. If all else fails, have some global static variable, and check the value in the routine(s) which care. if the flag variable is still zero, then initialize the stdout variable and change the flag variable to 1. I imagine there's plenty of smarter ways to do it though. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stdout changes break some ports
Terry Lambert wrote:
> Kris Kennaway wrote:
> > How does one fix this in a library? I've been moving the
> > initialization to main() for applications.
>
> Use assembly glue to put it in a linker set that gets pulled
> in by the .init code.
>
> This will only work for user space code, since it depends in
> the crt0 treating it like a C++ binary (linker sets are a C++
> feature which FreeBSD uses all over anyway).
Realizing that I think this is the wrong way to fix this problem,
add the following to your library:
foo.c:
#include
static void
run_before_main(void)
{
... /* my crap */
}
TEXT_SET(__CTOR_LIST__, run_before_main);
If you want something run on rundown, use:
TEXT_SET(__DTOR_LIST__, run_after_main);
(or just use atexit(3), if you can live with the registration
polluting your source code).
Doing the code this way will guarantee that your code will
work on any FreeBSD supported platform where C++ works.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: asr can not map memory?
* Terry Lambert <[EMAIL PROTECTED]> [020331 00:05] wrote: > Michael Smith wrote: > > > What's the basis of the assumption that the I/O range is > > > unsupported in the first place, and why isn't it true for this > > > bridge chip, if it's a valid assumption for others? > > > > The information was provided in the debugging output and code that Alfred > > supplied in earlier messages. The short answer is "programmer error". > > > > You're walking into another conversation with insufficient context. 8) > > Hey, I'll always sit still for someone willing to give me context... > 8-). > > I was thinking it would be easier to get enough info to Alfred, > and let the patch pop out there. 8-) 8-). Issue is that there's something wonky with the PCI code such that it doesn't realize that the bus hanging off of a bus wants another memory range outside the PCI device's range. I wonder if there should be a flag to allow this? Some sort of escape mechanism? I need sleep. :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
