Problems with hw.acpi.cpu.cx_lowest=C2 (Re: cvs commit: src/etc/defaults rc.conf)
On Sun, Jan 29, 2006 at 01:30:07AM -0500, Kris Kennaway wrote: On Sat, Jan 28, 2006 at 10:17:47PM -0800, Nate Lawson wrote: Kris Kennaway wrote: On Sun, Jan 29, 2006 at 01:06:54AM -0500, Kris Kennaway wrote: On Sun, Jan 29, 2006 at 05:51:58AM +, Nate Lawson wrote: njl 2006-01-29 05:51:58 UTC FreeBSD src repository Modified files: etc/defaults rc.conf Log: Enable the lowest Cx state by default. This will save power and we have had enough testing of acpi_cpu to know this is stable now. On my desktop system (running RELENG_6 though), setting hw.acpi.cpu.cx_lowest=C0 causes atrocious performance. Is it broken in 6.x? C2, sorry. Ah, C0 should be disallowed already I thought (try it). As for C2, I MFCd a patch to acpi_cpu.c in November that should prevent this (1.57.2.1). Do you get a printf on console? This might be it: turns out I never rebooted to the newer kernel I built earlier this month, and I am still running a kernel from Nov 6. I'll get back to you. I finally managed to test this in RELENG_6. The system performance is not obviously bad, but sound playback is distorted (e.g. the 'bell' in KDE is much higher pitched than it should be, and on the console it is low pitched and lasting about 3 seconds). Nothing is logged on console. There may be other problems that I didn't notice right away, but the sound problems were enough to make me turn it off again. Kris pgpQNIAyR1x7s.pgp Description: PGP signature
Re: well-supported SATA RAID card?
On 3/10/06, Brian Szymanski [EMAIL PROTECTED] wrote: Howdy... After not having much success with the hptmv driver for highpoint's rocketraid 1820A, I'm wondering if other folks have had good luck with any SATA RAID cards with at least 6 ports... Is there a SATA RAID card with utilities that let you manage while the OS is running that folks have had good luck with? I've been happy with the megaraid series on linux at my job, but I'm wondering if the management utilities are there on freebsd, etc. Anyone care to comment on Areca's ARC-11xx PCI-X cards? I'm thinking about getting an 1130 (12-port version). *Is the arcmsr driver in FreeBSD stable? *Any issues with arrays larger then 2TB? *Rebuild times? *Command Line management software? *Is the company BSD friendly, no binary blob object in the driver? *Competent tech support? *What does the ethernet port on the ARC-1130 do? I'm primarily interested in this card because it can do RAID level 6 and based on the benchmarks I've seen it's a top performer. Anyhow, to the OP, stay way from promise cards. -- BSD Podcasts @ http://bsdtalk.blogspot.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Segfaults from gcc, awk and Zend; advice needed
For some reason I'm getting more or less random segfaults compiling kernels, world or PHP5 on BETA-3 (Python and perl went ok). So far I haven't succeeded building a fresh kernel or world. This system is an Athlon XP with 1MB RAM and 4GB swap, compiling is done in the usual places in /usr, which is a set of two gstriped partitions. Dmesg attached. Previously this system has been running 5-STABLE w/o any such problems (uptime before installing 6 was about 80 days, started from an installworld). This machine doesn't regularly see load yet, except for the few build(world/kernel)/install()s. I haven't seen any other messages of this kind, so I suspect a local problem. So far I think I need to look at: - memory; run memtestx86 and cross fingers - I recollect seeing mention of problems with large amounts of swap on this list in the past; turn one of the swap partitions off or something like that - Optimization flags; I've tried setting CPUTYPE?=athlon-xp and CLFAGS=, CFLAGS=-O -pipe, CFLAGS=-O2 -pipe so far. All w/o avail... - gcc 3.4.4, awk, PHP are all borken (all were built using gcc 3.4.4, I suppose) I'm a bit low on spare time, so I'd like to tackle this problem efficiently. Anything I forgot or to help me find the culprit? Regards, dmesg.out Description: Binary data -- Alban Hertroys Sometimes you wake up and you think: Galileo was right, The world does rotate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: VFS SMP stability changes merged to RELENG_6 for next beta
Jeff Roberson merged a large number of VFS stability improvements to the RELENG_6 tree this morning. These are intended to appear in the next beta, and in stability tests run by Kris and others, they appear to help a lot. However, change comes with risk, and as such, this message is to let you know that the changes have gone into the tree and you might want to, among other things, make sure that you either have a kernel from completely before, or completely after, the series of commits, and you might want to wait 24-48 hours to upgrade to make sure no immediate problems turn up. The commits were performed between 3:00am UTC and 3:15am UTC today against the central CVS repository, and likely have appeared on all of the cvsup mirrors by now. Despite these warnings, it would be really good (tm) if people could run with them as much and as soon as possible in order to shake out any nits before the next beta. They've been getting pretty heavy testing in HEAD, but -CURRENT doesn't offer the testing breadth that -STABLE does, and getting that breadth is really important to the release. Jeff's brief description of the changes is attached below, and as you can see, they're all really good things to have in the release. Robert N M Watson 1) Improved debugging with DEBUG_LOCKS via the new stack(9) api. 2) Fixed an INACTIVE leak. 3) Fixed several unmount races. 4) Fixed several nullfs unmount issues. 5) Some more Giant related VFS fixes and asserts. 6) Fixed the quota deadlock. 7) Fixes for an alarming number of snapshot races. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failing to understand getrusage()
On Sat, Mar 11, 2006 at 01:49:50AM +0300, Yar Tikhiy wrote:
On Tue, Mar 07, 2006 at 06:12:59PM +0200, Kostik Belousov wrote:
It may be desirable to add ru_maxrss sampling at the calcru time too.
Something like this:
Index: sys/kern/kern_resource.c
===
RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_resource.c,v
retrieving revision 1.156
diff -u -r1.156 kern_resource.c
--- sys/kern/kern_resource.c22 Feb 2006 16:58:48 - 1.156
+++ sys/kern/kern_resource.c7 Mar 2006 16:10:27 -
@@ -853,9 +853,16 @@
struct rusage *rup;
{
struct proc *p;
+ struct vmspace *vm;
+ long rss;
p = td-td_proc;
PROC_LOCK(p);
+ vm = p-p_vmspace;
+ rss = pgtok(vmspace_resident_count(vm));
+ if (rup-ru_maxrss rss)
+ rup-ru_maxrss = rss;
+
switch (who) {
case RUSAGE_SELF:
Please excuse me for a dumb question, but what makes ru_maxrss so
different from other ru_ fields that it deserves special handling
in kern_getrusage()? Perhaps the all-or-nothing approach will be
better for the sake of consistency...
Current resource usage accounting is inaccurate (i.e. done at sampling
points) only for several fields, ru_maxrss being one of them. E.g.,
ru_nsignals is precise.
Sure, the best would be implementing approach like solaris microaccounting
(AFAIR, solaris could measure used parts of the time-slice where
the thread runs on CPU, and do this measure on demand, not stressing
the system when the exact numbers are not needed).
My small fix just add little more sence to result of maxrss calculation,
making it to never return meaningless values like 0. Better, pmaps
shall be modified to correctly set maxrss (this seems to be not hard,
could someone look at the patch if I implement it ?).
pgp4ig0oR3kx0.pgp
Description: PGP signature
Re: kde
Steinberg, Michael wrote: im compiling kde from the ports for about the hundreth time and something always goes wrong this time its more simple than most but i can't seem to find what im looking for. It attempted to fetch a library called tiff.4 in several places and found nothing. It asked me to find it and ive been looking all over google and got nothing. Does anybody know where i can find this library? Thanx, Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Maybe you just got to get more down and dirty. If its really getting tough and there seems no end in sight try a portupgrade -kfa which I have always assumed stands for (along with the old doom cheat codes) Kick F**ken Ass :) Also try with the -p switch to create packages which might save some time on mass package nukes and retrys, or even a -O to ignore dependencies. Also if you get stuck on something small like tiff try just installing it as a package over the internet. pkg_add -r tiff to install a binary package of it, you could also do a -f on that to force it, which is something that should be considered to at the top of your list. I almost always have a good look through my /var/db/pkg before and after even the most ruthless portupgrade I usually find it remarkably clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_6 tinderbox] failure on sparc64/sparc64
TB --- 2006-03-13 10:37:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-03-13 10:37:02 - starting RELENG_6 tinderbox run for sparc64/sparc64 TB --- 2006-03-13 10:37:02 - cleaning the object tree TB --- 2006-03-13 10:37:31 - checking out the source tree TB --- 2006-03-13 10:37:31 - cd /tinderbox/RELENG_6/sparc64/sparc64 TB --- 2006-03-13 10:37:31 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2006-03-13 10:47:32 - building world (CFLAGS=-O2 -pipe) TB --- 2006-03-13 10:47:32 - cd /src TB --- 2006-03-13 10:47:32 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything TB --- 2006-03-13 11:51:45 - generating LINT kernel config TB --- 2006-03-13 11:51:45 - cd /src/sys/sparc64/conf TB --- 2006-03-13 11:51:45 - /usr/bin/make -B LINT TB --- 2006-03-13 11:51:45 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-03-13 11:51:45 - cd /src TB --- 2006-03-13 11:51:45 - /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Mar 13 11:51:46 UTC 2006 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] db_trace.o(.text+0x714): In function `stack_save': : undefined reference to `tl_text_begin' db_trace.o(.text+0x718): In function `stack_save': : undefined reference to `tl_text_end' db_trace.o(.text+0x71c): In function `stack_save': : undefined reference to `tl_text_begin' db_trace.o(.text+0x724): In function `stack_save': : undefined reference to `tl_text_end' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-03-13 12:03:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-03-13 12:03:20 - ERROR: failed to build lint kernel TB --- 2006-03-13 12:03:20 - tinderbox aborted TB --- 1.04 user 4.55 system 5178.35 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Segfaults from gcc, awk and Zend; advice needed
Alban wrote: For some reason I'm getting more or less random segfaults compiling kernels, world or PHP5 on BETA-3 (Python and perl went ok). So far I haven't succeeded building a fresh kernel or world. This system is an Athlon XP with 1MB RAM and 4GB swap, compiling is done in the usual places in /usr, which is a set of two gstriped partitions. Dmesg attached. If the crashes aren't repeatable (ie, the compiler segfaults in different places if you re-do the make), that's an almost sure sign of hardware problems like overheating. - Optimization flags; I've tried setting CPUTYPE?=athlon-xp and CLFAGS=, CFLAGS=-O -pipe, CFLAGS=-O2 -pipe so far. All w/o avail... If you're having problems, use the default compiler flags. Trying to add machine-specific optimizations into the mix is going to introduce spurious issues and make it harder to figure out the real problem. - gcc 3.4.4, awk, PHP are all borken (all were built using gcc 3.4.4, I suppose) I'm a bit low on spare time, so I'd like to tackle this problem efficiently. Anything I forgot or to help me find the culprit? I suppose you could wait until 6.1 is released and do a binary install/upgrade? -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: well-supported SATA RAID card?
Anyone care to comment on Areca's ARC-11xx PCI-X cards? I'm ?thinking about getting an 1130 (12-port version). We just installed an ARC-1160 so I'll try and answer as many of your questions that I can. *Is the arcmsr driver in FreeBSD stable? I've had no issues. *Any issues with arrays larger then 2TB? I think Areca does things a little differently than some of the other cards (someone correct me if I'm wrong on this.) Basically you setup a RAID set, which is just a set of disks. Then you setup volumes in that RAID set. The volumes are where you define RAID level and Ch/Id/Lun for access under an OS. The cards can handle volumes 2TB without a problem and supports both ways (Windows and LBA) of handling the volumes. We currently have a 3.6TB volume (11 400GB drives under RAID 6) available under FreeBSD 6-STABLE with no real problems other than the gotchas that are known basically. Here's the page on FreeBSD's website about that: http://www.freebsd.org/projects/bigdisk/index.html *Rebuild times? Can't give you an exact since it's been a while since I tested the original rebuild, but we've migrated the RAID set (and volume) twice since getting the system and the migrations happened within hours. I was able to expand the RAID Set (adding drives) and expand the corresponding volume set to fill the drives all while the system was running without a hitch. *Command Line management software? Haven't played with the CLI much yet, but it seems to handle every command you would need to send to the card. *Is the company BSD friendly, no binary blob object in the driver? Latest driver was built right into the kernel. Updates on Areca's website are in source form. *Competent tech support? I've only used their support when I originally got an 8 port card. They were very helpful in answering my questions to realize I needed the 16-port to do what I wanted. *What does the ethernet port on the ARC-1130 do? Out of Band management (telnet and HTTP) directly to the card. The 1130 and above all have the Ethernet and will also do email notifications directly without OS intervention. Eliminates the need to run a daemon under FreeBSD. We've found the HTTP management daemon under FreeBSD to have some problems (Core dumps occasionally), but once we started using the Ethernet port we didn't need to worry about that. I'm primarily interested in this card because it can do RAID level 6 and based on the benchmarks I've seen it's a top performer. Everything has been smooth with the Areca and we are using RAID 6 without any issues. I haven't done major performance tests myself so I can't give you any hard numbers, but we've been very pleased with the system. The problems I had were some initial corruption on our large volumes at the beginning do to a crash (my fault) with a softupdates volume. When trying to fsck the partition it told me I needed over 2.5GB of RAM to fsck the partition. Researching the problem came out with an answer of filesystem corruption that would be fixed easily, so I just reworked our partitions so that I had multiple smaller partitions and removed softupdates for now. I've crashed the system a few times since then and fsck worked just fine. Any other questions you have, feel free to ask. Jaime Bozza ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
/usr/local/etc/rc.d script problem
Hi to everyone! Seems i got a small problem with my startup scripts. I have record in /etc/rc.conf: local_startup=/usr/local/etc/rc.d And a few scripts in this directory. Normal configuration. On all servers it works great except one. I don't know where is a problem is, because it is identical configuration. But seems system is ignoring these scripts. It doesn't start any script from this directory. Maybe someone can give me an advice where is a problem is? Thanks! Victoria ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d script problem
From: victoria [EMAIL PROTECTED] Subject: /usr/local/etc/rc.d script problem Hi to everyone! Seems i got a small problem with my startup scripts. I have record in /etc/rc.conf: local_startup=/usr/local/etc/rc.d You shouldn't need that option, since the default value in /etc/defaults/rc.conf already includes that directory. Unless there is another reason... And a few scripts in this directory. Normal configuration. On all servers it works great except one. I don't know where is a problem is, because it is identical configuration. But seems system is ignoring these scripts. It doesn't start any script from this directory. Maybe someone can give me an advice where is a problem is? Thanks! Victoria The information you're giving is perhaps not enough. Are you sure you have *_enable=YES in rc.conf for each script you want to run? Check rc.conf, rc.conf.local and the scripts, and if you're unable to find out what's wrong, post them. It may also be useful if you tell us what version of FreeBSD are you running. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone seen this scsi error before ?
Graham Bentley wrote: Recently swapped out my Sony for a HP DAT and got this first time in dmesg (sa0:ahc0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 0 0 (sa0:ahc0:0:6:0): CAM Status: SCSI Status Error (sa0:ahc0:0:6:0): SCSI Status: Check Condition (sa0:ahc0:0:6:0): UNIT ATTENTION asc:28,0 (sa0:ahc0:0:6:0): Not ready to ready change, medium may have changed (sa0:ahc0:0:6:0): Unretryable error Anyone shed any light upon it ? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Hi, i've got similar (but not exact the same) problem with my SCSI controller on my freebsd box freshly installed with default options 9GENERIC kernel etc etc).Server model is HP DL 140.My 'uname -a' is: web# uname -a FreeBSD web.x.com 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Mon Feb 20 09:16:50 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 web# dmesg is attached.Any advice on what is happening ? Mar 11 13:00:52 web kernel: mpt0: Request 0xc4bc06e8 Timed out. Mar 11 13:00:52 web kernel: mpt0: Request 0xc4bbf478 Timed out. Mar 11 13:00:52 web kernel: mpt0: Request 0xc4bc02d8 Timed out. Mar 11 13:00:52 web kernel: mpt0: Request 0xc4bc0080 Timed out. Mar 11 13:00:52 web kernel: mpt0: Attempting to Abort Req 0xc4bbfdd8 Mar 11 13:06:12 web kernel: mpt0: mpt_recover_commands: Abort timed-out.Resetting controller Mar 11 13:06:12 web kernel: mpt0: soft reset failed: ack timeout Mar 11 13:06:12 web kernel: mpt0: WARNING - Failed hard reset! Trying to initialize anyway. Mar 11 13:06:12 web kernel: mpt0: Unhandled Event Notify Frame. Event 0xc086250d. Mar 11 13:06:12 web kernel: (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 0 0 85 95 8f 0 0 20 0 Mar 11 13:06:12 web kernel: (da0:mpt0:0:0:0): CAM Status: SCSI Status Error Mar 11 13:06:12 web kernel: (da0:mpt0:0:0:0): SCSI Status: Check Condition Mar 11 13:06:12 web kernel: (da0:mpt0:0:0:0): UNIT ATTENTION asc:29,2 Mar 11 13:06:12 web kernel: (da0:mpt0:0:0:0): Scsi bus reset occurred Mar 11 13:06:12 web kernel: (da0:mpt0:0:0:0): Retrying Command (per Sense Data) Copyright (c) 1992-2006 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 6.1-PRERELEASE #0: Mon Feb 20 09:16:50 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2822.51-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 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=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2010NX,LM Hyperthreading: 2 logical CPUs real memory = 1073152000 (1023 MB) avail memory = 1041223680 (992 MB) npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: Host to PCI bridge pcibus 0 on motherboard pir0: PCI Interrupt Routing Table: 25 Entries on motherboard pci0: PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pcib1: PCIBIOS PCI-PCI bridge irq 5 at device 2.0 on pci0 pci1: PCI bus on pcib1 pcib2: PCIBIOS PCI-PCI bridge irq 5 at device 4.0 on pci0 pci2: PCI bus on pcib2 bge0: Broadcom BCM5721 Gigabit Ethernet, ASIC rev. 0x4101 mem 0xdd10-0xdd10 irq 5 at device 0.0 on pci2 miibus0: MII bus on bge0 brgphy0: BCM5750 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:15:60:5f:66:fe pcib3: PCIBIOS PCI-PCI bridge irq 5 at device 5.0 on pci0 pci3: PCI bus on pcib3 bge1: Broadcom BCM5721 Gigabit Ethernet, ASIC rev. 0x4101 mem 0xdd20-0xdd20 irq 5 at device 0.0 on pci3 miibus1: MII bus on bge1 brgphy1: BCM5750 10/100/1000baseTX PHY on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:15:60:5f:66:ff pcib4: PCIBIOS PCI-PCI bridge irq 5 at device 6.0 on pci0 pci4: PCI bus on pcib4 pcib5: PCIBIOS PCI-PCI bridge at device 0.0 on pci4 pci5: PCI bus on pcib5 pci4: base peripheral, interrupt controller at device 0.1 (no driver attached) pcib6: PCIBIOS PCI-PCI bridge at device 0.2 on pci4 pci6: PCI bus on pcib6 mpt0: LSILogic 1030 Ultra4 Adapter port 0x2000-0x20ff mem 0xdd42-0xdd43,0xdd40-0xdd41 irq 5 at device 3.0 on pci6 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.14.0 mpt0: Unhandled Event Notify Frame. Event 0xa. pci4: base peripheral, interrupt controller at device 0.3 (no driver attached) uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 5 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root
Re: Kernel INCLUDE_CONFIG_FILE workaround?
Jorge Aldana wrote: I'm on 6.1PreRelease and this works: strings -n 3 /boot/kernel/kernel | grep -v | sed -n 's/^___//p' There was a minor tweek in this line back in 5.X transition form 4.X but my script works fine for 6.X since then. Note that the problem isn't in the line you provided above that extracts the built-in configuration file. It's in the build procedure that's supposed to put the config file into the kernel in the first place. In other words, options INCLUDE_CONFIG_FILE doesn't include *all* the configuration data, because it doesn't include included configuration files. It's only including the very first level of nested configuration files, which is not an accurate representation of what's in the kernel. In my example, the configuration file for GENERIC should've been in there somewhere, as well as anything included by GENERIC (such as the stuff in DEFAULTS). Again, this used to work great, but appears to have been broken in favor of... usability? -- Alan Amesbury University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
UID/GID ranges (was Re: Required audit group is missing...)
Looks like the Handbook needs to be updated to reflect this, as audit isn't currently listed. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-uid-and-gids.html -- Alan Amesbury University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with NDIS - FreeBSD 6.1-PRERELEASE
Hello! I've a problem with NDIS and a 'PRISM 802.11g Wireless Adapter (3890)' because if I do an 'ifconfig ndis0 inet 192.168...' I must wait about !!!5 MINUTES!!! for the finish of ifconfig... My System: Medion MD41300 Notebook with P4 3.06GHz HT CPU Windows driver for the WLAN chip: http://www1.medion.de/downloads/download.pl?id=1870type=treiberfilename=wlanwid2010win2kxp.exelang=de pciconf -lv [EMAIL PROTECTED]:6:0: class=0x028000 card=0x001417cf chip=0x38901260 rev=0x01 hdr=0x00 vendor = 'Intersil Americas Inc (Was: Harris Semiconductor)' device = 'ISL3890 PRISM GT 802.11g 54Mbps Wireless Controller' class= network FreeBSD 6.1-PRERELEASE #2: Sun Mar 12 23:36:01 CET 2006 That's what I've done: - I've built a kernel with SMP support, NDISAPI etc. (for details see the following config): http://net.razik.de/temp/RAZIK2006-03-12-6 - I've built a kernel module with 'ndisgen PRISMA00.inf PRISMA00.sys' - its name is: 'PRISMA00_sys.ko' - In my rc.conf I have the following line: ifconfig_ndis0=inet 192.168.0.7 netmask 255.255.255.0 ssid razik.de wepmode mixed wepkey 1:0xABCDEF... deftxkey 1 (It doesn't matter if I use WEP or not...) It's not possible to load the PRISMA00_sys.ko module at startup (because of an error), so my current loader.conf is: kernel=kernel.6.0-STABLE snd_ich_load=YES linux_load=YES nvidia_load=YES wlan_wep_load=YES After system startup I load the module manually by typing 'kldload PRISMA00_sys' and I get: ndis0: PRISM 802.11g Wireless Adapter (3890) mem 0xd2004000-0xd2005fff irq 18 at device 6.0 on pci3 can't re-use a leaf (BusType)! ndis0: NDIS API version: 5.1 And about 40 seconds later i get ndis0: Ethernet address: 00:60:b3:9d:46:dc After loading the module I can see (by typing 'ps ax') that ifconfig is automatically started (? by /etc/pccard_ether ?) and tries to configure the ndis0 device like it is written in the rc.conf. That takes about 5 minutes!!! If I delete the config line for the ndis0 device in my rc.conf and kldload the PRISMA00_sys module and ifconfig ndis0 manually it also takes about 5 minutes... And it doesn't matter if I set 'machdep.hyperthreading_allowed=1' or not. After the 5 minutes (if the system doesn't crash) I get this from 'ifconfig ndis0': ndis0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::260:b3ff:fe9d:46dc%ndis0 prefixlen 64 scopeid 0x4 inet 192.168.0.7 netmask 0xff00 broadcast 192.168.0.255 ether 00:60:b3:9d:46:dc media: IEEE 802.11 Wireless Ethernet autoselect status: associated ssid razik.de channel 9 bssid 00:13:10:27:e4:c8 authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpowmax 100 protmode CTS And normally I can use the WLAN chip without problems then... Does anyone have an idea why ifconfig needs so long to setup the device? Regards, Lukas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with hw.acpi.cpu.cx_lowest=C2 (Re: cvs commit: src/etc/defaults rc.conf)
Kris Kennaway wrote: On Sun, Jan 29, 2006 at 01:30:07AM -0500, Kris Kennaway wrote: On Sat, Jan 28, 2006 at 10:17:47PM -0800, Nate Lawson wrote: Kris Kennaway wrote: On Sun, Jan 29, 2006 at 01:06:54AM -0500, Kris Kennaway wrote: On Sun, Jan 29, 2006 at 05:51:58AM +, Nate Lawson wrote: njl 2006-01-29 05:51:58 UTC FreeBSD src repository Modified files: etc/defaults rc.conf Log: Enable the lowest Cx state by default. This will save power and we have had enough testing of acpi_cpu to know this is stable now. On my desktop system (running RELENG_6 though), setting hw.acpi.cpu.cx_lowest=C0 causes atrocious performance. Is it broken in 6.x? C2, sorry. Ah, C0 should be disallowed already I thought (try it). As for C2, I MFCd a patch to acpi_cpu.c in November that should prevent this (1.57.2.1). Do you get a printf on console? This might be it: turns out I never rebooted to the newer kernel I built earlier this month, and I am still running a kernel from Nov 6. I'll get back to you. I finally managed to test this in RELENG_6. The system performance is not obviously bad, but sound playback is distorted (e.g. the 'bell' in KDE is much higher pitched than it should be, and on the console it is low pitched and lasting about 3 seconds). Nothing is logged on console. There may be other problems that I didn't notice right away, but the sound problems were enough to make me turn it off again. Are you sure that's the cause? (Does setting cx_lowest to C1 fix it?) Can you send the output of sysctl hw.acpi so we can see how often each cx type is being run? -- Nate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
I did some further testing and it turns out that rpc.lockd is broken in some cases when operating over NFSv2 (this is the default for nfs root mounts). Tracing the lock traffic I see the client making a request, the server replying but the client never acting on the reply (or never receiving it), so it just retransmits every 20 seconds forever. That is what I saw Friday, using the debug log mainly. I was expecting to find some error message, but I only saw the repetition of something that seemed to be ok. I tried vainly to look into rpc.lockd but it's not at all simple. But my greatest frustration was than when I started rpc.lockd with -d on the client, the problem did never occur. It didn't occur to me that the difference between this and other clients was that the diskless mount is NFSv2. I can't be 100% sure that the problem I have is the same you observed, but locking works on this client on other mounts (home directories through amd, NFSv3). It really seems an NFSv2 specific issue. I'm not yet sure whether this is a regression in 6.x or another case that was broken forever. I didn't have problems in 5. I just compiled a 6.0-RELEASE kernel, and it is also broken. Unfortunately there's currently no option to use NFSv3 for nfs root mounts to work around this (unless you're using bootp), but it should just be a trivial matter of adding | NFSMNT_NFSV3 to the flags in nfsclient/nfs_diskless.c:nfs_setup_diskless(): nd-root_args.flags = (NFSMNT_WSIZE | NFSMNT_RSIZE | NFSMNT_RESVPORT); It was only today that I could try your sugestion. But... I get a kernel panic, it can't find init... Looking is nfsclient/bootp_subr.c, it looks like there's a little more to do when mounting via NFSv3. Well, this doesn't work, but thanks to your sugestion, by looking in nfs_diskless.c, I found a loader option to disable lockd, boot.nfsroot.options=lockd. This option is new (it doesn't exist on 6.0). Now I can lock any file not only on /var, but also on /etc, etc. (remember this option in fstab wasn't honored for the root mount) Everything works. Locking in shared home directories also work, because they're NFSv3 mounts (I tried it already...). So, I finally have it working, and all I needed was having this in loader.conf: boot.nfsroot.options=lockd. I'm quite tired of this issue, so, for all I'm concerned, I'm done. Is the NFSv2/rpc.lockd issue reported? Is there any information more that I can provide? I'm available for further information and testing if anyone can't reproduce the bug. I'm glad you could, no daemons on my machine... I failed finding a way to reproduce it on other machines using mount_nfs -2, so aditional assistance may be needed to the developers. If the problem is reported and no further information is needed from me, then I can only thank you and congratulate you for your great effort in understanding what was wrong and pointing a way to work around it. Thank you, Kris, Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with hw.acpi.cpu.cx_lowest=C2 (Re: cvs commit: src/etc/defaults rc.conf)
On Mon, Mar 13, 2006 at 09:03:35AM -0800, Nate Lawson wrote: I finally managed to test this in RELENG_6. The system performance is not obviously bad, but sound playback is distorted (e.g. the 'bell' in KDE is much higher pitched than it should be, and on the console it is low pitched and lasting about 3 seconds). Nothing is logged on console. There may be other problems that I didn't notice right away, but the sound problems were enough to make me turn it off again. Are you sure that's the cause? (Does setting cx_lowest to C1 fix it?) Absolutely sure: the system worked at C1 after boot, then I set it to C2, observed that beeping was broken, then set it back to C1 and observed that it worked again. Can you send the output of sysctl hw.acpi so we can see how often each cx type is being run? # sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.reset_video: 1 hw.acpi.cpu.cx_supported: C1/0 C2/1 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% 0.00% hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0.temperature: 38.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 75.0C hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 Kris pgprl92vJP3G1.pgp Description: PGP signature
No net
Hi all Some bug (very low priority if it's bug) report ? I've strange thing on my FB-box running stable. When I boot the PC if I type Return many time (When BootLoader ask my if I want boot disk1 or disk2) and when I have the screen to chose the boot method...I don't have the network. I cannot ping anything. Event I make ifconfig down/up nothing work whit the network card, I need to reboot. Well you can tell me it's useless to type Return many time (one time is enough...)ok..ok... But in case... Regards. -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. 7 ième étage, plateau D, bureau 10 Heure local/Local time: Mon Mar 13 18:29:52 CET 2006 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: threads/80435: panic on high loads
Martin wrote: David Xu wrote: This bug unlikely should be reported on thread@, your code is a fork bomb, I think it is a warning why recent days the kernel crashed by such attack, can you reproduce it on 6.0 ? 6.0R seems to work fine with this fork bomb. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 on flash disk and swap
If you feel this situation is undesirable, the first thing to do is to put together the patches necessary to allow the kernel to actually track how much ram+swap might be needed to cover the address-space allocations that have been granted. This isn't trivial: just start thinking about shared allocations, forking, copy-on-writem, etc. In order to make this change costless I suspect you'll have to hide it behind a kernel config option. Maybe you'll bill it as mere instrumentation. Then worry about convincing people that overcommit shouldn't be the only option. But once you have your kernel config option to enable proper accounting it should be a short-hop to making a sysctl that can disable overcommit and enforce limits based on the previously mentioned accounting. Most importantly though you won't need to convince anyone that the default ought to be changed. SIGDANGER has essentially been rejected universally by everyone but its creators (IBM), and as it is unusual, don't expect anyone to write a program that uses it. Ditto for any solution that involves madvise or expecting programs to prefault their pages. Other suggestion: build a time machine to go back to 1990 and get early (pages guaranteed) and late (overcommitted) allocation written into POSIX. Somewhat accepted is to ensure allocations must be backed but to also support a M_NORESERVE flag in mmap to permit overcomitted allocations. Anyways, no matter what you must first give the kernel the necessary accounting code. For the record: I believe in overcommit, but I recognize that it violates the semantics people were (foolishly) taught in school. Also, when the system is page-starved it kills the largest consumer of pages that has the same UID as the process that pushed the system over the limit---not merely the largest consumer of pages. So you see, running critical services that carefully pre-allocate and fault their memory is possible within the overcommit framework. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with hw.acpi.cpu.cx_lowest=C2 (Re: cvs commit: src/etc/defaults rc.conf)
On Mon, Mar 13, 2006 at 12:46:46PM -0800, Nate Lawson wrote: Kris Kennaway wrote: On Mon, Mar 13, 2006 at 09:03:35AM -0800, Nate Lawson wrote: I finally managed to test this in RELENG_6. The system performance is not obviously bad, but sound playback is distorted (e.g. the 'bell' in KDE is much higher pitched than it should be, and on the console it is low pitched and lasting about 3 seconds). Nothing is logged on console. There may be other problems that I didn't notice right away, but the sound problems were enough to make me turn it off again. Are you sure that's the cause? (Does setting cx_lowest to C1 fix it?) Absolutely sure: the system worked at C1 after boot, then I set it to C2, observed that beeping was broken, then set it back to C1 and observed that it worked again. Ok, good to know. This looks like a different failure mode where occasionally the system is waking up from the idle too often, but not enough to affect system performance. Actually when I retried C2, performance is bad again. e.g. opening a mailbox in mutt pauses for about 30 seconds before it starts to read the mailbox. top shows CPU activity ping-ponging between: CPU states: 0.0% user, 0.0% nice, 50.0% system, 0.0% interrupt, 50.0% idle and CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Can you send the output of sysctl hw.acpi so we can see how often each cx type is being run? hw.acpi.cpu.cx_supported: C1/0 C2/1 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% 0.00% I'd like to see it after you've set it to C2 for a few minutes. I'm looking to see what happens with cx_usage. It stays at hw.acpi.cpu.cx_usage: 0.00% 100.00% always. Kris pgp6Uq70GGjvk.pgp Description: PGP signature
Re: rpc.lockd brokenness (2)
On Mon, Mar 13, 2006 at 05:15:59PM +, Miguel Lopes Santos Ramos wrote: I'm not yet sure whether this is a regression in 6.x or another case that was broken forever. I didn't have problems in 5. I just compiled a 6.0-RELEASE kernel, and it is also broken. I have verified (using loopback mounts and a fcntl() regression test) that the same locking bug exists in 5.4's rpc.lockd with nfsv2, so if you're not seeing it there then perhaps you're just lucky :( Unfortunately there's currently no option to use NFSv3 for nfs root mounts to work around this (unless you're using bootp), but it should just be a trivial matter of adding | NFSMNT_NFSV3 to the flags in nfsclient/nfs_diskless.c:nfs_setup_diskless(): nd-root_args.flags = (NFSMNT_WSIZE | NFSMNT_RSIZE | NFSMNT_RESVPORT); It was only today that I could try your sugestion. But... I get a kernel panic, it can't find init... Looking is nfsclient/bootp_subr.c, it looks like there's a little more to do when mounting via NFSv3. Yes, I see the same thing. Sorry. It would be nice to have a way to do nfsv3 root mounts, so perhaps I'll work on this some more. Well, this doesn't work, but thanks to your sugestion, by looking in nfs_diskless.c, I found a loader option to disable lockd, boot.nfsroot.options=lockd. This option is new (it doesn't exist on 6.0). Now I can lock any file not only on /var, but also on /etc, etc. (remember this option in fstab wasn't honored for the root mount) Everything works. Locking in shared home directories also work, because they're NFSv3 mounts (I tried it already...). So, I finally have it working, and all I needed was having this in loader.conf: boot.nfsroot.options=lockd. I'm quite tired of this issue, so, for all I'm concerned, I'm done. Yes, this is probably the best possible workaround. Unfortunately, rpc.lockd has no maintainer, so the many bugs and deficiencies in it will probably stay unresolved for the forseeable future. Is the NFSv2/rpc.lockd issue reported? Not yet, I'll file a PR when I get the time. Is there any information more that I can provide? I don't think so, thanks for your help. Kris pgpJHarpOHj3R.pgp Description: PGP signature
Re: Problems with hw.acpi.cpu.cx_lowest=C2 (Re: cvs commit: src/etc/defaults rc.conf)
Kris Kennaway wrote: On Mon, Mar 13, 2006 at 09:03:35AM -0800, Nate Lawson wrote: I finally managed to test this in RELENG_6. The system performance is not obviously bad, but sound playback is distorted (e.g. the 'bell' in KDE is much higher pitched than it should be, and on the console it is low pitched and lasting about 3 seconds). Nothing is logged on console. There may be other problems that I didn't notice right away, but the sound problems were enough to make me turn it off again. Are you sure that's the cause? (Does setting cx_lowest to C1 fix it?) Absolutely sure: the system worked at C1 after boot, then I set it to C2, observed that beeping was broken, then set it back to C1 and observed that it worked again. Ok, good to know. This looks like a different failure mode where occasionally the system is waking up from the idle too often, but not enough to affect system performance. Can you send the output of sysctl hw.acpi so we can see how often each cx type is being run? hw.acpi.cpu.cx_supported: C1/0 C2/1 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% 0.00% I'd like to see it after you've set it to C2 for a few minutes. I'm looking to see what happens with cx_usage. -- Nate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: ffs_valloc: dup alloc
I get the above panic after nfs clients attach to this nfs server and being read/write ops on it after an unclean shutdown. I've fsck'ed the fs, and it marks it as clean, but I get this every time. It's an NFS share of a GEOM stripe (about 2TB). mode = 0100600, inum = 58456203, fs = /mnt panic: ffs_valloc: dup alloc I do have dumps from two crashes so far. This is FreeBSD-6.1-PRERELEASE from Friday-ish. What should I do with these vmcores? (please cc/to me since I am not on -stable list) Thanks! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UID/GID ranges (was Re: Required audit group is missing...)
On Mon, Mar 13, 2006 at 09:37:17AM -0600, Alan Amesbury wrote: Looks like the Handbook needs to be updated to reflect this, as audit isn't currently listed. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-uid-and-gids.html Correct, I've just added it. Thanks! - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgplUEd9bs9sP.pgp Description: PGP signature
Re: SATA drive 1 disappears
Volker wrote: The RAID set is now running degraded. Both systems are running on R 6.0. I know it's more like guesswork, but what might be the reason for these disc errors? Are the discs really dying? When rebooting the system(s) the first disc re-appears for a few days and will disappear again later. The hdu connectors have been checked. Run the hard disc manufacturers diagnostic software. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: threads/80435: panic on high loads
On Tuesday 14 March 2006 01:39, Martin wrote: Martin wrote: David Xu wrote: This bug unlikely should be reported on thread@, your code is a fork bomb, I think it is a warning why recent days the kernel crashed by such attack, can you reproduce it on 6.0 ? 6.0R seems to work fine with this fork bomb. Martin Can anyone add this to 6.1 todo list ? this definitely should be fixed before 6.1R. David Xu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ata panic
Hi, I was trying out a recent RELENG_6 on a VIA mini ITX board with built in CF reader. If a CF is present, the box panics at boot (tried with 2 separate boards and different CFs just in case it was hardware). This is with a RELENG_6 from March 7th with the flash in I get a panic at bootup. ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding enabled, default to accept, logging limited to 9100 packets/entry by default lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on 8237 chip ad0: setting UDMA100 on 8237 chip ad0: 38166MB Seagate ST340014A 8.54 at ata0-master UDMA100 ad0: 78165360 sectors [77545C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: VIA check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=UNSUPPORTED udma=UNSUPPORTED cable=40 wire ad2: setting PIO4 on 8237 chip ad2: 244MB SanDisk SDCFB-256 Rev 0.00 at ata1-master PIO4 Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x20:0xc0699c37 stack pointer = 0x28:0xc0c20b78 frame pointer = 0x28:0xc0c20c14 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 = 0 (swapper) trap number = 18 panic: integer divide fault KDB: stack backtrace: panic(c06c8ad5,c06f119b,0,0,f) at 0xc0511f23 = panic+0x103 trap_fatal(0,0,0,0,c07333c0) at 0xc06910a5 = trap_fatal+0x225 trap(8,28,28,1,0) at 0xc06915d7 = trap+0x20f calltrap() at 0xc068081a = calltrap+0x5 --- trap 0x12, eip = 0xc0699c37, esp = 0xc0c20b78, ebp = 0xc0c20c14 --- __qdivrem(7a2b0,0,0,0,0) at 0xc0699c37 = __qdivrem+0x3b __udivdi3(7a2b0,0,0,0) at 0xc069a0de = __udivdi3+0x16 ad_attach(c3343c80,c3343c80,c32bd800,0,c0c20d24) at 0xc04684af = ad_attach+0x44f device_attach(c3343c80) at 0xc0526c8e = device_attach+0x1be bus_generic_attach(c3217000,c3217000,,2,c3343c80) at 0xc05278a6 = bus_generic_attach+0x12 ata_identify(c3217000,c3147bd0,c0c20d6c,c0523d00,0) at 0xc045906d = ata_identify+0xcd ata_boot_attach(0,c07206b0,c0c20d88,c04e34c7,0) at 0xc04591e5 = ata_boot_attach+0x4d run_interrupt_driven_config_hooks(0,c31459e8,c1ec00,c1e000,c25000) at 0xc0523d00 = run_interrupt_driven_config_hooks+0x1c mi_startup() at 0xc04e34c7 = mi_startup+0xb3 begin() at 0xc0433e55 = begin+0x2c Uptime: 3s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort Below is a dmesg with the CF slot empty. Its been a while since I tried, but I am pretty sure it used to work Mar 6 17:03:54 ps9996 kernel: Copyright (c) 1992-2006 The FreeBSD Project. Mar 6 17:03:54 ps9996 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 6 17:03:54 ps9996 kernel: The Regents of the University of California. All rights reserved. Mar 6 17:03:54 ps9996 kernel: FreeBSD 6.1-PRERELEASE #0: Sat Mar 4 07:20:49 EST 2006 Mar 6 17:03:54 ps9996 kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/gas Mar 6 17:03:54 ps9996 kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Mar 6 17:03:54 ps9996 kernel: CPU: VIA C3 Nehemiah+RNG+ACE (796.77-MHz 686-class CPU) Mar 6 17:03:54 ps9996 kernel: Origin = CentaurHauls Id = 0x698 Stepping = 8 Mar 6 17:03:54 ps9996 kernel: Features=0x381b03fFPU,VME,DE,PSE,TSC,MSR,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE Mar 6 17:03:54 ps9996 kernel: real memory = 517865472 (493 MB) Mar 6 17:03:54 ps9996 kernel: avail memory = 497393664 (474 MB) Mar 6 17:03:54 ps9996 kernel: npx0: [FAST] Mar 6 17:03:54 ps9996 kernel: npx0: math processor on motherboard Mar 6 17:03:54 ps9996 kernel: npx0: INT 16 interface Mar 6 17:03:54 ps9996 kernel: acpi0: CM400 AWRDACPI on motherboard Mar 6 17:03:54 ps9996 kernel: acpi0: Power Button (fixed) Mar 6 17:03:54 ps9996 kernel: Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Mar 6 17:03:54 ps9996 kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 Mar 6 17:03:54 ps9996 kernel: cpu0: ACPI CPU on acpi0 Mar 6 17:03:54 ps9996 kernel: acpi_button0: Power Button on acpi0 Mar 6 17:03:54 ps9996 kernel: acpi_button1: Sleep Button on acpi0 Mar 6 17:03:54 ps9996 kernel: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 Mar 6 17:03:54 ps9996 kernel: pci0: ACPI PCI bus on pcib0 Mar 6 17:03:54 ps9996 kernel: agp0: VIA PM800/PN800/PM880/PN880 host to PCI bridge mem 0xf800-0xf9ff at device 0.0 on pci 0 Mar 6 17:03:54 ps9996 kernel: pcib1: PCI-PCI bridge at device 1.0 on pci0 Mar 6 17:03:54 ps9996 kernel: pci1: PCI bus on pcib1 Mar 6 17:03:54 ps9996 kernel: pci1: display, VGA at device 0.0 (no driver attached) Mar 6 17:03:54 ps9996 kernel: puc0: US Robotics (3Com) 3CP5609 PCI 16550 Modem port 0xe400-0xe407 irq 12 at device 8.0 on pci0 Mar 6 17:03:54
Re: Required audit group is missing...
On Fri, Mar 10, 2006 at 09:48:43PM -0600, Greg Rivers wrote: On Fri, 10 Mar 2006, Alfred Perlstein wrote: ... stable... :D /usr/src # make installworld ERROR: Required audit group is missing, see /usr/src/UPDATING. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. /usr/src # grep audit /usr/src/UPDATING /usr/src # ??? mergemaster -p is your friend. When I bumped into this error (I usually mergemaster after installworld, in contravention of the UPDATING recommendation,) I went to run mergemaster and mergemaster itself barfed, complaining about the lack of the audit group. Sorry, I didn't bother to make a note of the error message. It was easy to fix manually, but a bit weird, given the error message and the lack of anything specific in UPDATING at the time. -- Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ata panic
At 11:38 PM 13/03/2006, Mike Tancsa wrote: Hi, I was trying out a recent RELENG_6 on a VIA mini ITX board with built in CF reader. If a CF is present, the box panics at boot (tried with 2 separate boards and different CFs just in case it was hardware). This is with a RELENG_6 from March 7th with the flash in I get a panic at bootup. Just updated the source to the latest RELENG_6 in case the changes fixed it, but no dice GEOM: new disk ad0 ad0: VIA check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=UNSUPPORTED udma=UNSUPPORTED cable=40 wire ad2: setting PIO4 on 8237 chip ad2: 244MB SanDisk SDCFB-256 Rev 0.00 at ata1-master PIO4 Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x20:0xc069c01b stack pointer = 0x28:0xc0c20b78 frame pointer = 0x28:0xc0c20c14 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 = 0 (swapper) trap number = 18 panic: integer divide fault KDB: stack backtrace: panic(c06caf91,c06f370c,0,0,f) at 0xc0512343 = panic+0x103 trap_fatal(0,0,0,0,c07359a0) at 0xc0693485 = trap_fatal+0x225 trap(8,28,28,1,0) at 0xc06939b7 = trap+0x20f calltrap() at 0xc0682b6a = calltrap+0x5 --- trap 0x12, eip = 0xc069c01b, esp = 0xc0c20b78, ebp = 0xc0c20c14 --- __qdivrem(7a2b0,0,0,0,0) at 0xc069c01b = __qdivrem+0x3b __udivdi3(7a2b0,0,0,0) at 0xc069c4c2 = __udivdi3+0x16 ad_attach(c3199400,c3199400,c32a5000,0,c0c20d24) at 0xc046870b = ad_attach+0x44f device_attach(c3199400) at 0xc05270ae = device_attach+0x1be bus_generic_attach(c3228380,c3228380,,2,c3199400) at 0xc0527cc6 = bus_generic_attach+0x12 ata_identify(c3228380,0,c0c20d6c,c0524120,0) at 0xc04592c9 = ata_identify+0xcd ata_boot_attach(0,c0722c90,c0c20d88,c04e37f7,0) at 0xc0459441 = ata_boot_attach+0x4d run_interrupt_driven_config_hooks(0,c31459f0,c1ec00,c1e000,c25000) at 0xc0524120 = run_interrupt_driven_config_hooks+0x1c mi_startup() at 0xc04e37f7 = mi_startup+0xb3 begin() at 0xc0434095 = begin+0x2c Uptime: 3s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort -- Press a key on the console to reboot, -- or switch off the system now. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Required audit group is missing...
On Tue, Mar 14, 2006 at 04:37:57PM +1100, Andrew Reilly wrote: On Fri, Mar 10, 2006 at 09:48:43PM -0600, Greg Rivers wrote: On Fri, 10 Mar 2006, Alfred Perlstein wrote: ... stable... :D /usr/src # make installworld ERROR: Required audit group is missing, see /usr/src/UPDATING. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. /usr/src # grep audit /usr/src/UPDATING /usr/src # ??? mergemaster -p is your friend. When I bumped into this error (I usually mergemaster after installworld, in contravention of the UPDATING recommendation,) I went to run mergemaster and mergemaster itself barfed, complaining about the lack of the audit group. Sorry, I didn't bother to make a note of the error message. You ran mergemaster, not mergemaster -p. Kris pgpYQQe8Bg0fz.pgp Description: PGP signature
Re: ata panic
Mike Tancsa wrote: At 11:38 PM 13/03/2006, Mike Tancsa wrote: Hi, I was trying out a recent RELENG_6 on a VIA mini ITX board with built in CF reader. If a CF is present, the box panics at boot (tried with 2 separate boards and different CFs just in case it was hardware). This is with a RELENG_6 from March 7th with the flash in I get a panic at bootup. Just updated the source to the latest RELENG_6 in case the changes fixed it, but no dice Hmm, thats not the intended behavior :) Thanks for the report, I'll look into this ASAP! -Søren GEOM: new disk ad0 ad0: VIA check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=UNSUPPORTED udma=UNSUPPORTED cable=40 wire ad2: setting PIO4 on 8237 chip ad2: 244MB SanDisk SDCFB-256 Rev 0.00 at ata1-master PIO4 Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x20:0xc069c01b stack pointer = 0x28:0xc0c20b78 frame pointer = 0x28:0xc0c20c14 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 = 0 (swapper) trap number = 18 panic: integer divide fault KDB: stack backtrace: panic(c06caf91,c06f370c,0,0,f) at 0xc0512343 = panic+0x103 trap_fatal(0,0,0,0,c07359a0) at 0xc0693485 = trap_fatal+0x225 trap(8,28,28,1,0) at 0xc06939b7 = trap+0x20f calltrap() at 0xc0682b6a = calltrap+0x5 --- trap 0x12, eip = 0xc069c01b, esp = 0xc0c20b78, ebp = 0xc0c20c14 --- __qdivrem(7a2b0,0,0,0,0) at 0xc069c01b = __qdivrem+0x3b __udivdi3(7a2b0,0,0,0) at 0xc069c4c2 = __udivdi3+0x16 ad_attach(c3199400,c3199400,c32a5000,0,c0c20d24) at 0xc046870b = ad_attach+0x44f device_attach(c3199400) at 0xc05270ae = device_attach+0x1be bus_generic_attach(c3228380,c3228380,,2,c3199400) at 0xc0527cc6 = bus_generic_attach+0x12 ata_identify(c3228380,0,c0c20d6c,c0524120,0) at 0xc04592c9 = ata_identify+0xcd ata_boot_attach(0,c0722c90,c0c20d88,c04e37f7,0) at 0xc0459441 = ata_boot_attach+0x4d run_interrupt_driven_config_hooks(0,c31459f0,c1ec00,c1e000,c25000) at 0xc0524120 = run_interrupt_driven_config_hooks+0x1c mi_startup() at 0xc04e37f7 = mi_startup+0xb3 begin() at 0xc0434095 = begin+0x2c Uptime: 3s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort -- Press a key on the console to reboot, -- or switch off the system now. . ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ata panic
At 01:37 AM 14/03/2006, Søren Schmidt wrote: Mike Tancsa wrote: At 11:38 PM 13/03/2006, Mike Tancsa wrote: Hi, I was trying out a recent RELENG_6 on a VIA mini ITX board with built in CF reader. If a CF is present, the box panics at boot (tried with 2 separate boards and different CFs just in case it was hardware). This is with a RELENG_6 from March 7th with the flash in I get a panic at bootup. Just updated the source to the latest RELENG_6 in case the changes fixed it, but no dice Hmm, thats not the intended behavior :) Thanks for the report, I'll look into this ASAP! Thanks! I also just confirmed a kernel from Feb 1 boots up OK, but not with boot -v ?? eg here is a regular boot from the Feb 1 kernel WARNING: WITNESS option enabled, expect reduced performance. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: VIA C3 Nehemiah+RNG+ACE (796.77-MHz 686-class CPU) atapci0: VIA 6420 SATA150 controller port 0xeb00-0xeb07,0xe000-0xe003,0xe100-0xe107,0xe200-0xe203,0xe300-0xe30f,0xd400-0xd4ff irq 10 at device 15.0 on pci0 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 atapci1: VIA 8237 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe500-0xe50f at device 15.1 on pci0 ata0: ATA channel 0 on atapci1 ata1: ATA channel 1 on atapci1 Timecounters tick every 1.000 msec Fast IPsec: Initialized Security Association Processing. ad0: 38166MB Seagate ST340014A 8.54 at ata0-master UDMA100 ad2: 244MB SanDisk SDCFB-256 Rev 0.00 at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s1a where as boot -v gives ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on 8237 chip ad0: setting UDMA100 on 8237 chip ad0: 38166MB Seagate ST340014A 8.54 at ata0-master UDMA100 ad0: 78165360 sectors [77545C/16H/63S] 16 sectors/interrupt 1 depth queue ata1-master: pio=PIO4 wdma=UNSUPPORTED udma=UNSUPPORTED cable=40 wire ad2: setting PIO4 on 8237 chip ad2: 244MB SanDisk SDCFB-256 Rev 0.00 at ata1-master PIO4 Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc06d7637 stack pointer = 0x28:0xc0c20b64 frame pointer = 0x28:0xc0c20bec 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 = 0 (swapper) [thread pid 0 tid 0 ] Stopped at __qdivrem+0x3b: divl%ecx,%eax db db bt Tracing pid 0 tid 0 td 0xc078dac0 __qdivrem(7a2b0,0,0,0,0) at __qdivrem+0x3b __udivdi3(7a2b0,0,0,0) at __udivdi3+0x16 ad_describe(c339f700,c339f700,c32df3a0,c33bd800,c31a3600) at ad_describe+0x1b3 ad_attach(c339f700) at ad_attach+0x1e7 device_attach(c339f700,c0c20d28,c339f700,0,c33bd800) at device_attach+0x58 device_probe_and_attach(c339f700) at device_probe_and_attach+0xe0 bus_generic_attach(c328b280,c328b280,,2,c339f700) at bus_generic_attach+0x16 ata_identify(c328b280) at ata_identify+0x1c8 ata_boot_attach(0) at ata_boot_attach+0x3e run_interrupt_driven_config_hooks(0,c1ec00,c1e000,0,c043b215) at run_interrupt_driven_config_hooks+0x18 mi_startup() at mi_startup+0x96 begin() at begin+0x2c db Tracing pid 0 tid 0 td 0xc078dac0 __qdivrem(7a2b0,0,0,0,0) at __qdivrem+0x3b __udivdi3(7a2b0,0,0,0) at __udivdi3+0x16 ad_describe(c339f700,c339f700,c32df3a0,c33bd800,c31a3600) at ad_describe+0x1b3 ad_attach(c339f700) at ad_attach+0x1e7 device_attach(c339f700,c0c20d28,c339f700,0,c33bd800) at device_attach+0x58 device_probe_and_attach(c339f700) at device_probe_and_attach+0xe0 bus_generic_attach(c328b280,c328b280,,2,c339f700) at bus_generic_attach+0x16 ata_identify(c328b280) at ata_identify+0x1c8 ata_boot_attach(0) at ata_boot_attach+0x3e run_interrupt_driven_config_hooks(0,c1ec00,c1e000,0,c043b215) at run_interrupt_driven_config_hooks+0x18 mi_startup() at mi_startup+0x96 begin() at begin+0x2c db ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kern/94278 (was: threads/80435: panic on high loads)
David Xu wrote: Can anyone add this to 6.1 todo list ? this definitely should be fixed before 6.1R. One of my friends also has found kern/94278: http://www.freebsd.org/cgi/query-pr.cgi?pr=94278 There is no comment on it so far. This crash (without panic) is not less important, in my opinion. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
