Re: Patch to teach config(8) about platforms.
On Wed, 2003-01-29 at 18:46, Marcel Moolenaar wrote:
On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote:
Agreed. There's an advantage there, but see also my reply to
Juli about the use of machine to mean MACHINE_ARCH and the
use of platform to mean MACHINE. This I don't find appealing.
I can see your point here, but if needed I'd rather see them renamed to
MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE
and MACHINE_ARCH are confusingly similar.
I'm not sure I understand you. I don't mind the capitalization,
just that we have MACHINE_ARCH and MACHINE defined on the hand
and machine and platform on the other. If you would ask a
person how they should be related, I can imagine that the
logical should would be to relate machine to MACHINE and
platform to MACHINE_ARCH. Which is opposite to what Juli
proposed. That's the unappealing part. Not a biggy, but
something that's better avoided now than fixed later.
In that case I'm mostly in agreement. Avoiding confusion is a Good
Thing(tm).
[snip]
Agreed. We should not do the same, but instead of saying that we
do mips and powerpc different, I think we should say that mips and
powerpc do it the normal way and pc98 does it differently. I like
to use an extra keyword for the weird case (pc98) and not the normal
(common) case. See also above, this is looking at it from a point
of view we'll going to have in the future, not a point of view
we all have now.
Ok, so are you saying here that Juli's patch is ok but we need to look
at how we deal with pc98?
I would not introduce a platform/foo.h, but rather
machine/${variant}/foo.h. The reason for this is that the
/usr/include/platform directory is only needed on powerpc and mips,
which seems to indicate that it should be under machine. Also,
the use of machine/${variant} allows us to install the headers for
all variants, which may improve cross-building. Note that I haven't
tried it on for size, so I'm not fixated on it. I was hoping this
would fall out of the discussion.
You see how the current approach affects other architectures if you
look at the diff for src/sys/conf/kmod.mk. All architectures,
including those that don't have multiple variants will have a link
added that mirrors the machine link. I find that aestheticly
displeasing. If you have the variants under machine, you don't
have to create more links.
The change to src/include/Makefile also seems to have a bug in
that it depends in /usr/include/platform to be created by
mtree, but I don't see and diff for that. Adding platform to
BSD.include.dist means that every architecture gets the
directory. Otherwise it has to be created by hand for those
platforms that have it.
The same happens in config(8) where we create a platform link
in all cases, not just for powerpc and mips.
Ok, the nice side to having platform/foo.h is that (to go back to the
endian example) you can have machine/endian.h including
platform/endian.h and not having to be a mess like:
#if defined(POWERMAC)
#include machine/powermac/endian.h
#elsif defined(LITTLE_ENDIAN_ARCH)
#include machine/little_endian_arch/endian.h
#elsif
...
#endif
It doesn't have to be /usr/include/platform, it could be
/usr/include/machine/platform for instance, but it'd be nice for it to
have a constant name.
Or are you saying that you would prefer to change how the machine
directive works in config(8) and introduce a new non-standard
directive for pc98?
That was the thought I was playing with.
Hmm. Juli, what do you think of this?
We could perhaps introduce platform and make it mutually exclusive
with machine, and that way if the config file has a machine
directive we get the old behaviour and only invoke the new behaviour
when we have a platform directive. Then we can start transitioning
over to it as needed. This is pretty much a no-op on sparc64, ia64 and
alpha (AFAIK) but powerpc can switch, and i386/pc98 can switch to it
later on. Perhaps this could be a target for 6.0.
If the former, I agree totally. If the latter, I'm not so sure. I'd
rather see the directive be platform as that is a much more accurate
name for it IMO. If this means we kill off the machine directive, then
that may be how it works.
I don't have a problem with the name platform, although I avoid it
for now to avoid confusion.
*nod* Fair enough.
--
Benno Rice [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 11:56:59PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] You see how the current approach affects other architectures if you look at the diff for src/sys/conf/kmod.mk. All architectures, including those that don't have multiple variants will have a link added that mirrors the machine link. I find that aestheticly displeasing. If you have the variants under machine, you don't have to create more links. Only within the kernel build directory. That's at Peter's request. Doing it for the installed version breaks mkioctl. But not doing it makes the installed version rather useless on mips and powerpc, doesn't it? I mean, not having the links to the platform directory when headers in the machine directory depend on it? Or am I missing the purpose of the installed bsd.kmod.mk? The same happens in config(8) where we create a platform link in all cases, not just for powerpc and mips. See the comment for kmod.mk. It doesn't affect anything. It can be changed, if you like. It depends. If we opt for a platform directory in all case, we might as well have the link in all cases. I don't like it, but won't actually wake up every morning and go look for it in an attempt to make my SM life more enjoyable :-) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Please don't define away DEBUGPRINTF and similar...
I am currently letting FlexeLint loose on the kernel again, and I have
turned my attention to a new warning from it:
_
return (err);
../../../dev/usb/usb_subr.c 604 Warning 548: else expected
Initally I ignored these warnings because the couple of them which
I looked at were actually ok, but now that I looked through all of
them I uncovered a couple of bugs which all follow the same pattern,
which I think I can best illustrate by quoting a randomly chosen
case:
#ifdef USB_DEBUG
#define DPRINTF(x) if (usbdebug) logprintf x
#define DPRINTFN(n,x) if (usbdebug(n)) logprintf x
extern int usbdebug;
#else
#define DPRINTF(x)
#define DPRINTFN(n,x)
#endif
[...]
if (index == USB_UNCONFIG_INDEX) {
/* We are unconfiguring the device, so leave unallocated. */
DPRINTF((usbd_set_config_index: set config 0\n));
err = usbd_set_config(dev, USB_UNCONFIG_NO);
if (err)
DPRINTF((usbd_set_config_index: setting config=0
failed, error=%s\n, usbd_errstr(err)));
return (err);
}
Please be more careful.
Here are the places this warning occurs in GENERIC:
../../../dev/amr/amr_cam.c 566 Warning 548: else expected
../../../dev/amr/amr_cam.c 629 Warning 548: else expected
../../../dev/amr/amr.c 515 Warning 548: else expected
../../../dev/em/if_em_hw.c 2166 Warning 548: else expected
../../../dev/em/if_em_hw.c 2237 Warning 548: else expected
../../../dev/usb/ums.c 594 Warning 548: else expected
../../../dev/usb/usb_subr.c 604 Warning 548: else expected
../../../dev/usb/usbdi.c 974 Warning 548: else expected
../../../dev/usb/usbdi.c 1034 Warning 548: else expected
../../../kern/kern_switch.c 448 Warning 548: else expected
--
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
Re: net-snmp errors
On Tue, Jan 28, 2003 at 04:30:47PM -0600, Nick H. -- Technical Support Engineer wrote: Sorry about emailing both lists, as Im not sure which one this falls under. It's a current machine (5.0-CURRENT) and it's a problem with a port (net-snmp). Below is what happens: `VM_METER' undeclared (first use in this function) Anyone know how to fix this or a way around it? You need to update and get version 1.17 of /usr/src/sys/vm/vm_param.h. See: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1718003+1720385+/usr/local/www/db/text/2003/freebsd-current/20030119.freebsd-current -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, Jan 29, 2003 at 07:19:38PM +1100, Benno Rice wrote: The same happens in config(8) where we create a platform link in all cases, not just for powerpc and mips. Ok, the nice side to having platform/foo.h is that (to go back to the endian example) you can have machine/endian.h including platform/endian.h and not having to be a mess like: #if defined(POWERMAC) #include machine/powermac/endian.h #elsif defined(LITTLE_ENDIAN_ARCH) #include machine/little_endian_arch/endian.h #elsif ... #endif It doesn't have to be /usr/include/platform, it could be /usr/include/machine/platform for instance, but it'd be nice for it to have a constant name. Agreed. A link is better. Or are you saying that you would prefer to change how the machine directive works in config(8) and introduce a new non-standard directive for pc98? That was the thought I was playing with. Hmm. Juli, what do you think of this? We could perhaps introduce platform and make it mutually exclusive with machine, and that way if the config file has a machine directive we get the old behaviour and only invoke the new behaviour when we have a platform directive. Then we can start transitioning over to it as needed. This is pretty much a no-op on sparc64, ia64 and alpha (AFAIK) but powerpc can switch, and i386/pc98 can switch to it later on. Perhaps this could be a target for 6.0. What if an architecture doesn't have different platforms. Do we want to give a platform name that matches the architecture or do we make platform optional? I think I prefer it to be optional. This could mean we have a kernel config file that has no machine and not platform keyword. I've been thinking about the implicit selection of the architecture based on where the config file lives. We currently restrict where config(8) can be run from and don't really have a nice way of dealing with the case where SYSTEM_NAME is actually a path. This basicly means that we must run config(8) from /sys/$ARCH/conf. This makes the implicit selection of the architecture logical, even or especially if we want to remove the restriction of where we have the kernel config file and/or where we run the config(8) utility from later. We can always add the necessary options and keywords to deal with the added flexibility, including making the architecture explicit. In that case it would work the same on all architectures without any weird interferences of having multiple platforms. Thoughts? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic in softupdates
Just got this panic under CURRENT: [... 21 frames after the panic removed ...] #22 0xc02494fc in softdep_disk_io_initiation (bp=0x100) at ../../../ufs/ffs/ffs_softdep.c:3453 #23 0xc01df5ad in cluster_wbuild (vp=0xc2f457c4, size=16384, start_lbn=11, len=3) at buf.h:408 #24 0xc01d980c in vfs_bio_awrite (bp=0xc77ba030) at ../../../kern/vfs_bio.c:1633 #25 0xc0250bea in ffs_fsync (ap=0xcd326c48) at ../../../ufs/ffs/ffs_vnops.c:258 #26 0xc024fdfe in ffs_sync (mp=0xc2666200, waitfor=3, cred=0xc0eb5e80, td=0xc0ec5380) at vnode_if.h:612 #27 0xc01eb85a in sync_fsync (ap=0xcd326cd0) at ../../../kern/vfs_subr.c:3505 #28 0xc01e83ce in sched_sync () at vnode_if.h:612 #29 0xc018b444 in fork_exit (callout=0xc01e8250 sched_sync, arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:873 FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #6: Tue Jan 21 16:05:16 CET 2003 [EMAIL PROTECTED]:/src/src/sys/i386/compile/tCAERDONN i386 Sources around Jan, 21th. -- Ollivier ROBERT -=- Eurocontrol EEC/AMI -=- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic in softupdates
OR Just got this panic under CURRENT: OR [... 21 frames after the panic removed ...] OR #22 0xc02494fc in softdep_disk_io_initiation (bp=0x100) OR at ../../../ufs/ffs/ffs_softdep.c:3453 [ ...snip...] looks simulate to kern/42277 and kern/42235 -- VAMPIRO-RIPN http://vampiro.rootshell.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make buildworld failure
Yeah, that fixed the above mentioned problem.. however i'm running into a build problem about an hour later, related to telnet.. maybe it was fixed overnight in cvs, i'll see if it will build now. Let me know how it goes... I may wanna try that To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make buildworld failure
On Wed, Jan 29, 2003 at 06:16:04AM -0500, Jeff Utter wrote: Yeah, that fixed the above mentioned problem.. however i'm running into a build problem about an hour later, related to telnet.. maybe it was fixed overnight in cvs, i'll see if it will build now. I don't think so, I cvsupped about 30 min ago. cc -O -pipe -march=pentium3 -DENCRYPTION -DAUTHENTICATION -DSRA -I/usr/src/secu re/lib/libtelnet/../../../crypto/telnet -I/usr/src/secure/lib/libtelnet/../../.. /crypto/telnet/libtelnet -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /u sr/src/crypto/telnet/libtelnet/enc_des.c -o enc_des.o cc1: warnings being treated as errors /usr/src/crypto/telnet/libtelnet/enc_des.c: In function `fb64_start': /usr/src/crypto/telnet/libtelnet/enc_des.c:214: warning: implicit declaration of function `des_new_random_key' *** Error code 1 Stop in /usr/src/secure/lib/libtelnet. *** Error code 1 Stop in /usr/src/secure/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewire hangs on Thinkpad
On Sat, Jan 25, 2003 at 11:55:01AM -0700, M. Warner Losh wrote: This sounds like it might be an interrupt storm. I'm not sure if the fwohci driver is failing to clear an interrupt source, or if the cardbus bridge is failing. Have you connected a fw device to the firewire card? I've been able to run a few more tests, even though I've not done abused it in every way I have in my mind yet... The evidence I currently have is: - if I load the modules at loader time everything is fine, with or without a device attached - if I load the modules later on, the kldload doesn't return and the system stops responding; I can still enter DDB. The only way to recover from that is to eject the card; at that point, the system is usable BUT as soon as there is network activity, the system freezes hard (can't get to DDB). IMHO this is 100% an interrupt problem. Does this ring a bell with one of you, or should I provide more info? Bye, Andrea -- The dark ages were caused by the Y1K problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [5.0-RELEASE] uid option in ipfw
On 03:50+0300, Jan 28, 2003, Oleg Baranov wrote:
It looks like firewall in 5.0-RELEASE doesn't respect uid option.
I migrated from 4.7 where the following lines worked fine:
allow tcp from me to any uid 500 setup
allow udp from me to any uid 500 keep-state
I couldn't get these lines working on 5.0 (packets don't match these rules).
it's a little strange thing - the following lines DO work, but they
match for ANY user on the system:
allow tcp from me to any uid 0 setup
allow udp from me to any uid 0 keep-state
also the counters are updated in a mysterious way...
it's a very confusing thing for me. can anyone help to solve the problem
plz?
Please try a patch below.
Index: sys/netinet/ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.25
diff -u -r1.25 ip_fw2.c
--- sys/netinet/ip_fw2.c21 Jan 2003 08:56:03 - 1.25
+++ sys/netinet/ip_fw2.c29 Jan 2003 11:50:32 -
@@ -1515,7 +1515,7 @@
#endif
if (cmd-opcode == O_UID) {
match =
- socheckuid(pcb-inp_socket,
+ !socheckuid(pcb-inp_socket,
(uid_t)((ipfw_insn_u32 *)cmd)-d[0]);
} else {
match = groupmember(
%%%
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Wed Jan 29 03:32:21 PST 2003 -- Kernel build for GENERIC completed on Wed Jan 29 04:03:22 PST 2003 -- Kernel build for LINT started on Wed Jan 29 04:03:23 PST 2003 -- === vinum Makefile, line 4440: warning: duplicate script for target geom_bsd.o ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and is not compiled with LINT /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is not compiled with LINT /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open': /h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once /h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.) cc1: warnings being treated as errors /h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close': /h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read': /h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write': /h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl': /h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap': /h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from incompatible pointer type *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
unsubscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
restore(8) triggers panic
I decided to dump, newfs -O2, and restore -r some filesystems on my -CURRENT/alpha box. restore reliably triggered a panic such as this: free inode /var/64 has 27384711479296 blocks bad block 1043841974, ino 64 pid 51 (restore), uid 0 inumber 64 on /var: bad block free inode /var/64 had -100 blocks mode = 0177, inum = 78, fs = /var panic: ffs_valloc: dup alloc UFS1 or UFS2, softupdates on or off, doesn't matter. I eventually managed to restore the filesystem by populating it with some dummy files and running the restore afterwards. -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewire hangs on Thinkpad
At Wed, 29 Jan 2003 12:49:51 +0100, Andrea Campi wrote: On Sat, Jan 25, 2003 at 11:55:01AM -0700, M. Warner Losh wrote: This sounds like it might be an interrupt storm. I'm not sure if the fwohci driver is failing to clear an interrupt source, or if the cardbus bridge is failing. Have you connected a fw device to the firewire card? I've been able to run a few more tests, even though I've not done abused it in every way I have in my mind yet... The evidence I currently have is: - if I load the modules at loader time everything is fine, with or without a device attached - if I load the modules later on, the kldload doesn't return and the system stops responding; I can still enter DDB. The only way to recover from that is to eject the card; at that point, the system is usable BUT as soon as there is network activity, the system freezes hard (can't get to DDB). IMHO this is 100% an interrupt problem. Does this ring a bell with one of you, or should I provide more info? I have another strange firewire and cardbus/pccard interaction. If I load firewire module while I'm using wi0 in cardbus slot, the wi0 stop its work and output following messages. (In my laptop, fwohci is on PCI.) wi0: xmit failed wi0: timeout in wi_cmd 0x010b; event status 0x ... Even if I replace fwochi_pci_attach() with one line 'return EIO' (i.e. the doesn't anything), the problem still happens. I think this is not a problem of fwohci. Maybe PCI or Cardbus/PCcard or kldload problem? /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
trouble starting X, unresolved symbol
I'm trying to get X up and going after upgrading 4.7 - 5.0. I have portupgraded XFree86-4 and wrapper. Here is the output from /var/log/XFree86.0.log: Symbol from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved! Fatal server error: Caught signal 11. Server aborting Any thoughts? Thanks, Kirk R. Wythers email: [EMAIL PROTECTED] University of Minnesota tel: 612.625.2261 Department of Forest Resources fax: 612.625.5212 Saint Paul, MN 55108 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Please don't define away DEBUGPRINTF and similar...
In article [EMAIL PROTECTED],
Poul-Henning Kamp [EMAIL PROTECTED] wrote:
I am currently letting FlexeLint loose on the kernel again, and I have
turned my attention to a new warning from it:
_
return (err);
../../../dev/usb/usb_subr.c 604 Warning 548: else expected
Initally I ignored these warnings because the couple of them which
I looked at were actually ok, but now that I looked through all of
them I uncovered a couple of bugs which all follow the same pattern,
which I think I can best illustrate by quoting a randomly chosen
case:
#ifdef USB_DEBUG
#define DPRINTF(x) if (usbdebug) logprintf x
#define DPRINTFN(n,x) if (usbdebug(n)) logprintf x
extern int usbdebug;
#else
#define DPRINTF(x)
#define DPRINTFN(n,x)
#endif
[...]
if (index == USB_UNCONFIG_INDEX) {
/* We are unconfiguring the device, so leave unallocated. */
DPRINTF((usbd_set_config_index: set config 0\n));
err = usbd_set_config(dev, USB_UNCONFIG_NO);
if (err)
DPRINTF((usbd_set_config_index: setting config=0
failed, error=%s\n, usbd_errstr(err)));
return (err);
}
It's complaining because of the empty statement (;) in the if
clause, I suppose. Does it shut up if you define the macros like
this in the disabled case?
#define DPRINTF(x) ((void)0)
#define DPRINTFN(n,x)((void)0)
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sshd tunneling problems (5.0RELEASE)
ssh sshd normally work fine, but I cannot establish any tunnels (tried with multiple clients). Every time a tunnel is requested, sshd sends this message to syslog: Jan 29 11:37:08 kopirka sshd[3521]: error: getsockopt TCP_NODELAY: Connection reset by peer Since the same setup is working fine on a 4-STABLE system, it seems that it is a 5.x problem. -- Ashes to ashes, DOS to DOS ivoras @ fer.hr To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PHP on 5.0RELEASE
I've got a big ugly PHP build on a brand new, otherwise clean 5.0 box that is dumping cores. It works great as an apache module, but the CLI always coredumps. Here's gdb's output: Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libc-client4.so.8...done. Loaded symbols for /usr/local/lib/libc-client4.so.8 Reading symbols from /usr/local/lib/libmm.so.12...done. Loaded symbols for /usr/local/lib/libmm.so.12 Reading symbols from /usr/local/lib/libpspell.so.15...done. Loaded symbols for /usr/local/lib/libpspell.so.15 Reading symbols from /usr/local/payflowpro/lib/libpfpro.so...done. Loaded symbols for /usr/local/payflowpro/lib/libpfpro.so Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.10...done. Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.10 Reading symbols from /usr/local/lib/libmhash.so.2...done. Loaded symbols for /usr/local/lib/libmhash.so.2 Reading symbols from /usr/lib/libcrypt.so.2...done. Loaded symbols for /usr/lib/libcrypt.so.2 Reading symbols from /usr/lib/libpam.so.2...done. Loaded symbols for /usr/lib/libpam.so.2 Reading symbols from /usr/local/lib/libpng.so.5...done. Loaded symbols for /usr/local/lib/libpng.so.5 Reading symbols from /usr/lib/libz.so.2...done. Loaded symbols for /usr/lib/libz.so.2 Reading symbols from /usr/lib/libssl.so.2...done. Loaded symbols for /usr/lib/libssl.so.2 Reading symbols from /usr/lib/libcrypto.so.2...done. Loaded symbols for /usr/lib/libcrypto.so.2 Reading symbols from /usr/lib/libm.so.2...done. Loaded symbols for /usr/lib/libm.so.2 Reading symbols from /usr/local/lib/libcurl.so.2...done. Loaded symbols for /usr/local/lib/libcurl.so.2 Reading symbols from /usr/lib/libc.so.5...done. Loaded symbols for /usr/lib/libc.so.5 Reading symbols from /usr/local/lib/libaspell.so.15...done. Loaded symbols for /usr/local/lib/libaspell.so.15 Reading symbols from /usr/lib/libstdc++.so.4...done. Loaded symbols for /usr/lib/libstdc++.so.4 Reading symbols from /usr/ports/textproc/aspell/work/aspell-0.50.3/lib/.libs/libaspell.so.15...done. Loaded symbols for /usr/ports/textproc/aspell/work/aspell-0.50.3/lib/.libs/libaspell.so.15 Reading symbols from /usr/libexec/ld-elf.so.1...done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x2856dde0 in strcmp () from /usr/lib/libc.so.5 and here is what php is configured with as per customer's request: './configure' \ '--with-apxs=/usr/local/apache/bin/apxs' \ '--with-mysql=/usr/local' \ '--with-imap=/usr/local' \ '--enable-track-vars' \ '--with-mhash' \ '--with-pspell' \ '--with-gd' \ '--with-ftp' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-sockets' \ '--enable-exif' \ '--enable-discard-path' \ '--enable-bcmath' \ '--with-mm' \ '--with-openssl' \ '--with-curl' \ '--with-pfpro=/usr/local/payflowpro' \ '--with-zlib' \ Does anyone have any ideas before I try removing one line at a time from the config till I find the culprit? Thanks, Adam Adam Bayless| vi /etc/mail/aliases Fibernet System Janitor | complaints: /dev/null [EMAIL PROTECTED] | :wq baylessfamily.org/~abayless | newaliases To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make buildworld failure
Same problem here: cc1: warnings being treated as errors /usr/src/crypto/telnet/libtelnet/enc_des.c: In function `fb64_start': /usr/src/crypto/telnet/libtelnet/enc_des.c:214: warning: implicit declaration of function `des_new_random_key' *** Error code 1 Stop in /usr/src/secure/lib/libtelnet. *** Error code 1 Stop in /usr/src/secure/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Regards, Nick - Original Message - From: leafy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 5:48 AM Subject: Re: make buildworld failure : On Wed, Jan 29, 2003 at 06:16:04AM -0500, Jeff Utter wrote: : Yeah, that fixed the above mentioned problem.. however i'm running into a build problem about an hour later, related to telnet.. maybe it was fixed overnight in cvs, i'll see if it will build now. : : I don't think so, I cvsupped about 30 min ago. : : : c -O -pipe -march=pentium3 -DENCRYPTION -DAUTHENTICATION -DSRA -I/usr/src/s ecu : re/lib/libtelnet/../../../crypto/telnet -I/usr/src/secure/lib/libtelnet/../. ./.. : crypto/telnet/libtelnet -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /u : sr/src/crypto/telnet/libtelnet/enc_des.c -o enc_des.o : cc1: warnings being treated as errors : /usr/src/crypto/telnet/libtelnet/enc_des.c: In function `fb64_start': : /usr/src/crypto/telnet/libtelnet/enc_des.c:214: warning: implicit declaration of : function `des_new_random_key' : *** Error code 1 : : Stop in /usr/src/secure/lib/libtelnet. : *** Error code 1 : : Stop in /usr/src/secure/lib. : *** Error code 1 : : Stop in /usr/src. : *** Error code 1 : : Stop in /usr/src. : *** Error code 1 : : Stop in /usr/src. : *** Error code 1 : : Stop in /usr/src. : : -- : Without the userland, the kernel is useless. : --inspired by The Tao of Programming : : 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: Patch to teach config(8) about platforms.
On 29-Jan-2003 Benno Rice wrote: On Wed, 2003-01-29 at 18:46, Marcel Moolenaar wrote: On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote: Agreed. There's an advantage there, but see also my reply to Juli about the use of machine to mean MACHINE_ARCH and the use of platform to mean MACHINE. This I don't find appealing. I can see your point here, but if needed I'd rather see them renamed to MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE and MACHINE_ARCH are confusingly similar. I'm not sure I understand you. I don't mind the capitalization, just that we have MACHINE_ARCH and MACHINE defined on the hand and machine and platform on the other. If you would ask a person how they should be related, I can imagine that the logical should would be to relate machine to MACHINE and platform to MACHINE_ARCH. Which is opposite to what Juli proposed. That's the unappealing part. Not a biggy, but something that's better avoided now than fixed later. In that case I'm mostly in agreement. Avoiding confusion is a Good Thing(tm). Just be consistent please. Ignore the implementation and choose one of these two paths: 1) Use MACHINE and MACHINE_ARCH with MACHINE_ARCH being the architecture and MACHINE being the platform and use the 'machine' keyword for MACHINE with MACHINE_ARCH either explicit (in which case 'machine' defaults to 'arch' just like MACHINE defaults to MACHINE_ARCH) or implicit from the config file location. 2) Use PLATFORM and MACHINE with matching config keywords and if platform is not specified it defaults to MACHINE. I don't really care which, but please just pick one and be fully consistent. If you go with 1), I suggest an alternative header file layout where you have an /usr/include/arch and the machine/ headers (which are platform-specific) include the arch/ headers for common things. I think both ways can work, but please do not change the meaning of one set w/o changing the other. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Buildworld failure
Apologies if this comes through again after this. I sent it from a different account this afternoon and it doesn't appear to have got through so I'm sending it again. I get a different problem to the telnet buildworld failure: === lib/liby sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 liby.a /usr/obj/usr/src/i386/usr/lib sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 liby_p.a /usr/obj/usr/src/i386/usr/lib === lib/libz sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libz.a /usr/obj/usr/src/i386/usr/lib sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/lib/libz/zconf.h /usr/src/lib/libz/zlib.h /usr/obj/usr/src/i386 /usr/include sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libz_p.a /usr/obj/usr/src/i386/usr/lib sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libz.so.2 /usr/obj/usr/src/i386/usr/lib ln -fs libz.so.2 /usr/obj/usr/src/i386/usr/lib/libz.so 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error --- Matt ([EMAIL PROTECTED]) http://www.xtaz.co.uk/ --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Seat-belt for source upgrades from stable to current
Hi folks, Can anyone think of a good way to implement an installworld / installkernel seat-belt for source upgrades from stable to current? What I'm looking for is a way for installworld and installkernel in the current source to look for some signature in the target filesystem that suggests that a stable world is about to be upgraded to current. I want this because far too many people, far too frequently, update their source to HEAD by mistake and then end up with current when they really wanted stable. [1] If this can be done cleanly, I'd like to do it. If not, I don't want it to be a hack. So, ideas on infallible signatures? Ciao, Sheldon. [1] Guess who just trashed a stable installation for the 3rd time in 3 years today? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Wed, Jan 29, 2003 at 09:18:22PM +0200, Sheldon Hearn wrote: Hi folks, Can anyone think of a good way to implement an installworld / installkernel seat-belt for source upgrades from stable to current? What I'm looking for is a way for installworld and installkernel in the current source to look for some signature in the target filesystem that suggests that a stable world is about to be upgraded to current. I want this because far too many people, far too frequently, update their source to HEAD by mistake and then end up with current when they really wanted stable. [1] If this can be done cleanly, I'd like to do it. If not, I don't want it to be a hack. So, ideas on infallible signatures? /usr/bin/uname -r /usr/obj/usr/src/usr.bin/uname/uname -r -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problem with X
On Tue, 28 Jan 2003, joseph wrote: Try a make build world and see if that version of libc_r works. It should fix the problem. joseph I tried that... now the error is: Symbol from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved! This is getting old. any other ideas? thanks, Kirk On Mon, 2003-01-27 at 13:07, Alexander Pohoyda wrote: Charlie ROOT [EMAIL PROTECTED] writes: root, nor a regular user. Is this a font path problem? No, it is not. /usr/libexec/ld-elf.so.1: /usr/lib/libc_r.so.5: Undefined symbol __thr_jtable This is a problem. Version numbers are OK, though. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Wed Jan 29 14:27:54 EST 2003 -- === hme In file included from /tinderbox/sparc64/src/sys/dev/aic7xxx/aic7xxx_osm.h:64, from /tinderbox/sparc64/src/sys/dev/aic7xxx/ahc_pci.c:36: machine/bus.h: In function `sparc64_dmamem_alloc_size': machine/bus.h:1096: structure has no member named `dmamem_alloc' machine/bus.h:1096: structure has no member named `parent' machine/bus.h:1098: structure has no member named `dmamem_alloc_size' machine/bus.h: In function `sparc64_dmamem_free_size': machine/bus.h:1122: structure has no member named `dmamem_free' machine/bus.h:1122: structure has no member named `parent' machine/bus.h:1124: structure has no member named `dmamem_free_size' *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problem with X
Symbol from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved! The same error was reported about a week ago on [EMAIL PROTECTED] mailing list. There was, however, no solution posted. You might try to contact the guy admin(at)antiv(dot)pe(dot)kr, maybe he has some update. Don't forget to post a message to the list if you have a solution! -- Alexander Pohoyda [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Wed, Jan 29, 2003 at 07:19:38PM +1100, Benno Rice wrote: Or are you saying that you would prefer to change how the machine directive works in config(8) and introduce a new non-standard directive for pc98? That was the thought I was playing with. Hmm. Juli, what do you think of this? We could perhaps introduce platform and make it mutually exclusive with machine, and that way if the config file has a machine directive we get the old behaviour and only invoke the new behaviour when we have a platform directive. Then we can start transitioning over to it as needed. This is pretty much a no-op on sparc64, ia64 and alpha (AFAIK) but powerpc can switch, and i386/pc98 can switch to it later on. Perhaps this could be a target for 6.0. What if an architecture doesn't have different platforms. Do we want to give a platform name that matches the architecture or do we make platform optional? I think I prefer it to be optional. This could mean we have a kernel config file that has no machine and not platform keyword. Well, the whole point of platform is it doesn't affect first-class platforms, which is where we have one architecture, one platform. In those cases it would gain nothing, and by not having it, there is no loss. Of course, i386 might eventually grow it, if pc98 is merged, as there may be some things we would restrict to the !pc98 case. But hell, at that point we may have platform isa and platform acpi or something, for the two different growing i386 platforms. I suppose jhb might prefer legacy for the former :) I've been thinking about the implicit selection of the architecture based on where the config file lives. We currently restrict where config(8) can be run from and don't really have a nice way of dealing with the case where SYSTEM_NAME is actually a path. This basicly means that we must run config(8) from /sys/$ARCH/conf. This makes the implicit selection of the architecture logical, even or especially if we want to remove the restriction of where we have the kernel config file and/or where we run the config(8) utility from later. We can always add the necessary options and keywords to deal with the added flexibility, including making the architecture explicit. In that case it would work the same on all architectures without any weird interferences of having multiple platforms. If we just make machine mean more of what it means now, then we're set. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: John Baldwin [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On 29-Jan-2003 Benno Rice wrote: On Wed, 2003-01-29 at 18:46, Marcel Moolenaar wrote: On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote: Agreed. There's an advantage there, but see also my reply to Juli about the use of machine to mean MACHINE_ARCH and the use of platform to mean MACHINE. This I don't find appealing. I can see your point here, but if needed I'd rather see them renamed to MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE and MACHINE_ARCH are confusingly similar. I'm not sure I understand you. I don't mind the capitalization, just that we have MACHINE_ARCH and MACHINE defined on the hand and machine and platform on the other. If you would ask a person how they should be related, I can imagine that the logical should would be to relate machine to MACHINE and platform to MACHINE_ARCH. Which is opposite to what Juli proposed. That's the unappealing part. Not a biggy, but something that's better avoided now than fixed later. In that case I'm mostly in agreement. Avoiding confusion is a Good Thing(tm). Just be consistent please. Ignore the implementation and choose one of these two paths: 1) Use MACHINE and MACHINE_ARCH with MACHINE_ARCH being the architecture and MACHINE being the platform and use the 'machine' keyword for MACHINE with MACHINE_ARCH either explicit (in which case 'machine' defaults to 'arch' just like MACHINE defaults to MACHINE_ARCH) or implicit from the config file location. 2) Use PLATFORM and MACHINE with matching config keywords and if platform is not specified it defaults to MACHINE. I don't really care which, but please just pick one and be fully consistent. If you go with 1), I suggest an alternative header file layout where you have an /usr/include/arch and the machine/ headers (which are platform-specific) include the arch/ headers for common things. I think both ways can work, but please do not change the meaning of one set w/o changing the other. If we change the meaning of machine, IMO the requirement to include up to *every* exported header with a stub is ugly. NetBSD does this. What if we install them as they're named. arch for the multi-arch systems, platform too... And symlink machine to arch for backwards compatability? I have to think that a complete move to a new pair of words would be GREAT, but we'd want to maintain some (faked) historic mistakes :) Unless you think that the platform headers should be the consumers, but of course, then you'd want to invert how the build, etc., are in what I'm suggesting, or? I mean, a lot of this is out of wanting the master port to drive, with the meta-data in the back, reading off the map, as it were. Aside from that, a pair of arch and platform would be good, and have them be mutually exclusive with machine where machine is for the traditional 1:1 ports. And retains the old behaviour, modulo any possible new stuff wrt config file location that arch would give us flexibility on. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: add ext2fs to the module list in modules/Makefile
On Tue, Jan 28, 2003 at 09:54:30PM -0800, David O'Brien wrote: On Mon, Jan 27, 2003 at 11:14:41PM +0200, Enache Adrian wrote: please add ext2fs to the modules list in src/sys/modules/Makefile. It is already there. :-) Just wrapped by WANT_EXT2FS_MODULE. So you need to add that to your /etc/make.conf. Oh, really thank you for the answer. And sorry for posting without carefully checking before. Regards Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, Jan 29, 2003 at 11:55:42AM -0800, Juli Mallett wrote: What if an architecture doesn't have different platforms. Do we want to give a platform name that matches the architecture or do we make platform optional? I think I prefer it to be optional. This could mean we have a kernel config file that has no machine and not platform keyword. Well, the whole point of platform is it doesn't affect first-class platforms, which is where we have one architecture, one platform. I think the number of first-class platforms is less than you think At this time only ia64 and sparc64 would fit, with ia64 having a high chance of growing another platform... Alpha has multiple platforms, but it has not been made explicit. pc98 is an alternate platform for i386. And we have PowerPC and mips. So, I look at it from the opposite way. The 1A, 1P case is a special' case of 1A, nP, for any reasonable number n ;-) 1A = one architecture, 1P = one platform, nP = multiple platforms, where n = the number of platforms. Designing it such that it's good for any number n of platforms yields a system that more easily captures the exception of n=1. Trying to handle the n1 case in a system that's primarily designed to handle n=1 is much harder. You can say that pc98 is the result of trying to handle n1 in a system that can only work with n=1. In those cases it would gain nothing, and by not having it, there is no loss. Of course, i386 might eventually grow it, if pc98 is merged, as there may be some things we would restrict to the !pc98 case. But hell, at that point we may have platform isa and platform acpi or something, for the two different growing i386 platforms. I suppose jhb might prefer legacy for the former :) What about IO_APIC vs PIC? The point is not that we're discussing whether or not they should be platforms, but that in a weird way one could treat it as different platforms. If we can handle such a case then nothing is lost if we don't make use of it for i386. If we just make machine mean more of what it means now, then we're set. But pc98 needs to be dealt with. Maybe a summary of what's been discussed would be a good idea. We've had a lot of mail with some confusion to be dealt with as well... -- 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: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] If we just make machine mean more of what it means now, then we're set. But pc98 needs to be dealt with. Maybe a summary of what's been discussed would be a good idea. We've had a lot of mail with some confusion to be dealt with as well... Well, yes and no... If we make machine mean more of where stuff is which is what it means now, then we can have machine pc98 for it, until it moves to the new world order (if ever) and use that to figure out where files,options,ldscript,... And so on, fine. It obviously already does the right thing wrt MACHINE_ARCH for how things work. Those are defined by the native system's headers when make is built. And for a cross-build, they're overridden. So if we just add that one tiny little bit of logic to end up with /sys/$machine (for config), then pc98 is fine even wrt being able to build outside of the source tree... Can you tell me where pc98 is a problem here? Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, Jan 29, 2003 at 12:55:30PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] If we just make machine mean more of what it means now, then we're set. But pc98 needs to be dealt with. Maybe a summary of what's been discussed would be a good idea. We've had a lot of mail with some confusion to be dealt with as well... Well, yes and no... If we make machine mean more of where stuff is which is what it means now, then we can have machine pc98 for it, until it moves to the new world order (if ever) and use that to figure out where files,options,ldscript,... And so on, fine. It obviously already does the right thing wrt MACHINE_ARCH for how things work. Those are defined by the native system's headers when make is built. And for a cross-build, they're overridden. So if we just add that one tiny little bit of logic to end up with /sys/$machine (for config), then pc98 is fine even wrt being able to build outside of the source tree... Can you tell me where pc98 is a problem here? I thought the idea was to have machine be usable for platforms, so as to have the mapping machine-MACHINE. This makes the keyword unusable for handling the pc98 case. I guess I was confused (now you know who needs the summary :-) -- 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: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Wed, Jan 29, 2003 at 12:55:30PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] If we just make machine mean more of what it means now, then we're set. But pc98 needs to be dealt with. Maybe a summary of what's been discussed would be a good idea. We've had a lot of mail with some confusion to be dealt with as well... Well, yes and no... If we make machine mean more of where stuff is which is what it means now, then we can have machine pc98 for it, until it moves to the new world order (if ever) and use that to figure out where files,options,ldscript,... And so on, fine. It obviously already does the right thing wrt MACHINE_ARCH for how things work. Those are defined by the native system's headers when make is built. And for a cross-build, they're overridden. So if we just add that one tiny little bit of logic to end up with /sys/$machine (for config), then pc98 is fine even wrt being able to build outside of the source tree... Can you tell me where pc98 is a problem here? I thought the idea was to have machine be usable for platforms, so as to have the mapping machine-MACHINE. This makes the keyword unusable for handling the pc98 case. I guess I was confused (now you know who needs the summary :-) Well, I like what jhb has suggested, of fully moving to a new set of keywords for config(8) to describe these sorts of things, rather than having machine+platform, having arch+platform, but keeping machine for those things that want it. Does that work for you? That way there's no misunderstanding about machine as it comes out of the picture, except for cases where MACHINE_ARCH is MACHINE is machine, unless we are making the (unaffected) pc98 mistake. When I mean make machine more of what it is now, I mean just use it for finding stuff, which is all it does now. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, Jan 29, 2003 at 01:28:33PM -0800, Juli Mallett wrote: I thought the idea was to have machine be usable for platforms, so as to have the mapping machine-MACHINE. This makes the keyword unusable for handling the pc98 case. I guess I was confused (now you know who needs the summary :-) Well, I like what jhb has suggested, of fully moving to a new set of keywords for config(8) to describe these sorts of things, rather than having machine+platform, having arch+platform, but keeping machine for those things that want it. Does that work for you? Yes. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Is netstat börked?
ref5% netstat -na -p tcp ref5% dalek# netstat -an -p tcp dalek# Both times logged in via ssh, etc. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewire hangs on Thinkpad
Andrea Campi wrote: On Sat, Jan 25, 2003 at 11:55:01AM -0700, M. Warner Losh wrote: This sounds like it might be an interrupt storm. I'm not sure if the fwohci driver is failing to clear an interrupt source, or if the cardbus bridge is failing. Have you connected a fw device to the firewire card? I've been able to run a few more tests, even though I've not done abused it in every way I have in my mind yet... The evidence I currently have is: - if I load the modules at loader time everything is fine, with or without a device attached - if I load the modules later on, the kldload doesn't return and the system stops responding; I can still enter DDB. The only way to recover from that is to eject the card; at that point, the system is usable BUT as soon as there is network activity, the system freezes hard (can't get to DDB). IMHO this is 100% an interrupt problem. Does this ring a bell with one of you, or should I provide more info? I expect that the attach of the device creates an interrupt if the system is already up. This would indicate that it was an order of operations problem in the driver registration for a live piece of hardware. Probably, it needs to attach the interrupt handler first, and then handle the result of an active probe as a special case (if it can). This should let you set up the hardware in the right order that you don't start getting interrupts because you've enabled them before establishing a handler. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is netstat börked?
Works here. largo# netstat -an -p tcp Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp4 0 0 *.22 *.*LISTEN tcp6 0 0 *.22 *.*LISTEN tcp4 0 0 *.80 *.*LISTEN tcp4 0 0 *.587 *.*LISTEN tcp4 0 0 *.25 *.*LISTEN FreeBSD 5.0-CURRENT #0: Mon Jan 27 04:25:33 EST 2003 Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ On Wed, 29 Jan 2003, Juli Mallett wrote: ref5% netstat -na -p tcp ref5% dalek# netstat -an -p tcp dalek# Both times logged in via ssh, etc. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD 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
Newfs börked: Kills make release in strange ways.
Newfs is börked right now (see below), and that kills make release in really strange ways. Considering I actually went as far as adding a make test target in src/sbin/newfs then it is a tiny bit disappointing that it was not used pre-commit. Poul-Henning bang# dd if=/dev/zero of=/dev/md0 dd: /dev/md0: end of device 2881+0 records in 2880+0 records out 1474560 bytes transferred in 0.153023 secs (9636198 bytes/sec) bang# newfs /dev/md0 /dev/md0: 1.4MB (2880 sectors) block size 16384, fragment size 2048 using 2 cylinder groups of 1.00MB, 64 blks, 128 inodes. super-block backups (for fsck -b #) at: 32, 2080 bang# fsck /dev/md0 fsck: Could not determine filesystem type bang# fsck_ffs /dev/md0 ** /dev/md0 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ROOT INODE UNALLOCATED ALLOCATE? [yn] ^C * FILE SYSTEM MARKED DIRTY * bang# -- 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
Re: Newfs börked: Kills make release in strange ways.
* De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Newfs börked: Kills make release in strange ways. ] Newfs is börked right now (see below), and that kills make release in really strange ways. It looks like it was this typo, which didn't show up as being a problem as I never tried to boot (fsck) off one of these volumes: %%% Index: mkfs.c === RCS file: /home/ncvs/src/sbin/newfs/mkfs.c,v retrieving revision 1.68 diff -d -u -r1.68 mkfs.c --- mkfs.c 27 Jan 2003 07:24:32 - 1.68 +++ mkfs.c 29 Jan 2003 22:59:32 - @@ -842,7 +842,7 @@ else ((struct ufs2_dinode *)iobuf)[ino_to_fsbo(sblock, ino)] = ip-dp2; - wtfs(d, sblock.fs_size, (char *)iobuf); + wtfs(d, sblock.fs_bsize, (char *)iobuf); } /* %%% Also, the ioctl stuff was giving me trouble, I thought this was due to my local configuration being a mix of rather old and rather new bits (my newfs in /sbin was from October before my libufs version), but I was just not doing writable disks Right At All in libufs, really. Now there's a command to do it, used by bwrite, etc. I'll be committing that in a sec. Then I'll sit on newfs again for a few days. BTW, I ended up with the few of these: Zone md99 was not empty. Lost 1 pages of memory. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problem with X
On Wed, 2003-01-29 at 11:29, Charlie ROOT wrote: On Tue, 28 Jan 2003, joseph wrote: Try a make build world and see if that version of libc_r works. It should fix the problem. joseph I tried that... now the error is: Symbol from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved! I'm sorry this error was still around. Apparently I had looked at a CVS version of X when trying to figure out why it was happening, and CVS X has it fixed. Until I commit a fix, you can add -fno-merge-constants to your CFLAGS. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: openpam error from sshd
On Mon, Jan 27, 2003 at 06:17:37PM +0100, Dag-Erling Smorgrav wrote: Kris Kennaway [EMAIL PROTECTED] writes: I've just updated bento to 5.0, and sshd is now giving the following error every few seconds: auth.err bento sshd[55737]: in _openpam_check_error_code(): pam_sm_setcred(): unexpected return value 24 Peter says he's seen this elsewhere on the cluster. What's going on? *grumble* it's a bug in one of our PAM modules (krb5, I think), which I never got around to fixing it because it isn't really important. Error 24 is PAM_NO_MODULE_DATA, which isn't an allowed return value for pam_setcred() according to the XSSO, but nobody really cares because anything else than PAM_SUCCESS is an error, so the bug doesn't have any adverse effect other than making OpenPAM bitch so I remember to fix it :) I believe I fixed this in revision 1.13 of pam_krb5.c. I'd be much obliged if you double-checked. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problem with X
On Wed, 2003-01-29 at 15:17, Eric Anholt wrote: On Wed, 2003-01-29 at 11:29, Charlie ROOT wrote: On Tue, 28 Jan 2003, joseph wrote: Try a make build world and see if that version of libc_r works. It should fix the problem. joseph I tried that... now the error is: Symbol from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved! I'm sorry this error was still around. Apparently I had looked at a CVS version of X when trying to figure out why it was happening, and CVS X has it fixed. Until I commit a fix, you can add -fno-merge-constants to your CFLAGS. I'm more confused now. Could someone who is seeing this problem, after building XFree86-4-Server, do this: grep MODULE XFree86-4-Server/work/xc/lib/font/bitmap/module/Makefile | grep FLAG and tell me the output? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Wed Jan 29 15:12:44 PST 2003 -- Kernel build for GENERIC completed on Wed Jan 29 15:47:50 PST 2003 -- Kernel build for LINT started on Wed Jan 29 15:47:51 PST 2003 -- === vinum Makefile, line 4440: warning: duplicate script for target geom_bsd.o ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and is not compiled with LINT /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is not compiled with LINT /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open': /h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once /h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.) cc1: warnings being treated as errors /h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close': /h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read': /h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write': /h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl': /h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap': /h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from incompatible pointer type *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic#2 copying many files from UFS to UFS2 partition
At 9:49 PM -0500 1/28/03, Garance A Drosihn wrote: Hmm, well, I finally got my first actual system panic which wasn't obviously caused by my own screwing around. On the console I have: free inode /usr/cvs/net/64 had 0 blocks panic: Negative bio_offset (-19038208) on bio 0xce51be28 cpuid = 0; lapic.id = 0100 Debugger(panic) Stopped atDebugger+0x55: xchgl %ebx,in_Debugger.0 It looks like the sequence which generated that panic can be repeated to generate other panics. My sequence was: use sysinstall to remove and then recreate the new UFS2 partition, 3100 meg in size, mounted on /usr/cvs/net pushd /usr/cvs/net-old tar cf - ./ | (popd; cd /usr/cvs/net; tar xpf -) and again I got a panic, although not quite the same panic. It also seemed like it happened much sooner in the process. This time it says: free inode /usr/cvs/net/64 had 0 blocks mode = 017, inum = 78, fs = /usr/cvs/net panic: ffs_valloc: dup alloc cpuid = 0; lapic.id = 0100 Debugger(panic) Stopped atDebugger+0x55: xchgl %ebx,in_Debugger.0 The first panic was while doing a 'mkdir'. There's no mkdir in the traceback this time. It looks like the system was in the middle of an open() call (syscall 5). It's interesting that all three panics mentioned /usr/cvs/net/64, even though the source directory has no file-or-directory named '64' in it. I expect that some system dumps would be more useful than me typing in backtraces, so I set up dumpdev and dumpdir in rc.conf, rebooted, and tried again. The system panic'ed again, looking about the same as the second panic. I typed 'panic' in the debugger, it says panic: from debugger cpuid = 1; lapic.id = boot() called on cpu#1 Uptime: 6m8s Dumping 511 MB ata0: resetting devices I let it sit there, well, for about 20 minutes, before deciding that nothing is happening and I powered the machine off and on to get it back. There was no dump in the dump-dir. I've tried this a number of times now, and it seems I never get a dump. My dumpdir is on a UFS1 partition, I'm using it instead of /var because my /var is 256meg and this partition is over 1 gig. So, what should I do at this point to help pin this down? -- 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: dump -L and privilege
Date: Fri, 17 Jan 2003 09:08:09 +0900 From: Jun Kuriyama [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Current [EMAIL PROTECTED] Subject: dump -L and privilege X-ASK-Info: Confirmed by User I'm trying to use dump -L option to dump with snapshot on -current/RELENG_5_0 family. I found dump -L needs writable permission to the device (that's reasonable because it *writes* snapshot file). But when I try to dump by operator group, it's impossible to dump with -L option (target device has root:operator and crw-r-). This behavior is understandable. But in actual backup operations, what should we do? I'd like to hear what you thought in design. (1) Do dump as root with -L option. (2) Do chmod g+w for device. (3) Other ideas? -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project Sorry for the slow reply. I am just back from several weeks of travel and am trying to get caught up on my email. You have raised an important point here. By default (that is when vfs.usermount == 0) only root is allowed to do mounts. Since dump -L needs to do a snapshot, that can only be done by a root process. I see two possible solutions to the problem. The first would be to change the default for vfs.usermount == 1 and then have dump -L create the snapshot in a directory owned by operator (or by whatever user runs the dumps). Then the snapshot could be created, used, and deleted by that user. The other alternative would be to create a setuid-to-root program that would take a snapshot and chown it to the user that does dumps. This setuid program could then be invoked by dump -L to create a snapshot for it. I favor the first approach, but there may be good security issues of which I am unaware that make that a bad choice. Perhaps we could get someone like Robert Watson to comment on these choices. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI recoving issues
has anyone had ACPI recovering issues? anytime i go into a S3 suspend and try to recover, if im in x the screen tries to recover and sortof melts before it goes white with color vertical lines, and if im in the console i get no video, and it seems to go into a halt. is this a video configuration problem or an acpi configuration problem? thanks seele To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI recoving issues
Seele Varcuzzo wrote: has anyone had ACPI recovering issues? anytime i go into a S3 suspend and try to recover, if im in x the screen tries to recover and sortof melts before it goes white with color vertical lines, and if im in the console i get no video, and it seems to go into a halt. is this a video configuration problem or an acpi configuration problem? When suspend happens, the suspending context needs to signal the X server to restore the console state, before suspending, and then put it back, as a result of a resume. This is necessary because X writes registers, and doesn't maintain shadow copies in user space, and so can't put the card back into a known state. In many suspend models, the video card is actually powered off and resets to the default state when it resumes, which is not the state the X server expects it to be in. As a workaround, you might be able to set one of the many acpi sysctl options to prevent the video card from being powered down, when everything else is (depends on your suspend -- if it's a suspend to disk, this won't be an option for you). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
At 9:18 PM +0200 1/29/03, Sheldon Hearn wrote: Can anyone think of a good way to implement an installworld / installkernel seat-belt for source upgrades from stable to current? What I'm looking for is a way for installworld and installkernel in the current source to look for some signature in the target filesystem that suggests that a stable world is about to be upgraded to current. How about requiring the user to touch some file in / or /boot which indicates the branch-tag that's acceptable for installworlds? Then you just need to propagate the tag from the 'cvs co' stage to some file under /usr/src (such as /usr/src/CVS/Tag ). So, maybe compare /usr/src/CVS/Tag to /boot/BRANCH_TAG, where the second file has to be typed in by the user, by hand. Eh, maybe /boot isn't the right place for it. Well, maybe /.branch_tag [1] Guess who just trashed a stable installation for the 3rd time in 3 years today? Well, I almost would have done the same thing in my latest 4.7 install, but when I cd'ed into sys/i386/conf I thought it was odd that there was a GENERIC.hints file sitting there... If it wasn't for my desire to compile an SMP kernel instead of GENERIC, I might not have noticed until it was too late!! -- 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: Seat-belt for source upgrades from stable to current
At 8:05 PM -0800 1/29/03, Steve Kargl wrote: On Wed, Jan 29, 2003, Garance A Drosihn wrote: How about requiring the user to touch some file in / or /boot which indicates the branch-tag that's acceptable for installworlds? Then you just need to propagate the tag from the 'cvs co' stage to some file under /usr/src (such as /usr/src/CVS/Tag ). So, maybe compare /usr/src/CVS/Tag to /boot/BRANCH_TAG, where the second file has to be typed in by the user, by hand. Eh, maybe /boot isn't the right place for it. Well, maybe /.branch_tag I don't have a /usr/src/CVS directory. I suspect most people don't pulldown the cvs repository. Well, then, just have the branch-tag show up in some file that is somewhere else in the /usr/src tree. It ain't hard to do. This new check would not go into effect until you updated your /usr/src tree, and the same update could bring in a /usr/src/BRANCH file. uname(1) works on both 4.7 and 5.0. This seems like a trivial problem to fix. If you use something fixed like uname, then what does one do once they *DO* want to switch from one branch to another one? -- 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: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 08:13:22PM -0500, Mike Barcroft wrote: Benno Rice [EMAIL PROTECTED] writes: On Wed, 2003-01-29 at 11:18, Juli Mallett wrote: * De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] In short, platform provides machinery for a single port of FreeBSD which represents exactly one MACHINE_ARCH to support a numbe of different hardware platforms - MACHINE - under a unified system, without interfering with how anything works, and without doing it in a convoluted/imho-backwards way. There is not a way to mix MACHINE and MACHINE_ARCH within a single port, as it is now. You have to duplicate things like pc98 does. I'd also like to point out that PowerPC will benefit greatly from this. PowerPC platforms vary wildly in how they do various things (incl. endianness in some cases) and so this provides a much cleaner mechanism to select a set of platform quirks than trying to do what i386/pc98 do. Perhaps if we could see PC98 converted to this design the advantages would become obvious. I think this is an EXCELLENT idea! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problem with X
On Wed, 2003-01-29 at 19:18, Kirk R. Wythers wrote: Eric, I'll grep that for you as soon as I get to my office tomorrow. Should I try the add -fno-merge-constants to CFLAGS? Sure. What you add to CFLAGS in the environment won't show up in that grep, so I'll still be able to get the information from it. (The question is whether imake is detecting whether that flag is available in gcc or not). -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
¸ßÆ·ÖÊÍøÂçÊÓƵ»áÒé¡¢ÍøÂçÔ¶³Ì½Ì½Ìѧϵͳ
¸ßÆ·ÖÊÍøÂçÊÓƵ»áÒé¡¢ÍøÂçÔ¶³Ì½Ì½Ìѧϵͳ ±¾¹«Ë¾×îвúÆ·:ÍøÂçÊÓƵ»áÒéÊÓƵ·þÎñÆ÷---¹ã·ºÓÃÓÚ¸ßÇåÎú¶È¾ÖÓò»ò¹ãÓòÊÓƵ»áÒé¡¢ÍøÂç¼à¿Ø¡¢Ó׶ùÔ°¾´ÀÏÔººÍÒ½Ôº²¡·¿¼ÒÈËÒìµØÔ¶³Ì¼à»¤¡¢×¨¼ÒÔ¶³ÌÒ½ÁÆ»áÕïºÍ½Ìѧ¡¢ÍøÂçÔ¶³Ì½ÌÊÒÒÔ¼°ÎÞ»°·Ñ¿ÉÊÓ»¯¿Í»§·þÎñϵͳ,ÍøÉÏ·ç¾°Çø,¾ÆµêʵʱÊÓƵչʾ¡¢µçÊÓ½ÚÄ¿ÍøÉÏʵʱת²¥¡¢´óÐÍÕ¹»áÏÖ³¡ÍøÂçÖ±²¥µÈ,ÍøÉÏ´«ÊäЧ¹û¾ÓÄ¿Ç°¹úÄÚÍâÁìÏÈˮƽ£¬¼Û¸ñ½öÓнø¿Úͬµµ´Î²úÆ·1/10¡£ »¶ÓÍøÉϹۿ´ÑÝʾЧ¹û:www.webht.com ÑÝʾ»·¾³¼°ÊÔÓ÷½·¨£º ±¾¹«Ë¾ÊÓƵ»áÒé·þÎñÆ÷ÿÌì24СʱÁ¬Ðø¿ª»ú£¬ÈôÓÐÐËȤÇëÔÚ±¾¹«Ë¾ÍøÕ¾ÏÂÔØ×îаæÂÌÉ«¿Í»§¶ËÈí¼þ,Ö±½Óµã»÷Ö´ÐкóÊäÈë·þÎñÆ÷ºÅ332£¬Óû§ÃûºÍÃÜÂë¾ùΪ¡°1234¡±£¬°´È·¶¨ºóÉÔµÈƬ¿Ì¼´¿ÉÁ¬Í¨ÊÓƵ»áÒéϵͳ¿´µ½ÑÝʾÏÖ³¡Í¼Ïó£¬ÔÚ´Ë´¦ÎÒÃÇ¿ÉÓû°Í²½øÐÐÊÓƵ»áÒéÓïÒô½»Ì¸£¬Ç×ÉíÌåÑé×îÐÂIT³É¹û£¬»¶ÓÓëÈκιúÍâ²úÆ·×÷Ò»¸ö±È½Ï£¬Äú»á·¢ÏÖÖйúµÄÔÂÁÁ±ÈÍâ¹úµÄÔÂÁÁ»¹ÒªÔ²¡£ Ó¦ÓÃÖ®Ò» -- ÍøÂçÊÓƵԶ³Ì½ÌѧºÍר¼ÒÔ¶³Ì»áÕïϵͳ£º ÃûУÃûʦ½²¿Î¡¢¸ß¼¶½ÌÊÚ½²Ñ§¡¢Ò½Ñ§ÊÖÊõȨÍþµÄÊÖÊõ¶¼¿ÉʹÓñ¾ÏµÍ³Í¨¹ýÍøÂçÏòÌض¨Óû§¿ª·Å£¬»ñÓÐÃÜÂëµÄ½ÌÊÒ»ò¸öÈ˿ɵǽϵͳ²Î¼Óѧϰ¡£Ò»Ì×·þÎñÆ÷¿É¹©10---100ÒÔÉÏÓû§Í¬Ê±µÇ½£¬Ö»Òª·þÎñÆ÷¶Ë´ø¿í×ã¹»£¨500K X Óû§ÊýÁ¿£©£¬Óû§¶Ë300-500K´ø¿íÎÞ·ÓÉÑÓ³Ù£¬¿É×öµ½ÊÓÒôƵ»ù±¾Í¬²½£¬Ë«¹¤¶Ô½²¡£ ר¼ÒÔ¶³Ì»áÕ¡ª¡ªÀûÓÃÊÓѶҵÎñʵÏÖÖÐÐÄÒ½ÔºÓë»ù²ãÒ½Ôº¾ÍÒÉÄѲ¡Ö¢½øÐлáÕï¡¢Ö¸µ¼ÖÎÁÆÓ뻤Àí¡¢¶Ô»ù²ãÒ½ÎñÈËÔ±µÄҽѧÅàѵµÈµÈ¡£¸ßÖÊÁ¿µÄÊÓѶҵÎñʹҽÉú¡¢»¤Ê¿ÔÚ²»Í¬µØ·½Í¬Ê±Ðͬ¹¤×÷³ÉΪ¿ÉÄÜ¡£Ô¶³ÌÒ½ÁƶÔÓÚһЩÖÐСҽԺÓÐ×ÅÖØÒªµÄÒâÒ壬¿ÉÒԵõ½´óÒ½ÔºµÄҽѧר¼ÒµÄ×ÉѯºÍ»áÕï¡£ Ó¦ÓÃÖ®Ò» -- ÎÞ»°·Ñ¿ÉÊÓ»¯¿Í»§·þÎñϵͳ£º ×ܹ«Ë¾Ö»Ð谲װһ̨ÊÓƵ·þÎñÆ÷¡¢¼¸Ö»ÉãÏñ»ú£¬Ô¶³ÌµÄ¸÷µØÁ¬Ëøµê·Ö¹«Ë¾Ö»ÐèʹÓÃÃâ·ÑµÄ¿Í»§¶ËÈí¼þͨ¹ýµçÄÔÉÏÍø¾Í¿Éͨ¹ýÍøÂçÓë×ܲ¿¶Ô»°£¬Í¬Ê±¿´µ½×ܲ¿¸ßÇåÎúͼÏ󡣿ÉÓÃÓÚ×ܲ¿¶ÔÏÂÊôµ¥Î»ÕÙ¿ªÊÓƵ»áÒé¡¢ÏÂÊôºô½Ð×ܲ¿½øÐÐÒµÎñÁªÏµ»ò×ܲ¿Ð²úÆ·¶Ô¹úÄÚÍâÔ¶¶Ë¿Í»§½øÐÐÑÝʾ¡¢ÅàѵºÍµç×Ó°×°åÎÄ×Ö¹µÍ¨£¬ÕâÒ»Ìصã¾ÍʹµÃ±¾ÏµÍ³¿ÉÈ¡´ú´óÐÍÆóÒµ¼¯ÍÅÄ¿Ç°°º¹óµÄ800µç»°¿Í»§·þÎñϵͳ¶øͨ¹ýÁ®¼ÛµÄÍøÂ緽ʽ¿ªÕ¹Óû§·þÎñ,ʹÓû§Ö±½Ó¿´µ½²úƷʵÎï´ïµ½×îºÃµÄÐû´«·þÎñ×÷Ó㬲¢ÇÒË«·½¶¼²»»á²úÉúÈκλ°·Ñ¡£ ÆäËü²úÆ·£º 1¡¢ÊÓƵ˫½ÊÏßÊÕ·¢Æ÷--Á®¼ÛµÄ¸ßÐÔÄÜÔ¶¾àÀë¼à¿Ø´«ÊäÉ豸,¾àÀë¿É´ï1-3ǧÃס£ 2¡¢LEDµç×ÓÏÔʾÆÁ£¬¼à¿Ø±¨¾¯×¨ÓÃÏÔʾÌõÆÁ£»3¡¢È«ÖÐÎľØÕóÍòÄÜÇл»¼à¿Ø±¨¾¯Ö÷»ú 4¡¢ÍøÂçÊÓƵ»áÒéϵͳ 5¡¢ÏúÊÛ±£°²¼à¿Ø¡¢Â¥Óî¶Ô½²É豸£¬³Ð½Ó±£°²¼à¿ØºÍУ԰ÍøÂ繤³Ì¡£7¡¢IC¿¨³ö×â³µ¼Æ¼ÛÆ÷ºÍ¹«ÎñÆû³µ¹ÜÀí»ú£»8¡¢²ÊÉ«¡¢ºÚ°×ÉãÏó»ú£¬Ë®ÏÂÉãÏó»ú,ϵÁкìÍâµÆ¡¢Æû³µÒ¹ÊÓÒÇ¡¢ÏµÁÐÎÞÏßÓ°ÒôÊÕ·¢Æ÷¡¢¹â¶Ë»ú¡¢ÊÓƵ¹²À´«ÊäµÈÉ豸. ±¾ÏµÍ³Ìص㣺 ÔÚͬһ¸öÍøÂç´ø¿í»·¾³ÏÂͼÏóºÍÓïÒôÖÊÁ¿¿É³¬¹ýÄ¿Ç°ËùÓеĹúÄÚÍâ²úÆ·£¬±¾ÏµÍ³ÊµÏÖ¸ßËÙ¸ßЧÂʵÄÈí¼þѹËõ¼¼Êõ£¬Ê¹ÊµÊ±Ñ¹Ëõ´«ÊäµÄͼÏóΪ756X576ÏóËØ£¬¶ø·ÇÏóËصķŴ󣬹ÊͼÏóÇåÎú¶È¸ß£¬Ê¹ÓÃÊó±êµã»÷»Ãæ¿É¸´Ô·Å´óΪÂúÆÁÏÔʾ£¬Ê¹ÓôóÆÁÄ»²Êµç»òͶӰÏÔʾÂúÆÁͼÏó»áÓÐÒâÏë²»µ½µÄ¸ßÇåÎú¶ÈЧ¹û¡£ ×îÐÂÏûÏ¢£º×¨Îª±¾ÏµÍ³ÅäÓõÄMCUÒµÒÑ¿ª·¢ÊÔÑé³É¹¦£¬ÒÑͨ¹ý16¡¢32ºÍ64ºÍ128 Óû§µÄ´óϵͳ²âÊÔ£¬×ª·¢µÄͼÏóÇåÎúÎȶ¨£¬¶ą̀MCU¼¶Á¬ºó¿É¹¹³É¸ü´óϵͳ£¬Ïêϸ×éÍø·½°´Ç뺯µçÁªÏµ¡£ ÐìÖÝ»ªÍ³µçÄÔÉ豸ÓÐÏÞ¹«Ë¾ ÐìÖÝÊÐÇàÄê·288ºÅËÄÂ¥ TEL£º0516-3738506 2682031 FAX£º0516-3752314 ÁªÏµÈË£ºÍõÈ𺣠ÍøÖ·£ºwww.webht.com ÓÊÏ䣺[EMAIL PROTECTED] »¶Ó¹âÁÙÍøÉÏÓªÏúÈí¼þ³¬ÊÐ http://www.sesoft.findhere.org ±¾ÓʼþÓ󬼶¹ã¸æÈí¼þ·¢ËÍ http://www.sesoft.findhere.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
¸ßÆ·ÖÊÍøÂçÊÓƵ»áÒé¡¢ÍøÂçÔ¶³Ì½Ì½Ìѧϵͳ
¸ßÆ·ÖÊÍøÂçÊÓƵ»áÒé¡¢ÍøÂçÔ¶³Ì½Ì½Ìѧϵͳ ±¾¹«Ë¾×îвúÆ·:ÍøÂçÊÓƵ»áÒéÊÓƵ·þÎñÆ÷---¹ã·ºÓÃÓÚ¸ßÇåÎú¶È¾ÖÓò»ò¹ãÓòÊÓƵ»áÒé¡¢ÍøÂç¼à¿Ø¡¢Ó׶ùÔ°¾´ÀÏÔººÍÒ½Ôº²¡·¿¼ÒÈËÒìµØÔ¶³Ì¼à»¤¡¢×¨¼ÒÔ¶³ÌÒ½ÁÆ»áÕïºÍ½Ìѧ¡¢ÍøÂçÔ¶³Ì½ÌÊÒÒÔ¼°ÎÞ»°·Ñ¿ÉÊÓ»¯¿Í»§·þÎñϵͳ,ÍøÉÏ·ç¾°Çø,¾ÆµêʵʱÊÓƵչʾ¡¢µçÊÓ½ÚÄ¿ÍøÉÏʵʱת²¥¡¢´óÐÍÕ¹»áÏÖ³¡ÍøÂçÖ±²¥µÈ,ÍøÉÏ´«ÊäЧ¹û¾ÓÄ¿Ç°¹úÄÚÍâÁìÏÈˮƽ£¬¼Û¸ñ½öÓнø¿Úͬµµ´Î²úÆ·1/10¡£ »¶ÓÍøÉϹۿ´ÑÝʾЧ¹û:www.webht.com ÑÝʾ»·¾³¼°ÊÔÓ÷½·¨£º ±¾¹«Ë¾ÊÓƵ»áÒé·þÎñÆ÷ÿÌì24СʱÁ¬Ðø¿ª»ú£¬ÈôÓÐÐËȤÇëÔÚ±¾¹«Ë¾ÍøÕ¾ÏÂÔØ×îаæÂÌÉ«¿Í»§¶ËÈí¼þ,Ö±½Óµã»÷Ö´ÐкóÊäÈë·þÎñÆ÷ºÅ332£¬Óû§ÃûºÍÃÜÂë¾ùΪ¡°1234¡±£¬°´È·¶¨ºóÉÔµÈƬ¿Ì¼´¿ÉÁ¬Í¨ÊÓƵ»áÒéϵͳ¿´µ½ÑÝʾÏÖ³¡Í¼Ïó£¬ÔÚ´Ë´¦ÎÒÃÇ¿ÉÓû°Í²½øÐÐÊÓƵ»áÒéÓïÒô½»Ì¸£¬Ç×ÉíÌåÑé×îÐÂIT³É¹û£¬»¶ÓÓëÈκιúÍâ²úÆ·×÷Ò»¸ö±È½Ï£¬Äú»á·¢ÏÖÖйúµÄÔÂÁÁ±ÈÍâ¹úµÄÔÂÁÁ»¹ÒªÔ²¡£ Ó¦ÓÃÖ®Ò» -- ÍøÂçÊÓƵԶ³Ì½ÌѧºÍר¼ÒÔ¶³Ì»áÕïϵͳ£º ÃûУÃûʦ½²¿Î¡¢¸ß¼¶½ÌÊÚ½²Ñ§¡¢Ò½Ñ§ÊÖÊõȨÍþµÄÊÖÊõ¶¼¿ÉʹÓñ¾ÏµÍ³Í¨¹ýÍøÂçÏòÌض¨Óû§¿ª·Å£¬»ñÓÐÃÜÂëµÄ½ÌÊÒ»ò¸öÈ˿ɵǽϵͳ²Î¼Óѧϰ¡£Ò»Ì×·þÎñÆ÷¿É¹©10---100ÒÔÉÏÓû§Í¬Ê±µÇ½£¬Ö»Òª·þÎñÆ÷¶Ë´ø¿í×ã¹»£¨500K X Óû§ÊýÁ¿£©£¬Óû§¶Ë300-500K´ø¿íÎÞ·ÓÉÑÓ³Ù£¬¿É×öµ½ÊÓÒôƵ»ù±¾Í¬²½£¬Ë«¹¤¶Ô½²¡£ ר¼ÒÔ¶³Ì»áÕ¡ª¡ªÀûÓÃÊÓѶҵÎñʵÏÖÖÐÐÄÒ½ÔºÓë»ù²ãÒ½Ôº¾ÍÒÉÄѲ¡Ö¢½øÐлáÕï¡¢Ö¸µ¼ÖÎÁÆÓ뻤Àí¡¢¶Ô»ù²ãÒ½ÎñÈËÔ±µÄҽѧÅàѵµÈµÈ¡£¸ßÖÊÁ¿µÄÊÓѶҵÎñʹҽÉú¡¢»¤Ê¿ÔÚ²»Í¬µØ·½Í¬Ê±Ðͬ¹¤×÷³ÉΪ¿ÉÄÜ¡£Ô¶³ÌÒ½ÁƶÔÓÚһЩÖÐСҽԺÓÐ×ÅÖØÒªµÄÒâÒ壬¿ÉÒԵõ½´óÒ½ÔºµÄҽѧר¼ÒµÄ×ÉѯºÍ»áÕï¡£ Ó¦ÓÃÖ®Ò» -- ÎÞ»°·Ñ¿ÉÊÓ»¯¿Í»§·þÎñϵͳ£º ×ܹ«Ë¾Ö»Ð谲װһ̨ÊÓƵ·þÎñÆ÷¡¢¼¸Ö»ÉãÏñ»ú£¬Ô¶³ÌµÄ¸÷µØÁ¬Ëøµê·Ö¹«Ë¾Ö»ÐèʹÓÃÃâ·ÑµÄ¿Í»§¶ËÈí¼þͨ¹ýµçÄÔÉÏÍø¾Í¿Éͨ¹ýÍøÂçÓë×ܲ¿¶Ô»°£¬Í¬Ê±¿´µ½×ܲ¿¸ßÇåÎúͼÏ󡣿ÉÓÃÓÚ×ܲ¿¶ÔÏÂÊôµ¥Î»ÕÙ¿ªÊÓƵ»áÒé¡¢ÏÂÊôºô½Ð×ܲ¿½øÐÐÒµÎñÁªÏµ»ò×ܲ¿Ð²úÆ·¶Ô¹úÄÚÍâÔ¶¶Ë¿Í»§½øÐÐÑÝʾ¡¢ÅàѵºÍµç×Ó°×°åÎÄ×Ö¹µÍ¨£¬ÕâÒ»Ìصã¾ÍʹµÃ±¾ÏµÍ³¿ÉÈ¡´ú´óÐÍÆóÒµ¼¯ÍÅÄ¿Ç°°º¹óµÄ800µç»°¿Í»§·þÎñϵͳ¶øͨ¹ýÁ®¼ÛµÄÍøÂ緽ʽ¿ªÕ¹Óû§·þÎñ,ʹÓû§Ö±½Ó¿´µ½²úƷʵÎï´ïµ½×îºÃµÄÐû´«·þÎñ×÷Ó㬲¢ÇÒË«·½¶¼²»»á²úÉúÈκλ°·Ñ¡£ ÆäËü²úÆ·£º 1¡¢ÊÓƵ˫½ÊÏßÊÕ·¢Æ÷--Á®¼ÛµÄ¸ßÐÔÄÜÔ¶¾àÀë¼à¿Ø´«ÊäÉ豸,¾àÀë¿É´ï1-3ǧÃס£ 2¡¢LEDµç×ÓÏÔʾÆÁ£¬¼à¿Ø±¨¾¯×¨ÓÃÏÔʾÌõÆÁ£»3¡¢È«ÖÐÎľØÕóÍòÄÜÇл»¼à¿Ø±¨¾¯Ö÷»ú 4¡¢ÍøÂçÊÓƵ»áÒéϵͳ 5¡¢ÏúÊÛ±£°²¼à¿Ø¡¢Â¥Óî¶Ô½²É豸£¬³Ð½Ó±£°²¼à¿ØºÍУ԰ÍøÂ繤³Ì¡£7¡¢IC¿¨³ö×â³µ¼Æ¼ÛÆ÷ºÍ¹«ÎñÆû³µ¹ÜÀí»ú£»8¡¢²ÊÉ«¡¢ºÚ°×ÉãÏó»ú£¬Ë®ÏÂÉãÏó»ú,ϵÁкìÍâµÆ¡¢Æû³µÒ¹ÊÓÒÇ¡¢ÏµÁÐÎÞÏßÓ°ÒôÊÕ·¢Æ÷¡¢¹â¶Ë»ú¡¢ÊÓƵ¹²À´«ÊäµÈÉ豸. ±¾ÏµÍ³Ìص㣺 ÔÚͬһ¸öÍøÂç´ø¿í»·¾³ÏÂͼÏóºÍÓïÒôÖÊÁ¿¿É³¬¹ýÄ¿Ç°ËùÓеĹúÄÚÍâ²úÆ·£¬±¾ÏµÍ³ÊµÏÖ¸ßËÙ¸ßЧÂʵÄÈí¼þѹËõ¼¼Êõ£¬Ê¹ÊµÊ±Ñ¹Ëõ´«ÊäµÄͼÏóΪ756X576ÏóËØ£¬¶ø·ÇÏóËصķŴ󣬹ÊͼÏóÇåÎú¶È¸ß£¬Ê¹ÓÃÊó±êµã»÷»Ãæ¿É¸´Ô·Å´óΪÂúÆÁÏÔʾ£¬Ê¹ÓôóÆÁÄ»²Êµç»òͶӰÏÔʾÂúÆÁͼÏó»áÓÐÒâÏë²»µ½µÄ¸ßÇåÎú¶ÈЧ¹û¡£ ×îÐÂÏûÏ¢£º×¨Îª±¾ÏµÍ³ÅäÓõÄMCUÒµÒÑ¿ª·¢ÊÔÑé³É¹¦£¬ÒÑͨ¹ý16¡¢32ºÍ64ºÍ128 Óû§µÄ´óϵͳ²âÊÔ£¬×ª·¢µÄͼÏóÇåÎúÎȶ¨£¬¶ą̀MCU¼¶Á¬ºó¿É¹¹³É¸ü´óϵͳ£¬Ïêϸ×éÍø·½°´Ç뺯µçÁªÏµ¡£ ÐìÖÝ»ªÍ³µçÄÔÉ豸ÓÐÏÞ¹«Ë¾ ÐìÖÝÊÐÇàÄê·288ºÅËÄÂ¥ TEL£º0516-3738506 2682031 FAX£º0516-3752314 ÁªÏµÈË£ºÍõÈ𺣠ÍøÖ·£ºwww.webht.com ÓÊÏ䣺[EMAIL PROTECTED] »¶Ó¹âÁÙÍøÉÏÓªÏúÈí¼þ³¬ÊÐ http://www.sesoft.findhere.org ±¾ÓʼþÓ󬼶¹ã¸æÈí¼þ·¢ËÍ http://www.sesoft.findhere.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 11:46:47PM -0800, Marcel Moolenaar wrote:
I would not introduce a platform/foo.h, but rather
machine/${variant}/foo.h. The reason for this is that the
/usr/include/platform directory is only needed on powerpc and mips,
which seems to indicate that it should be under machine. Also,
the use of machine/${variant} allows us to install the headers for
all variants, which may improve cross-building.
This is a very nice way of adding the complexity when it is needed, but
not getting in the way of those cases where it isn't needed.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Wed, Jan 29, 2003 at 11:21:39PM -0500, Garance A Drosihn wrote:
At 8:05 PM -0800 1/29/03, Steve Kargl wrote:
uname(1) works on both 4.7 and 5.0. This seems
like a trivial problem to fix.
If you use something fixed like uname, then what does one do once
they *DO* want to switch from one branch to another one?
Compare output from /usr/bin/uname -r to ${OBJDIR}/usr.bin/uname/uname -r.
If the strings are the same, then install. If the strings are different
or an error occurs either abort the install or wait for keyboard input
to continue the installation.
You don't need a special file to indicate what version of
FreeBSD you have. uname -r tells you.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
¸ßÆ·ÖÊÍøÂçÊÓƵ»áÒé¡¢ÍøÂçÔ¶³Ì½Ì½Ìѧϵͳ
¸ßÆ·ÖÊÍøÂçÊÓƵ»áÒé¡¢ÍøÂçÔ¶³Ì½Ì½Ìѧϵͳ ±¾¹«Ë¾×îвúÆ·:ÍøÂçÊÓƵ»áÒéÊÓƵ·þÎñÆ÷---¹ã·ºÓÃÓÚ¸ßÇåÎú¶È¾ÖÓò»ò¹ãÓòÊÓƵ»áÒé¡¢ÍøÂç¼à¿Ø¡¢Ó׶ùÔ°¾´ÀÏÔººÍÒ½Ôº²¡·¿¼ÒÈËÒìµØÔ¶³Ì¼à»¤¡¢×¨¼ÒÔ¶³ÌÒ½ÁÆ»áÕïºÍ½Ìѧ¡¢ÍøÂçÔ¶³Ì½ÌÊÒÒÔ¼°ÎÞ»°·Ñ¿ÉÊÓ»¯¿Í»§·þÎñϵͳ,ÍøÉÏ·ç¾°Çø,¾ÆµêʵʱÊÓƵչʾ¡¢µçÊÓ½ÚÄ¿ÍøÉÏʵʱת²¥¡¢´óÐÍÕ¹»áÏÖ³¡ÍøÂçÖ±²¥µÈ,ÍøÉÏ´«ÊäЧ¹û¾ÓÄ¿Ç°¹úÄÚÍâÁìÏÈˮƽ£¬¼Û¸ñ½öÓнø¿Úͬµµ´Î²úÆ·1/10¡£ »¶ÓÍøÉϹۿ´ÑÝʾЧ¹û:www.webht.com ÑÝʾ»·¾³¼°ÊÔÓ÷½·¨£º ±¾¹«Ë¾ÊÓƵ»áÒé·þÎñÆ÷ÿÌì24СʱÁ¬Ðø¿ª»ú£¬ÈôÓÐÐËȤÇëÔÚ±¾¹«Ë¾ÍøÕ¾ÏÂÔØ×îаæÂÌÉ«¿Í»§¶ËÈí¼þ,Ö±½Óµã»÷Ö´ÐкóÊäÈë·þÎñÆ÷ºÅ332£¬Óû§ÃûºÍÃÜÂë¾ùΪ¡°1234¡±£¬°´È·¶¨ºóÉÔµÈƬ¿Ì¼´¿ÉÁ¬Í¨ÊÓƵ»áÒéϵͳ¿´µ½ÑÝʾÏÖ³¡Í¼Ïó£¬ÔÚ´Ë´¦ÎÒÃÇ¿ÉÓû°Í²½øÐÐÊÓƵ»áÒéÓïÒô½»Ì¸£¬Ç×ÉíÌåÑé×îÐÂIT³É¹û£¬»¶ÓÓëÈκιúÍâ²úÆ·×÷Ò»¸ö±È½Ï£¬Äú»á·¢ÏÖÖйúµÄÔÂÁÁ±ÈÍâ¹úµÄÔÂÁÁ»¹ÒªÔ²¡£ Ó¦ÓÃÖ®Ò» -- ÍøÂçÊÓƵԶ³Ì½ÌѧºÍר¼ÒÔ¶³Ì»áÕïϵͳ£º ÃûУÃûʦ½²¿Î¡¢¸ß¼¶½ÌÊÚ½²Ñ§¡¢Ò½Ñ§ÊÖÊõȨÍþµÄÊÖÊõ¶¼¿ÉʹÓñ¾ÏµÍ³Í¨¹ýÍøÂçÏòÌض¨Óû§¿ª·Å£¬»ñÓÐÃÜÂëµÄ½ÌÊÒ»ò¸öÈ˿ɵǽϵͳ²Î¼Óѧϰ¡£Ò»Ì×·þÎñÆ÷¿É¹©10---100ÒÔÉÏÓû§Í¬Ê±µÇ½£¬Ö»Òª·þÎñÆ÷¶Ë´ø¿í×ã¹»£¨500K X Óû§ÊýÁ¿£©£¬Óû§¶Ë300-500K´ø¿íÎÞ·ÓÉÑÓ³Ù£¬¿É×öµ½ÊÓÒôƵ»ù±¾Í¬²½£¬Ë«¹¤¶Ô½²¡£ ר¼ÒÔ¶³Ì»áÕ¡ª¡ªÀûÓÃÊÓѶҵÎñʵÏÖÖÐÐÄÒ½ÔºÓë»ù²ãÒ½Ôº¾ÍÒÉÄѲ¡Ö¢½øÐлáÕï¡¢Ö¸µ¼ÖÎÁÆÓ뻤Àí¡¢¶Ô»ù²ãÒ½ÎñÈËÔ±µÄҽѧÅàѵµÈµÈ¡£¸ßÖÊÁ¿µÄÊÓѶҵÎñʹҽÉú¡¢»¤Ê¿ÔÚ²»Í¬µØ·½Í¬Ê±Ðͬ¹¤×÷³ÉΪ¿ÉÄÜ¡£Ô¶³ÌÒ½ÁƶÔÓÚһЩÖÐСҽԺÓÐ×ÅÖØÒªµÄÒâÒ壬¿ÉÒԵõ½´óÒ½ÔºµÄҽѧר¼ÒµÄ×ÉѯºÍ»áÕï¡£ Ó¦ÓÃÖ®Ò» -- ÎÞ»°·Ñ¿ÉÊÓ»¯¿Í»§·þÎñϵͳ£º ×ܹ«Ë¾Ö»Ð谲װһ̨ÊÓƵ·þÎñÆ÷¡¢¼¸Ö»ÉãÏñ»ú£¬Ô¶³ÌµÄ¸÷µØÁ¬Ëøµê·Ö¹«Ë¾Ö»ÐèʹÓÃÃâ·ÑµÄ¿Í»§¶ËÈí¼þͨ¹ýµçÄÔÉÏÍø¾Í¿Éͨ¹ýÍøÂçÓë×ܲ¿¶Ô»°£¬Í¬Ê±¿´µ½×ܲ¿¸ßÇåÎúͼÏ󡣿ÉÓÃÓÚ×ܲ¿¶ÔÏÂÊôµ¥Î»ÕÙ¿ªÊÓƵ»áÒé¡¢ÏÂÊôºô½Ð×ܲ¿½øÐÐÒµÎñÁªÏµ»ò×ܲ¿Ð²úÆ·¶Ô¹úÄÚÍâÔ¶¶Ë¿Í»§½øÐÐÑÝʾ¡¢ÅàѵºÍµç×Ó°×°åÎÄ×Ö¹µÍ¨£¬ÕâÒ»Ìصã¾ÍʹµÃ±¾ÏµÍ³¿ÉÈ¡´ú´óÐÍÆóÒµ¼¯ÍÅÄ¿Ç°°º¹óµÄ800µç»°¿Í»§·þÎñϵͳ¶øͨ¹ýÁ®¼ÛµÄÍøÂ緽ʽ¿ªÕ¹Óû§·þÎñ,ʹÓû§Ö±½Ó¿´µ½²úƷʵÎï´ïµ½×îºÃµÄÐû´«·þÎñ×÷Ó㬲¢ÇÒË«·½¶¼²»»á²úÉúÈκλ°·Ñ¡£ ÆäËü²úÆ·£º 1¡¢ÊÓƵ˫½ÊÏßÊÕ·¢Æ÷--Á®¼ÛµÄ¸ßÐÔÄÜÔ¶¾àÀë¼à¿Ø´«ÊäÉ豸,¾àÀë¿É´ï1-3ǧÃס£ 2¡¢LEDµç×ÓÏÔʾÆÁ£¬¼à¿Ø±¨¾¯×¨ÓÃÏÔʾÌõÆÁ£»3¡¢È«ÖÐÎľØÕóÍòÄÜÇл»¼à¿Ø±¨¾¯Ö÷»ú 4¡¢ÍøÂçÊÓƵ»áÒéϵͳ 5¡¢ÏúÊÛ±£°²¼à¿Ø¡¢Â¥Óî¶Ô½²É豸£¬³Ð½Ó±£°²¼à¿ØºÍУ԰ÍøÂ繤³Ì¡£7¡¢IC¿¨³ö×â³µ¼Æ¼ÛÆ÷ºÍ¹«ÎñÆû³µ¹ÜÀí»ú£»8¡¢²ÊÉ«¡¢ºÚ°×ÉãÏó»ú£¬Ë®ÏÂÉãÏó»ú,ϵÁкìÍâµÆ¡¢Æû³µÒ¹ÊÓÒÇ¡¢ÏµÁÐÎÞÏßÓ°ÒôÊÕ·¢Æ÷¡¢¹â¶Ë»ú¡¢ÊÓƵ¹²À´«ÊäµÈÉ豸. ±¾ÏµÍ³Ìص㣺 ÔÚͬһ¸öÍøÂç´ø¿í»·¾³ÏÂͼÏóºÍÓïÒôÖÊÁ¿¿É³¬¹ýÄ¿Ç°ËùÓеĹúÄÚÍâ²úÆ·£¬±¾ÏµÍ³ÊµÏÖ¸ßËÙ¸ßЧÂʵÄÈí¼þѹËõ¼¼Êõ£¬Ê¹ÊµÊ±Ñ¹Ëõ´«ÊäµÄͼÏóΪ756X576ÏóËØ£¬¶ø·ÇÏóËصķŴ󣬹ÊͼÏóÇåÎú¶È¸ß£¬Ê¹ÓÃÊó±êµã»÷»Ãæ¿É¸´Ô·Å´óΪÂúÆÁÏÔʾ£¬Ê¹ÓôóÆÁÄ»²Êµç»òͶӰÏÔʾÂúÆÁͼÏó»áÓÐÒâÏë²»µ½µÄ¸ßÇåÎú¶ÈЧ¹û¡£ ×îÐÂÏûÏ¢£º×¨Îª±¾ÏµÍ³ÅäÓõÄMCUÒµÒÑ¿ª·¢ÊÔÑé³É¹¦£¬ÒÑͨ¹ý16¡¢32ºÍ64ºÍ128 Óû§µÄ´óϵͳ²âÊÔ£¬×ª·¢µÄͼÏóÇåÎúÎȶ¨£¬¶ą̀MCU¼¶Á¬ºó¿É¹¹³É¸ü´óϵͳ£¬Ïêϸ×éÍø·½°´Ç뺯µçÁªÏµ¡£ ÐìÖÝ»ªÍ³µçÄÔÉ豸ÓÐÏÞ¹«Ë¾ ÐìÖÝÊÐÇàÄê·288ºÅËÄÂ¥ TEL£º0516-3738506 2682031 FAX£º0516-3752314 ÁªÏµÈË£ºÍõÈ𺣠ÍøÖ·£ºwww.webht.com ÓÊÏ䣺[EMAIL PROTECTED] »¶Ó¹âÁÙÍøÉÏÓªÏúÈí¼þ³¬ÊÐ http://www.sesoft.findhere.org ±¾ÓʼþÓ󬼶¹ã¸æÈí¼þ·¢ËÍ http://www.sesoft.findhere.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
David O'Brien wrote: On Tue, Jan 28, 2003 at 09:37:16PM -0800, Juli Mallett wrote: I've made a note that you don't think my way is optimal. I do, and that's that, at this point. No black magic, no convoluted config files, etc. Go deal with the ODE config and Mach's configuration files, I have. Or NetBSD's. Or OpenBSD's. At this point, I am convinced that the platform keyword is the least offensive and most productive way of doing all of this, and so on, being someone who has worked with more backwards methods, and being the person who had to deal with this first, and came up with something that suits the two groups who need it most (the pc98 mistake is probably near impossible to correct, due to the historical nature), MIPS, and PowerPC. Juli, you need to convince many more than just yourself that this is a good approach for something that is so over-reaching and will be something we *all* have to live with. Right now you don't have much of a buy-in for this, and we haven't even seen public support for it from Peter (the config(8) maintainer). I still think a PC98 conversion would be compelling. But in any case, isn't the first person to a working PPC port kind of an overriding argument, one way or the other? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Thu, 2003-01-30 at 15:48, David O'Brien wrote: On Tue, Jan 28, 2003 at 09:37:16PM -0800, Juli Mallett wrote: I've made a note that you don't think my way is optimal. I do, and that's that, at this point. No black magic, no convoluted config files, etc. Go deal with the ODE config and Mach's configuration files, I have. Or NetBSD's. Or OpenBSD's. At this point, I am convinced that the platform keyword is the least offensive and most productive way of doing all of this, and so on, being someone who has worked with more backwards methods, and being the person who had to deal with this first, and came up with something that suits the two groups who need it most (the pc98 mistake is probably near impossible to correct, due to the historical nature), MIPS, and PowerPC. Juli, you need to convince many more than just yourself that this is a good approach for something that is so over-reaching and will be something we *all* have to live with. Right now you don't have much of a buy-in for this, and we haven't even seen public support for it from Peter (the config(8) maintainer). Possibly you have a very eloquent design, and that once something is implemented using it the rest of us will have our light bulbs turned on. Maybe this is something that should remain in a Perforce tree until that time. I actually think this design is a good thing. I look at the way NetBSD does sub-ports and I find it mildly confusing unless you know a port is a sub-port of one of the top-level ports (eg, macppc's relationship to powerpc) it looks like it's a top-level port in it's own right. This system would allow us to group all the sub-ports in the same directory, thus clearly showing the relationship. I would like to see the framework for this brought in, then when I start work on making FreeBSD work on the Teron CX boards I can use it. We can also aim (if we wish) to move pc98 over to this. Alpha could also use this to separate out the various platforms and we could also use it to distinguish between acpi and legacy PC systems if we want. By rejecting this, you're forcing powerpc platform ports (of which there will be more than one, I can assure you) to do pc98-style hackery in order to exist. I really don't want this. It's my aim with the powerpc port to enable vendors to support their hardware with a minimum of effort. This means making adding new platforms easy and quick. Juli's system allows this. The current system doesn't. -- Benno Rice [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Patch to teach config(8) about platforms.
On Thu, 2003-01-30 at 15:57, David O'Brien wrote:
On Tue, Jan 28, 2003 at 11:46:47PM -0800, Marcel Moolenaar wrote:
I would not introduce a platform/foo.h, but rather
machine/${variant}/foo.h. The reason for this is that the
/usr/include/platform directory is only needed on powerpc and mips,
which seems to indicate that it should be under machine. Also,
the use of machine/${variant} allows us to install the headers for
all variants, which may improve cross-building.
This is a very nice way of adding the complexity when it is needed, but
not getting in the way of those cases where it isn't needed.
Except that it requires us to know which platform variant directory to
use in each case. If this directory is then copied or symlinked to
/usr/include/platform or /usr/include/machine/platform, I don't object
but otherwise it'll lead to an ifdef nightmare in the machine includes.
--
Benno Rice [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: Seat-belt for source upgrades from stable to current
At 8:59 PM -0800 1/29/03, Steve Kargl wrote:
On Wed, Jan 29, 2003 at 11:21:39PM -0500, Garance A Drosihn wrote:
At 8:05 PM -0800 1/29/03, Steve Kargl wrote:
uname(1) works on both 4.7 and 5.0. This seems
like a trivial problem to fix.
If you use something fixed like uname, then what does one do once
they *DO* want to switch from one branch to another one?
Compare output from /usr/bin/uname -r to ${OBJDIR}/usr.bin/uname/uname -r.
If the strings are the same, then install. If the strings are different
or an error occurs either abort the install or wait for keyboard input
to continue the installation.
You don't need a special file to indicate what version of
FreeBSD you have. uname -r tells you.
Indeed, I know what uname -r does.
I also know that it changes when freebsd goes from 4.6 to 4.7,
even though the user has not changed what branch (RELENG_4)
they intend to be pulling updates from when we decide to change
the name.
I understand what you're advocating, I just don't prefer it. On
the other hand, I agree that would also work better than what we
have now. I only want to offer some suggestions, and let someone
else (sheldon?) decide what they wanted to implement.
--
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: -current, IBM A30p 2 external FW-disks
Do you get timeout only for sbp0:0:0? Is the other drive still working? I have no problem with concurrent accesses with `iozone -s 102400m -r 1024k`. tty ad0 da0 da1 tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 21 360 0.00 0 0.00 63.76 199 12.39 64.00 249 15.54 3 1431 1.00 1 0.00 64.00 213 13.34 64.00 228 14.27 0 153 0.00 0 0.00 64.00 214 13.38 64.00 199 12.45 0 154 0.00 0 0.00 64.00 234 14.61 63.76 200 12.44 0 154 0.00 0 0.00 63.74 188 11.68 64.00 241 15.09 6 154 0.00 0 0.00 64.00 214 13.36 64.00 213 13.30 try some of the following: - fwcontorl -g 20 - sysctl hw.firewire.sbp.max_speed=0 - change SBP_QUEUE_LEN in sbp.c to 1 and rebuld module. - sysctl machdep.cpu_idle_hlt=0 - sysctl debug.sbp_debug=1 and send me a dmesg. At Tue, 28 Jan 2003 20:42:41 +0100 (CET), Michael Reifenberger wrote: fwohci0: vendor=1180, dev=522 fwohci0: 1394 Open Host Controller Interface mem 0xc0201000-0xc02017ff irq 11 at device 0.2 on pci2 It's new to me. dev=522 is not listed in /usr/share/misc/pci_vendors... system power profile changed to 'economy' Can you chane it to 'performance' mode? /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
At 8:59 PM -0800 1/29/03, Steve Kargl wrote: You don't need a special file to indicate what version of FreeBSD you have. uname -r tells you. Actually, one thing I don't know is how this would work when it comes to RELENG_4 vs RELENG_4_0 (since I don't run RELENG_4_0). What does uname show for the security branches? Just wondering. The uname idea is fine with me, if someone wants to implement it that way. -- 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: PHP on 5.0RELEASE
* Adam Bayless [EMAIL PROTECTED] [20030129 21:11]: wrote: I've got a big ugly PHP build on a brand new, otherwise clean 5.0 box that is dumping cores. It works great as an apache module, but the CLI always coredumps. Here's gdb's output: Core was generated by `php'. cut Reading symbols from /usr/libexec/ld-elf.so.1...done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x2856dde0 in strcmp () from /usr/lib/libc.so.5 cut What happens is you do the following: ln -s /usr/lib/libc.so.5 /usr/lib/libc.so.4 I had apache core dumping on 5.0-RELEASE until I did that. I haven't had time to revisit this issue although I vaguely remember something like that being discussed.. and here is what php is configured with as per customer's request: './configure' \ '--with-apxs=/usr/local/apache/bin/apxs' \ '--with-mysql=/usr/local' \ '--with-imap=/usr/local' \ '--enable-track-vars' \ '--with-mhash' \ '--with-pspell' \ '--with-gd' \ '--with-ftp' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-sockets' \ '--enable-exif' \ '--enable-discard-path' \ '--enable-bcmath' \ '--with-mm' \ '--with-openssl' \ '--with-curl' \ '--with-pfpro=/usr/local/payflowpro' \ '--with-zlib' \ Does anyone have any ideas before I try removing one line at a time from the config till I find the culprit? I am sure it's not the lines in the config file. -Wash -- Odhiambo Washington [EMAIL PROTECTED] The box said 'Requires Wananchi Online Ltd. www.wananchi.com Windows 95, NT, or better,' Tel: +254 2 313985-9 +254 2 313922 so I installed FreeBSD. GSM: +254 72 743223 +254 733 744121 This sig is McQ! :-) Lieberman's Law: Everybody lies, but it doesn't matter since nobody listens. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Thu, Jan 30, 2003 at 12:47:13AM -0500, Garance A Drosihn wrote:
At 8:59 PM -0800 1/29/03, Steve Kargl wrote:
You don't need a special file to indicate what version of
FreeBSD you have. uname -r tells you.
Actually, one thing I don't know is how this would work when it
comes to RELENG_4 vs RELENG_4_0 (since I don't run RELENG_4_0).
What does uname show for the security branches? Just wondering.
The uname idea is fine with me, if someone wants to implement it
that way.
I don't run 4.x, so I do know. ;-)
I suspect on a 4.x system, you'll get 4.x-
where is either FreeBSD or STABLE. To distinguish
between 4.x and 5.x, all we need the first character.
In actuality, if you build a 5.0 world on a 4.x system,
I think ${OBJDIR}/usr.bin/uname/uname will die with an
error when the shared libraries aren't found.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
At 9:55 PM -0800 1/29/03, Steve Kargl wrote: I don't run 4.x, so I do know. ;-) I suspect on a 4.x system, you'll get 4.x- where is either FreeBSD or STABLE. To distinguish between 4.x and 5.x, all we need the first character. So, uname -r shows 4.7-FreeBSD for the security branch? If someone intends to be running the security branch, isn't it just as much of an error if they mistakenly install the 4-stable branch when they didn't want that? I think we have to check more than the first character. Note that I'm also thinking about cases were people are doing buildworlds on one machine, and then NFS-exporting that to do installworlds on other machines. I don't do that, but we might as well try to help as many people as possible with a change like this. I'm not saying that I know what that *is*, just that I'm trying to toss out a variety of ideas... :-) -- 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: PHP on 5.0RELEASE
* Dan Nelson [EMAIL PROTECTED] [20030130 08:56]: wrote: In the last episode (Jan 30), Odhiambo Washington said: * Adam Bayless [EMAIL PROTECTED] [20030129 21:11]: wrote: I've got a big ugly PHP build on a brand new, otherwise clean 5.0 box that is dumping cores. It works great as an apache module, but the CLI always coredumps. Here's gdb's output: Core was generated by `php'. cut Reading symbols from /usr/libexec/ld-elf.so.1...done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x2856dde0 in strcmp () from /usr/lib/libc.so.5 cut What happens is you do the following: ln -s /usr/lib/libc.so.5 /usr/lib/libc.so.4 You really don't want to do that; install the compat4x port/package to get libc.so.4. Cool. I did not even know about /usr/ports/misc/compat4x :-) -Wash S y s t e m s A d m i n i s t r a t o r -- ___W_A_N_A_N_C_H_I__O_N_L_I_N_E__L_T_D___The People's Choice__ Wananchi Head Office|*| Tel: +254 2 313 985-9 1st Flr Loita, Loita St.|*| Fax: +254 2 313 922 10286-GPO, NAIROBI, KE |*| e-mail: wash at wananchi dot com -- ++ Emacs is a nice operating system, it lacks a decent editor though To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PHP on 5.0RELEASE
In the last episode (Jan 30), Odhiambo Washington said: * Adam Bayless [EMAIL PROTECTED] [20030129 21:11]: wrote: I've got a big ugly PHP build on a brand new, otherwise clean 5.0 box that is dumping cores. It works great as an apache module, but the CLI always coredumps. Here's gdb's output: Core was generated by `php'. cut Reading symbols from /usr/libexec/ld-elf.so.1...done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x2856dde0 in strcmp () from /usr/lib/libc.so.5 cut What happens is you do the following: ln -s /usr/lib/libc.so.5 /usr/lib/libc.so.4 You really don't want to do that; install the compat4x port/package to get libc.so.4. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: openpam error from sshd
Jacques A. Vidrine [EMAIL PROTECTED] writes: I believe I fixed this in revision 1.13 of pam_krb5.c. I'd be much obliged if you double-checked. Looks fine to me. Thanks! DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
