Re: More ULE bugs fixed.
On Sat, 1 Nov 2003, Bruce Evans wrote: On Fri, 31 Oct 2003, Jeff Roberson wrote: I have commited my SMP fixes. I would appreciate it if you could post update results. ULE now outperforms 4BSD in a single threaded kernel compile and performs almost identically in a 16 way make. I still have a few more things that I can do to improve the situation. I would expect ULE to pull further ahead in the months to come. My simple make benchmark now takes infinitely longer with ULE under SMP, since make -j 16 with ULE under SMP now hangs nfs after about a minute. 4BSD works better. However, some networking bugs have developed in the last few days. One of their manifestations is that SMP kernels always panic in sbdrop() on shutdown. The nice issue is still outstanding, as is the incorrect wcpu reporting. It may be related to nfs processes not getting any cycles even when there are no niced processes. I've just run your script myself. I was using sched_ule.c rev 1.75. I did not encounter any problem. I also have not run it with 4BSD so I don't have any performance comparisons. Hopefully the next time you have an opportunity to test things will go smoothly. I fixed a bug in sched_prio() that may have caused this behavior. You commented on the nice cutoff before. What do you believe the correct behavior is? In ULE I went to great lengths to be certain that I emulated the old behavior of denying nice +20 processes cpu time when anything nice 0 or above was running. As a result of that, nice -20 processes inhibit any processes with a nice below zero from receiving cpu time. Prior to a commit earlier today, nice -20 would stop nice 0 processes that were non-interactive. I've changed that though so nice 0 will always be able to run, just with a small slice. Based on your earlier comments, you don't believe that this behavior is correct, why, and what would you like to see? Thanks, Jeff Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [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 ia64/ia64
TB --- 2003-11-02 10:46:59 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-02 10:46:59 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-11-02 10:46:59 - 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-02 10:49:05 - 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: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. [...] cc -O -pipe -DUSE_GZIP=1 -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/index.c cc -O -pipe -DUSE_GZIP=1 -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/install.c cc -O -pipe -DUSE_GZIP=1 -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/installUpgrade.c cc -O -pipe -DUSE_GZIP=1 -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/keymap.c cc -O -pipe -DUSE_GZIP=1 -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/label.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/label.c: In function `diskLabel': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/label.c:993: error: structure has no member named `bios_hd' /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall/label.c:993: error: structure has no member named `bios_sect' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/sysinstall. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.sbin. *** 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-02 11:50:58 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-02 11:50:58 - TB --- ERROR: failed to build world TB --- 2003-11-02 11:50:58 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic (in_pcb.c:866).
Hello. I got this panic while doing 'killall -9 ppp' on FreeBSD 5-CURRENT (kernel from October 31st): panic: mtx_lock() of spin mytex @ /usr/src/sys/netinet/in_pcb.c:866 [...] db trace [...] Debugger [...] panic [...] _mtx_lock_flags [...] [...] in_losing+0x40 [...] tcp_timer_rexmt+0x23e [...] softclock+0x1ad [...] ithread_loop+0x177 [...] fork_exit+0xb5 [...] fork_trampoline+0x8 [...] -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Panic (route.c:99).
Hello. Kernel from October 31st, while doing 'killall ssh'. panic: mtx_lock() of spin mutex @ /usr/src/sys/net/route.c:99 db trace Debugger [...] panic [...] _mtx_lock_flags [...] [...] rtalloc_ign+0x4b [...] rtalloc+0x19 [...] tcp_rtlookup+0x39 [...] tcp_gettaocache+0x11 [...] tcp_output+0x161 [...] tcp_usr_shutdown+0xb2 [...] soshutdown+0x42 [...] shutdown+0x6c [...] syscall+0x28f [...] Xint0x80_syscall+0x1d -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
LOR (rtsock.c:388 route.c:133).
Hello. Simlar one was reported but not exactly this one: lock order reversal 1st 0xc4516e90 rtentry (rtentry) @ /usr/src/sys/net/rtsock.c:388 2nd 0xc43e327c radix node head (radix node head) @ /usr/src/sys/net/route.c:133 Stack backtrace: backtrace(c05c6672,c43e327c,c05cb651,c05cb651,c05cb6a7) at backtrace+0x17 witness_lock(c43e327c,8,c05cb6a7,85,c437c300) at witness_lock+0x686 _mtx_lock_flags(c43e327c,0,c05cb6a7,85,c4516c90) at _mtx_lock_flags+0xb4 rtalloc1(c4539a6c,1,1,435,0) at rtalloc1+0x74 rt_setgate(c4516e00,c437c300,c4539a6c,184,0) at rt_setgate+0x23c route_output(c1926700,c44f8dd0,8c,c1926700,1f74) at route_output+0x674 raw_usend(c44f8dd0,0,c1926700,0,0) at raw_usend+0x76 rts_send(c44f8dd0,0,c1926700,0,0) at rts_send+0x35 sosend(c44f8dd0,0,e8916c80,c1926700,0) at sosend+0x429 soo_write(c4497374,e8916c80,c452d480,0,c446b4c0) at soo_write+0x92 dofilewrite(c446b4c0,c4497374,2,bfbfeab0,8c) at dofilewrite+0xe3 write(c446b4c0,e8916d14,c05d6e5b,3f0,3) at write+0x6f syscall(2f,2f,2f,2,3) at syscall+0x28f Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4), eip = 0x2826e173, esp = 0xbfbfe89c, ebp = 0xbfbfe8c8 --- -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: More ULE bugs fixed.
On Fri, 31 Oct 2003, Sam Leffler wrote: On Friday 31 October 2003 09:04 am, Bruce Evans wrote: My simple make benchmark now takes infinitely longer with ULE under SMP, since make -j 16 with ULE under SMP now hangs nfs after about a minute. 4BSD works better. However, some networking bugs have developed in the last few days. One of their manifestations is that SMP kernels always panic in sbdrop() on shutdown. I'm looking at something similar now. If you have a stack trace please send it to me (along with any other info). You might also try booting debug.mpsafenet=0. Turning off mpsafenet fixed all these problems. These console messages are with it not turned off. fxp is the only physical network device. %%% WARNING: loader(8) metadata is missing! [ preserving 869208 bytes of kernel symbol table ] 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 #1005: Sun Nov 2 20:38:42 EST 2003 [EMAIL PROTECTED]:/c/sysc/i386/compile/smp Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 268435456 (256 MB) avail memory = 255369216 (243 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 17 - irq 9 IOAPIC #0 intpin 18 - irq 11 IOAPIC #0 intpin 19 - irq 5 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: flags 0x80 npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdef0 pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: serial bus, USB at device 7.2 (no driver attached) piix0: PIIX Timecounter port 0x5000-0x500f at device 7.3 on pci0 Timecounter PIIX frequency 3579545 Hz quality 0 pci0: multimedia, video at device 11.0 (no driver attached) pci0: multimedia at device 11.1 (no driver attached) fxp0: Intel 82559 Pro/100 Ethernet port 0xa400-0xa43f mem 0xea00-0xea0f,0xea104000-0xea104fff irq 9 at device 13.0 on pci0 fxp0: Ethernet address 00:90:27:99:02:99 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: [MPSAFE] puc0: Titan VScom PCI-200HV2 port 0xb000-0xb01f,0xac00-0xac07,0xa800-0xa807 mem 0xea103000-0xea103fff,0xea102000-0xea102fff irq 5 at device 17.0 on pci0 sio4: Titan VScom PCI-200HV2 on puc0 sio4: type 16550A sio5: Titan VScom PCI-200HV2 on puc0 sio5: type 16550A atapci1: HighPoint HPT366 UDMA66 controller port 0xbc00-0xbcff,0xb800-0xb803,0xb400-0xb407 irq 11 at device 19.0 on pci0 atapci1: [MPSAFE] ata2: at 0xb400 on atapci1 ata2: [MPSAFE] atapci2: HighPoint HPT366 UDMA66 controller port 0xc800-0xc8ff,0xc400-0xc403,0xc000-0xc007 irq 11 at device 19.1 on pci0 atapci2: [MPSAFE] ata3: at 0xc000 on atapci2 ata3: [MPSAFE] orm0: Option ROMs at iomem 0xc8000-0xcbfff,0xc-0xc7fff on isa0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 sio0 at port 0x3f8-0x3ff irq 4 flags 0x90 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A cy0 at iomem 0xd4000-0xd5fff irq 10 on isa0 cy0: driver is using old-style compatibility shims ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: Parallel port bus on ppc0 ppbus0: IEEE1284 device found Probing for PnP devices on ppbus0: plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 unknown: PNP0303 can't assign resources (port) speaker0: PC
CD timeouts
I'm running -CURRENT as of Nov 1. I recall this 56x IDE drive working without too much trouble on 4.8, but it's having some serious issues now. Are the following a result from the drive being sketchy, or -CURRENT? I don't think it's a very high quality drive, but it seemed to work okay before. Also, as I type, I'm using xmms and it occasionally hangs, coincident with the resetting of the cd drive. It hangs until I hit a key on the keyboard. Nov 2 07:53:24 foo kernel: acd0: WARNING - READ_CD recovered from missing interrupt Nov 2 07:54:27 foo kernel: acd0: WARNING - READ_CD read data overrun 258720 Nov 2 07:54:27 foo kernel: acd0: WARNING - READ_CD recovered from missing interrupt Nov 2 07:55:07 foo kernel: acd0: WARNING - READ_CD read data overrun 258720 Nov 2 07:55:07 foo kernel: acd0: WARNING - READ_CD recovered from missing interrupt Nov 2 07:55:54 foo kernel: acd0: WARNING - READ_CD read data overrun 94080 Nov 2 07:55:54 foo kernel: acd0: WARNING - READ_CD recovered from missing interrupt Nov 2 07:56:44 foo kernel: acd0: WARNING - READ_CD read data overrun 258720 Nov 2 07:56:44 foo kernel: acd0: WARNING - READ_CD recovered from missing interrupt Nov 2 07:57:00 foo kernel: pid 1190 (netstat), uid 1001: exited on signal 10 Nov 2 07:57:16 foo kernel: acd0: TIMEOUT - READ_CD retrying (2 retries left) Nov 2 07:57:16 foo kernel: ata1: resetting devices .. Nov 2 07:57:16 foo kernel: done Nov 2 07:57:48 foo kernel: acd0: TIMEOUT - READ_CD retrying (1 retry left) Nov 2 07:57:48 foo kernel: ata1: resetting devices .. Nov 2 07:57:48 foo kernel: done Nov 2 07:58:20 foo kernel: ata1: resetting devices .. Nov 2 07:58:20 foo kernel: done Nov 2 07:58:20 foo kernel: acd0: FAILURE - READ_CD timed out Nov 2 07:58:52 foo kernel: acd0: TIMEOUT - READ_CD retrying (2 retries left) Nov 2 07:58:52 foo kernel: ata1: resetting devices .. Nov 2 07:58:53 foo kernel: done Kelley ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Sat, 1 Nov 2003, Terry Lambert wrote: I think at this point, you are going to have to look at the sources; IMO, it's a problem in some code that calls the ether_output() function directly with too large a packet, and since NFS doesn't manually implement TCP, that's not it. Hmmm. Is this maybe UDP? If so, the easiest fix is don't use UDP; FreeBSD's UDP fragment reassembly code sucks anyway, and gives an excellent means of implementing a DOS attack on the target system's available mbufs. If it's UDP, and you insist on it working, you might want to make sure that the packet goes through the UDP fragmentation and NFS rsize/wsize limitation code. I noticed in src/sys/dev/em/README that there are problems with jumbograms and UDP so I use TCP. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
USB (mouse) problem
hi, recently i installed freebsd 5 current on an asus m2400n notebook. most things work fine so far, but one ugly problem left: every time i plug in my usb mouse the system freezes. the system is really dead then (needs to be rebooted) - even the light on the optical mouse is swiched off. Any ideas ? thx seb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
/etc/rc.d/ipsec starts not in time
Submitter-Id: current-users Originator:Kostyuk Oleg Organization: Confidential: no Synopsis: /etc/rc.d/ipsec starts not in time Severity: serious Priority: medium Category: conf Class: sw-bug Release: FreeBSD 5.1-CURRENT i386 Environment: System: FreeBSD demani.digma 5.1-CURRENT FreeBSD 5.1-CURRENT #4: Sun Nov 2 13:45:34 EET 2003 [EMAIL PROTECTED]:/var/.0/usr/obj/usr/src/sys/CUB i386 Description: I use ipsec between my desktop and nfs/ntp server. On boot my mashine stops on Mounting NFS file systems. If I press Ctrl+C, booting continue ok, but nfs mounts left unmounted and time not in sync. I try to use -b flag to mount_nfs in fstab, but this not help me. Problem is in order of starting /etc/rc.d/ipsec. It must start BEFORE any network interaction, may be even before configuring interfaces. But I not sure in case with diskless mashines. How-To-Repeat: Create entry in /etc/fstab for nfs mount, create /etc/ipsec.conf to establish secure connection to same server (on both sides, of course :), and reboot. Fix: (~)% grep -h '\$FreeBSD' /usr/src/etc/rc.d/ipsec /etc/rc.d/ipsec # $FreeBSD: src/etc/rc.d/ipsec,v 1.6 2003/07/30 18:53:59 mtm Exp $ # $FreeBSD: src/etc/rc.d/ipsec,v 1.6 2003/07/30 18:53:59 mtm Exp $ (~)% diff -u /usr/src/etc/rc.d/ipsec /etc/rc.d/ipsec --- /usr/src/etc/rc.d/ipsec Wed Jul 30 21:53:59 2003 +++ /etc/rc.d/ipsec Sun Nov 2 14:43:59 2003 @@ -5,8 +5,8 @@ # # PROVIDE: ipsec # REQUIRE: root beforenetlkm mountcritlocal -# BEFORE: DAEMON +# BEFORE: NETWORK # KEYWORD: FreeBSD NetBSD # it does not really require beforenetlkm. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Sticky mouse with SCHED_ULE 10-30-03
Are you using moused? Is this SMP or UP? What CPUs are you using? Thanks, Jeff I am having similar problems after my last cvsup (10-31-03) also using a USB MS Intellimouse. Mouse is slow to respond under ULE but fine under 4BSD. The mouse feels like it's being sampled at a slow rate. I am using moused, on a UP Athlon XP 1800+. I am running seti at home at nice 15, but kill the seti process made no notable difference. I failed to check objective performance as the interactive experience was truly difficult to work with and I just wanted to get my work done. =] -Schnoopay I just disabled moused and told X to read from /dev/ums0 and the mouse problems are gone. I haven't changed anything else from when the mouse was sticky so I guess not using moused is a good work around. -Schnoopay ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CDDA with common programs (ATAng)
On Saturday 01 November 2003 23:06, Artem 'Zazoobr' Ignatjev wrote: On Sat, 01.11.2003, at 11:08, Harald Schmalzbauer ÐÉÛÅÔ: *SNIP* There were great tools which could do that automatically but they don't work any more for a reason I cannot follow. I've ran accross this one some time ago - dagrab no longer work, neither cdparanoia was. After recvsup of ports/audio and recompile of dagrab all went fine. Thank you for that hint, also to Arjan van Leeuwen. First I tried Arjan's hint which worked fine. Today I built world and tried the unpatched original port which builds fine again. Seems the changes have been backed out or whatever. But it's not working for me. First I can't run it as non-root and then it seems to need atapicam which I haven't. With Arjan's link it works without atapicam and as non-root. I think this patch should be commited. Ha, stop. Today it doesn't work as non-root anymore. I'm sure with -current some days ago and the same patch it worked without root privileges. I can't follow that. Thanks a lot, -Harry pgp0.pgp Description: signature
Re: USB (mouse) problem
On Sun, 2 Nov 2003, sebastian ssmoller wrote: hi, recently i installed freebsd 5 current on an asus m2400n notebook. most things work fine so far, but one ugly problem left: every time i plug in my usb mouse the system freezes. the system is really dead then (needs to be rebooted) - even the light on the optical mouse is swiched off. Please read the handbook on the proper form for problem reports. In the future, you might want to include the following: - uname -a - boot -s output - a trace, if available on the first vt or serial console. - your kernel config file of the running system. When you say that your machine locks solid, are you in X11 when you're plugging in the mouse? If so, it might really be panicking, it's just that you don't get to see the message printed to the screen. The best way to catch this class of problem is to hook up a serial console and perform the voodoo that makes the machine lock up. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Sat, Nov 01, 2003 at 06:24:18PM -0500, Barney Wolff wrote: Er, how is it possible to send a UDP packet 65535? Last time I looked it was a 16-bit field. This is explained in section 4. of RFC 2675, IPv6 Jumbograms, http://www.ietf.org/rfc/rfc2675.txt -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CDDA with common programs (ATAng)
It seems Harald Schmalzbauer wrote: Ha, stop. Today it doesn't work as non-root anymore. I'm sure with -current some days ago and the same patch it worked without root privileges. I can't follow that. Thats a feature of atapi-cd now being under GEOM.. The device nodes are now mode 640 which the security mob has been nagging me about for years. So now you know where to direct complaints :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATA hangs my Ultra5 on boot
Hi, Yesterday I upgraded -current on my Ultra5 from a August 24th -current, and now it hangs on boot, after logging error messages like these: ad0: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - SET_MULTI recovered from missing interrupt ad0: WARNING - SETFEATURES recovered from missing interrupt output of boot -v below. /Jesper Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 400MHz), No Keyboard OpenBoot 3.25, 512 MB (50 ns) memory installed, Serial #16330074. Ethernet address 8:0:20:f9:2d:5a, Host ID: 80f92d5a. Boot device: disk File and args: FreeBSD/sparc64 boot block Boot path: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Boot loader: /boot/loader Console: OpenFirmware console FreeBSD/sparc64 bootstrap loader, Revision 1.0 ([EMAIL PROTECTED], Sat Nov 1 20:02:24 CET 2003) bootpath=/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x276608+0x4fdf8 syms=[0x8+0x47580+0x8+0x39e47] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 8 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot -v nothing to autoload yet. jumping to kernel entry at 0xc004. 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 #9: Sat Nov 1 22:07:34 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SPARC64 Preloaded elf kernel /boot/kernel/kernel at 0xc034a000. Timecounter tick frequency 4 Hz quality 0 real memory = 536870912 (512 MB) avail memory = 514809856 (490 MB) machine: SUNW,Ultra-5_10 cpu0: Sun Microsystems UltraSparc-IIi Processor (400.00 MHz CPU) mask=0x91 maxtl=5 maxwin=7 null: null device, zero device random: entropy source openfirm: OpenFirmware control device mem: memory I/O nexus0: OpenFirmware Nexus device pcib0: U2P UPA-PCI bridge on nexus0 pcib0: Sabre, impl 0, version 0, ign 0x7c0, bus A initalizing intr_countp pcib0: [FAST] pcib0: [FAST] DVMA map: 0xc000 to 0xc3ff pci0: OFW PCI bus on pcib0 pci0: physical bus=0 found- vendor=0x108e, dev=0x5000, revid=0x13 bus=0, slot=1, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x10 (480 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found- vendor=0x108e, dev=0x5000, revid=0x13 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x10 (480 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) pcib1: APB PCI-PCI bridge at device 1.1 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode0xc0-0xdf, 0xe0-0xff pcib1: memory decode 0xe000-0x pci1: OFW PCI bus on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base f000, size 24, enabled map[14]: type 1, range 32, base f100, size 23, enabled found- vendor=0x108e, dev=0x1000, revid=0x01 bus=1, slot=1, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x52 (2460 ns), mingnt=0x0a (2500 ns), maxlat=0x19 (6250 ns) map[10]: type 1, range 32, base e000, size 15, memory disabled found- vendor=0x108e, dev=0x1001, revid=0x01 bus=1, slot=1, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x52 (2460 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) map[10]: type 1, range 32, base e100, size 24, memory disabled map[14]: type 4, range 32, base , size 8, port disabled map[18]: type 1, range 32, base e200, size 12, enabled found- vendor=0x1002, dev=0x4750, revid=0x5c bus=1, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0080, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[10]: type 4, range 32, base 00c0, size 3, enabled map[14]: type 4, range 32, base 00c8, size 2, enabled map[18]: type 4, range 32, base 00c00010, size 3, enabled map[1c]: type 4, range 32, base 00c00018, size 2, enabled map[20]: type 4, range 32, base 00c00020, size 4, enabled found- vendor=0x1095, dev=0x0646, revid=0x03 bus=1, slot=3, func=0 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x10 (480 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=255 ebus0:
Re: USB (mouse) problem
On Sun, 2003-11-02 at 15:18, Andre Guibert de Bruet wrote: On Sun, 2 Nov 2003, sebastian ssmoller wrote: hi, recently i installed freebsd 5 current on an asus m2400n notebook. most things work fine so far, but one ugly problem left: every time i plug in my usb mouse the system freezes. the system is really dead then (needs to be rebooted) - even the light on the optical mouse is swiched off. Please read the handbook on the proper form for problem reports. In the sorry for not providing enough information. i did not want to submit a problem report. i just wanted to see whether somebody has similar problems and whether it really is a problem - or i am just not clever enough to configure my system ... :) so here are further info: -i tried both: x11 and vt (console). plugging in the mouse always causes system freeze -uname -a: FreeBSD hadriel.linnet 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Nov 2 16:37:45 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SND i386 -a could not found any further info about this crash (trace, log file) -i attached my kernel config file -unfort. i do not have a proper cable to set up a serial connection/console :( -what kind of info should the boot -s command provide (i could not find this command on my system) ? so is there anybody with similar problems/experiences ? thx seb (...) # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.392 2003/09/19 20:04:55 joerg Exp $ machine i386 cpu I686_CPU ident FIRST #To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints #Default places to look for devices. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options SCHED_4BSD #4BSD scheduler options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFS_ROOT#NFS usable as /, requires NFSCLIENT options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. # Debugging for use in -current options DDB #Enable the kernel debugger options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS options WITNESS #Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN#Don't run witness on spinlocks for speed # To make an SMP kernel, the next two are needed #optionsSMP # Symmetric MultiProcessor Kernel #options
FreeBSD/sparc64 iso of resent -current ?
Is this available anywhere ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CDDA with common programs (ATAng)
On Sunday 02 November 2003 17:01, Soren Schmidt wrote: It seems Harald Schmalzbauer wrote: Ha, stop. Today it doesn't work as non-root anymore. I'm sure with -current some days ago and the same patch it worked without root privileges. I can't follow that. Thats a feature of atapi-cd now being under GEOM.. The device nodes are now mode 640 which the security mob has been nagging me about for years. So now you know where to direct complaints :) Ok, found that so some entries in devfs.conf did the trick. The rest I wrote obove was wrong. Accidentaly I forgot to remove the patch in the files directory, so cdparanoia still fails to build on -current. 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] Fehler 1 Thanks, -Harry -Søren ___ [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: buildworld error: rm: tar: is a directory
Date: Sat, 1 Nov 2003 12:23:37 -0800 (PST) From: Jean-Marc Zucconi [EMAIL PROTECTED] Subject: Re: buildworld error: rm: tar: is a directory To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] eculp writes: Mensaje citado por Ruslan Ermilov [EMAIL PROTECTED]: | On Sat, Nov 01, 2003 at 04:48:42AM -0800, [EMAIL PROTECTED] wrote: | I'm having problems with current buildworld in gnu now on two different | machines in current(today). The latest is the following: | | rm: tar: is a directory | *** Error code 1 | | Stop in /usr/src/gnu/usr.bin/tar. | *** Error code 1 | | Stop in /usr/src/gnu/usr.bin/tar. | *** Error code 1 | | Stop in /usr/src/gnu/usr.bin. | *** Error code 1 | | I'm begining to wonder if I'm getting a complete checkout with cvsup | of the gnu tree. | | ``rm -rf /usr/obj/usr/src/gnu/usr.bin/tar'' and try again. Ruslan That didn't seem to work. I've erased the /usr/obj/usr tree several times and even gnu but without luck. After resuping getting the error doing a rm -rf /usr/obj/usr/src/gnu/usr.bin/tar and then another make buildworld, I continue to get: Try 'cvs update -PdA' Jean-Marc Make sure that your cvs supfile has the line tag=. A week ago I used the cvs-supfile from the /usr/share/examples/cvsup folder and had the same error. When I used the standard-supfile from the same file, which had the tag=. line, it worked fine. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
The matcd(4) driver needs a maintainer
Hi The matcd(4) driver needs an active maintainer. Do we have any volunteers? Without active maintenance/use, the driver will rot, die and be removed from the tree. Speak up now! M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sticky mouse with SCHED_ULE 10-30-03
On Sun, 2 Nov 2003, Schnoopay wrote: Are you using moused? Is this SMP or UP? What CPUs are you using? Thanks, Jeff I am having similar problems after my last cvsup (10-31-03) also using a USB MS Intellimouse. Mouse is slow to respond under ULE but fine under 4BSD. The mouse feels like it's being sampled at a slow rate. I am using moused, on a UP Athlon XP 1800+. I am running seti at home at nice 15, but kill the seti process made no notable difference. I failed to check objective performance as the interactive experience was truly difficult to work with and I just wanted to get my work done. =] -Schnoopay I just disabled moused and told X to read from /dev/ums0 and the mouse problems are gone. I haven't changed anything else from when the mouse was sticky so I guess not using moused is a good work around. I'm not able to reproduce this at all. Could any of you folks that are experiencing this problem update to sched_ule.c rev 1.75 and tell me if it persists? -Schnoopay ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic in _mtx_lock_sleep
Hello. I just had a panic here. I'm running CURRENT as of 31st of October,
platform is i386. I have a crashdump available if anyone wants to take a
look at this.
Here's some output from gdb -k:
[EMAIL PROTECTED]:~/tmp/debug/2003-10-31 gdb -k kernel.debug vmcore.6
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x68
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0647282
stack pointer = 0x10:0xcfe919e0
frame pointer = 0x10:0xcfe91a0c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 326 (named)
panic: from debugger
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc07f5914
stack pointer = 0x10:0xcfe91794
frame pointer = 0x10:0xcfe917a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 326 (named)
panic: from debugger
Uptime: 19h17m7s
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0646edb
stack pointer = 0x10:0xcb608aec
frame pointer = 0x10:0xcb608b00
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 14 (swi1: net)
panic: from debugger
Uptime: 19h17m8s
Dumping 191 MB
16 32 48 64 80 96 112 128 144 160 176
---
Reading symbols from /boot/kernel/vinum.ko...done.
Loaded symbols for /boot/kernel/vinum.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0651c90 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0652078 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0476f52 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc0476eb2 in db_command (last_cmdp=0xc09050e0, cmd_table=0x0,
aux_cmd_tablep=0xc0889714, aux_cmd_tablep_end=0xc088972c) at
/usr/src/sys/ddb/db_command.c:346
#5 0xc0476ff5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc047a005 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc07f565c in kdb_trap (type=12, code=0, regs=0xcfe919a0) at
/usr/src/sys/i386/i386/db_interface.c:171
#8 0xc0807b76 in trap_fatal (frame=0xcfe919a0, eva=0) at
/usr/src/sys/i386/i386/trap.c:818
#9 0xc0807183 in trap (frame=
{tf_fs = -1033306088, tf_es = -1023934448, tf_ds = -806813680, tf_edi
= -1030808900, tf_esi = -1030785904, tf_ebp = -806807028, tf_isp =
-806807092, tf_ebx = -1033092512, tf_edx = 2, tf_ecx = 0, tf_eax = 1,
tf_trapno = 12, tf_err = 0, tf_eip = -1067158910, tf_cs = 8, tf_eflags =
66118, tf_esp = 42062, tf_ss = -806807052}) at
/usr/src/sys/i386/i386/trap.c:252
#10 0xc07f7008 in calltrap () at {standard input}:102
#11 0xc06ebab6 in ip_output (m0=0xc26c4260, opt=0xc28f7490, ro=0xc28f1abc,
flags=0, imo=0x0, inp=0xc28f1a80) at /usr/src/sys/netinet/ip_output.c:266
#12 0xc06fd2d6 in udp_output (inp=0xc28f1a80, m=0xc1561300,
addr=0xc2745660, control=0x0, td=0xc26c4260) at
/usr/src/sys/netinet/udp_usrreq.c:847
#13 0xc06fdf81 in udp_send (so=0x0, flags=0, m=0xc155cf00, addr=0x0,
control=0x0, td=0x0) at /usr/src/sys/netinet/udp_usrreq.c:1043
#14 0xc06913fd in sosend (so=0xc2913220, addr=0xc2745660, uio=0xcfe91bf4,
top=0xc155cf00, control=0x0, flags=0, td=0xc26c4260) at
/usr/src/sys/kern/uipc_socket.c:715
#15 0xc0695cdc in kern_sendit (td=0xc26c4260, s=22, mp=0xcfe91ca4, flags=0,
control=0x0) at /usr/src/sys/kern/uipc_syscalls.c:722
#16 0xc0695afe in sendit (td=0x0, s=0, mp=0xcfe91ca4, flags=0) at
/usr/src/sys/kern/uipc_syscalls.c:662
#17 0xc06960f3 in sendmsg (td=0x0, uap=0xcfe91d10) at
/usr/src/sys/kern/uipc_syscalls.c:900
#18 0xc0807f30 in syscall (frame=
{tf_fs = 135790639, tf_es = 135856175, tf_ds = -1078001617, tf_edi =
0, tf_esi = 0, tf_ebp = -1077943560, tf_isp = -806806156, tf_ebx = 0,
tf_edx = 135876352, tf_ecx = 136334080, tf_eax = 28, tf_trapno = 0, tf_err
= 2, tf_eip = 674256815, tf_cs = 31, tf_eflags = 646, tf_esp = -1077943988,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1012
#19 0xc07f705d in Xint0x80_syscall () at {standard
Panics and stuff..
Heum cvsuped earlier today (Sun 2 Nov 2003), after buildworld/installworld ive have noticed a few things i cant get working right.. First off the system seams to panic on background fsck i get this message: dev = ad1s1, block = 1, fs = /mnt/mellan panic: ffs_blkfree: freeing free block irq 1 atkbd0 panic page fault Then we have the Nvidia Xfree86 driver (version 1.0-4365), when iam trying to startx the system freezes and after aproximatly 4sec the system reboots. last row in XFree86.0.log say: (==) NVIDIA(0): Write-combining range (0xf3601000,0x1000) was already clear Huem if any one can point me out whats wrong i would be more than glad.. or if more information is needed. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
Jeff Roberson [EMAIL PROTECTED] wrote: On Fri, 31 Oct 2003, Bruno Van Den Bossche wrote: [...] I recently had to complete a little piece of software in a course on parallel computing. I've put it online[1] (we only had to write the pract2.cpp file). It calculates the inverse of a Vandermonde matrix and allows you to spawn multiple slave-processes who each perform a part of the work. Everything happens in memory so I've used it lately to test the different changes you made to sched_ule.c and these last fixes do improve the performance on my dual p3 machine a lot. Here are the results of my (very limited tests) : sched4bsd --- dimension slaves time 10001 90.925408 10002 58.897038 200 1 0.735962 200 2 0.676660 sched_ule 1.68 --- dimension slaves time 10001 90.951015 10002 70.402845 200 1 0.743551 200 2 1.900455 sched_ule 1.70 --- dimension slaves time 10001 90.782309 10002 57.207351 200 1 0.739998 200 2 0.383545 I'm not really sure if this is very relevant to you, but from the end-user point of view (me :-)) this does means something. Thanks! I welcome the feedback, positive or negative, as it helps me improve things. Thanks for the report! Could you run this again under 4bsd and ULE with the following in your .cshrc: set time= ( 5 %Uu %Ss %E %P %X+%Dk %I+%Oio %Fpf+%Ww %cc/%ww ) And then time ./testpract 200 2, etc. This will give me a few hints about what's impacting your performance. The program can run as a slave or master. So one should run one master and multiple slaves and they all work on a piece of shared memory. So I've timed the individual processes, as the wrapper-script test_pract2 doesn't do more then launch a few processes in the background. I don't think the output of that is very relevant. Here's the result: sched_4bsd 1.26 10001 master: 49.172u 0.187s 2:21.54 34.8% 15+10182k 0+0io 0pf+0w 5962c/65w slave : 90.326u 0.250s 1:30.75 99.8% 15+168k 0+0io 0pf+0w 9156c/35w 10002 master: 49.113u 0.226s 1:49.94 44.8% 15+10181k 0+0io 0pf+0w 5942c/63w slave1: 55.211u 0.326s 0:59.11 93.9% 15+166k 0+0io 0pf+0w 11129c/2224w slave2: 54.897u 0.363s 0:58.62 94.2% 15+167k 0+0io 0pf+0w 7111c/6129w 200 1 master: 0.377u 0.007s 0:02.39 15.4% 15+589k 0+0io 0pf+0w 38c/13w slave : 0.711u 0.031s 0:00.74 100.0% 15+169k 0+0io 0pf+0w 85c/1w 200 2 master: 0.376u 0.007s 0:02.87 12.8% 16+602k 0+0io 0pf+0w 41c/11w slave1: 0.388u 0.006s 0:01.03 36.8% 18+201k 0+0io 0pf+0w 1245c/408w slave2: 0.345u 0.038s 0:00.68 54.4% 34+158k 0+0io 0pf+0w 432c/1215w sched_ule 1.75 10001 master: 49.097u 0.163s 2:21.32 34.8% 15+10186k 0+0io 0pf+0w 6197c/163w slave : 90.157u 0.398s 1:30.82 99.6% 15+168k 0+0io 0pf+0w 11568c/49w 10002 master: 49.132u 0.164s 1:48.15 45.5% 15+10155k 0+0io 0pf+0w 6517c/276w slave1: 55.634u 0.406s 0:57.52 97.4% 15+169k 0+0io 0pf+0w 12745c/9628w slave2: 55.416u 0.391s 0:57.13 97.6% 15+168k 0+0io 0pf+0w 12448c/10063w 200 1 master: 0.369u 0.016s 0:02.52 14.6% 15+577k 0+0io 0pf+0w 92c/35w slave : 0.690u 0.054s 0:00.74 100.0% 15+171k 0+0io 0pf+0w 147c/13w 200 2 master: 0.376u 0.007s 0:02.47 14.9% 15+589k 0+0io 0pf+0w 87c/21w slave1: 0.331u 0.023s 0:00.70 50.0% 15+173k 0+0io 0pf+0w 466c/2135w slave2: 0.304u 0.040s 0:00.39 87.1% 15+166k 0+0io 0pf+0w 412c/2119w [1] http://users.pandora.be/bomberboy/mptest/final.tar.bz2 It can be used by running testpract2 with two arguments, the dimension of the matrix and the number of slaves. example './testpract2 200 2' will create a matrix with dimension 200 and 2 slaves. -- Bruno This fortune is inoperative. Please try another. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
hw.ata.atapi_dma vanished
Hello, grumpf, after having had the first spontanous reboot with -current for a long time I wanted to look for hw.ata.atapi_dma (since the machine crashed (without ANY report) when I tried to access the CD) and found it's gone. The man page still tells my stories about that sysctl. What news did I miss? Thank you, -Harry pgp0.pgp Description: signature
Re: FreeBSD-CURRENT kernel hangs on starting KDE
You can use ident(1) to extract the CVS version numbers of the files that were used to compile your respective kernels. Try this for a list of files and their respective versions: 'ident /boot/kernel/kernel /boot/kernel.old/kernel | sort' Seeya...Q On Sun, 2003-11-02 at 08:07, Tamás R. wrote: I'm sorry for my previous e-mail, I hope it will look better :) Some months ago I installed a FreeBSD-current system on my desktop computer. I use the KDE desktop environment and I compiled really everything from ports. I periodically maintain it so my system is up-to-date. I have been experiencing a problem with FreeBSD-current kernel all the time. Some months ago I tried to compile a custom kernel based on GENERIC commenting out the not necessary hardwares from my config, like RAID and most of NICs, etc. (I think it is a general thing when customizing). Although I haven't tested it too much the kernel booted properly and everything worked good in console. Trying to start KDE caused system crash (I guess in kernel level). I have spent long days to find the reason trying almost all combination of kernel config settings without luck. Ok, but GENERIC is worked with some custom lines added to it (but I couldn't remove anything except debugging). Since 25th of September something changed in the current kernel source tree because I am not able to compile any kernel, even GENERIC, with which KDE would start without freezing the whole machine partly or completely. Unfortunately I did not preserve any earlier source tree version, I just upgraded it with cvsup before the compilations. Now I use a newer base system than the kernel, which results in an unstable operation (it is normal I guess), because I only preserved the lastest goog-working /boot/kernel binaries I compiled before. KDE freezing in detail -- System: FreeBSD 5.1-CURRENT i386 Relevant hardware config: Mainboard : ASUS P4S533-E (SIS645DX north, SIS962/L south bridges) Memory : PC2700 512MB DDR RAM (memtest86 tested) VGA card : ATI RADEON 9000 PRO Very recent FreeBSD-current GENERIC kernel (was compiled exaclty as described in the handbook) completely freezes some seconds later after starting KDE. Input peripherials/ACPI button become unusable and the machine does not respond to ICMP on LAN so it completely hangs. It is not thought a hardware failure because earlier kernel with the same config (synced with cvsup on 25th Sept. 2003) works very good. KDE and XFree86 were compiled from the lastest ports so they are up-to-date. Logs does not show any usable information related to this freezing so I think there is no point to attach any of them here (XFree86 just stops logging before some radeondrm messages would be logged in normal case). I guess so it is closely an ATI-driver related problem because when I tested the same base system/kernel with an S3Trio VGA card that worked and the ATI did not. This ATI is a common card (with dual head+tv output) and not a cheap one at all (I currently use it on other OS-es on the same machine without experiencing any problems). Since I have been experiencing these problems I sync my source tree more times a week and I'm trying to compile a working kernel without luck. Note: If I switch back to console immediately after X server started and before KDE begins to initialize then KDE starts up properly. When I go back to X again I see the desktop as everything would be right. Some seconds later the same freezing takes place. First the keyboard blocks, then the mouse starts clogging and the whole machine totally hangs. I would appreciate any help in connection with this problem's solution. Thanks in advance, Tamás R. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [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 ia64/ia64
TB --- 2003-11-02 22:44:26 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-02 22:44:26 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-11-02 22:44:26 - 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-02 22:46:27 - 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: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-11-02 23:50:54 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sun Nov 2 23:50:54 GMT 2003 Kernel build for GENERIC completed on Mon Nov 3 00:06:58 GMT 2003 TB --- 2003-11-03 00:06:58 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-03 00:06:58 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Nov 3 00:06:58 GMT 2003 [...] cc -c -O -pipe -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/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/patm/if_patm_tx.c cc -c -O -pipe -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/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/patm/if_patm_attach.c cc -c -O -pipe -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/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/patm/if_patm_rtables.c awk -f /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/tools/makeobjops.awk /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/pccard/card_if.m -c ; cc -c -O -pipe -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/ia64/ia64/src/sys
opendchub compile problem
Helo! I wanna install opendchub on my FreeBSD server. My system is: 4.9-STABLE FreeBSD I have installed perl-5.6.1_14. But when I want to make net/opendchub I got this: # make === opendchub-0.7.12 needs at least perl 5.6.1 to build. # Can anybody help me, please? Best regards, Sebastijan Btw: Is that ok, to post msg like this on this maillist? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: opendchub compile problem
On Mon, 03 Nov 2003 01:13:54 +0100, Sebastijan Vacun [EMAIL PROTECTED] wrote: Helo! I wanna install opendchub on my FreeBSD server. My system is: 4.9-STABLE FreeBSD I have installed perl-5.6.1_14. But when I want to make net/opendchub I got this: # make === opendchub-0.7.12 needs at least perl 5.6.1 to build. # Can anybody help me, please? Check in the /usr/ports/lang/perl5/pkg-message, it explains what you need to do. Best regards, Sebastijan Btw: Is that ok, to post msg like this on this maillist? Yes it's ok, but you have sent to the wrong mailing list. ;-) You should have sent to freebsd-ports instead freebsd-current. 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]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-11-03 00:13:02 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-03 00:13:02 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-11-03 00:13:02 - 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-03 00:15:24 - 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: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-11-03 01:09:43 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Mon Nov 3 01:09:43 GMT 2003 Kernel build for GENERIC completed on Mon Nov 3 01:18:59 GMT 2003 TB --- 2003-11-03 01:18:59 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-03 01:18:59 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Nov 3 01:18:59 GMT 2003 [...] cc -c -O -pipe -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/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/patm/if_patm_tx.c cc -c -O -pipe -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/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/patm/if_patm_attach.c cc -c -O -pipe -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/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/patm/if_patm_rtables.c awk -f /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/pccard/card_if.m -c ; cc -c -O -pipe -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/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter
Re: Sticky mouse with SCHED_ULE 10-30-03
Jeff Roberson wrote: I'm not able to reproduce this at all. Could any of you folks that are experiencing this problem update to sched_ule.c rev 1.75 and tell me if it persists? I just cvsupped again today, so I'm now on rev 1.75 and using moused again with no problems. Whatever was broke seems fixed now. =] -Schnoopay ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hw.ata.atapi_dma vanished
On Sunday 02 November 2003 03:40 pm, Harald Schmalzbauer wrote: Hello, grumpf, after having had the first spontanous reboot with -current for a long time I wanted to look for hw.ata.atapi_dma (since the machine crashed (without ANY report) when I tried to access the CD) and found it's gone. The man page still tells my stories about that sysctl. What news did I miss? man ata You add it to /boot/loader.conf now. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
possible NIS/ACL bug?
I think I might have found a bug in ACL's under UFS2 with 5.1-RELEASE-p10. I have been using ACL's successfully for awhile now, but I'd never played with default ACL's for directories and files you create underneath said directories until I came across the daemon news article at: --- http://ezine.daemonnews.org/200310/acl.html Anyway, while playing and following the examples, I think I may have found a bug in ACL's when using NIS maps. Here's my example (extra newline between prompts): --- [EMAIL PROTECTED]/p0:~/test getfacl .. | setfacl -M - . [EMAIL PROTECTED]/p0:~/test getfacl . #file:. #owner:1019 #group:1019 user::rwx group::r-x group:nes:r-x group:loki:r-x mask::r-x other::r-x [EMAIL PROTECTED]/p0:~/test getfacl .. | setfacl -dM - . [EMAIL PROTECTED]/p0:~/test getfacl -d . #file:. #owner:1019 #group:1019 user::rwx group::r-x group:nes:r-x group:loki:r-x mask::r-x other::r-x [EMAIL PROTECTED]/p0:~/test touch something [EMAIL PROTECTED]/p0:~/test getfacl something #file:something #owner:1019 #group:1019 user::rw- group::r-x # effective: r-- group::r-x # effective: r-- group::r-x # effective: r-- mask::r-- other::r-- --- Uh oh! It's that last part where there are the two extra entries for the two ACL added groups, but no GID seems to have been stored with each entry, whereas the example in the daemon news article does actually show GID's in these places. So I assume this is an NIS/ACL bug of some kind? Both my uid and gid as well as both the gid's above (nes and loki) are mapped via NIS. If anyone needs me to do anything else, let me know. I don't feel nearly competent enough to start debugging the source for get/setfacl to try to grok any of this. :) -- Mark Nippere-contacts: Computing and Information Services [EMAIL PROTECTED] Texas AM Universityhttp://ops.tamu.edu/nipsy/ College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- GG/IT d- s++:+ a- C++$ UBL+++$ P---+++ L+++$ E--- W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- Well, if we told you how we did it, then it very well wouldn't be unbreakable, would it? You need to trust us with your data. These are not the backdoors you are looking for. -- random /. quote end random quote of the moment ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible NIS/ACL bug?
On 03 Nov 2003, Mark Nipper wrote: Uh oh! It's that last part where there are the two extra entries for the two ACL added groups, but no GID seems to have been stored with each entry, whereas the example in the daemon news article does actually show GID's in these places. Of course, looking at the example right after I sent the message, I see that the file inherited default UID's from the directory, not GID's, but blah, I assume it should still work the same either way? Or maybe it's a feature and not a bug. :) -- Mark Nippere-contacts: Computing and Information Services [EMAIL PROTECTED] Texas AM Universityhttp://ops.tamu.edu/nipsy/ College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- GG/IT d- s++:+ a- C++$ UBL+++$ P---+++ L+++$ E--- W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- If you're not part of the solution, you're part of the precipitate. end random quote of the moment ___ [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-03 05:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-03 05:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-11-03 05: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-03 05:01:59 - 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: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-11-03 06:05:39 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Mon Nov 3 06:05:39 GMT 2003 Kernel build for GENERIC completed on Mon Nov 3 06:17:35 GMT 2003 TB --- 2003-11-03 06:17:35 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-03 06:17:35 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Nov 3 06:17:35 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/patm/if_patm_tx.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/patm/if_patm_attach.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/patm/if_patm_rtables.c awk -f /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/pccard/card_if.m -c ; cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter
Fw: [patch] combine mount_udf(8) with kiconv(3)
Hi, I was adviced to forward here, so that more poeple can see it. It was originally posted to fs@ and [EMAIL PROTECTED] Regards, - Forwarded message from R. Imura [EMAIL PROTECTED] - Date: Mon, 3 Nov 2003 01:42:18 +0900 From: R. Imura [EMAIL PROTECTED] Subject: [patch] combine mount_udf(8) with kiconv(3) To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hi all, I now added -C option to mount_udf(8) as well as mount_cd9660(8) and mount_ntfs(8) with UDF_ICONV kernel module in order to handle multibyte characters. Since I'm new to nmount(), please correct me if I'm wrong with how to write udf specific options/flags. The patch is here: http://www.ryu16.org/FreeBSD/kiconv/udf_5_current_20031101.diff It is grateful if this will be applied to the FreeBSD src tree. Regards, - R. Imura - End forwarded message - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dualbooting STABLE CURRENT
On Sat, Nov 01, 2003 at 01:26:10PM -0800, Steve Wingate wrote: STABLE taking the entire first disk (works fine) CURRENT taking the first 1/3 of the second disk and backup data taking the remaining 2/3 of the second disk. I have installed CURRENT (at least 8 times) but I cannot get it to boot. Choosing F1 on booteasy boots STABLE. Choosing F5 boots nothing but it then shows an F2 entry for FreeBSD. I choose F2 and nothing happens. I have tried boot easy on the first disk, the second disk, both disks and nothing seems to work. I have tried making both slices making bootable and every possible derivative I can think of. What am I missing here? What exact steps did you take to set this up? Also please boot into some version of FreeBSD and post the output of: fdisk da0 disklabel da0s1 fdisk da1 disklabel da1s1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dualbooting STABLE CURRENT
Sat, Nov 01, 2003 at 20:38:36, s.wingate (Steve Wingate) wrote about Re: Dualbooting STABLE CURRENT: I don't like the sound of that. I'll just stick with STABLE until 5.x is really ready. -STABLE will have the same problem since its in boot0 and the BIOS, not the OS on the partition its trying to boot. SW Actually STABLE will have no problems as it's been running on this box for SW over a year. You have working STABLE on first disk, not on second. Well, please show fdisk output for both disks. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS file system problem in either stable or current
On Sun, 2 Nov 2003, Valentin Nechayev wrote: Wed, Oct 22, 2003 at 03:14:33, strick (Dan Strick) wrote about UFS file system problem in either stable or current: DS There seems to be an inconsistency between release 4.9-RC and 5.1 ufs DS support. If I fsck the same ufs (type 1 of course) file system on DS both releases, each claims that the other has left incorrect DS summary data in the superblock. Presumably only one can be correct. DS I just don't know which to blame. Does this require explicit fsck? I have dual-booting between 4.9-release (and all previous 4.* releases earlier) and 5.1 (of 20030526) with shared disks and boot checking required in fstab; sometimes one of them crash and forced checking is made; neither 4.* nor 5.1 claims superblock is bad. You wouldn't notice after a crash. The incompatibility turns out to be the location and perhaps details of the summary information (e.g. number of free blocks) in the superblock. This does not affect the integrity of the file system. It does affect the output of the df command. The first time you run fsck on a file system after modifying it when running the other operating system, fsck will probably find inconsistent super block summary data. fsck -p will correct it without asking (and might not even say much about it). I recently read something in one of the FreeBSD newsgroups that suggests that this incompatibility between 4.x and 5.x has in some sense been corrected in -current. I don't know any details. See also: http://www.freebsd.org/cgi/getmsg.cgi?fetch=446102+449665+/usr/local/www/db/text/2003/freebsd-current/20031102.freebsd-current Dan Strick [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS file system problem in either stable or current
Wed, Oct 22, 2003 at 03:14:33, strick (Dan Strick) wrote about UFS file system problem in either stable or current: DS There seems to be an inconsistency between release 4.9-RC and 5.1 ufs DS support. If I fsck the same ufs (type 1 of course) file system on DS both releases, each claims that the other has left incorrect DS summary data in the superblock. Presumably only one can be correct. DS I just don't know which to blame. Does this require explicit fsck? I have dual-booting between 4.9-release (and all previous 4.* releases earlier) and 5.1 (of 20030526) with shared disks and boot checking required in fstab; sometimes one of them crash and forced checking is made; neither 4.* nor 5.1 claims superblock is bad. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS file system problem in either stable or current
On Sun, 2 Nov 2003, 11:18+0200, Valentin Nechayev wrote: Wed, Oct 22, 2003 at 03:14:33, strick (Dan Strick) wrote about UFS file system problem in either stable or current: DS There seems to be an inconsistency between release 4.9-RC and 5.1 ufs DS support. If I fsck the same ufs (type 1 of course) file system on DS both releases, each claims that the other has left incorrect DS summary data in the superblock. Presumably only one can be correct. DS I just don't know which to blame. Does this require explicit fsck? I have dual-booting between 4.9-release (and all previous 4.* releases earlier) and 5.1 (of 20030526) with shared disks and boot checking required in fstab; sometimes one of them crash and forced checking is made; neither 4.* nor 5.1 claims superblock is bad. mckusick's answer: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=100639+0+archive/2003/freebsd-current/20030323.freebsd-current Dan's PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/58373 -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
