Re: Machine freeze when X starts
Robert Watson wrote: On Mon, 17 Nov 2003, Jens Rehsack wrote: Hmm. This failure mode is fairly common when a resource deadlock or lock deadlock occurs in some kernel subsystems. Any chance you can get a serial console on the box so you can drop to DDB and generate some ps and stacktrace output? It seems to me a little bit more complicated to setup the serial console, so: yes, I can do it, but not today. Or - if you have a small quick get DDB to serial console without many trouble, I can give it a quick start. I'll try to do this week. Hook up a null modem cable to the first serial port on your machine, and to a serial port on another machine. On the other machine, use tip to attach to the com port, or some other com program of your choice. Speed should be 9600. ... Hi Robert, I had to build the kernels and world for the remote machine before, because I hadn't enabled the serial devices in the kernel, but I didn't get ready before today. I didn't get tip running, but my old serial terminal (Robotron P8000) worked fine. But the bug was gone in the meantime, so - sorry for now. But for the next time, I'm prepared. Best regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Machine freeze when X starts
Peter Ulrich Kruppa wrote:
At least we can be sure that something went completely wrong with
this weekend's sources.
Not just this weekend. The commit of the new interrupt code prevents
my system from running with HTT and I've seen nothing in the commits
which gives a workaround for me. John knows about the issue and I'm
hoping he thinks about a fix.
I had similar symptoms (X crashing, basic
commands not working), but was lucky enough, not to be completely
locked out. With some help from this list I could rebuild the OS.
X and Metacity work again, but Nautilus still crashes.
Jens, did you try to reload your old kernel?
No, because the (already build and installed) world requires
the new stat strcutures :-(
boot /boot/kernel.old
:-)
Great idea, but without dri it works fine.
Perhaps this gives you a little more than the power button.
Don't loading dri does even, but at the moment I'm rebuilding
the ports for another machine ('cause the crashed machine was
also the build workstation) to give Robert the backtrace (if
I can get it).
Bast regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Machine freeze when X starts
Janet Sullivan wrote: Jens Rehsack wrote: mail and rebuild all ports, my machine always crashes when I start X. My problem is, that I cannot determine the reason for the crashes, so I cannot think about a workaround. Any hints are very welcome :-) I've had the exact same symptoms as you with a radeon 9200 on a nforce2 board. I found that disabling DRI makes everything work happily. Try commenting out the Load dri line in your XF86Config. That helps, thank you very much. I only disabled the DRI Option from Section Device, but it wasn't enough. Best regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Machine freeze when X starts
Chris Knight wrote: -Original Message- From: Jens Rehsack [mailto:[EMAIL PROTECTED] Sent: Monday, 17 November 2003 00:00 To: [EMAIL PROTECTED] Subject: Machine freeze when X starts Hi, after I updated my machine yesterday to the -CURRENT src/ and ports/ of yesterday (2003-11-15 10:30 GMT), build kernel and world as described in Kirks HEADSUP mail and rebuild all ports, my machine always crashes when I start X. My problem is, that I cannot determine the reason for the crashes, so I cannot think about a workaround. Any hints are very welcome :-) I had a similar problem. I resolved my problem by killing the gnome session processes and the X lockup was fixed. I had replaced metacity with enlightenment, so there might be some weird interaction between the two. Hope this helps. Hi Chris, sorry, that wont help me out, 'cause the machine is not reacting to anything I'm doing (except the power and reset button). Best regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] /usr/sbin/moused fails if ums is built into kernel
Submitter-Id: current-users
Originator:Jens Rehsack
Organization: LiWing IT-Services
Confidential: no
Synopsis: [PATCH] /usr/sbin/moused fails if ums is built into kernel
Severity: serious
Priority: high
Category: bin
Class: sw-bug
Release: FreeBSD 5.1-CURRENT i386
Environment:
System: FreeBSD statler 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sat Nov 15 14:11:24 GMT
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STATLER i386
Description:
If the device ums is built into the kernel and not as module,
and the module is not build (eg. excluded by MODULES_OVERRIDE),
moused fails with:
'unable to load USB mouse driver: No such file or directory'
How-To-Repeat:
Build a -CURRENT kernel with ums, don't build the ums module,
use an usb-mouse and reboot.
Fix:
--- patch-usr.sbin::moused::moused.c begins here ---
Index: usr.sbin/moused/moused.c
===
diff -u usr.sbin/moused/moused.c.orig usr.sbin/moused/moused.c
--- usr.sbin/moused/moused.c.orig Sat Nov 15 14:51:14 2003
+++ usr.sbin/moused/moused.cSat Nov 15 15:08:10 2003
@@ -70,6 +70,9 @@
#include sys/socket.h
#include sys/stat.h
#include sys/un.h
+#include sys/param.h
+#include sys/linker.h
+#include sys/module.h
#include unistd.h
#define MAX_CLICKTHRESHOLD 2000/* 2 seconds */
@@ -495,6 +498,8 @@
static int kidspad(u_char rxc, mousestatus_t *act);
+static int usbmodule(void);
+
int
main(int argc, char *argv[])
{
@@ -754,8 +759,7 @@
retry = 1;
if (strncmp(rodent.portname, /dev/ums, 8) == 0) {
- if (kldload(ums) == -1 errno != EEXIST)
- logerr(1, unable to load USB mouse driver);
+ usbmodule();
retry = 5;
}
@@ -824,6 +828,43 @@
/* NOT REACHED */
exit(0);
+}
+
+static int
+usbmodule(void)
+{
+ int fileid, modid, loaded = 0;
+ struct kld_file_stat fstat;
+ struct module_stat mstat;
+
+ for( fileid = kldnext(0); loaded == 0 fileid 0;
+fileid = kldnext(fileid) )
+ {
+ fstat.version = sizeof(fstat);
+ if( kldstat( fileid, fstat ) 0 )
+ continue;
+ if( strncmp( fstat.name, uhub/ums, 8 ) == 0 )
+ {
+ loaded = 1;
+ break;
+ }
+
+ for( modid = kldfirstmod(fileid); modid 0;
+modid = modfnext(modid) )
+ {
+ mstat.version = sizeof(mstat);
+ if( modstat( modid, mstat ) 0 )
+ continue;
+ if( strncmp( mstat.name, uhub/ums, 8 ) == 0 )
+ {
+ loaded = 1;
+ break;
+ }
+ }
+ }
+
+ if( !loaded kldload(ums) == -1 errno != EEXIST )
+ logerr(1, unable to load USB mouse driver);
}
static void
--- patch-usr.sbin::moused::moused.c ends here ---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Machine freeze when X starts
Robert Watson wrote: On Sun, 16 Nov 2003, Jens Rehsack wrote: after I updated my machine yesterday to the -CURRENT src/ and ports/ of yesterday (2003-11-15 10:30 GMT), build kernel and world as described in Kirks HEADSUP mail and rebuild all ports, my machine always crashes when I start X. My problem is, that I cannot determine the reason for the crashes, so I cannot think about a workaround. Any hints are very welcome :-) It doesn't matter if I start using gdm or startx from console, the workstation switches to graphics mode and stops. I can press keys (eg. numlock) and there're recognized, but it seems no action is taken. I cannot kill the server using Ctrl+Alt+Backspace, Ctrl+Alt+Del didn't reboot, typing 'reset' doesn't do anything and it's not possible to remote login to the machine for clean reboot. The machine answers ping requests and accept incoming packets. A webserver is running on it and I can telnet to it, but the 'GET / HTTP/1.0' isn't answered. Hmm. This failure mode is fairly common when a resource deadlock or lock deadlock occurs in some kernel subsystems. Any chance you can get a serial console on the box so you can drop to DDB and generate some ps and stacktrace output? It seems to me a little bit more complicated to setup the serial console, so: yes, I can do it, but not today. Or - if you have a small quick get DDB to serial console without many trouble, I can give it a quick start. I'll try to do this week. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Machine freeze when X starts
Hi, after I updated my machine yesterday to the -CURRENT src/ and ports/ of yesterday (2003-11-15 10:30 GMT), build kernel and world as described in Kirks HEADSUP mail and rebuild all ports, my machine always crashes when I start X. My problem is, that I cannot determine the reason for the crashes, so I cannot think about a workaround. Any hints are very welcome :-) It doesn't matter if I start using gdm or startx from console, the workstation switches to graphics mode and stops. I can press keys (eg. numlock) and there're recognized, but it seems no action is taken. I cannot kill the server using Ctrl+Alt+Backspace, Ctrl+Alt+Del didn't reboot, typing 'reset' doesn't do anything and it's not possible to remote login to the machine for clean reboot. The machine answers ping requests and accept incoming packets. A webserver is running on it and I can telnet to it, but the 'GET / HTTP/1.0' isn't answered. Thanks for any help/hint in advance. Jens Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Sun Nov 16 12:29:39 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STATLER Preloaded elf kernel /boot/kernel/kernel at 0xc080f000. ACPI APIC Table: A M I OEMAPIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.86-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 1072889856 (1023 MB) avail memory = 1032679424 (984 MB) ioapic0 Version 2.0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled acpi0: A M I OEMXSDT on motherboard pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00f5410 acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 device_probe_and_attach: acpi_cpu1 attach returned 6 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82865 host to AGP bridge mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND pci1: ACPI PCI bus on pcib1 drm0: Matrox G550 (AGP) mem 0xfe00-0xfe7f,0xfe9fc000-0xfe9f,0xf400-0xf5ff irq 10 at device 0.0 on pci1 info: [drm] AGP at 0xf800 64MB info: [drm] Initialized mga 3.1.0 20021029 on minor 0 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xef00-0xef1f irq 16 at device 29.0 on pci0 usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xef20-0xef3f irq 19 at device 29.1 on pci0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xef40-0xef5f irq 18 at device 29.2 on pci0 usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xef80-0xef9f irq 16 at device 29.3 on pci0 usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: serial bus, USB at device 29.7 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 pci2: serial bus, FireWire at device 3.0 (no driver attached) skc0: 3Com 3C940 Gigabit Ethernet port 0xd800-0xd8ff mem 0xfeaf8000-0xfeafbfff irq 22 at device 5.0 on pci2 skc0: 3Com Gigabit LOM (3C940) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet address: 00:0c:6e:52:46:80 malloc() of 512 with the following non-sleepable locks held: exclusive sleep mutex skc0 (network driver) r = 0 (0xc69513c0) locked @ /usr/src/sys/pci/if_sk.c:1302 miibus0: MII bus on sk0 e1000phy0: Marvell 88E1000 Gigabit PHY on miibus0 lock order reversal 1st 0xc69513c0 skc0 (network driver) @ /usr/src/sys/pci/if_sk.c:659 2nd 0xc0727900 kernel environment (kernel environment) @ /usr/src/sys/kern/kern_environment.c:288 Stack backtrace: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto pcm0: Creative EMU10K1 port 0xdf40-0xdf5f irq 20 at device 12.0
Re: New interrupt code slows hyperthreading down
John Baldwin wrote: On 07-Nov-2003 Jens Rehsack wrote: John Baldwin wrote: Thanks, IRQ 16 was programmed as level, activelo, so it wasn't an off by one error there. Grr. I've seen, but I didn't found a bios option to set it to edge. Is there anything I can do on my machine to fix the problem, or should Asus be notified for a bios update or ...? No, level is correct. The APIC code doesn't mask edge triggered interrupts, and if it thought IRQ 16 was edge rather than level, that could explain the high interrupt rate. Since that isn't the case I'm not sure why it's triggering so many interrupts. Ok, but what I can do now to get my machine running with HTT again? It's out main development machine and with the single-processor config it runs mostly with a very high load. Is there any chance to get it running just before the new interrupt code. Could it be fixed? Regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[Fwd: [Bug optimization/11741] internal compiler error at gcse.c:5318]
Maybe at a good time the next snapshot should be imported into freebsd to get this fix, too :-) Some ports (eg. mysql40, apache) are switchable to high optimization where a bug in gcse could cause invalid code which will be removed with the patch for this bug. Original Message Subject: [Bug optimization/11741] internal compiler error at gcse.c:5318 Date: 8 Nov 2003 15:24:38 - From: cvs-commit at gcc dot gnu dot org [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] --- Additional Comments From cvs-commit at gcc dot gnu dot org 2003-11-08 15:24 --- Subject: Bug 11741 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2003-11-08 15:24:33 Modified files: gcc: ChangeLog gcse.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20030926-1.c 20031108-1.c Log message: Backport from mainline PR optimization/10467 PR optimization/11741 * gcse.c (pre_insert_copy_insn): Tweak the logic for finding the appropriate set to match the code in hash_scan_insn. * gcc.dg/20030926-1.c: New test case. * gcc.dg/20031108-1.c: New test case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.801r2=1.16114.2.802 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcse.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.223.2.7r2=1.223.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.2261.2.314r2=1.2261.2.315 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20030926-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=NONEr2=1.1.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20031108-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11741 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
New interrupt code slows hyperthreading down
Hi,
I recompiled my system today and when it came up again,
it was terrible slow. Using top I've seen, that there're
around 25% cpu-time is used to handle interrupts.
The kernel was configured using SMP ('cause it's a HTT
enabled CPU) and APIC. Setting machdep.hlt_logical_cpus
to 1 didn't change anything. Simply getting a few mails
(around 30) takes about 20 minutes. Most of time while
getting the mails my mozilla was in *Giant state,
what shouldn't be good, should it?
I've recompiled the kernel without SMP and APIC and
now the system's behaviour is more normal. Is the
behaviour of the new interrupt code better on real
multiprocessor systems?
Regards,
--
Jens Rehsack
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt code slows hyperthreading down
John Baldwin wrote:
On 07-Nov-2003 Jens Rehsack wrote:
Hi,
I recompiled my system today and when it came up again,
it was terrible slow. Using top I've seen, that there're
around 25% cpu-time is used to handle interrupts.
The kernel was configured using SMP ('cause it's a HTT
enabled CPU) and APIC. Setting machdep.hlt_logical_cpus
to 1 didn't change anything. Simply getting a few mails
(around 30) takes about 20 minutes. Most of time while
getting the mails my mozilla was in *Giant state,
what shouldn't be good, should it?
I've recompiled the kernel without SMP and APIC and
now the system's behaviour is more normal. Is the
behaviour of the new interrupt code better on real
multiprocessor systems?
Can you do a 'vmstat -i' under your SMP kernel to see where
all the interrupts are coming from? It sounds like a device
is interrupt storming. There has been report of this so far
with fwohci(4).
It's attached as well as the dmesg output booting with -v.
Jens
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #0: Fri Nov 7 10:12:42 GMT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/STATLER
Preloaded elf kernel /boot/kernel.old/kernel at 0xc087f000.
Calibrating clock(s) ... i8254 clock: 1193211 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 2398854804 Hz
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.85-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf29 Stepping = 9
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Hyperthreading: 2 logical CPUs
real memory = 1072889856 (1023 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0010 - 0x003f, 3145728 bytes (768 pages)
0x00c29000 - 0x3ed0afff, 1041113088 bytes (254178 pages)
avail memory = 1032667136 (984 MB)
ACPI APIC Table: A M I OEMAPIC
APIC ID: physical 0, logical 0:0
APIC ID: physical 1, logical 0:1
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 2
bios32: Found BIOS32 Service Directory header at 0xc00f
bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1
pcibios: PCI BIOS entry at 0xf+0x31
pnpbios: Found PnP BIOS data at 0xc00f5580
pnpbios: Entry = f:616a Rev = 1.0
Other BIOS signatures found:
MADT: Found IO APIC ID 2, Vector 0 at 0xfec0
ioapic0: intpin 0 - ExtINT
ioapic0: intpin 1 - irq 1
ioapic0: intpin 2 - irq 2
ioapic0: intpin 3 - irq 3
ioapic0: intpin 4 - irq 4
ioapic0: intpin 5 - irq 5
ioapic0: intpin 6 - irq 6
ioapic0: intpin 7 - irq 7
ioapic0: intpin 8 - irq 8
ioapic0: intpin 9 - irq 9
ioapic0: intpin 10 - irq 10
ioapic0: intpin 11 - irq 11
ioapic0: intpin 12 - irq 12
ioapic0: intpin 13 - irq 13
ioapic0: intpin 14 - irq 14
ioapic0: intpin 15 - irq 15
ioapic0: intpin 16 - irq 16
ioapic0: intpin 17 - irq 17
ioapic0: intpin 18 - irq 18
ioapic0: intpin 19 - irq 19
ioapic0: intpin 20 - irq 20
ioapic0: intpin 21 - irq 21
ioapic0: intpin 22 - irq 22
ioapic0: intpin 23 - irq 23
MADT: intr override: source 0, irq 2
ioapic0: Routing IRQ 0 - intpin 2
ioapic0: intpin 2 trigger: edge
ioapic0: intpin 2 polarity: active-hi
MADT: intr override: source 9, irq 9
ioapic0: intpin 9 trigger: level
ioapic0: intpin 9 polarity: active-hi
ioapic0 Version 2.0 irqs 0-23 on motherboard
cpu0 BSP:
ID: 0x VER: 0x00050014 LDR: 0x0100 DFR: 0x0fff
lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff
random: entropy source
mem: memory I/O
Pentium Pro MTRR support enabled
VESA: information block
56 45 53 41 00 03 43 57 00 c0 01 00 00 00 cd 52
00 c0 00 02 04 01 58 57 00 c0 5f 57 00 c0 6b 57
00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
VESA: 23 mode(s) found
VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc00c52cd (c00052cd)
VESA: Matrox Graphics Inc.
VESA: Matrox Matrox G550 00
null: null device, zero device
acpi0: A M I OEMXSDT on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x
pci_open(1a): mode1res=0x8000 (0x8000)
pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=25708086)
pcibios: BIOS version 2.10
Using $PIR table, 14 entries at 0xc00f5410
PCI-Only Interrupts: none
Location Bus Device Pin Link IRQs
embedded28A 0x68 3 4 5 6 7 10 11 12 14 15
embedded0 31A 0x62 3 4 5 6 7 10 11 12 14 15
embedded0 31B 0x61 3 4 5 6 7 10 11 12 14 15
embedded0 29A 0x60 3 4 5 6 7 10 11 12 14 15
embedded0 29B 0x63 3 4 5 6 7 10 11 12 14 15
embedded0 29C 0x62 3 4 5 6 7 10 11 12 14 15
embedded0 29D 0x6b 3
Re: New interrupt code slows hyperthreading down
Lars Eggert wrote: Jens Rehsack wrote: interrupt total rate irq1: atkbd0 512 2 irq8: rtc 23419127 irq13: npx01 0 irq14: ata0 4422 24 irq15: ata1 82 0 irq16: uhci0 uhci3 5379815 29238 This looks similar to what I described in the fwohci0 running wild thread. In both cases, irq16 seems to cause the problem... But I cannot unload the uhci driver, 'cause I need my mouse when using X. Ok, it would work even without, but I think then will I become the bottleneck, not irq 16 ;-) Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt code slows hyperthreading down
Lars Eggert wrote: John Baldwin wrote: On 07-Nov-2003 Lars Eggert wrote: Jens Rehsack wrote: interrupt total rate irq1: atkbd0 512 2 irq8: rtc 23419127 irq13: npx01 0 irq14: ata0 4422 24 irq15: ata1 82 0 irq16: uhci0 uhci3 5379815 29238 This looks similar to what I described in the fwohci0 running wild thread. In both cases, irq16 seems to cause the problem... Really. Does this only happen with ACPI enabled? Don't know about only, since I have never booted this machine without ACPI. I'll test next time I'm rebooting. Don't do it. I do it for testing a few minutes ago - and it prevents irq 16 from storming. But it does because the machine hangs at boot with: isa_probe_children: probing PnP devices I let it probe for about 10 minutes (you'll never know :-)), but it wont do. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt code slows hyperthreading down
John Baldwin wrote: On 07-Nov-2003 Jens Rehsack wrote: Lars Eggert wrote: John Baldwin wrote: On 07-Nov-2003 Lars Eggert wrote: This looks similar to what I described in the fwohci0 running wild thread. In both cases, irq16 seems to cause the problem... Really. Does this only happen with ACPI enabled? Don't know about only, since I have never booted this machine without ACPI. I'll test next time I'm rebooting. Don't do it. I do it for testing a few minutes ago - and it prevents irq 16 from storming. But it does because the machine hangs at boot with: isa_probe_children: probing PnP devices I let it probe for about 10 minutes (you'll never know :-)), but it wont do. Grrr, ok. Can you try the patch at http://www.FreeBSD.org/~jhb/patches/io_apic.patch and nab a boot -v dmesg with ACPI enabled? Thanks. Attached. Or shall I upload it to a web-server, too? Jens Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Fri Nov 7 22:43:13 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STATLER Preloaded elf kernel /boot/kernel/kernel at 0xc087f000. Calibrating clock(s) ... i8254 clock: 1193214 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2398855680 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.86-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 1072889856 (1023 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c29000 - 0x3ed0afff, 1041113088 bytes (254178 pages) avail memory = 1032667136 (984 MB) ACPI APIC Table: A M I OEMAPIC APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 bios32: Found BIOS32 Service Directory header at 0xc00f bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x31 pnpbios: Found PnP BIOS data at 0xc00f5580 pnpbios: Entry = f:616a Rev = 1.0 Other BIOS signatures found: MADT: Found IO APIC ID 2, Vector 0 at 0xfec0 ioapic0: intpin 0 - ExtINT (edge, activehi) ioapic0: intpin 1 - irq 1 (edge, activehi) ioapic0: intpin 2 - irq 2 (edge, activehi) ioapic0: intpin 3 - irq 3 (edge, activehi) ioapic0: intpin 4 - irq 4 (edge, activehi) ioapic0: intpin 5 - irq 5 (edge, activehi) ioapic0: intpin 6 - irq 6 (edge, activehi) ioapic0: intpin 7 - irq 7 (edge, activehi) ioapic0: intpin 8 - irq 8 (edge, activehi) ioapic0: intpin 9 - irq 9 (edge, activehi) ioapic0: intpin 10 - irq 10 (edge, activehi) ioapic0: intpin 11 - irq 11 (edge, activehi) ioapic0: intpin 12 - irq 12 (edge, activehi) ioapic0: intpin 13 - irq 13 (edge, activehi) ioapic0: intpin 14 - irq 14 (edge, activehi) ioapic0: intpin 15 - irq 15 (edge, activehi) ioapic0: intpin 16 - irq 16 (level, activelo) ioapic0: intpin 17 - irq 17 (level, activelo) ioapic0: intpin 18 - irq 18 (level, activelo) ioapic0: intpin 19 - irq 19 (level, activelo) ioapic0: intpin 20 - irq 20 (level, activelo) ioapic0: intpin 21 - irq 21 (level, activelo) ioapic0: intpin 22 - irq 22 (level, activelo) ioapic0: intpin 23 - irq 23 (level, activelo) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 - intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: active-hi MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: active-hi ioapic0 Version 2.0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00050014 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff random: entropy source mem: memory I/O Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 03 43 57 00 c0 01 00 00 00 cd 52 00 c0 00 02 04 01 58 57 00 c0 5f 57 00 c0 6b 57 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 23 mode(s) found VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc00c52cd (c00052cd) VESA: Matrox Graphics Inc. VESA: Matrox Matrox G550 00 null: null device, zero device acpi0: A M I OEMXSDT on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=25708086) pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00f5410 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded28A 0x68 3 4 5 6 7 10 11 12 14
Re: New interrupt code slows hyperthreading down
John Baldwin wrote: Thanks, IRQ 16 was programmed as level, activelo, so it wasn't an off by one error there. Grr. I've seen, but I didn't found a bios option to set it to edge. Is there anything I can do on my machine to fix the problem, or should Asus be notified for a bios update or ...? Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: if_xname changes incoming
Dimitry Andric wrote: On 2003-10-31 at 21:29:42 Brooks Davis wrote: Ok, we're mostly clear. World builds, but I've had to disconnect ipfstat, ipnat, and ipftest from the build because they need modifications and are on vendor branch. IP Filter users may wish to wait to upgrade until this issue is resolve or they may apply the following patch locally. Could you or the ipfilter maintainer (Darren?) please give some ping on the list, when it is in order again? Thanks in advance. :) You can use the patch attached to the message of the commit has been finished. It works fine with it. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
Don Lewis wrote:
On 2 Oct, Terry Lambert wrote:
[...]
Actually, write caching is not so much the problem, as the disk
reporting that the write has completed before the contents of
the transaction saved in the write cache have actually been
committed to stable storage.
Unfortunately, IDE disks do not permit disconnected writes, due
to a bug in the original IDE implementation, which has been
carried forward for [insert no good reason here].
Therefore IDE disks almost universally lie to the driver any
time write caching is enabled on an IDE drive.
In most cases, if you use SCSI, the problem will go away.
Nope, they lie as well unless you turn of the WCE bit. Fortunately
with tagged command queuing there is very little performance penalty for
doing this in most cases. The main exception to this is when you run
newfs which talks to the raw partition and only has one command
outstanding at a time.
Back in the days when our SCSI implementation would spam the console
whenever it reduced the number of tagged openings because the drive
indicated that its queue was full, I'd see the number of tagged openings
stay at 63 if write caching was disabled, but the number would drop
significantly under load (50%?) if write caching was enabled. I always
suspected that the drive's cache was full of data for write commands
that it had indicated to the host as being complete even though the data
hadn't been written to stable storage.
Unfortunately SCSI drives all seem to ship with the WCE bit set,
probably for benchmarking reasons, so I always have to remember to
turn this bit off whenever I install a new drive.
A message from this morning ('file system (UFS2) consistancy
after -current crash?') to this list describes exactly the
situation on my fileserver a few month ago, except my machine
runs with FreeBSD 4-STABLE and has an ICP-Vortex 6528RD controller.
I think, disk's or controllers (short hardware) write cache
is a problem. Maybe it shouldn't be in theory, but it is in
real world :-)
Best regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
Bill Moran wrote: [...] To me, this means: a) if you want reliable, don't use IDE with WC Reducable of 'don't use IDE' :-) b) if you want reliable and fast, don't use IDE, period, use SCSI. If you look at the recent postings, SCSI didn't help you out everytime. I use the fileserver in current configuration for nearly 5 years, and only once this happend, each other case all filesystems including hold data was recoverable. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
Kevin Oberman wrote: [...] Current has two major changes re speeding up fsck. The most significant is the background operation of fsck on file system with soft updates enabled. Because of the way softupdates works, you are assured of metadata consistency on reboot, so the file systems can be mounted and used immediately with fsck started up in the background about a minute after the system comes up. Be careful what you promise :-) Most new disks have an own disk cache and some of them have a write cache enabled. In case of a hardware failure (or power failure) this data may get lost and the disk's metadata isn't consistent. It's only when no write cache below the system is active. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
Kevin Oberman wrote: Date: Wed, 01 Oct 2003 06:39:47 + From: Jens Rehsack [EMAIL PROTECTED] Kevin Oberman wrote: [...] Current has two major changes re speeding up fsck. The most significant is the background operation of fsck on file system with soft updates enabled. Because of the way softupdates works, you are assured of metadata consistency on reboot, so the file systems can be mounted and used immediately with fsck started up in the background about a minute after the system comes up. Be careful what you promise :-) Most new disks have an own disk cache and some of them have a write cache enabled. In case of a hardware failure (or power failure) this data may get lost and the disk's metadata isn't consistent. It's only when no write cache below the system is active. [...] But thanks for bringing this up as it is important. And, yes, it has burned me, although it required a confluence of things all going wrong at exactly the right timing to catch a bunch of metadata in cache. (This could only have happened on a CURRENT system back in the 5.0 time frame.) It could only happen when the file system had been very active with an installworld. But it did happen. It happens to me in another circumstance. On my fileserver runs a portupgrade and during that something nasty fails. I couldn't determine what, but nearly the complete /usr/, /var/ and some of the /export/ data was lost+found :-) /var and /usr could be restored, and the rest came from backup or restored from lost+found, but it showed me the end of disk caching. The trade-off is a big performance hit. With disk cache on, I can copy my entire FreeBSD partition to another disk in about 15 minutes. With disk cache off, it took a few HOURS. This was a worst case example with dd on my laptop (slow disks). Here you should try to use other block sizes. Try it with smaller ranges, eg. 100MB. The result may be best somewhere between 8192 and 65536 bytes per block. Best regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gcc 3.2.2 vs gcc 3.2.3
Holger Kipp wrote: ... imho memtest seems to be suitable for this-is-real-broken-memory(tm) only. Yes, memtest86 could only detect bad memory. No reported failure doesn't says anything except memtest86 didn't found any error. It might be that due to differnent optimisations (gcc 3.2.2 vs gcc 3.2.3) you might escape the bitpatterns that would otherwise trigger the sig 11. There're several bugs known in gcc-3.2, some of them are removed in gcc-3.3, some of them are scheduled to be fixed in gcc-3.4. The best recommendation to optimization (if you don't want to research atr gcc.gnu.org) is using -O and not more. Regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC tickling obscure hardware bug or...?
[EMAIL PROTECTED] wrote: Quoting Scott Reese [EMAIL PROTECTED]: Hello all, I'm rephrasing my previous question to reflect new findings in my situation in the hopes that someone may have an idea of what's going on here (see thread Internal compiler error in reload_cse_simplify_operands from earlier this week). In a nutshell, I have upgraded my machine to a PIV 2.4 GHz processor on a VIA P4B 400 motherboard with 512 MB Samsung 2700 DDRAM. I have a 300 Watt power supply with a ball-bearing fan and a Seagate 40 GB HD. The problem I'm having that I did not see with my PIII is that I'm getting intermittent internal compiler errors when attempting to compile anything (again, see previous thread for an example). I even did a fresh install of the system yesterday in order to rule out something random getting hosed causing problems with my compiler. Through experimentation, I've found that toggling the CFLAGS from -O to -O2 or vice-versa works around the problem (actually, I've had greater success leaving my CFLAGS set to -O2 -pipe and occasionally bringing them back to -O -pipe when I run into an ICE and then setting them back again). My hunch is that some hardware bug is being tickled by gcc somehow. I don't think it's the standard broken hardware thing because I've not received any signal 11/7/4 errors at all and the system runs wonderfully. So far it's been up for over 24 hours, compiling ports and running without a hitch. The only strangeness is the compiler's behavior. Also, I should mention that I added options DISABLE_PSE options DISABLE_PG_G to my kernel config but the ICE's still persist, though they seem to be less frequent now. Attached is my dmesg, please let me know if anyone would like any more information about this or if you have any idea what might be going on here. Thank you, Scott Whenever I've had problems like this, it's been either bad memory, or bad memory settings in bios. I'd check both of those things. Ken According to several bug reports on gcc.gnu.org related to cse and p4 I strongly recommend to all whose using -On (with n1) to add -fno-gcse etc. for all cse options. Of course, any interested can add themself as watcher for each interested reported gcc bug. Best, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng: ata1-slave CDRW is only sometimes detected
Lefteris Chatzibarbas wrote: Hello, I have the following units on a MSI KT4V (KT400/VT8235) motherboard (80pin cable is used for both primary and secondary controller): ata0-master: WDC WD800JB ATA-6 disk ata0-slave: ata1-master: TEAC DV-516E DVDROM drive ata1-slave: TEAC CD-W524E CDRW drive For about a week I have the aforementioned setup. I had the same setup before ATAng got committed, but with a different DVDROM drive, without problems. When ATAng got committed I had only the CDRW drive as ata1-master, also, without problems. I detected a similar problem with yesterdays current, but giving it a chance I detected I a had a loosely cable. Regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bktr(4) bufs plus patch
Michal Mertl wrote:
I found 2 bugs and some potential problems in bktr(4) code.
Bug 1:
Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is
that code tries to use iicbus which isn't defined where it looks for
it. I added it there and the compilation and detection goes fine. I don't
know how to actually test it though.
[...]
Will anyone responsible take notice of this patch and commit it?
*** dev/bktr/bktr_reg.h.ori Sun Dec 8 10:40:14 2002
--- dev/bktr/bktr_reg.h Sun Dec 8 10:40:38 2002
***
*** 448,453
--- 448,454
struct bktr_i2c_softc {
int bus_owned;
+ device_t iicbus;
device_t iicbb;
device_t smbus;
};
*** dev/bktr/bktr_os.c.ori Sun Dec 8 10:39:13 2002
--- dev/bktr/bktr_os.c Sun Dec 8 10:39:35 2002
***
*** 499,513
destroy_dev(bktr-tunerdev);
destroy_dev(bktr-bktrdev);
- /* If this is unit 0, then destroy the alias entries too */
- #if (__FreeBSD_version =50)
- if (unit == 0) {
- destroy_dev(bktr-vbidev_alias);
- destroy_dev(bktr-tunerdev_alias);
- destroy_dev(bktr-bktrdev_alias);
- }
- #endif
-
/*
* Deallocate resources.
*/
--- 499,504
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bktr(4) bufs plus patch
John-Mark Gurney wrote: Jens Rehsack wrote this message on Wed, Sep 03, 2003 at 22:03 +: Michal Mertl wrote: I found 2 bugs and some potential problems in bktr(4) code. Bug 1: Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is that code tries to use iicbus which isn't defined where it looks for it. I added it there and the compilation and detection goes fine. I don't know how to actually test it though. [...] Will anyone responsible take notice of this patch and commit it? I'm not responsible, but I will take notice of it. Once I get my lab up and running (hopefully in the next week), I can test this and see how it works. Could we get it submitted as a pr (if it isn't already), and assign it to me? (I'll assign it to myself once I know the PR). This should be done by Michal, because it's the original submitter and seems to have made deep research :-) Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HTT on current
Bruce Evans wrote: On Tue, 26 Aug 2003, John Baldwin wrote: On 26-Aug-2003 Yamada Ken Takeshi wrote: [...] One test is not sufficient. -current is also not the best place to test. :) When I first implemented HTT in -current The above times seem slow enough to be partly the result of debugging options in -current. I get buildworld times ranging from 1401 seconds (2002/09/01) to 2427 seconds (2003/05/06) on Athlon XP1600 x 1 depending on configuration and tuning (but never with any expensive debugging options). A Xeon 2.8GHz x 2 should be a bit faster than an old Athlon. Hm, IFAIK I shouldn't have any debug options enabled, but who knows - didn't have time to check more than kernel and malloc. By the way, attached times shows that using HTT speeds up buildworld by 10 (compare HTT/no-HTT) and this is IMHO a real improvement. Many people buy much more expensive processor to get 10% more speed. ... I did 16 trials (first one was throwaway) of back-to-back buildworlds of the same version of -stable using make, make -j2, and make -j4 for the following configurations: UP, HTT, HTT with smp_idle_hlt, and HTT with pause instructions added to stable and smp_idle_hlt. The fastest build time belonged to UP without any -j option. All benchmarks using -j are invalid because of a pessimization in make(1). It sleeps for up to SEL_USEC = 10 usec after completion of every job (average 50 msec). With -j2 this increases !SMP buildworld times of approx. 2000 seconds by approx. 15%. I think it has a smaller effect for larger -j values and for SMP but haven't benchmarked it. This is fixed in NetBSD. I think fixing it was more urgent in NetBSD because NetBSD never changed SEL_USEC from its 4.4Lite default of 50. 50 was large enough to be noticeable even in 1997 when it was reduced in FreeBSD. That would explain the small slow down from -j8 to -j20. But the results seems to me to be schoolbook like: 4 processes per processor as I learned produces best results. Okay, that's so far. Best regards Jens Jens 1) HTT + PAT (-j4) - 4736.474u 569.157s 52:19.56 168.9% 4041+2517k 16977+153222io 5761pf+0w - 4737.875u 571.889s 51:07.10 173.1% 4039+2516k 1519+153172io 450pf+0w - 4734.651u 570.591s 51:51.69 170.4% 4039+2519k 12822+153198io 3264pf+0w 2) HTT + PAT (-j20) - 4754.903u 604.875s 51:10.69 174.5% -3981+2500k 3503+153256io 2952pf+0w - 4770.237u 613.092s 50:46.67 176.6% -3948+2501k 3132+153183io 3143pf+0w - 4772.232u 614.315s 50:45.60 176.8% -3942+2501k 2861+153184io 2963pf+0w 3) no-HTT, PAT, -j4 - 2843.366u 431.189s 57:54.23 94.2% 3981+2475k 1549+153171io 1276pf+0w - 2843.791u 430.378s 58:22.65 93.4% 3983+2476k 1293+153166io 450pf+0w - 2842.366u 432.233s 57:42.22 94.5% 3981+2473k 1277+153170io 450pf+0w 4) HTT, PAT, -j8 - 4761.587u 592.745s 50:40.74 176.0% -3986+2509k 1280+153185io 450pf+0w - 4756.575u 593.777s 50:49.25 175.4% -3991+2509k 1277+153198io 450pf+0w - 4766.158u 595.531s 50:36.81 176.5% -3975+2510k 1284+153182io 450pf+0w 5) Single-User-Mode, HTT, PAT, -j4 - 4732.941u 578.183s 51:08.25 173.0% 4035+2515k 1274+153164io 450pf+0w - 4720.249u 573.533s 51:16.59 172.3% 4034+2515k 1276+153165io 450pf+0w - 4737.491u 575.077s 51:07:71 173.1% 4035+2517k 1273+153173io 450pf+0w 5) Single-User-Mode, HTT, PAT, -j8 - 4756.060u 604.684s 50:33.13 176.7% -3978+2509k 1284+153173io 450pf+0w - 4803.037u 604.068s 52:26.76 171.8% -3904+2511k 17043+153163io 5763pf+0w Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Tue Aug 26 13:39:29 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STATLER Preloaded elf kernel /boot/kernel/kernel at 0xc05b. Preloaded elf module /boot/kernel/acpi.ko at 0xc05b021c. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.86-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 1072889856 (1023 MB) avail memory = 1036087296 (988 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 Pentium Pro MTRR support enabled VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc00c52cd (c00052cd) VESA: Matrox Graphics Inc. npx0: math processor on motherboard npx0: INT 16 interface acpi0: A M I OEMXSDT on motherboard pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00f5410 acpi0: power button is handled as a
Re: 3C940 / Asus P4P800 gigabit LAN driver
Stuart Walsh wrote: On Sun Aug 24, 01:22P +0200, Wilko Bulte wrote: On Sat, Aug 23, 2003 at 04:45:30PM +0100, Stuart Walsh wrote: Hi, I ported the openbsd additions to the sk driver to support the 3c940 gigabit network card which is commonly found in the above asus motherboard. Testers/comments/commits welcome, but please don't blame me if it burns your house down or something :) Hi Stuart, I tried this patch instead of the earlier ones you pointed me to on IRC. Unfortunately my Asus P4P800 still locks up solid (reset button required) after printing the 3c940's ethernet address. I'm interested to know if other P4P800 owners have the same issue. Wilko Hi Wilko, Sorry to hear you are still having trouble. Thus far I have only been able to find one other person to test the driver and for him it works perfectly(also a P4P800). Hi Guys, I have 2 machines with P4P800-Deluxe with the 3C940. If phk@ could fix the swap-issue, so that I can reboot easily, I would test your patches, too. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs andprocfsautomatically
On 14.08.2003 15:36, Scot W. Hetzel wrote:
I just noticed a problem with periodic scripts inside a jail. I'm getting:
Local system status:
tee: /dev/stderr: Operation not supported
Mail in local queue:
tee: /dev/stderr: Operation not supported
Mail in submit queue:
tee: /dev/stderr: Operation not supported
in the periodic daily, weekly, monthly and security reports. But if I mount
the fdescfs on the jail, then these errors go away.
So we need to add the following to the new jail script
jail_start()
{
:
eval jail_devfs=\\$jail_${_jail}_devfs\
[ -z ${jail_devfs} ] jail_devfs=NO:
eval jail_fdescfs=\\$jail_${_jail}_fdescfs\
[ -z ${jail_fdescfs} ] jail_fdescfs=NO
:
if checkyesno jail_devfs ; then
mount -t devfs dev ${jail_devdir}
if checkyesno jail_fdescfs ; then
mount -t fdescfs fdesc ${jail_devdir}/fd
fi
:
fi
:
}
jail_stop()
{
:
eval jail_devfs=\\$jail_${_jail}_devfs\
[ -z ${jail_devfs} ] jail_devfs=NO:
eval jail_fdescfs=\\$jail_${_jail}_fdescfs\
[ -z ${jail_fdescfs} ] jail_fdescfs=NO
:
if checkyesno jail_devfs ; then
if [ -d ${jail_devdir} ] ; then
if checkyesno jail_fdescfs; then
umount -f ${jail_devdir}/fd /dev/null 21
fi
umount -f ${jail_devdir} /dev/null 21
fi
fi
:
}
The only decsion we need to make is wheter to always mount the fdescfs when
devfs is mounted on the jail, or have a variable to enable mounting of the
fdescfs (jail_*_fdescfs).
Scot
I don't run periodics in jails, because they are not allowed to mail
out :-)
But I wouldn't really care having fdescfs mounted every time as
security problem, so I would decide to mount it ever (or defaultly).
If someone cares, addition of jail_example_mount_fdescfs is
recommented.
I add a CC to security@, because of there may be one or other who
has an important comment.
Best,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel failing to build
On 14.08.2003 23:10, Kris Kennaway wrote:
On Thu, Aug 14, 2003 at 05:28:54PM +0200, Guido Falsi wrote:
I's been a few days, the kernel on my machine is failing to build in the
same point...I tried cvsupping at various times.
The system is a -current from 19 July.
Build your kernel with WERROR= as discussed on this list.
There're 2 WERROR-related flages, NO_WERROR (bool, which
suppresses -Werror in some cases in /usr/share/mk/bsd.sys.mk)
and WERROR (string, contains Werror-Flag in
/usr/src/sys/conf/kern.pre.mk)
Suggestion to the Makefile maintainers:
--- kern.pre.mk.origFri Aug 15 14:32:40 2003
+++ kern.pre.mk Fri Aug 15 14:33:23 2003
@@ -52,7 +52,11 @@
.endif
.endif
DEFINED_PROF= ${PROF}
+.if defined(NO_WERROR)
+WERROR?= -Wno-error
+.else
WERROR?= -Werror
+.endif
INLINE_LIMIT?= 15000
CFLAGS+= -finline-limit=${INLINE_LIMIT} -fno-strict-aliasing
Best,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On 04.08.2003 01:04, Mike Makonnen wrote: On Sun, Aug 03, 2003 at 04:11:12PM +0200, Jens Rehsack wrote: the patch works for me very well. I've checked what's been done and had only small recommendations: - Wouldn't it be better to configure the devfs rules by /etc/devfs.conf or is it impossible? - Even it would be a good thing, if I could specify a ruleset for each jail, and fallback to devfs_ruleset_jail if no jail_example_devfs_ruleset is specified? Ok. Here's a retooled patch. It now includes a devfs rule specification format that we can even use in the general case (i.e. - for /dev). The default rules for a jail are included in it. It's in etc/defaults/devfs.rules and should be self-explanatory. I also put back Scott's code in rc.d/jail for handlind rulesets for individual jails. But I kept the default jail ruleset hard-coded. I don't see the poing of creating yet another knob for it. If a user doesn't want the default that's what the individual knobs for the jails are there for :) Let me know how it goes. On 04.08.2003 01:09, Mike Makonnen wrote: the patch is attached this time. Hi Mike, sorry that testing took a while, but it failed completely first time on my machine I didn't find the time to debug. 1st: you have a typo in etc/rc.d/jail sed /\[-z/\[ -z/ 2nd: you include the 'devfs_ruleset_hide' several times, and each time the devfs call for it hides all previous unhidden. So you have to remove the 'add include $devfs_ruleset_hide' from the unhiding rulesets. 3rd: I don't know why, but I had your etc/default/devfs.rules content 5 times in my etc/defaults/debfs.rules The parsing subr fails with this content and so the jails didn't came up. So it was my fault (even I cannot explain, 'cause I removed /usr/src/etc before I cvsup'ed and applied the patch). By the way, now it works. Great step for flexible jails!!! Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
INET6 in world
Hi David, I've seen that several world daemons (rpcbind, telnetd, ...) are build with INET6. In real life, I do not know anyone who owns some IPv6 addresses but many guys who disabled INET6 on their machines in kernel. Now the daemons prints out a (IMHO useless) warning, that they cannot bind to the INET6 socket on each start. Especially on workstation, which might to be started each day, this confuses the employee (each one once, but me as admin each time). Now the question: Would a patch be welcome which enables INET6 only if /etc/make.conf not contains 'NO_INET6=true'? Best regards and nice weekend, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On 02.08.2003 01:29, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 08:27:07PM +0200, Jens Rehsack wrote: On 29.07.2003 19:21, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote: Yeah, I'll take care of this. I had asked scott to mail me his final patch so I could commit it, but I never heard back from him. I'll dig out the revisions from my mail archives and combine the two. You can mail me the patch first, so that I can test it before you commit it, if you want. Hi Jens, Can you apply the attached patches and let me know how it goes? Cheers. Hi Mike, hi Scot, the patch works for me very well. I've checked what's been done and had only small recommendations: - Wouldn't it be better to configure the devfs rules by /etc/devfs.conf or is it impossible? - Even it would be a good thing, if I could specify a ruleset for each jail, and fallback to devfs_ruleset_jail if no jail_example_devfs_ruleset is specified? Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On 03.08.2003 16:11, Jens Rehsack wrote: On 02.08.2003 01:29, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 08:27:07PM +0200, Jens Rehsack wrote: On 29.07.2003 19:21, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote: Yeah, I'll take care of this. I had asked scott to mail me his final patch so I could commit it, but I never heard back from him. I'll dig out the revisions from my mail archives and combine the two. You can mail me the patch first, so that I can test it before you commit it, if you want. Hi Jens, Can you apply the attached patches and let me know how it goes? Cheers. Hi Mike, hi Scot, the patch works for me very well. Ahh - being able to read benefits clearly :-) Without having rc_debug=YES turned on the boot process shows an error: devfs_link: not found. It's called from within etc/rc.d/jails to link /var/log/log etc. Jens ___ [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 03.08.2003 23:39, Bernd Walter wrote: On Mon, Aug 04, 2003 at 07:20:02AM +1000, Andy Farkas wrote: On Sun, 3 Aug 2003, Bernd Walter wrote: On Sun, Aug 03, 2003 at 04:07:15PM +0200, Jens Rehsack wrote: Hi David, I've seen that several world daemons (rpcbind, telnetd, ...) are build with INET6. In real life, I do not know anyone who owns some IPv6 addresses but many guys who disabled INET6 on their machines in kernel. ... No daemon explicitly binds to an inet6 socket unless configured to do so. During bootup, I see this too: Jul 13 18:09:42 console.info hummer kernel: Starting rpcbind. Jul 13 18:09:42 console.info hummer kernel: Jul 13 18:09:42 daemon.err hummer rpcbind: cannot create socket for udp6 Jul 13 18:09:42 console.info hummer kernel: Jul 13 18:09:42 daemon.err hummer rpcbind: cannot create socket for tcp6 Just guessing: what's in your /etc/hosts for localhost? That's not the problem, because of # cat STATLER grep INET options INET#InterNETworking #optionsINET6 #IPv6 communications protocols :-) So no INET6 is available - /etc/hosts doesn't matter in that case Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On 02.08.2003 01:29, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 08:27:07PM +0200, Jens Rehsack wrote: On 29.07.2003 19:21, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote: Yeah, I'll take care of this. I had asked scott to mail me his final patch so I could commit it, but I never heard back from him. I'll dig out the revisions from my mail archives and combine the two. You can mail me the patch first, so that I can test it before you commit it, if you want. Hi Jens, Can you apply the attached patches and let me know how it goes? Cheers. Is there a difference to those Scot send me yesterday evening? If not, I'm working on it, but after a hard week I took a free day today and tomorrow starts with an meeting. So don't expect results of test before monday morning (7:00 GMT) Best regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] jail NG schript patch for mounting devfs and procfsautomatically
Hi all, hi Clement,
I updated the rcng jail start script to mount devfs and procfs
into the jail if wanted. Adding entries to /etc/fstab didn't
work properly, because the jail filesystem wasn't mounted when
the startup process wants to mount it.
Going this way allows us to control which jail could be used
via ssh (or another remote shell), too.
Any comments gladly welcome.
If it's useful for FreeBSD, I will write the rc.conf(5) update,
too. Please inform me to do this.
Regards,
Jens
--- etc/rc.d/jail.orig Mon May 5 15:38:41 2003
+++ etc/rc.d/jail Tue Jul 29 14:49:34 2003
@@ -53,6 +53,16 @@
eval jail_hostname=\\$jail_${_jail}_hostname\
eval jail_ip=\\$jail_${_jail}_ip\
eval jail_exec=\\$jail_${_jail}_exec\
+ eval jail_devfs=\\$jail_${_jail}_mount_devfs\
+ eval jail_procfs=\\$jail_${_jail}_mount_procfs\
+ if [ -n ${jail_devfs} ] checkyesno jail_devfs ; then
+ echo Mounting devfs to ${jail_rootdir}/dev
+ mount -t devfs devfs ${jail_rootdir}/dev
+ fi;
+ if [ -n ${jail_procfs} ] checkyesno jail_procfs ; then
+ echo Mounting procfs to ${jail_rootdir}/proc
+ mount -t procfs procfs ${jail_rootdir}/proc
+ fi;
[ -z ${jail_exec} ] jail_exec=/bin/sh /etc/rc
jail ${jail_rootdir} ${jail_hostname} ${jail_ip} ${jail_exec}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On 29.07.2003 18:47, Robert Watson wrote: On Tue, 29 Jul 2003, Jens Rehsack wrote: I updated the rcng jail start script to mount devfs and procfs into the jail if wanted. Adding entries to /etc/fstab didn't work properly, because the jail filesystem wasn't mounted when the startup process wants to mount it. Going this way allows us to control which jail could be used via ssh (or another remote shell), too. Any comments gladly welcome. If it's useful for FreeBSD, I will write the rc.conf(5) update, too. Please inform me to do this. Neat. :-) Someone, and unfortunately I appear to have lost track of who, had some tweaks to the rcNG scripts to set up some reasonable devfs rules for a jail, and apply them to the devfs mounted in a jail. Otherwise, you risk exposing undesired device nodes to the virtual environment. I suspect a search of the -current archives will turn up who, but I think a necessary part of a solution here will be to make sure jails are set up with the right devfs contents. Sorry, overseen. Sct W. Hetzel was the submitter, but it never becomes committed. If could be be so kind, please :-) (of course, not without prove it first) Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On 29.07.2003 19:21, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote: Yeah, I'll take care of this. I had asked scott to mail me his final patch so I could commit it, but I never heard back from him. I'll dig out the revisions from my mail archives and combine the two. You can mail me the patch first, so that I can test it before you commit it, if you want. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
buildkernel error with -CURRENT on moby with newly gcc 3.3.1
Hi,
I tried to update a machine which will become a webserver in
near future. I received following error in buildkernel:
[...]
cc -c -O -pipe -march=pentium4 -Wall \
-Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline \
-Wcast-qual-fformat-extensions -std=c99 -nostdinc \
-I- -I. -I/usr/src/sys -I/usr/src/sys/dev \
-I/usr/src/sys/contrib/dev/acpica \
-I/usr/src/sys/contrib/ipfilter \
-I/usr/src/sys/contrib/dev/ath \
-I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL \
-include opt_global.h -fno-common \
-mno-align-long-strings \
-mpreferred-stack-boundary=2 -ffreestanding \
/usr/src/sys/dev/ata/ata-all.c
{standard input}: Assembler messages:
{standard input}:7652: Error: invalid character '_' in mnemonic
*** Error code 1
Stop in /usr/obj/usr/src/sys/MOBY.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
The uname -a output is:
FreeBSD moby.helpers.liwing.de 5.1-CURRENT FreeBSD 5.1-CURRENT #0:
Mon Jul 14 11:11:54 GMT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MOBY i386
The lines around the location are:
ata_enclosure_status:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$24, %esp
movl8(%ebp), %edi
movl$6, -16(%ebp)
testb $8, 20(%edi)
ds ; je .L2817
movl(%edi), %eax
movl$1, 4(%esp)
movl%eax, (%esp)
call*248(%eax)
movl(%edi), %ecx
movl$0, %eax
movl$128, %edx
#APP
lock ; cmpxchgl %edx,244(%ecx) ;
setz %al ; movzbl %al,%eax ; 1: #
atomic_cmpset_int
#NO_APP
testl %eax, %eax
jne .L2830
movl$0, %esi
movl$128, %ebx
.L2822:
The line 7652 is the #NO_APP. I must blame myself and say, that I
don't know where #NO_APP stands for, so I don't have any idea where the
error comes from nor how it could be fixed.
The error doesn't appear compiling the file using -march=pentium3, where
the begin of ata_enclosure_status looks like:
ata_enclosure_status:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$24, %esp
movl8(%ebp), %edi
movl$6, -16(%ebp)
testb $8, 20(%edi)
je .L2817
movl(%edi), %eax
movl$1, 4(%esp)
movl%eax, (%esp)
call*248(%eax)
movl(%edi), %ecx
movl$0, %eax
movl$128, %edx
#APP
lock ; cmpxchgl %edx,244(%ecx) ;
setz %al ; movzbl %al,%eax ; 1: #
atomic_cmpset_int
#NO_APP
testl %eax, %eax
jne .L2830
movl$0, %esi
movl$128, %ebx
.p2align 4,,15
.L2822:
Does anyone know what's going on here?
Regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildkernel error with -CURRENT on moby with newly gcc 3.3.1
Jens Rehsack wrote:
Hi,
I tried to update a machine which will become a webserver in
near future. I received following error in buildkernel:
[...]
cc -c -O -pipe -march=pentium4 -Wall \
-Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline \
-Wcast-qual-fformat-extensions -std=c99 -nostdinc \
-I- -I. -I/usr/src/sys -I/usr/src/sys/dev \
-I/usr/src/sys/contrib/dev/acpica \
-I/usr/src/sys/contrib/ipfilter \
-I/usr/src/sys/contrib/dev/ath \
-I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL \
-include opt_global.h -fno-common \
-mno-align-long-strings \
-mpreferred-stack-boundary=2 -ffreestanding \
/usr/src/sys/dev/ata/ata-all.c
{standard input}: Assembler messages:
{standard input}:7652: Error: invalid character '_' in mnemonic
*** Error code 1
Stop in /usr/obj/usr/src/sys/MOBY.
*** Error code 1
Stop in /usr/src.
*** Error code 1
I made some research (as good as I could) and found out/assumed sth.:
1) #APP and #NO_APP will be placed by cc around inline assembly
and forces the assembler to reformat spaces as required to parse
code well.
2) in /usr/obj/usr/src/sys/MOBY/ata-all.s (generated by cc -S)
are 209 #APP/#NO_APP pairs are used, but only above described
one fails.
3) in theory, the error described by me couldn't happen
4) the asm instruction lock ; x ; causes the processor to lock the
execution of instruction x.
b) lock ; x ; y ; cause the processor to lock x and executes y normal
c) lock ; x ; y ; could be written as lock\n\tx\n\t\y\n\t with
same generated binary code
5) if in /usr/src/sys/i386/include/atomic.h the line
movzbl %%al,%0 ;
is changed into
movzbl %%al,%0\n\t ,
the ata-all.c is compiled without any warning.
Regards,
Jens
--
L i W W W i Jens Rehsack
LW W W
L i W W W W i nnnLiWing IT-Services
L iW W W Wi n n g g
i W W i n n g gFriesenstraße 2
06112 Halle
g
g g
Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED]
Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
compile error on moby with newly gcc 3.3.1
Hi,
I tried to update a machine which will become a webserver in
near future. I received following error in buildkernel:
[...]
cc -c -O -pipe -march=pentium4 -Wall \
-Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline \
-Wcast-qual-fformat-extensions -std=c99 -nostdinc \
-I- -I. -I/usr/src/sys -I/usr/src/sys/dev \
-I/usr/src/sys/contrib/dev/acpica \
-I/usr/src/sys/contrib/ipfilter \
-I/usr/src/sys/contrib/dev/ath \
-I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL \
-include opt_global.h -fno-common \
-mno-align-long-strings \
-mpreferred-stack-boundary=2 -ffreestanding \
/usr/src/sys/dev/ata/ata-all.c
{standard input}: Assembler messages:
{standard input}:7652: Error: invalid character '_' in mnemonic
*** Error code 1
Stop in /usr/obj/usr/src/sys/MOBY.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
The lines around the location are:
ata_enclosure_status:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$24, %esp
movl8(%ebp), %edi
movl$6, -16(%ebp)
testb $8, 20(%edi)
ds ; je .L2817
movl(%edi), %eax
movl$1, 4(%esp)
movl%eax, (%esp)
call*248(%eax)
movl(%edi), %ecx
movl$0, %eax
movl$128, %edx
#APP
lock ; cmpxchgl %edx,244(%ecx) ;
setz %al ; movzbl %al,%eax ; 1: #
atomic_cmpset_int
#NO_APP
testl %eax, %eax
jne .L2830
movl$0, %esi
movl$128, %ebx
.L2822:
The line 7652 is the #NO_APP. I must blame myself and say, that I
don't know where #NO_APP stands for, so I don't have any idea where the
error comes from nor how it could be fixed.
The error doesn't appear compiling the file using -march=pentium3, where
the begin of ata_enclosure_status looks like:
ata_enclosure_status:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$24, %esp
movl8(%ebp), %edi
movl$6, -16(%ebp)
testb $8, 20(%edi)
je .L2817
movl(%edi), %eax
movl$1, 4(%esp)
movl%eax, (%esp)
call*248(%eax)
movl(%edi), %ecx
movl$0, %eax
movl$128, %edx
#APP
lock ; cmpxchgl %edx,244(%ecx) ;
setz %al ; movzbl %al,%eax ; 1: #
atomic_cmpset_int
#NO_APP
testl %eax, %eax
jne .L2830
movl$0, %esi
movl$128, %ebx
.p2align 4,,15
.L2822:
Does anyone know what's going on here?
Regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: compile error on moby with newly gcc 3.3.1
Jens Rehsack wrote:
Hi,
I tried to update a machine which will become a webserver in
near future. I received following error in buildkernel:
[...]
cc -c -O -pipe -march=pentium4 -Wall \
-Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline \
-Wcast-qual-fformat-extensions -std=c99 -nostdinc \
-I- -I. -I/usr/src/sys -I/usr/src/sys/dev \
-I/usr/src/sys/contrib/dev/acpica \
-I/usr/src/sys/contrib/ipfilter \
-I/usr/src/sys/contrib/dev/ath \
-I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL \
-include opt_global.h -fno-common \
-mno-align-long-strings \
-mpreferred-stack-boundary=2 -ffreestanding \
/usr/src/sys/dev/ata/ata-all.c
{standard input}: Assembler messages:
{standard input}:7652: Error: invalid character '_' in mnemonic
*** Error code 1
Stop in /usr/obj/usr/src/sys/MOBY.
*** Error code 1
Stop in /usr/src.
*** Error code 1
I made some research (as good as I could) and found out/assumed sth.:
1) #APP and #NO_APP will be placed by cc around inline assembly
and forces the assembler to reformat spaces as required to parse
code well.
2) in /usr/obj/usr/src/sys/MOBY/ata-all.s (generated by cc -S)
are 209 #APP/#NO_APP pairs are used, but only above described
one fails.
3) in theory, the error described by me couldn't happen
4) the asm instruction lock ; x ; causes the processor to lock the
execution of instruction x.
b) lock ; x ; y ; cause the processor to lock x and executes y normal
c) lock ; x ; y ; could be written as lock\n\tx\n\t\y\n\t with
same generated binary code
5) if in /usr/src/sys/i386/include/atomic.h the line
movzbl %%al,%0 ;
is changed into
movzbl %%al,%0\n\t ,
the ata-all.c is compiled without any warning.
Regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
PR/53008
Hi Peter, would you please be so kind and have a look at PR/53008 (http://www.freebsd.org/cgi/query-pr.cgi?pr=53008), because you committed src/sys/i386/acpica/genwakecode.sh and under some circumstances an errornously output is generated (details in PR). The problem hits me when I was updating a plain installed machine (5.1-BETA) to 5-CURRENT one day before release mounting the sources via nfs. Because of a problem with the new pci code I had to switch back to an old kernel but the new world was already active (I know, not installed like recommented in handbook). Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Tweak re-routing of PCI interrupts
On 6/6/2003 9:29 PM, Bernd Walter wrote: On Fri, Jun 06, 2003 at 01:17:43PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : I already wondered how you could route interrupts without ACPI until I : booted my printserver with a recent kernel. PCIBIOS! Well - I'm not very familar with what i386 offer here. Specs are available here, so I could read. But in any case Johns patch revived my printserver (old HX socket7 board). Either my BIOS is broken or FreeBSD doesn't use it correctly. Whatever - I can run tests on that machine if required. I agree to Bernd. I don't know the problem Warner have with the patch, because it removes a big problem on non-acpi machines. Maybe a look to kern/53010 (http://www.freebsd.org/cgi/query-pr.cgi?pr=53010) change Warner's mind. If required, I will test further patches according this problem, too. Jens -- dmesg of machine which now runs with the fix: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #3: Sat Jun 7 12:06:31 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WINNIE Preloaded elf kernel /boot/kernel/kernel at 0xc03a2000. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 199433685 Hz CPU: Pentium Pro (199.43-MHz 686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping = 9 Features=0xf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV real memory = 134217728 (128 MB) avail memory = 126369792 (120 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 pci0: mass storage, ATA at device 1.1 (no driver attached) pci0: unknown at device 2.0 (no driver attached) pci0: unknown at device 2.1 (no driver attached) pci0: display, VGA at device 3.0 (no driver attached) ahc0: Adaptec 2940 Ultra SCSI adapter port 0xf800-0xf8ff mem 0xfedfe000-0xfedfefff irq 11 at device 18.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs ahc1: Adaptec 2940 Ultra SCSI adapter port 0xf400-0xf4ff mem 0xfedff000-0xfedf irq 9 at device 19.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=5, 16/253 SCBs orm0: Option ROM at iomem 0xc-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ed1: Plug Play Ethernet Card at port 0x220-0x23f iomem 0xc8000-0xcbfff irq 3 on isa0 ed1: address 00:c0:26:30:3a:68, type NE2000 (16 bit) unknown: PNP0303 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) Timecounters tick every 10.000 msec Waiting 15 seconds for SCSI devices to settle da1 at ahc1 bus 0 target 0 lun 0 da1: IBM DCAS-32160 S65A Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15) da1: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da0 at ahc0 bus 0 target 0 lun 0 da0: IBM DORS-32160!# WA3E Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) Mounting root from ufs:/dev/da0s1a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/53010: FreeBSD-CURRENT cannot use 2940 UW on SNI Pro C6(Pentium Pro System)
John's tweak patch for re-routing of PCI interrupts seems to work. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
file(1) doesn't recognize scripts correctly
Hi David, hi list, you got this mail, because you maintain src/contrib/file/. If you're not responsible, please let me know and I will find someone else to bother with this :-) I was playing around with file(1) to find a solution for detecting file content correctly. I've detected, that the pattern in src/contrib/file/Magfiles/commands which are useful detecting unknow scripts correctly (lines 44-52), prevents file from detecting eg. perl or scripts correctly. Sample: $ file -b /var/www/data/trevor/flexpage/tools/fpcombinelib a /usr/local/bin/php -Cqe script text executable $ file -b /var/www/data/trevor/flexpage/tools/getPage.pl a /usr/bin/perl script text executable I created a patch which may only a workaround until a script language is added which first letters are bigger than 'various'. Maybe a better solution would be renaming all scripts to 'script.shell', 'script.php', 'script.perl', ... 'script.various' or concatanation order is created. Last one may be the best solution. Please let me know what you think. Sample after patch: $ file -b /var/www/data/trevor/flexpage/tools/getPage.pl perl script text executable $ file -b /var/www/data/trevor/flexpage/tools/fpcombinelib PHP script text executable Regards, Jens diff -uNr Magdir.old/commands Magdir/commands --- Magdir.old/commands Thu Jun 5 09:43:50 2003 +++ Magdir/commands Thu Jun 5 09:46:15 2003 @@ -40,17 +40,6 @@ 0 string #!\ /usr/bin/enva 16string \0 %s script text executable - -# generic shell magic -0 string #!\ / a -3 string \0 %s script text executable -0 string #!\ / a -3 string \0 %s script text executable -0 string #!/ a -2 string \0 %s script text executable -0 string #!\ script text executable -3 string \0 for %s - # PHP scripts # Ulf Harnhammar [EMAIL PROTECTED] 0 string/c=?php PHP script text diff -uNr Magdir.old/varied.script Magdir/varied.script --- Magdir.old/varied.scriptThu Jan 1 00:00:00 1970 +++ Magdir/varied.scriptThu Jun 5 09:46:15 2003 @@ -0,0 +1,11 @@ +# generic shell magic +0 string #!\ / a +3 string \0 %s script text executable +0 string #!\ / a +3 string \0 %s script text executable +0 string #!/ a +2 string \0 %s script text executable +0 string #!\ script text executable +3 string \0 for %s + + ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Removing Sendmail
John Baldwin wrote: On 02-Apr-2003 Peter Schultz wrote: I'm sorry for beating a dead horse. A guy and I from tcbug were just trying to fix his postfix installation, he does not know what happened, it just stopped working. There would not have been a problem if sendmail wasn't tied into the system so closely. I'm just hoping core will say, submit a working solution and it will be done, so that there's a little inspiration here. Pete... First, core@ is not the appropriate body for that type of request. Both current@ and arch@ are much better targets. Second, is NO_SENDMAIL + the postfix port inadequate? The problem I see with that is, that even a minimalistic base install installs things like sendmail, ppp, atm-stuff, g77 and so on. I really think splitting the base in some sub-parts would it make much easier to do NO_SENDMAIL on my own. So I had to remove each not required file separately. That's no good solution. Regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Removing Sendmail
David O'Brien wrote: On Wed, Apr 02, 2003 at 06:01:01PM +0200, Jens Rehsack wrote: The problem I see with that is, that even a minimalistic base install installs things like sendmail, ppp, atm-stuff, g77 and so on. I would love to see the toolchain broken out into its own tarball like NetBSD. It isn't a simple 10min change though. I know. If it would someone had done before :-) It more a wish than a real expectation. Is somewhere a todo list how going on when trying to add eg. NO_PPP? Maybe: update your source to current check directories belong to eg. ppp patch Makefile(s) save patches buildworld reboot to single user mode rm usr/bin usr/lib usr/sbin /usr/libexec make installworld Are there any tests for the world available? If not, maybe a good point starting is writing a test suite which checks working of each not deselected world-component as good as it get's. Regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Removing Sendmail
Terry Lambert wrote: Jens Rehsack wrote: John Baldwin wrote: First, core@ is not the appropriate body for that type of request. Both current@ and arch@ are much better targets. Second, is NO_SENDMAIL + the postfix port inadequate? The problem I see with that is, that even a minimalistic base install installs things like sendmail, ppp, atm-stuff, g77 and so on. I really think splitting the base in some sub-parts would it make much easier to do NO_SENDMAIL on my own. So I had to remove each not required file separately. That's no good solution. So we are back to: o breaking the base system into packages, As it's already done with crypto, krb5, src, ... o either pre-installed with package alternatives to allow deinstall and reinstall, OR No, not deinstall. Decide on first binary sysinstall, maybe with writing a template /etc/make.conf respecting the packages you didn't want. o we are into seperately packaging all mail servers, picking the current one as default, and hacking the heck out of sysinstall to make sure there's a seperate choice item to get one installed No, if someone decides not having eg. an mta (s)he should know about the risk and consequences. ...all so that programs that require the ability to send local mail, many of them base systems components, can function. Only if the wrapper is configured correct (eg. for mail) or not, eg. if ppp or g77 is required but not available. That's what I said in the first place. So we are agreed. I meant other. Maybe now it's more clear. The correct mailing lists for this discussion are [EMAIL PROTECTED] and [EMAIL PROTECTED] I've set followups to [EMAIL PROTECTED] to indicate my own bias and the total lack of space for more sysinstall code on the install floppy... Just 2 more lists to subscribe :-) - may local folder list get slowly huge :-) Regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH: type errors in src-tree
Mark Murray wrote: John Polstra writes: In article [EMAIL PROTECTED], Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: This is wrong. caddr_t should be uniersally replaced with void *. Not quite. There is (or at least used to be) a lot of code that assumed you could do address arithmetic on a caddr_t. You can't do that on a void *, at least not in ANSI C. I think gcc lets you do it, but it's an extension. As I have discovered. I specifically looked for this, and my misreading of the spec is now clear. :-) Yes, but relying on this during fixing out caddr_t may break use of other compilers. Now, that OpenWatcom is released, the FreeBSd port of it should follow. And maybe someone will try to compile the kernel and world with it. If that would work, this would be great, because the watcom compiler generates much better code than gcc does, even than gcc -O3 (and all known optimizations on). So long, Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Dag-Erling Smorgrav wrote: Jens Rehsack [EMAIL PROTECTED] writes: Of course. Very often in ilmid.c the type caddr_t was used, and nearly the same count of 'const char *'s was used. I've searched the include files for caddr_t (core address) and found it defined as 'char *', so I decided to used commonly caddr_t - maybe later I check which of them could be changed into 'c_caddr_t' for being const. But You can of couse replace all 'caddr_t' which 'char *'. This is wrong. caddr_t should be uniersally replaced with void *. Good to know. I think I have done it where it's possible, and where really (unsigned) char *(*) was required, I've used that. There're some places in code where I'm not sure about it's being correct, but that has nothing to do with char */void *. DES Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Sorry for resending (3rd time), but I've found a small typo in the patch
of sbin/atm/ilmid/ilmid.c
Jens
--- sbin/atm/ilmid/ilmid.c.orig Wed Jan 1 18:48:45 2003
+++ sbin/atm/ilmid/ilmid.c Sat Mar 1 13:29:05 2003
@@ -162,7 +162,7 @@
union {
int ival; /* INTEGER/TIMESTAMP */
Objid oval; /* OBJID */
- longaval; /* IPADDR */
+ uint32_taval; /* IPADDR */
charsval[STRLEN]; /* OCTET */
} var;
Variable*next;
@@ -173,10 +173,10 @@
* which doesn't have the last three fields is the TRAP type.
*/
struct snmp_header {
- int pdulen;
- int version;
+ uint32_tpdulen;
+ uint32_tversion;
charcommunity[64];
- int pdutype;
+ uint32_tpdutype;
/* GET/GETNEXT/GETRESP/SET */
int reqid;
@@ -185,11 +185,11 @@
/* TRAP */
Objid enterprise;
- int ipaddr;
+ uint32_tipaddr;
int generic_trap;
int specific_trap;
- int varlen;
+ uint32_tvarlen;
Variable*head,
*tail;
};
@@ -279,7 +279,7 @@
* Temporary buffer for building response packets. Should help ensure
* that we aren't accidently overwriting some other memory.
*/
-u_char Resp_Buf[1024];
+char Resp_Buf[1024];
/*
* Copy the reponse into a buffer we can modify without
@@ -292,7 +292,7 @@
* TRAP generic trap types
*/
char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
- authenticationFailure, egpNeighborLoss,
+ authenticationFailure, egpNeighborLoss,
enterpriseSpecific };
@@ -320,6 +320,9 @@
*/
Objid addressEntry[MAX_UNITS + 1];
+static const char *ilmi_ident_str = ILMI;
+static const size_tilmi_ident_str_len = strlen(ILMI);
+
/*
* When this daemon started
*/
@@ -335,7 +338,7 @@
#defineLOG_FILE/var/log/ilmid
FILE *Log; /* File descriptor for log messages */
-void set_reqid( u_char *, int );
+void set_reqid( caddr_t, uint32_t );
void Increment_DL( int );
void Decrement_DL( int );
@@ -376,7 +379,7 @@
/*
* Utility to pretty print buffer as hex dumps
- *
+ *
* Arguments:
* bp - buffer pointer
* len - length to pretty print
@@ -387,10 +390,10 @@
*/
void
hexdump ( bp, len )
- u_char *bp;
- int len;
+ caddr_t bp;
+ uint32_tlen;
{
- int i, j;
+ uint32_ti, j;
/*
* Print as 4 groups of four bytes. Each byte is separated
@@ -443,7 +446,7 @@
* bufp- pointer to buffer pointer
* plen- pointer to PDU length or NULL if not a concern
*
- * Returns:
+ * Returns:
* bufp- updated buffer pointer
* plen- (possibly) adjusted pdu length
* len - decoded length
@@ -451,21 +454,21 @@
*/
int
asn_get_pdu_len ( bufp, plen )
- u_char **bufp;
- int *plen;
+ caddr_t *bufp;
+ uint32_t*plen;
{
- u_char *bp = *bufp;
- int len = 0;
- int i, b;
+ caddr_t bp =*bufp;
+ uint32_tlen = 0;
+ uint32_ti, b;
b = *bp++;
if ( plen )
- (*plen)--;
-if ( b 0x80 ) {
- for ( i = 0; i (b ~0x80); i++ ) {
+ --(*plen);
+ if ( b 0x80 ) {
+ for ( i = 0; i (b ~0x80); ++i ) {
len = len * 256 + *bp++;
if ( plen )
- (*plen)--;
+ --(*plen);
}
} else
len = b;
@@ -492,12 +495,12 @@
*/
int
asn_get_encoded ( bufp, len )
- u_char **bufp;
- int *len;
+ caddr_t *bufp;
+ uint32_t*len;
{
- u_char *bp = *bufp;
- int val = 0;
- int l = *len;
+ caddr_t bp = *bufp;
+ int val = 0; /* FIXME: signed? sure? */
+ uint32_tl = *len;
/*
* Keep going while high bit is set
@@ -507,7 +510,7 @@
* Each byte can represent 7 bits
*/
val = ( val 7 ) + ( *bp ~0x80 );
- l--;
+ --l;
} while ( *bp++ 0x80 );
*bufp = bp; /* update buffer pointer */
@@ -526,28 +529,28 @@
* plen- pointer to PDU length or NULL if not a concern
*
* Returns:
- * bufp- updated buffer pointer
+ * bufp- updated buffer pointer
* plen- (possibly) updated PDU length
* val - value of encoded
Re: PATCH: type errors in src-tree
Juli Mallett wrote: * De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ] [ Subjecte: Re: PATCH: type errors in src-tree ] Sorry for resending (3rd time), but I've found a small typo in the patch of sbin/atm/ilmid/ilmid.c - u_char **bufp; - Objid *objid; + caddr_t *bufp; + Objid *objid; I understand (and think good catch) on a number of other things, and bogus type-width assumptions being caught, etc. But this? caddr_t considered useless. Maybe you could clarify why you made the changes to use caddr_t? Of course. Very often in ilmid.c the type caddr_t was used, and nearly the same count of 'const char *'s was used. I've searched the include files for caddr_t (core address) and found it defined as 'char *', so I decided to used commonly caddr_t - maybe later I check which of them could be changed into 'c_caddr_t' for being const. But You can of couse replace all 'caddr_t' which 'char *'. Thanx, juli. Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Juli Mallett wrote:
* De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Re: PATCH: type errors in src-tree ]
caddr_t is discouraged, with preference of writing an actual type. caddr_t
is just an obfuscation. I'm unclear what it gains in your context.
Okay, sorry for misusing caddr_t. Here's a patch without any caddr_t,
but with 'char *' and 'const char *'.
Let me know what you're thinking about it.
Jens
--- sbin/atm/ilmid/ilmid.c.orig Wed Jan 1 18:48:45 2003
+++ sbin/atm/ilmid/ilmid.c Sat Mar 1 23:31:29 2003
@@ -162,7 +162,7 @@
union {
int ival; /* INTEGER/TIMESTAMP */
Objid oval; /* OBJID */
- longaval; /* IPADDR */
+ uint32_taval; /* IPADDR */
charsval[STRLEN]; /* OCTET */
} var;
Variable*next;
@@ -173,10 +173,10 @@
* which doesn't have the last three fields is the TRAP type.
*/
struct snmp_header {
- int pdulen;
- int version;
+ uint32_tpdulen;
+ uint32_tversion;
charcommunity[64];
- int pdutype;
+ uint32_tpdutype;
/* GET/GETNEXT/GETRESP/SET */
int reqid;
@@ -185,11 +185,11 @@
/* TRAP */
Objid enterprise;
- int ipaddr;
+ uint32_tipaddr;
int generic_trap;
int specific_trap;
- int varlen;
+ uint32_tvarlen;
Variable*head,
*tail;
};
@@ -279,7 +279,7 @@
* Temporary buffer for building response packets. Should help ensure
* that we aren't accidently overwriting some other memory.
*/
-u_char Resp_Buf[1024];
+char Resp_Buf[1024];
/*
* Copy the reponse into a buffer we can modify without
@@ -292,7 +292,7 @@
* TRAP generic trap types
*/
char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
- authenticationFailure, egpNeighborLoss,
+ authenticationFailure, egpNeighborLoss,
enterpriseSpecific };
@@ -320,6 +320,9 @@
*/
Objid addressEntry[MAX_UNITS + 1];
+static const char ilmi_ident_str[] = ILMI;
+static const size_tilmi_ident_str_len = strlen(ILMI);
+
/*
* When this daemon started
*/
@@ -335,7 +338,7 @@
#defineLOG_FILE/var/log/ilmid
FILE *Log; /* File descriptor for log messages */
-void set_reqid( u_char *, int );
+void set_reqid( char *, uint32_t );
void Increment_DL( int );
void Decrement_DL( int );
@@ -376,7 +379,7 @@
/*
* Utility to pretty print buffer as hex dumps
- *
+ *
* Arguments:
* bp - buffer pointer
* len - length to pretty print
@@ -387,10 +390,10 @@
*/
void
hexdump ( bp, len )
- u_char *bp;
- int len;
+ const char *bp;
+ const uint32_t len;
{
- int i, j;
+ uint32_ti, j;
/*
* Print as 4 groups of four bytes. Each byte is separated
@@ -443,7 +446,7 @@
* bufp- pointer to buffer pointer
* plen- pointer to PDU length or NULL if not a concern
*
- * Returns:
+ * Returns:
* bufp- updated buffer pointer
* plen- (possibly) adjusted pdu length
* len - decoded length
@@ -451,21 +454,21 @@
*/
int
asn_get_pdu_len ( bufp, plen )
- u_char **bufp;
- int *plen;
+ const char ** const bufp;
+ uint32_t* const plen;
{
- u_char *bp = *bufp;
- int len = 0;
- int i, b;
+ const char *bp =*bufp;
+ uint32_tlen = 0;
+ uint32_ti, b;
b = *bp++;
if ( plen )
- (*plen)--;
-if ( b 0x80 ) {
- for ( i = 0; i (b ~0x80); i++ ) {
+ --(*plen);
+ if ( b 0x80 ) {
+ for ( i = 0; i (b ~0x80); ++i ) {
len = len * 256 + *bp++;
if ( plen )
- (*plen)--;
+ --(*plen);
}
} else
len = b;
@@ -492,12 +495,12 @@
*/
int
asn_get_encoded ( bufp, len )
- u_char **bufp;
- int *len;
+ const char ** const bufp;
+ uint32_t* const len;
{
- u_char *bp = *bufp;
- int val = 0;
- int l = *len;
+ const char *bp = *bufp;
+ int val = 0; /* FIXME: signed? sure? */
+ uint32_tl = *len;
/*
* Keep going while high bit is set
@@ -507,7 +510,7 @@
* Each byte can represent 7 bits
*/
val = ( val 7 ) + ( *bp ~0x80 );
- l
Re: PATCH: type errors in src-tree
Barney Wolff wrote:
On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote:
Shouldn't we care about u_char vs char? On some machines it matters,
and on all machines compilers tend to notice and generate warnings.
Yes, usually we should. But I reviewed the code and didn't found a
reason for using 'unsigned char'. I got compiler warning ('couse I have
them enabled all) during compiling the file before I have finished the
patch. But most of the code relies on 'char' and 'u_char' was used for
storing chars only. Do you know any machine which stores signed chars
different than unsigned chars?
But the mixing - which was in it before - was not acceptable.
Jens
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Barney Wolff wrote: On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote: Shouldn't we care about u_char vs char? On some machines it matters, and on all machines compilers tend to notice and generate warnings. Just another question: I turned on '-ansi' and got some warning about a function declaration is not a prototype (all functions are declared in KR style). Is it preferred by the FreeBSD-Team having functions in KR styles or is the Ansi-Style on, too? Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Juli Mallett wrote:
* De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Re: PATCH: type errors in src-tree ]
Barney Wolff wrote:
On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote:
Shouldn't we care about u_char vs char? On some machines it matters,
and on all machines compilers tend to notice and generate warnings.
Just another question: I turned on '-ansi' and got some warning about a
function declaration is not a prototype (all functions are declared in
KR style). Is it preferred by the FreeBSD-Team having functions in KR
styles or is the Ansi-Style on, too?
ANSI is preferred, but mixing style with functional changes is discouraged.
I get the impression your change to width-specified values has a real
correlation to what things need to use, and thus it might fix brokenness
with systems not ILP32.
Ok, patch which complete ansi declarations appended. This fixes
enumerous errors with 'declaration is not a prototype' messages.
Thanx,
juli.
--
L i W W W i Jens Rehsack
LW W W
L i W W W W i nnnLiWing IT-Services
L iW W W Wi n n g g
i W W i n n g gFriesenstraße 2
06112 Halle
g
g g
Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED]
Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/
--- sbin/atm/ilmid/ilmid.c.orig Sun Mar 2 00:30:57 2003
+++ sbin/atm/ilmid/ilmid.c Sun Mar 2 00:50:40 2003
@@ -92,7 +92,8 @@
#defineASN_IPADDR 0x40
#defineASN_TIMESTAMP 0x43
-static char *Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET, ASN_NULL,
ASN_OBJID };
+static const char * const Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET,
+ ASN_NULL, ASN_OBJID };
/*
* Define SNMP PDU types
@@ -103,8 +104,8 @@
#definePDU_TYPE_SET0xA3
#definePDU_TYPE_TRAP 0xA4
-static char *PDU_Types[] = { GET REQUEST, GETNEXT REQUEST, GET RESPONSE, SET
REQUEST,
- TRAP };
+static const char * const PDU_Types[] = { GET REQUEST, GETNEXT REQUEST,
+ GET RESPONSE, SET REQUEST, TRAP };
/*
* Define TRAP codes
@@ -162,7 +163,7 @@
union {
int ival; /* INTEGER/TIMESTAMP */
Objid oval; /* OBJID */
- longaval; /* IPADDR */
+ uint32_taval; /* IPADDR */
charsval[STRLEN]; /* OCTET */
} var;
Variable*next;
@@ -173,10 +174,10 @@
* which doesn't have the last three fields is the TRAP type.
*/
struct snmp_header {
- int pdulen;
- int version;
+ uint32_tpdulen;
+ uint32_tversion;
charcommunity[64];
- int pdutype;
+ uint32_tpdutype;
/* GET/GETNEXT/GETRESP/SET */
int reqid;
@@ -185,11 +186,11 @@
/* TRAP */
Objid enterprise;
- int ipaddr;
+ uint32_tipaddr;
int generic_trap;
int specific_trap;
- int varlen;
+ uint32_tvarlen;
Variable*head,
*tail;
};
@@ -210,7 +211,7 @@
* foresiggrp: FORE specific Objid we see alot of (being connected to FORE
* switches...)
*/
-Objid Objids[] = {
+const ObjidObjids[] = {
#defineSYS_OBJID 0
{{ 8, 43, 6, 1, 2, 1, 1, 2, 0 }},
#defineUPTIME_OBJID1
@@ -279,7 +280,7 @@
* Temporary buffer for building response packets. Should help ensure
* that we aren't accidently overwriting some other memory.
*/
-u_char Resp_Buf[1024];
+char Resp_Buf[1024];
/*
* Copy the reponse into a buffer we can modify without
@@ -291,8 +292,8 @@
/*
* TRAP generic trap types
*/
-char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
- authenticationFailure, egpNeighborLoss,
+const char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
+ authenticationFailure, egpNeighborLoss,
enterpriseSpecific };
@@ -320,6 +321,9 @@
*/
Objid addressEntry[MAX_UNITS + 1];
+static const char ilmi_ident_str[] = ILMI;
+static const size_tilmi_ident_str_len = strlen(ILMI);
+
/*
* When this daemon started
*/
@@ -335,11 +339,11 @@
#defineLOG_FILE/var/log/ilmid
FILE *Log; /* File descriptor for log messages */
-void set_reqid( u_char *, int );
-void Increment_DL( int );
-void Decrement_DL( int );
+static voidset_reqid( char *, uint32_t );
+static voidIncrement_DL( int );
+static voidDecrement_DL( int );
-static char
Re: PATCH: type errors in src-tree
Juli Mallett wrote:
ANSI is preferred, but mixing style with functional changes is discouraged.
I get the impression your change to width-specified values has a real
correlation to what things need to use, and thus it might fix brokenness
with systems not ILP32.
Sorry, it's getting late here - seems that the compiler didn't cast
itself to 'char const **' in line 2279.
Jens
--
L i W W W i Jens Rehsack
LW W W
L i W W W W i nnnLiWing IT-Services
L iW W W Wi n n g g
i W W i n n g gFriesenstraße 2
06112 Halle
g
g g
Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED]
Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/
--- sbin/atm/ilmid/ilmid.c.orig Sun Mar 2 00:30:57 2003
+++ sbin/atm/ilmid/ilmid.c Sun Mar 2 00:56:16 2003
@@ -92,7 +92,8 @@
#defineASN_IPADDR 0x40
#defineASN_TIMESTAMP 0x43
-static char *Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET, ASN_NULL,
ASN_OBJID };
+static const char * const Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET,
+ ASN_NULL, ASN_OBJID };
/*
* Define SNMP PDU types
@@ -103,8 +104,8 @@
#definePDU_TYPE_SET0xA3
#definePDU_TYPE_TRAP 0xA4
-static char *PDU_Types[] = { GET REQUEST, GETNEXT REQUEST, GET RESPONSE, SET
REQUEST,
- TRAP };
+static const char * const PDU_Types[] = { GET REQUEST, GETNEXT REQUEST,
+ GET RESPONSE, SET REQUEST, TRAP };
/*
* Define TRAP codes
@@ -162,7 +163,7 @@
union {
int ival; /* INTEGER/TIMESTAMP */
Objid oval; /* OBJID */
- longaval; /* IPADDR */
+ uint32_taval; /* IPADDR */
charsval[STRLEN]; /* OCTET */
} var;
Variable*next;
@@ -173,10 +174,10 @@
* which doesn't have the last three fields is the TRAP type.
*/
struct snmp_header {
- int pdulen;
- int version;
+ uint32_tpdulen;
+ uint32_tversion;
charcommunity[64];
- int pdutype;
+ uint32_tpdutype;
/* GET/GETNEXT/GETRESP/SET */
int reqid;
@@ -185,11 +186,11 @@
/* TRAP */
Objid enterprise;
- int ipaddr;
+ uint32_tipaddr;
int generic_trap;
int specific_trap;
- int varlen;
+ uint32_tvarlen;
Variable*head,
*tail;
};
@@ -210,7 +211,7 @@
* foresiggrp: FORE specific Objid we see alot of (being connected to FORE
* switches...)
*/
-Objid Objids[] = {
+const ObjidObjids[] = {
#defineSYS_OBJID 0
{{ 8, 43, 6, 1, 2, 1, 1, 2, 0 }},
#defineUPTIME_OBJID1
@@ -279,7 +280,7 @@
* Temporary buffer for building response packets. Should help ensure
* that we aren't accidently overwriting some other memory.
*/
-u_char Resp_Buf[1024];
+char Resp_Buf[1024];
/*
* Copy the reponse into a buffer we can modify without
@@ -291,8 +292,8 @@
/*
* TRAP generic trap types
*/
-char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
- authenticationFailure, egpNeighborLoss,
+const char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
+ authenticationFailure, egpNeighborLoss,
enterpriseSpecific };
@@ -320,6 +321,9 @@
*/
Objid addressEntry[MAX_UNITS + 1];
+static const char ilmi_ident_str[] = ILMI;
+static const size_tilmi_ident_str_len = strlen(ILMI);
+
/*
* When this daemon started
*/
@@ -335,11 +339,11 @@
#defineLOG_FILE/var/log/ilmid
FILE *Log; /* File descriptor for log messages */
-void set_reqid( u_char *, int );
-void Increment_DL( int );
-void Decrement_DL( int );
+static voidset_reqid( char *, uint32_t );
+static voidIncrement_DL( int );
+static voidDecrement_DL( int );
-static char*Months[] = { Jan, Feb, Mar, Apr, May, Jun,
+static const char *Months[] = { Jan, Feb, Mar, Apr, May, Jun,
Jul, Aug, Sep, Oct, Nov, Dec };
/*
@@ -355,14 +359,14 @@
* none
*
*/
-void
-write_timestamp()
+static void
+write_timestamp(void)
{
- time_t clock;
+ time_t cur_clock;
struct tm *tm;
- clock = time ( (time_t)NULL );
- tm = localtime ( clock );
+ cur_clock = time ( (time_t)NULL );
+ tm = localtime ( cur_clock );
if ( Log Debug_Level 1 )
if ( Log != stderr )
@@ -385,12
Re: PATCH: type errors in src-tree
Barney Wolff wrote:
This is an example of what I was pointing out:
On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote:
...
@@ -1444,22 +1420,19 @@
* none- response sent
*
*/
-void
-send_resp ( intf, Hdr, resp )
- int intf;
- Snmp_Header *Hdr;
- u_char *resp;
+static void
+send_resp ( const int intf, Snmp_Header *Hdr, char *resp )
{
int n;
- if ( ilmi_fd[intf] 0 ) {
- n = write ( ilmi_fd[intf], (caddr_t)resp[1], resp[0] );
+ if ( ilmi_fd[intf] 0 ) { /* FIXME: does ilmi_fd[intf] exists? out of range?
*/
+ n = write ( ilmi_fd[intf], resp+1, resp[0] );
...
Here's a case where it matters whether something is u_char or char.
write(2) takes a size_t as its third arg, and extension of a char to
that may not be the same as for u_char, for example on Sparc. If the
response is ever 127 bytes, this will fail. You're going to have to
look carefully at how things are used to see when char is appropriate
and when u_char is necessary.
That is really right, but for those check I have to know more 'bout ATM,
right? I just have detected some compiler errors using
-finline-functions (yes, I'm playing with optimization options :-)). If
you know a real good online-reference, one fine day I'll check it and
check the entire ilmid.c code for valid signment.
Jens
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Barney Wolff wrote:
This is an example of what I was pointing out:
On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote:
...
@@ -1444,22 +1420,19 @@
* none- response sent
*
*/
-void
-send_resp ( intf, Hdr, resp )
- int intf;
- Snmp_Header *Hdr;
- u_char *resp;
+static void
+send_resp ( const int intf, Snmp_Header *Hdr, char *resp )
{
int n;
- if ( ilmi_fd[intf] 0 ) {
- n = write ( ilmi_fd[intf], (caddr_t)resp[1], resp[0] );
+ if ( ilmi_fd[intf] 0 ) { /* FIXME: does ilmi_fd[intf] exists? out of range?
*/
+ n = write ( ilmi_fd[intf], resp+1, resp[0] );
...
Here's a case where it matters whether something is u_char or char.
write(2) takes a size_t as its third arg, and extension of a char to
that may not be the same as for u_char, for example on Sparc. If the
response is ever 127 bytes, this will fail. You're going to have to
look carefully at how things are used to see when char is appropriate
and when u_char is necessary.
Fixed, thanks.
Jens
--- sbin/atm/ilmid/ilmid.c.orig Sun Mar 2 00:30:57 2003
+++ sbin/atm/ilmid/ilmid.c Sun Mar 2 01:45:06 2003
@@ -92,7 +92,8 @@
#defineASN_IPADDR 0x40
#defineASN_TIMESTAMP 0x43
-static char *Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET, ASN_NULL,
ASN_OBJID };
+static const char * const Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET,
+ ASN_NULL, ASN_OBJID };
/*
* Define SNMP PDU types
@@ -103,8 +104,8 @@
#definePDU_TYPE_SET0xA3
#definePDU_TYPE_TRAP 0xA4
-static char *PDU_Types[] = { GET REQUEST, GETNEXT REQUEST, GET RESPONSE, SET
REQUEST,
- TRAP };
+static const char * const PDU_Types[] = { GET REQUEST, GETNEXT REQUEST,
+ GET RESPONSE, SET REQUEST, TRAP };
/*
* Define TRAP codes
@@ -162,7 +163,7 @@
union {
int ival; /* INTEGER/TIMESTAMP */
Objid oval; /* OBJID */
- longaval; /* IPADDR */
+ uint32_taval; /* IPADDR */
charsval[STRLEN]; /* OCTET */
} var;
Variable*next;
@@ -173,10 +174,10 @@
* which doesn't have the last three fields is the TRAP type.
*/
struct snmp_header {
- int pdulen;
- int version;
+ uint32_tpdulen;
+ uint32_tversion;
charcommunity[64];
- int pdutype;
+ uint32_tpdutype;
/* GET/GETNEXT/GETRESP/SET */
int reqid;
@@ -185,11 +186,11 @@
/* TRAP */
Objid enterprise;
- int ipaddr;
+ uint32_tipaddr;
int generic_trap;
int specific_trap;
- int varlen;
+ uint32_tvarlen;
Variable*head,
*tail;
};
@@ -210,7 +211,7 @@
* foresiggrp: FORE specific Objid we see alot of (being connected to FORE
* switches...)
*/
-Objid Objids[] = {
+const ObjidObjids[] = {
#defineSYS_OBJID 0
{{ 8, 43, 6, 1, 2, 1, 1, 2, 0 }},
#defineUPTIME_OBJID1
@@ -279,7 +280,7 @@
* Temporary buffer for building response packets. Should help ensure
* that we aren't accidently overwriting some other memory.
*/
-u_char Resp_Buf[1024];
+char Resp_Buf[1024];
/*
* Copy the reponse into a buffer we can modify without
@@ -291,8 +292,8 @@
/*
* TRAP generic trap types
*/
-char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
- authenticationFailure, egpNeighborLoss,
+const char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
+ authenticationFailure, egpNeighborLoss,
enterpriseSpecific };
@@ -320,6 +321,9 @@
*/
Objid addressEntry[MAX_UNITS + 1];
+static const char ilmi_ident_str[] = ILMI;
+static const size_tilmi_ident_str_len = strlen(ILMI);
+
/*
* When this daemon started
*/
@@ -335,11 +339,11 @@
#defineLOG_FILE/var/log/ilmid
FILE *Log; /* File descriptor for log messages */
-void set_reqid( u_char *, int );
-void Increment_DL( int );
-void Decrement_DL( int );
+static voidset_reqid( char *, uint32_t );
+static voidIncrement_DL( int );
+static voidDecrement_DL( int );
-static char*Months[] = { Jan, Feb, Mar, Apr, May, Jun,
+static const char *Months[] = { Jan, Feb, Mar, Apr, May, Jun,
Jul, Aug, Sep, Oct, Nov, Dec };
/*
@@ -355,14 +359,14 @@
* none
*
*/
-void
-write_timestamp()
+static void
+write_timestamp(void)
{
- time_t clock;
+ time_t cur_clock;
struct tm *tm;
- clock = time ( (time_t)NULL
type errors in src-tree
type
/usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of
`oid_ncmp' from incompatible pointer type
In file included from /usr/src/sbin/atm/ilmid/ilmid.c:2425:
/usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of
`oid_ncmp' from incompatible pointer type
/usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of
`oid_ncmp' from incompatible pointer type
*** Error code 1
Stop in /usr/src/sbin/atm/ilmid.
*** Error code 1
Stop in /usr/src/sbin/atm.
*** Error code 1
...
I've checked the file and saw many problems with declared functions and
used types. As far as I didn't understand why 'asn_get_pdu_len' (and
similar) couldn't be called using a 'caddr_t *' as first argument
instead of 'u_char **', I think it's an error calling 'oid_ncmp' using a
'caddr_t' when a 'Objid *' is available and required by the function (it
casts the 'caddr_t' to 'Objid *'. Further I didn't understand why
'get_local_ip' is called using a 'long *' when a 'int *' is available on
32-bit and 64-bit architectures. Does FreeBSD run on any architecture
where an int may become 32-bit?
I read the source carefully and wondered about much, so I took the
Stevens (Unix Network Programming, Volume 1) and the Kernighan Richie
(Programming in C) out of my bookshelf and try to make the source more
standard conform. So I consequently use 'uint32_t' for an ip-address,
because htonl/ntohl require exact this type and it's more
cross-plattform-safe using that instead of wild int/long casting.
Furthermore I used caddr_t instead of mixing 'uchar *', 'caddr_t' and
'char *'. A real error has been fixed in function 'build_cold_start' and
every possible sizeof(type) has been replaced by sizeof(var). Useless
type casts have been removed.
Because I don't have any atm hardware, I cannot test the results, but i
compiles fine without any errors and can be called. A tester would be
nice :-)
So long,
Jens Rehsack
--
L i W W W i Jens Rehsack
LW W W
L i W W W W i nnnLiWing IT-Services
L iW W W Wi n n g g
i W W i n n g gFriesenstraße 2
06112 Halle
g
g g
Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED]
Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/
--- lib/libc/gen/_pthread_stubs.c.orig Tue Feb 18 18:52:31 2003
+++ lib/libc/gen/_pthread_stubs.c Tue Feb 18 19:05:04 2003
@@ -97,18 +97,18 @@
#defineFUNC_EXP(name) __CONCAT(name, _exp)
#defineSTUB_FUNC(name, idx, ret) \
- static ret FUNC_EXP(name)(void) __unused; \
- static ret FUNC_INT(name)(void) __unused; \
+ extern ret FUNC_EXP(name)(void) __unused; \
+ extern ret FUNC_INT(name)(void) __unused; \
WEAK_REF(FUNC_EXP(name), name); \
WEAK_REF(FUNC_INT(name), __CONCAT(_, name));\
typedef ret (*FUNC_TYPE(name))(void); \
- static ret FUNC_EXP(name)(void) \
+ ret FUNC_EXP(name)(void)\
{ \
FUNC_TYPE(name) func; \
func = (FUNC_TYPE(name))__thr_jtable[idx][0]; \
return (func());\
} \
- static ret FUNC_INT(name)(void) \
+ ret FUNC_INT(name)(void)\
{ \
FUNC_TYPE(name) func; \
func = (FUNC_TYPE(name))__thr_jtable[idx][1]; \
@@ -116,18 +116,18 @@
}
#defineSTUB_FUNC1(name, idx, ret, p0_type) \
- static ret FUNC_EXP(name)(p0_type) __unused;\
- static ret FUNC_INT(name)(p0_type) __unused;\
+ extern ret FUNC_EXP(name)(p0_type) __unused;\
+ extern ret FUNC_INT(name)(p0_type) __unused;\
WEAK_REF(FUNC_EXP(name), name); \
WEAK_REF(FUNC_INT(name), __CONCAT(_, name));\
typedef ret (*FUNC_TYPE(name))(p0_type);\
- static ret FUNC_EXP(name)(p0_type p0) \
+ ret FUNC_EXP(name)(p0_type p0) \
{ \
FUNC_TYPE(name) func; \
func = (FUNC_TYPE(name))__thr_jtable[idx][0]; \
return (func(p0
Re: sparc64 tinderbox failure
David Schultz wrote: Thus spake Doug Barton [EMAIL PROTECTED]: I made the suggestion in another forum that we create subscription lists for these tinderbox messages so that those interested could see them, and those not interested would not need to filter them out. Is anyone else interested in doing it that way? Or is this a solution looking for a problem? I think most people who track -CURRENT are subscribed to current@ precisely because they want to know when things break. Similarly for -STABLE, but that's a moot point because -STABLE doesn't break very often. For people who don't agree with this, there's always procmail; the reports aren't all that frequent that filtering is some sort of burden. I do, however, like the idea of consolidating them and providing more concise summaries. I agree. Even sometimes I hate got tinderbox message, in most cases I'm very interested. Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PATCH: type errors in src-tree
/sbin/atm/ilmid/ilmid.c:2384:
/usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of
`oid_ncmp' from incompatible pointer type
/usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of
`oid_ncmp' from incompatible pointer type
In file included from /usr/src/sbin/atm/ilmid/ilmid.c:2425:
/usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of
`oid_ncmp' from incompatible pointer type
/usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of
`oid_ncmp' from incompatible pointer type
*** Error code 1
Stop in /usr/src/sbin/atm/ilmid.
*** Error code 1
Stop in /usr/src/sbin/atm.
*** Error code 1
...
I've checked the file and saw many problems with declared functions and
used types. As far as I didn't understand why 'asn_get_pdu_len' (and
similar) couldn't be called using a 'caddr_t *' as first argument
instead of 'u_char **', I think it's an error calling 'oid_ncmp' using a
'caddr_t' when a 'Objid *' is available and required by the function (it
casts the 'caddr_t' to 'Objid *'. Further I didn't understand why
'get_local_ip' is called using a 'long *' when a 'int *' is available on
32-bit and 64-bit architectures. Does FreeBSD run on any architecture
where an int may become 32-bit?
I read the source carefully and wondered about much, so I took the
Stevens (Unix Network Programming, Volume 1) and the Kernighan Richie
(Programming in C) out of my bookshelf and try to make the source more
standard conform. So I consequently use 'uint32_t' for an ip-address,
because htonl/ntohl require exact this type and it's more
cross-plattform-safe using that instead of wild int/long casting.
Furthermore I used caddr_t instead of mixing 'uchar *', 'caddr_t' and
'char *'. A real error has been fixed in function 'build_cold_start' and
every possible sizeof(type) has been replaced by sizeof(var). Useless
type casts have been removed.
Because I don't have any atm hardware, I cannot test the results, but i
compiles fine without any errors and can be called. A tester would be
nice :-)
So long,
Jens Rehsack
--
L i W W W i Jens Rehsack
LW W W
L i W W W W i nnnLiWing IT-Services
L iW W W Wi n n g g
i W W i n n g gFriesenstraße 2
06112 Halle
g
g g
Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED]
Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/
--- lib/libc/gen/_pthread_stubs.c.orig Tue Feb 18 18:52:31 2003
+++ lib/libc/gen/_pthread_stubs.c Tue Feb 18 19:05:04 2003
@@ -97,18 +97,18 @@
#defineFUNC_EXP(name) __CONCAT(name, _exp)
#defineSTUB_FUNC(name, idx, ret) \
- static ret FUNC_EXP(name)(void) __unused; \
- static ret FUNC_INT(name)(void) __unused; \
+ extern ret FUNC_EXP(name)(void) __unused; \
+ extern ret FUNC_INT(name)(void) __unused; \
WEAK_REF(FUNC_EXP(name), name); \
WEAK_REF(FUNC_INT(name), __CONCAT(_, name));\
typedef ret (*FUNC_TYPE(name))(void); \
- static ret FUNC_EXP(name)(void) \
+ ret FUNC_EXP(name)(void)\
{ \
FUNC_TYPE(name) func; \
func = (FUNC_TYPE(name))__thr_jtable[idx][0]; \
return (func());\
} \
- static ret FUNC_INT(name)(void) \
+ ret FUNC_INT(name)(void)\
{ \
FUNC_TYPE(name) func; \
func = (FUNC_TYPE(name))__thr_jtable[idx][1]; \
@@ -116,18 +116,18 @@
}
#defineSTUB_FUNC1(name, idx, ret, p0_type) \
- static ret FUNC_EXP(name)(p0_type) __unused;\
- static ret FUNC_INT(name)(p0_type) __unused;\
+ extern ret FUNC_EXP(name)(p0_type) __unused;\
+ extern ret FUNC_INT(name)(p0_type) __unused;\
WEAK_REF(FUNC_EXP(name), name); \
WEAK_REF(FUNC_INT(name), __CONCAT(_, name));\
typedef ret (*FUNC_TYPE(name))(p0_type);\
- static ret FUNC_EXP(name)(p0_type p0) \
+ ret FUNC_EXP(name)(p0_type p0) \
{ \
FUNC_TYPE(name) func; \
func = (FUNC_TYPE(name))__thr_jtable[idx][0
Re: -O2 considered harmful
Andre Guibert de Bruet wrote: On Wed, 26 Feb 2003, Nuno Teixeira wrote: Does -march=k6-2 implies -m3dnow? Or -march=pentiumpro implies -mmmx? I always thought that when I use -march it will enable other porcessor specific optimizations like mmx and 3dnow (if available). IIRC, 166 and 180 Mhz PPros don't support MMX. Neither do PPro's 200: CPU: Pentium Pro (199.43-MHz 686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping = 9 Features=0xf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV I'm seeing differences in compiled code between simple -march=athlon-xp and -march=athlon-xp -mmmx -m3dnow -msse. The documentation says the same: those options have to be enabled to use extended instruction sets. -march/-mcpu just optmizes boundaries of jump labels, variables, etc... - and sometimes the kind of instructions to use, eg. 'loop label' or 'dec bcx, jne label', but that's all, AFAIK. So long, Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -O2 considered harmful
Dag-Erling Smorgrav wrote: It seems that with -O2 on ia32 (-march=k6-2 in my case), gcc will in some cases generate short jumps to targets too far away for the offset to fit in a single byte. A surefire way to reproduce this is to build Mesa (or XFree86-4-libraries, which includes parts of Mesa). Has anybody else run into this? I build world and ports on desktop machines usually using -O2 and never got any problems, except with lang/ezm3. If you tell me, where you've find the problems, I'll tell my gcc to keep the temporaries and check them after a make build. Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.2.2 import might have trashed ld-elf.so.1
leafy wrote: I rebuilt and installed world on Friday and reinstalled ALL my ports with 'portupgrade -ra'. I have found the exact line that will trigger the ld undefined symbol error. /usr/X11R6/bin/uic -nounload -tr tr2i18n -i htmlpageinfo.h ./htmlpageinfo.ui htmlpageinfo.cc.temp ; ret=$?; sed -e s,tr2i18n( \\ ),QString::null,g htmlpageinfo.cc.temp | sed -e s,tr2i18n( \\\, \\ ),QString::null,g | sed -e s,image\([0-9][0-9]*\)_data,img\1_htmlpageinfo,g htmlpageinfo.cc ; rm -f htmlpageinfo.cc.temp ; if test $ret = 0; then echo '#include htmlpageinfo.moc' htmlpageinfo.cc; else rm -f htmlpageinfo.cc ; exit $ret ; fi Error is: /usr/libexec/ld-elf.so.1: /usr/X11R6/plugins/designer/libwizards.so: Undefined symbol _Z22qCleanupImages_wizardsv Grepping the corresponding library: leafy@leafy:/usr/X11R6/plugins/designer$ nm libwizards.so |grep Z22 000256f0 T _Z22qCleanupImages_wizardsv So ld is not finding a symbol which is in the correct library. Jiawei Ye I'm not sure, but isn't the '-f' parameter required, if the portversion didn't change but an upgrade should be forced? Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bg fsck
Harald Schmalzbauer wrote: Hello all, I'm using 5.0-RC2 and after disconnecting a firewire HD and unclean shutdown the system is panicing after reboot (I can login) and a few minutes with the following message: [...] Please tell me if I can provide more infos, but I'm not subscribed so please cc directly. Best regards, -Harry On Dec the 14th was a similar message on the current-list. I recommend to boot in single user mode, fsck'ing your disks, reboot in multi-user mode and cvsup your system. After a rebuild it may work. Hope it helps a little. Best regards, Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Error installing 5.0-RC2 over NFS
Hi, I had a mysterious problem when I try to install from the 5.0-RC2 floppies over NFS. The Loading module if_awi.ko failed message is well known as I can see :-) But when I had configured my network (xl0 inet 10.62.10.23 netmask 255.255.255.0) using sysinstalls mask and bring it up right now, mount_nfs fails with the message: mount_nfs: can't update /var/db/mounttab for 10.62.10.72:/cdrom mount_nfs: /dist: no such file or directory Does anyone know how to fix or workaround? Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fdimage tool on rc2 cd missing
Hi, correct me if I'm wrong, but shouldn't be the fdimage tool for creating disk images under DOS on the first cd of 5.0-RC2 (and later RELEASE)? Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: XFree 4.2.1 doesn't work with last CURRENT
Aurelien Nephtali wrote: On Mon, Dec 23, 2002 at 12:18:45AM +0100, Jens Rehsack wrote: Aurelien Nephtali wrote: Hi, I've upgraded from 4.2.0 to 4.2.1 and now X11 doesn't want to start :/ I've attached the error log. Any help would be appreciated :) -- Aurelien 1) How did you upgrade? 2) What's the name of your machine? I've upgraded using 'portupgrade' tool and my box is a Celeron 700 running on -CURRENT. -- Aurelien portupgrade and what kind of parameters? Send me please following outputs: 'pkg_info' 'dmesg' 'ifconfig -a' 'cat /etc/make.conf' 'cat /etc/rc.conf' I don't care if you're using a i486SX-33 or a Athlon-MP 2.2+ GHz Dual Box, the relevant information is the name of your machine. Please send me the output of previously requested commands. Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: XFree 4.2.1 doesn't work with last CURRENT
Aurelien Nephtali wrote: Hi, I've upgraded from 4.2.0 to 4.2.1 and now X11 doesn't want to start :/ I've attached the error log. Any help would be appreciated :) -- Aurelien 1) How did you upgrade? 2) What's the name of your machine? -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mod_php4 4.2.3 under 5.0-CURRENT
Muhannad Asfour wrote: Hi, I was searching on groups.google.com recently to try to find out how to get mod_php4 compiled under 5.0-CURRENT, and I found your message and thought you might be of some assistance. I recently built a new server and wanted to run 5.0-CURRENT on it. I installed 5.0, cvsupped sources, rebuilt world, updated all of the ports. Everything works great, except the mod_php4 won?t build (Yes, I e-mailed the port maintainer, no reply yet) :( . I was wondering if you got it to build? Here is my error if you might be able to help me: === Building for mod_php4-4.2.3 Making all in Zend /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -O -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c zend_execute_API.c zend_execute_API.c: In function `zend_set_timeout': zend_execute_API.c:782: storage size of `t_r' isn't known zend_execute_API.c:788: `ITIMER_PROF' undeclared (first use in this function) zend_execute_API.c:788: (Each undeclared identifier is reported only once zend_execute_API.c:788: for each function it appears in.) zend_execute_API.c: In function `zend_unset_timeout': zend_execute_API.c:806: storage size of `no_timeout' isn't known zend_execute_API.c:810: `ITIMER_PROF' undeclared (first use in this function) *** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.3/Zend. *** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.3. *** Error code 1 Stop in /usr/ports/www/mod_php4. *** Error code 1 Stop in /usr/ports/www/mod_php4. Any help would greatly be appreciated, since this is a brand new server that needs to be up and running ASAP. Hi Muhannad, I just need a little bit more information to help you, cause I didn't run into compiler errors but in linker errors. Please send me your dmesg output and use the script(1) command to log your entire mod_php4 build process and send me that output, too. And please do not expect fast answers. It's 3:45 am here and I'm going to sleep in near future :-) Thanks, Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mod_php4 4.2.3 under 5.0-CURRENT
Making all in Zend /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -O -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c zend_language_parser.c /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -O -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c zend_language_scanner.c /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -O -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c zend_ini_parser.c zend_ini_parser.c: In function `ini_parse': zend_ini_parser.c:899: warning: assignment makes pointer from integer without a cast zend_ini_parser.c:902: warning: assignment makes pointer from integer without a cast /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -O -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c zend_ini_scanner.c /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -O -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c zend_alloc.c /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -O -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c zend_compile.c /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -O -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c zend_constants.c /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -O -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c zend_dynamic_array.c /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c ./zend_execute.c /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../main -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -DEAPI -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I../TSRM -O -pipe -march=pentium4 -I/usr/local/include -prefer-pic -c zend_execute_API.c zend_execute_API.c: In function `zend_set_timeout': zend_execute_API.c:782: storage size of `t_r' isn't known zend_execute_API.c:788: `ITIMER_PROF' undeclared (first use in this function) zend_execute_API.c:788: (Each undeclared identifier is reported only once zend_execute_API.c:788: for each function it appears in.) zend_execute_API.c: In function `zend_unset_timeout': zend_execute_API.c:806: storage size of `no_timeout' isn't known zend_execute_API.c:810: `ITIMER_PROF' undeclared (first use in this function) *** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.3/Zend. *** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.3. *** Error code 1 Stop in /usr/ports/www/mod_php4. *** Error code 1 Stop in /usr/ports/www/mod_php4. Script done on Fri Dec 20 21:49:43 2002 Thanks. -Original Message- From: Jens Rehsack [mailto:[EMAIL PROTECTED]] Sent: Friday, December 20, 2002 9:25 PM To: Muhannad Asfour Cc: [EMAIL PROTECTED] Subject: Re: mod_php4 4.2.3 under 5.0-CURRENT Muhannad Asfour wrote: Hi, I was searching on groups.google.com recently to try to find out how to get mod_php4 compiled under 5.0-CURRENT, and I found your message and thought you might be of some assistance. I recently built a new server and wanted to run 5.0-CURRENT on it. I installed 5.0, cvsupped sources, rebuilt world, updated all of the ports. Everything works great, except the mod_php4 won?t build (Yes, I e-mailed the port maintainer, no reply yet) :( . I was wondering if you got it to build? Here
Re: I'm leaving the project
Emiel Kollof wrote: * Matt Dillon ([EMAIL PROTECTED]) wrote: Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and flame in another project. Maybe I could join OpenBSD, the seem to share my views on how to deal with other people. Damn, isn't it a little early for april fool? Cheers, Emiel I think it's now time to let it be. It's gone and we've all read it and had our fun (more or less). It's over and we should stop that and care 'bout our own crap. Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade of port audio/id3lib - stdc++ wchar support missing
David O'Brien wrote: On Thu, Dec 12, 2002 at 12:33:18AM +0100, Jens Rehsack wrote: This would pull files off the vendor branch; and before doing that I'd like to know why the GCC developers have commented out those bits. ... But 4.7-STABLE has already support for wchar_t and it works fine So? I want to know why the GCC developers commented out those bits in GCC 3.2.1. I don't care about GCC 2.95 in RELNEG_4. I know that the id3v2 need wchar_t support. That's why I asked for a patch for FreeBSD 5.0-CURRENT which is sent by Tim Robbins. I do not know what exactly is included in 4.7 or in 5.0 but I know that id3v2 and id3lib build fine in 4.7 but didn't in 5.0. I thought it was more or less important because of Greg Lehey PR 9 (ports) which has serverity critical. Maybe you can ask Tim who created the patch why he did it that way. - BEGIN console extract - portupgrade -f id3lib id3v2 [...] Stop in /usr/ports/audio/id3v2. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade542.2 make ** Fix the problem and try again. ** The following packages were not installed or upgraded (*:skipped / !:failed) ! audio/id3lib38 (id3lib-3.8.1) (linker error) ! audio/id3v2 (id3v2-0.1.7) (linker error) - END console extract - Bye Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd problem
Andrew Thompson wrote: On Wed, 2002-12-11 at 05:52, Vasyl S. Smirnov wrote: Hi again. One more strange thing I've just discovered about sshd - two example ssh sessions: 1. ssh nostromo Password: correct password Connection closed by 10.100.76.33 (and the same sig 11/fatal messages on the console) 2. ssh nostromo Password: Enter Password: Enter Password: Enter [EMAIL PROTECTED]'s password: correct password [and SUCCESSFUL login] Now, what do you think about it? The first prompt is from s/key authentication, try putting ChallengeResponseAuthentication no (i think..) in your sshd_config. I know ChallengeResponseAuthentication from a linux system. It askes for a Response instead for a password. If you see the backtrace, you'll see that it couldn't be in direct sshd - it's an error either in pam or sshd gives wrong parameters. Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade of port audio/id3lib - stdc++ wchar support missing
David O'Brien wrote: On Sun, Dec 08, 2002 at 01:13:16PM +0100, Jens Rehsack wrote: David O'Brien wrote: On Thu, Dec 05, 2002 at 07:36:18PM -0600, Scot W. Hetzel wrote: You could try the patch I've attached: cd /usr/src zcat c++-wchar.diff.gz | patch cd gnu/lib/libstdc++ make make install ... Attached is the patch This would pull files off the vendor branch; and before doing that I'd like to know why the GCC developers have commented out those bits. Hi Kris, will the patch applied? What's the current status? If this is to test in order to send the patch to the GNU people that is good. If you hope to get this into FreeBSD directly, the above questions need answering. But 4.7-STABLE has already support for wchar_t and it works fine -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd problem
Vasyl S. Smirnov wrote: On Mon, Dec 09, 2002 at 12:59:44PM -0800, Kris Kennaway wrote: On Mon, Dec 09, 2002 at 05:49:31PM +0100, Jens Rehsack wrote: Can you check the core dump for backtrace and send that? sysctl kern.sugid_coredump=1 sysctl kern.corefile=/tmp/%N.core (or somewhere else writable by an unprivileged user) Ok, I ran gdb sshd sshd.core, then the bt command, here is its output: (gdb) bt #0 0x282670ff in strcasecmp () from /usr/lib/libc.so.5 #1 0x284151f4 in login_access () from /usr/lib/pam_login_access.so.2 #2 0x284150e2 in login_access () from /usr/lib/pam_login_access.so.2 #3 0x28414ef6 in login_access () from /usr/lib/pam_login_access.so.2 #4 0x28414daf in login_access () from /usr/lib/pam_login_access.so.2 #5 0x28414aed in pam_sm_acct_mgmt () from /usr/lib/pam_login_access.so.2 #6 0x281d97dc in openpam_dispatch () from /usr/lib/libpam.so.2 #7 0x281d8d1e in pam_acct_mgmt () from /usr/lib/libpam.so.2 #8 0x08061e05 in tty_parse_modes () #9 0x08062012 in tty_parse_modes () #10 0x0805db3a in tty_parse_modes () #11 0x0805d23a in tty_parse_modes () #12 0x0805cf58 in tty_parse_modes () #13 0x0804e6bf in tty_parse_modes () #14 0x08050166 in tty_parse_modes () #15 0x0804db65 in tty_parse_modes () Is this enough? I'm a bit new to gdb, so I may be missing something. sv Can you please send the gzipped core dump to me? And could you please include a dmesg output. I'll see what it make on my systems. Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd problem
Vasyl S. Smirnov wrote: Hi, Recently I've discovered that I cannot ssh to my box. After looking at the console, I found the following messages: Dec 9 10:09:05 nostromo kernel: pid 63040 (sshd), uid 0: exited on signal 11 Dec 9 10:09:05 nostromo sshd[63038]: fatal: buffer_put_cstring: s == NULL It seems to be a bug in sshd. I havent changed the default configs, except for /etc/ssh/known_hosts. Is anybody getting the same problem? My `uname -a`: FreeBSD nostromo.astral.ntu-kpi.kiev.ua 5.0-RC FreeBSD 5.0-RC #1: Sat Dec 7 14:56:05 EET 2002 [EMAIL PROTECTED]: /usr/obj/usr/src/sys/NOSTROMO i386 sv Can you check the core dump for backtrace and send that? Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstra?e 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade of port audio/id3lib - stdc++ wchar support missing
David O'Brien wrote: On Thu, Dec 05, 2002 at 07:36:18PM -0600, Scot W. Hetzel wrote: You could try the patch I've attached: cd /usr/src zcat c++-wchar.diff.gz | patch cd gnu/lib/libstdc++ make make install ... Attached is the patch This would pull files off the vendor branch; and before doing that I'd like to know why the GCC developers have commented out those bits. Hi Kris, will the patch applied? What's the current status? Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ata device(s) not found - help please
Hi, I tried to install a new firewall machine for my parents and tried using 5.0, because 4.7-STABLE find's the ata-controller only when I have disabled in BIOS. The results from 5.0-DP2 confuses me more. I attach the dmesg.out - please help. Kind regards, Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-DP2 #0: Sat Nov 16 14:13:13 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOOTMFS Preloaded elf kernel /kernel at 0xc080b000. Preloaded mfs_root /mfsroot at 0xc080b090. Calibrating clock(s) ... TSC clock: 99597710 Hz, i8254 clock: 1193810 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter TSC frequency 99546818 Hz CPU: Pentium/P54C (99.55-MHz 586-class CPU) Origin = GenuineIntel Id = 0x525 Stepping = 5 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 50331648 (48 MB) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x00832000 - 0x02ff7fff, 41705472 bytes (10182 pages) avail memory = 40472576 (38 MB) bios32: Found BIOS32 Service Directory header at 0xc00fb5b0 bios32: Entry = 0xfb980 (c00fb980) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb9b0 pnpbios: Found PnP BIOS data at 0xc00fcab0 pnpbios: Entry = e:eb7c Rev = 1.0 Other BIOS signatures found: Intel Pentium detected, installing workaround for F00F bug Initializing GEOMetry subsystem null: null device, zero device mem: memory I/O md0: Preloaded image /mfsroot 4423680 bytes at 0xc03d1304 npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x8000a000 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=04061039) pcib0: SiS 85c501 at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci0: physical bus=0 found- vendor=0x1039, dev=0x0406, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x6000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found- vendor=0x1039, dev=0x0008, revid=0x01 bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0174, size 2, enabled map[14]: type 4, range 32, base 01f4, size 2, enabled map[18]: type 4, range 32, base 0374, size 2, enabled map[1c]: type 4, range 32, base 03f4, size 2, enabled found- vendor=0x1039, dev=0x0601, revid=0x00 bus=0, slot=1, func=1 class=01-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0089, statreg=0x, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base f000, size 24, enabled map[14]: type 3, range 32, base f100, size 24, enabled found- vendor=0x10de, dev=0x0020, revid=0x04 bus=0, slot=13, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=5 powerspec 1 supports D0 D3 current D0 map[10]: type 4, range 32, base 6000, size 8, enabled map[14]: type 1, range 32, base f200, size 8, enabled found- vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=15, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=9 powerspec 2 supports D0 D1 D2 D3 current D0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Generic PCI ATA controller port 0x3f4-0x3f7,0x374-0x377,0x1f4-0x1f7,0x174-0x177 at device 1.1 on pci0 atapci0: Busmastering DMA not supported ata2: iobase=0x0174 altiobase=0x01f6 bmaddr=0x ata2: at 0x174 on atapci0 ata2: unable to allocate interrupt device_probe_and_attach: ata2 attach returned 6 ata3: iobase=0x0374 altiobase=0x03f6 bmaddr=0x ata3: at 0x374 on atapci0 ata3: unable to allocate
Re: OpenOffice and FreeBSD 5.0-Current
a wrote: Hi I am running FreeBSD 5.0-CURRENT (22 Nov 22:52 CET) I did a download of a precompiled OpenOffice 1.0.1_4 package (it is for FreeBSD Current) and installed that one with pkg_add. Ok, that one went fine. But after that, i was not able to start OpenOffice. I get an Segmentation fault, and thats it. So, it is a common problem, or just a problem with my machine (Acer Laptop 512T, 160 MB RAM, 366 Celeron CPU). So, i cant install OpenOffice from the ports, my machine is to slow, and i dont have that much diskspace. asg Maybe others know what's wrong. Can you try to start open office from a terminal and when it's dumping core again, start it using $ gdb -c core [openoffice] and generate a back trace and send them to the list (and maybe to the open office guys). But wait a few minutes - maybe someone other knows what really helps. Bye, jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
using 5.0-RELEASE
Hi, just a question to the possibilies using 5.0-RELEASE. In the early adopters guide (chapter 1) it's written, that 5.0-RELEASE should be as stable as possible to getting a large number of users to test. But if it's not recommented to use it in production environments, what test results do you expect? Wouldn't it better to say: 5.0-CURRENT is not recommented for production environments (as it's said 'bout using -STABLE blindly), 5.0-RELEASE may be used in non-critical environment, but heavily use of backup tool is recommented? I know many companies located in Halle (where we resides) which are using linux, not because it's more stable but because SuSE tells: it's 8.0 and we tested and it's great. The simply believe the recommendation of SuSE (or whoever) and if sth. fails, they think: Hmm - nothing paid, who really cares? And if I take a look to may AIX box, FBSD 5.0-CURRENT is more stable than my AIX 4.3.3, because of the ports tree (in AIX I must do all by myself). Bye, Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: '-ax' option in gcc
Miguel Mendez wrote:
Hi, subject says it all...
A -CURRENT system as of 11/15:
flynn@christine# cat hello.c
#include stdio.h
#include stdlib.h
int main(int argc, char **argv)
{
printf(Hello, foo!\n);
exit(0);
}
flynn@christine# env CFLAGS=-pg -ax make hello
cc -pg -ax -march=pentiumpro hello.c -o hello
cc1: unrecognized option `-ax'
*** Error code 1
Stop in /usr/home/flynn.
Is the -ax option deprecated? It's still present in the man page. No
problem building such program in a -STABLE box with 2.95
Cheers,
The -ax option generates code for profiling. The -ax options doesn't
appears in the current info documentation, which is an actual one
(AFAIK). So I assume, -ax is not supported anymore.
The are new options for that in gcc3, eg. -fprofile-arcs (for generating
profile information) and -fbranch-probabilities (for optimizing using
profile data).
You may also read http://gcc.gnu.org/ for details 'bout the new compiler
and http://gcc.gnu.org/news/profiledriven.html for information about the
new Infrastructure for Profile Driven Optimizations.
Bye,
Jens
--
L i W W W i Jens Rehsack
LW W W
L i W W W W i nnnLiWing IT-Services
L iW W W Wi n n g g
i W W i n n g gFriesenstraße 2
06112 Halle
g
g g
Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED]
Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: duplicate lock
David W. Chapman Jr. wrote: searching archive yields this thread. 'Subject: /usr/src/sys/netinet/udp_usrreq.c:290' looks like I'm not the only one seeing this. This happens on my test machine directly after samba starts ... Can you disable samba from starting just to make sure it isn't the cause? Samba disable, rebooted, error didn't happens again. Samba started by hand, 'duplicate lock ...' error displays. Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade of port audio/id3lib - stdc++ wchar support missing
David O'Brien wrote: On Thu, Nov 07, 2002 at 07:44:43PM +1100, Tim Robbins wrote: You could try the patch I've attached: cd /usr/src zcat c++-wchar.diff.gz | patch cd gnu/lib/libstdc++ make make install Can you ask Kris to try this on the ports cluster before we commit it? I wonder how many ports this could break. Cause I'm the pain in the neck who asks for this - I'm rebuilding all my ports today to check if it works with this patch (cvsup of /usr/src yesterday). The patch applied cleanly and world build and installs fine, even if the duplicate lock keeps and sablot dynamic linker error - but this has happened without the patch, too. I have installed on the test machine gnome2, apache13, perl5.6.1, mod_php4, mysql, postgresql, portupgrade (and the dependencies, of course). Should I test any specific port, too? Regards, Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade of port audio/id3lib - stdc++ wchar support missing
Tim Robbins wrote: On Thu, Nov 07, 2002 at 12:32:18AM +0100, Jens Rehsack wrote: Hi, there two open PR's (PR 44423 and PR 9) related to a problem with audio/id3lib. I downloaded the new version (3.8.1) and made patches for some files, so they should work fine with FreeBSD 5.0 (4.7 not tested, I think gcc3 is required). But I found out, that the libstdc++ which is installed by `make world` doesn't have wchar-support enabled. I do not have expirience in changing modules within freebsd world, so what do I have to do to add wchar-support? Any help would be nice - I didn't had so much time for C/C++ programming last year and I missed it. So I could do some more, too. You could try the patch I've attached: cd /usr/src zcat c++-wchar.diff.gz | patch cd gnu/lib/libstdc++ make make install I'll try it this evening. How big is the chance to include it into FBSD 5.0-Current distribution. Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: duplicate lock
Joel M. Baldwin wrote: FreeBSD outel.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Nov 7 05:13:19 PST 2002 [EMAIL PROTECTED]:/disk2/usr.src/sys/i386/compile/testGeneric.nonsmp i386 acquiring duplicate lock of same type: inp 1st inp @ ../../../netinet/udp_usrreq.c:290 2nd inp @ ../../../netinet/udp_usrreq.c:290 this comes up once right after I boot up. searching archive yields this thread. 'Subject: /usr/src/sys/netinet/udp_usrreq.c:290' looks like I'm not the only one seeing this. This happens on my test machine directly after samba starts ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Upgrade of port audio/id3lib - stdc++ wchar support missing
Hi, there two open PR's (PR 44423 and PR 9) related to a problem with audio/id3lib. I downloaded the new version (3.8.1) and made patches for some files, so they should work fine with FreeBSD 5.0 (4.7 not tested, I think gcc3 is required). But I found out, that the libstdc++ which is installed by `make world` doesn't have wchar-support enabled. I do not have expirience in changing modules within freebsd world, so what do I have to do to add wchar-support? Any help would be nice - I didn't had so much time for C/C++ programming last year and I missed it. So I could do some more, too. Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: uuid.h is not C++ safe
Patrick Hartling wrote: I was just about to put the new DCE 1.1 UUID functions into use in some C++ code, but linking fails because the function prototypes in uuid.h are not protected with the __cplusplus/extern C bits. It's easy enough for me to fix my local copy, but I'm sure this same thing could trip up other people. -Patrick Submit a patch. -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
port security/p5-Authen-PAM doesn't build
Hi folks, I tried to build webmin on 5.0-current and the required port security/p5-Authen-PAM fails to build. At first there was an error in configuration which I have fixed and send the patch (PR ports/ports/44769). Now comes up another error which I'm not able to fix, because it seems that PAM.c has contains more than 1 source file and I never have seen such a thing before and don't know how to handle. Could please anyone applies the patch in his own environment and tries to help me to fix the port? Thanks in advance, Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ISO C99
Hi folks, I saw many warning messages when compiling sth. under -current (as expected) while I turned on the -DNO_WERROR in /etc/make.conf as told in UPDATING. But the warnings are always the same: ISO C89 doesn't support %s, so I thought about turning on the -std=c99 switch. But the kernel compile abouts in des*.S (is no object here), because #Load is not a valid preprocessor directive... So my question is: is the C99 compilation desired or not. If yes, I would try to make patches for every file which doesn't compile fine with -std=c99, otherwise I wouldn't. Kind regards, Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
