Re: panic: mb_dtor_mbuf: M_EXT set
On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu wrote: I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff wrote: I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff wrote: I T This should be fixed in src/sys/kern_mbuf.c, rev. 1.9.2.3 I I And another bogus panic is removed in 1.9.2.4 I I I The kernel is working again, thanks! I I It's working in regard of vr0, thank you. However now my computer I resets w/o anything logged when starting kde; if I only startx it I doesn't happen (without exec startkde in .xinitrc); I commented out any I fancy options like dri with no effect and it also happen if I kldunload I snd_via8233 before starting kde. I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; it didn't I happen with sources from 19. Bad news. Can you do a binary search and find commit that makes this regression? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system laggy under load, SCHED_BSD
On Sun, Jan 22, 2006 at 11:00:28PM +0100, Tobias Roth wrote: T Since some time, I experience extremely bad system behaviour under T load. For instance when compiling something, or unpacking a large T archive, the system is almost unusable, even the mouse pointer T reacts sloppy. T T My system: T T 6.0-STABLE FreeBSD 6.0-STABLE #7: Sun Jan 22 15:53:39 CET 2006 i386 T T I use SCHED_BSD. T T How can I diagnose the problem, or provide more information? What T factors might influence what I experience? I cannot give a more precise T point in time as when this started, since I switched versions and T systems a few times recently. What are numbers for the swap in/out in top(1)? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Page fault, GEOM problem??
On Mon, 2006-01-23 at 06:43 +0100, Johan Ström wrote: On 23 jan 2006, at 01.17, Michael S. Eubanks wrote: On Sun, 2006-01-22 at 23:51 +0100, Johan Ström wrote: ...snip... On 22 jan 2006, at 22.58, Michael S. Eubanks wrote: This card does afaik dont have raid functionalitys (I've never read anything about it either on the web, the cards box or anywhere else..). I'm running GENERIC, which does include ataraid.. What does your dmesg identify your card as? atapci0: Promise PDC40518 SATA150 controller port 0xb800-0xb87f, 0xb400-0xb4ff mem 0xfb80-0xfb800fff,0xfb00-0xfb01 irq 19 at device 12.0 on pci0 Is it the same PDC chipset? -- Johan No, I have a different controller. My mistake. I think what is happening is the DMA read command is failing, therefore causing the device to be disconnected, and the kernel can't write to the disk from that point on (this is somewhat obvious given the output below). Nov 29 20:36:54 elfi kernel: subdisk10: detached Nov 29 20:36:54 elfi kernel: ad10: detached Nov 29 20:36:54 elfi kernel: unknown: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=426562704 Nov 29 20:36:54 elfi kernel: GEOM_MIRROR: Device gm0s1: provider ad10s1 disconnected. The message seen from the last line above is generated in any of the following scenarios (from g_mirror.c): 1. Device wasn't running yet, but disk disappear. 2. Disk was active and disapppear. 3. Disk disappear during synchronization process. Nov 29 20:36:54 elfi kernel: GEOM_MIRROR: Request failed (error=6). ad10s1[WRITE(offset=134356992, length=16384)] As far as recovering the disk, I remember seeing something about booting to single user mode and using fsck after a core dump in a previous post. I'm assuming the disks worked initially and that you were able to label them etc? Is there any possibility that the disk state may be altered by a power saving feature or setting in the BIOS and FreeBSD just doesn't know when it happens until the next time it tries to access the disk? For recovering, i've always done a direct reboot, the gmirror rebuilds the mirror and fsck is run. No problems reading labels etc, and never has been, only problem has been these sporadic crashes.. And the read/write performance (see earlier in thread)... This is a server, so all bios setting for powersaving is (should be) shut of. Bios should thus never make the disk go to sleep. Thanks for trying to help! Wish I could be of more help. :) Have you tried to toggle the sysctl dma flags? I've seen similar posts in the past with read timeouts caused from dma being enabled. # sysctl -a | grep dma ... hw.ata.ata_dma: 1 === Try turning this one off (1 == 0). hw.ata.atapi_dma: 1 ... -Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient wedged
Brooks Davis [EMAIL PROTECTED] wrote: This definitly sounds like something particular to your dhcp servers. It would be nice if we could fix it, but without some debugging help that's going to be pretty much impossible. [...] It happens to me quite often, too. The only thing related in the non-debug messages is: Jan 8 12:02:19 moneypenny dhclient[68091]: 5 bad IP checksums seen in 5 packets Jan 8 12:02:49 moneypenny last message repeated 743054 times Jan 8 12:04:50 moneypenny last message repeated 2951866 times Jan 8 12:14:51 moneypenny last message repeated 14457921 times Jan 8 12:24:52 moneypenny last message repeated 14812032 times Jan 8 12:34:53 moneypenny last message repeated 14770327 times Jan 8 12:44:55 moneypenny last message repeated 14748300 times Jan 8 12:51:44 moneypenny last message repeated 10037074 times ... which accounts for the CPU usage, I guess. I killed the bad IP checksums messages, so it doesn't annoy my syslog anymore, but it of course didn't fix the underlaying issue. I was looking at those packets with tcpdump once and didn't see anything obvious/bad there. And yes, I didn't have this problem with ISC client. And I surely use different cable provider, than the original poster ;) -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Page fault, GEOM problem??
On 23 jan 2006, at 09.53, Michael S. Eubanks wrote: On Mon, 2006-01-23 at 06:43 +0100, Johan Ström wrote: Wish I could be of more help. :) Have you tried to toggle the sysctl dma flags? I've seen similar posts in the past with read timeouts caused from dma being enabled. # sysctl -a | grep dma ... hw.ata.ata_dma: 1 === Try turning this one off (1 == 0). hw.ata.atapi_dma: 1 ... Disabling DMA, wouldnt that give me pretty bad performance? -Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
On Fri, Jan 20, 2006 at 01:21:28PM -0800, Nate Lawson wrote: JoaoBR wrote: I have some Epox socket 939 motherboards, nvidia3 with AMD Athlon 64 and some X2 They give me a very good performance but sporadic reboots without core dumps or any other advices so I guess there is some sudden irq conflict or so I get nothing usefull by vmstat. I mount the same Nics, adaptec, mem and processor on an Asus A8V and it runs wothout any problem stable. btw I am running releng_6 If disabling acpi doesn't solve the problem, then it's probably not acpi. I downloaded the acpi table and iasl shows me this epox.asl 2575: Name (_HID, _NVRAIDBUS) Error1068 - String must be entirely alphanumeric ^ (_NVRAIDBUS) Is here somebody how like to try to help me out here? You can get the files here: http://suporte.matik.com.br/epox.dsl http://suporte.matik.com.br/epox.dmesg You could get rid of the _ anywhere NVRAIDBUS occurs. But this should have nothing to do with causing resets. IIRC it is an error to put non-alphanumeric onto an _HID node, but ACPI-CA interpreter is able to handle this situation. IOW iasl will give up if such error is done and is to compiling such ASL, but the in-kernel AML interpreter should interprete such things correctly. If the ASL contains only this error, it won't help the OP to override the DSDT. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
On Monday 23 January 2006 08:59, Bruno Ducrot wrote: epox.asl 2575: Name (_HID, _NVRAIDBUS) Error1068 - String must be entirely alphanumeric ^ (_NVRAIDBUS) Is here somebody how like to try to help me out here? You can get the files here: http://suporte.matik.com.br/epox.dsl http://suporte.matik.com.br/epox.dmesg You could get rid of the _ anywhere NVRAIDBUS occurs. But this should have nothing to do with causing resets. good to know, after it iasl compiles fine with only an WAK warning as Reserved method must return a value (_WAK) IIRC it is an error to put non-alphanumeric onto an _HID node, but ACPI-CA interpreter is able to handle this situation. IOW iasl will give up if such error is done and is to compiling such ASL, but the in-kernel AML interpreter should interprete such things correctly. If the ASL contains only this error, it won't help the OP to override the DSDT. good to know as well, what means supposed my cards are ok the motherboard has issues right thank's João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Page fault, GEOM problem??
On Mon, 2006-01-23 at 10:24 +0100, Johan Ström wrote: On 23 jan 2006, at 09.53, Michael S. Eubanks wrote: On Mon, 2006-01-23 at 06:43 +0100, Johan Ström wrote: Wish I could be of more help. :) Have you tried to toggle the sysctl dma flags? I've seen similar posts in the past with read timeouts caused from dma being enabled. # sysctl -a | grep dma ... hw.ata.ata_dma: 1 === Try turning this one off (1 == 0). hw.ata.atapi_dma: 1 ... Disabling DMA, wouldnt that give me pretty bad performance? -Michael If it was not the problem, you could always change it back. It *should* be possible to simply set the control mode on those two disks (``man rc.early'', ``man atacontrol''). Unfortunately, the problem is noted as errata in several FreeBSD versions tending to appear on SATA disks. I believe this is also a problem with some linux setups. If you google ``FreeBSD hw.ata.ata_dma RELEASE'' you will eventually find the following page relating to Asus motherboards: http://www.ryxi.com/freebsd/63-668-write-dma-other-similar-errors-read.shtml I picked it out based on the following line in the dmesg output: Nov 29 20:46:09 elfi kernel: ACPI APIC Table: ASUS A7V333 I'd say it's worth a shot. You might even try turning both the flags off temporarily to see what you get. Your guess is as good as mine. :) -Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
On Mon, Jan 23, 2006 at 10:49:02AM -0200, JoaoBR wrote: On Monday 23 January 2006 08:59, Bruno Ducrot wrote: epox.asl 2575: Name (_HID, _NVRAIDBUS) Error1068 - String must be entirely alphanumeric ^ (_NVRAIDBUS) Is here somebody how like to try to help me out here? You can get the files here: http://suporte.matik.com.br/epox.dsl http://suporte.matik.com.br/epox.dmesg You could get rid of the _ anywhere NVRAIDBUS occurs. But this should have nothing to do with causing resets. good to know, after it iasl compiles fine with only an WAK warning as Reserved method must return a value (_WAK) IIRC it is an error to put non-alphanumeric onto an _HID node, but ACPI-CA interpreter is able to handle this situation. IOW iasl will give up if such error is done and is to compiling such ASL, but the in-kernel AML interpreter should interprete such things correctly. If the ASL contains only this error, it won't help the OP to override the DSDT. good to know as well, what means supposed my cards are ok the motherboard has issues right Can't tell for sure if you don't test without ACPI loaded. It may be possible after all the apci_thermal subsystem trigger a (false) overheat situation which may explain a sudden shutdown. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Page fault, GEOM problem??
I'm coming in very late here, and only have some hearsay. But, a friend of mine has built a new hobby machine, with twin 160G drives on a 3Ware 8006, working as a stripe. He had a bunch of problems with stability of the drives until I gave him a couple of tiny (half size) jumpers, that he put on the drive. Smooth sailing since them. If needed, I can find what the jumpers did. But looking through the controllers doco should give you a clue. Johan Ström wrote: On 23 jan 2006, at 09.53, Michael S. Eubanks wrote: On Mon, 2006-01-23 at 06:43 +0100, Johan Ström wrote: Wish I could be of more help. :) Have you tried to toggle the sysctl dma flags? I've seen similar posts in the past with read timeouts caused from dma being enabled. # sysctl -a | grep dma ... hw.ata.ata_dma: 1 === Try turning this one off (1 == 0). hw.ata.atapi_dma: 1 ... Disabling DMA, wouldnt that give me pretty bad performance? -Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Paul Root Few people know what to do when hula girls attack. - Sam, age 8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, Jan 23, 2006 at 04:27:09PM +0200, Ion-Mihai Tetcu wrote: I On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu wrote: I I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff wrote: I I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff wrote: I I T This should be fixed in src/sys/kern_mbuf.c, rev. 1.9.2.3 I I I I And another bogus panic is removed in 1.9.2.4 I I I I I I The kernel is working again, thanks! I I I I It's working in regard of vr0, thank you. However now my computer I I resets w/o anything logged when starting kde; if I only startx it I I doesn't happen (without exec startkde in .xinitrc); I commented I I out any fancy options like dri with no effect and it also happen I I if I kldunload snd_via8233 before starting kde. I I I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; it didn't I I happen with sources from 19. I I Bad news. Can you do a binary search and find commit that makes this I regression? I I FreeBSD 6.0-STABLE #1: Mon Jan 23 00:45:10 EET 2006 works:) So upgrading once more did help you? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, 23 Jan 2006 17:31:47 +0300 Gleb Smirnoff [EMAIL PROTECTED] wrote: On Mon, Jan 23, 2006 at 04:27:09PM +0200, Ion-Mihai Tetcu wrote: I On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu wrote: I I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff I I wrote: I I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff I I wrote: I I T This should be fixed in src/sys/kern_mbuf.c, rev. I I T 1.9.2.3 I I I I And another bogus panic is removed in 1.9.2.4 I I I I I I The kernel is working again, thanks! I I I I It's working in regard of vr0, thank you. However now my I I computer resets w/o anything logged when starting kde; if I I I only startx it doesn't happen (without exec startkde I I in .xinitrc); I commented out any fancy options like dri with I I no effect and it also happen if I kldunload snd_via8233 I I before starting kde. I I I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; it I I didn't happen with sources from 19. I I Bad news. Can you do a binary search and find commit that makes I this regression? I I FreeBSD 6.0-STABLE #1: Mon Jan 23 00:45:10 EET 2006 works:) So upgrading once more did help you? So it seem. I am using ULE, I have no problem with the new kernel with either UL or 4BSD. I didn't test the bad kernel with 4BSD, but I could do it if you like. -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #336: the xy axis in the trackball is coordinated with the summer solstice ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: kmem_malloc
Hi, At me a problem - after one - two weeks of job the machine panics and is reboot, prompt as to see why it occurs that it is possible to make with it? There can be data resulted below - will help to help me. #uname -a FreeBSD crom.azimutprint.ru 6.0-STABLE FreeBSD 6.0-STABLE #1: Fri Jan 13 11:29:48 MSK 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/cromkernel i386 #bzgrep panic /var/log/messages.?.bz2 | grep -v savecore Dec 26 10:48:43 crom kernel: panic: kmem_malloc(16384): kmem_map too small: 172457984 total allocated Dec 6 17:28:43 crom kernel: panic: kmem_malloc(4096): kmem_map too small: 172470272 total allocated #grep panic /var/log/messages | grep -v savecore Jan 20 03:04:42 crom kernel: panic: kmem_malloc(4096): kmem_map too small: 172470272 total allocated And attach dmesg.txt FreeBSD 6.0-STABLE #1: Fri Jan 13 11:29:48 MSK 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/cromkernel Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2806.37-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf33 Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x41dSSE3,RSVD2,MON,DS_CPL,CNTX-ID Hyperthreading: 2 logical CPUs real memory = 536018944 (511 MB) avail memory = 515055616 (491 MB) ACPI APIC Table: A M I OEMAPIC ioapic0 Version 2.0 irqs 0-23 on motherboard acpi0: A M I OEMXSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82875P host to AGP bridge mem 0xfe80-0xfebf at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 3.0 on pci0 pci2: ACPI PCI bus on pcib2 em0: Intel(R) PRO/1000 Network Connection Version - 3.2.18 port 0xcf80-0xcf9f mem 0xfe5e-0xfe5f irq 18 at device 1.0 on pci2 em0: Ethernet address: 00:0e:a6:5f:f2:ba pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci3: ACPI PCI bus on pcib3 atapci0: Promise PDC20378 SATA150 controller port 0xdf00-0xdf3f,0xdfa0-0xdfaf,0xdc00-0xdc7f mem 0xfe6fe000-0xfe6fefff,0xfe6c-0xfe6d irq 23 at device 4.0 on pci3 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 ata4: ATA channel 2 on atapci0 xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xd880-0xd8ff mem 0xfe6ff400-0xfe6ff47f irq 22 at device 10.0 on pci3 miibus0: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:76:e8:98:07 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci1: Intel ICH5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: ATA channel 0 on atapci1 ata1: ATA channel 1 on atapci1 pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Power Button on acpi0 speaker0: PC speaker port 0x61 on acpi0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xd6800-0xd6fff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 2806374508 Hz quality 800 Timecounters tick every 1.000 msec Fast IPsec: Initialized Security Association Processing. ad0: 194481MB Maxtor 6Y200P0 YAR41BW0 at ata0-master UDMA100 acd0: CDROM LG CD-ROM CRD-8521B/1.00 at ata1-master PIO4 ad4: 305245MB WDC WD3200JD-00KLB0 08.05J08 at ata2-master SATA150 ad6: 305245MB WDC WD3200JD-00KLB0 08.05J08 at ata3-master SATA150 ad8: 305245MB WDC WD3200JB-00KFA0 08.05J08 at ata4-master UDMA100 ad9: 305245MB WDC WD3200JB-00KFA0 08.05J08 at ata4-slave UDMA100 ar0: 610351MB Promise Fasttrak RAID0+1 (stripe 64 KB) status: READY ar0: disk0 READY (master) using ad4 at ata2-master ar0: disk1 READY (master) using ad6 at ata3-master ar0: disk2 READY (mirror) using ad8 at ata4-master ar0: disk3 READY (mirror) using ad9 at ata4-slave Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted WARNING: /raid1 was not properly dismounted em0: link state changed to UP WARNING: pseudo-random number generator used for IPsec processing
libc bug with nsswitch?
Hi, there seems to be a problem with RELENG_6 in environments where nss_ldap is used for user- and group-lookups. The problem affects different ports that don't have very much in common, so I guess there might be a bug in FreeBSD's libc, because that's the place, where the name-sevices are handled (correct me if I'm wrong). Two examples that are reproduceable here on various machines: 1. emulators/linux_base-8: When nss_ldap is enabled in /etc/nsswitch.conf, the installation of the port fails: --- log --- === Patching for linux_base-8-8.0_11 === linux_base-8-8.0_11 depends on executable: rpm - found === Configuring for linux_base-8-8.0_11 --- Installing the new version via the port === Installing for linux_base-8-8.0_11 === Generating temporary packing list === Checking if emulators/linux_base-8 already installed kern.fallback_elf_brand: 3 - 3 redhat-release-8.0-8.noarch.rpm glibc-common-2.3.2-4.80.8.i386.rpm [...list of rpms...] sh-utils-2.0.12-3.i386.rpm rpm-4.1-1.06.i386.rpm You have (unsupported) /var/lib/rpm/packages.rpm db1 format installed package headers Please install rpm-4.0.4 first, and do rpm --rebuilddb to convert your database from db1 to db3 format. var/tmp/rpm-tmp.41237: line 11: /dev/null: No such file or directory var/tmp/rpm-tmp.41237: line 12: /dev/null: No such file or directory Assertion failed: (cfg-ldc_uris[__session.ls_current_uri] != NULL), function do_init, file ldap-nss.c, line 1245. Abort trap (core dumped) *** Error code 134 Stop in /usr/ports/emulators/linux_base-8. *** Error code 1 Stop in /usr/ports/emulators/linux_base-8. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portinstall5998.0 make reinstall ** Fix the installation problem and try again. ** Listing the failed packages (*:skipped / !:failed) ! emulators/linux_base-8(install error) --- log --- 2. PHP4(5)/PEAR This was also reported by two other users, both are using nss_ldap but have PHP5 instead of PHP4. With nss_ldap enabled, the use of at least two php-modules (imagick, xslt) lead to a segmentation fault in php4, e.g. when trying to install an additional pear-module: --- log --- === Installing for pear-OLE-0.5 === pear-OLE-0.5 depends on file: /usr/local/share/pear/PEAR.php - found === pear-OLE-0.5 depends on executable: pear - found === Generating packing list === Generating temporary packing list === Checking if devel/pear-OLE already installed install ok: channel://pear.php.net/OLE-0.5 Segmentation fault (core dumped) *** Error code 139 Stop in /usr/ports/devel/pear-OLE. *** Error code 1 Stop in /usr/ports/textproc/pear-Spreadsheet_Excel_Writer. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portinstall39034.0 mak e ** Fix the problem and try again. --- log --- In both cases the installation works without any problem as soon as you disable nss_ldap (renaming /etc/nsswitch.conf is sufficient). my nsswitch.conf is as simple as this: passwd: files ldap group: files ldap bye, Uwe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, 23 Jan 2006 11:05:25 +0300 Gleb Smirnoff [EMAIL PROTECTED] wrote: On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu wrote: I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff wrote: I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff wrote: I T This should be fixed in src/sys/kern_mbuf.c, rev. 1.9.2.3 I I And another bogus panic is removed in 1.9.2.4 I I I The kernel is working again, thanks! I I It's working in regard of vr0, thank you. However now my computer I resets w/o anything logged when starting kde; if I only startx it I doesn't happen (without exec startkde in .xinitrc); I commented I out any fancy options like dri with no effect and it also happen I if I kldunload snd_via8233 before starting kde. I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; it didn't I happen with sources from 19. Bad news. Can you do a binary search and find commit that makes this regression? FreeBSD 6.0-STABLE #1: Mon Jan 23 00:45:10 EET 2006 works:) -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #113: Root nameservers are out of sync ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, Jan 23, 2006 at 04:35:07PM +0200, Ion-Mihai Tetcu wrote: I On Mon, Jan 23, 2006 at 04:27:09PM +0200, Ion-Mihai Tetcu wrote: I I On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu wrote: I I I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff I I I wrote: I I I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff I I I wrote: I I I T This should be fixed in src/sys/kern_mbuf.c, rev. I I I T 1.9.2.3 I I I I I I And another bogus panic is removed in 1.9.2.4 I I I I I I I I I The kernel is working again, thanks! I I I I I I It's working in regard of vr0, thank you. However now my I I I computer resets w/o anything logged when starting kde; if I I I I only startx it doesn't happen (without exec startkde I I I in .xinitrc); I commented out any fancy options like dri with I I I no effect and it also happen if I kldunload snd_via8233 I I I before starting kde. I I I I I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; it I I I didn't happen with sources from 19. I I I I Bad news. Can you do a binary search and find commit that makes I I this regression? I I I I FreeBSD 6.0-STABLE #1: Mon Jan 23 00:45:10 EET 2006 works:) I I So upgrading once more did help you? I I So it seem. I am using ULE, I have no problem with the new kernel with I either UL or 4BSD. I didn't test the bad kernel with 4BSD, but I I could do it if you like. Probably you hit another incorrect KASSERT in kern_mbuf.c. I have removed it some time after the first one. Since X was starting at this moment you couldn't be dropped into debugger, and so the box was rebooting. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, 23 Jan 2006 17:39:56 +0300 Gleb Smirnoff [EMAIL PROTECTED] wrote: On Mon, Jan 23, 2006 at 04:35:07PM +0200, Ion-Mihai Tetcu wrote: I On Mon, Jan 23, 2006 at 04:27:09PM +0200, Ion-Mihai Tetcu wrote: I I On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu I I wrote: I I I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff I I I wrote: I I I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb I I I Smirnoff wrote: I I I T This should be fixed in src/sys/kern_mbuf.c, I I I T rev. 1.9.2.3 I I I I I I And another bogus panic is removed in 1.9.2.4 I I I I I I I I I The kernel is working again, thanks! I I I I I I It's working in regard of vr0, thank you. However now my I I I computer resets w/o anything logged when starting kde; I I I if I only startx it doesn't happen (without exec startkde I I I in .xinitrc); I commented out any fancy options like dri I I I with no effect and it also happen if I kldunload I I I snd_via8233 before starting kde. I I I I I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; I I I it didn't happen with sources from 19. I I I I Bad news. Can you do a binary search and find commit that I I makes this regression? I I I I FreeBSD 6.0-STABLE #1: Mon Jan 23 00:45:10 EET 2006 I I works:) I I So upgrading once more did help you? I I So it seem. I am using ULE, I have no problem with the new kernel I with either UL or 4BSD. I didn't test the bad kernel with 4BSD, I but I could do it if you like. Probably you hit another incorrect KASSERT in kern_mbuf.c. I have removed it some time after the first one. Since X was starting at this moment you couldn't be dropped into debugger, and so the box was rebooting. I don't know if I understand you right, but starting a bare X and playing around for a while then typing startkde resulted in a reset. -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect Ferengi Rule of Acquisition #168: Whisper your way to success. -- ST:DS9, Treachery, Faith, and the Great River ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, Jan 23, 2006 at 04:44:53PM +0200, Ion-Mihai Tetcu wrote: I Probably you hit another incorrect KASSERT in kern_mbuf.c. I have I removed it some time after the first one. Since X was starting at I this moment you couldn't be dropped into debugger, and so the box was I rebooting. I I I don't know if I understand you right, but starting a bare X and I playing around for a while then typing startkde resulted in a reset. When panic happens and you have X on the screen, the kernel can't switch to syscons. It dumps core if you have KDB_UNATTENDED in kernel, in other case it just reboots. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_malloc
GreenX FreeBSD wrote: Hi, At me a problem - after one - two weeks of job the machine panics and is reboot, prompt as to see why it occurs that it is possible to make with it? Can you tell us the output of .. sysctl -a | grep ^ata_ .. I have a suspicion .. Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
problem with vlan interfaces in 6-STABLE
Hi everybody,
After my latest update to
FreeBSD hudson 6.0-STABLE FreeBSD 6.0-STABLE #15:
Mon Jan 23 12:29:38 CET 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/NFS-32-FBSD6 i386
I have a small problem with my vlan interfaces configured from rc.conf:
They get configured well, but they are simply not in up state as they
were before autmatically. I can login via console and do
ifconfig vlan340 up
and all is fine. The config did not change during the update:
cloned_interfaces=vlan340
ifconfig_em0=up vlanhwtag vlanmtu
ifconfig_vlan340=inet xx.xx.xx.xx netmask 255.255.255.192 vlan 340 vlandev em0
Is putting and additional:
ifconfig ${ifn} up
in the create loop in network.subr the way to fix this issue?
Thanx, Oliver
--
| Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin |
| Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ |
| Ich bin das Internet. Sowahr ich Gott helfe. |
| Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! |
pgpIbyPCgiXkj.pgp
Description: PGP signature
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, 23 Jan 2006 17:50:25 +0300 Gleb Smirnoff [EMAIL PROTECTED] wrote: On Mon, Jan 23, 2006 at 04:44:53PM +0200, Ion-Mihai Tetcu wrote: I Probably you hit another incorrect KASSERT in kern_mbuf.c. I have I removed it some time after the first one. Since X was starting at I this moment you couldn't be dropped into debugger, and so the I box was rebooting. I I I don't know if I understand you right, but starting a bare X and I playing around for a while then typing startkde resulted in a I reset. When panic happens and you have X on the screen, the kernel can't switch to syscons. It dumps core if you have KDB_UNATTENDED in kernel, in other case it just reboots. I don't have KDB_UNATTENDED but on this machine the in the last week I got an automatic dump (on a kmem_map too small while running an RC1 kernel) and then the reboot and I was under X (kde); I remember I had to wait and watch the HDD led w/o being able to do anything else. -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect Without freedom of choice there is no creativity. -- Kirk, The return of the Archons, stardate 3157.4 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
On Monday 23 January 2006 11:49, Bruno Ducrot wrote: good to know as well, what means supposed my cards are ok the motherboard has issues right Can't tell for sure if you don't test without ACPI loaded. It may be possible after all the apci_thermal subsystem trigger a (false) overheat situation which may explain a sudden shutdown. very nice because exactly this is what I thought, still more likely since the sudden off happens after a certain time when compiling world or other processor expensive tasks any hint how I can get closer to know this? Am I right that the shutdown comes from the motherboard in this case so there is not so very much to do for the OS? normally I find 20 up to 23 hw.acpi.thermal.tz0.temperature: 21.8C but unfortunatly I never could get it in time when it shut off there is an option in the BIOS as ACPI Shutdown Temp but it is disabled I just compiled cpufrequency into the kernel and enabled BIOS Smartfan CPU Temp to see what I get hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% machdep.cpu_idle_hlt: 1 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2000 dev.cpu.0.freq_levels: 2000/67000 1800/64700 1000/28600 dev.acpi_perf.0.%parent: cpu0 dev.powernow.0.%parent: cpu0 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 thank's again João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
how to harden freebsd?
Hey, i think about jailing some processes on a new freebsd-system. Is there also another way, to harden freebsd e.g. like selinux? Roger ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to harden freebsd?
On Monday 23 January 2006 17:42, Roger Grosswiler wrote: i think about jailing some processes on a new freebsd-system. Is there also another way, to harden freebsd e.g. like selinux? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/security.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/securing-freebsd.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp6Gb0OQhL4U.pgp Description: PGP signature
Re: how to harden freebsd?
On Mon, Jan 23, 2006 at 05:42:42PM +0100, Roger Grosswiler wrote: i think about jailing some processes on a new freebsd-system. Is there also another way, to harden freebsd e.g. like selinux? Have a look at security(7) for an overview of the existing FreeBSD security options. Also, jail(8) has some bits. There's no /direct/ SELinux, although much of the same ground is covered by the TrustedBSD stuff. Have a look over the web site: http://www.trustedbsd.org/ -Dom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to harden freebsd?
i think about jailing some processes on a new freebsd-system. Is there also another way, to harden freebsd e.g. like selinux? Start here: Mandatory Access Control http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
On Mon, Jan 23, 2006 at 01:52:11PM -0200, JoaoBR wrote: On Monday 23 January 2006 11:49, Bruno Ducrot wrote: good to know as well, what means supposed my cards are ok the motherboard has issues right Can't tell for sure if you don't test without ACPI loaded. It may be possible after all the apci_thermal subsystem trigger a (false) overheat situation which may explain a sudden shutdown. very nice because exactly this is what I thought, still more likely since the sudden off happens after a certain time when compiling world or other processor expensive tasks any hint how I can get closer to know this? Am I right that the shutdown comes from the motherboard in this case so there is not so very much to do for the OS? normally I find 20 up to 23 hw.acpi.thermal.tz0.temperature: 21.8C but unfortunatly I never could get it in time when it shut off there is an option in the BIOS as ACPI Shutdown Temp but it is disabled I just compiled cpufrequency into the kernel and enabled BIOS Smartfan CPU Temp to see what I get hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% machdep.cpu_idle_hlt: 1 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2000 dev.cpu.0.freq_levels: 2000/67000 1800/64700 1000/28600 dev.acpi_perf.0.%parent: cpu0 dev.powernow.0.%parent: cpu0 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 The temperature is read from some isa io port at 0x295... I'm wondering if you should use mbmon instead of ACPI (the _TMP method in that DSDT look a little ugly to my eyes, though I am not sure if it will give some buggy informations). Maybe you should try to disable acpi thermal stuff via hint.acpi_tz.0.disabled=1 and use the mbmon port for monitoring those temperatures. Don't use ACPI and mbmon at the same time: there will be some conflicts accessing the sensor chip internal registers. As an added 'bonus', you should have access to motherboard temperature, not only CPU, and you should be able to monitor voltages, fan, etc. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
On Monday 23 January 2006 16:08, Bruno Ducrot wrote: \ The temperature is read from some isa io port at 0x295... I'm wondering if you should use mbmon instead of ACPI (the _TMP method in that DSDT look a little ugly to my eyes, though I am not sure if it will give some buggy informations). ok, I didn't said it before but I graf with mrtg based on mbmon and I ever get something 40C but I never got peaks, then this sysctl temperatur is never higher then 24C what then confirmes you are saying here Maybe you should try to disable acpi thermal stuff via hint.acpi_tz.0.disabled=1 I will try it I haven't done it because I thought that if the shutoff is caused by a hardware/bios feature then the OS can not do so very much here but a try does not hurt anything this: debug.acpi.disabled=thermal would be the same? João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
JoaoBR wrote: On Monday 23 January 2006 16:08, Bruno Ducrot wrote: Maybe you should try to disable acpi thermal stuff via hint.acpi_tz.0.disabled=1 I will try it I haven't done it because I thought that if the shutoff is caused by a hardware/bios feature then the OS can not do so very much here but a try does not hurt anything this: debug.acpi.disabled=thermal would be the same? Yes. The first version he gave is the generic driver disabling mechanism, the acpi version disables all subsystems related to the function. It may be redundant though at this point and we might consider removing it. -- Nate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Page fault, GEOM problem?? (also: using a ASUS A7N8X-XE/nForce2 utlra400?)
On 23 jan 2006, at 14.15, Michael S. Eubanks wrote: On Mon, 2006-01-23 at 10:24 +0100, Johan Ström wrote: On 23 jan 2006, at 09.53, Michael S. Eubanks wrote: On Mon, 2006-01-23 at 06:43 +0100, Johan Ström wrote: Wish I could be of more help. :) Have you tried to toggle the sysctl dma flags? I've seen similar posts in the past with read timeouts caused from dma being enabled. # sysctl -a | grep dma ... hw.ata.ata_dma: 1 === Try turning this one off (1 == 0). hw.ata.atapi_dma: 1 ... Disabling DMA, wouldnt that give me pretty bad performance? -Michael If it was not the problem, you could always change it back. It *should* be possible to simply set the control mode on those two disks (``man rc.early'', ``man atacontrol''). Unfortunately, the problem is noted as errata in several FreeBSD versions tending to appear on SATA disks. I believe this is also a problem with some linux setups. If you google ``FreeBSD hw.ata.ata_dma RELEASE'' you will eventually find the following page relating to Asus motherboards: http://www.ryxi.com/freebsd/63-668-write-dma-other-similar-errors- read.shtml I picked it out based on the following line in the dmesg output: Nov 29 20:46:09 elfi kernel: ACPI APIC Table: ASUS A7V333 I'd say it's worth a shot. You might even try turning both the flags off temporarily to see what you get. Your guess is as good as mine. :) Okay, tried turning it of.. The disk IO speeds went even lower... whoping 9-10MB/s and lots of load ;) And since the crashes comes randomly (haven't been able to reproduce them on deamon) i dont realy want to run it like this.. ;) I did another test. I moved the controller card and the disks to my MSI K8N Neo motherboard (with AMD64 3200+ etc), and immediatly I got write speeds of ~49MB/s: $ dd if=/dev/zero of=bigfile.zero bs=1024 count=124 1024024576 bytes transferred in 21.974227 secs (46601164 bytes/sec) Compared to $ dd if=/dev/zero of=bigfile.zero bs=1024 count=124 1024024576 bytes transferred in 78.897708 secs (12979142 bytes/sec) All tests where done in /dev/mirror/gm0s1f on /usr (ufs, NFS exported, local, soft-updates, acls) Soo.. I guess this mobo is just plain fucked and needs to be replaced with something newer ;) Bad thing is, this is Socket A.. so there isnt so many choices left in the mobo market.. However, i found a ASUS A7N8X-XE NF ULTRA 400 SOCKET A with Nforce2 Ultra 400 chipset.. Does anyone have any knowledge about this chipset? How well does it work with Fbsd? I'll do some googling but if someone is using this successfully or unsuccessfully, please let me know :) -- Johan
Re: Page fault, GEOM problem??
On 23 jan 2006, at 20.16, Paul T. Root wrote: My friends disks are SATA. The jumper was to force the drives to use the SATA 1.x 1.5 gig standard instead of the faster SATA 2.x standard. Older cards can have trouble recognizing newer disks. His were recognized, but very flaky. They've been solid since. These disk should be SATA150 afaik (Maxtor MaXLine III 300Gb). The promise card is named SATAII 150.. So shouldnt be any missmatching. Both card and disks supports NCQ.. Dunno about freebsd on the other hand..Havent found a way to enable/ disable this Johan Ström wrote: On 23 jan 2006, at 15.29, Paul T. Root wrote: I'm coming in very late here, and only have some hearsay. But, a friend of mine has built a new hobby machine, with twin 160G drives on a 3Ware 8006, working as a stripe. He had a bunch of problems with stability of the drives until I gave him a couple of tiny (half size) jumpers, that he put on the drive. Smooth sailing since them. If needed, I can find what the jumpers did. But looking through the controllers doco should give you a clue. As far as I know, SATA drives doesnt have jumpers.. Mine doesnt seem to do atleast.. There are two unused pins but i doubt they are for jumpers.. -- Paul Root Few people know what to do when hula girls attack. - Sam, age 8
Re: need help for DSDT for an Epox Amd64 MB
On Monday 23 January 2006 16:48, Nate Lawson wrote: hint.acpi_tz.0.disabled=1 debug.acpi.disabled=thermal would be the same? Yes. The first version he gave is the generic driver disabling mechanism, the acpi version disables all subsystems related to the function. It may be redundant though at this point and we might consider removing it. well, would you mind saying which one exactly you think of for removing? thank you João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system laggy under load, SCHED_BSD
On Mon, Jan 23, 2006 at 11:46:01AM +0300, Gleb Smirnoff wrote: On Sun, Jan 22, 2006 at 11:00:28PM +0100, Tobias Roth wrote: T Since some time, I experience extremely bad system behaviour under T load. For instance when compiling something, or unpacking a large T archive, the system is almost unusable, even the mouse pointer T reacts sloppy. T T My system: T T 6.0-STABLE FreeBSD 6.0-STABLE #7: Sun Jan 22 15:53:39 CET 2006 i386 T T I use SCHED_BSD. T T How can I diagnose the problem, or provide more information? What T factors might influence what I experience? I cannot give a more precise T point in time as when this started, since I switched versions and T systems a few times recently. What are numbers for the swap in/out in top(1)? No swapping is hapenind accordng to top. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient wedged
On Mon, Jan 23, 2006 at 10:06:56AM +0100, Krzysztof Kowalik wrote: Brooks Davis [EMAIL PROTECTED] wrote: This definitly sounds like something particular to your dhcp servers. It would be nice if we could fix it, but without some debugging help that's going to be pretty much impossible. [...] It happens to me quite often, too. The only thing related in the non-debug messages is: Jan 8 12:02:19 moneypenny dhclient[68091]: 5 bad IP checksums seen in 5 packets Jan 8 12:02:49 moneypenny last message repeated 743054 times Jan 8 12:04:50 moneypenny last message repeated 2951866 times Jan 8 12:14:51 moneypenny last message repeated 14457921 times Jan 8 12:24:52 moneypenny last message repeated 14812032 times Jan 8 12:34:53 moneypenny last message repeated 14770327 times Jan 8 12:44:55 moneypenny last message repeated 14748300 times Jan 8 12:51:44 moneypenny last message repeated 10037074 times ... which accounts for the CPU usage, I guess. I killed the bad IP checksums messages, so it doesn't annoy my syslog anymore, but it of course didn't fix the underlaying issue. I was looking at those packets with tcpdump once and didn't see anything obvious/bad there. And yes, I didn't have this problem with ISC client. And I surely use different cable provider, than the original poster ;) What NIC are you using? This particular issue sounds like a NIC returning corrupt packets for some reason. Alternatively, the sending server could be producing corrupt packets. Some tcpdump traces (preferably raw dumps) could be useful. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgprpjH6da2ZF.pgp Description: PGP signature
Re: need help for DSDT for an Epox Amd64 MB
JoaoBR wrote: On Monday 23 January 2006 16:48, Nate Lawson wrote: hint.acpi_tz.0.disabled=1 debug.acpi.disabled=thermal would be the same? Yes. The first version he gave is the generic driver disabling mechanism, the acpi version disables all subsystems related to the function. It may be redundant though at this point and we might consider removing it. well, would you mind saying which one exactly you think of for removing? Thinking of removing debug.acpi.disabled since it is mostly redundant with the hint approach. But more investigation should be done before claiming that. -- Nate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system laggy under load, SCHED_BSD
On Sun, Jan 22, 2006 at 05:25:33PM -0500, Kris Kennaway wrote: On Sun, Jan 22, 2006 at 11:00:28PM +0100, Tobias Roth wrote: Hi Since some time, I experience extremely bad system behaviour under load. For instance when compiling something, or unpacking a large archive, the system is almost unusable, even the mouse pointer reacts sloppy. My system: 6.0-STABLE FreeBSD 6.0-STABLE #7: Sun Jan 22 15:53:39 CET 2006 i386 I use SCHED_BSD. How can I diagnose the problem, or provide more information? What factors might influence what I experience? I cannot give a more precise point in time as when this started, since I switched versions and systems a few times recently. This has been discussed a number of times: the short answer is to look for interrupt storms (vmstat -i), interrupt sharing (also vmstat -i), and in particular shared interrupts involving usb or other drivers still under Giant. Nothing out of the ordinary, when looking at those interrupts. However, turning on DMA for the harddisk made the mouse pointer sloppyness go away. Now hand me that pointy hat and let me sit in some dark corner... Thanks, Tobias ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
JoaoBR wrote:
On Monday 23 January 2006 19:48, Nate Lawson wrote:
well, would you mind saying which one exactly you think of for removing?
Thinking of removing debug.acpi.disabled since it is mostly redundant
with the hint approach. But more investigation should be done before
claiming that.
ok, means that all acpi subdrivers can not be disabled any more in boot.loader
and would be switched as hints on or off, right
is this already possible, I mean disabling the acpi subsets as hints?
let me ask what would be the advantage of using hints instead? Any timeline
for this or just a thought at this time?
grep resource_disabled /sys/dev/acpica/*.c
/sys/dev/acpica/acpi.c:if (resource_disabled(acpi, 0))
/sys/dev/acpica/acpi_perf.c:if (resource_disabled(acpi_perf, 0))
/sys/dev/acpica/acpi_throttle.c:if
(resource_disabled(acpi_throttle, 0))
grep acpi_disabled /sys/dev/acpica/*.c
/sys/dev/acpica/acpi.c:if (!acpi_disabled(bus))
/sys/dev/acpica/acpi.c:if (acpi_disabled(children))
/sys/dev/acpica/acpi.c: if (acpi_disabled(children))
/sys/dev/acpica/acpi.c:acpi_disabled(char *subsys)
/sys/dev/acpica/acpi_acad.c:if (acpi_disabled(acad) ||
/sys/dev/acpica/acpi_button.c:if (acpi_disabled(button) ||
/sys/dev/acpica/acpi_cmbat.c:if (acpi_disabled(cmbat) ||
/sys/dev/acpica/acpi_cpu.c:if (acpi_disabled(cpu) ||
acpi_get_type(dev) != ACPI_TYPE_PROCESSOR)
/sys/dev/acpica/acpi_ec.c:if (acpi_get_type(dev) != ACPI_TYPE_DEVICE
|| acpi_disabled(ec))
/sys/dev/acpica/acpi_hpet.c:if (acpi_disabled(hpet) ||
/sys/dev/acpica/acpi_isab.c:if (acpi_disabled(isab) ||
/sys/dev/acpica/acpi_lid.c:if (acpi_disabled(lid) ||
/sys/dev/acpica/acpi_pci_link.c:if (acpi_disabled(pci_link) ||
/sys/dev/acpica/acpi_pcib_acpi.c:if (acpi_disabled(pcib) ||
/sys/dev/acpica/acpi_pcib_pci.c:acpi_disabled(pci))
/sys/dev/acpica/acpi_resource.c:if (acpi_disabled(sysresource) ||
/sys/dev/acpica/acpi_smbat.c: if (acpi_disabled(smbat) ||
/sys/dev/acpica/acpi_thermal.c:if (acpi_get_type(dev) ==
ACPI_TYPE_THERMAL !acpi_disabled(thermal)) {
/sys/dev/acpica/acpi_timer.c:if (acpi_disabled(timer) ||
(acpi_quirks ACPI_Q_TIMER) ||
/sys/dev/acpica/acpi_video.c: if (acpi_disabled(video) ||
So it looks like debug.acpi.disabled=thermal is the only way to do it
for now. We may want to move to resource_disabled later, but that's for
future discusion.
--
Nate
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient wedged
Brooks Davis [EMAIL PROTECTED] wrote: What NIC are you using? fxp0: Intel 82559 Pro/100 Ethernet port 0xc000-0xc03f mem 0xdb121000-0xdb121fff,0xdb00-0xdb0f irq 11 at device 1.0 on pci2 This particular issue sounds like a NIC returning corrupt packets for some reason. Alternatively, the sending server could be producing corrupt packets. Some tcpdump traces (preferably raw dumps) could be useful. As I said, I didn't see anything bad in the tcpdump. And since I really didn't have such issues before, and I don't see anything weird in any other place... I recompiled dhclient with -g and will tcpdump the traffic again, if I notice it eating 99% of CPU time again. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
On Monday 23 January 2006 19:48, Nate Lawson wrote: well, would you mind saying which one exactly you think of for removing? Thinking of removing debug.acpi.disabled since it is mostly redundant with the hint approach. But more investigation should be done before claiming that. ok, means that all acpi subdrivers can not be disabled any more in boot.loader and would be switched as hints on or off, right is this already possible, I mean disabling the acpi subsets as hints? let me ask what would be the advantage of using hints instead? Any timeline for this or just a thought at this time? thank's João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with vlan interfaces in 6-STABLE
On Mon, Jan 23, 2006 at 01:28:00PM +0100, Oliver Brandmueller wrote: Hi everybody, After my latest update to FreeBSD hudson 6.0-STABLE FreeBSD 6.0-STABLE #15: Mon Jan 23 12:29:38 CET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NFS-32-FBSD6 i386 I have a small problem with my vlan interfaces configured from rc.conf: They get configured well, but they are simply not in up state as they were before autmatically. I can login via console and do ifconfig vlan340 up and all is fine. The config did not change during the update: cloned_interfaces=vlan340 ifconfig_em0=up vlanhwtag vlanmtu ifconfig_vlan340=inet xx.xx.xx.xx netmask 255.255.255.192 vlan 340 vlandev em0 The problem you're experiencing may be related to changes I committed to ifconfig in RELENG_6. I'll investigate the issue ASAP and report my results in this list. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
On Monday 23 January 2006 20:42, Nate Lawson wrote: So it looks like debug.acpi.disabled=thermal is the only way to do it for now. We may want to move to resource_disabled later, but that's for future discusion. that was a good one, you just saved me some reboots and new questions about it and good to know where to lookup it thank's! João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic on logout in serial console
Hi all, I'm pretty aggravated right now. At exactly the wrong moment my spinal reflexes kicked in and I logged out from my serial console session on an important server. BANG! Kernel panic. This has been reported numerous times before, so I won't bother giving you the specifics right now - had to boot it immediately to come back up anyway, so no time. Anyway - I was told at some point that this would be fixed in 6.x - but backporting the fix to 5.x would be hard to impossible. Guess what: It's still not fixed. And it's a really really (did I say really?) bad thing, at least as far as I'm concerned. Any fixes in the pipeline here? I'd be happy to help testing any patches.. I'm mostly pissed with myself though - I knew about this and usually never log out. But when under pressure, habits kick in. :P With very frustrated regards, /Eirik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[HEADSUP] recent instability on ports for 4.X
The most recent checkin of bsd.*.mk has caused some instability which we (the portmgr team) now think we've fixed the critical parts of. 'make search' is still broken and we are working on that. This only affects 4.X. This was the first time we've tested a patchset on 5-exp instead of 4-exp and of course this enraged Murphy (he of Murphy's Law) and so he came and bit us pretty hard. As well, a few ports that were doing non-standard things with USE_RC_SUBR were broken by this same checkin, and we are working with the maintainers on those ports as we find them. Apologies for the instability. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient wedged
On Mon, Jan 23, 2006 at 11:25:25PM +0100, Krzysztof Kowalik wrote: Brooks Davis [EMAIL PROTECTED] wrote: What NIC are you using? fxp0: Intel 82559 Pro/100 Ethernet port 0xc000-0xc03f mem 0xdb121000-0xdb121fff,0xdb00-0xdb0f irq 11 at device 1.0 on pci2 What's ifconfig say? This particular issue sounds like a NIC returning corrupt packets for some reason. Alternatively, the sending server could be producing corrupt packets. Some tcpdump traces (preferably raw dumps) could be useful. As I said, I didn't see anything bad in the tcpdump. And since I really didn't have such issues before, and I don't see anything weird in any other place... I recompiled dhclient with -g and will tcpdump the traffic again, if I notice it eating 99% of CPU time again. OK, thanks. My other guess would be that we're getting misaligned relative to the buffer somehow and that's causing all the checksums to fail. If you can get into gdb when dhclient is spinning and check the values of interface-rbuf_offset, interface-rbuf_len, and length in receive_packet() that might tell us something intresting. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpEH1LOU5INk.pgp Description: PGP signature
4.11 b_iodone callback question
I just inherited some older code that runs under 4.11 ... the core of software is a device driver that writes data to two separate disks(da1/da2). It appears that the authors are using a call back function to handle some interesting behavior related to the second disk being a circular buffer. So a couple of questions: 1. Does the call back routine set in b_iodone(disk writes are handled by VOP_STRATEGY) get invoked in a separate thread of execution, i.e. is simultaneous with the main code path? 2. Is it o.k. to have the callback routine invoke itself vi b_iodone(more VOP_STRATEGY) without locking the buffers used for the disk writes? Sean Bruno ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
4.11 b_iodone callback question
I just inherited some older code that runs under 4.11 ... the core of software is a device driver that writes data to two separate disks(da1/da2). It appears that the authors are using a call back function to handle some interesting behavior related to the second disk being a circular buffer. So a couple of questions: 1. Does the call back routine set in b_iodone(disk writes are handled by VOP_STRATEGY) get invoked in a separate thread of execution, i.e. is simultaneous with the main code path? 2. Is it o.k. to have the callback routine invoke itself vi b_iodone(more VOP_STRATEGY) without locking the buffers used for the disk writes? Sean Bruno ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
4.11 b_iodone callback question
I just inherited some older code that runs under 4.11 ... the core of software is a device driver that writes data to two separate disks(da1/da2). It appears that the authors are using a call back function to handle some interesting behavior related to the second disk being a circular buffer. So a couple of questions: 1. Does the call back routine set in b_iodone(disk writes are handled by VOP_STRATEGY) get invoked in a separate thread of execution, i.e. is simultaneous with the main code path? 2. Is it o.k. to have the callback routine invoke itself vi b_iodone(more VOP_STRATEGY) without locking the buffers used for the disk writes? Sean Bruno ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
apply
___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.9 won't upgrade ?
[ Redirecting to -stable, where it's more appropriate ] On Mon, Jan 23, 2006 at 07:31:10PM -0500 I heard the voice of Jim Keller, and lo! it spake thus: I go through the whole process, and although it does appear to recompile the system (my openssl went from the original distro to the newest version, for example), uname -a is still reporting the distro as 4.9-RELEASE. That's because you haven't installed the new kernel. Also, it will not install a custom kernel, it always goes to GENERIC, even when I specify KERNCONF= in the buildkernel process. This I dunno about. Were I you, I'd just go ahead and get GENERIC installed and running so that your kernel matches your userland at least, then worry about why your can't seem to build your own kernel. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
POKE
-- Scott Markwell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_malloc
Michael Butler пишет: GreenX FreeBSD wrote: Hi, At me a problem - after one - two weeks of job the machine panics and is reboot, prompt as to see why it occurs that it is possible to make with it? Can you tell us the output of .. sysctl -a | grep ^ata_ .. I have a suspicion .. Michael Hi, Michael #sysctl -a | grep ^ata ata_composit:192,0, 22663,617,65421 ata_request: 200,0, 45326, 1015, 468333 But, I little cvsup system. #uname -a FreeBSD crom.azimutprint.ru 6.0-STABLE FreeBSD 6.0-STABLE #0: Mon Jan 23 11:18:32 MSK 2006 -skip- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
permanent per month panic on 5.4-p4 related to smbfs
Approximately once per month or two this server panics. We use it for InterSystems Cache` (under linux emulation) and as samba-server (not heavy-loaded). Also, we are using smbfs # mount | grep smbfs //[EMAIL PROTECTED]/FTPEXCHANGE on /mnt/exchange (smbfs) //[EMAIL PROTECTED]/FREEBSD on /mnt/FreeBSD (smbfs) Panics mostly happen while active usage of smbfs. # dmesg -a can be found at http://www.dp.uz.gov.ua/dmesg.isc-cache kernel config - http://www.dp.uz.gov.ua/kernel.isc-cache # uname -a FreeBSD isc-cache.dp.uz.gov.ua 5.4-RELEASE-p4 FreeBSD 5.4-RELEASE-p4 #1: Fri Nov 4 11:37:34 EET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ISC-CACHE_KERNEL i386 db where Tracing pid 46479 tid 100104 td 0xc12a1600 turnstile_head(0,c11dd700,c1c42700,c11dd700,cc396b54) at turnstile_head+0x6 _mtx_unlock_sleep(c1c42794,0,c1d6eec2,61) at _mtx_unlock_sleep+0x40 _mtx_unlock_flags(c1c42794,0,c1d6eec2,61,c11dd700) at _mtx_unlock_flags+0x2e smb_iod_invrq(c11dd700,c11dd700,c11dd700,cc396ba4,c1d63766) at smb_iod_invrq+0x43 smb_iod_dead(c11dd700,c1597400,c1597488,c1c42700,cc396bbc) at smb_iod_dead+0x1a smb_iod_addrq(c1c42700,c1c42700,0,c1042a00,cc396bd4) at smb_iod_addrq+0x6e smb_rq_enqueue(c1c42700,c1c42718,c102c5c0,c1042a00,cc396ce4) at smb_rq_enqueue+0x2d smb_rq_simple(c1c42700,c1c42700,c1c42718,c1042a00,c1d6ecd9) at smb_rq_simple+0x2a smb_smb_treeconnect(c1597400,c11dd750,c19a28f0,c11dd700,c11dd758) at smb_smb_treeconnect+0x24e smb_iod_treeconnect(c11dd700,c1597400,c11dd700,c1342a98,c1d63d3c) at smb_iod_treeconnect+0x7b smb_iod_thread(c11dd700,cc396d48) at smb_iod_thread+0xf4 fork_exit(c1d63d3c,c11dd700,cc396d48) at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x8 db ps pid proc uid ppid pgrp flag stat wmesgwchan cmd 38438 c1ba3e200 38437 38384 0004000 [SLPQ 90evw 0xc19a28f0][SLP] df 38437 c1491c5c0 38393 38384 0004000 [SLPQ wait 0xc1491c5c][SLP] sh 38395 c12a0a980 38394 38384 0004000 [SLPQ piperd 0xc10b8600][SLP] mail 38394 c1ba31c40 38386 38384 000 [SLPQ wait 0xc1ba31c4][SLP] sh 38393 c12a08d40 38386 38384 000 [SLPQ wait 0xc12a08d4][SLP] sh 38386 c1ba3a980 38384 38384 0004000 [SLPQ wait 0xc1ba3a98][SLP] sh 38384 c11268d40 38380 38384 0004000 [SLPQ wait 0xc11268d4][SLP] sh 38380 c1ba61c40 433 433 000 [SLPQ piperd 0xc1341180][SLP] cron 35977 c129e1c4 1007 35975 35974 0004003 [SLPQ ttyin 0xc1061210][SLP] cache 35975 c129e54c 1007 35974 35974 0004002 [SLPQ wait 0xc129e54c][SLP] sh 35974 c0f5dc5c0 35973 35974 0004102 [SLPQ wait 0xc0f5dc5c][SLP] login 35973 c1491e200 551 35973 0004000 [SLPQ select 0xc06c4784][SLP] telnetd 35406 c1ba60000 497 35406 101 [RUNQ] cache 34146 c14911c40 451 451 101 [SLPQ select 0xc06c4784][SLP] smbd 1133 c1ba30000 1 1133 0004002 [SLPQ ttyin 0xc1043810][SLP] getty 91944 c13423880 1 91944 0004002 [SLPQ ttyin 0xc0e9c810][SLP] getty 46479 c1342a980 1 0 204 [APU 0] smbiod1 564 c129e3880 1 564 0004002 [SLPQ ttyin 0xc0e9c410][SLP] getty 551 c125854c0 1 551 000 [SLPQ select 0xc06c4784][SLP] inetd 531 c129ea980 497 531 102 [SLPQ select 0xc06c4784][SLP] cache 530 c125ce200 497 530 102 [SLPQ select 0xc06c4784][SLP] cache 527 c125ca980 497 527 102 [SLPQ accept 0xc126d2c2][SLP] cache 525 c125c8d40 524 525 0004002 [SLPQ select 0xc06c4784][SLP] clmanager 524 c125c7100 497 524 102 [SLPQ select 0xc06c4784][SLP] cache 510 c129ec5c0 497 497 102 [SLPQ semwait 0xc0fb][SLP] cache 509 c129ee200 497 497 102 [SLPQ semwait 0xc0fb][SLP] cache 508 c12a0 497 497 102 [SLPQ semwait 0xc0fb][SLP] cache 507 c12587100 497 497 102 [SLPQ semwait 0xc0fb][SLP] cache 506 c108aa980 497 497 102 [SLPQ semwait 0xc0fb][SLP] cache 505 c1258e200 497 497 102 [SLPQ semwait 0xc0fb][SLP] cache 504 c125c3880 497 497 102 [SLPQ semwait 0xc0fb][SLP] cache 503 c108a0000 497 497 102 [SLPQ semwait 0xc0fb][SLP] cache 502 c0f5d1c40 497 497 102 [SLPQ semwait 0xc0fb][SLP] cache 501 c1258a980 497 497 102 [SLPQ semwait 0xc0fb][SLP] cache 500 c125c1c40 497 497 102 [SLPQ semwait 0xc0fb][SLP] cache 497 c125c0000 1 497 0004002 [SLPQ msgwait 0xc0f89000][SLP] cache 455 c108ae200 1 455 001 [SLPQ select 0xc06c4784][SLP] winbindd 453 c108ac5c0 1 453 001 [SLPQ select 0xc06c4784][SLP] nmbd 451 c12580000 1 451 001 [SLPQ select 0xc06c4784][SLP] smbd 417 c0f5da980 1 417 100 [SLPQ select 0xc06c4784][SLP] sshd 342 c0f5d710 64 340 340 100 [SLPQ bpf 0xc10d8100][SLP] pflogd 340 c0f5d8d40 1 340 000 [SLPQ sbwait 0xc10d36ec][SLP] pflogd 271 c0f5de200 1 271 000 [SLPQ select 0xc06c4784][SLP] syslogd 253 c0f5d3880 1 253
