Re: FreeBSD as virtualbox guest not working
Hi, On Fri, 25 May 2012, Niclas Zeising wrote: NZSometime quite recent a change to FreeBSD CURRENT makes it almost impossible NZto run it as a virtualbox guest, at least under Windows. If I roll back the NZvbox machine to a (unfortunately quite old, from January) CURRENT everything NZseems to be working. NZThe issue is that the virtual machine runs very very slow, and makes the host NZalmost impossible to work with, especially during compiles and other NZactivities involving the CPU and the disk. I have also experienced that the NZhost machine crashes, but that might be unrelated. NZIs anyone else experiencing this, or am I doing something very wrong? I'm running current compiled with CLANG on the latest stable virtualbox under Win7. It works good, the only issue I had a couple of days ago when compiling world with -j4 (I've a 2-core with HTT) was that the CPUs were not raising their speed. They were just running on 780MHz and the compilation took half a day. A reboot of windows 'fixed' this. Normally if I do such a compile then both CPUs go up stable to 3.3GHz. I suspect that this is a bug in the BIOS or Windows where the frequency control gets stuck. NZLet me know if I need to provide more information or if I can help in some NZother way. Maybe first try to check with hwinfo what your CPUs are doing. harti ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
HEADSUP: netgraph constants changing
Hi all, as I've written a couple of days ago I'm going to bump some constants in the netgraph code that defined various name lengths in the next minutes. I've not received any negative feedback and have the ok from re. If you use netgraph make sure that the kernel, any externally maintained netgraph modules and any user space netgraph stuff (mainly ngctl and nghook) are in sync otherwise they'll not be able to communicate. This is especially important if you use netgraph for booting purposes. No correctly written code should break by this change :-) harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Bumping netgraph name sizes
Hi all, after some discussion among people working on netgraph (julian, archie, ru, brooks, emax and harti) it was decided that we need to bump several constants that define the size of names (node, hook, command string names) in netgraph because they turn out to be too short for several applications that need longer names. This change breaks the current netgraph ABI in the sense, that user programs and the kernel must be in sync and that externally maintained netgraph nodes and programs must be recompiled. Otherwise the functioning of netgraph should be unaffected (still some testing going on). We want to have this change in the tree before 5.2 for exactly this reason. If anybody has a reason why this would be a bad idea (and break something) we would like to hear that now. Attached is the corresponding patch. Regards, harti Index: sys/netgraph/ng_message.h === RCS file: /export/cvs/freebsd/src/sys/netgraph/ng_message.h,v retrieving revision 1.18 diff -u -r1.18 ng_message.h --- sys/netgraph/ng_message.h 22 Oct 2003 07:35:05 - 1.18 +++ sys/netgraph/ng_message.h 10 Nov 2003 11:04:07 - @@ -44,11 +44,21 @@ #define _NETGRAPH_NG_MESSAGE_H_ 1 /* ASCII string size limits */ -#define NG_TYPELEN 15 /* max type name len (16 with null) */ -#define NG_HOOKLEN 15 /* max hook name len (16 with null) */ -#define NG_NODELEN 15 /* max node name len (16 with null) */ -#define NG_PATHLEN 511 /* max path len (512 with null) */ -#define NG_CMDSTRLEN 15 /* max command string (16 with null) */ +#defineNG_TYPESIZ 32 /* max type name len (including null) */ +#defineNG_HOOKSIZ 32 /* max hook name len (including null) */ +#defineNG_NODESIZ 32 /* max node name len (including null) */ +#defineNG_PATHSIZ 512 /* max path len (including null) */ +#defineNG_CMDSTRSIZ32 /* max command string (including null) */ + +/* #ifndef BURN_BRIDGES */ +/* don't use these - they will go away */ +#define NG_TYPELEN (NG_TYPESIZ - 1) +#define NG_HOOKLEN (NG_HOOKSIZ - 1) +#define NG_NODELEN (NG_NODESIZ - 1) +#define NG_PATHLEN (NG_PATHSIZ - 1) +#define NG_CMDSTRLEN (NG_CMDSTRSIZ - 1) +/* #endif */ + #define NG_TEXTRESPONSE 1024 /* allow this length for a text response */ /* A netgraph message */ Index: sys/netgraph/netgraph.h === RCS file: /export/cvs/freebsd/src/sys/netgraph/netgraph.h,v retrieving revision 1.35 diff -u -r1.35 netgraph.h --- sys/netgraph/netgraph.h 22 Aug 2002 00:30:03 - 1.35 +++ sys/netgraph/netgraph.h 10 Nov 2003 11:04:07 - @@ -62,7 +62,7 @@ * Change it for NETGRAPH_DEBUG version so we cannot mix debug and non debug * modules. */ -#define _NG_ABI_VERSION 6 +#define _NG_ABI_VERSION 7 #ifdef NETGRAPH_DEBUG /*--*/ #define NG_ABI_VERSION (_NG_ABI_VERSION + 0x1) #else /* NETGRAPH_DEBUG */ /*--*/ -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld errors out on libbsnmp
On Mon, 10 Nov 2003, Dimitry Andric wrote: DAHi, DA DAI was just building world after your recent commits of the libbsnmp DAstuff. This results in the following errors: Sorry, that was my error. I have committed a fix for the library, one for the daemon follows in a couple of minutes as soon as I have verified that it builds the universe. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd core dumped
On Sat, 8 Nov 2003, Antoine Jacoutot wrote: AJHi :) AJ AJAre they any know issues with rpc.lockd under -CURRENT. AJI had a look at the gnats database and did not find anything related. AJI'm asking this because I have a lot of: AJkernel: pid 70065 (rpc.lockd), uid 0: exited on signal 11 (core dumped) AJ AJAny idea ? AJI would be pleased to send more information but I didn't see where to find AJmore debuging options for rpc.lockd. AJ AJ5.1-CURRENT #0: Tue Nov 4 01:44:35 CET 2003 [EMAIL PROTECTED]:/usr/ AJobj/usr/src/sys/KERNSRV01 i386 AJ AJThanks in advance. I can only say that I had a core dump under current on sparc, but the core file was unusable. Can you compile rcp.lockd with -g in CFLAGS and LDFLAGS and try to find out with gdb where it aborts? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Thu, 6 Nov 2003, John Baldwin wrote: JB JBOn 06-Nov-2003 Harti Brandt wrote: JB JBI figured out what is happenning I think. You are getting a spurious JB JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JB JBlists pending interrupts still waiting to be serviced. Try using JB JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JB JBthe spurious IRQ 7 interrupts go away. JB JB Ok, that seems to help. Interesting although why do these interrupts JB happen only with a larger HZ and when the kernel is doing printfs (this JB machine has a serial console). I have also not tried to disable SIO2 and JB the parallel port. JB JBCan you also try turning mixed mode back on and using JBhttp://www.FreeBSD.org/~jhb/patches/spurious.patch JB JBYou should get some stray IRQ 7's in the vmstat -i output as well as a few JBprintf's to the kernel console. Now I'm getting the same 'Couldn't get vector from ISR!' as before on Xapic_isr1. Again ISR1 is 0 and IRR1 is 0x100. Here is some data: db trace Debugger(c05ea5f4,0,c05fa63b,c0821b5c,100) at Debugger+0x55 panic(c05fa63b,c0821b6c,c062ab80,c0821bb4,c05ab57d) at panic+0x156 lapic_handle_intr() at lapic_handle_intr+0x1b Xapic_isr1() at Xapic_isr1+0x3d --- interrupt, eip = 0xc04bbbfd, esp = 0xc0821bb0, ebp = 0xc0821bb4 --- critical_exit(c0821bf4,c059af49,c0638100,0,c05f7a08) at critical_exit+0x2d _mtx_unlock_spin_flags(c0638100,0,c05f7a08,c88,c0821bec) at _mtx_unlock_spin_flags+0x23 siocnputc(c061e8e0,a,5,c0821d10,a) at siocnputc+0xe9 cnputc(a,2060d900,1,0,c05eec77) at cnputc+0x7a putchar(a,c0821d10,1,0,0) at putchar+0x6c kvprintf(c05eec76,c04d46b0,c0821d10,a,c0821d30) at kvprintf+0x8d printf(c05eec76,0,,0,c05c6e20) at printf+0x57 tc_init(c0622c60,c0821d78,c05c7b8f,8,8) at tc_init+0xc4 init_TSC_tc(8,8,c05c6e20,0,a0) at init_TSC_tc+0x91 cpu_initclocks(c0821d98,c0490ac5,0,81e000,81ec00) at cpu_initclocks+0x11f initclocks(0,81e000,81ec00,81e000,0) at initclocks+0x8 mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db x *lapic+0x110 0xd78f8110: 0 db x *lapic+0x210 0xd78f8210: 100 IRQ7 is the parallel port according to dmesg. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Wed, 5 Nov 2003, John Baldwin wrote: JB JBOn 05-Nov-2003 Harti Brandt wrote: JB On Tue, 4 Nov 2003, John Baldwin wrote: JB JB JB JB JBOn 04-Nov-2003 Harti Brandt wrote: JB JB On Tue, 4 Nov 2003, Harti Brandt wrote: JB JB JB JB HBOn Tue, 4 Nov 2003, John Baldwin wrote: JB JB HB JB JB HBJB JB JB HBJBOn 04-Nov-2003 Harti Brandt wrote: JB JB HBJB JB JB HBJB Hi, JB JB HBJB JB JB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This JB JB HBJB worked until yesterday, but with the new interrupt code it doesn't boot JB JB HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double JB JB HBJB fault. I suspect a race condition in the interrupt handling. My config JB JB HBJB file has JB JB HBJB JB JB HBJB options SMP JB JB HBJB device apic JB JB HBJB options HZ=1000 JB JB HBJB JB JB HBJBOk, I can try to reproduce. JB JB HBJB JB JB HBJB Device configuration finished. JB JB HBJB Timecounter TSC frequency 1380009492 Hz quality -100 JB JB HBJB Timecounters cpuid = 0; apic id = 00 JB JB HBJB instruction pointer = 0x8:0xc048995d JB JB HBJB stack pointer = 0x10:0xc0821bf4 JB JB HBJB frame pointercpuid = 0; apic id = 00 JB JB HBJB JB JB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from JB JB HBJB cpu_critical_exit. JB JB HBJB JB JB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. JB JB HBJBIt might be helpful to figure what type of fault you are actually getting. JB JB HB JB JB HBtf_err is 0, tf_trapno is 30 (decimal). JB JB JB JB More information: JB JB JB JB I have replaced all the reserved vectors with individual ones, that set JB JB tf_err to the index (vector number). It appears the the vector number is JB JB 39 decimal. What does that mean? JB JB JB JBIRQ 7. JB JBCan you post a verbose dmesg? Also, can you try both with and without JB JBACPI? JB JB Attached are both dmesgs. JB JB More datapoints: JB JB I had the parallel port (irq7) and the second sio disabled in the BIOS. JB After enabling both I now get a panic in lapic_handle_intr: Couldn't get JB vector from ISR! After fetching the relevant docs from intel I checked the JB registers of the apic pointed to by lapic. The interrupt taken is JB Xapic_irq1. isr1 is zero, but irr1 is 0x100 (that was without ACPI). How JB may that happen? As I understand ISR are the interrupts that have been JB delivered to the CPU so if it is interrupted a bit should be set, correct? JB JBI figured out what is happenning I think. You are getting a spurious JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JBlists pending interrupts still waiting to be serviced. Try using JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JBthe spurious IRQ 7 interrupts go away. Ok, that seems to help. Interesting although why do these interrupts happen only with a larger HZ and when the kernel is doing printfs (this machine has a serial console). I have also not tried to disable SIO2 and the parallel port. Thanks, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g++ problem
On Thu, 6 Nov 2003, Marius Strobl wrote: MSOn Thu, Nov 06, 2003 at 11:28:28AM -0500, Alexander Kabaev wrote: MS On Thu, 6 Nov 2003 16:55:00 +0100 (CET) MS C. Kukulies [EMAIL PROTECTED] wrote: MS MS I tried to compile a virus-scanner for Linux that allows for scanning MS Windoze PCs in a network for all sorts of recent viruses (RPC/DCOM and MS such). MS MS http://www.enyo.de/fw/software/doscan MS MS Compilation fails with the following: MS MS kukuboo2k# gmake MS g++ -g -O2 -Wall -I/usr/local/include -I. -I. -I./lib \ MS -MMD -MF src/doscan.d \ MS -c -o src/doscan.o src/doscan.cc MS In file included from src/doscan.cc:28: MS /usr/local/include/getopt.h:115: error: declaration of C function `int MS getopt() MS ' conflicts with MS /usr/include/unistd.h:377: error: previous declaration `int MS getopt(int, char* MS const*, const char*)' here MS gmake: *** [src/doscan.o] Error 1 MS MS I wonder where /usr/local/include comes from. If I remove that it MS compiles smoothly. MS MS Uhm, from you command line? What _this_ has to do with a compiler? MS MS MSThis happens with g++ 3.x when the devel/libgnugetopt port is installed MSand both its getopt.h and the base unistd.h are included. There are MSseveral ports that have workarounds for this issue. MSI have a patch for devel/libgnugetopt at MSftp://ftp.zeist.de/pub/patches/devel_libgnugetopt.diff MSthat should fix this issue by updating to the latest sources. MSIn my opinion the right thing to do is however to also include MSgetopt_long_only() in libc and not only getopt_long() so one can get MSrid of the devel/libgnugetopt port. I have a patch for this at MSftp://ftp.zeist.de/pub/patches/src_getopt_long_only.diff MSWhen I have time I'll continue testing of both and eventually submit MSPRs. getopt.h is broken. It should not define a Posix reserved name or the application should not use any of the interfaces in unistd.h. You cannot have both. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Wed, 5 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB On Tue, 4 Nov 2003, Harti Brandt wrote: HBJB HBJB HBOn Tue, 4 Nov 2003, John Baldwin wrote: HBJB HB HBJB HBJB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB HBJB HBJB Hi, HBJB HBJB HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB HBJB file has HBJB HBJB HBJB HBJB options SMP HBJB HBJB device apic HBJB HBJB options HZ=1000 HBJB HBJB HBJB HBJBOk, I can try to reproduce. HBJB HBJB HBJB HBJB Device configuration finished. HBJB HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB HBJB Timecounters cpuid = 0; apic id = 00 HBJB HBJB instruction pointer = 0x8:0xc048995d HBJB HBJB stack pointer = 0x10:0xc0821bf4 HBJB HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB HBJB cpu_critical_exit. HBJB HBJB HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJB HBJBIt might be helpful to figure what type of fault you are actually getting. HBJB HB HBJB HBtf_err is 0, tf_trapno is 30 (decimal). HBJB HBJB More information: HBJB HBJB I have replaced all the reserved vectors with individual ones, that set HBJB tf_err to the index (vector number). It appears the the vector number is HBJB 39 decimal. What does that mean? HBJB HBJBIRQ 7. HBJBCan you post a verbose dmesg? Also, can you try both with and without HBJBACPI? HB HBAttached are both dmesgs. HB HBMore datapoints: HB HBI had the parallel port (irq7) and the second sio disabled in the BIOS. HBAfter enabling both I now get a panic in lapic_handle_intr: Couldn't get HBvector from ISR! After fetching the relevant docs from intel I checked the HBregisters of the apic pointed to by lapic. The interrupt taken is HBXapic_irq1. isr1 is zero, but irr1 is 0x100 (that was without ACPI). How HBmay that happen? As I understand ISR are the interrupts that have been HBdelivered to the CPU so if it is interrupted a bit should be set, correct? HB HBI then have replaced the panic by a printf() followed by a return. Now the HBsystem comes to live, but I get a couple of these warnings. When the HBsystem is idle everyting seems fine, but when I start my simulation HBapplication (which normally generates between 20k and 250k interrupts/sec HBdepending on the MPSAFE setting of the ATM drivers) I get approx 1-2 of HBthese messages per second (this is with HZ=1000). HB HBA question while reading the code: what does the global lapic variable HBrefer to? As I understand every CPU has its local APIC. Does it point to HBone of those two? To which? An additional point. In the above test where I got 1-2 message per second I have now disabled a debugging printout in the ATM driver that gave 3-4 messages per second (from the interrupt handler). Now the 'Couldn't get...' messages have disappeared. So this really looks like a race somewhere. Is it possible that the bit in the ISR gets somehow cleared between the point where the interrupt is handed to the processor but before the Xapic_irq1 really runs and sees that bit? Perhaps from another Xapic_irq1 instance or whatever? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
New interrupt stuff breaks ASUS 2 CPU system
= 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x10:0xc0820994 frame pointer cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x10:0xc0820748 frame pointer cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x10:0xc08204fc frame pointer cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x10:0xc08202b0 frame pointer cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x10:0xc0820064 frame pointer cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x10:0xc081fe18 frame pointer cpuicpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x10:0xc081f734 frame pointer cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x10:0xc081f4e8 frame pointer cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x10:0xc081f29c frame pointer cpuicpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x1 0xc048995d is in critical_exit. It is the jmp after the popf from cpu_critical_exit. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Tue, 4 Nov 2003, John Baldwin wrote: JB JBOn 04-Nov-2003 Harti Brandt wrote: JB JB Hi, JB JB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This JB worked until yesterday, but with the new interrupt code it doesn't boot JB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double JB fault. I suspect a race condition in the interrupt handling. My config JB file has JB JB options SMP JB device apic JB options HZ=1000 JB JBOk, I can try to reproduce. JB JB Device configuration finished. JB Timecounter TSC frequency 1380009492 Hz quality -100 JB Timecounters cpuid = 0; apic id = 00 JB instruction pointer = 0x8:0xc048995d JB stack pointer = 0x10:0xc0821bf4 JB frame pointercpuid = 0; apic id = 00 JB JB 0xc048995d is in critical_exit. It is the jmp after the popf from JB cpu_critical_exit. JB JBThis is where interrupts are re-enabled, so you are getting an interrupt. JBIt might be helpful to figure what type of fault you are actually getting. tf_err is 0, tf_trapno is 30 (decimal). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Tue, 4 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB Hi, HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB file has HBJB HBJB options SMP HBJB device apic HBJB options HZ=1000 HBJB HBJBOk, I can try to reproduce. HBJB HBJB Device configuration finished. HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB Timecounters cpuid = 0; apic id = 00 HBJB instruction pointer = 0x8:0xc048995d HBJB stack pointer = 0x10:0xc0821bf4 HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB cpu_critical_exit. HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJBIt might be helpful to figure what type of fault you are actually getting. HB HBtf_err is 0, tf_trapno is 30 (decimal). Hmm, this seems to be the trapno that is set for all otherwise unused vectors, correct? There seems to be no info in the trapframe that shows me where this trap came from. How can I find this out? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Tue, 4 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB Hi, HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB file has HBJB HBJB options SMP HBJB device apic HBJB options HZ=1000 HBJB HBJBOk, I can try to reproduce. HBJB HBJB Device configuration finished. HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB Timecounters cpuid = 0; apic id = 00 HBJB instruction pointer = 0x8:0xc048995d HBJB stack pointer = 0x10:0xc0821bf4 HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB cpu_critical_exit. HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJBIt might be helpful to figure what type of fault you are actually getting. HB HBtf_err is 0, tf_trapno is 30 (decimal). More information: I have replaced all the reserved vectors with individual ones, that set tf_err to the index (vector number). It appears the the vector number is 39 decimal. What does that mean? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
is technically permitted by TLthe standards, if you language-lawyer them to death. TL TLTo put it in IETF terms: Be conservative in what you generate, TLand generous in what you accept. This does not apply here because you cannot return -1 and 0 at the same time. Adhering to a cleanly written standard and breaking a handful of badly written autoconf scripts is clearly better than adhering to undocumented historical behaviour. What will we do if Solaris 10 returns 0 in the above case? Change our code back? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Tue, 28 Oct 2003, Terry Lambert wrote: TLHarti Brandt wrote: TL When applying %*d%d to the string 123 the first 'd' format matches TL the string 123 and the conversion yields the number 123. This is then TL thrown away because assignment is suppressed. The next format specified TL finds an EOF condition on the stream so this counts as an input error TL according to paragraph 9, last sentence of 7.19.6.2. TL TL According to to paragraph 18 (The fscanf function returns the value of TL the macro EOF if an input failure occurs before any conversion. Otherwise, TL the function returns the number of input items assigned, which can be TL fewer than provided for, or even zero, in the event of an early matching TL failure.) the function returns 0, because there was a succesful TL conversion but no assignment. TL TLParagraph 6 of: TL TL http://www.opengroup.org/onlinepubs/007904975/functions/sscanf.html TL TLImplies that the lack of characters in the string following the TLconversion, due to failure in assignment, should result in an TLInput failure. Note also that stdio.h defines EOF as -1. I fail to locate this paragraph. This interpretation would also imply that scanf() always needs to return -1 whenever it cannot match a format specifier. TL TLI think it can be interpreted either way, still. You miss the section about RETURN VALUE: EOF is return on a read error. This is not an input error. You should also read the very 1st paragraph. This clearly states, that ISO is the primary source of information and the ISO text is a lot cleaner. TL TL TL I just had a look at the v7 implementation. In this implementation a TL suppressed assignment is not counted as a match even if the TL match was successful. This explains the return of -1 if the first TL not-suppressed conversion failes. TL TL I think changing current behaviour would be a regression with regard to TL ISO-C (and Posix). TL TLI really hate the idea of conforming to Linux; if I wanted to TLrun Linux, I'd run Linux. TL TLOn the other hand, there's a lot to be said for least common TLdenominator, and it's not like Linux' great idea of updating TLthe select struct timeval here: pretty much everyone has the TLsame behaviour as Linux, which is to say, -1. TL TLI think with a suppressed assignment, it's simply not possible TLto distinguish an error return from an EOF return, which really TLmakes me tempted to say return -1. I think it makes no sense to classify sscanf(123, %*d%d, ... as an error, but sscanf(123, %d%d, ... not, does it? Also at least Solaris 9 return -1 but fails to set errno. Which is simply a bug. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
(Cc set to current).
On Tue, 28 Oct 2003, Jordan K Hubbard wrote:
JKHBack in the pre-panther timeframe, we received the following bug report:
JKH
JKHEarlier versions of Mac OS X (e.g., 10.2.6) return a value of -1 with
JKHthe following program:
JKH
JKH#include stdlib.h
JKH
JKHmain()
JKH{ int ret, x;
JKH ret = sscanf (123, %*d%d, x);
JKH printf(ret is %d\n, ret);
JKH}
JKH
JKHOn Panther, the return value is zero. It affects packages like GMP,
JKHwhose automated test sequence assumes that -1 is the proper return
JKHvalue.
JKH
JKHA little investigation revealed that FreeBSD had changed vfscanf()
JKHabout 6 years ago, but it was the only Unix to do so and everyone
JKHelse has stuck with the more traditional behavior of returning an error
JKHin this case. We've done some investigation and consulted SUSv3, but
JKHit's unfortunately vague on what the proper behavior should be so it
JKHseems that it's been left to the various implementations to decide for
JKHthemselves what constitutes correct behavior. Given the fact that
JKHFreeBSD appears to be the odd-man out, we plan to revert back to the
JKH10.2.6 behavior for vfscanf() in 10.4, but it seems a pity to have
JKHFreeBSD diverge here (not just from Mac OS X past and future but from
JKHLinux and Solaris) in ways that break known 3rd-party software and for
JKHreasons which remain obscure.
JKH
JKHSo, two questions:
JKH
JKH1. Are the reasons not as obscure as I think? I'd welcome an
JKHexplanation as to why this was done.
I think ISO-C is pretty clear here. Basically three things happen when
the scanf() finds a format specifier: it matches the input string
according to the format specifier, if that match is not empty it converts
the value to the corresponding type and, if assignment suppression was
not specified it assigns the value.
When applying %*d%d to the string 123 the first 'd' format matches
the string 123 and the conversion yields the number 123. This is then
thrown away because assignment is suppressed. The next format specified
finds an EOF condition on the stream so this counts as an input error
according to paragraph 9, last sentence of 7.19.6.2.
According to to paragraph 18 (The fscanf function returns the value of
the macro EOF if an input failure occurs before any conversion. Otherwise,
the function returns the number of input items assigned, which can be
fewer than provided for, or even zero, in the event of an early matching
failure.) the function returns 0, because there was a succesful
conversion but no assignment.
I just had a look at the v7 implementation. In this implementation a
suppressed assignment is not counted as a match even if the
match was successful. This explains the return of -1 if the first
not-suppressed conversion failes.
I think changing current behaviour would be a regression with regard to
ISO-C (and Posix).
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Tue, 28 Oct 2003, Daniel Eischen wrote:
DEOn Tue, 28 Oct 2003, Harti Brandt wrote:
DE
DE
DE (Cc set to current).
DE
DE On Tue, 28 Oct 2003, Jordan K Hubbard wrote:
DE
DE JKHBack in the pre-panther timeframe, we received the following bug report:
DE JKH
DE JKHEarlier versions of Mac OS X (e.g., 10.2.6) return a value of -1 with
DE JKHthe following program:
DE JKH
DE JKH#include stdlib.h
DE JKH
DE JKHmain()
DE JKH{ int ret, x;
DE JKH ret = sscanf (123, %*d%d, x);
DE JKH printf(ret is %d\n, ret);
DE JKH}
DE JKH
DE JKHOn Panther, the return value is zero. It affects packages like GMP,
DE JKHwhose automated test sequence assumes that -1 is the proper return
DE JKHvalue.
DE JKH
DE JKHA little investigation revealed that FreeBSD had changed vfscanf()
DE JKHabout 6 years ago, but it was the only Unix to do so and everyone
DE JKHelse has stuck with the more traditional behavior of returning an error
DE JKHin this case. We've done some investigation and consulted SUSv3, but
DE JKHit's unfortunately vague on what the proper behavior should be so it
DE JKHseems that it's been left to the various implementations to decide for
DE JKHthemselves what constitutes correct behavior. Given the fact that
DE JKHFreeBSD appears to be the odd-man out, we plan to revert back to the
DE JKH10.2.6 behavior for vfscanf() in 10.4, but it seems a pity to have
DE JKHFreeBSD diverge here (not just from Mac OS X past and future but from
DE JKHLinux and Solaris) in ways that break known 3rd-party software and for
DE JKHreasons which remain obscure.
DE JKH
DE JKHSo, two questions:
DE JKH
DE JKH1. Are the reasons not as obscure as I think? I'd welcome an
DE JKHexplanation as to why this was done.
DE
DE I think ISO-C is pretty clear here. Basically three things happen when
DE the scanf() finds a format specifier: it matches the input string
DE according to the format specifier, if that match is not empty it converts
DE the value to the corresponding type and, if assignment suppression was
DE not specified it assigns the value.
DE
DE When applying %*d%d to the string 123 the first 'd' format matches
DE the string 123 and the conversion yields the number 123. This is then
DE thrown away because assignment is suppressed. The next format specified
DE finds an EOF condition on the stream so this counts as an input error
DE according to paragraph 9, last sentence of 7.19.6.2.
DE
DE According to to paragraph 18 (The fscanf function returns the value of
DE the macro EOF if an input failure occurs before any conversion. Otherwise,
DE the function returns the number of input items assigned, which can be
DE fewer than provided for, or even zero, in the event of an early matching
DE failure.) the function returns 0, because there was a succesful
DE conversion but no assignment.
DE
DE I just had a look at the v7 implementation. In this implementation a
DE suppressed assignment is not counted as a match even if the
DE match was successful. This explains the return of -1 if the first
DE not-suppressed conversion failes.
DE
DE I think changing current behaviour would be a regression with regard to
DE ISO-C (and Posix).
DE
DEI agree, and to add a little snippet of POSIX:
DE
DE RETURN VALUE
DE
DEUpon successful completion, these functions shall return the
DEnumber of successfully matched and assigned input items; this
DEnumber can be zero in the event of an early matching failure.
DEIf the input ends before the first matching failure or
DEconversion, EOF shall be returned. If a read error occurs, the
DEerror indicator for the stream is set, EOF shall be returned,
DEand errno shall be set to indicate the error.
DE
DEThere is no matching failure, but there is a conversion. I think
DE%*d just counts as an assignment suppression but does not suppress
DEthe fact that a conversion occurred.
DE
DEOn the other hand, Solaris 8 does seem to return -1...
But Solaris 8 and 9 also don't understand 'hh' modifiers and therefor are
neither ISO nor Posix conform. While we have Solaris 10 here, we have yet
to install it somewhere.
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, 20 Oct 2003, Vallo Kallaste wrote: VKHi VK VKIt seems to be a recent problem. The hardware is OK, both Windows XP VK(which I use very seldom) and Gentoo Linux do not exhibit any VKproblems. VKBasically one will get random signals as I have got in build- and VKinstallworld. It's impossible to complete make -j2 buildworld on my VKmachine, but sometimes non-parallel buildworld will do, only to die VKlater in installworld. VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it VKmatters. I have the same MB just with 1800+ processors. I had to reduce the CPU frequency by about 10% in the BIOS setup to get the machine stable. I assume the problem is actually the memory. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, 20 Oct 2003, Mark Santcroos wrote: MSOn Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote: MS On Mon, 20 Oct 2003, Vallo Kallaste wrote: MS MS VKHi MS VK MS VKIt seems to be a recent problem. The hardware is OK, both Windows XP MS VK(which I use very seldom) and Gentoo Linux do not exhibit any MS VKproblems. MS VKBasically one will get random signals as I have got in build- and MS VKinstallworld. It's impossible to complete make -j2 buildworld on my MS VKmachine, but sometimes non-parallel buildworld will do, only to die MS VKlater in installworld. MS VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and MS VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it MS VKmatters. MS MS I have the same MB just with 1800+ processors. I had to reduce the CPU MS frequency by about 10% in the BIOS setup to get the machine stable. I MS assume the problem is actually the memory. MS MSCouldn't the following be of help here? MS MSoptions DISABLE_PSE MSoptions DISABLE_PG_G Is the processor bug that these options seem to circumvent dependend on the actual operating frequency of the processor? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, 20 Oct 2003, Christian Brueffer wrote: CBOn Mon, Oct 20, 2003 at 10:50:02AM -0400, Barney Wolff wrote: CB On Mon, Oct 20, 2003 at 03:20:56PM +0200, Mark Santcroos wrote: CB On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote: CB On Mon, 20 Oct 2003, Vallo Kallaste wrote: CB CB VKHi CB VK CB VKIt seems to be a recent problem. The hardware is OK, both Windows XP CB VK(which I use very seldom) and Gentoo Linux do not exhibit any CB VKproblems. CB VKBasically one will get random signals as I have got in build- and CB VKinstallworld. It's impossible to complete make -j2 buildworld on my CB VKmachine, but sometimes non-parallel buildworld will do, only to die CB VKlater in installworld. CB VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and CB VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it CB VKmatters. CB CB I have the same MB just with 1800+ processors. I had to reduce the CPU CB frequency by about 10% in the BIOS setup to get the machine stable. I CB assume the problem is actually the memory. CB CB Couldn't the following be of help here? CB CB options DISABLE_PSE CB options DISABLE_PG_G CB CB I don't think so. I tried that on my A7M266D with no effect. I believe CB something in recent pmap code doesn't like this mobo, or maybe dual CB athlons in general. I can run RELENG_5_1 rock solid, and -current from CB 9/24/03 rock solid, but -current from 10/3 or later gets random sigs CB and eventually panics. I have scsi disks so it's not ata. CB CB CBI have the same experiences. Also AMD A7M-266D with two 1800+ Athlons here. CBUsed to work fine, but got random signals with my latest builds. I have no problems with the -current, but, as I've said, I have tuned speed down. If I remember correctly they running slower than their nominal speed. Dmesg shows 1380.01MHz, although they're 1800+. This is tuneable in the BIOS. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cannot create partition entries for /dev/ad3
On Thu, 9 Oct 2003, David Gilbert wrote: DG Daniel == Daniel O'Connor [EMAIL PROTECTED] writes: DG DGDaniel The only reason most people will ever touch /dev is to either DGDaniel make devices (hence no longer necessary with devfs), or change DGDaniel permissions. The later is more difficult with devfs, but IMHO DGDaniel the tradeoff is worthwhile. DG DGThis brings me to my (small) beef with devfs. When you invoke an DGabstraction, a metric of the usefulness of that abstraction is how DGwell the abstractions metaphors map onto the target system's DGmetaphors. DG DGSo as a filesystem, devfs does will by replicating the average DGperson's view of should be in /dev ... subject to what devices are DGactually found... DG DGBut filesystems also have persistence. In the trivial case, the DGpersistence of the object (say ... a disk) preserved the filesystems DGnode. But if I walk into /dev and change the permissions on a node, DGthis persists only until the next reboot. Filesystems not necessarily have persistance. Although it would be fancy to be able to backup and restore /proc or /portal. Many devices (especially with all this hot-plugable stuff today) are not persistant, why should their representation be? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no partition entries for /dev/ad3
On Wed, 8 Oct 2003, ecsd wrote: eHere are the contents of my /dev. As you can see, there are no entries efor the epartitions of ad3. My 5.0 system has no bsdlabel command. Can anyone etell me how I can coax the ad3s1* entries into existence? You probably need to fdisk(8) your disk first. The slices should then appear automagically. Then you can disklabel(8) the slices which will bring the partitions into life. Disklabel and bsdlabel are the same on i386. harti e e./ ad2s1c dspW0.1 pci estdin@ ttypg e../ ad2s1d dspr0.0 ppi0 estdout@ ttyph ead0 ad2s1e fd/ psm0 esysmousettypi ead0s1 ad2s1f geom.ctlptyp0 ettyd0 ttyv0 ead0s1a ad2s1g io ptyp1 ettyd1 ttyv1 ead0s1b ad3 ipauth ptyp2 ettyid0 ttyv2 ead0s1c agpgart ipl ptyp3 ettyid1 ttyv3 ead0s1d ata ipnat ptyp4 ettyld0 ttyv4 ead0s1e audio0.0ipstate ptyp5 ettyld1 ttyv5 ead0s1f audio0.1kbd0ptyp6 ettyp0 ttyv6 ead0s1g bpf0klogptyp7 ettyp1 ttyv7 ead1 bpsm0 kmemptyp8 ettyp2 ttyv8 ead1cconsole log@ptyp9 ettyp3 ttyv9 ead1s1 consolectl lpt0ptypa ettyp4 ttyva ead1s1a cttylpt0.ctlptypb ettyp5 ttyvb ead1s1b cuaa0 mdctl ptypc ettyp6 ttyvc ead1s1c cuaa1 mem ptypd ettyp7 ttyvd ead1s1e cuaia0 mixer0 ptype ettyp8 ttyve ead1s1f cuaia1 net/ptypf ettyp9 ttyvf ead1s1g cuala0 net1@ ptypg ettypa urandom@ ead1s1h cuala1 net2@ ptyph ettypb vga@ ead2 devctl net3@ ptypi ettypc xpt0 ead2s1 dsp0.0 net4@ random ettypd zero ead2s1a dsp0.1 network sndstat ttype ead2s1b dspW0.0 nullstderr@ ttypf e e e___ e[EMAIL PROTECTED] mailing list ehttp://lists.freebsd.org/mailman/listinfo/freebsd-current eTo unsubscribe, send any mail to [EMAIL PROTECTED] e -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no partition entries for /dev/ad3
On Wed, 8 Oct 2003, ecsd wrote: eI had already been able to go so far as to disklabel -w -r ad3 auto. eAfter doing this eon a 4.X system I would then disklabel -e /dev/ad3s1c, but /dev/ad3s1c edoes enot exist, so I am stuck. Maybe there is a rescan devices command? e efdisk thinks it has no work to do: e e*** Working on device /dev/ad3 *** e[...] eInformation from DOS bootblock is: e1: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) estart 63, size 39102273 (19092 Meg), flag 80 (active) ebeg: cyl 0/ head 1/ sector 1; eend: cyl 1023/ head 15/ sector 63 e2: UNUSED e3: UNUSED e4: UNUSED In that case you should have a /dev/ad3s1. Have you? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no partition entries for /dev/ad3
On Wed, 8 Oct 2003, ecsd wrote: eHarti Brandt wrote: eOn Wed, 8 Oct 2003, ecsd wrote: eeI had already been able to go so far as to disklabel -w -r ad3 auto. eeAfter doing this on a 4.X system I would then disklabel -e /dev/ad3s1c eebut /dev/ad3s1c does not exist, so I am stuck. eeMaybe there is a rescan devices command? e ee fdisk thinks it has no work to do. e eIn that case you should have a /dev/ad3s1. Have you? eharti e eThe chronology is that I booted the system, did the disklabel -w -r ad3 eauto, eturned around to disklabel -e /dev/ad3s1c (as I would normally do), and ewas told that /dev/ad3s1c did not exist. Then I wrote in here asking for ehelp. ead3s1c does not exist. If I understand correctly disklabel -e ad3 auto will create you partitions without creating slices. You should get /dev/ad3c and this will cover the entire disk (though I don't know if this is really supported). Normally you should put slices onto your disk and disklabel the slices. Given that you have a correct fdisk label you should have the slice entries /dev/ad3s[1-4]. Then you can disklabel the slices: 'disklabel -e /dev/ad3s1 auto'. ad3s1c of course does not exist if you don't have labeled the slice. You must label the slice (da3s1), not a partition thereof (da3s1c). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cannot create partition entries for /dev/ad3
On Wed, 8 Oct 2003, ecsd wrote: eGiven that FreeBSD 5.1 is on the shelf in a box at CompUSA for sale to the egeneral public, I think the proper thing to do is address the matter of edocumenting the revised operation of the devices in 5.X, rather than tell epeople to downgrade if they don't understand the behavior of their system, ebesides which FreeBSD 4.8 or 4.9 are not for sale at CompUSA as a consolation. eI did ask to know what documentation there is for the new behavior, but I have enot heard any replies. If there isn't any documentation, that's an answer too. You may want to look at section 12.3.2.1 of the handbook which will tell you to use 1) fdisk on the disk (da3) 2) disklabel on the slice (da3s1) 3) newfs on the partition (da3s1e) Yes, I know, real users don't read handbooks ... harti ePoul-Henning Kamp writes: eIn message [EMAIL PROTECTED], ecsd writes: eMAKEDEV was the cheese since year zero. [...] eI suggest you stick with 4-stable until you have caught up with ethe changes and the documentation. e e e___ e[EMAIL PROTECTED] mailing list ehttp://lists.freebsd.org/mailman/listinfo/freebsd-current eTo unsubscribe, send any mail to [EMAIL PROTECTED] e -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: procfs problem
You must mount procfs. # fstab; proc/proc procfs rw 0 0 harti On Mon, 29 Sep 2003, Jiri Mikulas wrote: JMHello JMi have problem with /proc JMi already have JM JMoptions PROCFS JMoptions PSEUDOFS JM JMin kernel JMbut get these messages JM~~~cut~~~ JMmap02# strace -p 730 JMstrace: open(/proc/..., ...): No such file or directory JMtrouble opening proc file JMmap02# truss -p 730 JMtruss: cannot open /proc/730/mem: No such file or directory JMmap02# ps aux | grep 730 JMroot 730 0.0 1.0 3476 2448 ?? Ss8:40AM 0:00.21 JM/usr/sbin/sshd JMmap02# uname -a JMFreeBSD map02.modrany.czf 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Sun Sep 28 JM23:37:08 CEST 2003 JM[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ROUTER i386 JM~~~cut~~~ JMthe same messages i get also at JM5.1-RELEASE-p3 FreeBSD 5.1-RELEASE-p3 #2: Wed Sep 17 00:17:40 CEST 2003 JMbox JM JMany ideas or do i something wrong? (forget I read anything about new JMprocfs - sorry if yes ...) ? JMthaks for reply JMJiri JM JM___ JM[EMAIL PROTECTED] mailing list JMhttp://lists.freebsd.org/mailman/listinfo/freebsd-current JMTo unsubscribe, send any mail to [EMAIL PROTECTED] JM -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrade from static to dynamic root
On Wed, 17 Sep 2003, Gordon Tetlow wrote: GTOn Tue, Sep 16, 2003 at 06:11:01PM +0200, Harti Brandt wrote: GT On Tue, 16 Sep 2003, Richard Nyberg wrote: GT GT RNAt Thu, 11 Sep 2003 14:44:55 +0200 (CEST), GT RNHarti Brandt wrote: GT RN Hi, GT RN GT RN I just tried to upgrade one of my systems from a static root from july to GT RN an actual dynamic root. The installworld went fine 'til the place where GT RN /bin/test is installed. At that point the installation stopped with ELF GT RN interpreter /libexec/ld-elf.so.1 not found. And really /libexec is not GT RN populated yet. GT RN GT RNMe too :( GT RNTo get installworld back on track I used cp under linux emulation to GT RNcopy ld-elf.so.1. Then I also had to run ldconfig -m /lib. After that GT RNmake installworld completed successfully. GT GT Or you could cd into /usr/obj/usr/src/rescue/rescue and do ./rescue cp ... GT (as long as you have a working shell) GT GTWhich of course exists in /rescue too. No, it doesn't. Rescue is installed after /bin, so if something goes wrong early in installworld, your system is hosed: no /libexec, no /rescue. You need to know how to get yourself out of this by pulling your hair... Seems that Ruslan has taken care of and emergency install of rtld-elf. This leaves you still without /rescue, but enables you to run at least /bin/sh. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrade from static to dynamic root
On Tue, 16 Sep 2003, Richard Nyberg wrote: RNAt Thu, 11 Sep 2003 14:44:55 +0200 (CEST), RNHarti Brandt wrote: RN Hi, RN RN I just tried to upgrade one of my systems from a static root from july to RN an actual dynamic root. The installworld went fine 'til the place where RN /bin/test is installed. At that point the installation stopped with ELF RN interpreter /libexec/ld-elf.so.1 not found. And really /libexec is not RN populated yet. RN RNMe too :( RNTo get installworld back on track I used cp under linux emulation to RNcopy ld-elf.so.1. Then I also had to run ldconfig -m /lib. After that RNmake installworld completed successfully. Or you could cd into /usr/obj/usr/src/rescue/rescue and do ./rescue cp ... (as long as you have a working shell) harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrade from static to dynamic root
On Sun, 14 Sep 2003, Ruslan Ermilov wrote:
REOn Thu, Sep 11, 2003 at 02:44:55PM +0200, Harti Brandt wrote:
RE
RE Hi,
RE
RE I just tried to upgrade one of my systems from a static root from july to
RE an actual dynamic root. The installworld went fine 'til the place where
RE /bin/test is installed. At that point the installation stopped with ELF
RE interpreter /libexec/ld-elf.so.1 not found. And really /libexec is not
RE populated yet. May it be, that the makefile uses one of the newly
RE installed tools during install? For example 'ln' to make the link test -
RE [?
RE
REIt shouldn't happen, because we save test and [ in ${INSTALLTMP}.
REIt looks like something hardcodes /bin/test. I've grepped the
REsrc/ makefiles and cannot find such a place. Where exactly did
REit happen in the installworld for you?
It installed /bin/test and then failed just when it was going to make the
link to '['. Unfortunately this is rather hard to reproduce, unless I roll
everything back.
harti
RE Also, wouldn't it be helpful to populate /rescue before /bin? Just in
RE the case something goes wrong between installing been and rescue for the
RE first time?
RE
REGood idea!
RE
RE
RECheers,
RE
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
upgrade from static to dynamic root
Hi, I just tried to upgrade one of my systems from a static root from july to an actual dynamic root. The installworld went fine 'til the place where /bin/test is installed. At that point the installation stopped with ELF interpreter /libexec/ld-elf.so.1 not found. And really /libexec is not populated yet. May it be, that the makefile uses one of the newly installed tools during install? For example 'ln' to make the link test - [? Also, wouldn't it be helpful to populate /rescue before /bin? Just in the case something goes wrong between installing been and rescue for the first time? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SENDMAIL_MC
On Tue, 26 Aug 2003, Gregory Neil Shapiro wrote:
GNS I have SENDMAIL_MC and SENDMAIL_SUBMIT_MC defined in /etc/make.conf
GNS (both with the full path, i.e. /etc/mail/...). From the documentation
GNS I take it, that this should work. My installworld however breaks because
GNS src/etc/sendmail/Makefile strips the pathname from the variables before
GNS trying to install the files.
GNS
GNS So, is this supposed to work this way?
GNS
GNSYes, it is supposed to work just fine. Can you show the exact
GNSerror you get after a buildworld and installworld? Also you
GNSmight try this before the buildworld:
GNS
GNScd /usr/src/etc/sendmail
GNSmake cleandir
GNSmake cleandir
This doesn't help. The error is:
=== etc
=== etc/sendmail
install -o root -g wheel -m 644 fokus.cf /etc/mail/sendmail.cf
install: fokus.cf: No such file or directory
*** Error code 71
Stop in /usr/src/etc/sendmail.
*** Error code 1
Stop in /usr/src/etc.
*** Error code 1
And I have the files:
/etc/mail/fokus.cf
/etc/mail/fokus.mc
/etc/mail/fokus.submit.cf
/etc/mail/fokus.submit.mc
The problem (I think) is in src/etc/sendmail/Makefile:
.if defined(SENDMAIL_MC)
INSTALL_CF= ${SENDMAIL_MC:T:R}.cf
This leaves INSTALL_CF with fokus.cf (the path is stripped off) and
there is (of course) no fokus.cf in src/etc/sendmail.
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SENDMAIL_MC
On Wed, 27 Aug 2003, Gregory Neil Shapiro wrote:
GNS The problem (I think) is in src/etc/sendmail/Makefile:
GNS
GNS .if defined(SENDMAIL_MC)
GNS INSTALL_CF= ${SENDMAIL_MC:T:R}.cf
GNS
GNS This leaves INSTALL_CF with fokus.cf (the path is stripped off) and
GNS there is (of course) no fokus.cf in src/etc/sendmail.
GNS
GNSBut there should be one in /usr/obj/usr/src/etc/sendmail/. Is there?
No. And now I got it. Sorry, my fault.
At some time not so long ago buildworld tried to build INSTALL_CF in
/etc/mail. I do my buildworlds as a non-privileged user and they failed
therefor. So I added magic in /etc/make.conf to not define SENDMAIL_MC
when doing buildworld. This worked until the build/install was really
fixed not so long ago, but now is obviously wrong.
Thanks for your help,
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
SENDMAIL_MC
Hi, I have SENDMAIL_MC and SENDMAIL_SUBMIT_MC defined in /etc/make.conf (both with the full path, i.e. /etc/mail/...). From the documentation I take it, that this should work. My installworld however breaks because src/etc/sendmail/Makefile strips the pathname from the variables before trying to install the files. So, is this supposed to work this way? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 in world
On Sun, 3 Aug 2003, Bernd Walter wrote: BWOn Sun, Aug 03, 2003 at 04:07:15PM +0200, Jens Rehsack wrote: BW Hi David, BW BW I've seen that several world daemons (rpcbind, telnetd, ...) are BW build with INET6. BW In real life, I do not know anyone who owns some IPv6 addresses BW but many guys who disabled INET6 on their machines in kernel. BW BWYou don't know me? BWNot to speak that each IPv4 address owner automaticaly owns IPv6 BWspace via 6to4 - see stf(4). BWIt's already available for everyone - just enable and use it. What's the sense of enabling and using IPv6, if your infrastucture in the company doesn't support it (because of the overhead with routing (hardware vs. software routing)) and you don't have an IPv6 connection to the outside world. Well, you could ping localhost per IPv6... harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current tinderbox] failure on i386/i386
That was just bad luck between two related commits. Sorry. harti On Tue, 29 Jul 2003, Tinderbox wrote: TTB --- 2003-07-29 18:31:41 - starting CURRENT tinderbox run for i386/i386 TTB --- 2003-07-29 18:31:41 - checking out the source tree TTB --- cd /home/des/tinderbox/CURRENT/i386/i386 TTB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TTB --- 2003-07-29 18:34:24 - building world TTB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TTB --- /usr/bin/make -B buildworld T Rebuilding the temporary build tree T stage 1: legacy release compatibility shims T stage 1: bootstrap tools T stage 2: cleaning up the object tree T stage 2: rebuilding the object tree T stage 2: build tools T stage 3: cross tools T stage 4: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include T stage 4: building libraries T stage 4: make dependencies T stage 4: building everything.. TTB --- 2003-07-29 19:34:01 - building generic kernel TTB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TTB --- /usr/bin/make buildkernel KERNCONF=GENERIC T Kernel build for GENERIC started on Tue Jul 29 19:34:01 GMT 2003 T Kernel build for GENERIC completed on Tue Jul 29 19:48:29 GMT 2003 TTB --- 2003-07-29 19:48:29 - generating LINT kernel config TTB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TTB --- /usr/bin/make -B LINT TTB --- 2003-07-29 19:48:29 - building LINT kernel TTB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TTB --- /usr/bin/make buildkernel KERNCONF=LINT T Kernel build for LINT started on Tue Jul 29 19:48:29 GMT 2003 T[...] Tcc -shared -nostdlib hack.c -o hack.So Trm -f hack.c Tsh /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/conf/newvers.sh LINT Tcc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline vers.c Tlinking kernel Tng_atm.o: In function `ng_atm_mod_event': Tng_atm.o(.text+0x24c0): undefined reference to `ng_atm_message_p' Tng_atm.o(.text+0x255c): undefined reference to `ng_atm_message_p' T*** Error code 1 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. T*** Error code 1 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. T*** Error code 1 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TTB --- 2003-07-29 20:01:08 - /usr/bin/make returned exit code 1 TTB --- 2003-07-29 20:01:08 - ERROR: failed to build lint kernel TTB --- 2003-07-29 20:01:08 - tinderbox aborted T T___ T[EMAIL PROTECTED] mailing list Thttp://lists.freebsd.org/mailman/listinfo/freebsd-current TTo unsubscribe, send any mail to [EMAIL PROTECTED] T -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration
On Mon, 21 Jul 2003, David O'Brien wrote: DOOn Tue, Jul 15, 2003 at 07:59:43AM +0200, Harti Brandt wrote: DO On Tue, 15 Jul 2003, Jun Kuriyama wrote: DO JKWith new gcc and -Wshadow, src/bin/ed/re.c shows this warning: DO JK DO JKcc -Wshadow -c re.c DO JKre.c: In function `get_compiled_pattern': DO JKre.c:44: warning: declaration of `exp' shadows a global declaration DO JKbuilt-in:0: warning: shadowed declaration is here DO JK DO JKIt seems local variable exp is conflicted with exp(3) declaration. I DO JKdon't know what name should be used... DO DO I would call this a compiler bug. It shouldn't declare exp(3) when you DO don't include math.h. As I understand the standard the names in math.h are DO only reserved when you include math.h. I remember that an earlier version DO of gcc had this bug, that was fixed then. Probably they unfixed it again. DO DO What's the chance of getting this fixed? DO DOThere is a discussion on the [EMAIL PROTECTED] mailing list, but DOthey are having a hard time agreeing there is a bug here. FreeBSD's GCC DOproblems have a better chance of getting fixed if those that experience DOand understand the bug would participate in related discussions on the DOGCC mailing lists. The Linux and Solaris community has no problem doing DOthis -- for some reason the BSD communities expects the poor guy doing DOthe GCC imports to be the single voice for BSD. :-( Well, I have subscribed. I red the messages in this thread and it seems, that there is more agreement that this needs to be fixed than people against it. I'm not familiar with the process in the gcc-community. Is there any action required? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on i386/pc98
Sorry, I failed to commit one of the files. Should work now. harti On Mon, 21 Jul 2003, Tinderbox wrote: TTB --- 2003-07-21 19:01:13 - starting CURRENT tinderbox run for i386/pc98 TTB --- 2003-07-21 19:01:13 - checking out the source tree TTB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TTB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TTB --- 2003-07-21 19:03:15 - building world TTB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TTB --- /usr/bin/make -B buildworld T Rebuilding the temporary build tree T stage 1: legacy release compatibility shims T stage 1: bootstrap tools T stage 2: cleaning up the object tree T stage 2: rebuilding the object tree T stage 2: build tools T stage 3: cross tools T stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include T stage 4: building libraries T stage 4: make dependencies T stage 4: building everything.. TTB --- 2003-07-21 20:02:20 - building generic kernel TTB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TTB --- /usr/bin/make buildkernel KERNCONF=GENERIC T Kernel build for GENERIC started on Mon Jul 21 20:02:20 GMT 2003 T[...] T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13].dev') T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13]') T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c: In function `harp_attach': T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: `MEDIA_UTP25' undeclared (first use in this function) T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: (Each undeclared identifier is reported only once T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: for each function it appears in.) T*** Error code 1 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/harp. T*** Error code 1 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules. T*** Error code 1 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. T*** Error code 1 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. T*** Error code 1 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TTB --- 2003-07-21 20:09:36 - /usr/bin/make returned exit code 1 TTB --- 2003-07-21 20:09:36 - ERROR: failed to build generic kernel TTB --- 2003-07-21 20:09:36 - tinderbox aborted T T___ T[EMAIL PROTECTED] mailing list Thttp://lists.freebsd.org/mailman/listinfo/freebsd-current TTo unsubscribe, send any mail to [EMAIL PROTECTED] T -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stop in /usr/src/sys/modules/harp
I have commited the missing file just now. Sorry for that. harti On Mon, 21 Jul 2003, Xaos wrote: X-BEGIN PGP SIGNED MESSAGE- XHash: SHA1 X XI keep getting this error when compiling a freshly cvsup'd source. 5.1-Current X X/usr/src/sys/dev/harp/if_harp.c:128: `VENDAPI_FORE_2' undeclared here (not in Xa function) X/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for X`map_devs[2].api') X/usr/src/sys/dev/harp/if_harp.c:128: `DEV_FORE_HE155' undeclared here (not in Xa function) X/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for X`map_devs[2].dev') X/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for X`map_devs[2]') X/usr/src/sys/dev/harp/if_harp.c:130: `VENDAPI_FORE_2' undeclared here (not in Xa function) X/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for X`map_devs[3].api') X/usr/src/sys/dev/harp/if_harp.c:130: `DEV_FORE_HE622' undeclared here (not in Xa function) X/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for X`map_devs[3].dev') X/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for X`map_devs[3]') X/usr/src/sys/dev/harp/if_harp.c:132: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:132: (near initialization for X`map_devs[4]') X/usr/src/sys/dev/harp/if_harp.c:134: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:134: (near initialization for X`map_devs[5]') X/usr/src/sys/dev/harp/if_harp.c:136: `DEV_FORE_LE25' undeclared here (not in a Xfunction) X/usr/src/sys/dev/harp/if_harp.c:136: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:136: (near initialization for X`map_devs[6].dev') X/usr/src/sys/dev/harp/if_harp.c:136: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:136: (near initialization for X`map_devs[6]') X/usr/src/sys/dev/harp/if_harp.c:138: `DEV_FORE_LE155' undeclared here (not in Xa function) X/usr/src/sys/dev/harp/if_harp.c:138: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:138: (near initialization for X`map_devs[7].dev') X/usr/src/sys/dev/harp/if_harp.c:138: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:138: (near initialization for X`map_devs[7]') X/usr/src/sys/dev/harp/if_harp.c:140: `DEV_IDT_25' undeclared here (not in a Xfunction) X/usr/src/sys/dev/harp/if_harp.c:140: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:140: (near initialization for X`map_devs[8].dev') X/usr/src/sys/dev/harp/if_harp.c:140: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:140: (near initialization for X`map_devs[8]') X/usr/src/sys/dev/harp/if_harp.c:142: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:142: (near initialization for X`map_devs[9]') X/usr/src/sys/dev/harp/if_harp.c:144: `VENDAPI_IDT_2' undeclared here (not in a Xfunction) X/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for X`map_devs[10].api') X/usr/src/sys/dev/harp/if_harp.c:144: `DEV_IDTABR_25' undeclared here (not in a Xfunction) X/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for X`map_devs[10].dev') X/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for X`map_devs[10]') X/usr/src/sys/dev/harp/if_harp.c:146: `VENDAPI_IDT_2' undeclared here (not in a Xfunction) X/usr/src/sys/dev/harp/if_harp.c:146: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:146: (near initialization for X`map_devs[11].api') X/usr/src/sys/dev/harp/if_harp.c:146: `DEV_IDTABR_155' undeclared here (not in Xa function) X/usr/src/sys/dev/harp/if_harp.c:146: initializer element is not Xconstant/usr/src/sys/dev/harp/if_harp.c:146: (near initialization for X`map_devs X X- -Tom X- -- XDeath is merciful, for there is no return Xtherefrom, but with him who has come back Xout of the nethermost chambers of night, Xhaggard and knowing, peace rests nevermore X- -Lovecraft X-BEGIN PGP SIGNATURE- XVersion: GnuPG v1.2.2 (FreeBSD) X XiD8DBQE/HKwQ4yFLRHBUZMwRAtAKAKC+DXMotlpa/s7c5R50WfvFneQ/HQCgkH9e Xw/az+o+YtNHT95L9apqLPq8= X=Kewt X-END PGP SIGNATURE- X X___ X[EMAIL PROTECTED] mailing list Xhttp://lists.freebsd.org/mailman/listinfo/freebsd-current XTo unsubscribe, send any mail to [EMAIL PROTECTED] X -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees
Re: [-CURRENT tinderbox] failure on i386/i386
On Sun, 20 Jul 2003, Peter Wemm wrote: PWTinderbox wrote: PW PW gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/cat PWgets.3 catgets.3.gz PW Segmentation fault (core dumped) PW *** Error code 139 PW PWThese false alarms are wearing a bit thin. Is there a problem with the PWtinderbox build machine perhaps? This seems to be a real bug. There was a discussion on sparc64 Tinderbox coredumps recently. I see the same problem when doing 'make universe' about one third of the kernels or buildworlds fail with a make dumping core in vfork() (according to gdb). I had no chance yet to try with a make that uses fork() instead of vfork(). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP problem with uma_zalloc
On Sat, 19 Jul 2003, Bosko Milekic wrote: BM BMOn Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara Harti Brandt wrote: BM[...] BM Well the problem is, that nothing is starved. I have an idle machine and BM a zone that I have limited to 60 or so items. When allocating the 2nd BM item I get block on the zone limit. Usually I get unblocked whenever I BM free an item. This will however not happen, because I have neither BM reached the limit nor is there memory pressure in the system to which I BM could react. I simply may be blocked forever. BM BM UMA_ZFLAG_FULL is set on the zone prior to the msleep(). This means BM that the next free will result in your wakeup, as the next free will BM be sent to the zone internally, and not the pcpu cache. But there is no free to come. To explain where we have the problem: the HARP ATM code uses a zone in the IP code to allocate control blocks for VCCs. The zone is limited to 100 items which evaluates to 1 page. When I start an interface, first the signalling vcc=5 is opened. This allocates one item from the zone, all the other items go into the CPU cache. Next I start ILMI. ILMI tries to open its vcc=16. While this works on UP machines (the zone allocator will find a free item in the CPU cache), on my 2-proc machine half of the time ILMI gets blocked on the zonelimit. And it blocks there forever, because, of course nobody is going to free the one and only allocated item. On a four processor machine the blocking probability will be 75%. So in order to be able to get out N items from a zone (given that there is no shortage of memory) one has to set the limit to N + nproc * items_per_allocation, which one cannot do because he doesn't know items_per_allocation. harti BM That makes the limit feature for zones rather useless, because I cannot BM predict how many of the items I can really allocate (this depends on the BM number of processors, the page size and the configuration of UMA itself). BM BM Perhaps we could make the behaviour dependent on the maximum number of BM items. When it is rather low (a couple of pages worth) and I would block BM on the zone limit and I have free items in another CPU's cache then BM drain one of the caches. BM BM Or I could simply remove the limits. BM BM BM harti BM BM BM BM BM -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP problem with uma_zalloc
On Mon, 21 Jul 2003, Bosko Milekic wrote: BM BMOn Mon, Jul 21, 2003 at 09:03:00AM +0200, Harti Brandt wrote: BM On Sat, 19 Jul 2003, Bosko Milekic wrote: BM BM BM BM BMOn Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara Harti Brandt wrote: BM BM[...] BM BM Well the problem is, that nothing is starved. I have an idle machine and BM BM a zone that I have limited to 60 or so items. When allocating the 2nd BM BM item I get block on the zone limit. Usually I get unblocked whenever I BM BM free an item. This will however not happen, because I have neither BM BM reached the limit nor is there memory pressure in the system to which I BM BM could react. I simply may be blocked forever. BM BM BM BM UMA_ZFLAG_FULL is set on the zone prior to the msleep(). This means BM BM that the next free will result in your wakeup, as the next free will BM BM be sent to the zone internally, and not the pcpu cache. BM BM But there is no free to come. To explain where we have the problem: BM BM the HARP ATM code uses a zone in the IP code to allocate control blocks BM for VCCs. The zone is limited to 100 items which evaluates to 1 page. BM When I start an interface, first the signalling vcc=5 is opened. This BM allocates one item from the zone, all the other items go into the CPU BM cache. Next I start ILMI. ILMI tries to open its vcc=16. While this works BM on UP machines (the zone allocator will find a free item in the CPU BM cache), on my 2-proc machine half of the time ILMI gets blocked on the BM zonelimit. And it blocks there forever, because, of course nobody is going BM to free the one and only allocated item. On a four processor machine the BM blocking probability will be 75%. BM BM So in order to be able to get out N items from a zone (given that there is BM no shortage of memory) one has to set the limit to N + nproc * BM items_per_allocation, which one cannot do because he doesn't know BM items_per_allocation. BM BM It sounds to me like your example is really not the general-case one. BM Basically, you're using a zone capped off at 1 page. Currently in BM UMA, this is the size of the slab. So, basically, you have this whole BM zone (with all associated overhead) so as to serve a maximum of only BM one slab. This defeats most of the assumptions made when the zone is BM created with PCPU caches. The zone maximum exists to prevent more BM than the specified amount of resources to be allocated toward the BM given zone; I don't think that the intention was to ensure that if BM the maximum items aren't allocated, there will always be one BM available, despite the fact that that is the effective behavior on BM UP. BM BM The solution to your really small zone problem is to either make the BM zone bigger, or to hack at UMA to export the UMA_ZONE_INTERNAL API BM properly so that you can skip the pcpu caches for all allocations and BM go straight to the zone. I'd suggest that you make the zone bigger, BM unless there's a Really Good reason not to. I think I take two paths: for stuffs like VCC where there may be a large number I will just remove the limit. The limits were a leftover when the ATM code had its own memory pool code. For stuff where there is a high probability that only a handful (usually 1 or 2) of them will be allocated (network interfaces) I will try to make it to use malloc(). How do you think about adding a paragraph for uma_zone_set_max to the man page?: An upper limit of items in the zone can be specified with a call to uma_zone_set_max. This limits the total number of items which includes: allocated items, free items and free items in the per-cpu caches. On systems with more than one CPU it may not be possible to allocate the specified number of items, because all of the remaining free items may be in the caches of the other CPUs when the limit is hit. Regards, harti BM BM In mb_alloc (for mbufs) I had implemented something that in this sort BM of scenario would dip into the other caches and transfer over what I BM called a bucket to the current cpu cache. Although in this BM scenario, it seems like that sort of solution would do what you want, BM some more thought into its behavior reveals that in fact it pessimizes BM the situation. To give you a better idea, let's consider what happens BM in this specific scenario, where a bucket would be all of a page. BM The allocator would make an attempt to allocate from its pcpu cache BM but would find it empty, so it would then attempt to steal a bucket BM from the second cpu's cache. There, it would find the bucket, move it BM to its cpu's cache, and grab an item from it. However, a thread on BM the second cpu may then attempt to grab an item, and the bucket will BM just ping-pong from pcpu cache to pcpu cache; the problem that the BM allocator was trying to solve for such really small zones was in fact BM still there - because of the general assumptions made in the design BM with respect to the size of most zones
Re: SMP problem with uma_zalloc
On Mon, 21 Jul 2003, Bosko Milekic wrote: BM A. Given the explanation, the small size of the limits makes a BM lot more sense now. Previously, the limit probably enforced the BM actual number of cached (pre-allocated) items in the pool. So, it was BM more than just a limit, it was a cache size parameter. That is BM probably why its size was kept relatively small. In the zone setting, BM the limit can easily be made larger or removed altogether (if there is BM no danger of that structure consuming all of kernel memory). No, there isn't. VCCs are usually limited by the interface card to a couple of thousand. BM How do you think about adding a paragraph for uma_zone_set_max to the man BM page?: BM BM An upper limit of items in the zone can be specified with a call to BM uma_zone_set_max. This limits the total number of items which includes: BM allocated items, free items and free items in the per-cpu caches. On BM systems with more than one CPU it may not be possible to allocate the BM specified number of items, because all of the remaining free items may BM be in the caches of the other CPUs when the limit is hit. BM BM Given that it has obviously led to confusion, this sort of change to BM the man page would be encouraging. BM BM Perhaps you would also ammend to it the purpose of uma_zone_set_max(), BM as it currently stands: BM BM The purpose of uma_zone_set_max() is to limit the maximum BM amount of memory that the system can dedicate toward the zone BM specified by the 'zone' argument. insert your text from above here BM BM Would you like to commit the change? Ok, I'll commit it. Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP problem with uma_zalloc
Bosko Milekic wrote: On Fri, Jul 18, 2003 at 07:05:58PM +0200, Harti Brandt wrote: Hi all, it seems there is a problem with the zone allocator in SMP systems. I have a zone, that has an upper limit on items that resolves to an upper limit of pages of 1. It turns out, that allocations from this zone get stuck from time to time. It seems to me, that the following happens: - on the first call to uma_zalloc a page is allocated and all the free items are put into the cache of the CPU. uz_free of the zone is 0 and uz_cachefree holds all the free items. - when the next call to uma_zalloc occurs on the same CPU, everything is fine. uma_zalloc just gets the next item from the cache. - when the call happens on another CPU, the code finds uz_free to be 0 and checks the page limit (uma_core.c:1492). It finds the limit already reached and puts the process to sleep (uma_zalloc was called with M_WAITOK). - the process may sleep there forever (depending on circumstances). If M_WAITOK is not set, the code will falsely return NULL while there are still free items (albeight in the cache of another CPU). I wonder whether this is intended behaviour. If yes, this should be definitely documented. uma_zone_set_max() seems to be documented only in the header file and it does not mention, that free items may not actually be allocatable because they happen to sit in another CPU's cache. If it is not intended (I would prefer this), I wonder how one can get the items out of another's CPU cache. I'm not too familiar with this code. I suppose this should be done somewhere around uma_core.c:1485? Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] If the per-cpu caches are relatively small (which they ought to be, especially when you've hit a maximum number of allocations from the zone), then this is actually not that bad of a behavior. I spoke to Jeff about this and it seemed to me that he was leaning toward keeping the behavior this way and, in fact, also perhaps _not_ even doing an internal free to the zone when UMA_ZFLAG_FULL is in effect but we still have space in the pcpu cache. While I'm not sure if going that far is a good idea, I _don't_ really think that the current behavior is a bad idea. As mentionned, when you have a zone that is mostly starved, all future frees will go back to the zone and not the per-cpu caches, but if you have some free items in another per-cpu cache, you're not likely to hit a starvation situation unless something is horribly wrong. And having the free code actually drain the per-cpu caches in a zone-full situation may lead to bad behavior under heavy load. Think about what happens under heavy load... your zone is starved and if you then flush all the pcpu caches and the load is still heavy, you're likely to have other threads try to allocate anyway, so they'll end up having to dip into the zone anyway; therefore, there doesn't seem to be much of a reason to push the cached objects back into the zone (if they're going to leave it again soon anyway). Well the problem is, that nothing is starved. I have an idle machine and a zone that I have limited to 60 or so items. When allocating the 2nd item I get block on the zone limit. Usually I get unblocked whenever I free an item. This will however not happen, because I have neither reached the limit nor is there memory pressure in the system to which I could react. I simply may be blocked forever. That makes the limit feature for zones rather useless, because I cannot predict how many of the items I can really allocate (this depends on the number of processors, the page size and the configuration of UMA itself). Perhaps we could make the behaviour dependent on the maximum number of items. When it is rather low (a couple of pages worth) and I would block on the zone limit and I have free items in another CPU's cache then drain one of the caches. Or I could simply remove the limits. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
GS_FONTPATH=/usr/local/share/ghostscript/fonts:/home/share/ghostscript/fonts mdpath = /usr/obj/test/base/usr/test/base/usr.bin/from, '\0' repeats 978 times obpath = '\0' repeats 1023 times cdpath = /usr/test/base/usr.bin/from, '\0' repeats 996 times machine = 0xbfbffaf7 i386 machine_arch = 0xbfbff9c9 i386 machine_cpu = 0x8078fb5 i386 ---Type return to continue, or q return to quit--- sysMkPath = (struct Lst *) 0x80a5a20 cp = 0x8078fba alpha start = 0xf15 Address 0xf15 out of bounds syspath = /usr/share/mk #7 0x08048131 in _start () No symbol table info available. (gdb) quit Script done on Thu Jul 17 09:54:58 2003 + /etc/malloc.conf - ja I have no idea how a program can core in vfork(). Probably a vm problem? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration
Hi,
here is a somewhat crude hack, that makes the warning go away. It just
prevents the warning if the shadowed symbol is a function and its source
file happens to be built-in. Once a real declaration is seen (as in
math.h) the source file will be the real source file of the declaration
and the warning is emitted. There are sure better ways to do something
like this... And, well, I did not make a world, just checked the example
program.
harti
Index: c-decl.c
===
RCS file: /home/ncvs/src/contrib/gcc/c-decl.c,v
retrieving revision 1.8
diff -u -r1.8 c-decl.c
--- c-decl.c11 Jul 2003 05:11:14 - 1.8
+++ c-decl.c17 Jul 2003 11:33:00 -
@@ -1637,7 +1637,9 @@
shadow_warning (a previous local, name, oldlocal);
}
else if (IDENTIFIER_GLOBAL_VALUE (name) != 0
- IDENTIFIER_GLOBAL_VALUE (name) != error_mark_node)
+ IDENTIFIER_GLOBAL_VALUE (name) != error_mark_node
+ (!FUNCTION_TYPE_CHECK(IDENTIFIER_GLOBAL_VALUE(name)) ||
+ strcmp(DECL_SOURCE_FILE(IDENTIFIER_GLOBAL_VALUE(name)), built-in)
!= 0))
shadow_warning (a global declaration, name,
IDENTIFIER_GLOBAL_VALUE (name));
}
On Wed, 16 Jul 2003, Jun Kuriyama wrote:
JKAt Tue, 15 Jul 2003 11:54:06 -0700,
JKDavid O'Brien wrote:
JK Much, much better if you can point to the specific GCC source code file
JK where this is handled.
JK
JKMay this help you?
JK
JK
JKwaterblue% cat exp.c
JKint
JKmain(int argc, char** argv)
JK{
JK int exp = 5;
JK
JK return 0;
JK}
JKwaterblue% cc -Wshadow -c exp.c
JKexp.c: In function `main':
JKexp.c:4: warning: declaration of `exp' shadows a global declaration
JKbuilt-in:0: warning: shadowed declaration is here
JK
JK
JK
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
Is there any specific reason that the sparc64 tinderbox permanently dumps core? I have no problem here to build world on my sparcs. harti On Mon, 14 Jul 2003, Tinderbox wrote: TTB --- 2003-07-14 11:12:19 - starting CURRENT tinderbox run for sparc64/sparc64 TTB --- 2003-07-14 11:12:19 - checking out the source tree TTB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TTB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TTB --- 2003-07-14 11:14:29 - building world TTB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TTB --- /usr/bin/make -B buildworld T Building an up-to-date make(1) T Rebuilding the temporary build tree T stage 1: legacy release compatibility shims T stage 1: bootstrap tools T stage 2: cleaning up the object tree T stage 2: rebuilding the object tree T stage 2: build tools T stage 3: cross tools T stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include T stage 4: building libraries T stage 4: make dependencies T stage 4: building everything.. T[...] Tgzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/getnetent.3 getnetent.3.gz Tgzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/getprotoent.3 getprotoent.3.gz Tgzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/getservent.3 getservent.3.gz Tgzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/hesiod.3 hesiod.3.gz Tgzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/if_indextoname.3 if_indextoname.3.gz Tgzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/inet.3 inet.3.gz Tgzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/inet_net.3 inet_net.3.gz TBus error (core dumped) T*** Error code 138 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib. T*** Error code 1 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. T*** Error code 1 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. T*** Error code 1 T TStop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TTB --- 2003-07-14 11:53:19 - /usr/bin/make returned exit code 1 TTB --- 2003-07-14 11:53:19 - ERROR: failed to build world TTB --- 2003-07-14 11:53:19 - tinderbox aborted T T___ T[EMAIL PROTECTED] mailing list Thttp://lists.freebsd.org/mailman/listinfo/freebsd-current TTo unsubscribe, send any mail to [EMAIL PROTECTED] T___ T[EMAIL PROTECTED] mailing list Thttp://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 TTo unsubscribe, send any mail to [EMAIL PROTECTED] T -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Tue, 15 Jul 2003, Marcel Moolenaar wrote: MMOn Tue, Jul 15, 2003 at 09:00:17PM +0200, Dag-Erling Sm?rgrav wrote: MM MM There's not much more I can say about it until I see the full MM log from the next run; the last one broke at a different point. MM MMThe first question is: what process is dumping core. I think MMyou'll find that with dmesg(8). For more than one week the sparc build dumps core at different points while compressing man pages. Perhaps a gzip problem? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Tue, 15 Jul 2003, Thomas Moestl wrote: TMOn Tue, 2003/07/15 at 12:04:56 -0700, Marcel Moolenaar wrote: TM On Tue, Jul 15, 2003 at 09:00:17PM +0200, Dag-Erling Sm?rgrav wrote: TM Marcel Moolenaar [EMAIL PROTECTED] writes: TM It needs to be analyzed because cross-builds should not fail. Do TM we have a machine problem? What exactly is dumping core? Is it TM gzip or some binary started immediately after it? If it's gzip, TM is there a relation with the recent compiler warning about strncmp? TM TM It's not a machine problem if it only happens to the sparc64 build - TM the same machine runs all the other -CURRENT tinderboxen except TM powerpc. TM TM It does not only happen to sparc64. I've seen it fail for all but TM i386 and pc98, I think. TM TMi386 and pc98 have failed too (random example: July 5). But sparc64 fails quite regularily when gziping man pages. The others are more random. Since about the same time I have dumping core make during make universe on my i386. The core shows differnt signals (4, 10, even SIGILL), but always in vfork(). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration
On Tue, 15 Jul 2003, Jun Kuriyama wrote:
JK
JKWith new gcc and -Wshadow, src/bin/ed/re.c shows this warning:
JK
JKcc -Wshadow -c re.c
JKre.c: In function `get_compiled_pattern':
JKre.c:44: warning: declaration of `exp' shadows a global declaration
JKbuilt-in:0: warning: shadowed declaration is here
JK
JKIt seems local variable exp is conflicted with exp(3) declaration. I
JKdon't know what name should be used...
I would call this a compiler bug. It shouldn't declare exp(3) when you
don't include math.h. As I understand the standard the names in math.h are
only reserved when you include math.h. I remember that an earlier version
of gcc had this bug, that was fixed then. Probably they unfixed it again.
What's the chance of getting this fixed?
harti
JK
JK
JKIndex: re.c
JK===
JKRCS file: /home/ncvs/src/bin/ed/re.c,v
JKretrieving revision 1.19
JKdiff -u -r1.19 re.c
JK--- re.c 30 Jun 2002 05:13:53 - 1.19
JK+++ re.c 14 Jul 2003 23:42:41 -
JK@@ -41,7 +41,7 @@
JK pattern_t *
JK get_compiled_pattern(void)
JK {
JK-static pattern_t *exp = NULL;
JK+static pattern_t *expr = NULL;
JK static char error[1024];
JK
JK char *exps;
JK@@ -52,27 +52,27 @@
JK errmsg = invalid pattern delimiter;
JK return NULL;
JK } else if (delimiter == '\n' || *++ibufp == '\n' || *ibufp == delimiter) {
JK-if (!exp)
JK+if (!expr)
JK errmsg = no previous pattern;
JK-return exp;
JK+return expr;
JK } else if ((exps = extract_pattern(delimiter)) == NULL)
JK return NULL;
JK /* buffer alloc'd not reserved */
JK-if (exp !patlock)
JK-regfree(exp);
JK-else if ((exp = (pattern_t *) malloc(sizeof(pattern_t))) == NULL) {
JK+if (expr !patlock)
JK+regfree(expr);
JK+else if ((expr = (pattern_t *) malloc(sizeof(pattern_t))) == NULL) {
JK fprintf(stderr, %s\n, strerror(errno));
JK errmsg = out of memory;
JK return NULL;
JK }
JK patlock = 0;
JK-if ((n = regcomp(exp, exps, 0))) {
JK-regerror(n, exp, error, sizeof error);
JK+if ((n = regcomp(expr, exps, 0))) {
JK+regerror(n, expr, error, sizeof error);
JK errmsg = error;
JK-free(exp);
JK-return exp = NULL;
JK+free(expr);
JK+return expr = NULL;
JK }
JK-return exp;
JK+return expr;
JK }
JK
JK
JK
JK
JK
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/shm
Hi, I'm not sure, whether this mailing list is the correct place for linux-centered discussions. Perhaps you want to continue via private mail? Regards, harti On Mon, 7 Jul 2003, Dan Nelson wrote: DNIn the last episode (Jul 07), Matthias Andree said: DN Marcin Dalecki schrieb am 2003-07-07: DN Matthias Andree wrote: DN Update your Linux top or run fewer processes on it then. :- DN DN You know that file system name lookup is one of the most expensive DN system calls under UNIX? DN DN So what? If you don't like the interface because it does ever so DN expensive file system lookups (I wonder what's so expensive if no DN disk drive latencies are involved), suggest a better one and donate DN an implementation. DN DN I'm sure I'd find disadvantages of non-Linux top if I only cared to DN look. I don't. It works when I need it, it's not in my way otherwise, DN that's as much as I care. DN DNThere is already a functional non-procfs implementation that has been DNaround long before procps top: groupsys top 3.5b12 (i.e. the top that DNall other non-Linux systems use) compiles fine on even the newest Linux DNkernels with the attached patch. It's one of the first things I build DNon a new Linux box. Procps top is way too slow; it takes a full 5 DNseconds just for the first screen refresh on a mostly-idle box with 400 DNprocesses. groupsys top is basically instantaneous. And don't think DNabout accidentally hitting a cursor or function key which running DNprocps top; it doesn't even use curses, so it beeps and waits 2 seconds DNfor each character in the escape sequence :) DN DN -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Does newreno work as designed ?
On Fri, 4 Jul 2003, Jeffrey Hsu wrote: JH I've had to disable newreno on my machines as well. JH have a wireless link to a DSL line, and I get much better JH performance when I do that. JH JHI would go test wireless links, but if_wi stopped working for my notebook. After updating the firmware on my to 8.72.1 it works for me again, albeit with a warning message. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lucent firmware
On Fri, 4 Jul 2003, Jeffrey Hsu wrote: JHMy card says JH JH wi0: using Lucent Embedded WaveLAN/IEEE JH wi0: Lucent Firmware: Station (6.16.1) JH JHFull information on the machine available at JH http://people.freebsd.org/~hsu/vx88 JH JHThis may be a different make from your chipset. JHI didn't find any firmware upgrades on the Lucent site. JH JHThis stopped working for me some time between the beginning JHof Feb and last week. (I didn't have access to the notebook JHbetween those times.) JH My card says now wi0: Lucent firmware: Station (8.72.1) after the update. I found the firmware at www.agere.com. Look for a file called wsuags454c-872.zip. This contains WSU10872.EXE. You need a windows for this (maybe a dos does it). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't connect to wireless network with recent -CURRENT
On Thu, 3 Jul 2003, Greg 'groggy' Lehey wrote: GgLI've just upgraded my laptop to a recent -CURRENT, and since then I've GgLbeen having a lot of network problems. Here's a rough chronology: GgL GgL- Machine is a Dell Inspiron 7500, which I've been using with releases GgL 4 and 5 of FreeBSD without problems for the last 3 years. It's GgL usually connected to my house 802.11b network, which is run by an GgL old 486 in ad-hoc mode, no WEP. I use DHCP to set up the GgL connection. GgL GgL- Things worked fine up to my last kernel: GgL GgL Jun 26 14:03:43 kondoparinga kernel: FreeBSD 5.0-CURRENT #0: Sun May 11 13:25:03 CST 2003 GgL GgL- On 28 June, I upgraded to the then -CURRENT. I had a lot of trouble GgL getting things working, including the following from the gateway GgL machine: GgL GgL Jun 29 09:35:15 air-gw dhcpd: DHCPREQUEST for 192.109.197.199 from 00:02:2d:04:09:3a via wi0 GgL Jun 29 09:35:15 air-gw dhcpd: DHCPACK on 192.109.197.199 to 00:02:2d:04:09:3a via wi0 GgL Jun 29 09:35:16 air-gw dhcpd: DHCPDECLINE on 192.109.197.199 from 00:02:2d:04:09:3a via wi0 GgL Jun 29 09:35:16 air-gw dhcpd: Abandoning IP address 192.109.197.199: declined. GgL Jun 29 09:35:16 air-gw dhcpd: DHCPDISCOVER from 00:02:2d:04:09:3a via wi0 GgL Jun 29 09:35:16 air-gw dhcpd: DHCPOFFER on 192.109.197.199 to 00:02:2d:04:09:3a via wi0 GgL GgL Nothing was mentioned in the log files on the laptop. GgL GgL- I managed to connect, however, and things worked for a while, but GgL the machine kept freezing. I tried with a 100 Mb/s Ethernet card, GgL and it had problems too. With both network cards, it reported GgL various error messages which I didn't write down because I thought GgL they would be logged; unfortunately they weren't. The one from wi0 GgL is still occurring: GgL GgL wi0: bad alloc 3b4 != ff, cur 0 nxt 0 GgL GgL- I built a new kernel and world on 1 July. Since then I haven't had GgL any trouble with the system freezing up, but and was no longer able GgL to connect at all with the wireless card. After booting, I get: GgL GgL wi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 GgLinet6 fe80::202:2dff:fe04:93a%wi0 prefixlen 64 scopeid 0x3 GgLinet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 GgLether 00:02:2d:04:09:3a GgLmedia: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) GgLstatus: associated GgLssid Netname 1:Netname GgLstationname FreeBSD WaveLAN/IEEE node GgLchannel 3 authmode OPEN powersavemode OFF powersavesleep 100 GgLwepmode OFF weptxkey 1 GgL GgL However, no traffic comes through. GgL GgLIt's pretty clear that it's this laptop: I have other machines on the GgLnet which work without problems, and this machine also works if I boot GgLit with 4.8-STABLE. GgL GgLAny thoughts? I think the same problem was reported by Rob Holmes two weeks ago and by me (although with lesser detail) yesterday. I converted my kernel from OLDBUS to NEWBUS and now one out of four or five tries the card works, but this is really annoying. I have an Inspiron 8200 and an Avaya (that is a Lucent) card. I have found no solution until now. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: WLAN card not working anymore
On Thu, 3 Jul 2003, M. Warner Losh wrote: MWLIn message: [EMAIL PROTECTED] MWLHarti Brandt [EMAIL PROTECTED] writes: MWL: my Avaya Wireless PC Card (actually seems to be a Lucent) stopped to MWL: work in my laptop as I updated the kernel today. It now says pcic0: Card MWL: type unrecognized by bridge is unsupported.. What does this mean and what MWL: can I do about it? MWL MWLWhat did you upgrad from and to? From -CURRENT from june 12th to yesterday's -CURRENT. I have now made a newcard kernel instead of oldcard. The card is recogniced but four out of five times I try to configure it (via dhcp) it doesn't work. I get usually the following: Jul 3 09:18:29 harti kernel: wi0: Avaya Communication Avaya Wireless PC Card at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 Jul 3 09:18:29 harti kernel: wi0: 802.11 address: 00:02:2d:42:a2:d7 Jul 3 09:18:29 harti kernel: wi0: using Lucent Technologies, WaveLAN/IEEE Jul 3 09:18:29 harti kernel: wi0: Lucent Firmware: Station (7.52.1) Jul 3 09:18:29 harti kernel: wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps Jul 3 09:19:18 harti kernel: wi0: bad alloc 1f9 != 1f6, cur 0 nxt 0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_cmd 0x0002; event status 0x8080 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_cmd 0x0121; event status 0x8080 Jul 3 09:19:19 harti kernel: wi0: wi_cmd: busy bit won't clear. Jul 3 09:19:19 harti last message repeated 2 times - card ejected Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc03/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc04/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc01/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc09/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc07/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc83/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc06/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc25/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc84/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc0e/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc85/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc20/0 Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc80/0 Jul 3 09:19:19 harti kernel: wi0: wi_cmd: busy bit won't clear. Jul 3 09:19:19 harti kernel: wi0: failed to allocate 2372 bytes on NIC Jul 3 09:19:19 harti kernel: wi0: tx buffer allocation failed (error 12) Jul 3 09:19:19 harti kernel: wi0: interface not running Jul 3 09:19:19 harti kernel: Sleeping for 10ms in wi_stop Jul 3 09:19:19 harti last message repeated 49 times Jul 3 09:19:19 harti kernel: wi0: wi_cmd: busy bit won't clear. Jul 3 09:19:19 harti kernel: wi0: timeout in wi_seek to fc80/0 Jul 3 09:19:20 harti kernel: wi0: detached Jul 3 09:19:20 harti dhclient: send_packet: No route to host Jul 3 09:19:20 harti dhclient: receive_packet failed on wi0: No route to host When it works it says: Jul 3 10:53:26 harti kernel: wi0: Avaya Communication Avaya Wireless PC Card at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 Jul 3 10:53:27 harti kernel: wi0: 802.11 address: 00:02:2d:42:a2:d7 Jul 3 10:53:27 harti kernel: wi0: using Lucent Technologies, WaveLAN/IEEE Jul 3 10:53:27 harti kernel: wi0: Lucent Firmware: Station (7.52.1) Jul 3 10:53:27 harti kernel: wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps Jul 3 10:53:45 harti dhclient: New Network Number: 195.37.78.0 Jul 3 10:53:45 harti dhclient: New Broadcast Address: 195.37.78.255 Jul 3 10:53:45 harti kernel: wi0: bad alloc 205 != 202, cur 0 nxt 0 Jul 3 10:53:45 harti dhclient: New IP Address (wi0): 195.37.78.200 Jul 3 10:53:45 harti dhclient: New Subnet Mask (wi0): 255.255.255.0 Jul 3 10:53:45 harti dhclient: New Broadcast Address (wi0): 195.37.78.255 Jul 3 10:53:45 harti dhclient: New Routers: 195.37.78.1 Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: WLAN card not working anymore
On Thu, 3 Jul 2003, Oliver Brandmueller wrote: OBHi. OB OBOn Thu, Jul 03, 2003 at 01:39:19PM +0200, Harti Brandt wrote: OB Jul 3 09:18:29 harti kernel: wi0: Lucent Firmware: Station (7.52.1) OB OBWell, I'm still seeing problems with my Lucent Card on -CURRENT (there OBwere postings here about that earlier, but Ican't provide details at the OBmoment as I don't have time to test - sorry Sam, Warner). OB OBMaybe you should try updating to the latest Firmware of the card, which OBis 8.10.1 at Lucent. That fixed a lot of problems for a friend of mine OB(at least under -STABLE some time ago). As soon as you have the latest OBStation Firmware in the card rerun your tests. Took me a while to find the firmware. I finally managed to find it at www.agere.com. Updating to 8.72.1 seems to cure the problem. There are only two messages left that seem to be harmless: Jul 3 16:08:59 harti kernel: wi0: Avaya Communication Avaya Wireless PC Card at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 Jul 3 16:08:59 harti kernel: wi0: 802.11 address: 00:02:2d:42:a2:d7 Jul 3 16:08:59 harti kernel: wi0: using Lucent Technologies, WaveLAN/IEEE Jul 3 16:08:59 harti kernel: wi0: Lucent Firmware: Station (8.72.1) Jul 3 16:08:59 harti kernel: wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ! Jul 3 16:09:05 harti kernel: wi0: bad alloc 204 != 201, cur 0 nxt 0 Jul 3 16:09:09 harti dhclient: New Network Number: 195.37.78.0 Jul 3 16:09:09 harti dhclient: New Broadcast Address: 195.37.78.255 ! Jul 3 16:09:09 harti kernel: wi0: bad alloc 208 != 205, cur 0 nxt 0 Thanks, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't connect to wireless network with recent -CURRENT
On Thu, 3 Jul 2003, M. Warner Losh wrote: MWLIn message: [EMAIL PROTECTED] MWLHarti Brandt [EMAIL PROTECTED] writes: MWL: I think the same problem was reported by Rob Holmes two weeks ago and by MWL: me (although with lesser detail) yesterday. I converted my kernel from MWL: OLDBUS to NEWBUS and now one out of four or five tries the card works, but MWL: this is really annoying. I have an Inspiron 8200 and an Avaya (that is a MWL: Lucent) card. I have found no solution until now. MWL MWLThe lucent problem is well known and has been known for a long time. MWLIt was broken between 5.0 and 5.1 for some people with lucent cards MWL(not me and mine). Enabling WITNESS seens to help, but that likely MWLmeans that it is a race that the overhead of WITNESS tickles in MWLcertain ways. Sam indicated he'd try to find some time to fix it. MWLThere's something subtle going on with the lucent cards, and I've MWLgiven up trying to find it. I just do't have the time. Updating the firmware from www.agere.com to 8.72.1 has cured the problem (except for two messages from the kernel): Jul 3 16:09:05 harti kernel: wi0: bad alloc 204 != 201, cur 0 nxt 0 Jul 3 16:09:09 harti kernel: wi0: bad alloc 208 != 205, cur 0 nxt 0 harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
WLAN card not working anymore
Hi, my Avaya Wireless PC Card (actually seems to be a Lucent) stopped to work in my laptop as I updated the kernel today. It now says pcic0: Card type unrecognized by bridge is unsupported.. What does this mean and what can I do about it? Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: world build fails since yesterday
On Thu, 26 Jun 2003, peter wrote: pHi p pI receive signals 4, 10, and 11 during my buildworlds. Just put in panother PSU: same problem. Checking memory next... I had such problems on a dual-proc Asus board. After reducing the DDR speed a little bit (233MHz, I think, instead of 256MHz), everyting works just fine. harti p pChristoph Kukulies wrote: p pI tried to sync my source tree and build the world. Yesterday pworld build failed. Today it seemd to get further but still failed pwith signal 4 (SIGILL !?) p pcd /usr/include/fs/fdescfs; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done pcd /usr/include/fs/fifofs; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done pcd /usr/include/fs/msdosfs; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done pcd /usr/include/fs/ntfs; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done pcd /usr/include/fs/nullfs; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done p*** Signal 4 p p p-- pChris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de p___ p[EMAIL PROTECTED] mailing list phttp://lists.freebsd.org/mailman/listinfo/freebsd-current pTo unsubscribe, send any mail to [EMAIL PROTECTED] p p p p p p p p___ p[EMAIL PROTECTED] mailing list phttp://lists.freebsd.org/mailman/listinfo/freebsd-current pTo unsubscribe, send any mail to [EMAIL PROTECTED] p -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
nfs mounting from localhost
Hi all, is there a possibility to nfs mount a file system from localhost from rcNG? All the NFS server stuff seems to be started after NFS mounting. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs and /dev/fd/3
On Wed, 4 Jun 2003, Marc Olzheim wrote: MOHi. MO MOI've seen the question once before, but it was not answered (on-list ?), MOso now that I run in on it, I'd like to know what to do: MO MOOn FreeBSD 4.x, without devfs, the following worked: MO( echo foo | tee /dev/fd/3 | tr f F ) 31 MO MOIt should produce both foo and Foo MO MOFreeBSD 5 with devfs, however, does not create a /dev/fd/3 upon opening MOfiledescriptor 3 by the shell, so there's no device to write to... MO MOHow can I fix or circumvent this, aside from mounting a ufs partition MOwith mknod-ed files over /dev/fd ? You must mount -tfdescfs fdesc /dev/fd but your example doesn't work even then (although it gives no error). Don't know why. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, 28 May 2003, Marcin Dalecki wrote: MDScott Long wrote: MD Q wrote: MD MD Don't overreact. MD MD MD Heh. I live this hell every day with Linux in my day job. MD MD I'm not suggesting taking the linux approach of MD versioning every module. But rather allowing the loader or a module MD (most likely a 3rd part or from a port) the ability to make a decision MD based on some internal revision/date based version as to whether it is MD safe to proceed to load. MD MD MD Ideally, every API would be versioned, and developers would be careful MD to architect their work so that the interfaces would be stable and MD gratuitous incompatibilities would be avoided. Alas, that is not always MD the case. MD MDNO no and again no. This would repeat the same design mistake MDthat is already in Linux. On API level you DO NOT WANT versioning. MDWhat you really want is: type signature cheking. Like for example MDdone through C++ symbol mangling rules. If you can't do it like that MDthen better leave it off as it is. Versioning in itself Type signature checking doesn't help you if the semantics of an API change without type changes. APIs should be semantically and syntactically stable in -STABLE. In -CURRENT they are expected to change. Managing a 3rd party driver for current is a nightmare, but may no be necessary once we have a -STABLE based on FreeBSD5. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf LOR
On Wed, 2 Apr 2003, Bosko Milekic wrote: BM For what concerns DONTWAIT, you should theoretically be allowed to BM hold a driver lock. But again, there may be a problem. Specifically, BM I see that UMA code has some explicit Giant acquires/frees in certain BM places. When the UMA code gets called from the malloc() code while BM the bucket is being internally allocated in mb_alloc, you may be BM hitting one of those paths. In fact, unless you have a specific Giant BM acquire in the fxp_* routines you list in your trace below, that is BM undoubtedly what is happening because there are no explicit Giant BM acquires in the code path from m_getcl() to malloc(), so they must be BM happening higher up in the call stack. Well, that's interesting. A month ago or so I sent a patch to smp@ with an update to the malloc page documenting the locking requirements. I got only one response. I wonder, how people are expected to correctly use an API, when that API is poorly documented (malloc(9) in this case, but mbuf(9) does not mention 'lock' either). I would ask people knowing the topic to comment on this. As soon as this EC proposal nightmare is over, I may try to write a corresponding section for mbuf(9). Regards, harti Index: malloc.9 === RCS file: /home/ncvs/src/share/man/man9/malloc.9,v retrieving revision 1.30 diff -u -r1.30 malloc.9 --- malloc.924 Feb 2003 05:53:27 - 1.30 +++ malloc.917 Mar 2003 15:06:14 - @@ -147,44 +147,22 @@ to return .Dv NULL if the request cannot be immediately fulfilled due to resource shortage. -Otherwise, the current process may be put to sleep to wait for -resources to be released by other processes. -If this flag is set, -.Fn malloc -will return -.Dv NULL -rather than block. Note that .Dv M_NOWAIT -is defined to be 0, meaning that blocking operation is the default. -Also note that -.Dv M_NOWAIT is required when running in an interrupt context. -.Pp -Programmers should be careful not to confuse -.Dv M_NOWAIT , -the -.Fn malloc -flag, with -.Dv M_DONTWAIT , -an -.Xr mbuf 9 -allocation flag, which is not a valid argument to -.Fn malloc . .It Dv M_WAITOK -Indicates that it is Ok to wait for resources. It is unconveniently -defined as 0 so care should be taken never to compare against this value -directly or try to AND it as a flag. The default operation is to block -until the memory allocation succeeds. +Indicates that it is ok to wait for resources. +If the request cannot be immediately fulfilled the current process is put +to sleep to wait for resources to be released by other processes. The .Fn malloc , .Fn realloc , and .Fn reallocf -functions can only return +functions cannot return .Dv NULL if -.Dv M_NOWAIT +.Dv M_WAITOK is specified. .It Dv M_USE_RESERVE Indicates that the system can dig into its reserve in order to obtain the @@ -194,6 +172,12 @@ programming. .El .Pp +Exactly one of either +.Dv M_WAITOK +or +.Dv M_NOWAIT +must be specified. +.Pp The .Fa type argument is used to perform statistics on memory usage, and for @@ -244,11 +228,37 @@ While it should not be relied upon, this information may be useful for optimizing the efficiency of memory use. .Pp -Malloc flags documented above should -.Em NOT -be used with +Programmers should be careful not to confuse the malloc flags +.Dv M_NOWAIT +and +.Dv M_WAITOK +with the .Xr mbuf 9 -routines as it will cause undesired results. +flags +.Dv M_DONTWAIT +and +.Dv M_TRYWAIT . +.Sh LOCKING CONSIDERATIONS +.Fn malloc , +.Fn realloc +and +.Fn reallocf +may not be called from fast interrupts handlers. +When called from threaded interrupts +.Ar flag +must contain +.Dv M_NOWAIT . +.Pp +.Fn malloc , +.Fn realloc +and +.Fn reallocf +must not be called with +.Dv M_WAITOK +while a mutex other than Giant is held. +Giant may or may not be held when +.Fn free +is called. .Pp Any calls to .Fn malloc -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Removing Sendmail
On Wed, 2 Apr 2003, Dan Naumov wrote: DNOn Wed, 02 Apr 2003 14:29:30 -0500 (EST) DNJohn Baldwin [EMAIL PROTECTED] wrote: DN DN I find an odd situation here whenever this topic comes up. One the DN one hand, people are always wanting to split the entire base system DN up into small packages for each little piece of the base. On the DN other hand, one of FreeBSD's selling points in real-world environments DN is that it doesn't have a bunch of little packages for the base system DN like Linux distros. Do people really prefer something like having DN rpm's for /bin/ps to having one lump base dist for all of /bin, /sbin, DN etc.? DN DNIt really depends on where you draw the line. Personally, I'd rather DNhave a very minimal base system that's kept as a whole with additional DNpackages avaible for those who want them. Basically if I was to decide DNon such things, I'd throw out CVS, BIND, g77, GDB, OpenSSL, SendMail, DNgames and crypto out of base and making them avaible through ports. But DNthat's all IMHO and not very likely to happen to FreeBSD in my lifetime DN;) I hope so. I have two fears with regard to splitting up the system: things in ports will start to rot. Developers will 'make world' and this will just compile the basic stuff. People will forget about the packages. Second, the last time I tried Linux (this was a couple of years ago) I got immediatly tired of foo-X.Y needs libbar-A.B bar-Z.T needs libbar-C.D and unfortunately you cannot have libbar-A.B and libbar-C.D together. Splitting up without dependencies between the packages is likely to be very hard if not impossible. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum broken by devstat changes?
On Tue, 25 Mar 2003, Kenneth D. Merry wrote: KDMOn Wed, Mar 26, 2003 at 11:06:52 +1030, Greg 'groggy' Lehey wrote: KDM On Tuesday, 25 March 2003 at 18:44:03 +0100, Hartmut Brandt wrote: KDM KDM Hi, KDM KDM when calling 'vinum start' it responds with KDM KDM usage: read drive [drive ...] KDM KDM from looking at the code, it appears that it cannot find the disk drives KDM to read the configuration from. KDM KDM vinum read da0 da1 KDM KDM just works. KDM KDM So what's the problem? (kernel and user land from today) KDM KDM Check vinum(8), function vinum_start (in KDM /usr/src/sbin/vinum/commands.c). It's possible that the changes have KDM broken some of the tests, probably of stat-device_type. I can't KDM think it's too difficult to fix. KDM KDMdisk_create() now creates the devstat entry for disks, but defaults KDMeverything to be a direct access (with no interface type). KDM KDMI've got patches in progress to fix that, but it looks like things should KDMwork with the current state of affairs. KDM KDMHave you rebuilt world? That was just a fresh world and kernel. It took me some time to get it up again - the vinum partition holds the ports for my other machines. I just have no time to work on this... KDMIt looks like vinum(8) doesn't include a call to devstat_checkversion(), so KDMit's possible you've got a version mismatch but no way to know it. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAKEDEV(8) manpage
On Tue, 25 Mar 2003, Steve Kargl wrote: SKOn Tue, Mar 25, 2003 at 10:11:00AM +0100, Christian Brueffer wrote: SK On Mon, Mar 24, 2003 at 09:43:17PM +0200, Giorgos Keramidas wrote: SK On 2003-03-24 19:14, Christian Brueffer [EMAIL PROTECTED] wrote: SK I'll write a small manpage this evening which says that MAKEDEV is SK gone now with a short summary of what devfs does. Does that resolve SK your worries? SK SK If you write a detailed description of devfs please add it to devfs(5) SK and just replace the existing manpage of MAKEDEV with something like: SK SK The MAKEDEV script was deprecated by devfs(5) and geom(4) and SK removed from FreeBSD after GEOM became mandatory. Please see SK the devfs(5), devfs(8), geom(4) and mount_devfs(8) manpages for SK more details. SK SK This should be enough IMHO to point the reader to the right place. SK SK - Giorgos SK SK SK That was my original intent. I'm still uncertain if it would be better SK to write a small manpage or just create a MLINK to one of the devfs SK pages... SK SK SKAre you going to write a man page everytime a feature SKis deprecated? MAKEDEV is dead and gone. At most SKcreate the MLINK. MAKEDEV has been in unix since at least version 7. That's about 30 years. If you deprecate a feature, that has been on virtually all unices for 30 years, it makes sense. Each time I type 'man vnconfig' (I don't use mdconfig often enough to remember which is actual and which of it is not there anymore) I'm puzzled that the mdconfig man page pops up. In that case it is easy to understand, that the functionality is almost the same. If I type 'man MAKEDEV' and devfs pops up, I have to think much more to find out, that these are somehow related. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: =?x-unknown?q?Re=3A_world=40alpha_b=F8rken_in_libatm?=
On Tue, 25 Mar 2003, Fred Clift wrote: [SNIP] FC/usr/src/lib/libatm/ioctl_subr.c: In function `get_cfg_info': FC/usr/src/lib/libatm/ioctl_subr.c:395: warning: cast increases required FCalignment of target type FC/usr/src/lib/libatm/ioctl_subr.c: In function `get_intf_info': FC/usr/src/lib/libatm/ioctl_subr.c:433: warning: cast increases required FCalignment of target type FC*** Error code 1 FC FCStop in /usr/src/lib/libatm. FC FC FC-- FC FCThis file aparently hasn't been modified in 5 months. FC FC11 Hours ago, Makefile for this lib was modified to have FC FCWARNS?= 5 FC FCadded which seems to have revealed the problem. For those who just want FCto get a complete buildworld, remvoing this is all that is needed (well, FCfor this problem -- my buildworld is running right now...) FC FCAs for the real problem I'm about to see what can be done about it. I already contacted mdodd. One needs to get rid of caddr_t and replace it with void *. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
vinum broken by devstat changes?
Hi, when calling 'vinum start' it responds with usage: read drive [drive ...] from looking at the code, it appears that it cannot find the disk drives to read the configuration from. vinum read da0 da1 just works. So what's the problem? (kernel and user land from today) harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
On Sun, 2 Mar 2003, Jens Rehsack wrote:
JRBarney Wolff wrote:
JR This is an example of what I was pointing out:
JR
JR On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote:
JR ...
JR
JR@@ -1444,22 +1420,19 @@
JR *none- response sent
JR *
JR */
JR-void
JR-send_resp ( intf, Hdr, resp )
JR- int intf;
JR- Snmp_Header *Hdr;
JR- u_char *resp;
JR+static void
JR+send_resp ( const int intf, Snmp_Header *Hdr, char *resp )
JR {
JR int n;
JR
JR- if ( ilmi_fd[intf] 0 ) {
JR- n = write ( ilmi_fd[intf], (caddr_t)resp[1], resp[0] );
JR+ if ( ilmi_fd[intf] 0 ) { /* FIXME: does ilmi_fd[intf] exists? out of range?
*/
JR+ n = write ( ilmi_fd[intf], resp+1, resp[0] );
JR
JR ...
JR
JR Here's a case where it matters whether something is u_char or char.
JR write(2) takes a size_t as its third arg, and extension of a char to
JR that may not be the same as for u_char, for example on Sparc. If the
JR response is ever 127 bytes, this will fail. You're going to have to
JR look carefully at how things are used to see when char is appropriate
JR and when u_char is necessary.
JR
JR
JRThat is really right, but for those check I have to know more 'bout ATM,
JRright? I just have detected some compiler errors using
JR-finline-functions (yes, I'm playing with optimization options :-)). If
JRyou know a real good online-reference, one fine day I'll check it and
JRcheck the entire ilmid.c code for valid signment.
Go to www.atmforum.com and look at the Standards page. You will find the
ILMI 4.0 standard there. But beware, if you are not used to read
telecommunication standards, you will be confused :-)
For ILMI you will also need the relavant SNMP RFCs and, maybe, the ASN.1
doc (don't remember exactly should be one of the Z.* ITU-T standards).
harti
JR
JRJens
JR
JR
JRTo Unsubscribe: send mail to [EMAIL PROTECTED]
JRwith unsubscribe freebsd-current in the body of the message
JR
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Problem with M_COPY_PACKET
On Mon, 24 Feb 2003, Hiten Pandya wrote:
HPCraig Rodrigues (Mon, Feb 24, 2003 at 12:07:02PM -0500) wrote:
HP The code in question looks like:
HP =
HP struct mbuf *
HP copy_mbuf(struct mbuf *m)
HP {
HP struct mbuf *new;
HP
HP MGET(new, M_DONTWAIT, MT_DATA);
HP if(new == NULL)
HP return NULL;
HP if(m-m_flags M_PKTHDR)
HP M_COPY_PKTHDR(new, m);
HP
HPWhat you need, is m_dup_pkthdr(). M_COPY_PKTHDR has been
HPdeprecated for several reasons, that are outlined in the
HPcommit log of rev. 1.109 of sys/sys/mbuf.h.
I wrote that code. It must be a M_MOVE_PKTHDR, because m is just disposed
afterwards.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: busdma documentation
On Mon, 24 Feb 2003, Hiten Pandya wrote: HPHarti Brandt (Mon, Feb 24, 2003 at 11:41:57AM +0100) wrote: HP On Mon, 24 Feb 2003, Dag-Erling Smorgrav wrote: HP HP DSis there any? if so, where? HP HP Hiten Pandya was/is working on this. Last time I had a look it had not HP much moved from NetBSD towards FreeBSD. Don't know about the current HP state: HP HP [1] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.txt HP [2] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.patch HP HPI am still working on it, and the URLs provided above are old. The new HPURL to busdma documentation stuff, is: HP HP http://www.unixdaemons.com/~hiten/work/busdma/ HP HPThere are some issues I am sorting out, and you can check my progress HPwith the TODO list in the directory. It will be finished sometime this HPweek as I was busy last week with other things, like school etc. Just a comment: the alignment argument to bus_dma_tag_create is unfortunately not used in the way you describe. It is ignored, except when bus_dmamem_alloc calls contigmalloc on all architectures. And it is used if it is larger than an IOPAGE on sparc64. If you need a smaller aligment, you must either fiddle around with a larger memory allocation (if you are going to call bus_dmamem_alloc) or rely on the undocumented fact, that aligning the virtual address also aligns the physical address (for small alignments). The latter is true at least for all architectures that have no IOMMU and for sparc. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: busdma documentation
On Mon, 24 Feb 2003, Dag-Erling Smorgrav wrote: DSis there any? if so, where? Hiten Pandya was/is working on this. Last time I had a look it had not much moved from NetBSD towards FreeBSD. Don't know about the current state: [1] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.txt [2] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.patch harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Proper -current if_attach locking?
On Fri, 3 Jan 2003, Nate Lawson wrote: NLI was looking into some could sleep messages and found some bogus NLlocking in the attach routine of many drivers. Several init a mtx in NLtheir softc and then lock/unlock it in their attach routine. This, of NLcourse, does nothing to provide exclusive access to a device. I assume NLthere is going to be a global IF_LOCK or something to be used in attach NLroutines. Can someone fill me in on the intended design? Probably not. I asked the same question a couple of month ago and got 0 answers. I think, there is no way, the driver itself can assure exclusive access to the device it is attaching. It *must* assume, that there is some kind of locking around the call to the attach routine. Getting the lock in the softc inside the attach routine may be neccessary, because the routine may call other functions that assume they have the lock. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pdp11 tinderbox failure
Great I was waiting for this for too long. I'm going to install this on my 11/70 emulator as soon as it compiles again :-) How about a HP-65 port? harti On Tue, 17 Dec 2002, Matt Dillon wrote: MD MD-- MD Rebuilding the temporary build tree MD-- MD stage 1: bootstrap tools MD-- MD stage 2: cleaning up the object tree MD-- MD stage 2: rebuilding the object tree MD-- MD stage 2: build tools MD-- MD stage 3: cross tools MD-- MD stage 4: populating /home/tinderbox/pdp11/obj/home/tinderbox/pdp11/src/pdp11/usr/include MD-- MD stage 4: building libraries MD-- MD stage 4: make dependencies MD-- MD stage 4: building everything.. MD-- MD Kernel build for GENERIC started on Sun Dec 15 10:07:13 PST 2002 MD-- MD=== xe MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/hwregs.c: MDIn function `AcpiGetSleepTypeData': MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/hwregs.c:242: MDwarning: cast discards qualifiers from pointer target type MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c: MDIn function `AcpiUtGetRegionName': MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:482: MDwarning: cast discards qualifiers from pointer target type MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c: MDIn function `AcpiUtGetEventName': MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:520: MDwarning: cast discards qualifiers from pointer target type MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c: MDIn function `AcpiUtGetTypeName': MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:590: MDwarning: cast discards qualifiers from pointer target type MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:593: MDwarning: cast discards qualifiers from pointer target type MD/home/tinderbox/pdp11/src/sys/dev/acpica/acpi_powerres.c:272: MDwarning: `acpi_pwr_deregister_consumer' defined but not MDused MD/home/tinderbox/pdp11/src/sys/dev/acpica/acpi_powerres.c:210: MDwarning: `acpi_pwr_deregister_resource' defined but not MDused MDcc1: warnings being treated as errors MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c: In MDfunction `ffs_snapshot': MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:542: MDwarning: cast to pointer from integer of different size MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:557: MDwarning: cast to pointer from integer of different size MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c: In MDfunction `mapacct_ufs1': MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:1002: MDwarning: cast to pointer from integer of different size MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c: In MDfunction `mapacct_ufs2': MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:1278: MDwarning: cast to pointer from integer of different size MD*** Error code 1 MD MDStop in MD/home/tinderbox/pdp11/obj/home/tinderbox/pdp11/src/sys/GENERIC. MD*** Error code 1 MD MDStop in /home/tinderbox/pdp11/src. MD*** Error code 1 MD MDStop in /home/tinderbox/pdp11/src. MD MD_ MDFor the best comics, toys, movies, and more, MDplease visit http://www.tfaw.com/?qt=wmf MD MD MDTo Unsubscribe: send mail to [EMAIL PROTECTED] MDwith unsubscribe freebsd-current in the body of the message MD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
busdma documentation
Hi all, is there any documentation on the FreeBSD-busdma stuff? FreeBSD seems differ substantially from NetBSD in this regard. As far as I understand FreeBSD uses an older version. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing /boot/modules from BSD.root.dist
On Fri, 15 Nov 2002, Ruslan Ermilov wrote: REHi! RE REAnyone objects to this patch? Yes. Where do a install my modules then, that don't build with the kernel? harti RE RE%%% REIndex: BSD.root.dist RE=== RERCS file: /home/ncvs/src/etc/mtree/BSD.root.dist,v REretrieving revision 1.58 REdiff -u -5 -r1.58 BSD.root.dist RE--- BSD.root.dist10 Jun 2002 04:47:26 - 1.58 RE+++ BSD.root.dist15 Nov 2002 08:38:24 - RE@@ -10,12 +10,10 @@ RE boot RE defaults RE .. RE kernel RE .. RE-modules RE-.. RE .. RE dev RE fd mode=0555 RE .. RE .. RE%%% RE RE RECheers, RE -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing /boot/modules from BSD.root.dist
On Fri, 15 Nov 2002, Ruslan Ermilov wrote: REOn Fri, Nov 15, 2002 at 01:51:57PM +, Gavin Atkinson wrote: RE On Fri, 15 Nov 2002, Ruslan Ermilov wrote: RE On Fri, Nov 15, 2002 at 12:47:59PM +, Gavin Atkinson wrote: RE On Fri, 15 Nov 2002, Ruslan Ermilov wrote: RE REAnyone objects to this patch? RE RE Yes - this is the only place to put modules which are not built as part RE of the kernel, for example /usr/ports/comms/ltmdm. RE RE This port puts it under /usr/local/share/ltmdm/ltmdm.ko. RE RE OK, it may have been a bad example, but I prefer having my kernel modules RE loaded via the standard loader.conf method rather than using kldload for RE modules which I always want to exist. /boot/modules has been documented as RE being in the search path for modules for ages now, it seems unnecessary to RE change this. I think that we do need somewhere on the root partition where RE modules can be kept, without them being lost on the next upgrade. RE REYes, the standard search path is /boot/kernel;/boot/modules;/modules. RENevertheless, we don't create /modules, why should we create /boot/modules? Because then Makefiles don't have to fiddle with creating directories. I don't have a rule for creating /usr/bin in every Makefile that installs into /usr/bin. Why should I have one for /boot/modules? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 optimization bug ?
On Mon, 11 Nov 2002, TOMITA Yoshinori wrote:
This is probably not a bug, but a feature. You are not expected to access
a variable through a pointer to a non-compatible type. int and short are
not compatible. (see your ISO C standard on this topic).
Try to use ntohl(), htonl() for your problem.
harti
TYFor the source code below, compiling gcc -O2/-O3 seem to produce
TYincorrect code.
TY
TY---
TY#include stdio.h
TYint main(int argc, char* argv[])
TY{
TYunsigned int x = 0x12345678;
TYunsigned short tmp;
TYprintf(%x\n, x);
TYtmp = ((unsigned short *)x)[0];
TY((unsigned short *)x)[0] = ((unsigned short *)x)[1];
TY((unsigned short *)x)[1] = tmp;
TYprintf(%x\n, x);
TYreturn 0;
TY}
TY---
TY
TY
TY% gcc -O1 a.c
TY% ./a.out
TY12345678
TY56781234
TY
TY% gcc -O2 a.c
TY% ./a.out
TY12345678
TY12341234
TY
TY% gcc -v
TYUsing built-in specs.
TYConfigured with: FreeBSD/i386 system compiler
TYThread model: posix
TYgcc version 3.2.1 [FreeBSD] 20021009 (prerelease)
TY
TY
TY
TY
TYIs this a gcc bug or the source code problem ?
TY
TYTo Unsubscribe: send mail to [EMAIL PROTECTED]
TYwith unsubscribe freebsd-current in the body of the message
TY
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 optimization bug ?
On Mon, 11 Nov 2002, Andrew Gallatin wrote:
AG
AGHarti Brandt writes:
AG On Mon, 11 Nov 2002, TOMITA Yoshinori wrote:
AG
AG This is probably not a bug, but a feature. You are not expected to access
AG a variable through a pointer to a non-compatible type. int and short are
AG not compatible. (see your ISO C standard on this topic).
AG
AG Try to use ntohl(), htonl() for your problem.
AG
AG
AGOn a similar theme, I assume the following is also not safe:
AG
AGstatic __inline u_int64_t
AG__bswap64 (u_int64_t x)
AG{
AG u_int64_t ret;
AG u_int32_t *x_ptr, *ret_ptr;
AG
AG x_ptr = (u_int32_t *)x;
AG ret_ptr = (u_int32_ *)ret;
AG ret_ptr[0] = __bswap32 (x_ptr[1]);
AG ret_ptr[1] = __bswap32 (x_ptr[0]);
AG
AG return ret;
AG}
AG
AG
AGBut does using a union make it safe?
AG
AGstatic __inline u_int64_t
AG__bswap64 (u_int64_t x)
AG{
AG union
AG {
AGu_int64_t u64;
AGu_int32_t u32[2];
AG }
AG ret, old;
AG
AG old.u64 = x;
AG ret.u32[0] = __bswap32 (old.u32[1]);
AG ret.u32[1] = __bswap32 (old.u32[0]);
AG return ret.u64;
AG}
AG
AG
AGFWIW, both *seem* to work correctly using gcc version 3.2.1 and high
AGoptimization.
Well, I just had a long discussion with a collegue about the topic. The
main problem is in the ISO-C standard, section 6.7 point 4 which states:
All declarations in the same scope that refer to the same object or
function shall specify compatible types.
This makes any fiddeling with a pointer of a type, that is different from
the type of the variable illegal. It also makes fiddeling with unions and
structs illegal. As far as I understand types are compatible when they
have the same type and type qualifiers. Structs are partly compatible when
they start with fields of the same type. So the only way to legally swap
integer values of any size is via arithmetic. Of course unions and
pointers may work with the given compiler version and optimisation level.
But, nothing in the standard guarantees you anything.
It may be possible that 6.5 (7) the last sentence allows you to access your
32-bit or 64-bit value character-wise (although I'm not sure).
harti
G
AGThanks,
AG
AGDrew
AG
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 optimization bug ?
On Mon, 11 Nov 2002, Thomas David Rivers wrote:
TDRHarti Brandt [EMAIL PROTECTED] wrote:
TDR
TDR
TDR Hmm, I though the following would work:
TDR
TDR void
TDR foo(unsigned short *s)
TDR {
TDR unsigned short temp;
TDR
TDR temp = s[0];
TDR s[0] = s[1];
TDR s[1] = temp;
TDR }
TDR
TDR main()
TDR {
TDR int i = 0x12345678;
TDR
TDR foo(i);
TDR printf(%08x\n, i);
TDR }
TDR
TDR because how would the compiler in main() know, that you do something wrong
TDR in foo(). But... if you compile this with -O5, it does not work! This is
TDR because the compiler inlines foo() into main and the program prints junk like
TDR 0x12342804.
TDR
TDR
TDR Nope - that doesn't work either. The call to foo() is not compatible
TDR with the prototype (in fact, the Systems/C compiler issues a warning
TDR on this:
TDR
TDRWarning #2034: passing argument 1 from incompatible pointer type
TDR
TDR I believe gcc would as well.
Yes, of course, but one would assume it to work (I suppose there is a
large amount of code that assumes it will work). It's funny also to see,
that the program changes behaviour if you swap main() and foo(). In this
case the compiler cannot inline.
I just tried to give a counter example to your hope, that every sane
compiler would do the right thing with using a union for casting. I would
also assume that every sane compiler would do the right thing for the
above code.
IMHO, the C-standard is broken with regard to the rules for type
compatibility. As far as I remember these rules came into the standard
from one or two well-known PC compiler vendors that wanted to allow very
aggressive optimisation to show good benchmark results. The 'restrict'
keyword seems to be also an outcome of this.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 optimization bug ?
On Mon, 11 Nov 2002, David Malone wrote:
DMOn Mon, Nov 11, 2002 at 04:52:22PM +0100, Harti Brandt wrote:
DMAGBut does using a union make it safe?
DM
DM Well, I just had a long discussion with a collegue about the topic. The
DM main problem is in the ISO-C standard, section 6.7 point 4 which states:
DM
DM All declarations in the same scope that refer to the same object or
DM function shall specify compatible types.
DM
DMI think Section 6.5 paragraph 7 allows access through unions. There
DMis a footnote saying that the list given (which includes access
DMthrough the same type, qualified versions of the same type, aggregates
DMand unions containign that type and character types) is intended
DMfor determining aliasing rules.
That just allows you to do
int foo
union bar {
int foofoo;
} *ptr = (union bar)foo;
I think. You end up with the same situation - you can refer the integer
object foo only through an integer pointer.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
__printf0like not working?
Hi, I just doscovered, that the -Wformat feature does not work for warn() and err(), but works for printf() und Co. Was the __printf0like feature not patched into the actual gcc? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
xl_stats_update taking very long
Hi, I have a system that I use for simulation purposes. I have set HZ to 1 and everything is just fine. Except for one thing: the routine xl_stats_update has a mean execution time of 7.6 milliseconds. For my feeling this is far too long (compare to dc_tick, which takes only 1.5 usecs). If I comment out most of ukphy_status in ukphy_subr.c the problem disappears. It seems, that the READ_PHY() takes very long. If the reason for this behaviour is a hardware design bug, xl_stats_update should be called from a kernel thread rather then from a callout. Is there anybody with xl, mii, what-ever knowledge who knows what happens here? Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rcNg messages
On Thu, 5 Sep 2002, Mike Makonnen wrote: MMOn Thu, 05 Sep 2002 13:17:04 +0200 (CEST) MMHarti Brandt [EMAIL PROTECTED] wrote: MM MM rcorder: requirement `ppp' in file `/etc/rc.d/rpcbind' has no providers. MM rcorder: requirement `beforenetlkm' in file `/etc/rc.d/ipsec' has no MM providers. rcorder: requirement `beforenetlkm' in file `/etc/rc.d/ipfilter' MM has no providers. rcorder: requirement `altqd' in file MM `/etc/rc.d/NETWORKING' has no providers. rcorder: requirement `dhclient' in MM file `/etc/rc.d/NETWORKING' has no providers. rcorder: requirement `network' MM in file `/etc/rc.d/NETWORKING' has no providers. MM MMWell, gordon made a commit yesterday to prevent scripts not used by FreeBSD MMfrom being installed. rcorder is complaining because some of those scripts are MMin the REQUIRE line of the installed scripts. While your startup order may be MMsubtly different because of it, it's a benign error message (in this case). MMYou can redirect it to /dev/null with the following patch. Ok, thanks for the answer. Just another problem: I have a couple of machines that boot diskless via DHCP and NFS. Up to now I set the hostname of each of these machines in rc.conf.local. But this doesn't work anymore. I tried to track the sourcing of the configure scripts, but rcNG is a rather complex thing. A workaround is to supply the hostname via DHCP, but that may not work for everyone and it does not help for the second problem: I have network_interfaces=dc0 dc1 dc2 dc3 lo0 ifconfig_dc0=up media 100basetx mediaopt full-duplex ifconfig_dc1=up media 100basetx mediaopt full-duplex ifconfig_dc2=up media 100basetx mediaopt full-duplex ifconfig_dc3=up media 100basetx mediaopt full-duplex in my rc.conf.local and that used to work. But now it doesn't. So what is the problem with rc.conf.local? harti To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rcNg messages
On Fri, 6 Sep 2002, Harti Brandt wrote:
HBOk, thanks for the answer. Just another problem: I have a couple of
HBmachines that boot diskless via DHCP and NFS. Up to now I set the hostname
HBof each of these machines in rc.conf.local. But this doesn't work anymore.
HBI tried to track the sourcing of the configure scripts, but rcNG is a
HBrather complex thing. A workaround is to supply the hostname via DHCP, but
HBthat may not work for everyone and it does not help for the second
HBproblem: I have
HB
HBnetwork_interfaces=dc0 dc1 dc2 dc3 lo0
HBifconfig_dc0=up media 100basetx mediaopt full-duplex
HBifconfig_dc1=up media 100basetx mediaopt full-duplex
HBifconfig_dc2=up media 100basetx mediaopt full-duplex
HBifconfig_dc3=up media 100basetx mediaopt full-duplex
HB
HBin my rc.conf.local and that used to work. But now it doesn't. So what
HBis the problem with rc.conf.local?
It seems I found the problem. It turns out that rcNG is much more
aggressive in not re-reading the rc_config_files if they were already red
in. The problem with diskless boots is, that the first time, it tries to
read the scripts (in rc itself), the rc.conf.local is not there. Later on
(in initdiskless) it is copied to /etc, but the scripts remember that they
already have sourced the config files and don't try it again.
A workaround is to rename initdiskless to initdiskless.sh and to add the
line
unset _rc_conf_loaded
after
cp -Rp /conf/${i}/etc/* /etc
around line 129. But that seems rather ugly to me.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: rcNg messages
On Fri, 6 Sep 2002, Mike Makonnen wrote: MMOn Fri, 6 Sep 2002 12:14:05 +0200 (CEST) MMHarti Brandt [EMAIL PROTECTED] wrote: MM MM It seems I found the problem. It turns out that rcNG is much more MM aggressive in not re-reading the rc_config_files if they were already red MM in. The problem with diskless boots is, that the first time, it tries to MM read the scripts (in rc itself), the rc.conf.local is not there. Later on MM (in initdiskless) it is copied to /etc, but the scripts remember that they MM already have sourced the config files and don't try it again. MM MM A workaround is to rename initdiskless to initdiskless.sh and to add the MM line MM MMYes, this is a known issue. We have a couple of semi-decent work arounds. I've MMattached an email from cvs-all that you can try. You apply it and hack MMinitdiskless to exit with code 2 to re-read the rc.conf files. Thanks. This fixes the problem. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rcNg messages
Hi, I switched to rcNg and on startup get these messages. Is this something to worry about or is this supposed to happen? harti rcorder: requirement `ppp' in file `/etc/rc.d/rpcbind' has no providers. rcorder: requirement `beforenetlkm' in file `/etc/rc.d/ipsec' has no providers. rcorder: requirement `beforenetlkm' in file `/etc/rc.d/ipfilter' has no providers. rcorder: requirement `altqd' in file `/etc/rc.d/NETWORKING' has no providers. rcorder: requirement `dhclient' in file `/etc/rc.d/NETWORKING' has no providers. rcorder: requirement `network' in file `/etc/rc.d/NETWORKING' has no providers. rcorder: requirement `wscons' in file `/etc/rc.d/syslogd' has no providers. rcorder: requirement `sysdb' in file `/etc/rc.d/syslogd' has no providers. rcorder: requirement `mountall' in file `/etc/rc.d/accounting' has no providers. rcorder: requirement `mountall' in file `/etc/rc.d/amd' has no providers. rcorder: requirement `mountall' in file `/etc/rc.d/cleartmp' has no providers. rcorder: requirement `mountall' in file `/etc/rc.d/ldconfig' has no providers. rcorder: requirement `beforemountlkm' in file `/etc/rc.d/mountd' has no providers. rcorder: requirement `mountall' in file `/etc/rc.d/mountd' has no providers. rcorder: requirement `aftermountlkm' in file `/etc/rc.d/securelevel' has no providers. -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
On Tue, 11 Jun 2002, Terry Lambert wrote: TLHarti Brandt wrote: TL TLFor a sound device, it would be nice if multiple instances to the TL TLdevices were mux'ed. I've had cases where the program I was using TL TLwas using a smaller number that the total available channels, and TL TLit would have been nice if the next open instance got the remaining TL TLchannels, rather than a device in use error. You'd have to manage TL TLthis by giving all remaining available channels to an opener, and TL TLthen having them ioctl() the unused ones back (e.g. allocate N TL TLwhen there are M available, means give M-N back). TL TL That has also nothing to do with cloning. Look at the current pcm driver - TL it just has a device entry per channel. TL TLA device entry per channel is a stupid idea. It means that I can TLnot write software to open the sound device, I have gto write TLsoftware to open the *right* sound device out of N sound devices, TLso that I get the right channel. It's a lot easier to just open TLthe thing, than it is to teach every single piece of software that TLuses sound to do the right thing, and know how to do that. If TLnothing else, it wil mean an incredible duplication of code in all TLsound using user space programs, and programs written by naieve TLprogrammers (yeah, I know -- like rattus giganticus, they don't TLexist, right) so that if you want to run A and B, you have to run TLB first, because B doesn't know aboout anything but the first sound TLdevice. This is just a recipe for disaster. You just don't know what you are talking about. This is exactly the difference between the current Linux sound (1 device) and FreeBSD (1 device/channel). In FreeBSD I can use N channels with different audio formats and speeds, in Linux I'm stuck to using all the channels with the same format. Try to write a conferencing tool, that has to work in a heterogenous environment. TL Where cloning could come into the TL play is when more than one process tries to open a 1-channel device and TL you want to mix the audio. As I said this would be a task of a layer above TL the sound driver (just as X 'multiplexes' N processes onto one display TL device). Unfortunately there is no good sound API up to now. TL TLIf only you could differentiate open instances of the same device TLfrom each other, so that mixing would just be implied, and just TLwork... if only the sound device were a *cloning device*. 8-). Yes. And to open a file on disk I open /dev/da0s1a and then issue an ioctl to get to the file (and a new device entry) and every disk driver implements the file system. Every sound device writer writes all the mixing and code conversion code into his driver... Just idiotic... Mixing and code conversion is something you should do above the device layer, just as you do TCP not in the network driver. What's the the API that the user program sees from this generic layer is just a matter of taste - cloning pseudo devices would be just fine. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
On Mon, 10 Jun 2002, Maksim Yevmenkin wrote: MYHackers, MY MYThe project i'm working on might require some sort of MYdevice cloning. The current way of cloning, i.e. use MYDEVFS and allocate unique minor numbers, is not very MYgood for my purpose. MY MYThe idea is simple: the same device(major,minor) can MYbe opened several times by different processes (or MYpossibly threads within the same process) and each MYprocess (thread) will have unique device instance. MYDevice driver will create new instance, every time MYopen() called. It will use D_TRACKCLOSE flag and MYdestroy instances in close(). MY MYWhat kind of information should i store to identify MYeach instance? Is/Will it be possible to identify a MYsingle thread within a process? Is there any problems MYwith fork()? The support for the threads is optional. MYI can live with single instance per process. In MHO this idea is based on a fundamental misunderstanding of what a device is under unix. If you need such a behaviour you should put another abstraction on top of you devices (as the filesystem is put on top of disks and sockets on top of network devices), that handle multiple contexts for multiple processes. A device is just a device... harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
On Tue, 11 Jun 2002, Terry Lambert wrote: TLHarti Brandt wrote: TL In MHO this idea is based on a fundamental misunderstanding of what a TL device is under unix. If you need such a behaviour you should put another TL abstraction on top of you devices (as the filesystem is put on top of TL disks and sockets on top of network devices), that handle multiple TL contexts for multiple processes. A device is just a device... TL TLI really disagree with this. SVR4 and AIX have supported clone TLdevices for a very long time now, starting with support for pty's. TL TLCloning eliminates several things: TL TLoThe search requirement for allocating an instance of a TL device type; this is generally a linear search, through TL an O(n^2) interface, e.g. looking up the next pty in the TL space defined by /dev/pty* TL TLoThe normal limit on the number of devices that's imposed TL because of both the namespace limits, and on static TL declaration of things that should be allocated on a per TL instance bases, up to the limits of system resources TL TLoThe system dependence on naming that goes into building TL code that it portable between systems. TL TLFor pty's, in particular, instance is identified via minor number; TLthe need to actually try to open and obtain exclusive use of the TLmaster pty, up to the first unallocated one, and the fact that TLwhen you run out of names, you run out of pty's, are both enough, TLeach on their own, to justify cloning devices. TL TLFreeBSD today can not run more than one VMWare seassion at a time TLbecause it lacks the ability to distinguish open instances to the TLdevice that exports the VMWare kernel context information to the TLuser space application: because FreeBSD lacks device cloning. TL TLRather than trying to say what someone should do, it'd be nice, TLat least in the case of commercial code that can't be demanded to TLbe rewritten, and which runs under a non-native ABI on FreeBSD, TLto be able to support all of the functionality of the OS whose TLABI is being emulated, and thus, if for no other reason, to TLsupport device cloning. TL TLIt's not like third parties are going to be willing to port their TLcode to FreeBSD, particularly after the last 6 years or so of TLbeing told *by FreeBSD people* to target the Linux ABI. TL TLSo trying to change people wanting cloning in the first place is TLnot really a winable fight. Terry, I was talking about real devices, not pseudo devices that you can get out of thin air. Device driver for real devices should be just what they are: device drivers. If you take a disk driver, then there is no code there that tries to present multiple contexts to multiple openers - supporting this is the task of the file system. If you take a sound card, the multiplexing stuff, that handles multiple processes open the soundcard should not be in the driver, but in the abstraction above. The same holds for the network devices. The situation is different for pseudo devices which you can create on demand. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
On Tue, 11 Jun 2002, Terry Lambert wrote: TLHarti Brandt wrote: TL I was talking about real devices, not pseudo devices that you can get out TL of thin air. Device driver for real devices should be just what they are: TL device drivers. If you take a disk driver, then there is no code there TL that tries to present multiple contexts to multiple openers - supporting TL this is the task of the file system. If you take a sound card, the TL multiplexing stuff, that handles multiple processes open the soundcard TL should not be in the driver, but in the abstraction above. The same holds TL for the network devices. The situation is different for pseudo devices TL which you can create on demand. TL TLThis is true for most real devices, but not all of them. TL TLFor a disk device, it would be nice if I could ioctl() it to change TLit's instance to that of a parent, e.g. for slice management. Can't see any 'cloning' here. TLFor a sound device, it would be nice if multiple instances to the TLdevices were mux'ed. I've had cases where the program I was using TLwas using a smaller number that the total available channels, and TLit would have been nice if the next open instance got the remaining TLchannels, rather than a device in use error. You'd have to manage TLthis by giving all remaining available channels to an opener, and TLthen having them ioctl() the unused ones back (e.g. allocate N TLwhen there are M available, means give M-N back). That has also nothing to do with cloning. Look at the current pcm driver - it just has a device entry per channel. Where cloning could come into the play is when more than one process tries to open a 1-channel device and you want to mix the audio. As I said this would be a task of a layer above the sound driver (just as X 'multiplexes' N processes onto one display device). Unfortunately there is no good sound API up to now. TLFor a DVD, it would be nice if you could select the instance of the TLdevice you were going to get for seperation of the ISO9660 and UDF TLFS's (e.g. which record boundary the device actually used). The way TLthat OS X supports this is by doing DVD mounts on both the character TLand block device seperately. For FreeBSD, UDF support, which has to TLhave access to the ISO9660 FS for the purposes of index access, is TLmuch more messy. No cloning here. TLYou could also make an argument for multiple input devices and the TLmanagement of which one you get when you open /dev/mouse. Again you just get it the wrong way around. You need per process/open context if you try to put the multiplexing of ONE mouse between MULTIPLE processes into the hardware mouse driver. Again this would be plain wrong. TLFinally, there's a long history on SCO Xenix and UNIX, starting with TLComputone multiport serial cards, of multiplexing access to the TLdevice seperately for printing vs. terminal I/O. Yes, Digiboard and TLother vendors handle this by having two device nodes for a single TLpgysical device, and maintaining a state machine for the escape TLsequences. But this is really a matter of preference, not necessity. TLWriting to one instance, you talk to the terminal, and writing to the TLother, you talk to the aux port. Again this is not about 'cloning a physical' device. TLI don't think the original poster wanted cloning for support on TLphysical devices for which there was a 1:1 relationship anyway TL(8^)), but there *are* cases where it could be useful. TL TLActually, I think the original poster never really disclosed *what* TLthey wanted to use the feature for... That's true... From reading the original post I was under the impression that this is again a 'hey, I write a device driver and I need to track the number of opens and to tack a context onto each open' that periodically comes up. If I'm wrong, well, sorry then... harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Richard Arends wrote: RAHello, RA RAOn a fresh current i get this RA RA# truss /bin/echo hello RAtruss: cannot open /proc/13245/mem: No such file or directory RAtruss: cannot open /proc/curproc/mem: No such file or directory You need to mount procfs. harti RA RAGreetings, RA RARichard. RA RA RAAn OS is like swiss cheese, the bigger it is, the more holes you get! RA RA RATo Unsubscribe: send mail to [EMAIL PROTECTED] RAwith unsubscribe freebsd-current in the body of the message RA -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Revision 1.88 of kern_linker.c breaks module loading for diskless
On Fri, 26 Apr 2002, Brian Somers wrote: BSThe intent is to discover whether there's a filesystem yet (vn_open() BSwill die horribly otherwise). BS BSMy use of rootdev is (obviously) flawed. AFAICT, either rootvp BSor rootvnode should be used, but I can't tell the difference between BSthe two at a glance and am lacking development resources right now BS(my development box seems to enjoy dropping cores too frequently to BSbuild a kernel at the moment). BS BSIf somebody could test that rootvnode or rootvp are non-NULL after BSan NFS-mounted root is set up, I'd thankfully approve the quick BSfix... :*) dlc1# gdb -k /boot/kernel/kernel /dev/mem (no debugging symbols found)... IdlePTD at phsyical address 0x00392000 initial pcb at physical address 0x082bdda0 panic messages: --- --- #0 0xc017b968 in mi_switch () (kgdb) p rootdev $1 = -1 (kgdb) p rootvnode $2 = -843452416 (kgdb) p rootvp $3 = -843452416 (kgdb) They obviously point to the same thing and are non-NULL (root is NFS). harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Revision 1.88 of kern_linker.c breaks module loading for diskless
Hello, the check for rootdev != NODEV introduced in rev 1.88 breaks loading of kernel modules from an NFS mounted root in diskless configurations. Dropping in gdb and printing rootdev shows -1 which is, I assume, NODEV. This worked before without problems. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Rev. 1.82 of kern_linker.c disables module loads...
Hello, This revision of kern_linker.c entirly disables module loads from /etc/rc during boot: revision 1.82 date: 2002/03/20 16:03:42; author: arr; state: Exp; lines: +10 -6 - Change a check of securelevel to securelevel_gt() call in order to help against users within a jail attempting to load kernel modules. - Add a check of securelevel_gt() to vfs_mount() in order to chop some low hanging fruit for the repair of securelevel checking of linking and unlinking files from within jails. There is more to be done here. Reviewed by: rwatson Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld broken on globaldata.h
On Wed, 12 Dec 2001, Poul-Henning Kamp wrote: PK PKMy buildworld breaks: PK PK[...] PK/flat/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c:52: machine/globaldata.h: No PKsuch file or directory PK PKAny workarounds/fixes ? This was broken by jhb's large commit yesterday to break globaldata in MI and MD parts. The following patch to gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c let's you compile gdb. Don't know whether it works. Maybe there are other problems further down in the buildworld (mine is still working) harti Index: kvm-fbsd.c === RCS file: /usr/ncvs/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c,v retrieving revision 1.32 diff -r1.32 kvm-fbsd.c 52c52,53 #include machine/globaldata.h --- #include sys/pcpu.h #include machine/pcpu.h 121c122 offsetof(struct globaldata, gd_ ## name) --- offsetof(struct pcpu, pc_ ## name) 788,789c789,790 struct globaldata lgd; struct globaldata *gd; --- struct pcpu lgd; struct pcpu *gd; 794c795 for (; gd != NULL; gd = SLIST_NEXT (lgd, gd_allcpu)) --- for (; gd != NULL; gd = SLIST_NEXT (lgd, pc_allcpu)) 797c798 if (lgd.gd_cpuid == cpuid) --- if (lgd.pc_cpuid == cpuid) -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NgSendMsg may return bad token number
Hi all, NgSendMsg returns the bad token number if the debugging level is higher than 2. It should use the token number from the message structure instead of the global gMsgId, because that is changed by the ASCII messages sent in _NgDebugMsg. The following patch fixes the problem for NgSendMsg: Index: msg.c === RCS file: /usr/ncvs/src/lib/libnetgraph/msg.c,v retrieving revision 1.5 diff -r1.5 msg.c 84c84 return (gMsgId); --- return (msg.header.token); The same problem exists obviously in NgSendMsgASCII, but I have no test case for this one and hence no fix. Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?
On Fri, 19 Oct 2001, Mark Peek wrote: MPYes, it does appear to be due to this commit. The first address on the MPinterface queue has an address of 0.0.0.0. Here's a patch that works for MPme to block the messages. I'm guessing at the correct behavior so use at MPyour own risk. At least the voices^Wlog messages have stopped. :-) MP MPMark The last commit fixed the problem. Thanks. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?
On Thu, 18 Oct 2001, Terry Lambert wrote:
TLTo expand a little...
TL
TL That said, it's probably a good idea to never ARP for 0.0.0.0,
TL since a who has in that case is a really dumb idea, since,
TL as weas pointed out, it's intended to mean this host, in the
TL absence of an IP address (i.e. 0.0.0.0 is not an IP address,
TL it's a special value meaning not an IP address).
TL
TLIt's probably also a good idea to make interfaces who have an
TLIP of 0.0.0.0 _not_ respond to ARP requests for that address,
TLand, just in case there are other idiots, we should also not
TLgive proxy ARP responses for that address, etiher.
I have run tcpdump all night to find out what happens. The host receives
an ARP request with a source address of 0.0.0.0:
18:33:51.222688 arp who-has hydra tell 0.0.0.0
0001 0800 0604 0001 0030 65c6 a174
c1af 8755
I think, this may happen if the host does not yet know it's IP address
(DHCP maybe?).
But FreeBSD-current for some unknown reason answers to this request:
18:33:51.222835 arp reply 0.0.0.0 is-at 0:60:97:a:99:f
0001 0800 0604 0002 0060 970a 990f
0030 65c6 a174
and then prints:
Oct 18 18:33:51 scotty /boot/kernel/kernel: arp: 00:30:65:c6:a1:74 is using my IP
address 0.0.0.0!
I think this is because I have an interface that is up and has NO IP
address:
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet 127.0.0.1 netmask 0xff00
xl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
inet 193.175.135.70 netmask 0xff00 broadcast 193.175.135.255
ether 00:60:97:0a:99:0f
media: Ethernet 10baseT/UTP (10baseT/UTP half-duplex)
hatm0: flags=841UP,RUNNING,SIMPLEX mtu 9180
media: ATM UTP/155MBit
status: active
lane0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1516
ether 00:00:00:00:00:00
I think it is definitly wrong to assume that an interface with no IP
address has IP address 0.0.0.0
harti
TLGhah. I hate special cases...
everything is a special case...
harti
TL
TL-- Terry
TL
TLTo Unsubscribe: send mail to [EMAIL PROTECTED]
TLwith unsubscribe freebsd-net in the body of the message
TL
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
rc.diskless2 fails to create /var/log/lastlog
Hi, /var/log/lastlog is not in /etc/newsyslog.conf and is for this reason no created upon boot. This gives an error message each time one logs into the system. The append patch creates the file. harti Index: rc.diskless2 === RCS file: /usr/ncvs/src/etc/rc.diskless2,v retrieving revision 1.12 diff -c -r1.12 rc.diskless2 *** rc.diskless21 Jun 2001 10:07:15 - 1.12 --- rc.diskless217 Oct 2001 14:03:37 - *** *** 67,72 --- 67,75 /usr/bin/touch $LOGFILES fi + echo +++ create lastlog + /usr/bin/touch /var/log/lastlog + mount -a # chown and chgrp are in /usr # -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: newfs fails to build small file systems.
On Wed, 17 Oct 2001, Bruce Evans wrote: BEOn Tue, 16 Oct 2001, Harti Brandt wrote: BE BE since version 1.41 of newfs.c newfs fails to build 2MByte md-based BE file systems. We use these file systems in our diskless pc's. BE [patch snipped] Thanks, the patch worked. However: BEThe problem addressed by the patch is that the default geometry of 1 BEtrack with 4096 sectors is extremly bogus for devices that don't even BEhave 4096 sectors altogether. Users should override the default BEgeometry for these devices, but most users don't (the release Makefiles BEset bad examples...), and newfs emits alarming warnings. The changes Well, if one really careful reads the newfs manpage he will find these defaults (but not their implications). A hint in the EXAMPLES section of the page would really be useful. Something along the lines of: To format a file system with lesser than (default sectors/track * default tracks/cylinder) = 4096 sectors use the -u switch the specify the number of sectors: newfs -u 2048 /dev/md0c for a 1MByte memory disk. would be really useful. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
