Re: Aironet/NEWCARD reinsertion panic
In message <[EMAIL PROTECTED]> Jose Gabriel J Marcelino writes: : db> trace : pccard_scan_cis(c1082680,c0167e0c,c9f43e88,0,0) at pccard_scan_cis+0x120 : pccard_read_cis(c1091a00) at pccard_read_cis+0xa9 : pccard_attach_card(c1082680) at pccard_attach_card+0xc5 : pccbb_insert(c1091c00,c9f43fa8,c1091c00,c9f43f94,c01b659d) at pccbb_insert+0x9e : pccbb_event_thread(c1091c00,c9f43fa8) at pcbb_event_thread+0x37 : fork_exit(c0287278,c1091c00,c9f43fa8) at fork_exit+0x2d : fork_trampoline() at fork_trampoline+0x8 Ah, this is a different panic than I've seeing on are removal. Looks like a resource conflict (likely unrelated to the resources not released, but there is a chance). The 16-bit support is still somewhat fragile in -current... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Aironet/NEWCARD reinsertion panic
In message <[EMAIL PROTECTED]> Jose Gabriel J Marcelino writes: : Ok, some people tried to help me find out why does the Aironet driver : panic on reinsertion, under NEWCARD with my recent patch (see previous : message and PR) however I need additional help to find the problem. *ALL* cards panic on reinsertion. At least all of them that I've tried. This has been broken in the past 2 or 3 weeks. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel Panic from Yesterday's CVSup
I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. -- Crist J. Clark [EMAIL PROTECTED] Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Sun Feb 4 20:09:00 PST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BUBBLES Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (132.96-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping = 11 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30130176 (29424K bytes) Preloaded elf kernel "kernel" at 0xc02a9000. Intel Pentium detected, installing workaround for F00F bug apm0: on motherboard apm0: found APM BIOS v1.1, connected at v1.1 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at 8.0 (no driver attached) ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc1: cannot reserve I/O port range sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2 at port 0x3e8-0x3ef irq 5 on isa0 sio2: type 16550A ep0: <3Com 3C509-TP EtherLink III> at port 0x300-0x30f irq 10 on isa0 ep0: Ethernet address 00:20:af:17:a3:e9 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, logging limited to 1000 packets/entry by default ad0: 1222MB [2484/16/63] at ata0-master BIOSPIO acd0: CDROM at ata0-slave using BIOSPIO Mounting root from ufs:/dev/ad0s1a kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0xe fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f2553 stack pointer = 0x10:0xc3a2bf50 frame pointer = 0x10:0xc3a2bf64 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 16 (irq14: ata0) trap number = 12 panic: page fault syncing disks... done Uptime: 0s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot <-- # $Id: BUBBLES,v 1.4 2001/02/04 06:49:24 cjc Exp cjc $ # # BUBBLES - 2000/11/11, cjc # # Kernel configuration for IBM Pentium 133 # # 2000/12/09, cjc - DEVEL became BUBBLES # machine i386 cpu I586_CPU ident BUBBLES maxusers32 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support #optionsDEVFS #Device Filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE#Allow users to grab the console options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING #optionsKBD_INSTALL_CDEV# install a CDEV entry in /dev device isa device pci #optionsCOMPAT_OLDISA # compatability shims for lnc, le #optionsCOMPAT_OLDPCI # compatability shims for lnc # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device
buildkernel target died...
Latest -CURRENT buidkernel died with this error messages: ===> sound/driver ===> sound/driver/ad1816 rm -f setdef0.c setdef1.c setdefs.h setdef0.o setdef1.o snd_ad1816.ko snd_ad1816.kld ad1816.o @ machine symb.tmp tmp.o bus_if.h device_if.h isa_if.h pci_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h ===> sound/driver/cmi cd: can't cd to /usr/src/sys/modules/sound/driver/cmi *** Error code 2 Stop in /usr/src/sys/modules/sound/driver. *** Error code 1 Stop in /usr/src/sys/modules/sound. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/DANTE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS)
Argl, the correct URL is of course: http://www.attic.ch:80/patches/rpc.diff_04022001.sh.tgz Cheers: Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 On Mon, 5 Feb 2001, Martin Blapp wrote: > > Hi, > > So, I have merged in the newest libc changes and fixed some > buildworld issues. It still needs some _THREAD_SAFE fixes I > guess, cause we build now thread-safe libc per default. But > we can do this later ... > > Go into your CURRENT source tree and execute the shell archive, > it will create the necessary directories and remove some files > to prevent appling files two times. > > You find the TI-RPC patch on: > > http:/www.attic.ch/patches/rpc.diff_04022001.sh.tgz > > Martin > > Martin Blapp, [EMAIL PROTECTED] > > Improware AG, UNIX solution and service provider > Zurlindenstrasse 29, 4133 Pratteln, Switzerland > Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS)
Hi, So, I have merged in the newest libc changes and fixed some buildworld issues. It still needs some _THREAD_SAFE fixes I guess, cause we build now thread-safe libc per default. But we can do this later ... Go into your CURRENT source tree and execute the shell archive, it will create the necessary directories and remove some files to prevent appling files two times. You find the TI-RPC patch on: http:/www.attic.ch/patches/rpc.diff_04022001.sh.tgz Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Aironet/NEWCARD reinsertion panic
Hi again, Ok, some people tried to help me find out why does the Aironet driver panic on reinsertion, under NEWCARD with my recent patch (see previous message and PR) however I need additional help to find the problem. I'm including the complete details on the events leading to the panic. My kernel conf is at: http://devils.maquina.com/~gabriel/MINIME Verbose kernel boot dmesgs are at: http://devils.maquina.com/~gabriel/boot.newcard Card attach messages are at: http://devils.maquina.com/~gabriel/boot.an The debug dmesg I get on NEWCARD after removing the card: pccard1: 00 CD 3b cardbus0: Detaching card: no cards to detach! pccbb_pcic_socket_disable pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] pccbb0: WARNING: Resource left allocated! This is a bug... (rid=0, type=3, addr=44001000) pccbb0: WARNING: Resource left allocated! This is a bug... (rid=0, type=1, addr=b) pccbb0: WARNING: Resource left allocated! This is a bug... (rid=0, type=4, addr=100) This is suspicious, however I'm not sure where's the problem. After that, after I reinsert the card I get lots of scrolling lines like this: CISTPL_NONE 00 And after that DDB takes over: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xcaed8000 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01672c0 stack pointer = 0x10:0xc9f43c8c frame pointer = 0x10:0xc9f43e74 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 = 7 (pccbb0) kernel: type 12 trap, code=0 Stopped at pccard_scan_cis+0x120: movb0(%eax,%edx,1),%al db> trace pccard_scan_cis(c1082680,c0167e0c,c9f43e88,0,0) at pccard_scan_cis+0x120 pccard_read_cis(c1091a00) at pccard_read_cis+0xa9 pccard_attach_card(c1082680) at pccard_attach_card+0xc5 pccbb_insert(c1091c00,c9f43fa8,c1091c00,c9f43f94,c01b659d) at pccbb_insert+0x9e pccbb_event_thread(c1091c00,c9f43fa8) at pcbb_event_thread+0x37 fork_exit(c0287278,c1091c00,c9f43fa8) at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dangling symlink in /usr/compat/linux
Szilveszter Adam wrote: > > On Sun, Feb 04, 2001 at 02:03:22AM -0800, Doug Barton wrote: > > FYI, /usr/compat/linux/usr/lib/X11 points to ../X11R6/lib/X11, but > > there is no X11 in /usr/compat/linux/usr/X11R6/lib. There are linux X > > libraries in the directory, although I'm not sure what the right change > > would be. > > Are you sure? Ummm... duh. :) I confirmed this on two machines. > This what I get: > > [11:19, Feb 04., Sun] cc@fonix:/home/cc ttyv4 % ls -l > /usr/compat/linux/usr/lib/X11/ > total 2 > drwxr-xr-x 2 root wheel 2048 Nov 17 14:03 config > [11:19, Feb 04., Sun] cc@fonix:/home/cc ttyv4 % ls -l > /usr/compat/linux/usr/X11R6/lib/X11/ > total 2 > drwxr-xr-x 2 root wheel 2048 Nov 17 14:03 config > > Seems to be in order to me... at least, the symlink definitely points to > somewhere that exists. Have you installed any linux X apps other than real player? That and netscape are all I have installed. > (I installed linux-base quite some time ago but I know it works because I > use RealPlayer every day:-) Me too. Doug -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
25.000 EMAILS MEDECINS
Cher Mr ou Mme. Nous vous prions de bien vouloir trouver ci-dessous une information concernant les adresses électroniques concernant les disciplines suivantes. Médecins généralistes et spécialistes-kinésithérapeutes-homéopathes-gynécologues-rhumatologues-pneumo logues-gastro-entérologues-psychiatres-infirmières-cliniques- hopitaux Quantité 25.000 ADRESSES @MAILS PAYS : FRANCE BELGIQUE SUISSE Livraison par @mail ou sur disquette Pc - Mac Espérant répondre à votre attente, Vous souhaitant bonne réception de la présente. Dans l'attente de vous lire recevez mes cordiales salutations. Jc Boulan ACPS jcb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Aironet under NEWCARD
Hi, Replying to myself. Seeing no answers I decided to work a little on adding the NEWCARD support to an(4) and I'm now sending this using it :-) It works ok, but card reinsertions cause at least this notebook to panic. I've submitted a PR with the appropriate patches. It's online at: http://www.freebsd.org/cgi/query-pr.cgi?pr=24854 Now I'm on to that ich (i810 and 440MX) AC97 audio driver :-) Regards Gabriel On Sun, Feb 04, 2001 at 02:57:51AM +, Jose Gabriel J Marcelino wrote: > Hi, > - The main problem however is that now the OLDCARD kernel crashes after > I remove my Cisco 340 (Aironet) PC Card from the only PC card slot present. > > I can give more detailed information on that if someone wants it, but I guess > the later has to do with the NEWCARD changes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken procfs/status, related to kthreads
On Sun, 4 Feb 2001, Andrzej Bialecki wrote: > According to procfs(5), the status line contains several well-defined > fields separated by spaces. However, the kernel thread names look like > 'swi5: task queue' and 'swi1: net', which results in variable number of > space-separated fields. As a consequence, some software that parses this > line gives incorrect results. I think procfs never actually implemented this. Program names may have spaces in them too. Of course, the line is too hard to parse if the first "field" has spaces in it. Only MAXCOMLEN and NAME_MAX prevent the command name being the contents of another process's status line :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Broken procfs/status, related to kthreads
Hi, Whoever made procfs aware of kernel threads broke also the /proc/%pid/status line. Or, maybe it's a by-product of showing kthreads in the proc table... According to procfs(5), the status line contains several well-defined fields separated by spaces. However, the kernel thread names look like 'swi5: task queue' and 'swi1: net', which results in variable number of space-separated fields. As a consequence, some software that parses this line gives incorrect results. I noticed this while trying to fix mysterious coredumps in src/release/picobsd/tinyware/aps (which is obsolete anyway, but it should work). Andrzej Bialecki // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Advansys driver problems: adv1 probe now fails (Invalid baseport ... Failing probe)
Recently, I updated a box with an ISA Advansys controller card + HP CD Burner to -CURRENT. On doing so, I discovered that my machine crashed at boot due to a NULL pointer passed to free(). John Baldwin provided me with a set of patches that appears to correct bugs in the Advansys (adv) driver that resolve this problem, allowing the probe to continue through (and then fail gracefully, as opposed to panicking). I've attached the references to the patches he provided to this e-mail. It should be pointed out, just for reference, that I've used this card successfully under FreeBSD for a number of years, and the hardware is believed to be in reasonable shape. It's sort of an interesting story, however. I updated in October, and discovered the box crashed--I didn't have time to deal with it then, so added a "disable adv0" to my /boot/kernel.conf. Putting that in there caused the device to probe as adv1, and work fine. Taking out the "disable adv0" causes the October kernel to panic in free() also. I've included three dmesg snippets from boot -v. after.txt Feb 3, 2001 + jhb patches with "di adv0" in kernel.conf after-2.txt Feb 3, 2001 + jhb patches without "di adv0" in kernel.conf before.txt Sep 29, 2000 with "di adv0" in kernel.conf before-2.txtSep 29, 2000 without "di adv0" in kernel.conf before-2 includes a panic, needless to say, due to breakage in the driver resulting in free() dying. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services -- Forwarded message -- Date: Sat, 3 Feb 2001 12:42:12 -0800 (PST) From: John Baldwin <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: adv patch Robert, A patch can be found at http://www.FreeBSD.org/~jhb/patches/adv.patch It compiles at least. John ... adv0: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 adv0 failed to probe at port 0x110 irq 15 drq 7 on isa0 ... isa_probe_children: probing PnP devices adv1: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 adv1: Invalid baseport of 0x20 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x0 specified. Nearest valid baseport is 0x100. Faili ng probe. adv1: Invalid baseport of 0x40 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x70 specified. Nearest valid baseport is 0x100. Fail ing probe. unknown: can't assign resources unknown: at port 0x60 on isa0 adv1: Invalid baseport of 0x61 specified. Nearest valid baseport is 0x100. Fail ing probe. unknown: failed to probe at port 0x61 on isa0 adv1: Invalid baseport of 0xf0 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x400 specified. Nearest valid baseport is 0x330. Fai ling probe. unknown: can't assign resources unknown: at port 0x10-0x1f,0x22-0x3f on isa0 unknown: can't assign resources unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources unknown: at port 0x378-0x37b on isa0 unknown: can't assign resources unknown: at port 0x3f0-0x3f5 on isa0 adv1: Invalid baseport of 0x111 specified. Nearest valid baseport is 0x120. Fai ling probe. unknown: failed to probe at port 0x111-0x120 iomem 0xc8000-0xc irq 11 drq 5 on isa0 ... adv0: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 adv0 failed to probe at port 0x110 irq 15 drq 7 on isa0 ... adv1: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 adv1: Invalid baseport of 0x20 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x0 specified. Nearest valid baseport is 0x100. Faili ng probe. adv1: Invalid baseport of 0x40 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x70 specified. Nearest valid baseport is 0x100. Fail ing probe. unknown: can't assign resources unknown: at port 0x60 on isa0 adv1: Invalid baseport of 0x61 specified. Nearest valid baseport is 0x100. Fail ing probe. unknown: failed to probe at port 0x61 on isa0 adv1: Invalid baseport of 0xf0 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x400 specified. Nearest valid baseport is 0x330. Fai ling probe. unknown: can't assign resources unknown: at port 0x10-0x1f,0x22-0x3f on isa0 unknown: can't assign resources unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources unknown: at port 0x378-0x37b on isa0 unknown: can't assign resources unknown: at port 0x3f0-0x3f5 on isa0 adv1: Invalid baseport of 0x111 specified. Nearest valid baseport is 0x120. Fai ling probe. unknown: failed to probe at port 0x111-0x120 iomem 0xc8000-0xc irq 11 drq 5 on isa0 ... adv1: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 adv1: at port 0x110 iomem 0xc8000-0xc irq 11 drq 5 on isa0 adv2: Invalid baseport of 0x20 specified. Nearest valid baseport is 0x100. Failing p
Re: Reclaim 8 0 Killed
It's normal. bpf implements what I currently have for my preferred way of preventing a DoS with cloning devices. The message indicates that the bpf0 device node were reclaimed. Poul-Henning In message <[EMAIL PROTECTED]>, Robert Watson writes: > >Updated to a recent -CURRENT yesterday on one of my boxes, and noticed a >slightly unusual shutdown message: > > syncing disks... 8 8 5 5 1 1 > done > Reclaim 8 0 Killed > Uptime: 10h23m28s > Rebooting... > >Don't know what it means, or if it's harmful, but it's certainly different >:-). > >Robert N M Watson FreeBSD Core Team, TrustedBSD Project >[EMAIL PROTECTED] NAI Labs, Safeport Network Services > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Reclaim 8 0 Killed
Updated to a recent -CURRENT yesterday on one of my boxes, and noticed a slightly unusual shutdown message: syncing disks... 8 8 5 5 1 1 done Reclaim 8 0 Killed Uptime: 10h23m28s Rebooting... Don't know what it means, or if it's harmful, but it's certainly different :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Does task scheduler work correctly? (... nice bug fix)
On Thu, 1 Feb 2001, Cejka Rudolf wrote: > Sheldon Hearn wrote (2001/02/01): > > What I remember of the discussions that surrounded this one, your > > summary is correct. The only thing is that nice isn't so much _broken_ > > as it just isn't doing what you'd expect it to. :-) > > Ok, scheduler in -current is not broken. But I'm afraid that in -stable Nah, it is broken. > it is - can (niced) process cause a lock of machine?. Currently, we > have dual processor box with 4.2-STABLE and it silently locks too often. > With current scheduler in mind, it is hard to say if I should search in > HW or SW for a potential fix... I think only processes with niceness less than -5 can cause lockups. This is because they get assigned priorities below some kernel priorities, so priority inversion is possible. I think priority inversions between processes running in user mode are impossible (because low-priority (higher priority numbered) processes can't block in user mode). > > I don't think any of the FreeBSD manual pages suggest that nice 20 > > processes aren't supposed to get _any_ CPU time. > > Maybe. But there are some conventions and two-process sensitivity > 2.5:1 is not very big (is low). Solaris and Linux have much bigger > ratio (sufficient). So why FreeBSD has to be so much different? Just a bug. The relative weights of the priorities are mostly determined accidentally by the following formula in resetpriority(): newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT + NICE_WEIGHT * (p->p_nice - PRIO_MIN); For process mixes consisting of only long-running cpu hog processes, the priorities tend to a common limit (this is fairly obvious -- lower priority processes get run more; this increases their priority until it is not lower, so the priority of all the processes is similar; also, correct design of the algorithm that decays p_estcpu should ensure that the common priority doesn't hunt). For the simple case of 2 long-running cpu hog processes with nicenesses n1 and n2, the priority for both tends towards a limit of approximately 104 (see ps output). This corresponds to the (p_estcpu / weight) term for the process with the lowest nice value tending towards its maximum value of (PRIO_MAX - PRIO_MIN - PPQ == 36); the maximum is nearly reached because of correct design of of the decay algorithm, and actually reached because of bugs). The p_estcpu's for the two processes can be calculated from this: 104 = 48 + p->p_estcpu / 8 + 1 * (p->p_nice + 20) p->p_estcpu = (36 - p->p_nice) * 8 In the limit, the runtimes are to a first approximation proportional to p_estcpu (higher terms depend on the decay algorithm), so for processes with niceness n0 and n1, the relative runtimes are approximately: (36 - n0) : (36 - n1) This formula is neither simple nor good. For n0 = 0 and n1 = 20, it gives the ratio of 36:16, which is close to the 2.5:1 ratio observed by Cejka. I observe a ratio closer to 3:1 for the runtimes, and the formula gives almost the exact ratio for the p_estcpu's. The formula breaks down near (n0 = -16, n1 = 20), since the p_estcpu term can never raise the priority by more than 36, so the ratio is 1:0 for n0 < - 16 and n1 = 20. This is a bug. > Insensitivity of nice were problem in the past and it is going back. For RELENG_4 before I imported the fixes from NetBSD, the corresponding calculations are: 127 = 50 + p->p_estcpu / 4 + 2 * p->p_nice p->p_estcpu = (38.5 - p->p_nice) * 8 ratio = (38.5 - n0) : (38.5 - n1) ratio for nicenesses (0, 20) = 38.5:18.5 so -current is almost perfectly bug for bug compatible in this area with RELENG_4! :-( In RELENG_4, the corresponding calculations are: 86 = 50 + p->p_estcpu / 8 + 2 * p->p_nice p->p_estcpu = (18 - p->p_nice) * 16 ratio = (18 - n0) : (18 - n1) ratio for nicenesses (0, 20) = 18:-2 (formula invalid, actually 1:0) ratio for nicenesses (0, 17) = 18:1 Quick fix: --- Index: kern/kern_synch.c === RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v retrieving revision 1.124 diff -c -2 -r1.124 kern_synch.c *** kern/kern_synch.c 2001/01/31 04:29:51 1.124 --- kern/kern_synch.c 2001/02/03 15:16:44 *** *** 1039,1044 mtx_enter(&sched_lock, MTX_SPIN); if (p->p_rtprio.type == RTP_PRIO_NORMAL) { ! newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT + ! NICE_WEIGHT * (p->p_nice - PRIO_MIN); newpriority = min(newpriority, MAXPRI); p->p_usrpri = newpriority; --- 1039,1046 mtx_enter(&sched_lock, MTX_SPIN); if (p->p_rtprio.type == RTP_PRIO_NORMAL) { ! newpriority = PUSER + ! (PRIO_MAX - PRIO_MIN + 1) * ! (p->p_estcpu / INVERSE_ESTCPU_WEIGHT) / ! (PRIO_MAX - p->p_nice + 1); newpriority = min(newprior
Re: kernel trap 26 panic
On Sat, 03 Feb 2001 22:54:33 -0800 (PST), John Baldwin <[EMAIL PROTECTED]> said: > The ppbus does painful things with its interrupt handlers. This > is a known problem and on the todo list, just not fixed yet. This problem (with lpr) is new in the past couple of days, at least here ... -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] There are things that are so serious that you can only joke about them. -- Werner Heisenberg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
update of ipfilter
well, I got as far as importing ipfilter 3.4.16 into -current before I realised that ref5 is not working properly (again) or for some reason it just doesn't know about the ssh files that freefall does so if I just broke -current, I'm sorry but if I could have done a test compile on a 5.x box I would have... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dangling symlink in /usr/compat/linux
On Sun, Feb 04, 2001 at 02:03:22AM -0800, Doug Barton wrote: > FYI, /usr/compat/linux/usr/lib/X11 points to ../X11R6/lib/X11, but > there is no X11 in /usr/compat/linux/usr/X11R6/lib. There are linux X > libraries in the directory, although I'm not sure what the right change > would be. Are you sure? This what I get: [11:19, Feb 04., Sun] cc@fonix:/home/cc ttyv4 % ls -l /usr/compat/linux/usr/lib/X11/ total 2 drwxr-xr-x 2 root wheel 2048 Nov 17 14:03 config [11:19, Feb 04., Sun] cc@fonix:/home/cc ttyv4 % ls -l /usr/compat/linux/usr/X11R6/lib/X11/ total 2 drwxr-xr-x 2 root wheel 2048 Nov 17 14:03 config Seems to be in order to me... at least, the symlink definitely points to somewhere that exists. (I installed linux-base quite some time ago but I know it works because I use RealPlayer every day:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Dangling symlink in /usr/compat/linux
FYI, /usr/compat/linux/usr/lib/X11 points to ../X11R6/lib/X11, but there is no X11 in /usr/compat/linux/usr/X11R6/lib. There are linux X libraries in the directory, although I'm not sure what the right change would be. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doFS.sh should obey MDDEVICE if available
Since mdconfig can autoallocate the device, why is this needed ? In message <[EMAIL PROTECTED]>, Makoto MATSUSHITA writes: > >src/release/scripts/doFS.sh rev. 1.6 doesn't consider MDDEVICE variable >(formaly, VNDEVICE). Here is a sample fix to use MDDEVICE variable to >configure md -- trivial, add '-u' option if MDDEVICE is already defined. > >-- - >Makoto `MAR' MATSUSHITA > >Index: doFS.sh >=== >RCS file: /pub/cvsup/FreeBSD.cvs/src/release/scripts/doFS.sh,v >retrieving revision 1.29 >diff -c -r1.29 doFS.sh >*** doFS.sh2001/01/31 22:58:39 1.29 >--- doFS.sh2001/02/03 23:16:51 >*** >*** 37,43 > awk 'BEGIN {printf "%c%c", 85, 170}' |\ > dd of=${FSIMG} obs=1 seek=510 conv=notrunc 2>/dev/null > >! MDDEVICE=`mdconfig -a -t vnode -f ${FSIMG}` > if [ ! -c /dev/${MDDEVICE} ] ; then > if [ -f /dev/MAKEDEV ] ; then > ( cd /dev && sh MAKEDEV ${MDDEVICE} ) >--- 37,47 > awk 'BEGIN {printf "%c%c", 85, 170}' |\ > dd of=${FSIMG} obs=1 seek=510 conv=notrunc 2>/dev/null > >! if [ "x${MDDEVICE}" != "x" ] ; then >! mdconfig -a -t vnode -f ${FSIMG} -u ${MDDEVICE} >! else >! MDDEVICE=`mdconfig -a -t vnode -f ${FSIMG}` >! fi > if [ ! -c /dev/${MDDEVICE} ] ; then > if [ -f /dev/MAKEDEV ] ; then > ( cd /dev && sh MAKEDEV ${MDDEVICE} ) > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Watch your devfs permissions in driver make_dev calls
Greg Lehey wrote: > On Friday, 2 February 2001 at 20:10:10 -0800, Peter Wemm wrote: > > Robert Watson wrote: > > > >> crw-r--r-- 1 root wheel 78, 0 Dec 31 1969 pci > > > > This one may appear harmless, but it is not. It is trivially easy to creat e > > an alignment fault (fatal on an alpha) with the userland pciconf tool. > > We must not allow this to be used by users until the kernel part is fixed. > > > > Eg: try this on an alpha: pciconf -r -l pci0:x:x 0x3 - ie: read a longword > > at byte offset 3 in configuration space.. kaboom! > > This looks like a separate issue. Presumably you can do this as root > as well. pciconf should check the parameters. The kernel should check the parameters passed in from the userland, at least, it should not die like this. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message