Re: Today -STABLE doesn't build in rescue - ifconfig.lo
On Thu, Mar 24, 2005 at 09:29:48AM +0200, Ion-Mihai Tetcu wrote: On Wed, 23 Mar 2005 17:47:04 -0800 Doug Barton [EMAIL PROTECTED] wrote: Ion-Mihai Tetcu wrote: Hi, This happens when makeing world with -DNOCLEAN, sources cvsup'ed 5 minutes ago. I'm going to try a clean build and let you know if that solves it: It definitely should solve it. I've been building RELENG_5 for 2 days straight without problems. And yes, it solved it :) For future reference, it's generally better to try the clean build first before sending in a report like this, especially in -stable. Point taken, but you know I'm not the one to make exaggerated noise. I was 02:35 in the morning and I wanted to know if anyone saw the same thing and if I need to wait I could simply go to bed. Thanks for the new BIND. You shouldn't be using NOCLEAN routinely; it's only safe when sources do not change. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpEe5yR43pDV.pgp Description: PGP signature
Re: fail during #make buildworld
On Thu, Mar 24, 2005 at 10:42:12AM +0700, zen wrote: Hi freebsd-stable; i just cvsup my box today my current version are 5.3 RELEASE, and cvsup it with releng_5. and the make buildworld just stop with these error messages : libmagic/../../contrib/file/apprentice.c /usr/src/lib/libmagic/../../contrib/file/funcs.c /usr/src/lib/libmagic/../../contrib/file/magic.c /usr/src/lib/libmagic/../../contrib/file/print.c /usr/obj/usr/src/i386/usr/bin/ld: cannot find -lc *** Error code 1 Stop in /usr/src/lib/libmagic. *** Error code 1 1. Remove /usr/obj/usr/src/ completely. 2. Run make cleandir to get rid of (possible) build files in /usr/src. 3. Check that your date/time is set correctly. 4. Re-run make buildworld. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpNQpJukdJU6.pgp Description: PGP signature
RE: Distinct base and ports update ?
On March 22, 2005 11:50 pm, Constant, Benjamin wrote: I think this may work if I use two cvsup files (one for the src-all and the other one for the ports) using a different date inside. You should always use separate supfiles for the source and ports trees. Why? Because the ports tree changes on a daily basis, and the source tree may only change every couple of months (depending on the branch you are tracking). Why compare every single file in the source tree on your system and the cvsup server when all you want to do is get the latest ports tree?? I agree with you. Keep them separate. Keep the tags separate. And only update the source tree when you need to. This is what I want to do but I must be sure that if I update my mirror, I can use the same base across multiple updates. That's why the date parameter sounds interesting to me. And, if all your systems are on a LAN, then why not NFS mount the /usr/src and /usr/ports directories off a central system? That way, you only have to update one system, and you're guaranteed that all the servers have the same source and ports trees. Just set the work directory prefix (it's listed in the ports(7) man page) so that the compilation work directories are local, and you're set. Unfortunately I can't but the idea is good :-) Alternatively, just have 1 build system that makes packages, and copy those packages out to the other servers, and do the installs/upgrades with packages. This is also a good way of working as it help you to remove (for example) compiler stuff from your system. Keeping your installation as minimal as possible is always a good choice. Thank your for these tips. Regards, Benjamin Constant. The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. This communication is from TI Automotive. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to `memset'
On Wed, 23 Mar 2005, Vinod Kashyap wrote:
If any kernel module has the following, or a similar line in it:
-
char x[100] = {0};
-
I think you mean:
-
auto char x[100] = {0};
-
or after fixing some style bugs:
-
char x[100] = { 0 };
-
building of the GENERIC kernel on FreeBSD 5 -STABLE for amd64
as of 03/19/05, fails with the following message at the time of linking:
undefined reference to `memset'.
The same problem is not seen on i386.
The problem goes away if the above line is changed to:
-
char x[100];
memset(x, 0, 100);
-
This version makes the pessimizations and potential bugs clear:
- clearing 100 bytes on every entry to the function is wasteful. C90's
auto initializers hide pessimizations like this. They should be
used very rarely, especially in kernels. But they are often misused,
even in kernels, even for read-only data that should be static. gcc
doesn't optimize even auto const x[100] = { 0 }; to a static
initialization -- the programmer must declare the object as static to
prevent gcc laboriously clearing it on every entry to the function.
- 100 bytes may be too much to put on the kernel stack. Objects just
a little larger than this must be dynamically allocated unless they
can be read-only.
Adding CFLAGS+=-fbuiltin, or CFLAGS+=-fno-builtin to /sys/conf/Makefile.amd64
does not help.
-fno-builtin is already in CFLAGS, and if it has any effect on this then
it should be to cause gcc to generate a call to memset() instead of doing
the memory clearing inline. I think gcc has a builtin memset() which is
turned off by -fno-builtin, but -fno-builtin doesn't affect cases where
memset() is not referenced in the source code.
-ffreestanding should prevent gcc generating calls to library functions
like memset(). However, -ffreestanding is already in CFLAGS too, and
there is a problem: certain initializations like the one in your example
need to use an interface like memset(), and struct copies need to use and
interface like memcpy(), so what is gcc to do when -fno-builtin tells it
to turn off its builtins and -ffreestanding tells it that the relevant
interfaces might not exist in the library?
Anyone knows what's happening?
gcc is expecting that memset() is in the library, but the FreeBSD kernel
is freestanding and happens not to have memset() in its library.
Related bugs:
- the FreeBSD kernel shouldn't have memset() at all. The kernel interface
for clearing memory is bzero(). A few files misspelled bzero() as
memset() and provided a macro to convert from memset() to bzero(), and
instead of fixing them a low-quality memset() was added to sys/libkern.h.
This gives an inline memset() so it doesn't help here. memset() is of
some use for setting to nonzero, but this is rarely needed and can
easily be repeated as necessary. The support for the nonzero case in
sys/libkern.h is of particularly low quality -- e.g., it crashes if
asked to set a length of 0.
- memset() to zero and/or gcc methods for initialization to 0 might be
much slower than the library's methods for clearing memory. This is
not a problem in practice, although bzero() is much faster than gcc's
methods in some cases, because:
(a) -fno-builtin turns off builtin memset().
(b) the inline memset() just uses bzero() in the fill_byte = 0 case,
so using it instead of bzero() is only a tiny pessimization.
(c) large copies that bzero() can handle better than gcc's inline
method (which is stosl on i386's for your example) cannot because
the data would be too large to fit on the kernel statck.
- there are slightly different problems for memcpy():
(a) memcpy() is in the library and is not inline, so there is no
linkage problem if gcc generates a call to memcpy() for a struct
copy.
(b) the library memcpy() never uses bcopy(), so it is much slower than
bcopy() in much cases.
(c) the reason that memcpy() is in the library is to let gcc inline
memcpy() for efficiency, but this reason was turned into nonsense
by adding -fno-builtin to CFLAGS, and all calls to memcpy() are
style bugs and ask for inefficiency. (The inefficiency is small
or negative in practice because bzero() has optimizations for
large copies that are small pessimizations for non-large copies.)
- the FreeBSD kernel shouldn't have memcmp(). It has an inline one that
has even lower quality than the inline memset(). memcmp() cannot be
implemented using bcmp() since memcmp() is tri-state but bcmp() is
boolean, but the inline memcmp() just calls bcmp(). This works, if
at all, because nothing actually needs memcmp() and memcmp() is just
a misspelling of bcmp().
Bruce
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: naming of usb tty device
Hello Rene, On Thursday 24 March 2005 15:51, you wrote: On Thu, Mar 24, 2005 at 03:15:58PM +0800, Mars Trading wrote: Hello, I heard that tty usb devices would be renamed to /dev/cuaU# replacing /dev/ucom#. Is this going to happen in 5.4-RELEASE? I This is true for 6.0 (CURRENT), in which it has already happened, but it is highly unlikely that it will be MFC'd to RELENG_5 (and thus 5.4-RELEASE) as it breaks POLA. You should contact phk for this stuff. hope so; I'm still having problems using uplcom+ucom. Maybe the renaming thing would help? What kind of problems? uplcom works fine on my 5-STABLE box, where I use the uplcom device to talk to my mobile phone. The problem is similar to that mentioned in PR usb/77294 which states: I get reproducable panic()s that look like a NULL pointer dereference. What I saw on the console: putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks putc to a clist with no reserved blocks ucom1: read start failed fatal trap 12 in kernel mode fault virtual address = 0x4c [ ... ] current process = getty stopped at usb_transfer_complete+0xd2: movl0x4c(%eax),%eax The person who wrote the PR was using getty; I'm using mgetty and I get kernel panics every now and then usually after 12-24hrs., sometimes less. What I did was to take sys/dev/usb/uplcom.c from -current and used it on -stable (crazy, I know). I still get a lot of those putc to a clist with no reserved cblocks' but the machine stayed up for over 7 days. Though I hear -current is quite usable, I'm too chicken to try it out. Dennis -- Mars Trading 9620 Kamagong St., Makati, Manila, Philippines Phone: (632) 8952241 FAX: (632) 8996124 email: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today -STABLE doesn't build in rescue - ifconfig.lo
On Thu, 24 Mar 2005 10:07:31 +0200 Ruslan Ermilov [EMAIL PROTECTED] wrote: On Thu, Mar 24, 2005 at 09:29:48AM +0200, Ion-Mihai Tetcu wrote: On Wed, 23 Mar 2005 17:47:04 -0800 Doug Barton [EMAIL PROTECTED] wrote: Ion-Mihai Tetcu wrote: Hi, This happens when makeing world with -DNOCLEAN, sources cvsup'ed 5 minutes ago. I'm going to try a clean build and let you know if that solves it: It definitely should solve it. I've been building RELENG_5 for 2 days straight without problems. And yes, it solved it :) For future reference, it's generally better to try the clean build first before sending in a report like this, especially in -stable. Point taken, but you know I'm not the one to make exaggerated noise. I was 02:35 in the morning and I wanted to know if anyone saw the same thing and if I need to wait I could simply go to bed. Thanks for the new BIND. You shouldn't be using NOCLEAN routinely; it's only safe when sources do not change. For the time from 5.3R I had only once on one machine a problem besides this (and yes, the sources haven't changed much in all this time execpt the present MFCs race :). Now I know and just had an example of it, that NOCLEAN ain't working; my question is do I risk having bad code compiled or just errors like this one ? From my knowledge of how make works in a perfect word :) not even this should happen. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to `memset'
On Thu, 24 Mar 2005, Bruce Evans wrote:
On Wed, 23 Mar 2005, Vinod Kashyap wrote:
If any kernel module has the following, or a similar line in it:
-
char x[100] = {0};
-
building of the GENERIC kernel on FreeBSD 5 -STABLE for amd64
as of 03/19/05, fails with the following message at the time of linking:
undefined reference to `memset'.
...
...
Anyone knows what's happening?
gcc is expecting that memset() is in the library, but the FreeBSD kernel
is freestanding and happens not to have memset() in its library.
As to why gcc calls memset() on amd64's but not on i386's:
- gcc-3.3.3 doesn't call memset() on amd64's either.
- gcc-3.4.2 on amd64's calls memset() starting with an array size of
65. It uses mov[qlwb] for sizes up to 16, then stos[qlwb] up to
size 64. gcc-3.3.3 on i386's uses mov[lwb] for sizes up to 8,
then stos[lwb] for all larger sizes.
- the relevant change seems to be:
% Index: i386.c
% ===
% RCS file: /home/ncvs/src/contrib/gcc/config/i386/i386.c,v
% retrieving revision 1.20
% retrieving revision 1.21
% diff -u -2 -r1.20 -r1.21
% --- i386.c19 Jun 2004 20:40:00 - 1.20
% +++ i386.c28 Jul 2004 04:47:35 - 1.21
% @@ -437,26 +502,36 @@
% ...
% +const int x86_rep_movl_optimal = m_386 | m_PENT | m_PPRO | m_K6;
% ...
Note that rep_movl is considered optimal on i386's but not on amd64's.
% @@ -10701,6 +11427,10 @@
%/* In case we don't know anything about the alignment, default to
% library version, since it is usually equally fast and result in
% - shorter code. */
% - if (!TARGET_INLINE_ALL_STRINGOPS align UNITS_PER_WORD)
% + shorter code.
% +
% + Also emit call when we know that the count is large and call overhead
% + will not be important. */
% + if (!TARGET_INLINE_ALL_STRINGOPS
% +(align UNITS_PER_WORD || !TARGET_REP_MOVL_OPTIMAL))
% return 0;
%
TARGET_REP_MOVL_OPTIMAL is x86_rep_movl_optimal modulo a mask. It is
zero for amd64's, so 0 is returned for amd64's here unless you use -mfoo
to set TARGET_INLINE_ALL_STRINGOPS. Returning 0 gives the library call
instead of a stringop.
This is in i386_expand_clrstr(). There is an identical change in
i386_expand_movstr() that gives library calls to memcpy() for (at
least) copying structs.
Bruce
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today -STABLE doesn't build in rescue - ifconfig.lo
On Thu, Mar 24, 2005 at 11:17:34AM +0200, Ion-Mihai Tetcu wrote: On Thu, 24 Mar 2005 10:07:31 +0200 Ruslan Ermilov [EMAIL PROTECTED] wrote: On Thu, Mar 24, 2005 at 09:29:48AM +0200, Ion-Mihai Tetcu wrote: On Wed, 23 Mar 2005 17:47:04 -0800 Doug Barton [EMAIL PROTECTED] wrote: Ion-Mihai Tetcu wrote: Hi, This happens when makeing world with -DNOCLEAN, sources cvsup'ed 5 minutes ago. I'm going to try a clean build and let you know if that solves it: It definitely should solve it. I've been building RELENG_5 for 2 days straight without problems. And yes, it solved it :) For future reference, it's generally better to try the clean build first before sending in a report like this, especially in -stable. Point taken, but you know I'm not the one to make exaggerated noise. I was 02:35 in the morning and I wanted to know if anyone saw the same thing and if I need to wait I could simply go to bed. Thanks for the new BIND. You shouldn't be using NOCLEAN routinely; it's only safe when sources do not change. For the time from 5.3R I had only once on one machine a problem besides this (and yes, the sources haven't changed much in all this time execpt the present MFCs race :). Now I know and just had an example of it, that NOCLEAN ain't working; my question is do I risk having bad code compiled or just errors like this one ? From my knowledge of how make works in a perfect word :) not even this should happen. Recent example: a BIND header file disappeared, but was still referenced in .depend, resulting in a broken NO_CLEAN build (on two days ago HEAD). It could also result in bad code compiled, but only if dependency info is missed, which is usually indicative of a bug in a makefile (these are rare but it happens sometimes). So your best bet whenever you upgrade your sources is to *not* use NO_CLEAN. Kernel build is cheating, it always drops .depend files (both kernel and modules) even with NO_CLEAN, so chances of getting an error there are minimal. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpuynwOXRNKl.pgp Description: PGP signature
kernel panics on sio interrupt-level overflows
Hello,
Hello,
I have FreeBSD 5.3-STABLE installed. Since I've installed a new 115200
Kbit/s modem and established ppp connection using kernel ppp, I
started recieving following messages:
sio0: 296 more interrupt-level buffer overflows (total 57038)
This message repeats almost every minute meaning serious malfunction
in the channel.
Bruce Evans [EMAIL PROTECTED] wrote in
http://lists.freebsd.org/pipermail/freebsd-bugs/2003-May/000687.html
Try changing this line in sio.c:
cp4ticks = speed / 10 / hz * 4;
to something like:
cp4ticks = speed / 10 / hz * 40;
or if you use a non-default value for hz (default is 100):
cp4ticks = speed / 10 / 100 * 40;
the change to
cp4ticks = speed / 10 / hz * 40;
made my kernel panic every 20 minutes
I use ipfw with dummynet and have set following all recommendations
HZ=1000
in my kernel configuration. So, we have
cp4ticks = speed / 10 / 100 * 40 == speed / 10 / 1000 * 4
(what is the default, unchanged value) and must work properly
but due to unproper interrupt latency we have these overflows.
So, changing cp4ticks to
cp4ticks = speed / 10 / hz * 40; == speed / 10 / 1000 * 40
made my kernel panic.
##
The worse thing is that when I returned sio.c to default, my kernel
never stopped panicing. This panic is definitely provoked by sio
device, as if I turn off my modem (or kill pppd) kernel doesn't panic.
##
Here is some data that can help:
/etc/ppp/options:
/dev/cuaa1
115200
lock
modem
crtscts
---
/etc/ppp/options.cuaa1:
noauth
persist
call ukrtel
---
/etc/ppp/peers/ukrtel:
name ukrtel
defaultroute
ipcp-accept-local
ipcp-accept-remote
???.???.???.???:???.???.???.??? - my/peers adresses
connect /etc/ppp/peers/connect.inet# empty, 1 line - exit 0
---
I am bad debugger but I can provide some info extracted from my dump:
(kgdb) backtrace
#0 doadump () at pcpu.h:159
#1 0xc060b063 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397
#2 0xc060b389 in panic (fmt=0xc080321d spin lock held too long)
at /usr/src/sys/kern/kern_shutdown.c:553
#3 0xc060270c in _mtx_lock_spin (m=0xc08d7800, td=0xc19ca320, opts=0,
file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:613
#4 0xc077c165 in siointr (arg=0xc1ab8800) at /usr/src/sys/dev/sio/sio.c:1710
#5 0xc0790ead in intr_execute_handlers (isrc=0xc19b8890, iframe=0xd541ac94)
at /usr/src/sys/i386/i386/intr_machdep.c:203
#6 0xc07932be in lapic_handle_intr (frame=
{if_vec = 52, if_fs = -717160424, if_es = -1067384816, if_ds = 16, if_edi
= -1046699232, if_esi = -1064591424, if_ebp = -717116188, if_ebx = -1046425600,
if_edx = -1064566184, if_ecx = 0, if_eax = -1046425600, if_eip = -1067440569, if
_cs = 8, if_eflags = 582, if_esp = -104520, if_ss = 4})
at /usr/src/sys/i386/i386/local_apic.c:490
#7 0xc078d753 in Xapic_isr1 () at apic_vector.s:110
#8 0x0034 in ?? ()
#9 0xd5410018 in ?? ()
#10 0xc0610010 in coredump (td=0xc08b9fc0) at vnode_if.h:1244
#11 0xc05f6f46 in ithread_loop (arg=0xc1981c80)
at /usr/src/sys/kern/kern_intr.c:546
#12 0xc05f6001 in fork_exit (callout=0xc05f6df8 ithread_loop,
arg=0xc1981c80, frame=0xd541ad48) at /usr/src/sys/kern/kern_fork.c:811
#13 0xc078d3fc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
(kgdb) list *0xc077c165
0xc077c165 is in siointr (/usr/src/sys/dev/sio/sio.c:1710).
1705
1706#ifndef COM_MULTIPORT
1707com = (struct com_s *)arg;
1708
1709mtx_lock_spin(sio_lock);
1710siointr1(com);
1711mtx_unlock_spin(sio_lock);
1712#else /* COM_MULTIPORT */
1713bool_t possibly_more_intrs;
1714int unit;
(kgdb) list *0xc060270c
0xc060270c is in _mtx_lock_spin (cpufunc.h:305).
300 }
301
302 static __inline void
303 ia32_pause(void)
304 {
305 __asm __volatile(pause);
306 }
307
308 static __inline u_int
309 read_eflags(void)
(kgdb) list *0xc060b389
0xc060b389 is at /usr/src/sys/kern/kern_shutdown.c:553.
548 mtx_lock_spin(sched_lock);
549 td-td_flags |= TDF_INPANIC;
550 mtx_unlock_spin(sched_lock);
551 if (!sync_on_panic)
552 bootopt |= RB_NOSYNC;
553 boot(bootopt);
554 }
555
556 /*
557 * Support for poweroff delay.
(kgdb) list *0xc07932be
0xc07932be is in lapic_handle_intr (/usr/src/sys/i386/i386/local_apic.c:491).
486
487 if (frame.if_vec == -1)
488 panic(Couldn't get vector from ISR!);
489 isrc = intr_lookup_source(apic_idt_to_irq(frame.if_vec));
490 intr_execute_handlers(isrc, frame);
491 }
492
493 /* Translate between IDT vectors and IRQ vectors. */
494 u_int
495 apic_irq_to_idt(u_int irq)
-
here is my dmesg:
ACPI APIC Table: VIA694 AWRDACPI
Timecounter i8254 frequency 1193182 Hz quality 0
CPU:
Re: undefined reference to `memset'
At 2005-03-24 08:31:14+, Bruce Evans writes: what is gcc to do when -fno-builtin tells it to turn off its builtins and -ffreestanding tells it that the relevant interfaces might not exist in the library? Plainly, GCC should generate code which fills the array with zeroes. It's not obliged to generate code which calls memset (either builtin or in a library). If it knows that it can do so, then fine. Otherwise it must do it the Old Fashioned Way. So this is surely a bug in GCC. Nick B, who used to write compilers for a living ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amd64 and FreeBSD 5.4-BETA1
On Wed, 23 Mar 2005 19:43:58 -0700 Scott Long [EMAIL PROTECTED] wrote: How does this machine behave with a stock 6.0-CURRENT kernel? Could It behaves in the same way. you see if the 6.0-CURRENT-SNAP002 snapshot boots on it? Yes, hang on for about an hour or two. :-) No, it also hangs (the machine stops responding) after printing the 'acd0 ...' line. If I set the hint (hint.apic.0.disabled=1) it boots completely. Anything else you wat me to try? -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Denied broadcast packets in same interface with antispoofing
FreeBSD 5.4-PRERELEASE #0: Thu Mar 17 16:41:58 EET 2005
${fwcmd} add 400 deny log ip from any to any not antispoof in
rl2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 192.168.0.97 netmask 0xffe0 broadcast 192.168.0.127
/var/log/security:
ipfw: 400 Deny ICMP:8.0 192.168.0.97 192.168.0.96 in via rl2
ipfw: 400 Deny ICMP:8.0 192.168.0.97 192.168.0.96 in via rl2
ipfw: 400 Deny ICMP:8.0 192.168.0.97 192.168.0.127 in via rl2
ipfw: 400 Deny ICMP:8.0 192.168.0.97 192.168.0.127 in via rl2
ipfw: 400 Deny UDP 192.168.0.97:123 192.168.0.127:123 in via rl2
Why are broadcast packets originating from the same interface are denied
access? Am I missing something here?
Thanks in advance,
Lefteris Tsintjelis
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Apache compile prob in portupgrade
I have run this upgrade on the 2 machines i have here, with 2 different errors but both failing to install. = Main Production Machine error: libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' *** Error code 1 Routing Machine error: Making install in prefork find: /usr/local/include/apr-1/apr.h: No such file or directory find: /usr/local/include/apr-1/apr_allocator.h: No such file or directory find: /usr/local/include/apr-1/apr_anylock.h: No such file or directory find: /usr/local/include/apr-1/apr_atomic.h: No such file or directory find: /usr/local/include/apr-1/apr_base64.h: No such file or directory etc etc etc untill it fails Something has gone wonky somewhere. -- Yours Sincerely Shinjii http://www.shinji.nq.nu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE3: ATA mkIII official patches - please test!
Søren Schmidt [EMAIL PROTECTED] writes: New version available for testing: [...] Intel ICH6R and Promise S150SX4 still working like a charm (except for missing RAID5 support). Please commit :) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ndis crash on 5.4pre with Ralink RT2500
On Tue, Mar 22, 2005 at 11:39:23PM +0100, Rene Ladan wrote: On Tue, Mar 22, 2005 at 10:49:15PM +0100, Rene Ladan wrote: On Tue, Mar 22, 2005 at 10:21:04PM +0100, Markus Trippelsdorf wrote: On Tue, 2005-03-22 at 21:51 +0100, Rene Ladan wrote: I was trying to get a Ralink RT2500 Wireless LAN Card to work. Why don't you just try the shinny new native driver? http://damien.bergamini.free.fr/ral/download.html The card itself is a Sweex LC500050, which might not work on PCIBIOS 2.1 motherboards according to ral(4) (mine is old enough to be one of these). Maybe this helps the panic? I captured a panic (hand-written), after a ndis0 up message from the kernel, with inet address still 0.0.0.0 : fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code = supervisor read, page not present instruction pointer = 0x8:0xdeadc0de stack pointer = 0x10:0xca3f7c40 frame pointer = 0x10:0xca3f7ca4 code segment = base 0x0, limit 0xf, type 0x1b DPL 0, pres 1, def32 1, gran 1 eflags = interrupt enabled, resume, IOPL=0 current proc = 32 (ndis swi) tid = 100031 show pciregs gives: [EMAIL PROTECTED]:0:0 class 0x28000 card 0x25601814 chip 0x02011814 rev 0x01 hdr 0x00 output from trace (still hand-copied): _end (c160d000, c14f6cb4, c155cb1c, c159ff6d, c160d000) @ 0xdeadc0de drv_data(c14f6000, c10eb200, c15a472c, caa19d10, c159e243) @ 0xc155cb87 = drv_data+0xa87 ndis_intrtask(c14d6000, 0, c15a2276, 100, c159e160) @ 0xc1556c07 = ndis_intrtask+0x27 ndis_runq(c15472c, caa19d48, c05f3ebb, 30e, c1315640) @ 0xc159e243 = ndis_runq+0xe3 fork_exit(c159e160, c15a472c, caa19d48) @ 0xc047d4a6 = fork_exit+0xc6 fork_trampoline() @ 0xc05c564c = fork_trampoline + 0x3 trap 0x1, eip 0, esp 0xcaa19d7c, ebp 0 Regards, Rene __ Markus -- It won't fit on the line. -- me, 2001 -- It won't fit on the line. -- me, 2001 - End forwarded message - -- It won't fit on the line. -- me, 2001 -- It won't fit on the line. -- me, 2001 pgpZprignRZm8.pgp Description: PGP signature
Re: UPDATE3: ATA mkIII official patches - please test!
Dag-Erling Smørgrav wrote: Søren Schmidt [EMAIL PROTECTED] writes: New version available for testing: [...] Intel ICH6R and Promise S150SX4 still working like a charm (except for missing RAID5 support). Please commit :) Good! If you look carefull you can see that RAID5 support has stepped closer, composite ATA commands are now in there making RAID5 possible. I've fixed a few nits with the rebuild stuff, if I dont find any real showstoppers I'll porbably commit it after eastern... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE3: ATA mkIII official patches - please test!
Søren Schmidt [EMAIL PROTECTED] writes: Good! If you look carefull you can see that RAID5 support has stepped closer, composite ATA commands are now in there making RAID5 possible. I noticed that in your email. Maybe I'll sit down on a rainy day and finish the software RAID5 support, and you can add XOR offloading later... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to `memset'
Peter Wemm [EMAIL PROTECTED] writes: I wondered if it might be because of something like -O2 (don't do that) Peter, stop that. The kernel builds and runs fine with -O2, and has for a long time. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumpon and gmirror = ioctl(DIOCSKERNELDUMP): Operation not supported
On Tue, Mar 22, 2005 at 05:45:16PM -0300, Marcus Grando wrote: + Hi, + + I try run dumpon on swap partition in gmirror disk. But that's not + possible. This error occurs: + + # dumpon -v /dev/mirror/datas1b + dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported + + It's possible to use dumpon with gmirror disk? Any patch? No, you cannot dump on GEOM providers such as gmirror's provider, because GEOM needs context switching. You can try to dump on one of the mirror components (the one with the biggest priority). -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpRxyxznrZu8.pgp Description: PGP signature
Re: Problem with Sempron-2800 + FreeBSD 5.4-BETA/PRE
On Tue, 22 Mar 2005, Tom wrote: So after my previous problem with 5.3 not being able to do a buildworld, I decided that maybe an upgrade was in order. I downloaded the 5.4 ISO and installed from it. I tried to do a buildworld, same problem as the 5.3 install. cc -DHAVE_CONFIG_H -DCOMPILE_ONLY -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -o mkmagic /usr/src/lib/libmagic/../../contrib/file/apprentice.c /usr/src/lib/libmagic/../../contrib/file/funcs.c /usr/src/lib/libmagic/../../contrib/file/magic.c /usr/src/lib/libmagic/../../contrib/file/print.c /usr/obj/usr/src/i386/usr/bin/ld: cannot find -lc *** Error code 1 Stop in /usr/src/lib/libmagic. I've had this problem on this same box with every install I've done. System time off? Check the archives, this has come up before and been traced to problems with the build environment. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: naming of usb tty device
On Thu, 24 Mar 2005, Mars Trading wrote: I heard that tty usb devices would be renamed to /dev/cuaU# replacing /dev/ucom#. Is this going to happen in 5.4-RELEASE? I hope so; I'm still having problems using uplcom+ucom. Maybe the renaming thing would help? No, this renaming is in -CURRENT only. I doubt the renaming would solve your ucom problems. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: undefined reference to `memset'
This version makes the pessimizations and potential bugs clear:
- clearing 100 bytes on every entry to the function is
wasteful. C90's
auto initializers hide pessimizations like this. They should be
used very rarely, especially in kernels. But they are
often misused,
even in kernels, even for read-only data that should be
static. gcc
doesn't optimize even auto const x[100] = { 0 }; to a static
initialization -- the programmer must declare the object
as static to
prevent gcc laboriously clearing it on every entry to the function.
- 100 bytes may be too much to put on the kernel stack. Objects just
a little larger than this must be dynamically allocated unless they
can be read-only.
A statement like this (auto and not static) is necessary if you
are dealing with re-entrancy. Whatever the issues with wastage or
bad performance, a programmer should definitely be able to do it,
if he so desires. Also, the line I mentioned earlier was only
an example. Something like this also fails (your response already
explains this):
-
struct x_type x = {0};
-
Adding CFLAGS+=-fbuiltin, or CFLAGS+=-fno-builtin to
/sys/conf/Makefile.amd64
does not help.
-fno-builtin is already in CFLAGS, and if it has any effect
on this then
it should be to cause gcc to generate a call to memset()
instead of doing
the memory clearing inline. I think gcc has a builtin
memset() which is
turned off by -fno-builtin, but -fno-builtin doesn't affect
cases where
memset() is not referenced in the source code.
-ffreestanding should prevent gcc generating calls to library
functions
like memset(). However, -ffreestanding is already in CFLAGS too, and
there is a problem: certain initializations like the one in
your example
need to use an interface like memset(), and struct copies
need to use and
interface like memcpy(), so what is gcc to do when
-fno-builtin tells it
to turn off its builtins and -ffreestanding tells it that the relevant
interfaces might not exist in the library?
Anyone knows what's happening?
gcc is expecting that memset() is in the library, but the
FreeBSD kernel
is freestanding and happens not to have memset() in its library.
How is it then, that an explicit call to memset (like in my example) works?
As about other questions in the thread:
1. Yes, the example code is within a function,
2. I should have mentioned that I don't see the problem if I am
building only the kernel module. It happens only when I am building
the kernel integrating the module containing the example code.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to `memset'
Dag-Erling Smørgrav wrote: Peter Wemm [EMAIL PROTECTED] writes: I wondered if it might be because of something like -O2 (don't do that) Peter, stop that. The kernel builds and runs fine with -O2, and has for a long time. DES No it doesn't. See the gymnastics that Bill Paul had to do recently in the iee80211 code to get around the insane inlining that gcc does with -O2. I'm not saying that gcc produces incorrect code, but I am saying that there is very strong evidence that it produces code that is incompatible with the restrictions inherent to the kernel, mainly that stack space is not infinite. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to `memset'
Scott Long writes: No it doesn't. See the gymnastics that Bill Paul had to do recently in the iee80211 code to get around the insane inlining that gcc does with -O2. I'm not saying that gcc produces incorrect code, but I am saying that there is very strong evidence that it produces code that is incompatible with the restrictions inherent to the kernel, mainly that stack space is not infinite. I wonder how this is being done elsewhere, on NetBSD, everything is built with -O2 and has been for several years afair. Not that I care much about it but apparently it doesn't seem to be such a big problem everywhere? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bdes (and other) problems on 5.3 fixit cd
Matthias Buelow [EMAIL PROTECTED] wrote: Hi folks, I'm trying the restore a dump, which I have encrypted with the bdes(1) utility, from a mounted 5.3-RELEASE fixit CD (cd2 i386). I have encrypted the dump with the same bdes that is on that CD. I use a pipeline that looks something like /mnt2/usr/bin/bdes -d dumpfile |/mnt2/sbin/restore -tf - (to view the dump) and after a couple kilobytes that seem to get through, I always get a stream of : fwrite error at 8 messages from bdes and decryption fails. Decryption works without problems on another machine on an ordinary 5.3-STABLE installation. From looking at bdes.c, the message gets written on short writes (fwrite wrote less than requested). Instead of trying to write the rest, the author decided to just print a warning and that was it. Amazingly, the message doesn't get printed in a bdes|cat pipeline. Only when restore is being used does it seem to happen. Is there anything odd with shell pipelines on the fixit disk? It doesn't matter if I use sh or tcsh for running the pipeline. On a side note, there seem to be other problems with the 5.3 fixit disk.. one has to symlink /mnt2/usr/bin to /usr/bin because otherwise scp won't find the ssh executable, and mount complains about nfs not compiled in but there's a mount_nfs utility which works ok. Editing a disklabel with bsdlabel -e device won't work, since bsdlabel complains about /mnt2/stand/vi: No such file or directory and one has to set EDITOR to vi, or an existing pathname, in order to get it to work. All in all, makes a bit of an unpolished appearance.. hasn't the stuff been tested in a while? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to `memset'
On Thu, 2005-Mar-24 12:03:19 -0800, Vinod Kashyap wrote:
[ char x[100] = { 0 }; ]
A statement like this (auto and not static)
I'd point out that this is the first time that you've mentioned that
the variable is auto. Leaving out critical information will not
encourage people to help you.
is necessary if you
are dealing with re-entrancy.
This isn't completely true. The preferred approach is:
char*x;
x = malloc(100, MEM_POOL_xxx, M_ZERO | M_WAITOK);
(with a matching free() later).
Whatever the issues with wastage or
bad performance, a programmer should definitely be able to do it,
if he so desires.
Again, untrue. The FreeBSD kernel is not a standard C environment.
Kernel stack is a relatively small, fixed size and using excessive
kernel stack will lead to panics. Increasing the kernel stack size is
undesirable because it's expensive in RAM consumption.
How is it then, that an explicit call to memset (like in my example) works?
The code
auto char x[100] = {0};
is equivalent to
auto char x[100];
memset(x, 0, sizeof(x));
but memset only exists as a static inline function (defined in libkern.h).
If an explicit call to memset works then the problem would appear to be
that the compiler's implicit expansion is failing to detect the static
inline definition, and generating an external reference which can't be
satisfied. This would seem to be a gcc bug.
2. I should have mentioned that I don't see the problem if I am
building only the kernel module. It happens only when I am building
the kernel integrating the module containing the example code.
This is the opposite of what you implied previously. There are some
differences in how kernel modules are built so this
How about posting a (short) compilable piece of C code that shows the
problem. I would expect that an nm of the resultant object would
show U memset when the code was compiled for linking into the kernel
and some_address t memset or not reference memset at all when
compiled as a module.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bdes (and other) problems on 5.3 fixit cd
oops.. that one misfired. sorry. (I was testing the weird nail program and apparently it invoked a reply on some random message..) mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to `memset'
Matthias Buelow wrote: Scott Long writes: No it doesn't. See the gymnastics that Bill Paul had to do recently in the iee80211 code to get around the insane inlining that gcc does with -O2. I'm not saying that gcc produces incorrect code, but I am saying that there is very strong evidence that it produces code that is incompatible with the restrictions inherent to the kernel, mainly that stack space is not infinite. I wonder how this is being done elsewhere, on NetBSD, everything is built with -O2 and has been for several years afair. Not that I care much about it but apparently it doesn't seem to be such a big problem everywhere? mkb. I'm sure that it's highly dependent on the version of gcc in use and the other -f flags that are passed to it, neither of which I'm familiar with in NetBSD. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ffs_mountroot: can't find rootvp after cvsup and making worldfmen
I just cvsupped to the latest RELENG_5 (as of yesterday) and built and installed the world and a new kernel. When I boot the new kernel, I get an error ffs_mountroot: can't find rootvp. At the mountroot prompt, whatever I type (even '?') causes a crash and reboot. I can still boot my old kernel without a problem. The dmesg from the old kernel and a capture of the boot of the new kernel are below. Noticably absent from the new one is the line ad0: 76319MB ST380011A/3.06 [155061/16/63] at ata0-master UDMA100 which is my only disk drive. Can somebody please help? Thanks, Graham old kernel Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #18: Fri Jan 21 06:23:06 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/fang Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 1.70GHz (1700.03-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf12 Stepping = 2 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 335478784 (319 MB) avail memory = 322949120 (307 MB) npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: GBT AWRDACPI on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x4000-0x40f7,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 rl0: RealTek 8139 10/100BaseTX port 0xc000-0xc0ff mem 0xe400-0xe4ff irq 11 at device 9.0 on pci2 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:20:ed:1c:da:f9 pci2: multimedia, audio at device 10.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 UDMA100 controller port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xd000-0xd01f irq 5 at device 31.2 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: serial bus, SMBus at device 31.3 (no driver attached) uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xd800-0xd81f irq 12 at device 31.4 on pci0 uhci1: [GIANT-LOCKED] usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered fdc0: floppy drive controller port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: Standard parallel printer port port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 ppbus0: IEEE1284 device found Probing for PnP devices on ppbus0: lpt0: Printer on ppbus0 lpt0: Interrupt-driven port atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] Timecounter TSC frequency 1700030560 Hz quality 800 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ad0: 76319MB ST380011A/3.06 [155061/16/63] at ata0-master UDMA100 Mounting root from ufs:/dev/ad0s1a new kernel /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/326592kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Wed Mar 23 20:16:31 EST 2005) |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\Loading /boot/defaults/loader.conf |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\/boot/kernel/kernel text=0x252bec
Re: undefined reference to `memset'
On Thu, 24 Mar 2005, Nick Barnes wrote: At 2005-03-24 08:31:14+, Bruce Evans writes: what is gcc to do when -fno-builtin tells it to turn off its builtins and -ffreestanding tells it that the relevant interfaces might not exist in the library? Plainly, GCC should generate code which fills the array with zeroes. It's not obliged to generate code which calls memset (either builtin or in a library). If it knows that it can do so, then fine. Otherwise it must do it the Old Fashioned Way. So this is surely a bug in GCC. Nick B, who used to write compilers for a living But the compiler can require the Old Fashioned Way to be in the library. libgcc.a is probably part of gcc even in the freestanding case. The current implementation of libgcc.a won't all work in the freestanding case, since parts of it call stdio, but some parts of it are needed and work (e.g., __divdi3() on i386's at least). The kernel doesn't use libgcc.a, but it knows that __divdi3() and friends are needed and implements them in its libkern. Strictly, it should do something similar for memset(). I think the only bugs in gcc here are that the function it calls is in the application namespace in the freestanding case, and that the requirements for freestanding implementations are not all documented. The requirement for memset() and friends _is_ documented (in gcc.info), but the requirement for __divdi3() and friends are only documented indirectly by the presence of these functions in libgcc.a. Bruce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to `memset'
On Fri, 25 Mar 2005, Peter Jeremy wrote:
On Thu, 2005-Mar-24 12:03:19 -0800, Vinod Kashyap wrote:
[ char x[100] = { 0 }; ]
A statement like this (auto and not static)
I'd point out that this is the first time that you've mentioned that
the variable is auto. Leaving out critical information will not
encourage people to help you.
It was obviously auto, since memset() would not have been called for
a global variable.
is necessary if you
are dealing with re-entrancy.
This isn't completely true. The preferred approach is:
char*x;
x = malloc(100, MEM_POOL_xxx, M_ZERO | M_WAITOK);
(with a matching free() later).
This is also preferred to alloca() and C99's dynamic arrays.
BTW, the kernel has had some dubious examples of dynamic arrays in very
important code since long before C99 existed. vm uses some dynamic
arrays, and this is only safe since the size of the arrays is bounded
and small. But when the size of an array is bounded and small,
dynamic allocation is just a pessimization -- it is more efficient
to always allocate an array with the maximum size that might be needed.
How is it then, that an explicit call to memset (like in my example) works?
The code
auto char x[100] = {0};
is equivalent to
auto char x[100];
memset(x, 0, sizeof(x));
but memset only exists as a static inline function (defined in libkern.h).
If an explicit call to memset works then the problem would appear to be
that the compiler's implicit expansion is failing to detect the static
inline definition, and generating an external reference which can't be
satisfied. This would seem to be a gcc bug.
No, it is a feature :-). See my earlier reply.
2. I should have mentioned that I don't see the problem if I am
building only the kernel module. It happens only when I am building
the kernel integrating the module containing the example code.
This is the opposite of what you implied previously. There are some
differences in how kernel modules are built so this
How about posting a (short) compilable piece of C code that shows the
problem. I would expect that an nm of the resultant object would
show U memset when the code was compiled for linking into the kernel
and some_address t memset or not reference memset at all when
compiled as a module.
I deleted the actual example. Most likely it would fail at load time
do to using memset(). Another possibility is for the code that needs
memset to be unreachable in the module since it is inside an ifdef.
Bruce
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: undefined reference to `memset'
-Original Message-
From: Peter Jeremy [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 24, 2005 2:46 PM
To: Vinod Kashyap
Cc: freebsd-stable@freebsd.org; [EMAIL PROTECTED]
Subject: Re: undefined reference to `memset'
On Thu, 2005-Mar-24 12:03:19 -0800, Vinod Kashyap wrote:
[ char x[100] = { 0 }; ]
A statement like this (auto and not static)
I'd point out that this is the first time that you've mentioned that
the variable is auto. Leaving out critical information will not
encourage people to help you.
It is char x[100] = {0}; and that's it. Doesn't it make it auto?
Isn't auto the default?
is necessary if you
are dealing with re-entrancy.
This isn't completely true. The preferred approach is:
char*x;
x = malloc(100, MEM_POOL_xxx, M_ZERO | M_WAITOK);
(with a matching free() later).
Well, I am in a function that is OS-independent, and cannot assume
malloc (or a wrapper to it) is available.
Whatever the issues with wastage or
bad performance, a programmer should definitely be able to do it,
if he so desires.
Again, untrue. The FreeBSD kernel is not a standard C environment.
Kernel stack is a relatively small, fixed size and using excessive
kernel stack will lead to panics. Increasing the kernel stack size is
undesirable because it's expensive in RAM consumption.
Whatever that may be, I don't think the compiler should be stopping me
from doing standard C stuff. I could be having this statement in my
module with full knowledge that it would not cause a kernel stack overflow.
How is it then, that an explicit call to memset (like in my
example) works?
The code
auto char x[100] = {0};
is equivalent to
auto char x[100];
memset(x, 0, sizeof(x));
but memset only exists as a static inline function (defined
in libkern.h).
If an explicit call to memset works then the problem would
appear to be
that the compiler's implicit expansion is failing to detect the static
inline definition, and generating an external reference which can't be
satisfied. This would seem to be a gcc bug.
2. I should have mentioned that I don't see the problem if I am
building only the kernel module. It happens only when I
am building
the kernel integrating the module containing the example code.
This is the opposite of what you implied previously. There are some
differences in how kernel modules are built so this
No, it's not. This is what I wrote in my first e-mail:
building of the GENERIC kernel on FreeBSD 5 -STABLE for amd64.
I just forgot to mention that the problem did not occur when I
build only the module. This is possibly due to different gcc flags
being used in the 2 cases.
How about posting a (short) compilable piece of C code that shows the
problem. I would expect that an nm of the resultant object would
show U memset when the code was compiled for linking into the kernel
and some_address t memset or not reference memset at all when
compiled as a module.
Just like the problem is not seen when I build only the module, it's
not seen if I simply write a foo.c (with the example code) and compile it.
That's the reason I posted the patch to /sys/dev/twa/twa.c, which would
cause the problem if applied, and then followed with a kernel build.
I can send the result of running nm on twa.o tomorrow.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: undefined reference to `memset'
Vinod, On Thu, 2005-03-24 at 19:01 -0800, Vinod Kashyap wrote: Just like the problem is not seen when I build only the module, it's not seen if I simply write a foo.c (with the example code) and compile it. That's the reason I posted the patch to /sys/dev/twa/twa.c, which would cause the problem if applied, and then followed with a kernel build. I can send the result of running nm on twa.o tomorrow. Please take a look at other messages in this thread, like some of the ones I have posted. They clearly show your problem in a small example and how it is happening in the -O2 case as memset is being optimized away. -O would appear to do the right thing and adding -minline-all-stringops (at either optimization level) would produce even better code. Cheers, Sean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: undefined reference to `memset'
-Original Message- From: Sean McNeil [mailto:[EMAIL PROTECTED] Sent: Thursday, March 24, 2005 7:15 PM To: Vinod Kashyap Cc: Peter Jeremy; freebsd-stable@freebsd.org; [EMAIL PROTECTED] Subject: RE: undefined reference to `memset' Vinod, On Thu, 2005-03-24 at 19:01 -0800, Vinod Kashyap wrote: Just like the problem is not seen when I build only the module, it's not seen if I simply write a foo.c (with the example code) and compile it. That's the reason I posted the patch to /sys/dev/twa/twa.c, which would cause the problem if applied, and then followed with a kernel build. I can send the result of running nm on twa.o tomorrow. Please take a look at other messages in this thread, like some of the ones I have posted. They clearly show your problem in a small example and how it is happening in the -O2 case as memset is being optimized away. -O would appear to do the right thing and adding -minline-all-stringops (at either optimization level) would produce even better code. I did look at your posting Sean, thanks. But did you see the undefined reference to `memset' linker error when you built it? It's obvious that a reference to memset is being generated by the initialization of an array of 100 bytes to 0. The linker is getting the needed memset if you build a stand alone program, or even build a stand alone kernel module, but is not being able to find it when building the kernel itself. This implies to me that it is a difference in the use of flags, or linking/not linking with particular libraries that's causing the problem. I am also confused as to how an explicit call to memset works, when compiler generated call doesn't! Are we talking 2 different memset's here? Maybe a memset and an __memset? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [joe@jbdww.com: SIIG Multiport Card]
Hello, This makes since about the baud rate not working. I have my configuration and hint file just like yours. And I get the same results. If you plug the card into a windows machine, will it work then? If so then what is the windows driver setting up differently? Could there be a patch for this card? I see there is a big list of supported cards for FreeBSD, so is any of the other better, and is low cost like the SIIG card. Thanks JBD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kirk McKusick Sent: Wednesday, March 23, 2005 10:45 PM To: Joe Doran Cc: freebsd-stable@freebsd.org Subject: Re: [EMAIL PROTECTED]: SIIG Multiport Card] - Forwarded message from Joe Doran [EMAIL PROTECTED] - From: Joe Doran [EMAIL PROTECTED] To: freebsd-stable@freebsd.org Date: Mon, 21 Mar 2005 21:25:47 -0600 Subject: SIIG Multiport Card Hello, I am trying to us a SIIG 4 port Multi-port card on FreeBSD 5.3, and I am having issues with the baud rate. The kernel finds the four ports, and I can open them, but I am unable to change the Baud Rate. It is stuck at 115,200. I have this in my kernel config. device pcu device sio Thanks JBD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] - End forwarded message - Joe, I have the following configuration for my SIIG 4 port Multi-port card on FreeBSD 5.3: device pcu device sio options COM_MULTIPORT plus the added hints in /boot/device.hints (this assuming that you have one on-board sio port. If you have two on-board ports, it would be 0x201. See sio(4)): hint.sio.1.flags=0x101 hint.sio.2.flags=0x101 hint.sio.3.flags=0x101 hint.sio.4.flags=0x101 When I boot up I get the following configuration from the card: Mar 23 13:52:24 beastie2 kernel: puc0: Oxford Semiconductor OX16PCI954 UARTs port 0x7800-0x781f,0x7400-0x741f mem 0xfb007000-0xfb007fff,0xfb006000-0xfb006fff irq 20 at device 4.0 on pci3 Mar 23 13:52:24 beastie2 kernel: sio1: Oxford Semiconductor OX16PCI954 UARTs on puc0 Mar 23 13:52:24 beastie2 kernel: sio1: type 16550A (multiport master) Mar 23 13:52:24 beastie2 kernel: sio1: unable to activate interrupt in fast mode - using normal mode Mar 23 13:52:24 beastie2 kernel: sio2: Oxford Semiconductor OX16PCI954 UARTs on puc0 Mar 23 13:52:24 beastie2 kernel: sio2: type 16550A (multiport) Mar 23 13:52:24 beastie2 kernel: sio2: unable to activate interrupt in fast mode - using normal mode Mar 23 13:52:24 beastie2 kernel: sio3: Oxford Semiconductor OX16PCI954 UARTs on puc0 Mar 23 13:52:24 beastie2 kernel: sio3: type 16550A (multiport) Mar 23 13:52:24 beastie2 kernel: sio3: unable to activate interrupt in fast mode - using normal mode Mar 23 13:52:24 beastie2 kernel: sio4: Oxford Semiconductor OX16PCI954 UARTs on puc0 Mar 23 13:52:24 beastie2 kernel: sio4: type 16550A (multiport) Mar 23 13:52:24 beastie2 kernel: sio4: unable to activate interrupt in fast mode - using normal mode I am able to tip from one port on the SIIG card to another quite happily, and I can change the baud information (at least to the extent that I have to set it to the same baud rate on both ports for them to be able to communicate with each other). But I am unable to communicate from an SIIG port to any other RS-232 port (whether native sio port or external such as a modem). To try and get an understanding of what is going on, I attached my dual trace scope to the send and receive lines. I observed the following anomolies: 1) The SIIG port is outputting a signal at +/- 3v as compared to every other RS-232 which is at +/- 5v. 2) The SIIG appears to have a badly skewed clock, running at approximately 10x what it should be. That is when it is set at 1800 baud, it is putting out characters that are about the same width as a normal port running at 19200 baud. 3) With no output, it has about a 0.2v jitter (high frequency hum) in its output. 4) It appears to be missing its final framing bit when it sends characters. I tried finding a set of baud rates that would match character widths, but even at 1800/19200 it is not quite right, and definitely is not effective at transmitting characters between SIIG and non-SIIG ports. I tried calling the SIIG support, but they seem limited to helping with how to install under Windows systems. I have concluded that the only viable way to use these ports is to buy two cards for the two machines between which I wish to debug (as they do at least seem able to talk to themselves). I am at a loss as to how to get them to talk to anything else. I have previously used Cyclades, but they want $500 for a PCI 4-port card. If you have found anything else that work, I would love to hear about it. Kirk McKusick ___ freebsd-stable@freebsd.org mailing
RE: undefined reference to `memset'
On Thu, 2005-03-24 at 19:51 -0800, Vinod Kashyap wrote: I did look at your posting Sean, thanks. But did you see the undefined reference to `memset' linker error when you built it? It's obvious that a reference to memset is being generated by the initialization of an array of 100 bytes to 0. The linker is getting the needed memset if you build a stand alone program, or even build a stand alone kernel module, but is not being able to find it when building the kernel itself. This implies to me that it is a difference in the use of flags, or linking/not linking with particular libraries that's causing the problem. Here is what I believe is happening: There exists an inline function called memset. This inline function _should_ replace any uses of memset within the function when compiled with optimization (-O or -O2). In any event that a call is not inlined, a local copy of memset should be emitted and used. This is what happens with -O, but not with -O2. This is clearly seen by an objdump at each optimization. For -O, a local copy of memset is emitted and used. For -O2, memset is still called, but the memset code is optimized away. This is a bug, IMHO, in various ways. 1) -O2 is being too agressive and eliminating memset when it shouldn't. 2) both optimized versions are not replacing the call to memset with the inline code. Here is one of several issues with the amd64 compiler used at -O2 vs. -O. There are others as well. Note: this comment inserted for the sole purpose of adding flame-bait :) You do not need to link to show this. In fact, since this is a standard program and memset is available in libc, you will not see the problem in a link. You need to look at the nm output and objdump to understand what is happening. I am also confused as to how an explicit call to memset works, when compiler generated call doesn't! Are we talking 2 different memset's here? Maybe a memset and an __memset? The problem is that the compiler is inserting the memset call. Either it is happening too late for inlining to occur or it is done in some fashion that doesn't lend to inlining by the compiler. The call inside the function is handled like all other code and is properly identified and inlined. We are not talking about 2 different memset functions, no. We are talking about 2 different mechanisms for using memset where one is not properly inlined and the other is. HTH, Sean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
