Re: panic: probing for non-PCI bus
> > Hmmm, I'll have to open it up to see if it has an AGP slot, but it is in > > the server room at work. :-/ Here is a dmesg with a kernel of about Nov 3. > > > > pcib1: at device 1.0 on pci0 > > pci1: on pcib1 > > Ok, no AGP bus, but you do have a PCI bus that the MP Table doesn't know about. > I'll commit a fix. Note that your system isn't going to work with ACPI. Perhaps > there is a BIOS option to set the interrupt model to APIC rather than PIC that > might fix the ACPI case. Ok, I opened the machine this morning and it does have an AGP slot. I also had a look in the BIOS setup, but didn't see anything to change the interrupt model. The closest I saw was: MPS 1.4 Support - Enabled/Disabled (Enabled) PCI 2.1 Support - Enabled/disabled (Enabled) PNP OS Installed - No/Yes (No) I built a new kernel with your mptable changes included and with acpi enabled, it would panic, but the onboard scsi interrupt doesn't work, so you don't get very far. With acpi disabled, it seems to work fine, although I haven't done much yet. So it looks like I'm up and running again, thanks. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: probing for non-PCI bus
Oops, I missed a not. On Wed, Nov 12, 2003 at 09:01:25AM +0200, John Hay wrote: > > > Hmmm, I'll have to open it up to see if it has an AGP slot, but it is in > > > the server room at work. :-/ Here is a dmesg with a kernel of about Nov 3. > > > > > > pcib1: at device 1.0 on pci0 > > > pci1: on pcib1 > > > > Ok, no AGP bus, but you do have a PCI bus that the MP Table doesn't know about. > > I'll commit a fix. Note that your system isn't going to work with ACPI. Perhaps > > there is a BIOS option to set the interrupt model to APIC rather than PIC that > > might fix the ACPI case. > > Ok, I opened the machine this morning and it does have an AGP slot. > > I also had a look in the BIOS setup, but didn't see anything to change > the interrupt model. The closest I saw was: > > MPS 1.4 Support - Enabled/Disabled (Enabled) > PCI 2.1 Support - Enabled/disabled (Enabled) > PNP OS Installed - No/Yes (No) > > I built a new kernel with your mptable changes included and with acpi > enabled, it would panic, but the onboard scsi interrupt doesn't work, ^^^ not > so you don't get very far. With acpi disabled, it seems to work fine, > although I haven't done much yet. So it looks like I'm up and running > again, thanks. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: mutex inp not owned at in_pcb.c:685
I'm getting one of these panics every time I cd into an amd mountpoint
on one of my machines with today's -current:
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc04fd20f in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc04fd4c7 in panic () at ../../../kern/kern_shutdown.c:550
#3 0xc04f6248 in _mtx_assert (m=0xc1a238cc, what=0,
file=0xc0662af6 "../../../netinet/in_pcb.c", line=685)
at ../../../kern/kern_mutex.c:667
#4 0xc05659c7 in in_pcbdetach (inp=0xc1a23820)
at ../../../netinet/in_pcb.c:685
#5 0xc057827b in tcp_twclose (tw=0xc1d79000, reuse=0)
at ../../../netinet/tcp_subr.c:1725
#6 0xc05660a5 in in_pcblookup_local (pcbinfo=0xc06c36c0, laddr={s_addr = 0},
lport_arg=3248633888, wild_okay=1) at ../../../netinet/in_pcb.c:1002
#7 0xc0565350 in in_pcbbind_setup (inp=0xc1a23680, nam=0xc19254a0,
laddrp=0xc1a236b8, lportp=0xc1a2369a, td=0xc1cee640)
at ../../../netinet/in_pcb.c:353
#8 0xc0565036 in in_pcbbind (inp=0xc1a23680, nam=0xc19254a0, td=0xc1cee640)
at ../../../netinet/in_pcb.c:218
#9 0xc057a7c6 in tcp_usr_bind (so=0x0, nam=0xc19254a0, td=0xc1cee640)
at ../../../netinet/tcp_usrreq.c:252
#10 0xc052c59e in sobind (so=0x0, nam=0xc19254a0, td=0xc1cee640)
at ../../../kern/uipc_socket.c:230
#11 0xc052fb47 in kern_bind (td=0xc1cee640, fd=8, sa=0xc19254a0)
at ../../../kern/uipc_syscalls.c:183
#12 0xc052faf3 in bind (td=0xc1cee640, uap=0xdce90d14)
at ../../../kern/uipc_syscalls.c:163
#13 0xc06186cb in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 8, tf_esi = -1077943876, tf_ebp =
-1077943860, tf_isp = -588706444, tf_ebx = 1019, tf_edx = -1, tf_ecx = 48, tf_eax =
104, tf_trapno = 12, tf_err = 2, tf_eip = 671989471, tf_cs = 31, tf_eflags = 663,
tf_esp = -1077943920, tf_ss = 47})
at ../../../i386/i386/trap.c:1010
#14 0xc06096fd in Xint0x80_syscall () at {standard input}:136
--
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
release build problems, drivers.flp: file system is full
Hi. Release build fails: drivers.flp: file system if full. Can somebody remove some driver from drivers.conf? thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sysinstall fails
Sysinstall fails then attempt to create new file system. error message: cannot get operator gid. how to dial with it? P.S. please, CC me ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on i386/i386
TB --- 2003-11-12 07:36:59 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 07:36:59 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-11-12 07:36:59 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 07:39:12 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-11-12 08:41:22 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 12 08:41:22 GMT 2003 >>> Kernel build for GENERIC completed on Wed Nov 12 08:56:09 GMT 2003 TB --- 2003-11-12 08:56:09 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-12 08:56:09 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 12 08:56:09 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/acpi_timer.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/Osd/OsdDebug.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/Osd/OsdHardware.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/
HEADSUP: netgraph constants changing
Hi all, as I've written a couple of days ago I'm going to bump some constants in the netgraph code that defined various name lengths in the next minutes. I've not received any negative feedback and have the ok from re. If you use netgraph make sure that the kernel, any externally maintained netgraph modules and any user space netgraph stuff (mainly ngctl and nghook) are in sync otherwise they'll not be able to communicate. This is especially important if you use netgraph for booting purposes. No correctly written code should break by this change :-) harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
xscreensaver bug?
Hi, I'm new in FreeBSD. I found that after I lock screen with xscreensaver, I can unlock it with the root's password as well as my normal user's password. I don't think it is a good thing. Is it a bug? Regards, -- Zeng Nan Simple is Beautiful. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sysinstall fails
Okey. I've made fresh (2003) release from HEAD. During installation, sysinstall has troubles creating filesystems. 1). fdisk creates slice with name "ad0p1". and newfs can't find /dev/ad0p1*. 2). if i create slice, then do "rescan devices" or rerun sysinstall, slice has name "ad0s1". but newfs says: "cannot retrive operator gid" 3). I've run "Fixed Shell" and created file "/etc/group" with one line "operator:*:5:root" and newfs created file systems successfuly. is this known issues? P.S. Sorry my bad english. P.P.S. Please, CC' me. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall fails
Hi. On Wed, Nov 12, 2003 at 11:37:03AM +0200, [EMAIL PROTECTED] wrote: > I've made fresh (2003) release from HEAD. > During installation, sysinstall has troubles creating > filesystems. > > 1). fdisk creates slice with name "ad0p1". and newfs > can't find /dev/ad0p1*. > 2). if i create slice, then do "rescan devices" or > rerun sysinstall, slice has name "ad0s1". but > newfs says: "cannot retrive operator gid" > 3). I've run "Fixed Shell" and created file "/etc/group" > with one line "operator:*:5:root" and newfs > created file systems successfuly. > > is this known issues? I can at least say I found the same problem in a snapshot from a few days ago (I think 08 Nov 03) for an install with a Mylex controller, as where the devices were incorrectly referenced as mlx0p1a instead of mlx0s1a and so on. I finally installed an 5.1-REL and updated in that situation, because I just had it around. - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xscreensaver bug?
[EMAIL PROTECTED] wrote: Hi, I'm new in FreeBSD. I found that after I lock screen with xscreensaver, I can unlock it with the root's password as well as my normal user's password. I don't think it is a good thing. Is it a bug? It is not a bug, but rather a feature of xscreensaver. It has (to the best of my knowledge) nothing to do with FreeBSD. If you install xscreensaver on Linux, or some other platform, it will probably allow you to unlock the screen with the root password there too. -- Morten Rodal pgp0.pgp Description: PGP signature
Intel 865 probs
Hi, Having lots of probs with a machine based on an Intel 865 motherboard. Any pointers? Please let me know if you need more info. It seems to run OK unless userland ppp is invoked, after which it falls over within about 30 minutes. External ISDN TA connected to cuaa0 stopped functioning after a couple of days' operation. New TA installed, sources updated, world and kernel built and installed. Thanks in advance, Peter Risdon. server.mydomain.com kernel log messages: a-0xb on isa0 Timecounter "TSC" frequency 2394011744 Hz quality 800 Timecounters tick every 10.000 msec GEOM: create disk ad0 dp=0xc6b02370 GEOM: create disk ad2 dp=0xc6b02070 sa0 at ahc0 bus 0 target 3 lun 0 WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /usr/home was not properly dismounted WARNING: /var was not properly dismounted /var: superblock summary recomputed lock order reversal 1st 0xc70c8afc vm object (vm object) @ vm/swap_pager.c:1323 2nd 0xc097fc80 swap_pager swhash (swap_pager swhash) @ vm/swap_pager.c:1838 3rd 0xc1034378 vm object (vm object) @ vm/uma_core.c:876 Stack backtrace: lock order reversal 1st 0xc71d7090 rtentry (rtentry) @ net/rtsock.c:388 2nd 0xc693b87c radix node head (radix node head) @ net/route.c:1114 Stack backtrace: 1st 0xc0974ab4 route cache (route cache) @ netinet/ip_input.c:781 2nd 0xc7d4ed90 rtentry (rtentry) @ netinet/ip_input.c:781 panic: mutex inp not owned at ../../../netinet/ip_output.c:210 syncing disks, buffers remaining... 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 giving up on 2420 buffers Uptime: 6h55m14s panic: sleeping thread (pid 27) owns a mutex Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Fatal double fault: eip = 0xc07ec9f5 esp = 0xe1c4e000 ebp = 0xe1c4e008 panic: double fault Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep Uptime: 6h55m14s panic: msleep FreeBSD 5.1-CURRENT #0: Mon Nov 10 11:44:45 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENplusSERIAL Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a7. avail memory = 1016430592 (969 MB) pcib1: slot 1 INTA is routed to irq 11 pcib1: slot 8 INTA is routed to irq 11 puc0: port 0xbc00-0xbc1f irq 11 at device 1.0 on pci1 sio4: on puc0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode sio5: on puc0 sio5: type 16550A sio5: unable to activate interrupt in fast mode - using normal mode ahc0: port 0xb800-0xb8ff mem 0xff8ff000-0xff8f irq 3 at device 2.0 on pci1 ahc0: Host Adapter Bios disabled. Using default SCSI device parameters aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs fxp0: port 0xb400-0xb43f mem 0xff8fe000-0xff8fefff irq 11 at device 8.0 on pci1 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface Timecounter "TSC" frequency 2394013308 Hz quality 800 GEOM: create disk ad0 dp=0xc6b02370 GEOM: create disk ad2 dp=0xc6b02070 sa0 at ahc0 bus 0 target 3 lun 0 WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /usr/home was not properly dismounted WARNING: /var was not properly dismounted /var: mount pending error: blocks 4 files 1 /var: superblock summary recomputed FreeBSD 5.1-CURRENT #0: Mon Nov 10 11:44:45 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENplusSERIAL Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a7. avail memory = 1016430592 (969 MB) pcib1: slot 1 INTA is routed to irq 11 pcib1: slot 8 INTA is routed to irq 11 puc0: port 0xbc00-0xbc1f irq 11 at device 1.0 on pci1 sio4: on puc0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode sio5: on puc0 sio5: type 16550A sio5: unable to activate interrupt in fast mode - using normal mode ahc0: port 0xb800-0xb8ff mem 0xff8ff000-0xff8f irq 3 at device 2.0 on pci1 ahc0: Host Adapter Bios disabled. Using d
[current tinderbox] failure on i386/pc98
TB --- 2003-11-12 09:00:29 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 09:00:29 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-11-12 09:00:29 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 09:02:53 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-11-12 10:01:12 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 12 10:01:12 GMT 2003 >>> Kernel build for GENERIC completed on Wed Nov 12 10:13:25 GMT 2003 TB --- 2003-11-12 10:13:25 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-12 10:13:25 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 12 10:13:25 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac/mac_label.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac/mac_net.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac/mac_pipe.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tin
[current tinderbox] failure on ia64/ia64
TB --- 2003-11-12 10:22:41 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 10:22:41 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-11-12 10:22:41 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 10:24:58 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. [...] ===> bin/df cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/../../sbin/mount -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c: In function `prtstat': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 5) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 7) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 5) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-11-12 11:06:35 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 11:06:35 - TB --- ERROR: failed to build world TB --- 2003-11-12 11:06:35 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-11-12 11:06:35 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 11:06:35 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-11-12 11:06:35 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 11:08:36 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. [...] ===> bin/df cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/../../sbin/mount -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c: In function `prtstat': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 5) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 7) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 5) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-11-12 11:45:59 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 11:45:59 - TB --- ERROR: failed to build world TB --- 2003-11-12 11:45:59 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: release build problems, drivers.flp: file system is full
toha> Release build fails: toha> drivers.flp: file system if full. Since yesterday. toha> Can somebody remove some driver from drivers.conf? No, don't do that. Since we have only 3 floppies, simply removing some modules may mean "it cannot use it while installing FreeBSD." Fortunately we have some rooms in mfsroot.flp, we can move some drivers (back?) to there. I'm just trying which module(s) can be moved or not. -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
which 3ware controllers are supported ?
Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? Cheers, Andrew. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: which 3ware controllers are supported ?
On Wednesday 12 November 2003 14:07, Andrew Atrens wrote: > Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? I recommended that a friend of mine. It's running without an Problem under 4.7. I Don't know about newer versions but it should work well. -Harry > > > Cheers, > > Andrew. > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" pgp0.pgp Description: signature
Re: panic related to in_output.c
Bah. Certainly better. The machine was locking every 15-20 minutes. Now
it reboots itself every couple of hours with the following:
panic: lock (sleep mutex) tcp not locked @ /usr/src/sys/netinet/tcp_syncache.c 378
-Steve
On Tue, Nov 11, 2003 at 04:20:20PM -0500, Steve Ames wrote:
> That seems to have done the job (v 1.48 of tcp_syncache.c). At least its
> been up for nearly an hour which is a definate positive!
>
> Thanks.
>
> -Steve
>
> - Original Message -
> From: "Sam Leffler" <[EMAIL PROTECTED]>
> To: "Steve Ames" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Tuesday, November 11, 2003 11:58 AM
> Subject: Re: panic related to in_output.c
>
>
> > On Tuesday 11 November 2003 08:40 am, Steve Ames wrote:
> > > Code from yesterday evening (11/10 around 5PM EST). Just updated this
> > > morning. I saw no updates to ip_output.c but there were changes to a
> couple
> > > of other files in sys/netinet so figured I'd give it a whirl...
> > >
> > > panic: mutex inp not owned at /usr/src/sys/netinet/ip_output.c:218
> > > cpuid= -;
> > > Debugger("panic")
> > > Stopped at Debugger+0x55: xchgl %ebx,in_Deubbger,0
> > > db>
> >
> > I'll commit the fix today. I was waiting for testing feedback from the
> 1st
> > person that tripped the assertion...
> >
> > Sam
> >
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cdparanoia in the ports fails.
I am trying to get cdparanoia from the port to compile but am running into the following: ===> Building for cdparanoia-3.9.8_5 cd interface && gmake all gmake[1]: Entering directory `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' gmake libcdda_interface.a CFLAGS="-O -O -mcpu=pentiumpro" gmake[2]: Entering directory `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' cc -O -O -mcpu=pentiumpro -c scan_devices.c cc -O -O -mcpu=pentiumpro -c common_interface.c cc -O -O -mcpu=pentiumpro -c cooked_interface.c cooked_interface.c: In function `cooked_read': cooked_interface.c:204: error: storage size of `arg' isn't known cooked_interface.c:215: error: `CDIOCREADAUDIO' undeclared (first use in this function) cooked_interface.c:215: error: (Each undeclared identifier is reported only once cooked_interface.c:215: error: for each function it appears in.) gmake[2]: *** [cooked_interface.o] Error 1 gmake[2]: Leaving directory `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' gmake[1]: *** [lib] Error 2 gmake[1]: Leaving directory `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/audio/cdparanoia. system: freebsd 5-current ports 5-current -- Sweetleaf [EMAIL PROTECTED] -- http://www.fastmail.fm - Access your email from home and the web ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cdparanoia in the ports fails.
"Sweetleaf" <[EMAIL PROTECTED]> writes: > I am trying to get cdparanoia from the port to compile but am running > into the following: > > ===> Building for cdparanoia-3.9.8_5 > cd interface && gmake all > gmake[1]: Entering directory > `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' > gmake libcdda_interface.a CFLAGS="-O -O -mcpu=pentiumpro" > gmake[2]: Entering directory > `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' > cc -O -O -mcpu=pentiumpro -c scan_devices.c > cc -O -O -mcpu=pentiumpro -c common_interface.c > cc -O -O -mcpu=pentiumpro -c cooked_interface.c > cooked_interface.c: In function `cooked_read': > cooked_interface.c:204: error: storage size of `arg' isn't known > cooked_interface.c:215: error: `CDIOCREADAUDIO' undeclared (first use in > this function) > cooked_interface.c:215: error: (Each undeclared identifier is reported > only once > cooked_interface.c:215: error: for each function it appears in.) > gmake[2]: *** [cooked_interface.o] Error 1 > gmake[2]: Leaving directory > `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' > gmake[1]: *** [lib] Error 2 > gmake[1]: Leaving directory > `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' > gmake: *** [all] Error 2 > *** Error code 2 > > Stop in /usr/ports/audio/cdparanoia. > > > system: > > freebsd 5-current > > ports 5-current Well, no, the latest cdparanoia port is cdparanoia-3.9.8_6. That fixed the problem you're seeing. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
open office
Does openoffice seem slow to respond to others? Clicking on a menu option such as "file" as to open a file takes about 30sec to give me the drop down menu. Also i have noticed there might be a problem with the way the port built or installed gtk, go to the business card creator and you should see just gibberesh instead of the wizzard layout. I am using the openoffice in the 5-current ports which is 1.1.0. System: amd athlon-xp 1800 w/256 ddr 2700 ram freebsd-5-current with 5-current ports. -- Sweetleaf [EMAIL PROTECTED] -- http://www.fastmail.fm - Does exactly what it says on the tin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: open office
On Wed, 12 Nov 2003, Sweetleaf wrote: > Does openoffice seem slow to respond to others? Clicking on a menu option > such as "file" as to open a file takes about 30sec to give me the drop > down menu. Also i have noticed there might be a problem with the way the > port built or installed gtk, go to the business card creator and you > should see just gibberesh instead of the wizzard layout. I am using the > openoffice in the 5-current ports which is 1.1.0. > > System: amd athlon-xp 1800 w/256 ddr 2700 ram > > freebsd-5-current with 5-current ports. Are you using libc_r, or another of the threading libraries? Interactivity problems in applications can sometimes be attributed to thread-level scheduling or locking problems, either in the application, or due to the threading model. I've found that switching to libkse makes threaded GUI applications a lot more responsive, as the GUI can continue to update while another thread performs slow disk I/O or the like. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel 865 probs
Peter, >Hi, > >Having lots of probs with a machine based on an Intel 865 motherboard. >Any pointers? Please let me know if you need more info. It seems to run >OK unless userland ppp is invoked, after which it falls over within >about 30 minutes. External ISDN TA connected to cuaa0 stopped >functioning after a couple of days' operation. New TA installed, sources >updated, world and kernel built and installed. For what its worth, I had a lot of problems on the I865P board, and It boiled down to memory corruption. The machine had lots of "random" crashes, meanng that they were not occuring when I do something specific. The machine startted to panic as soon as the load got high. I took out the memory, and placed it into another slot and the machine is cruising along happily now. The other questions is what is the date of the -CURRENT tree that is giving this problems? I can recall quite a few problems, which were fixed, that could cause this problem. Jaco van Tonder Magic Developer :: Premsoft Development (Pty) Ltd Direct: +27 11 312 2122 :: Fax: +27 11 312 2122 :: Mobile: +27 83 417 5424 Email: [EMAIL PROTECTED] :: Web: http://www.premsoft.co.za/ Disclaimer: http://www.premsoft.co.za/email_disclaimer.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall fails
On Wed, Nov 12, 2003 at 11:37:03AM +0200, [EMAIL PROTECTED] wrote: > I've made fresh (2003) release from HEAD. > During installation, sysinstall has troubles creating > filesystems. > > 1). fdisk creates slice with name "ad0p1". and newfs > can't find /dev/ad0p1*. > 2). if i create slice, then do "rescan devices" or > rerun sysinstall, slice has name "ad0s1". but > newfs says: "cannot retrive operator gid" Yes. I ran into this just yesterday. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: which 3ware controllers are supported ?
On Wed, Nov 12, 2003 at 03:43:27PM +0100, Harald Schmalzbauer wrote: Content-Description: signed data > On Wednesday 12 November 2003 14:07, Andrew Atrens wrote: > > Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? > > I recommended that a friend of mine. It's running without an Problem under > 4.7. I Don't know about newer versions but it should work well. > > -Harry I have a 3Ware 7000-2 (two-channel, 32-bit) running fine under 5.1-RELEASE, so it'll probably work fine under -CURRENT. However, 3dm from the ports tree does not work. Thanks, Josh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Recent -CURRENT panic (New interrupt code related?); backtrace included
On 12-Nov-2003 Xin LI/李鑫 wrote: > Hello, > > On recently compiled kernels, I often get panics which seemed to be interrupt > related. Among > other things, almost all of them claims that "Kernel trap 30", which seemd to be > strange. > > The kernel I am currently running, namely, > > FreeBSD servers.frontfree.net 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Sat Oct 25 > 22:27:05 CST 2003 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS i386 > > seemed to be ok, however, when I am trying the new kernels (you see, 14 compile and > run > attempts:), it exhibits incredible instablity. > > FreeBSD 5.1-CURRENT #19: Wed Nov 12 12:17:28 CST 2003 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS > > Here is one of the crashdumps I caught. The machine was configured with a UP kernel, > with > DEVICE_POLLING enabled. There are two networking adapters attached to it, a fxp and > a dc, and the > machine itself act as a NAT gateway. The network load is not very heavy. If you > think the > backtrace helpful, or need any more information, please write me and I will try > everything I can > to help. Do you have 'device apic' enabled? If so, can you try using 'options NO_MIXED_MODE'. Barring that, can you try http://www.FreeBSD.org/~jhb/patches/spurious.patch and if that doesn't work http://www.FreeBSD.org/~jhb/patches/atpic.patch? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: probing for non-PCI bus
On 12-Nov-2003 John Hay wrote: >> > Hmmm, I'll have to open it up to see if it has an AGP slot, but it is in >> > the server room at work. :-/ Here is a dmesg with a kernel of about Nov 3. >> > >> > pcib1: at device 1.0 on pci0 >> > pci1: on pcib1 >> >> Ok, no AGP bus, but you do have a PCI bus that the MP Table doesn't know about. >> I'll commit a fix. Note that your system isn't going to work with ACPI. Perhaps >> there is a BIOS option to set the interrupt model to APIC rather than PIC that >> might fix the ACPI case. > > Ok, I opened the machine this morning and it does have an AGP slot. > > I also had a look in the BIOS setup, but didn't see anything to change > the interrupt model. The closest I saw was: > > MPS 1.4 Support - Enabled/Disabled (Enabled) > PCI 2.1 Support - Enabled/disabled (Enabled) > PNP OS Installed - No/Yes (No) > > I built a new kernel with your mptable changes included and with acpi > enabled, it would panic, but the onboard scsi interrupt doesn't work, > so you don't get very far. With acpi disabled, it seems to work fine, > although I haven't done much yet. So it looks like I'm up and running > again, thanks. Yes, your BIOS doesn't include any interrupt routing information in ACPI for using APICs, so your machine isn't going to work with ACPI and 'device apic'. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: HEADSUP: netgraph constants changing
On 12-Nov-2003 Harti Brandt wrote: > > as I've written a couple of days ago I'm going to bump some constants in > the netgraph code that defined various name lengths in the next minutes. > I've not received any negative feedback and have the ok from re. If you > use netgraph make sure that the kernel, any externally maintained netgraph > modules and any user space netgraph stuff (mainly ngctl and nghook) are in > sync otherwise they'll not be able to communicate. This is especially > important if you use netgraph for booting purposes. No correctly written > code should break by this change :-) Please be sure to increment NG_VERSION in ng_message.h. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall fails
On 12-Nov-2003 David O'Brien wrote: > On Wed, Nov 12, 2003 at 11:37:03AM +0200, [EMAIL PROTECTED] wrote: >> I've made fresh (2003) release from HEAD. >> During installation, sysinstall has troubles creating >> filesystems. >> >> 1). fdisk creates slice with name "ad0p1". and newfs >> can't find /dev/ad0p1*. >> 2). if i create slice, then do "rescan devices" or >> rerun sysinstall, slice has name "ad0s1". but >> newfs says: "cannot retrive operator gid" > > Yes. I ran into this just yesterday. The fdisk slice name problem might be related to Marcel's GPT changes to sysinstall. GPT partitions use /dev/ad0pX while MBR slices use /dev/ad0sX. Both are created in the fdisk part of sysinstall. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
atheron driver and netgear WG511T
hi, i get this when inserting my Netgear WG511T card into my laptop: ath0: mem 0x8801-0x8801 irq 11 at device 0.0 on cardbus0 ath0: unable to attach hardware; HAL status 13 device_probe_and_attach: ath0 attach returned 6 the ath manpage says that this chip should be supported... any ideas? regards, bernhard ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall fails
On Wed, Nov 12, 2003 at 12:16:36PM -0500, John Baldwin wrote: > > On 12-Nov-2003 David O'Brien wrote: > > On Wed, Nov 12, 2003 at 11:37:03AM +0200, [EMAIL PROTECTED] wrote: > >> I've made fresh (2003) release from HEAD. > >> During installation, sysinstall has troubles creating > >> filesystems. > >> > >> 1). fdisk creates slice with name "ad0p1". and newfs > >> can't find /dev/ad0p1*. > >> 2). if i create slice, then do "rescan devices" or > >> rerun sysinstall, slice has name "ad0s1". but > >> newfs says: "cannot retrive operator gid" > > > > Yes. I ran into this just yesterday. > > The fdisk slice name problem might be related to Marcel's GPT > changes to sysinstall. GPT partitions use /dev/ad0pX while > MBR slices use /dev/ad0sX. Both are created in the fdisk > part of sysinstall. Yup, my bad. I'll make the code ia64 specific. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on alpha/alpha
TB --- 2003-11-12 17:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 17:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-11-12 17:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 17:04:33 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. [...] ===> bin/df cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/../../sbin/mount -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c: In function `prtstat': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 5) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 7) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 5) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-11-12 17:47:07 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 17:47:07 - TB --- ERROR: failed to build world TB --- 2003-11-12 17:47:07 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: which 3ware controllers are supported ?
Josh Tolbert wrote: On Wed, Nov 12, 2003 at 03:43:27PM +0100, Harald Schmalzbauer wrote: Content-Description: signed data On Wednesday 12 November 2003 14:07, Andrew Atrens wrote: Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? I recommended that a friend of mine. It's running without an Problem under 4.7. I Don't know about newer versions but it should work well. -Harry I have a 3Ware 7000-2 (two-channel, 32-bit) running fine under 5.1-RELEASE, so it'll probably work fine under -CURRENT. However, 3dm from the ports tree does not work. There was a list message about this back in May from [EMAIL PROTECTED] with the subject "Re: 3dmd broken" http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1035474+0+archive/2003/freebsd-current/20030601.freebsd-current which included a tiny binary patch. I tried this with the port version of 3dmd on a 5.1-Release box, and it seems to work OK. Barry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: APIC-UP related panic
I, for one, am always pleased to see these sort of in-depth explanations of these sort of shims. On Tue, Nov 11, 2003 at 11:35:26AM -0500 I heard the voice of John Baldwin, and lo! it spake thus: > > It's documented in /sys/i386/conf/NOTES now along with 'device apic'. For > a longer explanation of what is happening: > [...] > > So, by default, to work around motherboards that don't hook IRQ 0 > up to the I/O APIC, we route IRQ 0 through the the 8259A PICs. > [...] > > However, if NO_MIXED_MODE works, that is actually the more desirable > way to run your system. How common is the need for this? Does turning of mixed mode when it's not needed give any real advantages higher up? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: APIC-UP related panic
"Matthew D. Fuller" <[EMAIL PROTECTED]> writes: > > However, if NO_MIXED_MODE works, that is actually the more desirable > > way to run your system. > How common is the need for this? Does turning of mixed mode when it's > not needed give any real advantages higher up? NO_MIXED_MODE disables a hack which allow FreeBSD to work with mother- boards that lie about how APIC pins are wired. In general, you always want to use NO_MIXED_MODE *except* on hardware that has the bug that makes the mixed-mode hack necessary. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on amd64/amd64
TB --- 2003-11-12 17:47:08 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 17:47:08 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-11-12 17:47:08 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 17:49:08 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. [...] ===> bin/df cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/../../sbin/mount -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c: In function `prtstat': /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 5) /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 7) /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 5) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. TB --- 2003-11-12 18:29:43 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 18:29:43 - TB --- ERROR: failed to build world TB --- 2003-11-12 18:29:43 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sound patch for pop & crackles
Hello All,
Could people experiencing pops and crackles try the attached
patch and set hw.snd.fragps=128. This patch also fixes select on
vchans.
more details in
http://www.freebsd.org/cgi/query-pr.cgi?pr=59208
Thanks,
--Mat
--
I don't even know what street Canada is on.
- Al Capone
--- channel.c.old Wed Nov 12 02:42:43 2003
+++ channel.c Wed Nov 12 03:59:31 2003
@@ -41,6 +41,10 @@
#define DEB(x) x
*/
+static int chn_fragsps = 0;
+SYSCTL_INT(_hw_snd, OID_AUTO, fragsps, CTLFLAG_RW,
+ &chn_fragsps, 1, "max fragments per second, 0 to disable");
+
static int chn_targetirqrate = 32;
TUNABLE_INT("hw.snd.targetirqrate", &chn_targetirqrate);
@@ -59,7 +63,7 @@
return err;
}
SYSCTL_PROC(_hw_snd, OID_AUTO, targetirqrate, CTLTYPE_INT | CTLFLAG_RW,
- 0, sizeof(int), sysctl_hw_snd_targetirqrate, "I", "");
+ 0, sizeof(int), sysctl_hw_snd_targetirqrate, "I", "default fragment targets
this IRQ rate");
static int report_soft_formats = 1;
SYSCTL_INT(_hw_snd, OID_AUTO, report_soft_formats, CTLFLAG_RW,
&report_soft_formats, 1, "report software-emulated formats");
@@ -113,10 +117,17 @@
chn_wakeup(struct pcm_channel *c)
{
struct snd_dbuf *bs = c->bufsoft;
+struct pcmchan_children *pce;
- CHN_LOCKASSERT(c);
- if (SEL_WAITING(sndbuf_getsel(bs)) && chn_polltrigger(c))
- selwakeup(sndbuf_getsel(bs));
+// CHN_LOCKASSERT(c);
+ if (SLIST_EMPTY(&c->children)) {
+ if (SEL_WAITING(sndbuf_getsel(bs)) && chn_polltrigger(c))
+ selwakeup(sndbuf_getsel(bs));
+ } else {
+ SLIST_FOREACH(pce, &c->children, link) {
+ chn_wakeup(pce->channel);
+ }
+ }
wakeup(bs);
}
@@ -931,7 +942,7 @@
{
struct snd_dbuf *b = c->bufhard;
struct snd_dbuf *bs = c->bufsoft;
- int bufsz, irqhz, tmp, ret;
+ int irqhz, tmp, ret;
CHN_LOCKASSERT(c);
if (!CANCHANGE(c) || (c->flags & CHN_F_MAPPED))
@@ -960,14 +971,23 @@
DEB(printf("%s: updating (%d, %d)\n", __func__, blkcnt,
blksz));
}
} else {
+ if ( chn_fragsps != 0 &&
+ sndbuf_getbps(bs) * sndbuf_getspd(bs) / blksz > chn_fragsps)
+ {
+ blksz = sndbuf_getbps(bs) * sndbuf_getspd(bs) / chn_fragsps;
+ tmp = 32;
+ while (tmp < blksz)
+ tmp <<= 1;
+ blksz = tmp;
+ if (blksz * blkcnt > CHN_2NDBUFMAXSIZE)
+ blkcnt = CHN_2NDBUFMAXSIZE / blksz;
+ }
ret = EINVAL;
if ((blksz < 16) || (blkcnt < 2) || (blkcnt * blksz >
CHN_2NDBUFMAXSIZE))
goto out;
ret = 0;
c->flags |= CHN_F_HAS_SIZE;
}
-
- bufsz = blkcnt * blksz;
ret = sndbuf_remalloc(bs, blkcnt, blksz);
if (ret)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: which 3ware controllers are supported ?
On Wed, Nov 12, 2003 at 11:55:34AM -0600, Barry Pederson wrote: > Josh Tolbert wrote: > > >On Wed, Nov 12, 2003 at 03:43:27PM +0100, Harald Schmalzbauer wrote: > >Content-Description: signed data > > > >>On Wednesday 12 November 2003 14:07, Andrew Atrens wrote: > >> > >>>Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? > >> > >>I recommended that a friend of mine. It's running without an Problem > >>under 4.7. I Don't know about newer versions but it should work well. > >> > >>-Harry > > > > > >I have a 3Ware 7000-2 (two-channel, 32-bit) running fine under > >5.1-RELEASE, so it'll probably work fine under -CURRENT. However, > >3dm from the ports tree does not work. > > There was a list message about this back in May from [EMAIL PROTECTED] with the > subject "Re: 3dmd broken" > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1035474+0+archive/2003/freebsd-current/20030601.freebsd-current > > which included a tiny binary patch. I tried this with the port version of > 3dmd on a 5.1-Release box, and it seems to work OK. > > Barry Hi Barry, Interesting. I should have searched. I wasn't running 5.1 back then. :) Either way, thank you. I'll give the patch a shot. Thanks, Josh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS-UP new statfs structure
The statfs structure was updated on Nov 11th with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build and boot a new kernel BEFORE doing a `make world' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. Running an old kernel after a `make world' will cause programs such as `df' that do a statfs system call to fail with a bad system call. Kirk McKusick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: munmap & cp
On 2003-11-11 at 15:31:15 Wiktor Niesiobedzki wrote: > $ mkdir foo > $ cd foo > $ touch foo > $ cp foo foo2 > cp: foo: Invalid argument Yes, I've just run into this problem too, because a large number of ports failed to install because of it. This is because they cp -r a number of directories to be installed, and these obviously contain 0 byte files... :( Since the cp source doesn't seem to have been touched for 4 months, it turns out that the semantics of the munmap call changed suddenly, due to "Open Group Base Specifications Issue 6", see: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/vm_map.c I wonder why mmap of 0 bytes is allowed to succeed, and munmap of the same amount is not, but then again, it's obviously following a standard, which doesn't have to abide to any rules of logic. ;) Anyway, cp (and possibly other tools which use munmap) will need to be fixed. For now, I simply disabled the VM_AND_BUFFER_CACHE_SYNCHRONIZED flag in the Makefile for cp, which simply disables the whole mmap'ing stuff. I don't notice any difference without it... pgp0.pgp Description: PGP signature
Re: HEADS-UP new statfs structure
On Wed, 12 Nov 2003, Kirk McKusick wrote: > The statfs structure was updated on Nov 11th with 64-bit fields > to allow accurate reporting of multi-terabyte filesystem sizes. > > You should build and boot a new kernel BEFORE doing a `make world' > as the new kernel will know about binaries using the old statfs > structure, but an old kernel will not know about the new system > calls that support the new statfs structure. Running an old kernel > after a `make world' will cause programs such as `df' that do a > statfs system call to fail with a bad system call. shouldn't in addition to this mail requested by Scott UPDATING also be updated ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SV: which 3ware controllers are supported ?
-Ursprungligt meddelande- Fran: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Josh Tolbert >> > >>>Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? > >> we use the 7500-8 ATA card on STABLE and CURRENT with 8x160GB drives in RAID 5 mode, we have no problems what soever, and we have replaced drives and successfully rebuilt arrays with no data loss at all. so I guess a works for me (tm) is in order Rgds Matt www.fruitsalad.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on i386/i386
TB --- 2003-11-12 18:29:44 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 18:29:44 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-11-12 18:29:44 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 18:32:52 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-11-12 19:31:11 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 12 19:31:11 GMT 2003 >>> Kernel build for GENERIC completed on Wed Nov 12 19:46:03 GMT 2003 TB --- 2003-11-12 19:46:03 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-12 19:46:03 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 12 19:46:03 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_partition/mac_partition! .c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_portacl/mac_portacl.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_seeotheruids/mac_seeoth! eruids.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i3
Re: Intel 865 probs
Jaco, Thanks for this. Jaco H. van Tonder wrote: For what its worth, I had a lot of problems on the I865P board, and It boiled down to memory corruption. The machine had lots of "random" crashes, meanng that they were not occuring when I do something specific. The machine startted to panic as soon as the load got high. I took out the memory, and placed it into another slot and the machine is cruising along happily now. I played with the memory slots as soon as the problems started, and found memtest would sometimes throw up huge numbers of errors, and sometimes none at all. FWIW slot 1 was the worst. But I suspect, no more than that, some other problem as well. The other questions is what is the date of the -CURRENT tree that is giving this problems? I can recall quite a few problems, which were fixed, that could cause this problem. Nov 10. I ran cvsup at about 9:00am GMT. Peter Risdon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on i386/pc98
TB --- 2003-11-12 19:56:57 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 19:56:57 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-11-12 19:56:57 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 19:59:09 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-11-12 20:57:31 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 12 20:57:31 GMT 2003 >>> Kernel build for GENERIC completed on Wed Nov 12 21:09:45 GMT 2003 TB --- 2003-11-12 21:09:45 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-12 21:09:45 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 12 21:09:45 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_partition/mac_partition! .c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_portacl/mac_portacl.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_seeotheruids/mac_seeoth! eruids.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-11-12 21:34:58 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 21:34:58 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-11-12 21:34:58 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 21:36:59 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> lib/libpam/modules/pam_permit cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_permit/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_permit/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_permit/pam_permit.c building static pam_permit library ranlib libpam_permit.a ===> lib/libpam/modules/pam_radius cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/pam_radius.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/pam_radius.c: In function `build_access_request': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/pam_radius.c:114: warning: cast increases required alignment of target type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-11-12 21:49:24 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 21:49:24 - TB --- ERROR: failed to build world TB --- 2003-11-12 21:49:24 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Still getting NFS client locking up
On Mon, Nov 10, 2003 at 11:28:40AM -0500, Robert Watson wrote: > How fast are your systems, speaking of which? I live in the world of > 300-500 mhz machines at work, and 300-800 mhz boxes at home. If you're > using multi-ghz boxes, that could well be the distinguishing factor > between our configurations... I collected some information from my client and server, just before my server crashed (probably because of this), including a tcpdump of the last seconds before it stops... http://www.stack.nl/~marcolz/FreeBSD/NFS/ Zlo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: munmap & cp [patch enclosed]
On Wed, Nov 12, 2003 at 08:18:05PM +0100, Dimitry Andric wrote:
> On 2003-11-11 at 15:31:15 Wiktor Niesiobedzki wrote:
>
> > $ mkdir foo
> > $ cd foo
> > $ touch foo
> > $ cp foo foo2
> > cp: foo: Invalid argument
> Anyway, cp (and possibly other tools which use munmap) will need to be
> fixed. For now, I simply disabled the VM_AND_BUFFER_CACHE_SYNCHRONIZED
> flag in the Makefile for cp, which simply disables the whole mmap'ing
> stuff. I don't notice any difference without it...
I would still propose my one-line solution, to use mmap only when the file
size is greater than 0. As far as I looked into source tree, most usages of
munmap are in unsafe way - i.e. without checking the return value.
Is there someone willing to commit this trival change? For now, some number of
ports will refuse tu build/install.
Cheers,
Wiktor Niesiobedzki
PS. The acctual patch attached.
--- utils.c 2003/06/22 07:02:17 1.41
+++ utils.c 2003/11/11 14:32:17
@@ -133,7 +133,7 @@
* wins some CPU back.
*/
#ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED
+ if (S_ISREG(fs->st_mode) && fs->st_size <= 8 * 1048576 && fs->st_size > 0) {
- if (S_ISREG(fs->st_mode) && fs->st_size <= 8 * 1048576) {
if ((p = mmap(NULL, (size_t)fs->st_size, PROT_READ,
MAP_SHARED, from_fd, (off_t)0)) == MAP_FAILED) {
warn("%s", entp->fts_path);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
buildworld failure on sparc64?
===> lib/libpam/modules/pam_radius cc -O -pipe -I/usr/src/lib/libpam/modules/pam_radius/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_radius/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libpam/modules/pam_radius/pam_radius.c /usr/src/lib/libpam/modules/pam_radius/pam_radius.c: In function `build_access_request': /usr/src/lib/libpam/modules/pam_radius/pam_radius.c:114: warning: cast increases required alignment of target type *** Error code 1 Stop in /usr/src/lib/libpam/modules/pam_radius. *** Error code 1 Stop in /usr/src/lib/libpam/modules. *** Error code 1 ? -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Still getting NFS client locking up
On November 11, 2003 11:36 pm, Janet Sullivan wrote: > So far I only have problems in a mixed -STABLE/-CURRENT environment. > When the client & server are both -CURRENT I haven't had any problems. I just installed another -STABLE box to see if keeping them both -STABLE helps. I haven't really tested the NFS yet as I didn't want to risk locking the box up in the middle of a buildworld. So i just mounted the NFS drive on the new test box and left it Within an hour the NFS server box doing the build world was locked up solid. I can't say if it was NFS mount related or not; nfsd wasn't really doing anything. Doesn't seem like it would have been. Beginning to wonder if it is some strange hardware problem on this box; which coincidentally only shows up when there's an nfs mount! But that doesn't explain why my normally rock solid desktop system tanked when being tested as an NFS client to that STABLE box. Hmmm... Back to testing. I'm doing heavy disk I/O tests without any NFS mounts now. If they go okay, back to the NFS mounting and testing... It seems to me there is something desperately wrong with NFS is mixing -CURRENT and -STABLE NFS server/clients causes either side (in my case both sides) to lock up solid. I mean, problems are problems... but solid lockups with no crash messages or anything is ... nasty. > Are the folks seeing hangs getting any kind of console error messages? I see nothing. My server is completely locks up. Nothing responds. The drive light (the times i've noticed) is frozen "on". On my desktop box the mouse is dead as well. > I don't see anything - performance just tanks to the point of being > unusable. When testing with my desktop box as client, i noticed just before or just when the NFS locked up the mouse and keyboard response would be very erratic ... slow and jerky. -- Tim Middleton | Cain Gang Ltd | "Who is Ungit?" said he, still holding [EMAIL PROTECTED] | www.Vex.Net | my hands. --C.S.Lewis (TWHF) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADSUP: I toasted SMP
My turnstile changes have toasted SMP on current. Symptoms include a page fault in the priority propagation code. If I can't get it fixed tomorrow I will back out the turnstile changes. For now you can do 'set kern.smp.disabled=1' at the loader prompt to disable SMP and your kernel should still work fine as a UP kernel. Sorry for the inconvenience. :( -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Still getting NFS client locking up
On Wed, 12 Nov 2003, Tim Middleton wrote: > On November 11, 2003 11:36 pm, Janet Sullivan wrote: > > So far I only have problems in a mixed -STABLE/-CURRENT environment. > > When the client & server are both -CURRENT I haven't had any problems. > > I just installed another -STABLE box to see if keeping them both -STABLE > helps. I haven't really tested the NFS yet as I didn't want to risk > locking the box up in the middle of a buildworld. If we can demonstrate the problem with both systems as -STABLE, that rules out a lot of things, and might also raise some questions about the hardware. > So i just mounted the NFS drive on the new test box and left it > Within an hour the NFS server box doing the build world was locked up > solid. I can't say if it was NFS mount related or not; nfsd wasn't > really doing anything. Doesn't seem like it would have been. Beginning > to wonder if it is some strange hardware problem on this box; which > coincidentally only shows up when there's an nfs mount! But that doesn't > explain why my normally rock solid desktop system tanked when being > tested as an NFS client to that STABLE box. Hmmm... One of the problems that can occur in -STABLE is a cascading failure when one file system is jammed up (i.e., an NFS mount from another system). Processes hang holding locks in NFS because the NFS session is stalled; other processes try to aquire the hold locks while holding additional locks, and before you know it a lot of very useful locks are held and can't be released due to an inability to free up locks at the cause. Many aspects of this problem are believed to be resolved in -CURRENT, but it's a touch cookies to crack without redoing VFS locking. If you have a spare system, it might be really interesting to install -STABLE on it, replicate data from your file server, point the client at that, and see if the problem still occurs there with the same load. You might also try swapping network cards: perhaps we're looking at a network device driver problem where loss of key packets, or packets over a certain size, is causing an unrecoverable failure. > Back to testing. I'm doing heavy disk I/O tests without any NFS mounts > now. If they go okay, back to the NFS mounting and testing... > > It seems to me there is something desperately wrong with NFS is mixing > -CURRENT and -STABLE NFS server/clients causes either side (in my case both > sides) to lock up solid. I mean, problems are problems... but solid lockups > with no crash messages or anything is ... nasty. Clearly there's a substantial problem, but it sounds like we're still having a lot of trouble identifying the circumstances that trigger the problem, and attempting to narrow things down. One of the problem with distributed system debugging is that it's often hard to track the problem down to a particular source when you catch it partway through a cascading failure. For example, it could well be that a server problem is triggering client symptoms, or it could be that a serious client problem might consume resources on the server such that other clients couldn't operate. Under these circumstances, it can be very difficult to track it down to a particular cause (a missing unlock on the server, for example). > > Are the folks seeing hangs getting any kind of console error messages? > > I see nothing. My server is completely locks up. Nothing responds. The > drive light (the times i've noticed) is frozen "on". On my desktop box > the mouse is dead as well. I can't help but wonder if the server isn't suffering an under-reported hardare failure. It might be interesting to see how quickly the problem vanishes when exchanging various elements. > > I don't see anything - performance just tanks to the point of being > > unusable. > > When testing with my desktop box as client, i noticed just before or > just when the NFS locked up the mouse and keyboard response would be > very erratic ... slow and jerky. This might suggest a high RPC load, deep queues in processing, or key locks held for extended periods of time. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
undelete for FreeBSD current?
I've done a bad thing and need to recover a single file in /usr/local/etc/rc.d/ after a rm -rf of /usr/local I've kept the file system relatively quiet since then. Is there a port that can achieve this? Otherwise pointers to web sites or mail archives regarding the use of fsdb to achieve this would be helpful. Please no replies about backups. Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Edinburgh PO Box 1500 EDINBURGH South Australia 5111 IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: undelete for FreeBSD current?
On Thu, Nov 13, 2003 at 11:30:51AM +1030, Thyer, Matthew wrote: > I've done a bad thing and need to recover a single file in /usr/local/etc/rc.d/ > after a rm -rf of /usr/local > > I've kept the file system relatively quiet since then. TCT may help. http://www.porcupine.org/forensics/tct.html but I don't think it's been tested with current/ufs2. Also, don't expect to build it on the system and then find a deleted file. But if you have a clue of what you're looking for, just grepping /dev/da or /dev/ad might work. (grep -a -A100 -B100) -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: drm, irqs, etc.
[ updating for completeness ] On Wed, 5 Nov 2003, Eric Anholt wrote: > On Wed, 2003-11-05 at 21:24, Mike Hoskins wrote: > > i've got XFree86 4.3.0 installed, from the "X-4" meta port. that went > > smoothly. using the mga driver with a matrox g450 (dual head). no dri on > > head 2 as expected, but again no obvious problems. > > what i've noticed (this is 5.1-p8) is that after X has been running for > > awhile, trying to exit X causes a hang. > 5.1 is -current, not -stable, so you should be mailing the -current > list. I've reset the cc: appropriately. i'm always confused about that, since i cvsup RELENG_5_1 not "." -- and don't usually view something that's been tagged as a RELEASE the same as CURRENT. ;) but thanks for moving this to the correct list. > If you're not using up to date -current, please upgrade to -current past > October 24th, which included some DRM IRQ fixes. If the problem > persists, could you check that it doesn't happen with the DRI disabled > in your XF86Config? same configuration, now running: FreeBSD mojo.sfo.televoke.net 5.1-RELEASE-p10 FreeBSD 5.1-RELEASE-p10 #0: Mon Nov 10 16:33:20 PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MOJO i386 has not exhibited the behavior... if it reoccurs i will update the list, but it appears to happy for now. thanks, -mrh -- From: "Spam Catcher" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Do NOT send email to the address listed above or you will be added to a blacklist! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Who needs these silly statfs changes...
...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! enigma# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0a 205434 123332 6566865%/ devfs 11 0 100%/dev /dev/da0e 7957764 713336818777697%/usr rot13:/mnt2 56595176 54032286 18014398507517260 0%/rot13/mnt2 Kris "Now accepting payment for data hosting" Kennaway pgp0.pgp Description: PGP signature
Re: drm, irqs, etc.
> Date: Wed, 12 Nov 2003 17:43:02 -0800 (PST) > From: Mike Hoskins <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > [ updating for completeness ] > On Wed, 5 Nov 2003, Eric Anholt wrote: > > On Wed, 2003-11-05 at 21:24, Mike Hoskins wrote: > > > i've got XFree86 4.3.0 installed, from the "X-4" meta port. that went > > > smoothly. using the mga driver with a matrox g450 (dual head). no dri on > > > head 2 as expected, but again no obvious problems. > > > what i've noticed (this is 5.1-p8) is that after X has been running for > > > awhile, trying to exit X causes a hang. > > 5.1 is -current, not -stable, so you should be mailing the -current > > list. I've reset the cc: appropriately. > > i'm always confused about that, since i cvsup RELENG_5_1 not "." -- and > don't usually view something that's been tagged as a RELEASE the same as > CURRENT. ;) but thanks for moving this to the correct list. In reality, 5.0 and 5.1 are neither, but questions have to go somewhere and it was announced some time ago that until a V5 version was declared 'STABLE', that questions should go to CURRENT and not STABLE. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
I've been thinking about this all day... Thus spake Jesper Skriver <[EMAIL PROTECTED]> [23:53:26 11/12/03: : > + /* : > +* Only unicast IP, not from loopback, no L2 or IP broadcast, : > +* no multicast, no INADDR_ANY : > +*/ : > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || : > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) || : : #jesper : You will never see packets with a multicast source address. Do you mean: Any packets with a multicast source address will be dropped by the kernel before this point, or that no host will ever send a packet with a multicast source address? In the former, that's fine. In the latter, how does one guarantee that there isn't a malicious host out there sending spoofed multicast-source packets? - Damian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: undelete for FreeBSD current?
On Wed, 12 Nov 2003, Barney Wolff wrote: > On Thu, Nov 13, 2003 at 11:30:51AM +1030, Thyer, Matthew wrote: > > I've done a bad thing and need to recover a single file in /usr/local/etc/rc.d/ > > after a rm -rf of /usr/local > > > > I've kept the file system relatively quiet since then. > > TCT may help. http://www.porcupine.org/forensics/tct.html but I don't > think it's been tested with current/ufs2. Also, don't expect to build > it on the system and then find a deleted file. > > But if you have a clue of what you're looking for, just grepping > /dev/da or /dev/ad might work. (grep -a -A100 -B100) Assuming that the file system had a fair amount of free space, and therefore wasn't fragmented, I've always found the "strings" command quite helpful in recovering text files after loss or deletion. It can also be nicely applied to /dev/mem if you accidentally close that pesky editor window without save... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
new interrupt code breaks fbsd as VMWare guest
5.1-CURRENT-20031110-JPSNAP causes VMWare Workstation 4.0.5 on XP to throw a NOT_IMPLEMENTED message and die, while 20031025-JPSNAP works fine. The last few lines displayed during verbose boot are: ioapic0: routing intpin 1 (IRQ 1) to cluster 0 ioapic0: routing intpin 3 (IRQ 3) to cluster 0 ioapic0: routing intpin 4 (IRQ 4) to cluster 0 ioapic0: routing intpin 6 (IRQ 6) to cluster 0 ioapic0: routing intpin 7 (IRQ 7) to cluster 0 ioapic0: routing intpin 8 (IRQ 8) to cluster 0 setting kern.smp.disabled=1 at the loader prompt doesn't help. Verbose boot messages attached. regards, JohnSMAP type=01 base= len=0009f800 SMAP type=02 base=0009f800 len=0800 SMAP type=02 base=000dc000 len=4000 SMAP type=02 base=000e4000 len=0001c000 SMAP type=01 base=0010 len=03e0 SMAP ty3f0 len=0010 SMAP type=02 base=fec0 len=0001 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fffe len=0002000Copyright (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-20031110-JPSNAP #0: Mon Nov 10 05:25:06 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0ead000. Preloaded mfs_root "/boot/mfsroot" at 0xc0ead254. MPTable: Calibrating clock(s) ... i8254 clock: 1233701 Hz 1233701 Hz differs from default of 1193182 Hz by more than 1% Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1074032664 Hz CPU: AMD Duron(tm) Processor (1074.03-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x671 Stepping = 1 Features=0x383fbff Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 67108864 (64 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x01029000 - 0x03eb9fff, 48828416 bytes (11921 pages) avail memory = 51453952 (49 MB) bios32: Found BIOS32 Service Directory header at 0xc00f7040 bios32: Entry = 0xfd880 (c00fd880) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd880+0x120 pnpbios: Found PnP BIOS data at 0xc00f70a0 pnpbios: Entry = f:985d Rev = 1.0 Other BIOS signatures found: ioapic0: Assuming intbase of 0 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, o) ioapic0: intpin 23 -> irq 23 (level, activelo) ioapic0: intpin 1 trigger: edge ioapic0: intpin 1 polarity: active-hi ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: active-hi ioapic0: intpin 3 trigger: edge ioapic0: intpin 3 polarity: actin 4 trigger: edge ioapic0: intpin 4 polarity: active-hi ioapic0: intpin 5 trigger: edge ioapic0: intpin 5 polarity: active-hi ioapic0: intpin 6 trigger: edge ioapic0: intpin 6 polarity: active-hi ioapic0: intpin 7 trigger: edge ioapic0: intpin 7 polarity: active-hi ioapic0: intpin 8 trigger: edge ioapic0: intpin 8 polarity: active-hi ioapic0: intpin 17 trigger: level ioapic0: intpin 17 polarity: active-lo iointpin 10 trigger: edge ioapic0: intpin 10 polarity: active-hi ioapic0: intpin 11 trigger: edge ioapic0: intpin 11 polarity: ntpin 12 polarity: active-hi ioapic0: intpin 13 trigger: edge ioapic0: intpin 13 polarity: active-hi ioapic0: intpin 14 trigger: edge ioapic0: intpin 14 polarity: active-hi ioapic0: intpin 15 trigger: edge ioapic0: intpin 15 polarity: active-hi lapiINT1 trigger: edge lapic: LINT1 polarity: active-hi ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00040011 LDR
GNOME users should recompile gnomevfs2 after today update
I found that the new statfs changes cause nautilus to crash on startup. The fix is to recompile/reinstall devel/gnomevfs2. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Recent -current hangs on Tyan S2460 before finishing boot
Hello, I'm having trouble getting recent (post- "device apic", pre- turnstile) kernels to boot on my Tyan S2460 (Tiger MP) system with dual AMD Athlons. What happens is that the machine seems to get "stuck" soon after the "Waiting for SCSI devices to settle" message is printed -- it appears to be willing to wait forever rather than the SCSI_DELAY time. Disabling ACPI in the BIOS has no apparent effect on the hang. Using SCHED_4BSD or SCHED_ULE likewise makes no difference. I've been following the current@ list hoping to see someone else report a problem similar to mine but haven't seen anything yet. I do have a serial console attached to the machine and DDB enabled so I'm able to provide some information and get more if needed. I'm including a copy of the boot messages from my last attempt to boot "FreeBSD 5.1-CURRENT #2: Tue Nov 11 17:35:40 EST 2003" which was cvsup'ed shortly prior to the build date. Included in the messages are the output of "ps" and "trace" once I broke into ddb. I'm also including output from "acpidump -t" and "mptable -verbose" since I've seen that information requested in the past. Some details about the system that may be pertinent: 1. It has two 1Ghz Athlon "Thunderbird" (Not MP) processors. That hasn't been a problem so far. 2. The BIOS is version 1.04 (latest is 1.05). The last time I tried updating to 1.05 (some time ago) I saw lots of error messagess complaining about undefined ACPI stuff so I reverted. 3. There is a Tekram 390F (I think that's the model -- it uses the sym driver) and an Adaptec 3944 SCSI controller. A single internal SCSI drive is connected to the Tekram and 10 external drives are connected to the two ports on the 3944. The external drives are configured as a Vinum Raid10 array. There's also a single IDE drive connected to one of the built-in IDE controllers. Please let me know if there is anything more you want to know. Thanks, -Ben Type '?' for a list of commands, 'help' for more detailed help. OK boot -sv -\|/-\|SMAP type=01 base= len=0009f400 SMAP type=02 base=0009f400 len=0c00 SMAP type=02 base=000e4800 len=0001b800 SMAP type=01 base=0010 len=0fef SMAP type=03 base=0fff len=fc00 SMAP type=04 base=0c00 len=0400 SMAP type=02 base=fec0 len=0001 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fff8 len=0008 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 #2: Tue Nov 11 17:35:40 EST 2003 [EMAIL PROTECTED]:/export/obj/usr/src-all/current/src/sys/AKIRA.ULE Preloaded elf kernel "/boot/kernel/kernel" at 0xc089d000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc089d250. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc089d2fc. Preloaded elf module "/boot/kernel/snd_es137x.ko" at 0xc089d3a8. Preloaded elf module "/boot/kernel/usb.ko" at 0xc089d458. Preloaded elf module "/boot/kernel/ums.ko" at 0xc089d500. Preloaded elf module "/boot/kernel/agp.ko" at 0xc089d5a8. Preloaded elf module "/boot/kernel/random.ko" at 0xc089d650. Calibrating clock(s) ... i8254 clock: 1192972 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 141373 Hz CPU: AMD Athlon(tm) Processor (1000.04-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183fbff AMD Features=0xc044 Data TLB: 24 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 268369920 (255 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c29000 - 0x0fb3dfff, 250695680 bytes (61205 pages) avail memory = 251088896 (239 MB) ACPI APIC Table: 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: 1 cpu1 (AP): APIC ID: 0 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 bios32: Found BIOS32 Service Directory header at 0xc00f7480 bios32: Entry = 0xfd6c0 (c00fd6c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd6c0+0x120 pnpbios: Found PnP BIOS data at 0xc00f74d0 pnpbios: Entry = f:9ece Rev = 1.0 Other BIOS signatures found: MADT: Found IO APIC ID 2, Vector 0
Re: GNOME users should recompile gnomevfs2 after today update
On Thu, 13 Nov 2003 04:54:21 -0800, walt <[EMAIL PROTECTED]> wrote: I found that the new statfs changes cause nautilus to crash on startup. The fix is to recompile/reinstall devel/gnomevfs2. Thanks for let us know and add CC'ing to freebsd-gnome list.. Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ULE and very bad responsiveness
Hi, from comp.unix.bsd.freebsd.misc: Kris Kennaway wrote: > On 2003-11-13, Harald Schmalzbauer <[EMAIL PROTECTED]> wrote: > >> Well, I don't have any measurements but in my case it's not neccessary at >> all. I built a UP kernel with ULE like Kris advised me. > > Are you running an up-to-date 5.1-CURRENT? ULE was broken with these > characteristics until very recently. If you're up-to-date and still > see these problems, you need to post to the current mailing list. > > Kris Yes, I am running current as of 13. Nov. Find attached my first problem description. Thanks, -Harry --- Begin Message --- Harald Schmalzbauer wrote: > Kris Kennaway wrote: > >> On 2003-11-12, Ivan Voras <[EMAIL PROTECTED]> wrote: >>> Kris Kennaway wrote: On 2003-11-11, Ivan Voras <[EMAIL PROTECTED]> wrote: > Debugging in 5-current halves the overall performance for non > cpu-only processes and ULE scheduler still offers less performance > than 4BSD. No, your data shows no statistically-significant difference between ULE and 4BSD. >>> >>> Well, I agree 6 measurements[*] are not much, but then again, it points >>> to a correlation and some folks need all the speed they can get (and >>> don't have MP systems). >>> >>> >>> [*] bytebench runs 6 measurements for each test. >> >> There's no correlation unless you do enough measurements to measure >> it. Your numbers showed an tiny difference which may or may not be >> real. > > Well, I don't have any measurements but in my case it's not neccessary at > all. I built a UP kernel with ULE like Kris advised me. > Seti is always running with nice 15. > When I try to install a already built (compiled) port it takes about 2 > minutes to complete (in this case the nvidia-driver). > When I stop seti it is done in about 5 Seconds like usual. Also when > building a port, the first make-fetch-extract-patch-configure steps take > 100 times the time against seti not running. > With the old scheduler I dind't even recognize that seti was running > (that's what nice 15 should affect I think). > On the other hand, starting up kde doesn't make any noticable difference, > but starting (and working) with kmail does. It's not the factor 100 or so > like with the make process but noticably more sluggish where I couldn't > feel any difference with the old scheduler. > > Please tell me what I should do. If there's no solution I'll switch back > in a view days because I loved BSD for the great responsiveness under high > load. I always had seti runnning, compiling in the backgroung, listening > music and do my daily work without any problem on a 1Ghz machine. > > Thanks, > > -Harry > > > >> >> Kris --- End Message --- pgp0.pgp Description: signature
Re: open office
On Wed, Nov 12, 2003 at 08:07:11AM -0800, Sweetleaf wrote: > Does openoffice seem slow to respond to others? Clicking on a menu option > such as "file" as to open a file takes about 30sec to give me the drop > down menu. Also i have noticed there might be a problem with the way the > port built or installed gtk, go to the business card creator and you > should see just gibberesh instead of the wizzard layout. I am using the > openoffice in the 5-current ports which is 1.1.0. I doesn't notice this slowdown when using the "open file" menue. Rest dunno. Never used it and don't find the term in german OO. FreeBSD titan.klemm.apsfilter.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Nov 6 23:21:41 CET 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN i386 Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? -> http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE and very bad responsiveness
On Thursday 13 November 2003 07:17, Harald Schmalzbauer wrote: > Hi, > > from comp.unix.bsd.freebsd.misc: > > Kris Kennaway wrote: > > On 2003-11-13, Harald Schmalzbauer <[EMAIL PROTECTED]> wrote: > >> Well, I don't have any measurements but in my case it's not neccessary > >> at all. I built a UP kernel with ULE like Kris advised me. > > > > Are you running an up-to-date 5.1-CURRENT? ULE was broken with these > > characteristics until very recently. If you're up-to-date and still > > see these problems, you need to post to the current mailing list. > > > > Kris > > Yes, I am running current as of 13. Nov. > > Find attached my first problem description. This time I also attached my dmesg and kernel conf > > Thanks, > > -Harry 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 #39: Thu Nov 13 04:47:34 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE Preloaded elf kernel "/boot/kernel/kernel" at 0xc09bf000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc09bf244. Preloaded elf module "/boot/kernel/nvidia.ko" at 0xc09bf2f0. ACPI APIC Table: Timecounter "i8254" frequency 1183583 Hz quality 0 CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 268173312 (255 MB) avail memory = 250781696 (239 MB) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc0760fe2 (122) VESA: NVIDIA acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f2a10 acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci2: on pcib1 pcib1: slot 0 INTA is routed to irq 16 nvidia0: mem 0xf000-0xf3ff,0xfd00-0xfdff irq 16 at device 0.0 on pci2 pcib2: at device 30.0 on pci0 pci1: on pcib2 fxp0: port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: port 0xef40-0xef5f irq 19 at device 31.2 on pci0 usb0: 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 ichsmb0: port 0xefa0-0xefaf irq 17 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 uhci1: port 0xef80-0xef9f irq 23 at device 31.4 on pci0 usb1: 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 uhub2: Standard Microsystems product 0x0140, class 9/0, rev 1.10/0.00, addr 2 uhub2: 4 ports with 4 removable, self powered ums0: Microsoft Microsoft IntelliMouse® Explorer, rev 1.10/1.14, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. uhub3: Texas Instruments General Purpose USB Hub, class 9/0, rev 1.10/1.01, addr 4 uhub3: 2 ports with 2 removable, bus powered pcm0: port 0xef00-0xef3f,0xe800-0xe8ff irq 17 at device 31.5 on pci0 pcm0: atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A npx0: [FAST] npx0: on motherboard npx0: INT 16 interface orm0: at iomem 0xd0800-0xd17ff,0xcf800-0xd07ff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <12 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 1095826590 Hz quality 800 Timecounters tick every 1.000 msec GEOM: create disk ad0 dp=0xc2d99760 ad0: 39083MB [79408/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-master PIO4 pcm0: measured ac97 link rate at 55931 Hz Mounting root from ufs:/dev/ad0s2a Warning: pid 574 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 580 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 581 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 601 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 602 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 603 used static ldt al
Re: tcp hostcache and ip fastforward for review
Hajimu UMEMOTO wrote: > > Hi, > > >>>>> On Tue, 11 Nov 2003 19:26:41 +0100 > >>>>> Andre Oppermann <[EMAIL PROTECTED]> said: > > oppermann> I have fixed the panic. It was a stupid braino in the test whether > oppermann> we have to free the allocated route. It was trying to free a null > oppermann> pointer route which obviously doesn't work. :-^ > > oppermann> The updated patch is here: > > oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-2003.patch > > oppermann> If you could try again please? > > It panics at another point on boot. > (kgdb) frame 24 > #24 0xc058e637 in tcp_hc_getmtu (inc=0x0) > at /usr/home/ume/cvs/freefall/current/src/sys/netinet/tcp_hostcache.c:420 > 420 hc_entry = tcp_hc_lookup(inc); > (kgdb) Ok, I found the bug. It was in the ipv6 hash function where I made a mistake with the hashmask. The updated patch is here: http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch Could you try again please? I have organized a second IPv6 capable machine (OpenBSD) for testing and I was able to ssh from my development machine to the OpenBSD via IPv6 tcp connection. I hope the last update has ironed out all ip6 bugs now. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hi, >>>>> On Wed, 12 Nov 2003 16:22:38 +0100 >>>>> Andre Oppermann <[EMAIL PROTECTED]> said: oppermann> Ok, I found the bug. It was in the ipv6 hash function where I made oppermann> a mistake with the hashmask. oppermann> The updated patch is here: oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch oppermann> Could you try again please? It does repeatable panic. Unfortunately, my laptop hanguped during dumping core, and I couldn't get core. So, I copied the output from ddb by hand. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor read, page not present instruction pointer = 0x8:0xc05b68c5 stack pointer = 0x10:0xd208ea28 frame pointer = 0x10:0xd208ea64 code segment= base 0x0, limit 0x, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 27 (swi1: net) kernel: type 12 trap, code=0 Stopped at in6_selecthlim+0x35:cmpl$0,0x1c(%esi) db> trace in6_selecthlim(0,0,28,0,fadd8ac9) at in6_selecthlim+0x35 syncache_respond(c3f6f000,c19a0600,1,c19a0600,0) at syncache_respond+0x31c syncache_add(d208eb80,d208ebf4,c1fc4836,d208eb4c,c19a0600) at syncache_add+0x4f4 tcp_input(c19a0600,28,0,d208ec40,6) at tcp_input+0xdae tcp6_input(d208ec84,d208ec60,6,d208ec84,28) at tcp6_input+0xf5 ip6_input(c19a0600,d018930f,39d40a1e,c0724474,0) at ip6_input+0xc18 netisr_processqueue(c06f0484,aa,7b1c1ccb,351110b4,c050250d) at netisr_processqueue+0xd9 swi_net(0,0,0,0,c199254c) at swi_net+0xd9 ithread_loop(c1988580,d208ed48,4d,55ff44fd,0) at ithread_loop+0x1d8 fork_exit(c04e4d90,c1988580,d208ed48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd208ed7c, ebp = 0 --- db> Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hajimu UMEMOTO wrote:
>
> Hi,
>
> >>>>> On Wed, 12 Nov 2003 16:22:38 +0100
> >>>>> Andre Oppermann <[EMAIL PROTECTED]> said:
>
> oppermann> Ok, I found the bug. It was in the ipv6 hash function where I made
> oppermann> a mistake with the hashmask.
> oppermann> The updated patch is here:
> oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch
> oppermann> Could you try again please?
>
> It does repeatable panic. Unfortunately, my laptop hanguped during
> dumping core, and I couldn't get core. So, I copied the output from
> ddb by hand.
-snip-
> Stopped at in6_selecthlim+0x35:cmpl$0,0x1c(%esi)
> db> trace
> in6_selecthlim(0,0,28,0,fadd8ac9) at in6_selecthlim+0x35
> syncache_respond(c3f6f000,c19a0600,1,c19a0600,0) at syncache_respond+0x31c
Grmpf... That is a logic error by me. Please add the following check
on line 707 in the patched netinet6/in6_src.c:
else if (in6p && !IN6_IS_ADDR_UNSPECIFIED(&in6p->in6p_faddr)) {
^^
Thank you for your effort in testing my changes!
--
Andre
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> Hello all,
>
> this patch contains three things (to be separated for committing):
>
> tcp_hostcache
>
> - removes protocol cloning from routing table (IPv4+6)
> - removes rtentry pointer from inpcb and in6pcb
> - removes ip route cache in ip_input.c (locking much easier)
> - removes most (tcp specific) metrics from rtentry metrics
> - adds a hostcache table which carries the metrics for tcp
> - works transparently for IPv4 and IPv6
> - is designed for concurrent access in SMP environments
> - significant reduction of routing table size (no cloning anymore)
> - eases many routing table locking situations in ip/tcp code
>
> ip_fastforward
>
> - removes ip_flow forwarding code
> - adds full direct process-to-completion IPv4 forwarding code
> - handles ip fragmentation incl. hw support (ip_flow did not)
> - supports ipfw and ipfilter (ip_flow did not)
> - supports divert and ipfw fwd (ip_flow did not)
> - drops anything it can't handle back to normal ip_input
I have a few comments to this code, see inline, look for #jesper
Apart from that it looks good.
/Jesper
> +int
> +ip_fastforward(struct mbuf *m)
> +{
> + struct ip *ip;
> + struct mbuf *m0 = NULL;
> +#ifdef IPDIVERT
> + struct ip *tip;
> + struct mbuf *teem = NULL;
> +#endif
> + struct mbuf *tag = NULL;
> + struct route ro;
> + struct sockaddr_in *dst = NULL;
> + struct in_ifaddr *ia = NULL;
> + struct ifaddr *ifa = NULL;
> + struct ifnet *ifp = NULL;
> + struct ip_fw_args args;
> + in_addr_t odest, dest;
> + u_short sum;
> + int hlen;
> + int error = 0;
> + int ipfw;
> +
> + /*
> + * Are we active and forwarding packets?
> + */
> + if (!ipfastforward_active || !ipforwarding)
> + return 0;
> +
> + /*
> + * If there is any MT_TAG we fall back to ip_input because we can't
> + * handle TAGs here.
> + */
> + if (m && m->m_type == MT_TAG)
> + return 0;
> +
> + M_ASSERTVALID(m);
> + M_ASSERTPKTHDR(m);
> +
[...]
> +
> + /*
> + * Only unicast IP, not from loopback, no L2 or IP broadcast,
> + * no multicast, no INADDR_ANY
> + */
> + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) ||
> + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) ||
#jesper
You will never see packets with a multicast source address.
> + (ntohl(ip->ip_dst.s_addr) == (u_long)INADDR_BROADCAST) ||
> + (IN_MULTICAST(ntohl(ip->ip_src.s_addr))) ||
> + (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) ||
> + (ip->ip_dst.s_addr == INADDR_ANY) )
> + goto fallback;
> +
> + /*
> + * Is it for a local address on this host?
> + */
> + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) {
> + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) {
> + goto fallback;
> + }
> + }
> +
> + /*
> + * Or is it for a local IP broadcast address on this host?
> + */
> + if (m->m_pkthdr.rcvif->if_flags & IFF_BROADCAST) {
> + TAILQ_FOREACH(ifa, &m->m_pkthdr.rcvif->if_addrhead, ifa_link) {
> + if (ifa->ifa_addr->sa_family != AF_INET)
> + continue;
> + ia = ifatoia(ifa);
> + if (ia->ia_netbroadcast.s_addr == ip->ip_dst.s_addr)
> + goto fallback;
> + if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr ==
> + ip->ip_dst.s_addr)
> + goto fallback;
> + continue;
> +fallback:
> + /* drop the packet back to netisr */
> + ip->ip_len = htons(ip->ip_len);
> + ip->ip_off = htons(ip->ip_off);
> + return 0;
> + }
> + }
> + ipstat.ips_total++;
#jesper
If we stored special "for us" /32 routes in the routing table for
addresses configured on this host, we could avoid the above 2 loops,
which can quite expensive.
These special routes will simply mean that the packet is for us, and
needs to given to ip_input
> + /**
> + ** Third: incoming packet firewall processing
> + **/
> +
> + odest = dest = ip->ip_dst.s_addr;
#jesper
You could save a few cycles by doing
#ifdef PFIL_HOOKS
odest = ip->ip_dst.s_addr;
/*
* Run through list of ipfilter hooks for input packets
*/
if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) ||
m == NULL)
return 1;
M_ASSERTVALID(m);
M_ASSERTPKTHDR(m);
ip = mtod(m, struct ip *); /* if m changed during fw processing */
dest = ip->ip_dst.s_addr;
#else
odest = dest = ip->ip_dst.s_addr;
#endif
Thus avoiding writing to dest twice.
> +#ifdef PFIL_HOOKS
>
Re: tcp hostcache and ip fastforward for review
Jesper Skriver wrote:
>
> On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> > Hello all,
> >
> > this patch contains three things (to be separated for committing):
...
> > ip_fastforward
> >
> > - removes ip_flow forwarding code
> > - adds full direct process-to-completion IPv4 forwarding code
> > - handles ip fragmentation incl. hw support (ip_flow did not)
> > - supports ipfw and ipfilter (ip_flow did not)
> > - supports divert and ipfw fwd (ip_flow did not)
> > - drops anything it can't handle back to normal ip_input
>
> I have a few comments to this code, see inline, look for #jesper
Answers also inline. [All whitespace bugs are fixed and omitted here]
> Apart from that it looks good.
Thanks for reviewing!
> /Jesper
>
> > +int
> > +ip_fastforward(struct mbuf *m)
> > +{
...
> > +
> > + /*
> > + * Only unicast IP, not from loopback, no L2 or IP broadcast,
> > + * no multicast, no INADDR_ANY
> > + */
> > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) ||
> > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) ||
>
> #jesper
> You will never see packets with a multicast source address.
I hope so but we can never be sure. Here we look at what we've got
straight from the wire. Everything is possible there. I only need
to craft an apropriate packet...
> > + (ntohl(ip->ip_dst.s_addr) == (u_long)INADDR_BROADCAST) ||
> > + (IN_MULTICAST(ntohl(ip->ip_src.s_addr))) ||
> > + (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) ||
> > + (ip->ip_dst.s_addr == INADDR_ANY) )
> > + goto fallback;
...
> > + /*
> > + * Or is it for a local IP broadcast address on this host?
> > + */
> > + if (m->m_pkthdr.rcvif->if_flags & IFF_BROADCAST) {
> > + TAILQ_FOREACH(ifa, &m->m_pkthdr.rcvif->if_addrhead, ifa_link) {
> > + if (ifa->ifa_addr->sa_family != AF_INET)
> > + continue;
> > + ia = ifatoia(ifa);
> > + if (ia->ia_netbroadcast.s_addr == ip->ip_dst.s_addr)
> > + goto fallback;
> > + if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr ==
> > + ip->ip_dst.s_addr)
> > + goto fallback;
> > + continue;
> > +fallback:
> > + /* drop the packet back to netisr */
> > + ip->ip_len = htons(ip->ip_len);
> > + ip->ip_off = htons(ip->ip_off);
> > + return 0;
> > + }
> > + }
> > + ipstat.ips_total++;
>
> #jesper
> If we stored special "for us" /32 routes in the routing table for
> addresses configured on this host, we could avoid the above 2 loops,
> which can quite expensive.
Good idea. I will look at that after 5.2 code freeze.
> These special routes will simply mean that the packet is for us, and
> needs to given to ip_input
>
> > + /**
> > + ** Third: incoming packet firewall processing
> > + **/
> > +
> > + odest = dest = ip->ip_dst.s_addr;
>
> #jesper
> You could save a few cycles by doing
Well, you're right. However I don't think it makes any difference
and I'd like to keep it the current way for clarity and ease of reading
and understanding the code.
> #ifdef PFIL_HOOKS
> odest = ip->ip_dst.s_addr;
> /*
> * Run through list of ipfilter hooks for input packets
> */
> if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) ||
> m == NULL)
> return 1;
>
> M_ASSERTVALID(m);
> M_ASSERTPKTHDR(m);
>
> ip = mtod(m, struct ip *); /* if m changed during fw processing */
> dest = ip->ip_dst.s_addr;
> #else
> odest = dest = ip->ip_dst.s_addr;
> #endif
>
> Thus avoiding writing to dest twice.
>
> > +#ifdef PFIL_HOOKS
> > + /*
> > + * Run through list of ipfilter hooks for input packets
> > + */
> > + if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) ||
> > + m == NULL)
> > + return 1;
> > +
> > + M_ASSERTVALID(m);
> > + M_ASSERTPKTHDR(m);
> > +
> > + ip = mtod(m, struct ip *); /* if m changed during fw processing */
> > + dest = ip->ip_dst.s_addr;
> > +#endif
...
> > +passin:
> > + ip = mtod(m, struct ip *); /* if m changed during fw processing */
> > +
> > + /*
> > + * Destination address changed?
> > + */
> > + if (odest != dest) {
> > + /*
> > + * Is it now for a local address on this host?
> > + */
> > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) {
> > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr)
> > + goto forwardlocal;
> > + }
>
> #jesper
>
> Same comment as above - and do we really want to see if the original
> d
Re: tcp hostcache and ip fastforward for review
On Thu, Nov 13, 2003 at 12:13:14AM +0100, Andre Oppermann wrote:
> Jesper Skriver wrote:
> >
> > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> > > Hello all,
> > >
> > > this patch contains three things (to be separated for committing):
> ...
> > > ip_fastforward
> > >
> > > - removes ip_flow forwarding code
> > > - adds full direct process-to-completion IPv4 forwarding code
> > > - handles ip fragmentation incl. hw support (ip_flow did not)
> > > - supports ipfw and ipfilter (ip_flow did not)
> > > - supports divert and ipfw fwd (ip_flow did not)
> > > - drops anything it can't handle back to normal ip_input
> >
> > I have a few comments to this code, see inline, look for #jesper
>
> Answers also inline. [All whitespace bugs are fixed and omitted here]
One comment at the bottom.
> > Apart from that it looks good.
>
> Thanks for reviewing!
>
> > /Jesper
> >
> > > +int
> > > +ip_fastforward(struct mbuf *m)
> > > +{
> ...
> > > +
> > > + /*
> > > + * Only unicast IP, not from loopback, no L2 or IP broadcast,
> > > + * no multicast, no INADDR_ANY
> > > + */
> > > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) ||
> > > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) ||
> >
> > #jesper
> > You will never see packets with a multicast source address.
>
> I hope so but we can never be sure. Here we look at what we've got
> straight from the wire. Everything is possible there. I only need
> to craft an apropriate packet...
True, but do we really care if forwarded such a packet ?
And if we want to check, we should just drop it directly instead of
giving the packet to ip_input.
/Jesper
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Jesper Skriver wrote:
>
> On Thu, Nov 13, 2003 at 12:13:14AM +0100, Andre Oppermann wrote:
> > Jesper Skriver wrote:
> > >
> > > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> > > > Hello all,
> > > >
> > > > this patch contains three things (to be separated for committing):
> > ...
> > > > ip_fastforward
> > > >
> > > > - removes ip_flow forwarding code
> > > > - adds full direct process-to-completion IPv4 forwarding code
> > > > - handles ip fragmentation incl. hw support (ip_flow did not)
> > > > - supports ipfw and ipfilter (ip_flow did not)
> > > > - supports divert and ipfw fwd (ip_flow did not)
> > > > - drops anything it can't handle back to normal ip_input
> > >
> > > I have a few comments to this code, see inline, look for #jesper
> >
> > Answers also inline. [All whitespace bugs are fixed and omitted here]
>
> One comment at the bottom.
>
> > > Apart from that it looks good.
> >
> > Thanks for reviewing!
> >
> > > /Jesper
> > >
> > > > +int
> > > > +ip_fastforward(struct mbuf *m)
> > > > +{
> > ...
> > > > +
> > > > + /*
> > > > + * Only unicast IP, not from loopback, no L2 or IP broadcast,
> > > > + * no multicast, no INADDR_ANY
> > > > + */
> > > > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) ||
> > > > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) ||
> > >
> > > #jesper
> > > You will never see packets with a multicast source address.
> >
> > I hope so but we can never be sure. Here we look at what we've got
> > straight from the wire. Everything is possible there. I only need
> > to craft an apropriate packet...
>
> True, but do we really care if forwarded such a packet ?
Yes, never forward anything that should not be. Stop the problem
right here instead of letting it become a problem somewhere else.
> And if we want to check, we should just drop it directly instead of
> giving the packet to ip_input.
Makes sense.
Can we ever have a packet that has a source address with INADDR_BROADCAST
or IN_MULTICAST? I can't think of such a case.
Can we ever have a packet with destination address INADDR_ANY? Maybe
for BOOTP? But then the source address would be 0.0.0.0 too?
With fallback to ip_input() in all those cases I wanted to make sure that
I don't break any obscure hack or protocol I didn't think of.
--
Andre
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
